Bug 49277

Summary:	Expose a variable to identify SSL Session renegotiated
Product:	Apache httpd-2	Reporter:	Klaubert <klaubert>
Component:	mod_ssl	Assignee:	Apache HTTPD Bugs Mailing List <bugs>
Status:	NEW ---
Severity:	normal	CC:	klaubert
Priority:	P3
Version:	2.5-HEAD
Target Milestone:	---
Hardware:	Sun
OS:	Solaris

Description Klaubert 2010-05-12 09:54:13 UTC

With the new variable introduced in 2.3 (trunk) SSL_SESSION_RESUMED, a basic point is missing: when a SSL_SESSION_ID is really new or is renegotiated, like in 

Prior SSL_SESSION_ID | Current SSL_SESSION_ID  | Status
  -                  | AAAAAAAAAAAA            | Initial
AAAAAAAAAAAA         | BBBBBBBBBBBB            | Renegotiated
BBBBBBBBBBBB         | CCCCCCCCCCCC            | Renegotiated
CCCCCCCCCCCC         | DDDDDDDDDDDD            | Renegotiated

Achieve can be possible, once that the client send this information on SSL Client Hello, on Initial it don't send a SSL_SESSION_ID (Session ID lenght = 0), but on subsequent connections it send in Client Hello with the SessionID, until a renegotiation be force by the server (once that still valid for the client, but not for the server, because SSLSessionCacheTimeout), and this way creating a new SSL_SESSION_ID.

This can be very helpful in differentiating the first SSL_SESSION_ID from the new ones renegotiated, for a better logout control (to don't allow a user reuse a token/smartcard plugged on computer to gain access in the application after the user click on logout).

Comment 1 Dennis Clarke 2014-03-26 22:05:05 UTC

I can confirm that with the latest rev of Apache and OpenSSL that the 
SSL_SESSION_ID data is blank on the initial connection where SSL_SESSION_RESUMED
is equal to "Initial".

Thus : 

SERVER_SOFTWARE: Apache/2.4.9 (Unix) PHP/5.4.26 OpenSSL/1.0.1e

SSL_SESSION_ID:
SSL_SESSION_RESUMED: Initial
SSL_VERSION_INTERFACE: mod_ssl/2.4.4
SSL_VERSION_LIBRARY: OpenSSL/1.0.1e

This seems blatently wrong that the SESSION ID is blank given that section 7 ( page 26 ) of RFC 5246 states : 

 The Handshake Protocol is responsible for negotiating a session,
   which consists of the following items:

   session identifier
      An arbitrary byte sequence chosen by the server to identify an
      active or resumable session state.


One would think that with TLS1.2 that the handshake process is complete in 
order to receive a page of data in a modern browser via https and therefore
the SSL_SESSION_ID is not blank.

Other reasonable SSL environment variables are complete and look correct 
thus : 

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: TLSv1.2
SSL_SECURE_RENEG: true
SSL_SERVER_A_KEY: rsaEncryption
SSL_SERVER_A_SIG: sha1WithRSAEncryption
SSL_SERVER_I_DN: CN=VeriSign Class 3 Extended Validation SSL CA,OU=Terms of use at https://www.verisign.com/rpa (c)06,OU=VeriSign Trust Network,O=VeriSign\, Inc.,C=US
SSL_SERVER_I_DN_C: US
SSL_SERVER_I_DN_CN: VeriSign Class 3 Extended Validation SSL CA
SSL_SERVER_I_DN_O: VeriSign, Inc.
SSL_SERVER_I_DN_OU: VeriSign Trust Network

etc etc. 

Seems wrong that SSL_SESSION_ID is blank.

Dennis