[PYTHON-CRYPTO] Execute connect_ssl() twice to connect - is this right?

[Latitia Haskins]

Just in case anyone is interested, this issue is due to the inclusion (or in
the case of linux: the exclusion) of applink.c in openssl. When building
without using applink.c, the same phenomenon takes place in Windows as it
does in Linux. So this is an issue with openssl (and the "need" for
rebuilding python using applink.c) not necessarily m2crypto. Also, as it
turns out, a 1 is finally returned after the 3rd connect_ssl() call. A funky
kludge, but it connects just fine in the end.

On 3/1/07, Latitia Haskins <latitia.haskins at gmail.com> wrote:
>
>
> >>>> 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.create_socket(ss.ssl_ctx)
> > >>>> 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...
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20070316/b2bcd045/attachment.html>