58

I have been reading on HTTPS, trying to figure out how exactly it works. To me it doesn't seem to make sense, for example, I was reading this

https://ssl.trustwave.com/support/support-how-ssl-works.php

And notice it says this in the page

Step 4: xyz.com will next create a unique hash and encrypt it using both the customer's public key and xyz.com's private key, and send this back to the client.

Step 5: Customer's browser will decrypt the hash. This process shows that the xyz.com sent the hash and only the customer is able to read it.

What I don't understand is, couldn't a hacker just intercept the public key it sends back to the "customer's browser", and be able to decrypt anything the customer can?

Thanks for any response

sarnold
  • 102,305
  • 22
  • 181
  • 238
Austin
  • 4,801
  • 6
  • 34
  • 54
  • 1
    Read http://en.wikipedia.org/wiki/Public-key_cryptography – nos Jun 05 '11 at 09:19
  • 3
    You might wish to learn from a [document with many more details](http://en.wikipedia.org/wiki/Transport_Layer_Security#Simple_TLS_handshake). The trustwave guide is strong on hand-waving, weak on information. – sarnold Jun 05 '11 at 09:20
  • @sarnold, agreed, it's not just "weak on information", it's actually incorrect in a few places. Without client-certs (out of scope here), there's no "customer's public key" (+ it's not used there with client-certs anyway). There's also of course some confusion between encryption and signing (when "encrypting" with the private key...). I can't figure out what they mean in step 3. – Bruno Jun 07 '11 at 13:11
  • 1
    In @nos's link to the wikipedia link, check the "A postal analogy" section; I read a lot before, and this was the analogy that made all things clear! – Emad Alashi Mar 03 '13 at 22:29
  • 1
    Pick some better and more detailed description. For example read [our article](http://www.eldos.com/security/articles/1948.php). – Eugene Mayevski 'Callback Jun 05 '11 at 09:31
  • 1
    Steps 4 and 5 are not correct. The hash is not encrypted or decrypted at all, but *signed* with the server's *private* key. The hash is only used to authenticate that the server owns the public key it sent. – user207421 Feb 07 '17 at 21:54

6 Answers6

121

Why is HTTPS required?

To verify whether the website is authenticated/certified or not (uncertified websites can do evil things). An authenticated website has a unique personal certificate purchased from one of the CA’s.

Who are CA’s (Certificate Authorities)?

CA’s are globally trusted companies like GoDaddy, GeoTrust, VeriSign etc who provide digital certificates to the websites.

What are public keys and private keys?

Keys are nothing but long random numbers used to encrypt/decrypt data.
Public keys are keys which can be shared with others. Private keys are meant to be kept private.

Suppose Jerry generates a private key and public key. He makes many copies of that public key and shares with others.
Now, others can only encrypt the data using the public key and that data can only be decrypted by the private key of Jerry.
Another approach is to use public keys to only decrypt the data and private keys to only encrypt the data.

How does a company get a certificate?

Website owner first generates a public key and private key, keeping the private key secret. He gives a Certificate Signing Request file (CSR) and his public key to the CA.
CA then creates a personal certificate based on CSR including domain name, owner name, expiry date, serial no. etc and also adds an encrypted text (= digital signature) to the certificate and finally encrypts the whole certificate with the public key of the server and sends it back to the website owner.
This certificate is then decrypted with the private key of the website owner and finally, he installs it on the website.

Note: That encrypted text is the digital signature of the CA. That text is encrypted by the private key of the CA and can only be decrypted by a public key of CA.
When you install your operating system or Browser, root-certificates from many trusted CA's like GeoTrust, VeriSign, GoDaddy etc. come with it. These root-certificates contain the public key of that CA provider which helps decrypt the signature.

HTTPS security can be split into 2 parts (Handshakes):

1. To validate the certificate of a website:

enter image description here

1) When you enter the URL www.Google.com, Google’s server gives its public key and certificate (which was signed by GeoTrust) to the Browser.

2) Now browser has to verify the authenticity of the certificate i.e. it’s actually signed from GeoTrust or not. As browsers come with a pre-installed list of public keys from all the major CA’s, it picks the public key of the GeoTrust and tries to decrypt the digital signature of the certificate which was encrypted by the private key of GeoTrust.

