[Twisted-Python] Log in - state of the art?
Andrea Arcangeli
andrea at cpushare.com
Sat Nov 6 13:23:01 EST 2004
On Sat, Nov 06, 2004 at 06:04:43PM +0000, exarkun at divmod.com wrote:
> There's already a bug in the tracker, and I added some code along these lines yesterday.
>
> However, after some discussion with James Knight, I don't think the
> set_verify OpenSSL API is of any relevance to this use case. Andrea
> would probably be better off verifying the client certificate at a
> later time. The discussion of exactly where really belongs on the
if you can tell me where should I check it that's fine with me.
> twisted-web mailing list, but as far as the SSL details are
I'm not going to do any web sort of thing, I'm using ssl only to wrap
encryption around a stocket. It looked the fastest way. the protocol
running on top of ssl is a not standard one. This is why I posted here
and not to twisted-web (I'm not even subscribed there).
> concerned, rejecting the certificate at the handshake verification
> time causes the handshake to fail; while it is possible that this is
> a non-fatal error, many implementations will simply drop the
> connection anyway.
>
> When performing an application-level certificate verification
> subsequently, a secure communication channel has been established
> and can be used to communicate the error to the user as, say, a web
> page informing them of the invalidity of their certificate. The
this doesn't look possible, the server side that should emit the
graceful webpage is a malicious attack that would rather show you the
true faked website instead of a warning.
Only the client can notice the error and the graceful message I was
going to add was infact in the client (as soon as I notice the server is
the wrong one and it doesn't match the client certificate stored on the
client harddisk, I will immediatly stop talking with the server).
> drawback of this approach is that it allows attackers to charge you
> the cost of a full SSL handshake and a bit of encrypted traffic.
> The advantages seem to far outweigh this.
full ssl handshake during an attack is fine ;).
> A further problem with the OpenSSL verify callback is that it is
> synchronous and called in the IO thread. For any non-trivial
> application, this is likely to end up blocking the reactor in
> unacceptable ways.
good point. luckily this is not a problem at all for my case, since it's
only invoked in the client and when the client startup, it won't be
asynchronous anyways, since python also need to read the *.py sources from disk ;)
the server truly needs to be always async, and the server won't use the
verify callback (that can only be useful in the client).
Anyways I'm all hears if you've a better solution to do the verify. I
don't claim my solution to be good, but this was the only way I could
make it work so far (and it's pretty much undocumented, that's why I
said it may be appropriate to put more focus on the verification of the
certificate as a more official API in twisted, because without any
verification the ssl protocol is weak).
Please let me know if I should subscribe to twisted-web or if it's ok to
discuss the strict SSL issues here.
thanks for the help!
More information about the Twisted-Python
mailing list