RFC 7568 Deprecates SSLv3 As Insecure

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.

Comments

PROPOSED standard

[andreas.hummelbrunne]

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

Re:PROPOSED standard

[Junta]

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

Re:PROPOSED standard

[Opportunist]

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

RFC or not.

Re:PROPOSED standard

[Anonymous Coward]

Yeah, just like Internet Key Exchange v2:
http://www.rfc-editor.org/std/std79.txt
Oh wait... that is an actual standard...

Any how... I find it interesting that the document does not address SSLv2 (or SSLv1). The RFCs related to this originally intended there to be a negotiation. It was possible for a client or server to drop a connection because one would not support a high enough version. Admittedly, as you go back in time these older protocols are less desirable. But if you have an RFC that says a server must not send a SSLv3 response, it should just as validly not send an SSLv2 or SSLv1 response.

yeah yeah

[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:yeah yeah

[XanC]

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:yeah yeah

[ledow]

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.

Re:yeah yeah

[QuietLagoon]

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:yeah yeah

[rickb928]

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.

Re:yeah yeah

[Anonymous Coward]

If it is on the Internet, it needs to be hardened and updatable. In general, devices should be on a private segment, well firewalled, disallowing all access in/out [1] unless explicitly needed. Everything else needs to be on a private network tucked well away from the Internet, accessible via a VPN (that uses 2FA.)

Ideally the private network should be segmented so that a compromised machine on one subnet can't access cameras on another unless there is a need for it.

[1]: Disallowing access in goes without saying, but disallowing access out is just as important so a compromised device isn't able to phone home, or if it does, it sets off the IDS so its compromise is evident.

Re:yeah yeah

[ThatsMyNick]

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

Re:yeah yeah

[camperdave]

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

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

Re:yeah yeah

[bill_mcgonigle]

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.

Re:yeah yeah

[toejam13]

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

Re:yeah yeah

[Bengie]

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.

Re:yeah yeah

[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 ?
They're going to stop working once browser makers disable SSLV3. That's good. The companies who decided on supporting a standard from the previous century are going to look bad, and people are going to get mad "Why doesn't this stupid camera I bought 3 years ago work anymore?". Well, because the makers of the thing thought they could sell it and not support it, treating it like a brick instead of software that's part of an ecosystem.

Abandonware breaking is a GOOD THING. It's supposed to break and send a message to the manufacturers that supporting a product on the web takes years of commitment, not simply just making it and moving on, which is currently the case.

Re:yeah yeah

[operagost]

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.

Re:yeah yeah

[Anonymous Coward]

Who gives a fuck?

None of those should be on an internet routable address anyway.

Re:yeah yeah

[Anonymous Coward]

Because everything those limited devices could talk to will magically not support SSLv3

Numbnuts

Re:yeah yeah

[Anonymous Coward]

If they support HTTP, what is the problem?

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

Re:yeah yeah

[Krojack]

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.

Re:yeah yeah

[omnichad]

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.

Re:yeah yeah

[Demonoid-Penguin]

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:yeah yeah

[Demonoid-Penguin]

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

Re:yeah yeah

[camperdave]

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?

It's about time

[QuietLagoon]

What in the world took so long?

Agreed, but at least one point is alarmist...

[Junta]

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.

Re:Agreed, but at least one point is alarmist...

[Anonymous Coward]

I thought poodle rendered sslv3 completely broken anyway?
http://www.neowin.net/news/poodle-attack-shows-that-all-sslv3-connections-are-insecure

Re:Agreed, but at least one point is alarmist...

[Opportunist]

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

Re:Agreed, but at least one point is alarmist...

[Anonymous Coward]

Look, the NSA needs all you shitlords to move to the latest, totally not backdoored, elliptic curve encryption standards. Sof if you nerds could just update all your servers to stop using RSA ASAP that would be great. *sips coffee*.

Re:Agreed, but at least one point is alarmist...

[Junta]

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)

Re:Agreed, but at least one point is alarmist...

[WaffleMonster]

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.

Re:Agreed, but at least one point is alarmist...

[Demonoid-Penguin]

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.

You think V3 is bad?

[Anonymous Coward]

I've got a NAS appliance at work whose "secure" web administration portal not only uses SSLv3 and is vulnerable to Poodle, but accepts SSLv2 (!!!). Why no, no updates from the manufacturer are forthcoming, why do you ask?

This is what we have to look forward to with IoT devices a thousand times over: Insecure software stacks that not only aren't up to date, but CAN'T be kept up to date.

Re:You think V3 is bad?

[MightyDrunken]

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

Re:You think V3 is bad?

[Anonymous Coward]

Did you say NSA appliance?

No, Tweedle Dum.

Re:You think V3 is bad?

[ledow]

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.

They broke it when they named it TLS.

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

Re:They broke it when they named it TLS.

[guruevi]

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:They broke it when they named it TLS.

[danbob999]

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

Re:They broke it when they named it TLS.

[perbu]

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:They broke it when they named it TLS.

[guruevi]

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

Re:They broke it when they named it TLS.

[perbu]

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.

Re:They broke it when they named it TLS.

[Bing Tsher E]

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.

RFCs are not laws

[WaffleMonster]

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.

Re:RFCs are not laws

[Just Some Guy]

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.

Re:RFCs are not laws

[TheRaven64]

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.

Re:RFCs are not laws

[WaffleMonster]

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.

Re:RFCs are not laws

[WaffleMonster]

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.

Re:RFCs are not laws

[Anonymous Coward]

The "market" is an inefficient sociopath.

TLSv1.0 too...

[roman_mir]

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.

"Eating your words" != GOOD nutrition

[Anonymous Coward]

"Your hosts file comments are not trustworthy" - by omnichad (1198475) on Friday August 09, 2013 @11:22AM (#44520759)

Oh, really? Ok: MalwareBytes' hpHosts Admin (MalwareBytes employee who has seen & verified its sourcecode too no less as safe) hosts & recommends it -> http://hosts-file.net/?s=Downl...

&

MalwareBytes = BEST antivirus (per this VERY recent testing of them all) -> http://www.av-test.org/en/news...

&

It's GUARANTEED safe & clean (per it being checked by 57 antivirus programs recently) in BOTH its 64-bit model -> https://www.virustotal.com/en/...

+

In its 32-bit model also https://www.virustotal.com/en/...

---

Tells us, omniweasel:

* HOW'S IT TASTE "EATING YOUR WORDS" flavored with your FOOT IN YOUR MOUTH ramming them down spiced with the BITTER TASTE of SELF-DEFEAT"?

LMAO...

APK

P.S.=> Lastly: In the past, You also conceded MANY points on hosts to me & made huge mistakes vs. me here http://tech.slashdot.org/comme...

&

Here too http://tech.slashdot.org/comme...

LMAO @ U, "omniloser"... apk