Saturday, October 18, 2014

POODLE Attack and Disabling SSL V3 in WSO2 Carbon 4.2.0 Based Products

Early this week Google researchers announced that they have found a bug in the SSL 3.0 protocol. The exploit could be used to intercept critical data that’s supposed to be encrypted between clients and servers.

The exploit first allows attackers to initiate a “downgrade dance” that tells the client that the server doesn’t support the more secure TLS (Transport Layer Security) protocol and forces it to connect via SSL 3.0.

From there a man-in-the-middle attack can decrypt secure HTTP cookies.

POODLE

Google calls this the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack.

This means, even both your server and the client support TLS, still due to the downgrade attack, both the parties can be forced to use SSL 3.0. If any one of the party disables its support for SSL 3.0 - that will help to mitigate the attack.

Both Chrome and Firefox already announced that they are going to disable the SSL 3.0 support by default. Firefox 34, with SSL 3.0 disabled,  will be released on 25th November. If you want to disable SSL 3.0 on firefox now, you can use the plugin SSL Version Control.

Chrome has already issued a patch to disable SSL 3.0.

Disable SSL V3 on WSO2 Carbon 4.2.0

Following explains how to disable SSL 3.0 support on WSO2 Carbon 4.2.0 based servers
  1. Open [product_home]/repository/conf/catalina-server.xml
  2. Find the Connector configuration corresponding to TLS - usually this is having the port as 9443 and sslProtocol as TLS.
  3. If you are using JDK 1.6 then remove the attribute sslProtocol="TLS" from the above configuration and replace it with:  sslEnabledProtocols="TLSv1"
  4.  If you are using JDK 1.7 then remove the attribute sslProtocol="TLS" from the above configuration and replace it with:  sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
If you have enabled pass-thru transport in any WSO2 product (ESB, API Manager) - you also need to do the following configuration change.
  1. Open [product_home]/repository/conf/axis2/axis2.xml
  2. Find the transportReceiver configuration element for org.apache.synapse.transport.passthru.PassThroughHttpSSLListener
  3. If you are using JDK 1.6 - add the following parameter under transportReceiver.
  4.  <parameter name="HttpsProtocols">TLSv1</parameter> 
  5. If you are using JDK 1.7 - add the following parameter under transportReceiver.
  6.  <parameter name="HttpsProtocols">TLSv1,TLSv1.1,TLSv1.2</parameter> 
Following explains how to validate the fix. You can download TestSSLServer.jar from here.

$ java -jar TestSSLServer.jar localhost 9443 

To test the pass-thru transport use the following command with the corresponding port.

$ java -jar TestSSLServer.jar localhost 8243 

Output before the fix

Supported versions: SSLv3 TLSv1.0
Deflate compression: no
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
  SSLv3
     RSA_EXPORT_WITH_RC4_40_MD5
     RSA_WITH_RC4_128_MD5
     RSA_WITH_RC4_128_SHA
     RSA_EXPORT_WITH_DES40_CBC_SHA
     RSA_WITH_DES_CBC_SHA
     RSA_WITH_3DES_EDE_CBC_SHA
     DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
     DHE_RSA_WITH_DES_CBC_SHA
     DHE_RSA_WITH_3DES_EDE_CBC_SHA
     RSA_WITH_AES_128_CBC_SHA
     DHE_RSA_WITH_AES_128_CBC_SHA
     RSA_WITH_AES_256_CBC_SHA
     DHE_RSA_WITH_AES_256_CBC_SHA
  (TLSv1.0: idem)


Output after the fix

Supported versions: TLSv1.0
Deflate compression: no
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
  TLSv1.0
     RSA_EXPORT_WITH_RC4_40_MD5
     RSA_WITH_RC4_128_MD5
     RSA_WITH_RC4_128_SHA
     RSA_EXPORT_WITH_DES40_CBC_SHA
     RSA_WITH_DES_CBC_SHA
     RSA_WITH_3DES_EDE_CBC_SHA
     DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
     DHE_RSA_WITH_DES_CBC_SHA
     DHE_RSA_WITH_3DES_EDE_CBC_SHA
     RSA_WITH_AES_128_CBC_SHA
     DHE_RSA_WITH_AES_128_CBC_SHA
     RSA_WITH_AES_256_CBC_SHA
     DHE_RSA_WITH_AES_256_CBC_SHA

