6

Please note that this is not about how SSL communication happens between browser (I researched and understood it) and client but other aspects.

Using Digicert's SSL mechanism explanation I have understood how the data is encrypted between browsers and servers. Below is my understanding.

  1. Browser will send a request to the server to get some resource. Server checks if the protocol of the request is HTTPS, if so then it will send its certificate (this certificate is already signed by some CA (Certificate Authority, like Digicert)) in the response.
  2. Browser will check if the certificate is valid by validating looking up the signing authority in its valid CA pool.
  3. If the browser finds that this certificate is signed by a valid CA then it generates a session key and encrypts it using the public key present in the certificate.
  4. Browser will send this encrypted session key to the server and server will decrypt the session key. The server will send back an acknowledgment to the browser which would be encrypted using the session key.
  5. Above steps complete an SSL handshake and then secure communication starts between browser and server.

Questions:
Based on my above understanding:

  1. The browser will generate a session key and encrypt it using server's public key. But which encryption algorithm (or commonly called as cipher algorithm) will be used by the browser?
    • How is cipher selection determined, and will browser and server both use the same cipher/key size for encryption and decryption?
  2. Once SSL handshake is completed, all communication will be encrypted using the symmetric session key, but again which encryption algorithm will be used by the browser?
  3. Is the encryption algorithm used by browser in any way dependent upon certificate received from server?
    • Or is all encryption performed by the browser performed with the same cipher algorithm?
  4. Please correct me if I am wrong, the algorithm or cipher information is also present in the certificate? How does that information stored in the certificate?
    • While generating the certificate do I need to state which algorithm, how many bits encryption, padding etc.?

Based on the above answer I will have the most important question - suppose I am providing my server's private key to somebody so that he can monitor the SSL traffic for my server, then apart from providing him the private key what all other things I need to take care. And do I need to tell him the algorithm or cipher I am using at server?

RoraΖ
  • 12,347
  • 4
  • 51
  • 83
hagrawal
  • 215
  • 2
  • 11
  • Why in the world would you hand out your private key to a 3rd party? If it is a service, they will tell you what they need from you re: algorithms. – schroeder Aug 05 '15 at 20:32
  • I need it establishing a mechanism for my SSL traffic monitoring by only authorized person. – hagrawal Aug 05 '15 at 20:37
  • @hagrawal this is a thing where there are actually technical solutions -- basically, to do what you want, you can use a web server that takes care of the actual TLS communication, and then proxy the request to the actual, real web server that would normally serve the request. – Rens van der Heijden Aug 05 '15 at 20:43
  • For some cipher suites, having the private key is insufficient for eavesdropping. See https://en.m.wikipedia.org/wiki/Forward_secrecy – Neil Smithline Aug 05 '15 at 21:23
  • Your first steps 3 and 4 are not correct. The session key is not generated by the client; is not encrypted; is not transmitted; and is not decrypted. It is calculated independently by both peers via a key agreement protocol. – user207421 Mar 21 '17 at 04:19

3 Answers3

3
  1. The browser will generate a session key and encrypt it using server's public key. But which encryption algorithm (or commonly called as cipher algorithm) will be used by the browser?
    • How is cipher selection determined, and will browser and server both use the same cipher/key size for encryption and decryption?

The browser will send a list of cipher suites to the server that it supports. This answer will explain what a cipher suite is in detail, but basically a cipher suite is a list of algorithms to use for the secure communication. A cipher suite contains:

  • TLS Version
  • Key Exchange Algorithm
  • Signing Algorithm
  • Symmetric Encryption Algorithm
  • Integrity Algorithm

For example: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The browser sends a list of supported cipher suites to the server, and the server chooses the most secure cipher suite that it supports. If it doesn't support any in the list then the connection fails. The symmetric encryption algorithm is what the session key is used for. In SSL/TLS, keys are generated from the pre-master secret.

  1. Once SSL handshake is completed, all communication will be encrypted using the symmetric session key, but again which encryption algorithm will be used by the browser?

Again, the symmetric algorithm in the cipher suite will be used for the encrypted communication. In the example above it would be 128-bit AES in GCM mode.

  1. Is the encryption algorithm used by browser in any way dependant upon certificate received from server?
    • Or is all encryption performed by the browser performed with the same cipher algorithm?

It is in no way dependent on the certificate. All encryption is performed by the symmetric encryption algorithm in the cipher suite chosen by the server.

  1. Please correct me if I am wrong, the algorithm or cipher information is also present in the certificate? How does that information stored in the certificate?
    • While generating the certificate do I need to state which algorithm, how many bits encryption, padding etc.?