3) If it’s able to decrypt the signature (which means it’s a trustworthy website) then it proceeds to the next step else it stops and shows a red cross before the URL.

2. To create a secure connection (encrypts outgoing and incoming data) so that no one else can read it:

enter image description here

1) As I mentioned, Google sends its public key when you enter www.Google.com . Any data encrypted with this public key can only be decrypted by Google’s private key which Google doesn’t share with anyone.

2) After validating the certificate, browser creates a new key let’s call it Session Key and make 2 copies of it. These keys can encrypt as well as decrypt the data.

3) The browser then encrypts (1 copy of session key + other request data) with the Google's public key . Then it sends it back to the Google server.

4) Google’s server decrypts the encrypted data using its private key and gets the session key , and other request data.

Now, see, server and browser both have got the same copies of session key of the browser. No one else has this key, therefore, only server and browser can encrypt and decrypt the data. This key will now be used for both to decrypt and to encrypt the data.

5) When Google sends the data like requested HTML document and other HTTP data to the browser it first encrypts the data with this session key and browser decrypts the data with the other copy of the session key.

6) Similarly, when browser sends the data to the Google server it encrypts it with the session key which server decrypts on the other side.

Note: This session key is only used for that session only. If the user closes the website and opens again, a new session key would be created.

can't get enough of web? behind the scenes when u type www.google.com in browser

GorvGoyl
  • 42,508
  • 29
  • 229
  • 225
  • 7
    The session can and usually does persist across multiple TCP connections. The part about encrypting and sending the session key and decrypting it at the server is complete and utter rubbish. The session key is never transmitted at all: it is established via a secure key negoatiaon algorithm. Please check your facts before posting nonsense like this. RFC 2246. – user207421 Feb 07 '17 at 21:52
  • @EJP thanks for the input.. I'll cross verify and update the answer if it's true. – GorvGoyl Feb 08 '17 at 10:41
  • It's true. See RFC 2246. Fix it. – user207421 Mar 19 '17 at 23:28
  • @EJP according to RFC 2246 in some cases premaster secret key is used (apart from Diffie-Hellman) and shared which I suppose is the session key. Also, in this case, same master secret cannot be reused in a new session according to http://web.science.mq.edu.au/~len/comp347/review/website/resources/tls_explanation.pdf Please correct me if I'm wrong. – GorvGoyl Mar 20 '17 at 06:07
  • 3
    Well. this should be chosen as the best answer. Very detailed and lucid writing. – SimpleGuy Feb 14 '18 at 16:11
  • 3
    Good one Jerry. Very precise. Thanks. – Mona Apr 27 '18 at 03:01
  • 2
    Read it again. The premaster secret is not the session key. It is two steps removed from the session key. The session key is never sent. – user207421 Mar 12 '20 at 23:13
  • 2
    Can't anyone copy the encrypted digital signature of CA and create a fake certificate ? – alizeyn May 09 '20 at 13:24
  • I think @user207421 is right. Diffie-Hellman is used so both parties can get a shared secret/key without transmitting the actual key. The other very important thing is that all the handshake messages would be hashed and verified to help prevent MITM attacks. – Zack Light Jan 26 '22 at 07:38
28

What I don't understand is, couldn't a hacker just intercept the public key it sends back to the "customer's browser", and be able to decrypt anything the customer can.

First, understand that there are generally two steps of HTTPs communication.

1) Generate a shared symmetric key which can only be known between client and server, no one else knows it

2) With this shared symmetric key, client and server is able to safely communicate with each other without worrying about information being intercepted and decrypted by others.

So the question becomes, how can the client and server generate a secret shared key without being known by others in this open internet? This is the asymmetric algorithm coming to play, a demo flow is like below:

-- Client receives public key from server.

-- Client generates a key string "DummySharedKey" which will be later used as shared key, and encrypt it into "7$&^^%####LDD!!@" with server's public key, Man-in-the-middle may have the public key and might be able to intercept the encrypted data, but the data is useless to him as the data can only be decrypted by sever's private key.

