[Twisted-Python] Log in - state of the art?

[exarkun at divmod.com]

On Sat, 06 Nov 2004 12:48:12 -0500, Itamar Shtull-Trauring <itamar at itamarst.org> wrote:
>On Sat, 2004-11-06 at 18:39 +0100, Andrea Arcangeli wrote:
> 
> > this works fine and the connection is aborted if the certificate is
> > wrong, but I can't intercept the exception to print a meaningful message
> > to the user. This is not a big problem though it'll prevent me to ask
> > the user to autosubmit the stack trace to the server for debugging
> > purposes. 
> 
> Please add an issue in the bug/feature tracker about this
> (http://twistedmatrix.com/bugs/) and put me on the nosy list. If it's
> not in the bug tracker it's not likely to get added cause we'll forget.
> 

  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 twisted-web mailing list, but as far as the SSL details are 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 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.

  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.

  Jp