9

I want to understand how certificates add to the security of information exchange.

Suppose i have a encrypted bidirectional connection between Alice and Bob, using a public key/private key pair. As long as i confirm by secure channels that the public key actually belongs to the expected end of the tunnel, i have secured the connection from MITM.

What security do certificates bring to the table? In theory i need a certificate from a CA itself in order to be sure that further certificates from this CA are from actually the same CA

Another doubt; its stated also that SSL/TLS supports perfect forward secrecy because IKE happens at regular intervals; i don't understand how this allows perfect forward secrecy at all; it seems that if you save all the packet exchange between two endpoints and you happen to brute-force a send-receive key, this will expose all IKE happening during that session. Probably this could be alleviated by doing IKE over several sessions, that is, exchanging each key under multiple session keys, which means you need to crack more than one key to get to other keys

EDIT i've added a follow up question here.

Samuel Reid
  • 103
  • 4
lurscher
  • 1,200
  • 1
  • 10
  • 14
  • For the IKE question, are you confusing SSL with IPsec? – nealmcb May 07 '11 at 05:33
  • 1
    We have many questions on SSL and its flaws/caveats. E.g. check out http://security.stackexchange.com/questions/5/does-an-established-ssl-connection-mean-a-line-is-really-secure and see if you still have a question here. – nealmcb May 07 '11 at 05:36

2 Answers2

9

Yes, MITM attacks are thwarted if you can make sure that you use the right public key. Certificates are a public key distribution method which allows precisely that.

The point of the certificates is that you just need to "know" the CA public key in order to be able to verify all certificates that the CA has issued -- there can be millions of those, and it also works on the certificates that the CA will issue next week. So while certificates do not totally remove the need for a source of trust (an a priori known public key), they sufficiently concentrate that need so that the practical problem of key distribution is solved.

Gaining confidence in a public key can be done through other schemes than certificates; for instance, SSH does it by caching (you trust the server public key because you can verify that it is the same key than the last time you contacted it; in a way, SSH realizes timewise trust concentration, whereas certificates do it spacewise).

Perfect Forward Secrecy is achieved with SSL when you use the 'DHE' suites -- for "Diffie-Hellman Ephemeral". The important word here is "Ephemeral": the actual private keys which protect the session symmetric key are dynamically generated, and never stored (these are Diffie-Hellman keys); therefore, those keys are supposed to be immune to disclosure. The keys which are stored (e.g. in a private key file) are used only for signatures, so stealing them does not give the ability to decrypt past conversations (it gives the ability to impersonate the server for ulterior conversations, though). PFS is not about actual key breaks, but about key stealing, which is, in practice, a much more plausible attack path. The DHE cipher suites ensure PFS by never storing the key exchange private keys.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1
    thanks! you addressed precisely my source of confusion: that stealing private keys don't give ability to decrypt past conversations. However, i still don't understand how are these dynamically generated keys being exchanged? i suppose the public version of a pair of asymmetric keys are being exchanged only? – lurscher May 07 '11 at 23:12
  • 2
    @lurscher: lookup Diffie-Hellman, e.g. there: http://en.wikipedia.org/wiki/Diffie-Hellman -- both parties combine their private DH key with the DH public key from the peer, and the DH magic is that they both end up with the same value, which is inaccessible to third parties who only see the public keys. – Thomas Pornin May 08 '11 at 12:10
7

What security brings certificates to the table? In theory i need a certificate from a CA itself

Yes, a (huge) number CA certificates are already present in your browser by default. This still leaves the initial boot strap issue for when you download the operating system which includes the browser (or the certificates for the distribution package system which is used to download the browser).

I think such a compromise is easier noticed than a CA in that list signing a bogus server certificate, unless it is a high profile site as in the linked case.

Another doubt; its stated also that SSL/TLS supports perfect forward secrecy because IKE happens at regular intervals

Please note that while SSL supports perfect forward secrecy, it is commonly disabled for performance reasons.

The security property is not based on the frequent generation of new session keys, but on the usage of Diffie-Hellman for key exchange.

DH allows the negotiation of a secret key over an insecure line, if the attacker can neither modify the content nor destination of both ends of the data stream. The linked Wikipedia article has a very good explanation of how DH works. It is understandable with little mathematical background knowledge.

The idea behind perfect forward secrecy is to prevent an attacker from decoding an old recorded data stream in the future, when the private key may be compromised. The certificates ensures that Alice is talking to the correct Bob. Therefore the requirements of DH (no modification, no wrong target) are met in the PFS scenario.

Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121