9

I do understand the cryptography basics, but I am uncertain about the following three steps:

Step 1: How to compute a TLS certificate

Correct me if I am wrong: The certificate authority computes a hash value over the relevant certificate information (including the public key of the certificate aplicant), then it signs this hash value using the private key of the authority. The output of this process is a single certificate file that can be deployed on servers which have access to the corresponding private key.

Step 2: How to verify that the server owns the private key corresponding to the TLS certificate?

The client gets the certificate from the server during the TLS handshake. But the certificate alone is not sufficient to verify data authenticity. (since anybody could send a copy of a certificate without owning the private key) Therefore I think that there must be some additional random information transmitted, which needs to be signed using the corresponding private key (perhaps also by computing a hash)?

Does the client decrypt this random information with the certificate's public key? How is this check performed?

Step 3: How to verify that the certificate is signed by a trusted authority?

I think this works mainly with preinstalled browser tables that contain the public keys of the trusted authority's (among other information).

Are the certificate authority's public keys used to decrypt a hash value and check if it matches with a self-computed hash value over the whole certificate?

Mike76
  • 283
  • 1
  • 2
  • 9
  • 3
    We have been there before, this is a dupe of http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work , (it is really hard to give more detail than what was given in the top two answers there). – grochmal Oct 08 '16 at 18:53
  • 1
    I only have three specific questions, it would be nice if someone could address exactly these questions – Mike76 Oct 08 '16 at 18:54
  • 1
    I just refactored this question to make it more specific – Mike76 Oct 08 '16 at 18:55
  • Hmm... your title is still very misleading. The rest of the question is a huge improvement though. – grochmal Oct 08 '16 at 18:57
  • I also changed the title and made the text shorter, now it is not a duplicate anymore – Mike76 Oct 08 '16 at 19:01
  • The question you linked as duplicate is a broad overview of TLS, while this question is now far more specific – Mike76 Oct 08 '16 at 19:08

1 Answers1

8

An answer to question 1:

Yes, except the CA's root is offline in an HSM in a vault, not available to be stolen electronically. The root was used to sign a handful of intermediate certificates (backups and OCSP responder certificates and other stuff) that reside in HSMs that are directly connected to computers that can be reached electronically.

To issue a certificate, the CA "backend":

  1. receives CSR
  2. uses some method of validation (ACME protocol, human clicking "ok" on admin website, etc.)
  3. logs all the decisions and info used to make the decision for checking by later audit
  4. generates the certificate data (X.509 v3) encoded in X.690 DER, using a template and new serial number / source of randomness.
  5. maybe gets Certificate Transparency SCTs.
  6. asks the HSM to sign the blob (or hash of the blob).
  7. appends signature to certificate and sends it to the customer facing storage.

An answer to question 2:

In RSA key exchange, the client generates a random sequence of bytes and performs RSA encryption using the public key from the server's certificate. Then the client sends the resulting ciphertext to the server and expects the server to decrypt it (using the private key corresponding to the public key from the certificate) and use the random value in a KDF, together with other values, to generate symmetric keys and send a Finished message encrypted with the resulting symmetric keys. The client verifies the Finished message. The server can only succeed in generating the expected symmetric keys by decryption RSA encrypted message. https://www.rfc-editor.org/rfc/rfc5246#appendix-F.1.1.2

In DHE/ECDHE key exchange with PFS, the server signs its ephemeral key using the private key corresponding to the public key in the certificate and sends this in ServerKeyExchange. The client verifies the signature using the public key from the certificate. https://www.rfc-editor.org/rfc/rfc5246#appendix-F.1.1.3

An answer to question 3: The browser contains a list of trusted roots (Mozilla Firefox does this) or uses a list of trusted roots provided by the operating system (Google Chrome uses the OS roots store). The root store contains self-signed certificates and some metadata about them that might constrain what they can be used for. Browsers also contain code that adds additional checks, like Chrome requiring Certificate Transparency from Symantec-owned CAs and the cutoff dates that allow using SHA1 certificates.

The way a leaf server/domain certificate is verified using the root store is by building a chain of intermediate certificates, one signing the other, from a trusted root to the leaf. The root signs an intermediate and the intermediate signs the leaf. There can be more than one intermediate in a chain. The intermediates are sent by the server together with the leaf. https://en.wikipedia.org/wiki/Certification_path_validation_algorithm

Different computers have different root stores and by using cross signing, many different paths can be built. Currently the browsers try to build sha256-only paths if possible, sometimes fail and produce an error saying only a sha1 path was built thus the connection might be insecure.

Do not confuse digital signatures with encryption: https://security.stackexchange.com/a/87373/70830

Community
  • 1
Z.T.
  • 7,768
  • 1
  • 20
  • 35
  • 1
    Thanks for your this great answer. I assume that generating symmetric keys directly from the long-living RSA keys is a serious security breach, so there should always be a mechanism like Diffie Hellmann in place. Is DHE/ECDHE the only common way to guarantee perfect forward secrecy? – Mike76 Oct 08 '16 at 19:45
  • 1
    @Mike76 Yes, TLS 1.3 banned non-PFS key exchanges for a reason. Diffie Hellman is the only way I know to get PFS. DH can be implemented using many different underlying mathematics operations. Currently deployed are classic DHE, ECDHE over NIST P-256 (and other curves, but this is the popular one), ECDHE over curve 25519, Ring-LWE (https://security.googleblog.com/2016/07/experimenting-with-post-quantum.html). – Z.T. Oct 08 '16 at 19:51
  • I wonder if PFS could also be achieved by creating temporary RSA key pairs on both communication sides. Client and server would only need to transmit their public keys to each other, and the private keys could be purged after the session is over. I must have some error in reasoning with this thought? EDIT: The private key could be already purged once the symmetric key is established – Mike76 Oct 08 '16 at 19:58
  • 1
    @Mike76 Yes, kinda like the 512bit RSA keypair that was used in 90s export-grade broken crypto. Server can create new strong ephemeral RSA key pair for each handshake, sign the ephemeral public key with its long-term key, send the the ephemeral public key + signature to the client, the client will encrypt some entropy with the ephemeral public key and send the ciphertext to the server. It looks secure to me (I Am Not A Cryptographer!), but generating good RSA key pairs is slow, so throughput of handshakes will be bad (pregenerating ephemerals is insecure, how to verify?). – Z.T. Oct 08 '16 at 20:09
  • So using Diffie Hellmann seems not to be absolutely necessary for perfect forward secreny, but rather the best choice in terms of performance – Mike76 Oct 08 '16 at 20:13