The algorithm and cipher for the secure communication is not in the certificate, but as stated above within the cipher suite chosen by the server. The certificate only contains information relating to the certificate itself. Which includes, but not limited to, validity information, signing algorithm, issuer information etc.

Based on the above answer I will have the most important question - suppose I am providing my server's private key to somebody so that he can monitor the SSL traffic for my server, then apart from providing him the private key what all other things I need to take care. And do I need to tell him the algorithm or cipher I am using at server?

I would highly recommend not providing your server's private key for SSL traffic monitoring (for reasons outside the scope of this question). However, if you do decide to share your private key the other party doesn't need any other information. As the algorithm and cipher are not included in the certificate.

RoraΖ
  • 12,347
  • 4
  • 51
  • 83
2

Super short answer: The server and client negotiate what algorithm they support and subsequently use. It is communicated during the handshake.

schroeder
  • 125,553
  • 55
  • 289
  • 326
  • I'd like to add here, to answer question 4, that the algorithm and cipher for the certificate are set during certificate generation. Padding is defined in TLS, and there is no padding needed for the certificates (they have a length field). – Rens van der Heijden Aug 05 '15 at 20:38
  • @schroeder So, how browser and server negotiate the algorithm, key size etc. to use? My understanding was that this information should be in the SSL certification along with the server's public key. But now I am reading about ciphersuites which gives me impression that this agreement/negotiation is done separately and not using SSL certificate. Could you please throw light? – hagrawal Aug 05 '15 at 20:41
  • @RensvanderHeijden But are they really used for encryption? I doubt it because now I am reading about ciphersuites which gives me impression that this agreement/negotiation is done separately and not using SSL certificate. – hagrawal Aug 05 '15 at 20:42
  • @hagrawal no, they are not used for encryption -- those in the certificate are the algorithms used to generate and verify the certificate. Also, it is not so much a negotiation, but more of a specification -- the verifier of the certificate is not involved in this process, and if the browser does not support a specific algorithm (e.g., SHA1, which is being phased out over the next couple of years), they cannot check the certificate. – Rens van der Heijden Aug 05 '15 at 20:44
1

Not an answer (@raz got that) but some errors in your "understanding" too large for comments IMO:

Browser will send a request to the server to get some resource. Server checks if the protocol of the request is HTTPS, if so then it will send its certificate (this certificate is already signed by some CA (Certificate Authority, like Digicert)) in the response.

The SSL/TLS handshake occurs before the browser sends the request, so the request (including URL) is encrypted. See If SSL encrypts urls, then how are https messages routed? and Does SSL/TLS (https) hide the urls being accessed

The browser checks the scheme first, and (normally) connects to port 443 for https instead of 80 for http. For modern servers that support multiple "virtual hosts" on one IP address, the browser can and usually does send the host part of the URL in an extension called Server Name Indication (SNI) so the server can select the correct certificate(s) for the desired host.

Browser will check if the certificate is valid by validating looking up the signing authority in its valid CA pool.

As the Digicert page correctly says, the browser checks the cert is signed by a CA in its local store and is unexpired, unrevoked, and [for the correct host]. The page is out of date in one respect: nowadays practically all certs from public CAs like Digicert use the more flexible SubjectAlternativeName extension (often abbreviated SAN) rather than the CommonName element of the Subject field to specify the host name(s). The effect is basically the same.

[If okay the browser] generates a session key and encrypts it using the public key present in the certificate.
Browser will send this encrypted session key to the server and server will decrypt the session key. [...]

This is oversimplified and becoming obsolete. The original "RSA" key-exchange method does use RSA encryption, but the value chosen and encrypted by the client is not "the" session key but a premaster secret that contributes to the multiple session keys: see https://crypto.stackexchange.com/questions/1139/what-is-the-purpose-of-four-different-secrets-shared-by-client-and-server-in-ssl .

Also today it is becoming more common to use (several variants of) Diffie-Hellman which can provide forward secrecy as commented by @Neil; see How does SSL/TLS work? . The example ciphersuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 in @raz answer uses Ephemeral Elliptic-Curve Diffie-Hellman (ECDHE) key-exchange authenticated by RSA. This does NOT encrypt and decrypt the premaster with RSA; instead the client and server independently choose random element orders in a subgroup of an elliptic curve and mathematically combine them to produce the premaster.

Community
  • 1
dave_thompson_085
  • 10,064
  • 1
  • 26
  • 29