Update (October 29th, 2014 12:15 pm PT)
See today's v2 release notes and v4 release notes for a subsequent update related to "Poodle".
Update (October 16th, 2014 4:15 pm PT)
The hotfix has been released and you can read the release notes here. The security patches are now available via the Upgrade button in your environment.
Update (October 16th, 2014 3:00 pm PT)
Our engineers are hard at work and are still testing the fix for our non-ELB/classicUI customers. All of our ELB and newUI customers have been patched up. Please let us know if you have any questions. Our current ETA is at or before 17:00 PDT 10/16.
Issue
A vulnerability with OpenSSl has been discovered--affecting Debian, Ubuntu, Gentoo, and other Linux distributions relying on OpenSSL--This vulnerability relies on having SSLv3 available for connections.
Any ssl terminated hosted applications using SSLv3 has the possibility with some browsers to be forced to retry SSL negotiation using older versions (including SSLv3). A complicated scenario exists in which an attacker might use this to gain access to the unencrypted communications; the fix is to disable SSLv3 to prevent this from being possible.
Solution
Engine Yard engineers are actively working through the official patches to have SSL version 3 disabled on all applications.
Once we disable SSLv3, some IE6 users will not be able to use your site.
Further updates will be posted as available. Be sure to subscribe to this Known Issue to receive prompt email notifications.
More Information
-
Google Online Security Blog - http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
-
Openssl Security Advisory - https://www.openssl.org/~bodo/ssl-poodle.pdf
We are here to support you! If you have any questions or concerns, please open a ticket with our Support Team here:https://support.cloud.engineyard.com/tickets/new
Thanks to Ralph & team for your hard work!
I am grateful you guys fixed the ELBs proactively, but environments for which the SSL termination is done at the app master are still vulnerable I believe... What can we do *NOW* to protect ourselves, while you guys finish work on updating the stack?
Such manual steps were given for https://support.cloud.engineyard.com/entries/100990926-CVE-2014-6271-Scope-impact-and-resolution and that helped a lot!
Thank you,
An excellent question, Yves-Eric. Right this moment customers can disable SSLv3 on any public-facing applications to safeguard themselves from this vulnerability if manual updating isn't an option. We also have a patch going through our QA process now and should have an update here once it is ready.
@Severin Discher: Yes but, I guess I was asking: how to do it? After I posted my question, I experimented I tried putting "ssl_protocols TLSv1 TLSv1.1 TLSv1.2;" in our nginx_custom_configs custom recipe, uploaded it and applied it in a test environment, yet I was still able to connect using SSLv3...
Anyway, I see the stacks have been updated with a fix, so no worries!
Thanks again for your great work!