Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm not talking about decrypting the connection while the SSL/TLS is happening (MITM) but after the connection is closed and I have a pcap file of the entire negotiation/data transfer process.

How can I decrypt the data that was passed in the connection? Is there a way to get the session key (without waiting a few years for the calculation process to end)? Will quantum computers help?

share|improve this question
4  
Depends. SSL & TLS together cover a huge range of ciphers. They all offer different degrees of strength, and sometimes different security guarantees (e.g. perfect forward security). –  user502 Oct 7 '11 at 13:09
    
    
@ThomasPornin, I do know how does TLS\SSL works and I've read your (great) comment before asking. I'm asking if time and computer power can change the story? I can see the whole session, I have the cipher and the public-key, what do I need to break the session key? –  YSY Oct 7 '11 at 13:50
3  
This looks a lot like a homework question - what is it you are trying to get to here that is different to the answers to the question @Thomas linked to? –  Rory Alsop Oct 7 '11 at 15:20

2 Answers 2

up vote 11 down vote accepted

The short answer is "no". The longer answer is that SSL is specifically designed to make this impossible. If this was possible, SSL would be useless for its primary intended purpose -- to secure things like credit card numbers sent to secure web sites.

The short (and technically incorrect) answer for how SSL does this is as follows:

  1. The server presents a certificate to the client.

  2. The client confirms that the certificate was signed by an organization the client trusts and that this organization certifies that the certificate belongs to the server the client wants to reach.

  3. The client generates a random key, encrypts it with the public key in the certificate, and sends it to the server.

  4. The server decrypts the key and uses the shared secret the server and client now have to secure further communications. (It does this in a somewhat complex way though. Again, this is an oversimplified explanation.)

Decrypting the data would require at least recovering the shared secret generated at step 3. But how would you do that? It was only sent over the wire encrypted, and you don't have the server's private key.

share|improve this answer
    
It’s not impossible. It’s just not possible with reasonable resources. –  Gumbo Oct 12 '11 at 13:23
    
That's what "impossible" means -- "unattainable with the means at command". Would you correct a general who said, "It's impossible to take that hill" on the grounds that if he had a million men he could take it? –  David Schwartz Oct 12 '11 at 13:32
    
Do proxy server have access to the keys? I'm trying to proxy calls to a certain ssl server. The call to my proxy server is not ssl but the relay to the target server is. Who stores the keys? The proxy server or the client? –  mabounassif Mar 24 at 1:35

It can be done, but it requires information beyond what you have on the wire. Wireshark has the ability to do this sort of sniffing, assuming it can see the entire conversation and you also have the private key of the server's SSL certificate. Without the private key it doesn't work.

This is why you need to protect your private keys.

I've used this functionality in debugging software. A client/server application used SSL to transmit data and something funny was going on in the network layer. Since I controlled the entire environment I had the private key for the SSL certificate, so was able to use Wireshark to get the conversation. Which in turn pointed to a bug that I reported to development.

share|improve this answer
    
True, you can decrypt SSL session if you have access to server's private key BUT also SSL connection should use RSA key exchange, not Diffie-Hellman. Otherwise even a private key will get you nothing. –  thor Nov 11 '12 at 19:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.