[openssl-dev] Storing session in file and reusing at client side
Hello, I wanted to store the freshly negotiated ssl/tls session in a file and reuse it (via SSL_set_session()), in the next handshake. I was not able to do that since the handshake got terminated giving a fatal error - illegal parameters (47). Although this works perfectly fine when I store the session in a global variable at the client side and use it the next time. But I need to use the same session across multiple clients (I hope session does not store the IP and DNS entries). I had the following questions- 1). Why is the session, when stored in an external file, resulting into the "illegal parameter" error? 2). Is there some other way to handle the same session among different client *.c files? Something better than writing down the session in a file (well, even this does not seems to work for me!) It'll be great if someone could help me out on this. Thanks in advance. -- Regards Shubham Chauhan -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts
On Sun May 01 07:32:17 2016, hen...@newdawn.dk wrote: > Thank you all for the assistance - trying to convince Qt/C++ SSL > sockets to do as you've described by cutting down on ciphers. I did > check std Google Chrome ClientHello which does only contain about 10 > cipher suites - where Qt seems to include a lot more (all supported) - > so what i'm trying to determine now is which can I safely skip - based > on name , bit, protocol - this is for a web browser so if anyone have > any insight into which ciphers makes sense here that'd be greatly > appreciated - for now i'm trying to just use the same as other > browsers. Ah I should've been a bit clearer. The -bugs option does *not* cut down the number of ciphersuites it adds a bug workaround. If you set the flag SSL_OP_TLSEXT_PADDING it should work with that server. In a bit more detail. The original problem was triggered by a ClientHello 256 or more bytes in size and is the load balancer bug. After some consultation with the vendor it turns out that the bug is triggered by a ClientHello between 256 and 511 bytes in size.So a workaround was developed that pads the ClientHello so it exceeds 511 bytes in size if it would otherwise be between 256 and 511 bytes. That's what that flag does if you set it. So why isn't this the default behaviour of OpenSSL? Well it was at one point but it turned out a separate implementation (which was OK otherwise) couldn't handle the larger ClientHello with padding. So some buggy servers choke without the flag and some with it. The proper fix of course is for the affected server to update its load balancing software: the bug is actually several years old now. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts
Thank you all for the assistance - trying to convince Qt/C++ SSL sockets to do as you've described by cutting down on ciphers. I did check std Google Chrome ClientHello which does only contain about 10 cipher suites - where Qt seems to include a lot more (all supported) - so what i'm trying to determine now is which can I safely skip - based on name , bit, protocol - this is for a web browser so if anyone have any insight into which ciphers makes sense here that'd be greatly appreciated - for now i'm trying to just use the same as other browsers. Thank you again! On Sat, Apr 30, 2016 at 5:44 PM -0700, "Stephen Henson via RT" wrote: On Sat Apr 30 21:23:30 2016, hen...@newdawn.dk wrote: > Since this is a MS IIS 7.0 server I would argue that it'd be in the > interest of openssl to handle the situation rather than accept this > scenario - since IIS is likely powering more than a few hosts? It is > possible to have the host correctly list its supported protocols using > nmap - i'd assume the TLS1.2 attempt can be avoided altogether ( > without knowing any implementation details or if tht adds overhead > though ) ? > As others have indicated this is a known bug with a load balancer and not IIS. As well as the solutions suggested you can try the -bugs option to s_client which pads client hellos to workaround this issue. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
