back to article Twitter, Cloudflare kill SSL 3.0 ... and here's how YOU CAN TOO

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 …

  1. Destroy All Monsters Silver badge
    Paris Hilton

    immhavingapacheamidoingitrite?

    Listen 443 https

    SSLProtocol TLSv1.2

    SSLEngine on

    SSLCipherSuite HIGH:!IDEA:!ADH:!MD5:!aNULL

    1. Anonymous Coward
      Anonymous Coward

      Re: immhavingapacheamidoingitrite?

      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).

      1. streaky

        Re: immhavingapacheamidoingitrite?

        -sslv3 or whatever is what you need.

        Edit: Okay less lazy..

        SSLProtocol all -SSLv2 -SSLv3

  2. Novex

    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)

    1. Tom Chiverton 1

      Run the web site through the excellent SSLLabs scanner and see what's wrong.

      1. Novex

        Re: Run the web site through the excellent SSLLabs scanner and see what's wrong.

        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.

        1. Novex

          Re: Run the web site through the excellent SSLLabs scanner and see what's wrong.

          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.

    2. GeorgeL

      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

  3. Ian 55

    IIS needs you to reboot the whole server?

    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.

    1. Alister
      Unhappy

      Re: IIS needs you to reboot the whole server?

      IIS needs you to reboot the whole server?

      Yes!

      Unfortunately, as this is a registry hack, the only way to reload the registry is to restart the operating system.

      1. streaky

        Re: IIS needs you to reboot the whole server?

        "Unfortunately, as this is a registry hack, the only way to reload the registry is to restart the operating system."

        What. No.

  4. GumboKing
    Alert

    Some collateral damage

    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

    1. streaky

      Re: Some collateral damage

      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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like