SSL security with server certificate compromised

Hello everyone,

This may be very obvious, but I would love to hear a clear explanation.

Let's say I configure a web server with HTTPS only. Then I issue a
couple of queries from a browser, while I sniff all the traffic out to
a file (even though is is encrypted). Finally, I hand you the sniffed
traffic AND the server certificate file (cert file, key file, even the
key phrase or password). Questions:

1. Can the sniffed traffic be decrypted, at least in theory, with all
the information in the scenario I am posing? My guess is "yes",
although I am not sure how to go about it.
2. If the traffic can be decrypted, is this a time consuming process,
or a pretty quick thing? Perhaps it is even trivially scriptable?

Thanks for any information and comments. Best regards.

Gonzalo Diethelm

Dear Gonzalo,

Gonzo wrote:
> This may be very obvious, but I would love to hear a clear explanation.
>
> Let's say I configure a web server with HTTPS only. Then I issue a
> couple of queries from a browser, while I sniff all the traffic out to
> a file (even though is is encrypted). Finally, I hand you the sniffed
> traffic AND the server certificate file (cert file, key file, even the
> key phrase or password). Questions:
>
> 1. Can the sniffed traffic be decrypted, at least in theory, with all
> the information in the scenario I am posing? My guess is "yes",
> although I am not sure how to go about it.

If you are given the private key as well, of course it can be decrypted.
That is the whole point of keeping private keys private :)
With HTTPS, first a handshake is done, and a unique session key is
established next to the exchange of public parts of the certificates
used. The encryption like any asymmetrical method, relies on a
sufficiently large encryption key based on all this data, that can be
decrypted by the client (web browser) quickly since the private part of
the key needed is known to the client.
More information on how HTTPS works can be found online easily.

> 2. If the traffic can be decrypted, is this a time consuming process,
> or a pretty quick thing? Perhaps it is even trivially scriptable?

In theory, every encrypted data stream can be decrypted given enough
time. That is why browsers quite quickly moved from 56-bit to 128-bit
encryption after the more widespread introduction of using SSL. It is,
even with "low-grade" encryption, still a time consuming process since
the way to find the right key would be to brute-force the private key to
decipher the data. For normal web use, 128-bits is quite sufficient but
like I said given enough time that can also be broken and decrypted. Not
easily though, and not simply by scripting something to run over a
captured stream.

HTH

Additional note: with a compromised server certificate, you have an
authentication problem only. A different site can successfully identify
itself as the original owner. It does not mean the encryption is at risk
to be sniffed out as that is still done against the client's keys.

Hi MC,

> If you are given the private key as well, of course it can be decrypted.
> That is the whole point of keeping private keys private :)
> With HTTPS, first a handshake is done, and a unique session key is
> established next to the exchange of public parts of the certificates
> used. The encryption like any asymmetrical method, relies on a
> sufficiently large encryption key based on all this data, that can be
> decrypted by the client (web browser) quickly since the private part of
> the key needed is known to the client.

Ok, I was aware that HTTPS entailed generating a session key the way
you are describing here.

> In theory, every encrypted data stream can be decrypted given enough
> time. That is why browsers quite quickly moved from 56-bit to 128-bit
> encryption after the more widespread introduction of using SSL. It is,
> even with "low-grade" encryption, still a time consuming process since
> the way to find the right key would be to brute-force the private key to
> decipher the data. For normal web use, 128-bits is quite sufficient but
> like I said given enough time that can also be broken and decrypted. Not
> easily though, and not simply by scripting something to run over a
> captured stream.

But this was the point of my question. You seem to be saying that,
having the encrypted sniffs, you can brute-force them eventually, and I
agree that this is (at least in theory) doable. What I am asking is:
does having the server public AND private key help you in any way to
decrypt the sniffed traffic? In other words, if I give you full sniffed
traffic for a couple of requests / responses, and ask you to decrypt
them, would it make any difference to you (faster, easier) if I also
hand you the server's public / private keys?

Best regards.

"Gonzo" <gonzalo.diethelm@gmail.com> writes:
> But this was the point of my question. You seem to be saying that,
> having the encrypted sniffs, you can brute-force them eventually, and I
> agree that this is (at least in theory) doable. What I am asking is:
> does having the server public AND private key help you in any way to
> decrypt the sniffed traffic? In other words, if I give you full sniffed
> traffic for a couple of requests / responses, and ask you to decrypt
> them, would it make any difference to you (faster, easier) if I also
> hand you the server's public / private keys?

the (symmetric) session key is generated by the client, encrypted with
the server's public key and then transmitted to the server ... the
server then is able to obtain the session key value by decrypting it
with the server's private key (aka, given that you have access to the
server's private key ... then you can also access all session keys for
SSL sessions with that server). given that you have the server's
private key ... you can decrypt the transmitted session key ... w/o
having to resort to any brute force.

for little topic drift, rfc 4772 announced today ... "Security
Implications of Using the Data Encryption Standard (DES)" which includes
discussion on brute-force attacks ... ref
http://www.garlic.com/~lynn/aadsm26.htm#16 Security Implications of Using the Data Encryption Standard (DES)

for various drifts ... lots of past posts mentioning SSL server digital
certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

and lots of past posts mentioning (general) exploits, fraud,
vulnerabilities, and/or threats
http://www.garlic.com/~lynn/subintegrity.html#fraud

and lots of past posts discussing catch-22 for proposed improvements
in the SSL server digital certificate infrastructure
http://www.garlic.com/~lynn/subpubkey.html#catch22

basically implications of proposals for validation of SSL server
digital certificate applications which add digitally signatures and
verifying the application digital signature by doing a real-time
retrieval of public keys onfile with the domain name infrastructure
..... aka basically a certificateless infrastructure
http://www.garlic.com/~lynn/subpubkey.html#certless

which could then lead to everybody doing real-time retrieval of onfile
public keys ... eliminating the requirement for any digital
certificates. a certificateless public key infrastructure proposal
from old 1981 email:
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network

a recent thread with discussion of some other SSL server issues/vulnerabilities
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2006v.html#51 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2006w.html#0 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2006w.html#4 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2006w.html#5 Patent buster for a method that increases password security

MC wrote:
> Additional note: with a compromised server certificate, you have an
> authentication problem only. A different site can successfully identify
> itself as the original owner. It does not mean the encryption is at risk
> to be sniffed out as that is still done against the client's keys.

That's not the way I read the standard
(http://developer.mozilla.org/en/docs...uction_to_SSL). The client
creates a premaster session key for encryption and encrypts this key
using the server's public key. The server decrypts the the premaster
session key with his private key. Then both the client and server use
the premaster key to generate the same list of session keys. So if you
have the server's private key then you can decrypt the premaster and
create all the session keys for the session. With that you can decrypt
the session just as fast as it occurred on the wire.

The client's and the server's public/private keys are only used to
authenticate and do key exchange. The session encryption uses the
agreed upon symmetric encryption algorithm.

dMn