Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: [Bug 56324] SSL_SESSION_ID should not be blank even if
 SSL_SESSION_RESUMED is "Initial"
Date: Sat, 05 Apr 2014 20:03:21 +0000
Message-ID: <bug-56324-7868-s3lirieUtO@https.issues.apache.org/bugzilla/>
In-Reply-To: <bug-56324-7868@https.issues.apache.org/bugzilla/>
References: <bug-56324-7868@https.issues.apache.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Auto-Submitted: auto-generated
MIME-Version: 1.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=56324

Dennis Clarke <dclarke@blastwave.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4
           Severity|major                       |normal

--- Comment #3 from Dennis Clarke <dclarke@blastwave.org> ---
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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org