[PYTHON-CRYPTO] Execute connect_ssl() twice to connect - is this right?
latitia.haskins at GMAIL.COM
Thu Mar 1 23:21:57 CET 2007
> >>>> ss.ssl_ctx = M2Crypto.SSL.Context('tlsv1')
> >>>> ss.ssl_ctx.set_cipher_list('ADH-AES128-SHA')
> >>>> ss.ssl_ctx.set_tmp_dh('dhparam.pem')
> >>>> ss.ssl_ctx.set_tmp_dh_callback()
> >>>> ss.ssl_ctx.set_info_callback()
> set_info_callback can cause problems in some cases, like multithreaded
> programs. I don't think it is a problem here, though.
> As an SSL server I would also have expected it to load a server
> certificate into the context.
I am using anonymous Diffie Hellman (the default is to turn off this
cipher), which only requires the DH parameter file (dhparam.pem), so a
certificate is not necessary at all here. The set_info_callback() was just
so I can verify the handshaking between the server and client. I can remove
it and I still have the same issue.
> >>>> ss.set_reuse_addr()
> >>>> ss.socket.setblocking(0)
> >>>> ss.bind(('server.home.com ', 8888))
> >>>> ss.listen (5)
> >>>> sa = ss.socket.accept()
> It seems like a lot of work when SSL.Connection has an accept() method.
I still get the same result either way...
> #--------- client -------------------------------
> >>>> import M2Crypto
> >>>> import socket
> >>>> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> >>>> ctx = M2Crypto.SSL.Context('tlsv1')
> >>>> ctx.set_cipher_list('ADH-AES128-SHA')
> >>>> ctx.set_tmp_dh('dhparam.pem')
> >>>> ctx.set_tmp_dh_callback()
> >>>> ctx.set_info_callback ()
> >>>> s = M2Crypto.SSL.Connection(ctx, sock)
> Again, I wonder why you create socket separately when
> SSL.Connection.__init__ can do it for you.
Except in this case, the peer certificate is verified by default and I have
no interest in verifying the peer certificate - since there isn't one. So I
do all of the initializing instead of using all of the defaults.
What I mean by client connection, I meant the client socket connecting (with
a regular socket - the "s.socket.connect()"). The client doesn't truly
connect to the server until after the accept is executed and when it does,
it uses SSL. It is very strange.
I initially ran this in linux and today tried it in Windows with a different
result - no need to execute s.connect_ssl() twice! And instead of returning
a result of 0 it actually returns 1. I'm not totally sure what the
difference is between the two. Same exact code, just a different environment
(and build process - that's probably a hint).... If I figure it out, I'll
let you know.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the python-crypto