Question

To my great horror, I recently discovered that the SSL/TLS protocol that I until then had considered a safe choice for ensuring my users’ integrity, in fact suffers from several vulnerabilities, with exploits available (CAs in 2009, renegotiation exploit in 2009 and BEAST in 2011). Thus, it seems that several other minor vulnerabilities exist.

So the great question remains, what to do? As I have understood, the last two exploits I linked to above requires a fair amount of previously known information and then some guessing (BEAST) or can only partly exploit my “secured” connection, as it cannot actually decrypt the sent data (renegotiation). However, the methods still seems very, very threatening, and I doubt it’ll be long before hackers have added the exploits to their arsenals.

As an obvious countermeasure, I thought of adding an additional layer of encryption with Javascript to the extra sensitive parts of the webapps I take care of. I know a few good encryption libraries is coming up out there, so the encryption itself is not the issue. The issue, however, is that I’ve also read this fine article about Javascript as a cryptographic security measure, and it’s criticism of the method has made me wondering if additional security using Javascript is possible/sensible at all.

The thing is, that I think perhaps Javascript encryption anyhow could make things more secure, as at least the last two I linked to are man-in-the-middle attacks, so perhaps the extra encryption would ruin their attack (and I don’t know the SSL/TLS protocol well at all).

Do you think adding extra encryption with Javascript (to secured, controlled environments) would eliminate these threats?

EDIT:

I think the 3 answers so far has misunderstood me a bit. I know very well that a fully breached SSL/TLS connection renders any further Javascript encryption useless (as you point out – the Javascript itself would be compromised and presumeably altered). However, neither of the exploits I mentioned does – as I understand it – allow an attacker to fully compromise the connection immediately, especially not the renegotiation exploit. The question is more about if anyone who knows SSL/TLS well and the cryptocraphic difficulties of Javascript could shed some light on the issue of whether Javascript encryption could protect against these two specific exploits?

Still though, the conclusion I’m coming to is that it won’t add security. If anything because I’ve become doubtful that Javascript by itself is a language capable of doing cryptography properly (after reading a little more about cryptography best practices), primarily because of its lack of a secure random number generator. And then all the other fine reasons written about in the answers puts the final nail in the coffin to that idea.

Answer 1

Before thinking of adding an additional layer of encryption using JavaScript because SSL/TLS is allegedly broken, you should really understand what the issues you’ve mentioned about SSL/TLS really are. The information published in the general press (the links you’ve posted) can be a be simplified, misleading or sensationalistic.

Problems with certificates

This is not a vulnerability of SSL/TLS in itself, although it is important of course. Whatever new system you design will have to rely on an infrastructure to identify the remote party. The are a number of models for this (based on public key cryptography), mainly PKIs (a la X.509, see RFC 5280) and Web-of-Trust (a la PGP).

These problems fall into sub-categories:

• The host name for which the certificate has been issued is not checked properly (example with \0 that would pass for another host): that’s an implementation bug. As regrettable as it is, bugs are implemented regularly, sometimes in security-related code indeed. The design of SSL/TLS is not to blame here. The implementation of the host name verification is. (See RFC 2818 section 3.1 for HTTPS or RFC 6125.) This can be solved by fixing the bugs in the library/browser and upgrading to a fixed version. Failure to implement specifications properly will happen once in a while with any protocol, SSL/TLS or not. (Granted, the "clarity" of ASN.1 structures that make X.509 certificates doesn’t help…)
• The host name might not be displayed clearly in the browser. GUIs are an area that can be improved, but it seems difficult to educate users accordingly too. Attempts have been made, for example, to push for using Extended Validation certificates (green bar), but this may also have created some additional confusion (not without some clever marketing from those who benefit financially the most from EV certs).
• CAs can sometimes make mistake when issuing a certificate (or be compromised). Perhaps those CA certificates shouldn’t be in your browser in the first place.

The problems are not purely technical here. It’s more about how, as a human, you can check whether you want to trust the piece of information put in front of you (i.e. whether you believe the certificate is genuine and is that of the server you want to talk to).

I believe this problem doesn’t have a perfect solution. Trust is a very hard thing to model. This sort of situation could happen in any situation, not necessarily related with SSL/TLS or internet. (How many of your friends’s passports have you seen to check their names? Are they all genuine? Are you sure
they haven’t been issued after the authorities were given some false information?)

The implementations may not be perfect, and browser developers can work to fix bugs and improve GUIs. However, I don’t think any JavaScript add-on will fix any of this: you’ll still need a similar way to identify the remote party. There are browser add-ons that can partly help (e.g. by comparing to other cached copies of the certificate), but ultimately, it’s the user’s responsibility to choose whether or not to trust the identity of the server.

(The other weakness with this is that some developers don’t seem to want to understand that area too much: see the number of questions on SO asking how to disable certificate verification, to get rid of the warning messages. It’s a human problem too, if people want not to see the warning message.)

Renegotiation exploit (CVE-2009-3555) and BEAST

The renegotiation exploit was a protocol bug indeed, but this was fixed in RFC 5746. (It was argued at the time that it wasn’t purely an SSL/TLS bug, but that it was also an issue with how SSL/TLS interacts with the application protocol which it secures. It’s a problem that might have been averted if the HTTP stacks had been able to be notified of an SSL/TLS renegotiation, but this was a grey area and HTTP servers weren’t really designed for this anyway: too late and/or too big a task.) The problems regarding the fix have to do with deployment. It’s quite difficult to upgrade everyone at the same time. Encouraging people to upgrade to newer versions of TLS (and ditch SSL, actually) would help here.

BEAST is a problem (quite specific to browsers), but this can be fixed by a better configuration of the SSL/TLS stack, or by upgrading to more recent versions of SSL/TLS, again.

It seems here that SSL/TLS is victim of stagnation when it comes to version upgrades. This is of course more problematic than other pieces of software because the remote party (which may be an online customer you have never met) would often have to upgrade their version of SSL/TLS too.
I would say that, while it’s important (often for business purposes) not to exclude a number of users who can’t or won’t update their browser/OS, there comes a point where servers need to upgrade anyway.
Again, this is unfortunately not specific to SSL/TLS. Any sort of web development that needs to support IE6 will have similar problems (and it should be killed off…).

Again, I doubt very strongly that a JavaScript-based solution won’t suffer from similar problems (in particular, browser compatibility and version issues).