0

After learning the theory behind cryptography I'm having quite some problems understanding how SSL or X509 certificates works in practise and I simply cannot find useful information in the internet.

To my understanding, a webserver needs an SSL certificate to proof to the client that he is who is claiming to be (e.g. www.company.com). Beside that, I assume that it is also used for exchanging a temporary session key for symmetric encryption (probably AES) by some asymmetric key distribution system like Diffie-Hellman?

In that case: Does the certificate which the webserver holds, contain multiple public keys for all these crypto systems, for example an RSA key for RSA Signatures, the DL parameters for Diffie-Hellman? Or does he need multiple keys (also for multiple key sizes?)

I would be extremely thankful if anybody could tell me what exactly happens (step by step), when a client is connecting to a https address. Thank you so much!

Bruno Rohée
  • 5,221
  • 28
  • 39
netik
  • 407
  • 1
  • 4
  • 6
  • 3
    It might be useful for you to read [How does SSL/TLS work?](http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work) and target any specifics you still don't understand after that. – gowenfawr May 19 '16 at 20:03

2 Answers2

1

No, there is only one public key in the certificate. Obviously the server should also have the private key that belongs to the public key in the certificate.

The session key is retrieved using key establishment. There are basically two ways:

  1. the master secret is generated and then encrypted by the client using the public key of the server, the server can now decrypt the master secret and derive the session keys;
  2. the master secret is derived using Diffie-Hellman key agreement, the frames required for the key agreement are then signed by the server using the private key and verified by the client to perform the authentication.
  3. in principle the certificate can also contain a static Diffie-Hellman key but in practice this isn't used (much); in this case the key agreement is automatically verified.

The session keys are then derived from the master secret using key derivation with the PRF (identified at the end of the ciphersuite).

Type 1. is used by cipher suites starting with e.g. RSA_. Type 2. is used by ciphersuites starting with ECDHE_ or DHE_. Type 3 is identified with ECDH_ or DH_.

In case of client authentication the client should also perform authentication of the exchanged frames.

TLS 1.3 will only allow type 2 key establishment as it only relies on signature generation for the certificate. Furthermore it provides forward secrecy because the ephemeral (temporary) DH keys are destroyed after the key establishment has been performed. This makes it impossible to break the key establishment itself, re-calculate the session keys and decrypt the encrypted frames with the plaintext within the session.

Maarten Bodewes
  • 4,562
  • 15
  • 29
0

You're not really asking about X.509 and certificates, but how they are used within the TLS handshake to arrive at a secure and authenticated AES session key.

I would recommend you study this page, which does an excellent job of explaining every step of the TLS handshake.

https://tls13.ulfheim.net/

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207