SSL vulnerabilities – WikiLeaks

[Pedro]

As other people have commented on here SSL is well-known as a vulnerable protocol and the recent WikiLeaks revelations have affirmed this:

DO NOT solely rely on SSL/TLS to secure data in transit. 

Rationale: Numerous man-in-middle attack vectors and publicly disclosed flaws in the protocol.

Are AxCrypt planning to use SRP so that the server and client can prove their identity without transmitting any secrets?

More coverage by Bruce Schneier.

[SvanteSpectator]

Hello Pedro,

It’s always hard to separate conspiracy theory from real vulnerabilities in these scenarios. Our current view is that SSL/TLS is a good choice for AxCrypt. Better the devil you know, than the one you don’t, is part of it. We’re aware of various issues with SSL/TLS but we believe they are not generally relevant to our situation.

We currently have no plan to use SRP or any other mechanism, for establishing a secure connection between client and server.

Of course, this may change, but that’s the current viewpoint.

[Pedro]

Okay, thank you for the reply.

The leaked information was from the CIA and they were recommending their programmers not rely solely upon SSL. It’s not really a conspiracy theory because it has been proven insecure repeatedly.

Because AxCrypt transmits the password to the server then anybody in a privileged position could log the password and gain access to your files. This assumes that you’re using AxCrypt to share files or upload them to the cloud (if they’re local files then they’re secure, but other tools address full disk encryption better than AxCrypt).

Therefore the core users: cloud uploaders and emailing sharers may be prejudiced by these vulnerabilities in SSL ;-(

[SvanteSpectator]

Hello Pedro,

Yes, I read the list, and much of it is indeed sound advice but it must be taken in context.

The truth is far from “anybody in a privileged position could log the password“. That’s simply not true. Period.

The various leaks and errors made in SSL have been adressed one after another, as they are revealed. That’s not to say there aren’t any more – but it is to say it’s not that easy to design a secure protocol and I’d much rather use a well-known fixed protocol, than a less used and less analyzed, and less fixed protocol. Even worse – make up my own.

That a protocol has no known leaks does not mean it’s secure. That’s the problem with security. You can’t typically prove security, only demonstrate insecurity.

Properly used SSL/TLS is still trusted to protect a majority of world secrets, and world economic assets – and in general does a pretty good job of it, since both you and me and perhaps a billion of other users still have our money in our respective bank accounts without it being stolen by way of a hacked SSL/TLS connection with our banks for example.

The incentive to successfully hack and intercept an arbitrary SSL/TLS connection in economic terms is absolutely gigantic. It hasn’t happened. That’s one reason I trust SSL/TLS for AxCrypt use.

If, however, you have any indication that we’re not using SSL/TLS properly (no one is perfect) – please let us know and we’ll fix it immediately.

[Pedro]

Again, thank you for your reply.

SSL can be logged by somebody in a privileged position: AV scanners, corporate firewalls, Superfish-style vulnerabilities to name but a few.

SSL on its own isn’t used to protect world secrets; it’s used in conjunction with other protocols – normally E2E encryption in addition to SSL.

I’m not advocating you roll your own encryption; that’s a terrible idea even for an experienced cryptographer. I am suggesting that you consider an additional, peer-reviewed protocol like PAKE, in addition to SSL.

Regarding this site, take a look at your Qualys report. The site scores an F – the lowest possible. A+ is the best possible mark.

 

[SvanteSpectator]

Hello,

No, SSL cannot be intercepted by anyone in a privileged position – unless you by that mean you, yourself or someone else with administrator permissions on your local PC who can install any certificate in your certificate store to mount a man-in-the-middle attack. But this entity does not need to break into SSL! Anyone with admin permissions on your system can get at your secrets there in a number of easier ways. Corporate firewalls cannot terminate an SSL-connection without you being aware of this, and if they instead mount a MITM “attack” we’re back at previous argument. A trusted root certificate needs to be installed in your device.

SSL *is* used to protect both secrets and economic resources. Very few will use VPN to connect to their Internet bank.

You have tested the wrong site, http://www.axcrypt.net – no secrets are ever passed to that server (that being said, we’re in a continuing discussion with our hosting provider about that. It’s a known issue, but not really relevant to this discussion).

The correct site account.axcrypt.net , which currently receives a ‘B’ rating, due some minor issues that may be caused by the user having older browsers. This is a tradeoff between what users are allowed to connect. If we set up too strong a cipher suite, some users with older browsers can’t even connect. Users with modern browsers will not use the older problematic ciphers. But thanks, we’ll take another look at this and see if we can setup a suitable cipher suite giving us the ‘A’ rating, without locking out users.

Adding another layer of security may, or may not, increase the level of security. We may indeed do so in the future but adding layers also increases complexity and difficulty of analysis. Peer review is great – but it’s not a guarantee. There have been problems found in just about any protocol ever published, and the advantage of SSL/TLS is that there are literally thousands of researchers trying to find flaws, and publishing when they do. And they’ve been doing this for a long time.

Better the devil you know, than the devil you don’t still applies.

[Author]

Posts