February 14, 2007
SSL Redux
I decided to turn to the specification for TLS in determining the feasibility of my proposed attack from the other day. I was a little bit wrong in an assumption about how SSLv3 and TLS work with regards to client certificates, although the attack still works with some slight modification.
Negotiation works by the client side generating a random number (called the premaster_secret), encrypting with the client's private key, and shipping it to the server. The server then decrypts the value using the client's public key, and can simultaneously verify the client's authority to access the server, as well as use the now-decrypted premaster_secret to start making shared secret keys between the client and server.
The client-cert-forwarding attack still works, though, because of browsers being silly. My web browsers (IE7 and Firefox 2.0.0.1) both prompt for my smartcard PIN precisely once. After that, they sign whatever client cert requests are asked of them by any trusted server that chooses to ask it. Trusted servers are just those servers that happen to have valid certificates (e.g. someone paid a few dollars to have Verisign generate a key for them). If the site has an invalid key, the client will still sign, so long as he/she clicks "Okay" on the invalid certificate box.
Assuming our intermediary server receives a connection from the client, the client will generate a premaster_secret and send it to the intermediary. The intermediary can then open a connection to the bank, or what-have-you, and use the same premaster_secret. It has the premaster_secret that the client used in both decrypted form (using the client's public key) and encrypted form (what it initially received from the client, prior to decryption)...there seems to be no reason that the intermediary couldn't do this.
To define the problem in a rigorous way that points fingers at the things that need to be fixed is a little complicated, because SSL is a little complicated surrounding client certificates. The real solution is still to do something like have the client encrypt the premaster_secret concatenated with the target server...his way the target server will know the premaster_secret, but won't be able to generate appropriate ciphertext for the bank. Of course, the protocol people might say something like the SSL-library implementors should change their ways and not blindly sign certificates for sites. I guess I'll find out...







by reid
on October 01, 2007
by reid
on July 17, 2005