Poodle vulnerability

November 6, 2014 at 5:08 am Leave a comment

The Poodle vulnerability affects all Linux and Windows servers. This makes it unique – no other vulnerability has been this widespread.

Before I discuss fixes, I’d like to clarify some points:

  • Poodle is not ShellShock – it’s not related (I’ll cover ShellShock in a separate post)
  • Poodle is not a client-side vulnerability (your browser is safe) – it affects servers
  • Poodle won’t steal your credit card details
  • Poodle is not a virus
  • Poodle relies on protocol, not weak ciphers

* Technical bit – Protocol:

When a connection is made between a client (browser) and server (website), both sides must agree on the communication method. The most basic is http. This can be considered as visible to the world.

In 1995, Netscape “created” the SSL protocol (versions 1, 2 and then 3). This encrypts the messages once the communication method has been agreed between client and server. This can be considered as a step in the right direction.

In 1999, TLS was born (versions 1.0, 1.1, and 1.2 now exist). This is encryption at a “higher level”. The transport layer is encrypted rather than the socket layer. In layman’s terms, far more secure.

* More technical stuff:

– Ciphers – this is how the client and server agree to shake hands. I may want to acknowledge you with a firm handshake, and you want to high-five me. If we can’t agree on a handshake, we will not communicate.

As such, the server will tell the client what handshakes are acceptable. If the client disagrees with all of those, the connection will stop

– Fast-forward:

Truth is, many ciphers are weak. A thousand computers could work out your handshake if they focused on your handshake for 10 years. That’s called weak.

Other ciphers are strong. This would take a million computers a million years instead.

– But:

The *protocol* is the issue – SSLv3 is inherently flawed and it’s quite easy to bring down a server which accepts that protocol. It allows the client to run a remote program on a server. Because of the handshake agreement, it’s very easy for a client to only accept one handshake – one within the SSLv3 protocol. That is why it is critical that servers disable this.

And this happens to be almost every server on the internet. As such, the world is busy trying to disable that protocol, switch to TLS and not cause issues along the way.

– Fix (Tomcat):

I’ve been dealing with many servers over the last few weeks which needed patching. If you’re running Tomcat, then here’s how to patch your server (conf/server.xml – inside the Connector declaration):

— Tomcat 6:

sslProtocols = "TLSv1,TLSv1.1,TLSv1.2"

Note: That's undocumented but works for all Tomcat 6 instances I've tested it on

— Tomcat 7:

sslEnabledProtocols = "TLSv1,TLSv1.1,TLSv1.2"

Now you’ve disabled sslv3 your server is safe. While you’re at it, I’d add these which are what I consider “safe” ciphers:

ciphers=”TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_RC4_128_MD5,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_RC4_128_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA”

 

Hope that helps!

Peter

 

Advertisements

Entry filed under: Development. Tags: , , , .

Spring – Quartz scheduler setup

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: