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....@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 >> >