Friday, October 17, 2014

POODLE Attack and Disabling SSL V3 in Apache Tomcat

Early this week Google researchers announced that they have found a bug in the SSL 3.0 protocol. The exploit could be used to intercept critical data that’s supposed to be encrypted between clients and servers.

The exploit first allows attackers to initiate a “downgrade dance” that tells the client that the server doesn’t support the more secure TLS (Transport Layer Security) protocol and forces it to connect via SSL 3.0.

From there a man-in-the-middle attack can decrypt secure HTTP cookies.

POODLE

Google calls this the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack.

This means, even both your server and the client support TLS, still due to the downgrade attack, both the parties can be forced to use SSL 3.0. If any one of the party disables its support for SSL 3.0 - that will help to mitigate the attack.

Both Chrome and Firefox already announced that they are going to disable the SSL 3.0 support by default. Firefox 34, with SSL 3.0 disabled,  will be released on 25th November. If you want to disable SSL 3.0 on firefox now, you can use the plugin SSL Version Control.

Chrome has already issued a patch to disable SSL 3.0.

Disable SSL V3 on Apache Tomcat

Following explains how to disable SSL 3.0 support on Apache Tomcat 7.x.x.
  1. Open [tomcat_home]/conf/server.xml
  2. Find the Connector configuration corresponding to TLS - usually this is having the port as 8443 and sslProtocol as TLS.
  3. If you are using JDK 1.6 then remove the attribute sslProtocol="TLS" from the above configuration and replace it with:  sslEnabledProtocols="TLSv1"
  4.  If you are using JDK 1.7 then remove the attribute sslProtocol="TLS" from the above configuration and replace it with:  sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
Following explains how to validate the fix. You can download TestSSLServer.jar from here.

$ java -jar TestSSLServer.jar localhost 8443 

Output before the fix

Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Deflate compression: no
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
  SSLv3
     RSA_WITH_RC4_128_MD5
     RSA_WITH_RC4_128_SHA
     RSA_WITH_3DES_EDE_CBC_SHA
     DHE_RSA_WITH_3DES_EDE_CBC_SHA
     RSA_WITH_AES_128_CBC_SHA
     DHE_RSA_WITH_AES_128_CBC_SHA
     TLS_ECDHE_RSA_WITH_RC4_128_SHA
     TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
     TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  (TLSv1.0: idem)
  (TLSv1.1: idem)
  TLSv1.2
     RSA_WITH_RC4_128_MD5
     RSA_WITH_RC4_128_SHA
     RSA_WITH_3DES_EDE_CBC_SHA
     DHE_RSA_WITH_3DES_EDE_CBC_SHA
     RSA_WITH_AES_128_CBC_SHA
     DHE_RSA_WITH_AES_128_CBC_SHA
     RSA_WITH_AES_128_CBC_SHA256
     DHE_RSA_WITH_AES_128_CBC_SHA256
     TLS_ECDHE_RSA_WITH_RC4_128_SHA
     TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
     TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
     TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Output after the fix

Supported versions: TLSv1.0 TLSv1.1 TLSv1.2
Deflate compression: no
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
  TLSv1.0
     RSA_WITH_RC4_128_MD5
     RSA_WITH_RC4_128_SHA
     RSA_WITH_3DES_EDE_CBC_SHA
     DHE_RSA_WITH_3DES_EDE_CBC_SHA
     RSA_WITH_AES_128_CBC_SHA
     DHE_RSA_WITH_AES_128_CBC_SHA
     TLS_ECDHE_RSA_WITH_RC4_128_SHA
     TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
     TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  (TLSv1.1: idem)
  TLSv1.2
     RSA_WITH_RC4_128_MD5
     RSA_WITH_RC4_128_SHA
     RSA_WITH_3DES_EDE_CBC_SHA
     DHE_RSA_WITH_3DES_EDE_CBC_SHA
     RSA_WITH_AES_128_CBC_SHA
     DHE_RSA_WITH_AES_128_CBC_SHA
     RSA_WITH_AES_128_CBC_SHA256
     DHE_RSA_WITH_AES_128_CBC_SHA256
     TLS_ECDHE_RSA_WITH_RC4_128_SHA
     TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
     TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
     TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Thursday, October 16, 2014

