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

[Andrea Arcangeli]

On Fri, Nov 05, 2004 at 02:55:06PM -0500, Mike C. Fletcher wrote:
> I did up a few howtos in my blog a while back:
> 
>    http://blog.vrplumber.com/356

you example to create the keys was helpful thanks.

On the client side I would like to stress encryptions is worthless if we
can't verify the certificate on the other side and there seem not much
power into verifying the certificate in twisted today (if we can't
verify the certificate on the other side a man in the middle may see
everything and forward the packet to the real server). Everybody writing
a client should always verify the certificate somehow otherwise
encryption is worthless.

So the server side is fine, but the client side could be more oriented
towards verification of the certificate.

I'm copying the cacert.pem file (generated as in your blog) into the
client package (the certificate is basically the public key, so I can
make it public) and then the client source will be like this:

def verify_certificate(conn, cert, errno, depth, retcode):
    return crypto.dump_certificate(crypto.FILETYPE_PEM, cert) == server_certificate

class client_context_factory(ssl.ClientContextFactory):
    def getContext(self):
        ctx = SSL.Context(self.method)
        ctx.set_verify(SSL.VERIFY_PEER, verify_certificate)
        return ctx

def main():
    factory = EchoClientFactory()
    global server_certificate
    server_certificate = file("privkey.pem").read()
    reactor.connectSSL('localhost', 8000, factory, client_context_factory())
    reactor.run()

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. the problem is described here too:

http://twistedmatrix.com/pipermail/twisted-python/2003-December/006803.html

I believe SSL is better suited than the ssh protocol for my needs (I
only need to wrap some encryption over a socket and I want to write the
lowest amount of code as possible).

With a 8192 bits key I get around 4 packets sent all under 1400
per-packet (so they should fit most MTUs). Size of the packets is 100
(fixed), 1348, 1228, 1108. A 2048byte key would get away with just 3
packets (the 1348+1228 would shink to a single packet), but I prefer
stronger crypto despite the 1 more pack per connection. I like the idea
to multiplex the connection heavily on the client side, so each client
has only 1 channel open with the server. This should help to keep the
encrytpion cost (cpu and network) down too. I'm a bit scared that python
will become a bottleneck if I multiplex inside python instead of in the
tcp stack, but I expect in the short term to be network bound even in
the server side (the client side is obviously always network bound these
days). At least the server side algorithm is greatly scalable (there's
only 1 very cpu-light operation that is not scalable and has to reside
on a single machine and in the future I may need to rewrite that single
but in C definitely with epoll), the multiplex and the polling is
scalable (though I will need epoll eventually), so I can throw an
hardware farm at the problem if I hit a cpu bottleneck with too many
clients connected. My spare time is more worthy than hardware ;).

I'm optimistic I will not have to rewrite the whole server in C later on ;)

PS. I didn't use the days parameter while generating the certificate, I
assume that means "unlimited" time.