10

I've collected the issues that affect SSL 3.0 and found that they

  • are either configuration issues (disabling RC4, RC2, DES, anon, export, null suites, compression, proper key lengths, etc.) or
  • require a browser where the attacker can generate traffic using JavaScript.

So the question is: can a properly configured SSL 3.0 connection be attacked if the client is not a browser? (Think MUAs and other agents like that.) Are there attacks that can target a properly configured SSL 3.0 client-server that wouldn't be possible if the only thing that'd change was the protocol to a newer version?

I have the following theories about potential attacks:

  • BREACH, CRIME: both rely on the effect of compression of attacker-supplied known plaintext, thus not exploitable if the attacker cannot initiate requests in the context of the victim SSL client
  • POODLE: it can force fallback to SSL 3.0, but in this case, SSL 3.0 is used in itself, so the attack is irrelevant (see other attacks)
  • BEAST, Lucky13: both rely on cryptographic oracles (either time- or response based) that are exploitable only if the attacker can initiate requests in the context of the victim SSL client, which is not the case in my scenario above
  • RC4 attacks: mitigated by disabling RC4, leaving 3DES-CBC ciphersuites as the only choices (AES was not yet included in SSL 3.0, since it was released in 1996)
  • FREAK, LOGJAM: mitigated by enforcing sane key lengths (>1024 bit) on client and server

In summary, my client and server is configured in a way that keys have sane lengths, and the only cipher suite enabled is SSL_RSA_WITH_3DES_EDE_CBC_SHA.

See also previous discussion on /r/crypto

Improve this question
7
  • How can you say that the attacker cannot initiate requests? Are you only accepting connections from a single IP address or something like that?
    – Daisetsu
    Apr 24, 2016 at 1:30
  • @Daisetsu no, the context you cut off is important. The attacker cannot initiate requests in the context of the victim SSL client, so unlike in a browser where a malicious web page can use JavaScript to send requests from the victim browser, the scenario I'm interested in excludes such opportunities. As I wrote, such an example is a MUA or other non-browser SSL client.
    – dnet
    Apr 24, 2016 at 20:33
  • 1
    Ok, it wasn't entirely clear what you meant by 'in the context of the victim SSL client'. What you mean by that is that an attacker can't forge SSL requests via javascript or browser plugins since those don't exist outside a browser, right?
    – Daisetsu
    Apr 24, 2016 at 20:36
  • @Daisetsu exactly
    – dnet
    Apr 29, 2016 at 14:56
  • 1
    Seems like assuming the lack of capability on the client's behalf is what would actually create a poor security architecture justification. I don't think it's a bad question though (+1), interesting if nothing else, but this type of question leads to justifications for things which generally are not safe. Always assume the client may also be the attacker or enemy within and defend from there.
    – Trey Blalock
    Mar 29, 2017 at 6:24

1 Answer 1

Reset to default
1

SSL 3.0 is deprecated for almost two years now. As said by others, don't find any justification to use it any longer then necessary. About now almost all client software (including MUA's) will stop supporting it.

https://www.rfc-editor.org/rfc/rfc7568

Improve this answer
4
  • Dream on. Sure, Hipster Technology LLC and security-minded SMBs will maybe stop using it entierly, but security is only one of the many things organizations need to take care of. It's not about justifying it, it's about measuring the amount of risk it causes. If you as a decision maker in the area of corporate IT security have a list of 200 issues, usually you have the resources to deal with the top 100. In that case, sorting the issues in a meaningful manner is important, since an SQL injection on your web page is a bit more important than a hard(er)-to-exploit SSL flaw.
    – dnet
    Apr 24, 2017 at 12:21
  • However, this is not a matter of another risk assessment. At some point it was decided that this service or site should be secured (by the means of SSL). Things are either secured (according to latest standards) or they are not secured at all.
    – user258572
    Apr 25, 2017 at 13:37
  • That's precisely where you're wrong. Organizations have a finite amount of resources to devote to security. The more the better, but at some point you have to draw the line how much effort goes into securing a service. And this is not a binary game; if you eliminate the viability of performing attacks given certain threat models (but not all of them), you raised the bar. There's no such thing as a "secured" system, just remember that Heartbleed affected versions of OpenSSL that "secured" numerous services "according to latest standards". If SSL3 is the biggest worry, it's actually a good sign.
    – dnet
    Apr 25, 2017 at 20:49
  • Well, if you want to approach it more rationally, sure, do not upgrade your systems as the POODLE attack just has a low CVSS rating anyway, and yeah you do use a strong cypher suite. The thing is, the technology is deprecated. Nobody is doing any active development on it. Current software is actually disabling/decommissioning support for it, or already has done over a year ago. Why would someone would take such risks? Basically it is comparable to using XP; sure you can configure it so it is (almost) safe to use, it still isn't a sane thing to do.
    – user258572
    Apr 26, 2017 at 21:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .