10

SSL 2 was deprecated in 2011. However many devices are manufactured before 2011 and still in use today, and it is impossible to upgrade the software in the device (e.g. cellphones, tablets, PDAs, routers, IP cameras, printers etc.). In designing a network service, it is impractical to limit secure connection to clients with TLS 1.x only, since that would block out a major portion of users.

How insecure would it be, today, if a well-designed network service provides SSL 2 compatibility? Well-designed being, security is provided by multiple approaches, e.g. 2-factor authentication, proper user permission management, encapsulating user inputs in code, auto account locking after a number of failed logins, DMZ properly setup etc. The key factor here is, if SSL 2 is not provided, the service will be completely inaccessible a major portion of devices (30~40%) that are otherwise perfectly functional.

An example would be a corporate email server for daily communications. Sensitive information are never communicated or stored on this server. This server is capable of all SSL/TLS protocols, with an option to disable the weaker protocols.

What exactly are the risks of accepting SSL 2 connections on the server?

EDIT: This is not a question about how SSLv2 is insecure or why it should not be used. It is about the business risk associated with provide SSLv2 as an additional supported protocol for device compatibility. The concerned devices are:

  1. Perfectly functional.
  2. Supports only SSLv2. There are no possible software upgrade paths as these are not computers.
  3. The only other alternative on these devices is a plaintext transmission.
  4. Represent a majority (or non negligible portion) of the devices using the service.

I'm evaluating the whether to replace all devices, or continue using them but in a relatively insecure manner. It is therefore a business risk management decision. However I must first understand the business risks of providing SSLv2.

Community
  • 1
kevin
  • 933
  • 4
  • 16
  • 1
    SSLv3 was released in 1996. Do you really have twenty-year-old devices that you still need to support? – Mark Sep 02 '16 at 19:46
  • @Mark the devices are around 5~7 years old. I wish I can just reprogram them, since they're, at a hardware level, in very good conditions. The vendor has simply stopped supporting them, to promote their next series of products. – kevin Sep 02 '16 at 19:59
  • 4
    I would suggest that if a vendor put out an item 5-7 years ago that only supported SSLv2, that that item never should have been purchased in the first place and the vendor should probably be blacklisted because their next series of products is probably just as bad. If you use the devices, you should consider it roughly equivalent to plaintext. – Michael Hampton Sep 02 '16 at 21:46

4 Answers4

27

SSL 2 was deprecated in 2011

It was not deprecated, it was outright prohibited which is a huge difference. See also What's the difference between SSLv3 being deprecated and SSLv2 being prohibited?

However many devices are manufactured before 2011 and still in use today

TLS 1.0 was defined 1999 and was available in major TLS stacks (including openssl) from around this time. Not supporting it was already not an option in 2011.

if a well-designed network service provides SSL 2 compatibility

It is a kind of contradictory statement: well-designed vs. providing SSLv2 compatibility. Having a SSLv2 device on the network is not only insecure because of the SSLv2 protocol itself but also because it is highly likely that any old devices which cannot speak any better than SSLv2 wants to use weak ciphers too.

if SSL 2 is not provided, the service will be completely inaccessible a major portion of devices (30~40%) that are otherwise perfectly functional.

Depending on the environment you might be able to secure such devices by adding some software in front so that they are available with better protocols and ciphers.

An example would be a corporate email server for daily communications.

If this server supports only SSLv2 than it must be that old that it has lots of other vulnerabilities. TLS 1.0 was available with Windows XP already.

What exactly are the risks of accepting SSL 2 connections on the server?

While it is bad to have SSLv2 only it is bad to have SSLv2 additionally to other protocols. See DROWN attack for details on how availability of SSLv2 can aid in decrypting properly encrypted connections.

In summary:
if all of this is done within some restricted network where you have no malicious activity the using SSLv2 is probably perfectly safe as would be plain text. But as soon as you have the possibility that someone attacks the network you need to deal with the problems caused by the insecure SSL version (DROWN) and age of SSL stack (weak ciphers) and also at the general software problems (i.e. outdated and probably vulnerable software).

