Slashdot Mirror

← Back to Stories (view on slashdot.org)

RFC 7568 Deprecates SSLv3 As Insecure

Posted by timothy on from the must-not-is-in-all-caps dept.

AmiMoJo writes: SSLv3 should not be used, according to the IETF's RFC 7568. Despite being replaced by three versions of TLS, SSLv3 is still in use. Clients and servers are now recommended to reject requests to use SSLv3 for secure communication. "SSLv3 Is Comprehensively Broken," say the authors, and lay out its flaws in detail.

40 of 53 comments (clear)

  1. PROPOSED standard by andreas.hummelbrunne · · Score: 2

    Currently, this is a PROPOSED standard. Meaning it still has to be accepted as standard by the IETF.

    1. Re:PROPOSED standard by Junta · · Score: 3, Insightful

      In RFC land, PROPOSED standard is pretty much as far as most things get.

      See:
      https://tools.ietf.org/rfc/ind...

      For example, nntp is 'just' a 'proposed standard'.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    2. Re:PROPOSED standard by Opportunist · · Score: 1

      It is the DE FACTO standard if you at least care a tiny little bit about security.

      RFC or not.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  2. yeah yeah by Anonymous Coward · · Score: 1, Flamebait

    and what about the tens of thousands of UPSes, printers, KVMs, IP cameras, thermocouples and other embedded crap all which only responds to SSL v3 ? i suppose the IETF is going to come out with special firmware for all those devices still in wide use ? oh wait they arent. typical software "engineers" with no real world experience. go fuck yourselves.

    1. Re:yeah yeah by XanC · · Score: 2

      Would you prefer they pretend such devices aren't broken? It's not like they're waving a wand and making them all disappear anyway.

    2. Re:yeah yeah by ledow · · Score: 2

      Well.. personally speaking I don't expose any functionality to the net unless it can be updated, authenticated, secured, QoS'd, logged and monitored.

      So pretty much all those devices shouldn't BE on the boundary of your network, the only thing standing between you and the outside world.

      If you want to do that, use reverse proxies, not port-forwards, use VPN's, not opening up some cheap Chinese webcam to your home network and the random people of the Internet.

      So it doesn't actually matter if they used TLS or not - they are communicating only across a secured network anyway. You may as well just HTTP or telnet into them from your VPN.

      Just make sure that your frontline, Internet-facing, open-to-attack-from-the-Internet device if secured. So your VPN/firewall. And that's it.

    3. Re:yeah yeah by QuietLagoon · · Score: 2

      and what about the tens of thousands of UPSes, printers, KVMs, IP cameras, thermocouples and other embedded crap all which only responds to SSL v3 ?...

      Once the RFC "passes", they are out of standard.

      .
      I had to replace my 11-year-old wireless access point because it did only SSL3 and my browsers refused to connect to it in their default configuration. Even though the firmware in the access point is upgradeable, Netgear stopped supporting that unit long ago.

      So what about all the devices that are not upgradeable? Well, the first thing is not to expose them to insecure networks....

    4. Re:yeah yeah by rickb928 · · Score: 2

      All that 'utility' stuff shouldn't be exposed to public nets anyways, maybe not even to your intranet.

      Since your threats are both external (DDOS, botnets, intrusion) and internal (malware, bots, id10ts), you need to protect your management systems from both, and segregate your networks.

      Yes, a huge nuisance to be using portals, multiple authentications, etc, but the choice, for some, is having to explain how they crooks got into your corp net and picked it clean, or how they got into EVERYTHING and you can't get them out of all that, 'cause your management tools are also compromised, and they keep respawning internally, and you just can't, and they just keep, and it's so haaaarrd...

      Because you can't, probably, 'just reimage' all your servers, VMs, firewalls and appliances, even the damned UPS stuff. At least not without a total shutdown, and probably without a specific ETA...

      Arg.

      --
      deleting the extra space after periods so i can stay relevant, yeah.
    5. Re:yeah yeah by ThatsMyNick · · Score: 1

      It will display a warning and let you continue. Most of them use self signed certificates and get a warning displayed anyways.

    6. Re:yeah yeah by camperdave · · Score: 1

      It's not like they're waving a wand and making them all disappear anyway.

      They are... if nothing can speak SSLv3 to them.

      --
      When our name is on the back of your car, we're behind you all the way!
    7. Re:yeah yeah by bill_mcgonigle · · Score: 1

      It will display a warning and let you continue

      No, it won't - and that's the whole problem. It prompted me to write this piece on re-enabling SSLv3 on Firefox which is probably the most heavily-trafficked post I've done on that blog.

      Most of these devices will support HTTP and HTTPS. The posture of the browser developers is to blow up HTTPS support on SSLv3 everywhere, regardless of the risk profile.

      There are very few people who are going to get $1100 to replace a PDU because the current one only supports SSLv3. As it currently stands, those people have to re-enable SSLv3 for the whole Internet on their browsers to admin their local devices. Pretty soon they will have to stop updating their web browsers entirely.

      There are only two possible real world outcomes:
      1) people will re-enable HTTP administration and start sending their passwords cleartext on their LANs
      2) the very people in companies who do security work will be running outdated browsers, on purpose, to connect to their gear.

      3) a million dollars will appear overnight in a company's budget to replace gear for highly theoretical risks

      simply is not an option that exists concurrent with reality.

      If the browser engineers had handled the situation the same way as self-signed certs, or even made a more complex UI to specifically whitelist certain hostnames or subnets, then we could have made a reasonable transition. But that would have been hard work with real analysis required, and why do that when flipping a switch and boldly posturing is more crypto-macho?

      The very same people who jeered corporate people for staying on IE6 are creating exactly the same situation in regards to SSLv3. They may understand a narrow aspect of cryptography very well, but they completely fail to understand the security of complex systems. They are hurting the security and privacy we're working so hard to achieve. Jeers indeed.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    8. Re:yeah yeah by toejam13 · · Score: 1

      Time for a Firefox plugin that allows SSLv3 for local subnets/domains and any other whitelisted site but blocks it for everything else.

    9. Re:yeah yeah by operagost · · Score: 1

      It does matter if you are under a standard like PCI DSS. Even internally, PANs must only be transmitted over an encrypted connection, and systems where the PAN is stored must be administered with encrypted connections.

      --

      Gamingmuseum.com: Give your 3D accelerator a rest.
    10. Re:yeah yeah by Krojack · · Score: 1

      I guess it's a good thing there are only ten of thousands and not hundreds of thousands or millions... Shouldn't take long to replace them all.

    11. Re:yeah yeah by omnichad · · Score: 1

      There are only two possible real world outcomes:
      1) people will re-enable HTTP administration and start sending their passwords cleartext on their LANs
      2) the very people in companies who do security work will be running outdated browsers, on purpose, to connect to their gear.

      What about
      3) Create a trusted MITM proxy for all these devices. Browsers only see the higher-security proxy.

    12. Re:yeah yeah by Demonoid-Penguin · · Score: 1

      3) a million dollars will appear overnight in a company's budget to replace gear for highly theoretical risks

      Sort of like DDT. Except we didn't call the people who formerly championed it out when they finally saw the light.

    13. Re:yeah yeah by Demonoid-Penguin · · Score: 1

      If they support HTTP, what is the problem?

      If you do not have these toys on a private network you are doing it wrong.

      If I hadn't already posted I'd mod you up.

      It's not a binary problem - like having to deal with the companies investment in SAP/Oracle, old IE is used internally - that doesn't mean it should therefore be foisted on external users. Recognise the problem and contain it until it's feasible to remove it altogether.

      Bill "plug my articles" is a classic case of confirmation bias resulting from an emotional over-investment "we made significant investments so we distort risk management to base our decisions on the (optimistic) risk of a problem occurring, while ignoring the severity of the outcome" if (or when) that risk changes from probable to actual". The clue is in the "The very same people who jeered corporate people for staying on IE6 are creating exactly the same situation in regards to SSLv3. They may understand a narrow aspect of cryptography very well, but they completely fail to understand the security of complex systems.". As if "the system is really complex - you wouldn't understand" somehow negates the "I have no clue about the actual problem - cryptography is hard, so the problem is very small".
      Bill - it's OK to say you were wrong. Seriously. Sticking to your guns and all that other John Wayne bullshit is just that - bullshit (you do know he was a professional liar, right?). SSL3 is not the true successor to SSL2 - back to the drawing board, otherwise the only praise you deserve is "thanks for lowering the standards".

    14. Re:yeah yeah by camperdave · · Score: 1

      Google is removing SSLv3 from Chrome. It's gone from Firefox and Microsoft Internet Explorer. Safari won't be far behind. How are you going to connect to your SSLv3 device with no software?

      --
      When our name is on the back of your car, we're behind you all the way!
  3. It's about time by QuietLagoon · · Score: 1

    What in the world took so long?

  4. Agreed, but at least one point is alarmist... by Junta · · Score: 1

    Saying HMAC with SHA1 is 'weak' is a bit too worrisome. Even with MD5 broken, none of the breakage applies to use in HMAC as far as I know.

    So yes, if you are using a new implementation, go with the best hash. No reason to chose MD5/SHA1 in a new design. However if you are currently reliant upon some use of HMAC that happens to use SHA1 or even MD5, no need to exactly panic and break things to get away from that in an urgent way.

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:Agreed, but at least one point is alarmist... by Opportunist · · Score: 1

      My guess is that it's one of those "while we're at it..." things. I'm pretty sure that by the time that standard gets finally heeded by the majority, SHA1 can safely be considered "too weak for human consumption"...

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    2. Re:Agreed, but at least one point is alarmist... by Junta · · Score: 1

      HMAC is not just used in SSL. It's a commonly employed in a lot of protocols. It's an additional level of complexity beyond a 'broken' hash to compromise HMAC.

      A hash is compromised if you can find a collision faster than brute force. Even if you have no control over the data it is broken.

      It is more dangerously/practically broken if you can control generating two sets of data that hash to the same value. This is where MD5 is IIRC

      It is even more critically broken if, given an image that you do not control, you can generate your own data to hash to the same value.

      HMAC requires that the data combined in a useful way with some shared secret hashes to the given value. An attacker is missing part of the image that would require to be attacked, and that missing part is applied to the image in a way that makes it resilient to prefix and append attacks. SHA-1 and MD5 are weaker by virtue of brute force being easier in an HMAC context, but I don't think I've heard either of them as being 'broken' in context of HMAC. An example would be if someone figured out how to change arbitrary middle part of an image and have the hash work out correctly regardless of the secret data (if it collides, that might not be the desired effect, it would have to match what the image would have after being combined with the unknown key)

      --
      XML is like violence. If it doesn't solve the problem, use more.
    3. Re:Agreed, but at least one point is alarmist... by WaffleMonster · · Score: 1

      HMAC is not just used in SSL. It's a commonly employed in a lot of protocols. It's an additional level of complexity beyond a 'broken' hash to compromise HMAC.

      Exactly, just because a hash algorithm is broke for one purpose does not make it broke for all purposes. There are no publically known issues with even HMAC-MD5.

      Should also mention the PRF construction of SSLv3 is exactly the same as TLSv1. Only TLSv1.1+ cipher suites have different PRF algorithm. Statement in section 4.3 is flat wrong.

    4. Re:Agreed, but at least one point is alarmist... by Demonoid-Penguin · · Score: 1

      Saying HMAC with SHA1 is 'weak' is a bit too worrisome. Even with MD5 broken, none of the breakage applies to use in HMAC as far as I know.

      So yes, if you are using a new implementation, go with the best hash. No reason to chose MD5/SHA1 in a new design. However if you are currently reliant upon some use of HMAC that happens to use SHA1 or even MD5, no need to exactly panic and break things to get away from that in an urgent way.

      Panic no. Make plans to avoid a predictable risk from a demonstrable weakness in systems likely to be targets - yes.

      Just don't be the dick that, after jumping off the tenth floor was heard to say "so far so good" - while passing the third floor.

  5. They broke it when they named it TLS. by Anonymous Coward · · Score: 1

    They broke it when they named it TLS. Don't get me wrong. I know the security is better. That's not what they broke.

    They broke the name. Instead of just continuing on calling it "SSLv4" and so on, they changed it to "TLS". But everyone is told to "use SSL" meaning, "use SSL or TLS". Certificates are "SSL Certificates" that happen to work for TLS also. SSL is the secure sockets layer, while TLS is just transport layer security. One of them is "secure" in the absolute sense, the other just provides some "security". (This isn't reality, it's just what the name implies to people.)

    Now they get to live with the fact that they screwed up their PR on this one and people are responding negatively. Get used to the fact that people will continue to use SSL, and if there's any sense in the decision-makers' heads at all, they'll change the name to match what people expect.

    1. Re:They broke it when they named it TLS. by guruevi · · Score: 2

      Legal issues. SSL = Name was created and owned by Netscape (now AOL/TWC). TLS = Open/free and named so it would not get into trademark issues with Netscape/AOL.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    2. Re:They broke it when they named it TLS. by danbob999 · · Score: 1

      There is only one version of SSL still used. So soon enough, SSL will be legacy and all supported versions will be called TLS.

    3. Re:They broke it when they named it TLS. by perbu · · Score: 1

      Legal issues. SSL = Name was created and owned by Netscape (now AOL/TWC). TLS = Open/free and named so it would not get into trademark issues with Netscape/AOL.

      So I've heard. However, I've found no filed trademark "SSL" from Netscape. The trademark database is easily searchable.

    4. Re:They broke it when they named it TLS. by guruevi · · Score: 2

      In the US, you need not register a name for it to be trademarked necessarily. You just have to have it used.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    5. Re:They broke it when they named it TLS. by perbu · · Score: 1

      Sure. But that would be quite weak protection, especially where there is little or no risk of consumer harm. I've written about the name change a couple of times but I've never found a primary source on the issue and I'm curious to hear whether or not is real.
      If anyone has a link to some primary source on this that would be great.

    6. Re:They broke it when they named it TLS. by Bing+Tsher+E · · Score: 1

      In the US, you need to defend a trademark for the trademark to remain valid. If you haven't sued anybody, you won't be able to eventually.

  6. RFCs are not laws by WaffleMonster · · Score: 1

    It is sufficient to offer a comprehensive list of reasons for operators to discontinue use of SSL. Declaring "This document requires that SSLv3 not be used" is a pointless assertion.

    The market not IETF process decides which protocols will continue to be used going forward.

    1. Re:RFCs are not laws by Just+Some+Guy · · Score: 2

      The market not IETF process decides which protocols will continue to be used going forward.

      The market loves when we have formal documents laid down by the Formal Documents People confirming what we've been telling our bosses for years. I would bet large sums of money that some tech, somewhere, just walked out of a meeting happy because he finally has permission to deprecate a long-broken system.

      --
      Dewey, what part of this looks like authorities should be involved?
    2. Re:RFCs are not laws by TheRaven64 · · Score: 1

      The point of this is not to enforce it, it's so that you can justify doing the right thing to management in the name of standards compliance.

      --
      I am TheRaven on Soylent News
    3. Re:RFCs are not laws by WaffleMonster · · Score: 2

      The market loves when we have formal documents laid down by the Formal Documents People confirming what we've been telling our bosses for years. I would bet large sums of money that some tech, somewhere, just walked out of a meeting happy because he finally has permission to deprecate a long-broken system.

      I was afraid people would push back with these arguments.

      They would have had to miss section 3.1.1 of RFC7525 "Implementations MUST NOT negotiate SSL version 3.".. RFC7525 by the way is a BCP which is where this shit belongs.

      My point was subtle. You can provide reasons why you shouldn't use this or that which can be used for the same reasons you enumerated all without the baseless assertions and demands.

      BCPs are the appropriate venue for this not this largely redundant standards track RFC which happens to get noticed by Slashdot.

    4. Re:RFCs are not laws by WaffleMonster · · Score: 1

      The point of this is not to enforce it, it's so that you can justify doing the right thing to management in the name of standards compliance.

      This what BCPs are for. Specifically RFC7525 which already addresses this issue.

  7. Re:You think V3 is bad? by MightyDrunken · · Score: 2

    Did you say NSA appliance? Well there is your problem.

    --
    The most dangerous drug
  8. Re:You think V3 is bad? by Anonymous Coward · · Score: 1

    Did you say NSA appliance?

    No, Tweedle Dum.

  9. Re:You think V3 is bad? by ledow · · Score: 1

    Try tponline.co.uk - which is the UK , Teacher's Pension (and List 99 temporary criminal record check before the "proper" check is done) website.

    Ironically, it's one of the few website that REQUIRES a client certificate for every user who logs into it (which is a pain in the butt and costs a fortune as only they can supply the correctly signed client certs).

    The signup page, however? SSL v2.0 and vulnerable to EVERYTHING:

    https://www.ssllabs.com/ssltes...

    An "F" rating on SSL Labs. First time I've ever seen that on a domain that I've thought to check.

  10. TLSv1.0 too... by roman_mir · · Score: 1

    Doing some some PCI compliance certification stuff and a scan shows that the site is not compliant, the reason being that TLSv1 is supported. Turning TLSv1 off kills off support for a number of older browsers, all types of browsers.....

    (nginx)

        server {
            ssl on;
            #ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
            ssl_protocols TLSv1.1 TLSv1.2; .....
            }
        }

    Now I am trying to figure out what to do about this problem, how to detect the clients that do not support TLSv1 and to redirect them to a simple html page instead of the clients pretty much receiving 'connection reset by server' error.

    No dice so far, but I thought this was only supposed to happen a year from now (June 2016, not 2015), oh well.

    --
    You can't handle the truth.