28

I want to ask if my below understanding is correct or not regarding the HTTPS used for the webpage we are visiting.

I will use Gmail as an example:

  1. My laptop tries to connect to the Gmail server and sends an http request
  2. Gmail server replies with a request to establish https connection instead (sends https request)
  3. My laptop checks the https certification of Gmail server and agrees to use https to connect
  4. My laptop finds the Public Key of Gmail server and uses it to encrypt my gmail account password and sends it to Gmail Server
  5. Gmail Server verifies my password by using the Private Key of Gmail Server and confirms my email logon
  6. Gmail Server sends email information to my laptop by encrypting it using my laptop's Public Key
  7. My laptop reads the encrypted email information by decrypting it using the Private Key of my laptop
  8. So on and so forth until my laptop logs out the Gmail server.

Summary: there are 4 keys involved in this https connection. Gmail Server Public/Private Keys (2pc) + My Laptop Public/Private Keys (2pc)

schroeder
  • 123,438
  • 55
  • 284
  • 319
Xianlin
  • 409
  • 1
  • 5
  • 7
  • According to the answer below, looks like there are 3 keys involved during the https process. 1 public key (gmail server), 1 private key (gmail server), 1 symmetric key (my laptop and gmail server). – Xianlin Apr 12 '12 at 04:49
  • 3
    D.W.'s answer below is perfect. One small point that was missing is that public key cryptography is *slow*, like really really slow. Encrypting your entire session that way would be very CPU intensive. That is why the public key part is only used to transfer a session key, which is then used in (much faster) symmetric cryptography, typically a block cipher such as AES operating in CBC mode. – lynks Dec 04 '12 at 10:06

1 Answers1

52

Yes, you're on the right track! But things actually work a little bit differently than you outlined.

In particular, Steps 4-8 are not quite how SSL works. SSL works a little bit differently. Here is how it actually works (I'm going to make some small simplifications, but this should get the gist of the idea right):

  • The Gmail server sends your client a certificate. The certificate includes the Gmail server's public key, and some evidence that this public key actually belongs to gmail.com.

  • Your browser verifies the evidence in the certificate, to confirm that it has the proper public key for gmail.com.

  • Your browser chooses a random new symmetric key K to use for its connection to Gmail. It encrypts K under Gmail's public key.

  • Gmail decrypts K using its private key. Now both your browser and the Gmail server know K, but no one else does.

  • Anytime your browser wants to send something to Gmail, it encrypts it under K; the Gmail server decrypts it upon receipt. Anytime the Gmail server wants to send something to your browser, it encrypts it under K.

Your Steps 1-3 are roughly right, though not exactly right, and the details depend a little bit upon what browser you use and what URL you type into the address bar or how you get to Gmail in the first place -- but what you wrote is close enough for understanding the basic concept. Good enough for government work.

Here is some additional reading for you:

How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it?

How do the processes for digital certificates, signatures and ssl work?

Purpose of certificates signed and trusted by CA

Why is faking SSL certificate difficult?

Why is HTTPS not the default protocol?

Is visiting HTTPS websites on a public hotspot secure?

I think those articles should give you an excellent understanding of SSL, how it works, and why it is designed the way it is.

If that's not enough, you must have more more more, here are some articles from Wikipedia:

How certificates work

How SSL works

However they probably have way more technical details than you ever wanted to know, and they aren't a great first introduction to the concepts or the basic ideas.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 2
    For browser differences: chrome has a built in list of google domains to ssl for, ssl-everywhere Firefox extension does similar for an EFF released list of domains. In either case one can skip steps 1 and go straight to 2. Also if you explicitly type https:// bookmark with that you are manually skipping step 1. – ewanm89 Apr 12 '12 at 14:02
  • 1
    Small addendum to otherwise great answer: gmail's certificate is [digitally signed](http://en.wikipedia.org/wiki/Digital_signature) by a certficate authority (CA). Your browser checks that it trusts the CA (browsers come with built-in list) and that the cert was properly signed. Given an message and a signature, anyone can check if the message/sig is valid; however without the CA's private key you cannot construct a valid sig for a modified message. The CA's job is to verify they only sign certs for the real google.com and its CA/google's responsibility to keep their private keys secret. – dr jimbob Apr 12 '12 at 20:27
  • I think gmail uses ECDHE if available, in which case this description doesn't fit what happens. – CodesInChaos Dec 04 '12 at 12:34
  • Great answer. Maybe add the indication that the main reason they create that symetric key (instead of each encrypting using the other's public key) is that the public keys encryption/decryption would be too slow (it's part of their strength), whereas the new symetric key's encryption/decryption is much faster (so it won't slow down the data exchange too much) – Olivier Dulac Dec 04 '13 at 10:12
  • @D.W., Re "*some evidence that this public key actually belongs to gmail.com*"; What are these *evidences*? – Pacerier Apr 12 '16 at 10:26