Crypto Talk at 27C3: Is the SSLiverse a safe place? Day 2, 16:00, Saal 2

SSL/TLS is the standard when it comes to securing HTTP traffic on the internet. The authenticity of a web server is usually secured using a X.509 certificate digitally signed by a trusted certification authority (CA). All major web browsers come with a list of CAs preinstalled they assume as trustworthy. Every website can be signed by any of these CAs, so no web browser would show a warning, if www.dod.gov would be signed by a Chinese certification authority or the Deutsche Telekom.

To examine the usage of X.509 certificates for SSL/TLS, the EFF installed a SSL Observatory:

The SSL observatory is a project to bring more transparency to SSL Certificate Authorities, and help understand who really controls the web’s cryptographic authentication infrastructure. The Observatory is an Electronic Frontier Foundation (EFF) project that began by surveying port 443 of all public IPv4 space. At Defcon 2010, we reported the initial findings of the SSL Observatory. That included thousands of valid ‘localhost’ certificates, certificates with weak keys, CA certs sharing keys and with suspicious expiration dates, and the fact that there are approximately 650 organizations that can sign a certificate for any domain that will be trusted by modern desktop browsers, including some that you might regard as untrustworthy.

I am looking forward to see some obscure SSL/TLS setups here. For example, SSL/TLS doens’t require the server to present a certificate, connections where no certificate at all are also supported, which only provide security against an passive eavesdropper. Also, the usage of encryption is an optional feature in SSL/TLS, so that both parties may send their traffic in clear, and use SSL/TLS only to prevent unauthorized modification of the data or to prove authenticity of the server. Also, the key in a certificate doesn’t need to be an RSA key, instead some public Diffie-Hellmann parameters or a DSA key might be embedded there too.

For those of you who would like to know why it is called SSL/TLS: SSL 1.0 was created by Netscape to secure HTTP traffic, but the standard was never released to the public. SSL 2.0 was the first version of SSL released to the public and implemented in the Netscape Browser. SSL 3.0 was the last version of SSL created by Netscape, before the IETF took over development. TLS 1.0 was the first version of SSL released by the IETF, which technically still carriers a version number 3.1 in the protocol header. While there are big differences between SSL 2.0 and SSL 3.0, the differences between SSL 3.0 and TLS 1.0 are only minor. The current version of TLS is version 1.2 (which still carries a version number 3.3 in the protocol header), which contains some security fixes and improvements over TLS 1.0. So we usually say SSL/TLS, when we refer to the SSL or TLS protocol, but not to a particular version of the protocol.

Personally, I am interested in this talk because I conducted a small SSL X.509 survey by myself back in 2007, when I implemented a TLS 1.0 stack in Java for the J2ME platform. Nowadays, this stack is included in the bouncycastle project, a Java cryptography provider, and can be run on J2ME as well as on J2SE or J2EE.

See the talk at Day2, 16:00 Saal 2!

Autor: Erik Tews