Brief History of TLS

TLS has its roots in SSL. SSL was introduced by Netscape Communications in 1994 to build a secured channel between the Netscape browser and the web server it connects to. This was an important need at that time, just prior to the dot-com bubble. The SSL 1.0 specification was never released to the public, because it was heavily criticized for the weak crypto algorithms that were used. In November 1994, Netscape released the SSL 2.0 specification with many improvements. Most of its design was done by Kipp Hickman, with much less participation from the public community. Even though it had its own vulnerabilities, it earned the trust and respect of the public as a strong protocol. The very first deployment of SSL 2.0 was in Netscape Navigator 1.1.

In January 1996, Ian Goldberg and David Wagner discovered a vulnerability in the random-number-generation logic in SSL 2.0. Mostly due to US export regulations, Netscape had to weaken its encryption scheme to use 40-bit long keys. This limited all possible key combinations to a million million, which were tried by a set of researchers in 30 hours with many spare CPU cycles; they were able to recover the encrypted data.

Because SSL 2.0 was completely under the control of Netscape, Microsoft responded to its weaknesses by developing its own variant of SSL in 1995, called Private Communication Technology (PCT). PCT fixed many security vulnerabilities uncovered in SSL 2.0 and simplified SSL handshaking with fewer round trips required to establish a connection.

SSL 3.0 was released in 1996 by Netscape, and Paul Kocher was a key architect. In fact, Netscape hired Paul Kocher to work with its own Phil Karlton and Allan Freier to build SSL 3.0 from scratch. SSL 3.0 introduced a new specification language as well as a new record type and new data encoding, which made it incompatible with SSL 2.0. It fixed issues in its predecessor, introduced due to MD5 hashing. The new version used a combination of the MD5 and SHA-1 algorithms to build a hybrid hash. SSL 3.0 was the most stable of all. In 1996, Microsoft came up with a new proposal to merge SSL 3.0 and its own SSL variant PCT 2.0 to build a new standard called Secure Transport Layer Protocol (STLP).

Due to the interest shown by different vendors in solving the same problem in different ways, in 1996 the IETF initiated the TLS working group to standardize all vendor-specific implementations. All the major vendors, including Netscape and Microsoft, met under the chairmanship of Bruce Schneier in a series of IETF meetings to decide the future of TLS. TLS 1.0 (RFC 2246) was the result; it was released by the IETF in January 1999. The differences between TLS 1.0 and SSL 3.0 aren’t dramatic, but they’re significant enough that TLS 1.0 and SSL 3.0 don’t interoperate. TLS 1.0 was quite stable and stayed unchanged for seven years, until 2006. In April 2006, RFC 4346 introduced TLS 1.1, which made few major changes to 1.0. Two years later, RFC 5246 introduced TLS 1.2, which is the latest at the time of this writing.

Saturday, October 11, 2014

Its not Aladdin - its Ali Baba :-)

Ali Baba is a character from the folk tale Ali Baba and the Forty Thieves. This story is included in many versions of the One Thousand and One Nights, to which it was added by Antoine Galland in the 18th century. It is one of the most familiar of the "Arabian Nights" tales.

In the story, Ali Baba is a poor woodcutter who discovers the secret of a thieves' den, entered with the pass phrase "open sesame".

Aladdin is also  a Middle Eastern folk tale. It is one of the tales in same book One Thousand and One Nights, and one of the best known, although it was actually added to the collection in the 18th century by Frenchman Antoine Galland

It was Ali Baba - not Aladin who knew the pass phrase  "open sesame".

It look like in the RFC 2617 :HTTP Authentication: Basic and Digest Access Authentication Aladin has stolen Ali Baba's pass phrase :-)
If the user agent wishes to send the userid "Aladdin" and password "open sesame", it would use the following header field:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==