On Thu, Apr 19, 2012 at 19:45, Dave Thompson <dthomp...@prinpay.com> wrote:
> > From: owner-openssl-us...@openssl.org On Behalf Of Stéphane > Charette > > Sent: Sunday, 15 April, 2012 20:31 > > > I'm using Openssl to talk to a server that expects to re-use ssl > > sessions when a client needs to open many SSL connections. I have > > the same code working on Linux and Windows. > > Using classic resumption (sessionid) or RFC4507 ticket? > Thanks for the reply, Dave. I believe this is using the classic resumption (sessionid). I did write up some sample code to demonstrate the problem. And using some Mac/iPhone/iPad app to establish SSL connections to FileZilla, this has been confirmed on many devices, so I'm almost certain it isn't just my code. Unless I happen to have made the exact same mistake in the sample code as the application has done. Here is the sample application that works on Linux/Windows, but which hangs when the SSL connection is first established on the Mac: http://charette.no-ip.com:81/asio-openssl/ This code establishes the first SSL connection, then attempts to reuse the session ID to open up a 2nd connection. On a Mac, iPhone, and iPad, it hangs when the 2nd connection is established. Your posted code below doesn't check for error from SSL_connect; > if you do check what do you see? > Note that my code does check for errors. In the e-mail and in the sample code, I did trim a lot of lines to try and make a more concise posting. Can you recreate the problem with commandline s_client with -sess_out > on the first connection and -sess_in on the second, with or without > -no_ticket? If so, -debug and -state will probably be helpful. > Can I re-create the problem with the command-line ssl tool since it requires copying and re-using a ssl sessionid while the first control ssl socket is still active and in use? Is this what you're saying with -sess_out and -sess_in, that I can export the ssl session and re-import it even though it is a different context in a different application? Specifically, prior to doing (any/all) SSL_new(ctx) I assume. > And I assume you aren't changing settings like cipherlist and > compression between connections. Sharing the session *should* > override these, but maybe something might slip through a crack. > Even if so, I don't see any reason it would differ on Mac. > No, I'm not changing any of these. Please see the sample code I link to above. Both get1_session and set_session increment the refcount, so > I believe your session object(s?) will not get cleaned up even > if all connections using them go away and the cache times-out. > But in the usage you describe this is probably just a quite > small memory leak and doesn't matter. > Ooh, thanks for pointing that out. I'll confirm with valgrind, should be obvious if I'm leaking as the application has the potential to create a lot of these secondary ssl connections. Thanks for the help. Stéphane Charette
