immhavingapacheamidoingitrite?
Listen 443 https
SSLProtocol TLSv1.2
SSLEngine on
SSLCipherSuite HIGH:!IDEA:!ADH:!MD5:!aNULL
Websites and web browser makers are moving quickly to ditch the outdated SSL 3.0 encryption protocol for HTTPS following the discovering of a worrying design flaw. On Tuesday, Google researchers published details about the shortcoming, dubbed POODLE, which allows eavesdroppers to crack encrypted web traffic. More specifically …
I found according to Qualy's SSL checker that if I disabled TLS 1.0 a whole stack of common browsers were marked as "failed", such as the browser in Android 4.0 (which would include my phone).
So it might be wise to allow TLS 1.0 and 1.1 as well for now, unless you only care about your own access (in which case, use whatever you like because you control the infrastructure).
Disabling SSLv3 on SSLProtocol in httpd.conf on Apache works, but disabling SSLv3 on SSLCipherSuite in httpd.conf is breaking my web server (and the same in my email server with tls_cipher_suite in imapd.conf)... :(
So how do we get rid of the old SSLv3 ciphers, and ensure that the TLS 1.2 ciphers are used instead?
(Browser: FF 32; Email: TB 31)
If you mean the Qualys one, that's the one I benchmark by. If I disable the SSLv3 ciphers on my web server, but allow TLSv1 and TLSv1.2, nothing for TLSv1 gets through (all those clients show 'Protocol or cipher suite mismatch'), but a few that use TLSv1.2 are OK.
After a bit of 'back of envelope' research, I have found that it turns out the ciphers for SSLv3 and TLSv1 are basically the same but with different names. However, on my servers the TLSv1 setting directly links to the SSLv3 cipher list, so disabling SSLv3 in the cipher entry causes the ciphers for both SSLv3 and TLSv1 to be disabled. I believe this is an OpenSSL issue that may or may not be OS specific, or related to the version of OpenSSL on my server.
That is because SSLv3 needs to be disabeld at SSL protocol level and not SSL cipher suite level. The reason is OpenSSL tags TLSv1 with SSLv3 labels at ciper suite level. So if you disable SSLv3 at cipher level, you also disable TLSv1 - see proof at https://community.centminmod.com/threads/poodle-attacks-on-sslv3-vulnerability.1651/page-3#post-8189
When the linked to says IIS needs you to reboot the server, does it just mean the IIS software (in the way that you just need to tell Apache to look at its config files again) or the whole server?
I'm getting flashbacks to the way NT used to want several reboots every time you looked at the network settings.
After a customer's PayPal order seemed to have mysteriously not appeared in our system, we discovered that PayPal has blocked SSLv3 on their Instant Payment Notification (IPN) callbacks (without any notice as far as I can tell). It affects people who use older versions of their API under PHP.
A bit more info here:
http://stackoverflow.com/questions/26379773/paypal-ipn-acknowledgements-failing-with-ssl-routinesssl3-read-bytessslv3-aler
It's because they hardcoded telling curl to use SSLv3 - they've done it again in the patch with TLSv1.0 - given the state that TLSv1.0 is in it's highly likely the same thing will happen in the future and it'll break again. I don't know why they're not letting Curl negotiate the highest TLS version available, which is something I've mentioned on their github.