Code Review Request: JDK-8148421 (Extended Master Secret TLS extension)

Tue Oct 17 18:45:47 UTC 2017

Hi Xuelei,

Webrev 03
--------------------

 *
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8148421/webrev.03/
(browse online)
 *
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8148421/webrev.03/8148421.webrev.03.zip
(download)

Differences with previous webrev 02:

 * jsse.useExtendedMasterSecret system property was added to completely
disable the feature on both client and server sides.

 * Bug fix: if the server does not support TLS 1.0+ version (thus, a
previous TLS version was negotiated), the Extended Master Secret extension
is not used even if the client sends the extension in its ClientHello
message.

 * Bug fix: When TLS 1.0 or 1.1 are used, the session hash is calculated
concatenating a MD5 with a SHA1 hash.

 * 2 regression testcases were fixed.

 * knownExtensions array (in ExtensionType class) has now an initial length
of 16.

Feature documentation (for JSSE Reference Guides [1])
----------------------------------------------------

## Extended Master Secret Extension

The Extended Master Secret Extension is a feature that replaces the
algorithm used to derive the *master secret* for a TLS session. The new
algorithm provides a security enhancement to mitigate attacks such as the
[Triple Handshake Attack](https://www.mitls.org/pages/attacks/3SHAKE). The
Extension is defined by [RFC 7627](https://tools.ietf.org/html/rfc7627)
(*Transport Layer Security (TLS) Session Hash and Extended Master Secret
Extension*) and applies to TLS 1.0+.

Clients and servers need to agree on the usage of this extension during the
TLS full handshake, or the previous algorithm is used as a fallback. JSSE
supports and enables the Extension by default on both client and server
sides. However, for compatibility reasons, disabling is possible by setting
*jsse.useExtendedMasterSecret* system property to *false* (i.e. through the
*-Djsse.useExtendedMasterSecret="false"* command-line argument).

### How is the new algorithm different than the previous?

The original algorithm uses a PRF function to derive the *master secret*
from the following inputs: *pre-master secret* (result of a previous key
exchange); "master secret" string; and, client and server random values.

The new algorithm replaces the client and server random values with a hash
of the previously exchanged handshake messages. As a result, the session
*hash* contains information from certificates, key exchange parameters and
other handshake-specific values; in addition to the client and server
random numbers. Through binding *master secret* to the connection, an
active man-in-the-middle attacker cannot force the generation of an
identical value in a parallel connection. Thus, values that depend on the
*master secret* for authentication (such as the TLS "tls-unique" binding
value) can be trusted.

### Sessions resumption

The *master secret* for a TLS session is established during a full
handshake. When a session is resumed, the original *master secret* is used
without any further negotiations. However, for checking purposes, Extended
Master Secret Extension messages are exchanged during the abreviated
handshake to indicate that the Extension was used when the original *master
secret* was derived. JSSE raises an error if an incongruence is found here.

Release note: Extended Master Secret Extension support was added to JSSE
for both client and server sides
---------------------------------------------------------------------------------------------------------

The Extended Master Secret Extension for TLS 1.0+ is now supported on JSSE
for both client and server sides. By modifying the algorithm to derive the
session *master secret* (during a full handshake) and binding it to
connection-specific values, attacks such as the [Triple Handshake Attack](
https://www.mitls.org/pages/attacks/3SHAKE) are mitigated.

The extension, enabled by default, can be turned off by setting
*jsse.useExtendedMasterSecret* system property to *false*.

See further information about the Extension in [RFC 7627](
https://tools.ietf.org/html/rfc7627) (*Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension*).

Testing
-----------

I've run jtreg regression tests for the following categories:

 * javax/net/ssl
 * sun/security/ssl

Results:

 * Found 2 bugs running regression tests (both fixed in webrev 03).

 * Found 2 tests broken because of this patch (both fixed in webrev 03).

 * The number of tests that pass is equal with the patch than without, so I
assume that no regression was introduced given the current coverage.

Kind regards,
Martin.-

--
[1] -
http://docs.oracle.com/javase/9/security/java-secure-socket-extension-jsse-reference-guide.htm#JSSEC-GUID-93DEEE16-0B70-40E5-BBE7-55C3FD432345

On Sat, Aug 26, 2017 at 7:49 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:

> Hi Martin,
>
> Sorry for the delay.
>
> I like this no-API-change design.
>
> There may be some interoperbility/compatibility issues because of
> implementation issues of the Extended Master Secret Extension.  Maybe, we
> want an approach to turn off the extension if there is a concern.  It could
> be a system property (for example, jsse.useExtendedMasterSecret="false").
>
> Would you mind file a Compatibility & Specification Review (CSR) request
> for this feature proposal?  For more information, see the CSR wiki at
> OpenJDK:
>    https://wiki.openjdk.java.net/display/csr/Main
>
> I may have some comments about the implementation if the CSR request get
> approved.
>
> Thanks & Regards,
> Xuelei
>
> On 8/4/2017 6:18 AM, Martin Balao wrote:
>
>> Hi,
>>
>> This is my proposal for JDK-8148421 (Support Transport Layer Security
>> (TLS) Session Hash and Extended Master Secret Extension) [1]:
>>
>>   * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-81
>> 48421/webrev.01/ <http://cr.openjdk.java.net/~s
>> gehwolf/webrevs/mbalaoal/JDK-8148421/webrev.01/>(browse online)
>>   * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-81
>> 48421/webrev.01/8148421.webrev.01.zip (download)
>>
>> Notes:
>>
>>   * There is no PKCS#11 support for Extended Master Secret key derivation
>> at this moment. NSS supports it through a vendor-specific type definition
>> (CKM_NSS_TLS_EXTENDED_MASTER_KEY_DERIVE and
>> CKM_NSS_TLS_EXTENDED_MASTER_KEY_DERIVE_DH in pkcs11n.h file). Thus,
>> P11TlsMasterSecretGenerator uses the legacy Master Key Derivation method
>> only.
>>
>> Thanks in advanced,
>> Martin.-
>>
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8148421
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20171017/80ce1b09/attachment.htm>