IT: SSL 3.0 "Poodle" Vulnerability

My new gig is keeping me pretty busy.  Here's a bit I wrote on the Poodle SSL vulnerability today.

What is the vulnerability?
SSL 3.0’s block cipher encryption is vulnerable to a padding attack.  With this technique an attacker with access to the network path between client and server can decode the contents of an encrypted message by forcing it to be retransmitted many times.

To make this work, at a minimum, the attacker must be able to intercept and modify the network traffic sent by the client to the remote server.  (Examples of this include unencrypted wi-fi or access to the physical network between server and client.)  Additionally, this attack requires very large numbers of requests (hundreds to tens of thousands) to be sent to the remote server.  As such, the attack is really only feasible if the attacker also has the ability to run malicious code (i.e. JavaScript) on the client.

How does it work?
First, the attacker has to get the user to run their malicious code.  This can be accomplished by a man-in-the-middle attack against an unencrypted site.
Next, the code makes a connection to a secure site whose request they wish to decode.
Then the attacker must trick the client into using SSL 3.0 to talk to the remote server.  This is accomplished by interrupting or corrupting requests for a TLS connection.
Once the SSL connection is opened, the attacker changes the SSL request by changing a single byte of the stream, their “guess”, and adding additional padding to the SSL stream they want to decode.
-          If the attacker has guessed the SSL-encrypted byte improperly, the SSL connection will fail and disconnect.
-          If the attacker has guessed that byte properly, the SSL connection succeeds.
This pattern repeats until the SSL request has been decoded.  Each “Guessed” byte is a random value between 0 and 255, so decoding a 64 character request can take up to 16,000 attempts to complete, depending on the luck of the attacker.
Finally the malicious code will report back the decoded request to the attacker. [1]

What Protocols are vulnerable?
SSL 3.0

Is TLS 1.0 vulnerable?
With SSL 3.0 disabled, no.  TLS 1.0 has a built-in fail-back to SSL 3.0 if TLS negotiation fails.  An attacker can only leverage this failback if both TLS 1.0 AND SSL 3.0 are enabled.  This risk is eliminated when SSL 3.0 is disabled.

How acute is this Vulnerability?
Microsoft’s position is that there are no secure ciphers remaining in SSL 3.0, and it should be disabled.[3]
SANS’ position, from the CVE summary, is slightly more nuanced.[2]
“What should you do: Disable SSLv3. There is no patch for this. SSLv3 has reached the end of its useful life and should be retired.

This isn't a "patch now". Give it some time, test it carefully, but get going with it. The other problem is that this is a client and a server issue. You need to disable SSLv3 on either. Start with the servers for highest impact, but then see what you can do about clients.”

What is the impact of disabling SSL 3.0?
Clients that do not support TLS 1.0 or above will fail to connect.  This specifically includes Internet Explorer 6.0.  I call attention to this browser specifically as it still has a non-trivial installed base, comprising 1.6% of all internet traffic in October 2014.[5]

How do I disable SSL 3.0 on Clients?
-          SSL 3.0 can be disabled in Internet Explorer using a check box on the advanced tab of the Internet Options Panel.
-          Other OS Components
o   Web Browsers are the most likely target for attack, but are not the only components that use SSL.
o   The Windows operating system provides a library called Schannel to handle client encryption.
o   The SSL 3.0 Schannel client can be disabled using the registry key [3]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client] "Enabled"=dword:00000000

o   If SSL 3.0 schannel is disabled, this overrides the checkbox in Internet Explorer.
-          Non-OS Components
o   Not all applications use Microsoft’s schannel library.  These applications are not mitigated by the registry key above.
o   Mitigating these is application specific.
§  As an example, Mozilla has published the SSL Version Control Add-On to disable SSL 3.0 in their Firefox browser.

How can I prevent this attack against my Webservers?
i.e. How can I protect users from having their information stolen in this manner?
-          Disable SSL 3.0 in your web servers.
-          This can be completed with the registry key [3]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server] "Enabled"=dword:00000000

What is the risk of disabling SSL 3.0?
-          A small number of web servers or web clients may not have TLS 1.0 enabled.
o   Most notably, Internet Explorer 6.0 did not have TLS 1.0 enabled by default.
-          TLS 1.0 is 15 years old.[4]  It has been enabled by default since Windows Server 2003, and in all versions of Internet Explorer 7 or greater.
o   The risk of disabling SSL 3.0 on clients is vanishingly small.
o   The risk of disabling SSL 3.0 on servers is small.
o   Neither change is completely without risk.