Re: Execute connect_ssl() twice to connect - is this right?

Latitia Haskins <[email protected]>
Newsgroups gmane.comp.python.cryptography
Message-ID <[email protected]>
> >>>> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.