19 Oct 2014 POODLE, The Latest SSL Vulnerability
Recently, a vulnerability in the design of SSLv3 was discovered by Google team. POODLE or “Padding Oracle On Downgraded Legacy Encryption” allows a man-in-the-middle attacker to trigger the downgrade to SSLv3, decrypting the HTTP secure connection and extracting important information.
The issue was disclosed on Tuesday October 14th 2014. The admins team has taken immediate action and SSLv3 was disabled on all the servers under Spirula Systems management.
SSL is an encryption protocol that operates on the transport layer, and is used to secure connections in client-server architectures. SSL and it’s successor TLS protocols are used to encrypt data through a handshake process that ensures data or message confidentiality throughout that connection.
Bodo Möller, Thai Duong and Krzysztof Kotowicz from Google team discovered the POODLE bite, a vulnerability in the design of SSL version 3.0 which allows an attacker to interrupt the handshake process between the client and the server causing the client to retry the handshake process over an older version of the protocol.
For example, if the client supports TLSv1.0 and the server supports TLSv1.2 then, if the connection between them failed, when the client retries to establish the connection again, the encryption protocol will fallback to the older version; SSLv3 in this case. So, a man-in-the-middle attack within the client network or the server network will allow the attacker to decrypt this session and extract transmitted information.
A detailed report about this vulnerability was published on Tuesday October 14th 2014. The vulnerability exists if both the server and the client accept SSLv3.
Solution: Disable SSLv3
The recent discovery by Google engineers points out that SSLv3 should not be used any more and should be replaced by TLS as a successor. Affected services include any service that supports SSLv3. For example: Nginx, Apache, SMTP, OpenVPN, IMAP..etc.
Our team was quick to take action as soon as the issue was publicly disclosed:
- We developed a small tool to check all servers under our management and identify vulnerable servers/services.
- On each server/service, we made sure that SSLv3 is disabled.
- A second check we performed to make sure that all vulnerable servers/services were checked.
- Our internal deployment scripts and Ansible playbooks were updated to avoid any regression to a state where SSLv3 is enabled.
You should also disable SSLv3 from your client applications. This is critical to ensure that your data is protected from this attack when you access services that have not been updated to disable SSLv3 yet.
If you have any additional questions or concerns about the vulnerability, please feel free to contact us.