Summary
-------

Add support for *Extended Master Secret* TLS extension in JSSE provider on both client and server sides, according to [RFC 7627 (*Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension*)](https://tools.ietf.org/html/rfc7627). This extension modifies the scheme through which the TLS session master key is derived, preventing attacks such as the [Triple Handshake Attack](https://www.mitls.org/pages/attacks/3SHAKE).

Problem
-------

JSSE has lack of support for *Extended Master Secret* TLS extension on both client and server sides. Even though many TLS implementations still negotiate sessions without *Extended Master Secret* for backward compatibility reasons, this is discouraged and may pose a security risk. Risk is related to the fact that the master key is not cryptographically bound to the session, allowing an active attacker to set up the same master key on a different session and bypass authentication schemes that rely on it. 

JSSE is currently behind other TLS implementations in regard to *Extended Master Secret* support:

 * [OpenSSL](https://www.openssl.org/docs/man1.1.0/ssl/SSL_get_extms_support.html)
 * [NSS](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.21_release_notes)
 * [GnuTls](https://lists.gnupg.org/pipermail/gnutls-devel/2015-April/007535.html)

Solution
--------

When negotiating a TLS session as a client, send the *Extended Master Secret* extension as part of the Client Hello message. When negotiating a TLS session as a server, identify the use of *Extended Master Secret* extension in the Client Hello Message. If *Extended Master Secret* extension is in use, apply the algorithm specified in [RFC 7627](https://tools.ietf.org/html/rfc7627) to derive the session master key on both client and server sides. **Note:** The proposed solution does not change the current API, as it's JSSE internal.

Specification
-------------

Proposed webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8148421/webrev.02/

CSR is being asked for because the proposed change introduces modifications in the default behaviour for both JSSE TLS clients and servers. Clients will be sending the Extended Master Secret TLS extension in their Client Hello message by default (instead of not sending it). Servers will be handling received Extended Master Secret TLS extensions (instead of ignoring it). Both Clients and Servers will be using a new scheme for TLS master key derivation if the counterpart supports the aforementioned extension. This modifies not only the way in which JSSE Clients and Servers interact with each other but also their interaction with other TLS implementations from 3rd parties (i.e.: OpenSSL, NSS, GnuTls, etc.).

**Detailed changes:**

 * ClientHandshaker class
   * When negotiating a new TLS session (full handshake), the client sends the *Extended Master Secret* extension as part of the *Client Hello* message.
   * When resuming a TLS session (abbreviated handshake), the client sends the *Extended Master Secret* extension as part of the *Client Hello* message only if it was in use for the original session.
   * When processing a *Server Hello* message, the client identifies if the server supports the *Extended Master Secret* extension.
     * Client check for error conditions: the use of *Extended Master Secret* cannot differ from the original session when resuming a session.

 * ServerHandshaker class
   * When processing a *Client Hello* message, the server identifies if the client supports the *Extended Master Secret* extension.
     * Server check for error conditions: the use of *Extended Master Secret* cannot differ from the original session when resuming a session.
   * If *Extended Master Secret* is in use, the server sends the extension as part of the *Server Hello* message to notify the client.

 * SSLSessionImpl class
   * An instance variable was added to indicate if *Extended Master Secret* is enabled in the session.

 * Handshaker
   * Stores the session hash (handshake final hash) in a *TlsMasterSecretParameterSpec* instance for master key calculation when *Extended Master Secret* is in use.

 * TlsMasterSecretParameterSpec
   * The session hash (handshake final hash) can be stored here for master key calculation when *Extended Master Secret* is in use.

 * TlsMasterSecretGenerator
   * If *Extended Master Secret* is in use, derives the master key as specified in [RFC 7627](https://tools.ietf.org/html/rfc7627), using the session hash (handshake final hash) stored in the *TlsMasterSecretParameterSpec* instance.

**Note:**
As part of the change a property for disabling this new feature is also being considered. It would completely disable the use of this TLS extension. The property would apply to both Clients and Servers. The suggested property name would be `jsse.useExtendedMasterSecret` with a default value of `true`. Setting for disabling the wire protocol changes would, thus be: `jsse.useExtendedMasterSecret=false`.