Some discussion on SSL and its protocol flaw

A flaw in the SSL protocol was discovered several weeks ago. You haven't heard about it until now because the parties working on fixing it signed NDAs, which (for now at least) seems to have been a good idea.

SSL and TLS were designed to allow for computers to communicate with each other securely over insecure links, giving privacy and authentication even if the links are controlled by an enemy. Without going through the details, for all practical purposes, SSL and TLS are similar with minor differences, and I will use them interchangeably in this blog post.

If someone controls your link to the Internet -- or even just a significant portion of it -- they can redirect your supposed connection to http://paypal.com to their own server. But with SSL, the real paypal.com has secret information that it can use to prove that it is who it really says it is. When your browser was installed on your computer, it came with a set of "certificate authorities" that are used to prove that paypal.com has that secret information. A hostile https://paypal.com won't have that same information.

(All that is great in theory but has had problem in practice. The certificate authorities that your browser trusts have sometimes approved certificates that they should not have. And the end user too often ignores warnings when the secret information does not match. Those are serious issues but not the problem this time.)

Within a TLS connection, there are one or more TLS sessions. The client can switch among these sessions, each of which has its own security.

This new vulnerability appears related to the renegotiation phase of TLS, which allows for changing the state of the encryption tunnel. There are patches circulating for OpenSSL (a popular open source SSL implementation) to disable renegotiation, although some applications may require it.

One scenario depends upon client certificates, which are used when you want to automatically prove you who are to the server. This is hardly ever used in every-day web browsing or even secure web sites, because the technique of using some kind of username/password scheme is used instead. They may be used for specific web applications or within organizations, however. At this time, both Apache and Microsoft IIS are vulnerable.

Another method, not dependent upon client certs, does injection of specific HTTP requests. Generic defenses against XSS and CSRF attacks may work here, although I haven't investigated fully enough to say this for sure. If the MITM attacker can read arbitrary pages -- or use a separate attack to see the data -- then those defenses won't help.

Because of the broad nature of this vulnerability and the presence of a private working exploit, we would recommend that you keep a close watch on this SSL vulnerability. Please also review the SSL-based solutions that you are using in your own networks and that of your clients, so that you are prepared to update them when updates are available.