Wednesday, February 14, 2018

TLS session hash and extended master secret extension support - RFC 7627

Added TLS session hash and extended master secret extension support
-new properties: jdk.tls.useExtendedMasterSecret, jdk.tls.allowLegacyResumption
-Browser, automated, interoperability tests, Upgrade and downgrade tests
-short-term solution: server certificate change is restricted if endpoint identification is not enabled
-Session renegotiation - it can happen anytime due to different set if encryption kyes, hash alg used.
-Session resumption - means previous session info is used while communication
-Malicious user once session is compromized can perform DOS attacks. Server requires 10 times more processing power
-Master secret is 48-byte length, Pre-master secret size depends on alg RSA (48-byte)
-pre_master_secret is the value generated by the client using a CSPRNG and some other variables
----------
As described in [TRIPLE-HS], in both the RSA and DHE key exchanges, an active attacker can synchronize two TLS sessions so that they share the same “master_secret”. For an RSA key exchange where the client is unauthenticated, this is achieved as follows. Suppose a client C connects to a server A. C does not realize that A is malicious and that A connects in the background to an honest server S and completes both handshakes. For simplicity, assume that C and S only use RSA ciphersuites.
1. C sends a “ClientHello” to A, and A forwards it to S.
2. S sends a “ServerHello” to A, and A forwards it to C.
3. S sends a “Certificate”, containing its certificate chain, to A. A replaces it with its own certificate chain and sends it to C.
4. S sends a “ServerHelloDone” to A, and A forwards it to C.
5. C sends a “ClientKeyExchange” to A, containing the “pre_master_secret”, encrypted with A’s public key. A decrypts the “pre_master_secret”, re-encrypts it with S’s public key, and sends it on to S.
6. C sends a “Finished” to A. A computes a “Finished” for its connection with S and sends it to S.
7. S sends a “Finished” to A. A computes a “Finished” for its connection with C and sends it to C.
At this point, both connections (between C and A, and between A and S) have new sessions that share the same “pre_master_secret”, “ClientHello.random”, “ServerHello.random”, as well as other session parameters, including the session identifier and, optionally, the session ticket. Hence, the “master_secret” value will be equal for the two sessions and will be associated both at C and S with the same session ID, even though the server identities on the two connections are different. Recall that C only sees A’s certificate and is unaware of A’s connection with S. Moreover, the record keys on the two connections will also be the same.

This attack is possible because Master Secret only depends on ClientHello.random and ServerHello.random, the proposed fix was to include the certificate and other session dependent parameters in the formula to generate the master secret.
We define a session hash after completion of the handshake as follows:

session_hash = Hash(handshake_messages)

The extended master secret that’s extension type 0x0017 signals both the client and server that Master Secret is generated with this formula:
Solution for proxies to work: disable the Extended master secret key extension

Source: https://www.silverf0x00.com/tls-extended-master-secret-breaking-ssl-proxies/
-------------

No comments:

Post a Comment