-- Server receives the encrypted key string "7$&^^%####LDD!!@", and decrypt it into "DummySharedKey" with its private key

Above key exchange steps makes sure that only Client and Server can know the shared key is "DummySharedKey", no one else knows it.

So it's critical to understand that it is Client's responsibility to generate the shared key, NOT SERVER! (i think this is what confused you)

I also recommend you to take a look at this video which explains HTTPs very well. https://www.youtube.com/watch?v=JCvPnwpWVUQ&list=FLt15cp4Q09BpKVUryBOg2hQ&index=3

Frank Zhang
  • 800
  • 11
  • 11
  • 2
    The part about encrypting and sending the session key and decrypting it at the server is complete and utter rubbish. The session key is never transmitted at all: it is established via a secure key negoatiaon algorithm. Please check your facts before posting nonsense like this. RFC 2246. – user207421 Feb 07 '17 at 21:52
  • 6
    No one tells you how to politely reply?! – Frank Zhang Feb 08 '17 at 04:56
  • i have read the doc, it says session key is generated and transimited – Frank Zhang Feb 08 '17 at 05:27
  • 1
    Please quote the actual text that says so. It isn't there. The session key is never transmitted. Are you confusing it with the premaster secret, like everybody else here? – user207421 Mar 12 '20 at 23:17
21

What I don't understand is, couldn't a hacker just intercept the public key it sends back to the "customer's browser", and be able to decrypt anything the customer can.

Public/private key encryption is based on modulo arithmetics using prime numbers.

Such asymmetric encryption was only discovered in the mid-1970s. It is credited to Diffie and Hellman, and to Rivest, Shamir and Adleman. (Though, both actually rediscovered things already known by the British secret services.)

The wikipedia page on Diffie-Hellman has a detailed example of a secret key exchange through a public channel. While it does not describe SSL itself, it should be handy to make sense of why knowing a public key doesn't reveal the contents of a message.

You might also find this simple RSA example interesting.

Denis de Bernardy
  • 75,850
  • 13
  • 131
  • 154
5

I'm studying related topics and read several blogs like how-https-works and how-does-https-work-rsa-encryption-explained/.

I have summarized a sequence diagram based on my study and hope it can be helpful to someone who comes to this thread.

enter image description here

For more details, you can check the blog mentioned.

Eugene
  • 10,627
  • 5
  • 49
  • 67
1

I have written a small blog post around SSL Handshake between the server/client. Please feel free to take a look.

SSL Handshake

A small snippet from the same is as follows:

"Client makes a request to the server over HTTPS. Server sends a copy of its SSL certificate + public key. After verifying the identity of the server with its local trusted CA store, client generates a secret session key, encrypts it using the server's public key and sends it. Server decrypts the secret session key using its private key and sends an acknowledgment to the client. Secure channel established."

It also describes the symmetric/asymmetric encryption which is used for SSL certificates and data transfer once secure transport is established.

Abhishek Jain
  • 4,478
  • 8
  • 34
  • 51
  • I really enjoyed your post, it was quite clear. tks, – Carlos Alberto Apr 09 '16 at 19:38
  • The part about encrypting and sending the session key and decrypting it at the server is complete and utter rubbish. The session key is never transmitted at all: it is established via a secure key negoatiaon algorithm. Please check your facts before posting nonsense like this. RFC 2246. – user207421 Feb 07 '17 at 21:47
0

For detailed explanation of SSL, see https://www.ietf.org/rfc/rfc2246.txt

Here are the brief ideas of SSL to answer your question:

1) Using certificates to authenticate. Server certificate is a must and client certificate is optional (only when the server requests it). A certificate is like something to prove who you are and it also contains a public key for asymmetric encryption.

2) Using asymmetric encryption (with public key in the server certificate) to establish a shared symmetric key which is used to transfer data between client and server securely by symmetric encryption (for performance reason because symmetric encryption is faster than asymmetric encryption).

The shared symmetric key is established by exchanging a premaster secret from client side (encrypted with server public key) and is derived from the pre-master secret together with client random and server random (thanks @EJP for pointing this out in the comment):

master_secret = PRF(pre_master_secret, "master secret",
                           ClientHello.random + ServerHello.random)

