LogJam’s discovery(May 2015) came as a result of follow-up investigations into the FREAK (Factoring attack on RSA-EXPORT Keys) flaw, which was revealed in March.
Logjam - vulnerabilities in Diffie-Hellman key exchange affect browsers and servers using TLS. Before we delve deep into the vulnerability, lets have a look at how Diffie-Hellman key exchange works.
Let's say Alice wants to send a secured message to Bob over an unsecured channel. Since the channel is not secured, the message has to be secured itself, to avoid by being seen by outsiders other than Bob.
Diffie-Hellman key exchange provides a way to exchange keys between two parties over an unsecured channel, so the established key can be used to encrypt the messages later. First both Alice and Bob have to agree on a prime modulus (p) and a generator (g) - publicly. These two numbers need not be protected. Then Alice selects a private random number (a) and calculates g^a mod p , which is also known as Alice's public secret - let's say its A.
In the same manner Bob also picks his own private random number (b) and calculates g^b mod p, which is also known as Bob's public secret - let's say its B.
Now, both will exchange their public secrets over the unsecured channel, that is A and B - or g^a mod p and g^b mod p.
Once Bob, receives A from Alice - he will calculate the common secret (s) in the following manner, A^b mod p and in the same way Alice will also calculate the common secret (s) - B^a mod p.
Bob's common secret: A^b mod p -> (g^a mod p ) ^b mod p -> g^(ab) mod p
Alice's common secret: B^a mod p -> (g^b mod p ) ^a mod p -> g^(ba) mod p
Here comes the beauty of the modular arithmetic. The common secret derived at the Bob's is the same which is derived at the Alice's end. The bottom line is - to derive the common secret either you should know p,g, a and B or p,g,b and A. Anyone intercepting the messages transferred over the wire would only know p,g,A and B. So - they are not in a position to derive the common secret.
I would not go through here, explaining each and every message flow in the above diagram - but would only focus on the messages Server Key Exchange and the Client Key Exchange.
The Server Key Exchange message will be sent immediately after the Server Certificate message (or the Server Hello message, if this is an anonymous negotiation). The Server Key Exchange message is sent by the server only when the Server Certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret. This is true for the following key exchange methods:
In the DH key exchange, the cryptographic strength relies on the prime number (p) you pick, not in fact on the random numbers picked either by the server side or by the client side. It is recommended to have the prime number to be 2048 bits. Following table shows how hard it is to break DH key exchange based on the length of the prime number.
Fortunately no one is using 512 bits long prime numbers - but, except in EXPORT cryptography. During the crypto wars happened in 90's it was decided to make ciphers weaker when its being used to communicate outside USA and these weaker ciphers are known as EXPORT ciphers. This law was out-turned later, but unfortunately TLS was designed before that and it has the support for EXPORT ciphers. According to the EXPORT ciphers the DH prime numbers cannot be longer than 512 bits. If the client wants to use DH EXPORT ciphers with 512 bit prime number, then during the Client Hello message of the TLS handshake its has to send DH_EXPORT cipher suite.
None of the legitimate clients do not want to use a weak prime number - so will never suggest the server to use DH_EXPORT - but still - most servers do support DH_EXPORT cipher suite. That means, if someone in the middle manages to intercept the Client Hello initiated by the client and change the requested cipher suite to DH_EXPORT - then still the server will support it and key exchange will happen using a weaker prime number. These types of attacks are known as TLS downgrade attacks - since the original cipher suite used by the client was downgraded by changing the Client Hello message.
But, wouldn't this change ultimately detected by the TLS protocol itself. TLS has the provision to detect if any of the messages in the handshake got modified in the middle by validating the hash of all the messages sent and received by both the parties - at both the ends. This happens at the end of the handshake. Client derives the hash of the messages sent and received by it and sends the hash to the server - and server will validate the hash against the hash of all the messages sent and received by it. Then once again server derives the hash of the messages sent and received by it and sends the hash to the client - and client will validate the hash against the hash of all the messages sent and received by it. Since by this time the common secret is established - the hash is encrypted by the derived secret key - which, at this point is known to the attacker. So, the attacker can create a hash that is accepted by both the parties - encrypts it and sends it over to both the client and the server.
To protect from this attack, the server should not respond to any of the weaker ciphers, in this case DHE_EXPORT.
Now to verify the configurations are all set correctly, you can run TestSSLServer.jar which can be downloaded from here.
$ java -jar TestSSLServer.jar localhost 9443
In the output you get by running the above command, there is a section called “Supported cipher suites”. If all configurations are done correctly, it should not contain any export ciphers.
With Firefox v39.0 onwards it does not allow to access web sites which support DHE with keys less than 1023 bits (not just DHE_EXPORT). The key length of 768 bits and 1024 bits are assumed to be attackable depending on the computing resources the attacker has. Java 7 uses keys with length 768 bits even for non export DHE ciphers. This will probably not be fixed until Java 8, so we cannot use these ciphers. Its recommended not just remove DHE_EXPORT cipher suites - but also all the DHE cipher suites. In that case use following for the 'ciphers' configuration.
Logjam - vulnerabilities in Diffie-Hellman key exchange affect browsers and servers using TLS. Before we delve deep into the vulnerability, lets have a look at how Diffie-Hellman key exchange works.
How does Diffie-Hellman key exchange work?
Let's say Alice wants to send a secured message to Bob over an unsecured channel. Since the channel is not secured, the message has to be secured itself, to avoid by being seen by outsiders other than Bob.
Diffie-Hellman key exchange provides a way to exchange keys between two parties over an unsecured channel, so the established key can be used to encrypt the messages later. First both Alice and Bob have to agree on a prime modulus (p) and a generator (g) - publicly. These two numbers need not be protected. Then Alice selects a private random number (a) and calculates g^a mod p , which is also known as Alice's public secret - let's say its A.
In the same manner Bob also picks his own private random number (b) and calculates g^b mod p, which is also known as Bob's public secret - let's say its B.
Now, both will exchange their public secrets over the unsecured channel, that is A and B - or g^a mod p and g^b mod p.
Once Bob, receives A from Alice - he will calculate the common secret (s) in the following manner, A^b mod p and in the same way Alice will also calculate the common secret (s) - B^a mod p.
Bob's common secret: A^b mod p -> (g^a mod p ) ^b mod p -> g^(ab) mod p
Alice's common secret: B^a mod p -> (g^b mod p ) ^a mod p -> g^(ba) mod p
Here comes the beauty of the modular arithmetic. The common secret derived at the Bob's is the same which is derived at the Alice's end. The bottom line is - to derive the common secret either you should know p,g, a and B or p,g,b and A. Anyone intercepting the messages transferred over the wire would only know p,g,A and B. So - they are not in a position to derive the common secret.
How does Diffie-Hellman key exchange relate to TLS?
Let's have look at how TLS works.
I would not go through here, explaining each and every message flow in the above diagram - but would only focus on the messages Server Key Exchange and the Client Key Exchange.
The Server Key Exchange message will be sent immediately after the Server Certificate message (or the Server Hello message, if this is an anonymous negotiation). The Server Key Exchange message is sent by the server only when the Server Certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret. This is true for the following key exchange methods:
- DHE_DSS
- DHE_RSA
- DH_anon
- RSA
- DH_DSS
- DH_RSA
How would someone exploit this and what is in fact LogJam vulnerability?
On 20th May, 2015, a group from INRIA, Microsoft Research, Johns Hopkins, the University of Michigan, and the University of Pennsylvania published a deep analysis of the Diffie-Hellman algorithm as used in TLS and other protocols. This analysis included a novel downgrade attack against the TLS protocol itself called Logjam, which exploits EXPORT cryptography.In the DH key exchange, the cryptographic strength relies on the prime number (p) you pick, not in fact on the random numbers picked either by the server side or by the client side. It is recommended to have the prime number to be 2048 bits. Following table shows how hard it is to break DH key exchange based on the length of the prime number.
Fortunately no one is using 512 bits long prime numbers - but, except in EXPORT cryptography. During the crypto wars happened in 90's it was decided to make ciphers weaker when its being used to communicate outside USA and these weaker ciphers are known as EXPORT ciphers. This law was out-turned later, but unfortunately TLS was designed before that and it has the support for EXPORT ciphers. According to the EXPORT ciphers the DH prime numbers cannot be longer than 512 bits. If the client wants to use DH EXPORT ciphers with 512 bit prime number, then during the Client Hello message of the TLS handshake its has to send DH_EXPORT cipher suite.
None of the legitimate clients do not want to use a weak prime number - so will never suggest the server to use DH_EXPORT - but still - most servers do support DH_EXPORT cipher suite. That means, if someone in the middle manages to intercept the Client Hello initiated by the client and change the requested cipher suite to DH_EXPORT - then still the server will support it and key exchange will happen using a weaker prime number. These types of attacks are known as TLS downgrade attacks - since the original cipher suite used by the client was downgraded by changing the Client Hello message.
But, wouldn't this change ultimately detected by the TLS protocol itself. TLS has the provision to detect if any of the messages in the handshake got modified in the middle by validating the hash of all the messages sent and received by both the parties - at both the ends. This happens at the end of the handshake. Client derives the hash of the messages sent and received by it and sends the hash to the server - and server will validate the hash against the hash of all the messages sent and received by it. Then once again server derives the hash of the messages sent and received by it and sends the hash to the client - and client will validate the hash against the hash of all the messages sent and received by it. Since by this time the common secret is established - the hash is encrypted by the derived secret key - which, at this point is known to the attacker. So, the attacker can create a hash that is accepted by both the parties - encrypts it and sends it over to both the client and the server.
To protect from this attack, the server should not respond to any of the weaker ciphers, in this case DHE_EXPORT.
How to remove the support for weaker ciphers from WSO2 Carbon 4.0.0+ based products ?
The cipher set which is used in a Carbon server is defined by the embedded Tomcat server (assuming JDK 1.7.*)- Open
CARBON_HOME/repository/conf/tomcat/catalina-server.xml file. Find the Connector configuration corresponding to TLS. Usually there are only two connector configurations and connector corresponding to TLS have connector property, SSLEnabled=”true”. Add new property “ciphers” inside the TLS connector configurations with the value as follows. If you are using tomcat version 7.0.34 : ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_DHE_RSA_WITH_DES_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_DES_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA" If you are using tomcat version 7.0.59: ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_DHE_RSA_WITH_DES_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA" Restart the server.
- If you are using tomcat version 7.0.34 :
- ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_DES_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA"
- If you are using tomcat version 7.0.59:
- ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA"
How to remove the support for weaker ciphers from WSO2 pre-Carbon 4.0.0 based products ?
- Open CARBON_HOME/repository/conf/mgt-transports.xml
- Find the transport configuration corresponding to TLS - usually this is having the port as 9443 and name as https.
- Add the following new element.
- <parameter name="ciphers">SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_DES_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA</parameter>