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.<br><br><div><span class="gmail_quote">On 3/1/07,
<b class="gmail_sendername">Latitia Haskins</b> <<a href="mailto:latitia.haskins@gmail.com">latitia.haskins@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><div><span class="q"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>>>> ss.ssl_ctx = M2Crypto.SSL.Context('tlsv1')
<br>>>>>
ss.ssl_ctx.set_cipher_list('ADH-AES128-SHA')<br>>>>> ss.ssl_ctx.set_tmp_dh('dhparam.pem')<br>>>>> ss.ssl_ctx.set_tmp_dh_callback()<br>>>>> ss.ssl_ctx.set_info_callback()
<br><br>set_info_callback can cause problems in some cases, like multithreaded<br>programs. I don't think it is a problem here, though.<br><br>As an SSL server I would also have expected it to load a server<br>certificate into the context.
</blockquote></span><div><br>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.
<br></div><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>>>> ss.create_socket(ss.ssl_ctx)<br>>>>>
ss.set_reuse_addr
()<br>>>>> ss.socket.setblocking(0)<br>>>>> ss.bind(('<a href="http://server.home.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">server.home.com</a> ', 8888))<br>
>>>> ss.listen (5)<br>>>>> sa = ss.socket.accept
()<br><br>It seems like a lot of work when SSL.Connection has an accept() method.</blockquote></span><div><br>I still get the same result either way...<br></div><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> #--------- client -------------------------------<br>>>>> import M2Crypto<br>>>>> import socket<br>>>>> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)<br>>>>> ctx =
M2Crypto.SSL.Context('tlsv1')<br>>>>> ctx.set_cipher_list('ADH-AES128-SHA')<br>>>>> ctx.set_tmp_dh('dhparam.pem')<br>>>>> ctx.set_tmp_dh_callback()<br>>>>>
ctx.set_info_callback ()<br>>>>> s = M2Crypto.SSL.Connection(ctx, sock)<br><br>Again, I wonder why you create socket separately when<br>SSL.Connection.__init__ can do it for you.</blockquote></span><div><br>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.
<br></div></div><br>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.
<br><br>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.
<br><br>
</blockquote></div><br>