Community
  • 1
Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • In the last OpenSSL 1.0.1 release SSL2 is excluded from default builds You'll have to recompile OpenSSL youself, I expect we might see the same with SSL3 next year with the release of TLS1.3 – Yorick de Wid Sep 02 '16 at 11:21
  • @YorickdeWid: you probable meant OpenSSL 1.1.0 (released recently) not OpenSSL 1.0.1 (released 2012). – Steffen Ullrich Sep 02 '16 at 11:30
  • I'm sorry but this does not answer the question at all. I'm well aware of the relatively insecurity provided by SSLv2. My question is regarding identifying the risks, not a discussion about why SSLv2 should not be used. – kevin Sep 02 '16 at 11:31
  • 4
    @kevin: is DROWN attack not a risk? Are weak ciphers used by old SSLv2 only implementations not a risk? Is using old SSLv2 only software not a risk, which because of the age has probably lots of other unpatched vulnerabilities? – Steffen Ullrich Sep 02 '16 at 11:32
  • 2
    Would you then mind editing your answer to focus more on the risks, instead of a focus on SSLv2 should not be an option? In my scenario, replacing all SSLv2 devices (which are perfectly functional) would bring a non negligible amount of cost, therefore I must balance the cost of replacing them with the risk of continue using them, even if that means a less than perfect security environment. – kevin Sep 02 '16 at 11:45
  • @kevin: I've made a summary at the end. But since your question already starts with false assumptions (deprecation vs. prohibition, new SSLv2 devices up to 2011) I had to debunk these first in my answer. – Steffen Ullrich Sep 02 '16 at 11:47
  • @SteffenUllrich Yes, I posted it way too fast, ty – Yorick de Wid Sep 02 '16 at 11:48
  • 6
    @kevin If you are not concerned with the *why* as this post thoroughly explains, you'd be better off with unecrypted traffic. Then at least you don't facilitate false hope. – Yorick de Wid Sep 02 '16 at 11:52
  • I've clarified the situation a bit: the server is not the problem; it is capable of TLS connections. The clients are the problem. The question is whether to enable SSLv2 on the server to support these clients. – kevin Sep 02 '16 at 11:56
  • 12
    @kevin: this does not change the situation: DROWN is a problem exactly in this use case. Also clients which can only do SSLv2 can probably only to weak ciphers (and it does not matter if the server could do better). And such clients are either very old or the vendor had no idea what he did - which means they are probably vulnerable against attacks outside of SSL. – Steffen Ullrich Sep 02 '16 at 13:37
  • 4
    @Kevin read the linked page on DROWN. Supporting SSLv2 puts _all_ your traffic at risk _not just the clients that are limited to SSLv2_. As such you are not weighing the cost of supporting it vs the cost of replacing the devices, you are weighing the cost of no security against the cost of those devices. It is hard to make a case for allowing it. As [Matija Nalis's answer suggests](http://security.stackexchange.com/a/135739/17393) it would be better to have these devices use plain text and limit the risk to their data than to risk everything. – Mr.Mindor Sep 02 '16 at 20:29
  • @Steffen patch releases 1.0.1s and 1.0.2g on 2016-03-01 changed Configure to exclude SSLv2, and also 'LOW' (56/64-bit) and 'EXPORT' (40-bit) ciphersuites, by default. 1.0.1 is supported for 4 more months, and 1.0.2 will presumably remain supported for some time after 1.1.0. – dave_thompson_085 Sep 03 '16 at 03:14
  • Seffen + @Mindor: to be hyperpedantic, in OpenSSL (if compiled appropriately) if your app has sufficient control of cipherlist and certs/keys, you _could_ support SSL2 with an RSA cert/key and SSL3+TLS with ONLY DSA and/or ECDSA certs/keys and be safe from the propagating part of DROWN. You'd still have POODLE on SSL3, plus probably massive confusion supporting users. – dave_thompson_085 Sep 03 '16 at 03:23
  • @Mr.Mindor .. DROWN is only a risk in the very specific circumstance of other servers using the same private key as the SSLv2 system. that's really easy to avoid at an architectural level , just don't use the same private key. – Rory McCune Sep 03 '16 at 13:58
3

How insecure would it be, today, if a well-designed network service provides SSL 2 compatibility?

extremly insecure, as mentioned by others. If data is really of no importance as you claim, and you absolutely have to support those obsolete devices, you'd be much better to allow only secure TLS connections with 60% of your up-to-date clients, and use plaintext connection for other 40% which would be insecure anyway.

That way when connections are compromised, you'll only have 40% of the damage to cleanup... Additional bonuses is there'll be much better initative to upgrade old devices as people won't (wrongly) think that there is "at least some security with SSL2" (there isn't).

Matija Nalis
  • 2,265
  • 13
  • 19
  • 1
    When you say extremely insecure, can you point to any real-world tools which rely on weaknesses in SSLv2 to allow for exploitation of user data? – Rory McCune Sep 03 '16 at 13:55
  • @RoryMcCune One could, but actual working exploits have a price tag on them, and I don't deal with the stuff. For reasons though, see RFC6176 and fine links in all the comments, and some of the links on cve.mitre.org contain enough information for one in the field to recreate PoC herself. – Matija Nalis Sep 03 '16 at 14:57
  • 1
    well you say you could, but I've been in security quite a while and I've never actually seen one. Also I'd suggest there has never actually been a single observed case in the wild of someone actually leveraging any SSL protocol weakness (as opposed to an implementation weakness) as part of an attack. – Rory McCune Sep 03 '16 at 15:05
  • I explicitely said **I** do not deal with blackhat stuff... But I don't work for NSA, either. By the time whitehat folks learn of the exploit in the wild, it was usually already been exploited for years (at least) by government-level adversaries... – Matija Nalis Sep 03 '16 at 18:14
  • This advice seems irresponsible to me. There's a *big* difference between someone sniffing the traffic somewhere on the path and actively performing a MItM attack. The latter would be required to take advantage of any SSLv2 weaknesses, but the former could easily read plaintext data. There absolutely is "at least some security with SSL2". I don't see how you could responsibly claim there is not. This suggestion is analogous to telling people that have old cars which can easily be unlocked with a slim jim tool to just leave their cars unlocked, or buy a newer car. – TTT Sep 03 '16 at 18:35
  • @MatijaNalis lol NSA as bogeyman. So I'd suggest that if your adversary is the NSA then SSLv2 protocol weaknesses are the least of your worries, as they have a number of easier ways of breaking in. which is kind of the point of my answer, I think that overblowing the risk of poor encryption protocols is a bad idea. Yes it's definitely not the best option, but it needs to be considered alongside the threat model of the company in question. – Rory McCune Sep 03 '16 at 19:44
