[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