Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Communications Security The Internet

RFC 7568 Deprecates SSLv3 As Insecure 53

Posted by timothy 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.
This discussion has been archived. No new comments can be posted.

RFC 7568 Deprecates SSLv3 As Insecure More

RFC 7568 Deprecates SSLv3 As Insecure

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

  • yeah yeah (Score:1, Flamebait)

    by Anonymous Coward

    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.

    • Re: (Score:3)

      by XanC ( 644172 )

      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.

      • Re: (Score:3)

        by ledow ( 319597 )

        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 n

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

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

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

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

      • Re: (Score:1)

        by Bengie ( 1121981 )

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

        The second thing is to replace them or get upgradable devices. but but but but... excuses.

    • 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

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

      • 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 [bfccomputing.com] 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 S

        • Comment removed based on user account deletion

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

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

    • Re: (Score:2)

      by Krojack ( 575051 )

      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.

  • What in the world took so long?

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

    • 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"...

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

  • They broke it when they named it TLS. (Score:1)

    by Anonymous Coward

    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 "secu

    • Re: (Score:3)

      by guruevi ( 827432 )

      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.

      • Re: (Score:1)

        by perbu ( 624267 )

        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.

        • Re: (Score:3)

          by guruevi ( 827432 )

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

          • Re: (Score:1)

            by perbu ( 624267 )

            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.

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

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

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

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

      • 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

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

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

  • 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

Slashdot Top Deals

"Ninety percent of baseball is half mental." -- Yogi Berra

Close