We need the server random and client random to prevent replay attacks that an attacker can capture the previous session and replay it for the new session.

What I don't understand is, couldn't a hacker just intercept the public key it sends back to the "customer's browser", and be able to decrypt anything the customer can.

The hacker cannot decrypt the message since he does not know the server private key. Be aware that public key cannot be used to decrypt the message.

Khanh TO
  • 48,509
  • 13
  • 99
  • 115
  • 1
    There's no encryption with the customer's public key (who often doesn't even have a public key). That document is incorrect. – Bruno Apr 12 '13 at 08:55
  • In SSL communication, public key is used to encrypt private key (session key) and then use symmetric encryption to transfer data (for performance purpose because symmetric encryption is faster than asymmetric encryption) – Khanh TO Apr 12 '13 at 10:42
  • Yes, but it's not the client's public key. It's the server's. (The original article is wrong, so discussions about it are difficult...) – Bruno Apr 12 '13 at 10:45
  • This encryption and signing step is to transfer private key securely. After that the client and the server will use that private key to communicate. Note: private key is regenerated per session. – Khanh TO Apr 12 '13 at 10:45
  • private -> you probably mean shared/symmetric here. – Bruno Apr 12 '13 at 10:46
  • if server uses server's public key to encrypt, how can the client decrypt that when the client does not know server's private key? – Khanh TO Apr 12 '13 at 10:46
  • 1
    The *client* uses the server's public key to encrypt the pre master secret (in RSA key exchange mode). They then both have knowledge of the same master secret, which is then used to generate the same shared keys: http://tools.ietf.org/html/rfc5246#appendix-F.1.1.2 – Bruno Apr 12 '13 at 10:47
  • in symmetric encryption, only 1 key is used and also called private key (used in both encryption and decryption). in asymmetric encryption, 2 keys are used: public key and private key, and only private key can decrypt messages encrypted by the public key. – Khanh TO Apr 12 '13 at 10:49
  • In symmetric encryption, client and server indeed share the key, but it's called *shared* or *symmetric* key not *private* key. *Private* key refers to the private key in asymmetric encryption. – Bruno Apr 12 '13 at 10:50
  • ok, that's just how we call it. The idea of SSL is to use asymmetric encryption to establish a session – Khanh TO Apr 12 '13 at 10:54
  • 1
    Sure, SSL/TLS uses asymmetric crypto to establish a shared secret (and thus encryption keys for a symmetric encryption algorithm), but the client's *public* key (if there is one) is never used for encrypting anything in this context. – Bruno Apr 12 '13 at 11:12
  • What if we are using symmetric key encryption? Can a hacker intercept the symmetric key and decrypt the information? – daniely Apr 17 '14 at 19:48
  • @daniely: the hacker cannot intercept the symmetric key because the client and server use **asymmetric encryption** to transfer the symmetric key securely. – Khanh TO Apr 18 '14 at 13:51
  • @daniely: we cannot just use symmetric encryption without asymmetric encryption. If so, how can we transfer key securely? – Khanh TO Apr 18 '14 at 13:53
  • @KhanhTO **The symmetric key is never transferred at all.** It is *negotiated* by a key agreement algorithm. Everything you've written here about encrypting the session key is incorrect. Please check your facts before posting. RFC 2246. – user207421 Feb 07 '17 at 21:49
  • @EJP: Please have a look at this: `This message conveys cryptographic information to allow the client to communicate the premaster secret: either an RSA public key to encrypt the premaster secret with, or a Diffie-Hellman public key with which the client can complete a key exchange (with the result being the premaster secret.)`. From https://www.ietf.org/rfc/rfc2246.txt . It seems that we can use either RSA or Diffie-Hellman. – Khanh TO Feb 08 '17 at 11:44
  • I know what you said, and it's incorrect. The session key is never transmitted. RFC 2246 #8.1. The quotation you provide is about the pre-master secret, not the session key. – user207421 Feb 08 '17 at 21:57
  • @EJP: You're right. The session key is also derived from client random and server random to prevent replay attack. I recall that after many years out of school, thank you. – Khanh TO Feb 09 '17 at 11:52