Opened 8 years ago

Last modified 8 years ago

#6571 enhancement new

There should be a version of `StringTransport` that pretends to be secure

Reported by: Tom Prince Owned by:
Priority: normal Milestone:
Component: core Keywords: tests
Cc: Branch:
Author:

Description (last modified by Tom Prince)

There are a number of protocols in twisted that check if their underlying transport is secure. Currently, they do that by checking whether it implements ISSLTransport. Unfortunately, that inherits from ITCPTransport which brings along vearious unnecesary tcp-specifice methods.

  1. Create a new interface that can be used to represent the security of the underlying transport that doesn't depend on tcp.
  2. Implement a version of StringTransport that implements that interface.

This is motivated by #6401 and twisted.web.test.requesthelpers.DummyChannel.SSL.

Change History (3)

comment:1 Changed 8 years ago by Tom Prince

Description: modified (diff)

(fix formatting)

comment:2 Changed 8 years ago by Tom Prince

Here is some discussion from IRC:

<tomprince> ISSLTransport/ITLSTransport inherit from ITCPTransport :(
<glyph> tomprince: time for ISSLTransport_Ex?
<glyph> ITransportSecurity maybe, that just describes the security properties, then we could use it for DTLS too.
<glyph> No interface inheritance at all in that case, not even from ITransport.
<tomprince> This is in reference to twisted.web.test.requesthelper.DummyChannel.SSL which claims to implement ISSLTransport.
<exarkun is that bad?
<tomprince> I was going to suggest making an twisted.test.proto_helpers.StringTransportWithSSL that implements that, but then realized it would have to implement get/setTCP methods.
<exarkun Do you know about directlyProvides?
<tomprince> Yes.
<exarkun> So you're concerned about declaring that something implements ISSLTransport without actually implementing all the methods on the interface?
<tomprince> Yes, particularly in generic code like StringTransport, rather than something that isn't more limited in extent.
<glyph> tomprince: Our fixtures should surely be better.
<glyph> tomprince: And more complete.
<glyph> tomprince: MemorySecurityProperties(StringTransport())?
<exarkun> tomprince: You can replace SSL with an instance of StringTransport that provides ISSLTransport without making anything worse
<exarkun I mean sure do what glyph said, but that sounds like a broader ticket than "destroy DummyChannel.TCP"
<tomprince> Well, if it was just a matter of adding getPeerCertificate, it might be reasonable for this ticket.
<exarkun> well, if so, cool.
<tomprince> It isn't. Which is what started this discussion.

comment:3 Changed 8 years ago by Jean-Paul Calderone

The existing SSL transport mess was part of the motivation for twisted.protocols.tls. With twisted.protocols.tls, it's now actually possible to do TLS over *any* ITransport implementation (at least I'll say it is, maybe there are some rough edges to smooth out).

This actually means that it should be possible to do TLS on top of StringTransport without making any changes or additions to StringTransport. Whether is is actually convenient for unit testing or not, I don't know.

Just an idea to keep in mind. Maybe it has no bearing on the practical resolution for this ticket.

Note: See TracTickets for help on using tickets.