https://issues.apache.org/bugzilla/show_bug.cgi?id=56324
Dennis Clarke <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P4 Severity|major |normal --- Comment #3 from Dennis Clarke <[email protected]> --- Solution was found at Red Hat site which states that SSLv3 must be in the SSLProtocol list and the there is no promise to deliver a SSL_SESSION_ID in the TLS protocol spec. Therefore change SSLProtocol config to : SSLProtocol +SSLv3 -TLSv1.1 -TLSv1 -TLSv1.2 This results in the following standard ssl envionment variables with the SSL_SESSION_ID set : SERVER_SOFTWARE: Apache/2.4.9 (Unix) PHP/5.4.26 OpenSSL/1.0.1e SSL_CIPHER: DHE-RSA-AES256-SHA SSL_CIPHER_ALGKEYSIZE: 256 SSL_CIPHER_EXPORT: false SSL_CIPHER_USEKEYSIZE: 256 SSL_CLIENT_VERIFY: NONE SSL_COMPRESS_METHOD: NULL SSL_PROTOCOL: SSLv3 SSL_SECURE_RENEG: true SSL_SERVER_A_KEY: rsaEncryption SSL_SERVER_A_SIG: sha1WithRSAEncryption SSL_SESSION_ID: 0d1e27e44864fba71d718fb6ef2b71971b8fd4468f9641d59c1dd36ad2761a24 SSL_SESSION_RESUMED: Initial SSL_VERSION_INTERFACE: mod_ssl/2.4.9 SSL_VERSION_LIBRARY: OpenSSL/1.0.1e The docs at the Red Hat site state : A generic web browser sends "Client Hello" message with "SessionTicket TLS" extension of data length=0 during TLS handshake. If "SessionTicket TLS"(data length=0) is presented by the client, the server will handle a session ticket instead of a session id. Therefore, the server does not generate a session id. On the second access, it sends "Client Hello" with a session ticket which was received in the first access, and the server validate it and, if it is valid, generates a session id. This behavior is defined by RFC5077 and the reason why a session id does not appear at a first access and appears at a second access. This is an unavoidable limitation as long as TLSv1 is used and the client implementation uses the "SessionTicket TLS" extension, however, when configuring the client to use SSLv3 instead of TLSv1, a session id always appears, because SSLv3 has no such extension. Please consider using SSLv3 if possible. I can confirm that the same "limitation" exists with TLS v1.1 and v1.2. Dennis ps: reduced bug report to P4 normal -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
