User: Password:
Subscribe / Log in / New account

Certificates and "authorities"

Certificates and "authorities"

Posted Sep 11, 2011 1:40 UTC (Sun) by foom (subscriber, #14868)
In reply to: Certificates and "authorities" by Simetrical
Parent article: Certificates and "authorities"

>> Capturing a sites certificate not only allows you to _undetectably_ impersonate the site for the duration of the cert (or until its revoked), but it allows an attacker to decrypt all communications with that server _prior_ to the exploitation which they may have captured.

> If you can get root access to the web server, sure. In that case, why not just take over the webserver process itself?

The point is that taking over the webserver should not allow you to decrypt sessions that occurred *prior* to the takeover. Yet, because of the shoddy encryption most commonly used for SSL, that is exactly what you can do.

(Log in to post comments)

Certificates and "authorities"

Posted Sep 11, 2011 14:44 UTC (Sun) by Simetrical (guest, #53439) [Link]

I'm not familiar with SSL implementations to this level of detail, so I'll take your word for it. Regardless, this seems like only a minor additional level of compromise in the scheme of things. In most cases, such a breach will be pretty disastrous to start with, and lack of perfect forward secrecy doesn't make it that much worse. The fact that malicious governments can MITM sites like Gmail is an incomparably bigger issue.

Certificates and "authorities"

Posted Oct 18, 2011 20:54 UTC (Tue) by rich0 (guest, #55509) [Link]

The issue is that the SSL certificate is used to encrypt the session key and transmit it to the server. That means that the corresponding key can recover the session key (which is a requirement, since the server has to know the session key to talk to the browser).

If you capture the entire SSL session and later recover the key from the webserver you could go back and decrypt the session.

Note that a CA breach doesn't help with this - the key is stored on the webserver and is used to generate a CSR - it never leaves the server in a good implementation. Apache at least lets you store it encrypted on-disk as well (which requires providing the password when you start the web server).

I'm not certain this would work, but I'd think the way that you could prevent this attack would be to have the webserver not actually give the client its certificate, but instead generate and sign a new certificate for each connection, and then give that certificate to the browser. It would still have a valid trust chain so it would be usable, but it would have a different private key. The webserver would then discard that private key after the session is complete so that nobody could go back and decrypt the session. Right now server certificates cannot be used to sign additional certificates, so that would need to change to make this work.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds