[Twisted-Python] getpeername from verify callback
The following sample code worked until Twisted began to prefer memory BIOs over socket BIOs. Now it produces this error... exceptions.AttributeError: 'NoneType' object has no attribute 'getpeername' ...on line 9 where getpeername() is called by the verify() callback. Is there any way to obtain the peer name, given the OpenSSL.SSL.Connection object passed into verify()? Anything that surfaces the underlying socket? (Perhaps something similar to what is done in connectionMade(), which does work.) Or alternatively, is there a way to tell the reactor to employ socket BIOs? Thanks, Nathan ---------------------------------------------- from OpenSSL import SSL from twisted.internet import reactor, ssl from twisted.internet.protocol import ClientFactory from twisted.protocols.basic import LineReceiver class VerifyContextFactory(ssl.ClientContextFactory): def verify(self, connection, x509, errnum, errdepth, ok): print connection.getpeername()[0] return ok def getContext(self): ctx = ssl.ClientContextFactory.getContext(self) ctx.set_verify(SSL.VERIFY_PEER|SSL.VERIFY_FAIL_IF_NO_PEER_CERT, self.verify) return ctx class MyClient(LineReceiver): def connectionMade(self): print "connected to", self.transport.socket.getpeername()[0] return def connectionFailed(self, reason): reactor.stop() def connectionLost(self, reason): reactor.stop() class MyClientFactory(ClientFactory): protocol = MyClient if __name__ == "__main__": reactor.connectSSL('www.example.com', 443, MyClientFactory(), VerifyContextFactory()) reactor.run()
On Oct 18, 2012, at 9:41 PM, Nathan Mower <nathanm@securitymetrics.com> wrote:
The 'socket' attribute that you're accessing is not a documented attribute of ITransport, so in a way I'm glad that your code broke - this wasn't a valid way to use Twisted in the first place :). See <http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.I...>. Now, as it happens, <http://twistedmatrix.com/documents/current/api/twisted.protocols.tls.TLSMemo...> implements <http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.I...> which is a subinterface of <http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.I...>, which is therefore guaranteed to have a getPeer method <http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.I...> that returns an IPv4Address <http://twistedmatrix.com/documents/current/api/twisted.internet.address.IPv4...> or IPv6Address <http://twistedmatrix.com/documents/current/api/twisted.internet.address.IPv6...>, both of which have a 'host' attribute that is the hostname. So, in short, substitute "self.transport.getPeer().host" and your code should work again. -glyph
On 19 October 2012 09:28, Glyph <glyph@twistedmatrix.com> wrote:
Hi, Thanks for the explanation about new interfaces. I think that the initial question was about the SSL.Context.set_verify(connection, certificate, errnum, errdepth, code) callback.
From what I can see, SSL.Context or SSL.Connection has no transport attribute.
In previous version there was SSL.Connection.getpeername() -- Adi Roiban
On Oct 18, 2012, at 11:56 PM, Adi Roiban <adi@roiban.ro> wrote:
In this case, you actually want to pass in the hostname to verify against, not look at the connection. getpeername() ought to return the IP of the host you actually connected to, not the hostname, which is not meaningful to verify against. You need to pass in the host name that the user specified, so that needs to be an argument to the verifying context factory. If you need really need information from the connection itself for verification (although that is usually a bad idea, with the exception of the very specific case that SSH uses it for - although that grants little in the way of useful security, in my opinion), you will have to use connectTCP and startTLS rather than connectSSL, so you can construct a new TLS context once you already have a reference to the protocol object. This is a good thing, though; connectSSL is a slightly silly API and something that I hope will eventually go away; now that we have memory BIOs, TLS can be accomplished just fine without adding additional APIs for every reactor to support. -glyph
On 19 October 2012 07:41, Nathan Mower <nathanm@securitymetrics.com> wrote:
Hi I think that we are talking about this bug: http://twistedmatrix.com/trac/ticket/5684 [snip] -- Adi Roiban
On Oct 18, 2012, at 9:41 PM, Nathan Mower <nathanm@securitymetrics.com> wrote:
The 'socket' attribute that you're accessing is not a documented attribute of ITransport, so in a way I'm glad that your code broke - this wasn't a valid way to use Twisted in the first place :). See <http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.I...>. Now, as it happens, <http://twistedmatrix.com/documents/current/api/twisted.protocols.tls.TLSMemo...> implements <http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.I...> which is a subinterface of <http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.I...>, which is therefore guaranteed to have a getPeer method <http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.I...> that returns an IPv4Address <http://twistedmatrix.com/documents/current/api/twisted.internet.address.IPv4...> or IPv6Address <http://twistedmatrix.com/documents/current/api/twisted.internet.address.IPv6...>, both of which have a 'host' attribute that is the hostname. So, in short, substitute "self.transport.getPeer().host" and your code should work again. -glyph
On 19 October 2012 09:28, Glyph <glyph@twistedmatrix.com> wrote:
Hi, Thanks for the explanation about new interfaces. I think that the initial question was about the SSL.Context.set_verify(connection, certificate, errnum, errdepth, code) callback.
From what I can see, SSL.Context or SSL.Connection has no transport attribute.
In previous version there was SSL.Connection.getpeername() -- Adi Roiban
On Oct 18, 2012, at 11:56 PM, Adi Roiban <adi@roiban.ro> wrote:
In this case, you actually want to pass in the hostname to verify against, not look at the connection. getpeername() ought to return the IP of the host you actually connected to, not the hostname, which is not meaningful to verify against. You need to pass in the host name that the user specified, so that needs to be an argument to the verifying context factory. If you need really need information from the connection itself for verification (although that is usually a bad idea, with the exception of the very specific case that SSH uses it for - although that grants little in the way of useful security, in my opinion), you will have to use connectTCP and startTLS rather than connectSSL, so you can construct a new TLS context once you already have a reference to the protocol object. This is a good thing, though; connectSSL is a slightly silly API and something that I hope will eventually go away; now that we have memory BIOs, TLS can be accomplished just fine without adding additional APIs for every reactor to support. -glyph
On 19 October 2012 07:41, Nathan Mower <nathanm@securitymetrics.com> wrote:
Hi I think that we are talking about this bug: http://twistedmatrix.com/trac/ticket/5684 [snip] -- Adi Roiban
participants (3)
-
Adi Roiban -
Glyph -
Nathan Mower