3

The area that all the other answers seem to be missing is that the relative security (or lack thereof) of using SSLv2 in practical terms depends on the the threat model of the environment that they will be used in.

So everyone would agree that SSLv2 is a weak protocol (more technical details from the inimitable Mr Leek here. Basically an attacker with MITM is going to have more joy at attacking a connection made with SSLv2 and also where it uses weaker ciphers an attacker who can see traffic in a connection might be able to decrypt it more easily. In either case it's fair to say that this still isn't a low-end attack, MITM attacks on SSL aren't trivial to execute and decrypting even relatively weak ciphers takes a bit of effort. Well within nation state attack levels but not generally in the realm of casual or low-end attackers

In addition to this we have DROWN, but the key point about that is, it only applies where another server uses the same private key as the one running SSLv2.

So where does that leave us, back with your threat model. Who are the attackers who might want to compromise your system?

If we're looking at either high-end professionals or nation state, it's fair to say that SSLv2 should not be on the cards in any way, as the weaknesses it has are likely to be exploitable by those attackers

However, if your concerns are more around casual or low-end attackers easily getting access to the data in transit (perhaps it's being transmitted over a wireless network which has other users), then realistically I don't think you're likely to get compromised via an attack on SSLv2

Likely the largest practical business risk in those scenarios is that from a compliance standpoint this won't look good, and also if you get a security consultant in they will flag this up as a risk...

Outwith your SSLv2 problem, from a real-world seurity perspective, I'd likely be far more concerned about likely vulnerabilities in the software operating on these devices, given that it sounds like you won't be able to get security patches for them...

Community
  • 1
Rory McCune
  • 61,541
  • 14
  • 140
  • 221
2

EDIT: This is not a question about how SSLv2 is insecure or why it should not be used. It is about the business risk associated with provide SSLv2 as an additional supported protocol for device compatibility. The concerned devices are:

  1. Perfectly functional.
  2. Supports only SSLv2. There are no possible software upgrade paths as these are not computers.
  3. The only other alternative on these devices is a plaintext transmission.
  4. Represent a majority (or non negligible portion) of the devices using the service.

I'm evaluating the whether to replace all devices, or continue using them but in a relatively insecure manner. It is therefore a business risk management decision. However I must first understand the business risks of providing SSLv2.

There are two business risks:

  1. You may expose other (TLS) clients to DROWN attacks (which have been well covered by other answers so I will not repeat them here).
  2. You may cause your users to erroneously believe that their data is more secure than it would be if it were transmitted in plaintext.

Plaintext would actually be more secure because it would eliminate (1) and mitigate (2) (to the extent that users are aware you are using plaintext).

(Technically, mounting an attack against a plaintext session would be more straightforward than attacking SSLv2. But your threat model generally should not assume the adversary is lazy, so we cannot regard SSLv2 as more secure.)

Kevin
  • 916
  • 6
  • 12
  • I must say I'd disagree that, in most circumstances, cleartext transmission is more secure than SSLv2 encrypted data. Casual interception (e.g. over a wireless network) of cleartext data seems much more of a risk than an attacker who is able to decrypt SSL encrypted data of any kind. – Rory McCune Sep 03 '16 at 13:56
  • @Rory: You should be using WPA anyway. – Kevin Sep 03 '16 at 16:10
  • errm you realise that in many cases where two clients are attached to the same wireless network, traffic sniffing is possible even when WPA is in use? – Rory McCune Sep 03 '16 at 17:27
  • @Rory: I've never heard of that. Do you have a citation? I'd like to read more about the attack. – Kevin Sep 03 '16 at 17:28
  • 1
    http://security.stackexchange.com/a/6947/37 is one example of citations, bascially if you're authenticated to a wireless network unless client isolation or similar is deployed you can sniff traffic at the app. layer happily, so cleartext over WPA, whilst it protects against unauthenticated clients doesn't generally protect against other authenticated users. Also https://wiki.wireshark.org/HowToDecrypt802.11 from the wireshark wiki – Rory McCune Sep 03 '16 at 17:46
  • @RоryMcCune: Added a sentence at the end about SSLv2 vs. plaintext. What do you think? – Kevin Sep 03 '16 at 17:59