Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I've often heard it said that if you're logging in to a website - a bank, GMail, whatever - via HTTPS, that the information you transmit is safe from snooping by 3rd parties. I've always been a little confused as to how this could be possible.

Sure, I understand fairly well (I think) the idea of encryption, and that without knowing the encryption key people would have a hard time breaking the encryption. However, my understanding is that when an HTTPS connection is established, the encryption key is "discussed" between the various computers involved before the encrypted connection is established. There may be many factors involved in choosing an encryption key, and I know it has to do with an SSL certificate which may come from some other server. I do not know the exact mechanism.

However, it seems to me that if the encryption key must be negotiated between the server and the client before the encryption process can begin, then any attacker with access to the network traffic would also be able to monitor the negotiation for the key, and would therefore know the key used to establish the encryption. This would make the encryption useless if it were true.

It's obvious that this isn't the case, because HTTPS would have no value if it were, and it's widely accepted that HTTPS is a fairly effective security measure. However, I don't get why it isn't true. In short: how is it possible for a client and server to establish an encrypted connection over HTTPS without revealing the encryption key to any observers?

share|improve this question
+1 very nice question –  Louis Rhys Aug 16 '11 at 1:47
Watch 1. SSL explained - youtube.com/watch?v=a72fHRr6MRU and 2. What is HTTPS? - youtube.com/watch?v=JCvPnwpWVUQ –  claws Dec 14 '11 at 22:50
add comment

8 Answers

up vote 177 down vote accepted

It is the magic of public-key cryptography. Mathematics are involved.

The asymmetric key exchange scheme which is easiest to understand is asymmetric encryption with RSA. Here is an oversimplified description:

Let n be a big integer (say 300 digits); n is chosen such that it is a product of two prime numbers of similar sizes (let's call them p and q). We will then compute things "modulo n": this means that whenever we add or multiply together two integers, we divide the result by n and we keep the remainder (which is between 0 and n-1, necessarily).

Given x, computing x3 modulo n is easy: you multiply x with x and then again with x, and then you divide by n and keep the remainder. Everybody can do that. On the other hand, given x3 modulo n, recovering x seems overly difficult (the best known methods being far too expensive for existing technology) -- unless you know p and q, in which case it becomes easy again. But computing p and q from n seems hard, too (it is the problem known as integer factorization).

So here is what the server and client do:

  • The server has a n and knows the corresponding p and q (he generated them). The server sends n to the client.
  • The client chooses a random x and computes x3 modulo n.
  • The client sends x3 modulo n to the server.
  • The server uses his knowledge of p and q to recover x.

At that point, both client and server know x. But an eavesdropper saw only n and x3 modulo n; he cannot recompute p, q and/or x from that information. So x is a shared secret between the client and the server. After that this is pretty straightforward symmetric encryption, using x as key.

The certificate is a vessel for the server public key (n). It is used to thwart active attackers who would want to impersonate the server: such an attacker intercepts the communication and sends his value n instead of the server's n. The certificate is signed by a certification authority, so that the client may know that a given n is really the genuine n from the server he wants to talk with. Digital signatures also use asymmetric cryptography, although in a distinct way (for instance, there is also a variant of RSA for digital signatures).

share|improve this answer
I really like this answer. Is it technically accurate with regards to SSL? If it is, I'm tempted to mark it "most helpful". Gowenfawr's answer is also very helpful and has a lot more votes, but since it has "mangled details" I wonder if this answer is more accurate. –  Joshua Carmody Aug 16 '11 at 14:54
I skipped a lot of details, e.g. the "3" exponent can be another value (traditionally 65537) which is considered to be part of the public key. Also, there is padding at some point (the random value that the client chooses is smaller than x; x results from applying a relatively simple transform). Apart from that, this is how it goes in most SSL connections (the key exchange algorithm is negotiated at the start, but in most deployed SSL servers and client this ends up with RSA, as I describe, and not Diffie-Hellman). –  Thomas Pornin Aug 16 '11 at 15:00
One small tweak - in SSL/TLS - the X of this explanation is actually the "pre master secret", it's used by both the client and the server to generate the "master secret". Then another computation is done to create the "key block" which is a way of generating enough output based on the master secret and a series of random inputs to create the symmetric key needed for the selected symmetric cipher. This is really a small nit since it is pretty linear - if an attacker had the pre-master secret and the in-the-clear hello messages, he'd be able to listen in. –  bethlakshmi Aug 16 '11 at 16:10
How do you work out x given x cubed modulo n and p and q? –  Justin Feb 24 '12 at 9:46
@Justin: short version: you compute d, the inverse of 3 modulo phi(n) where phi(n) = (p-1)(q-1). Then, you do a modular exponentiation of x<sup>3</sup> modulo n, with d as exponent. There are reasonably clear explanations on the Wikipedia page on RSA. –  Thomas Pornin Feb 24 '12 at 12:22
show 3 more comments

Here's a really simplified version:

  1. When a client and a server negotiate HTTPS, the server sends its public key to the client.
  2. The client encrypts the session encryption key that it wants to use using the server's public key, and sends that encrypted data to the server.
  3. The server decrypts that session encryption key using its private key, and starts using it.
  4. The session is protected now, because only the client and the server can know the session encryption key. It was never transmitted in the clear, or in any way an attacker could decrypt, so only they know it.

Voilà, anyone can see the public key, but that doesn't allow them to decrypt the "hey-let's-encrypt-using-this-from-now-on" packet that's encrypted with that public key. Only the server can decrypt that, because only the server has that private key. Attackers could try to forge the response containing an encrypted key, but if the server sets up the session with that, the true client won't speak it because it isn't the key that the true client set.

It's all the magic of asymmetric key encryption. Fascinating stuff.

P.S. "really simplified" means "mangled details to make it easier to understand". Wikipedia "Transport Layer Security" gives an answer more correct in technical particulars, but I was aiming for "easy to grok".

share|improve this answer
At this point it's important to mention that the public key is signed by a trusted authority, meaning even if the attacker is a man in the middle, he can't pretend to be the server in an attempt to trick the client into encrypting the shared key using the attacker's public key instead. –  BlueRaja - Danny Pflughoeft Aug 15 '11 at 22:07
what would happen had we not invented asymmetric encryption? –  Louis Rhys Aug 16 '11 at 1:50
Without asymmetric encryption, the Internet as we know it would not exist, period. You can't sell stuff to random client systems with symmetric encryption. The Internet would be like TV, where you look at the infomercial but you have to call in on the phone to make the purchase. Asymmetric encryption really, really is fascinating stuff –  gowenfawr Aug 16 '11 at 3:44
Viola? Don't you mean Voila? :) –  Tom Aug 16 '11 at 5:45
I'm sorry, the viola-voila thing is such a reflexive in-joke thing with me, I used it without thinking about it, and of course, nobody here could be expected to be in on that joke. So, yes, voila was the intended semantic content, and viola was not a typo but an obscure syntactic joke. Sorry about that. –  gowenfawr Aug 16 '11 at 12:22
show 1 more comment

The other answers are good, but here's a physical analogy that may be easier to grasp:

Imagine a lock-box, the kind with a metal flap that you put a padlock on to secure. Imagine that the loop where you put the padlock is large enough to fit two padlocks. To securely exchange send something to another party without sharing padlock keys, you would

  1. put the "Thing" in the box, and lock it with your padlock.
  2. send the locked box to the other party.
  3. they put their padlock on the loop also (so that there are two locks on it), and return the double-locked box to you
  4. You remove your padlock, and return the now singly-locked box to them
  5. they remove their own lock and open the box.

With encryption the locks and keys are math, but the general concept is vaguely like this.

share|improve this answer
That's the way I was going to explain it too. The only other thing to add is that this complex back and forth is only needed once, as the thing you pass with it is a shared key. That way, until the end of the session, both ends can open up the lock-box and put things in it. Every session has a new padlock and pair of keys, so you just throw them away when your session ends. *8') –  Mark Booth Aug 16 '11 at 13:03
Kinda like @Mark Booth said, inside the box is a 3rd padlock with a set of keys, and it will be used for all future exchanges during the session. –  Scott Rippey Aug 16 '11 at 20:11
In addition: The box and the padlocks are made from extremely hard metal. It is absolutely impossible to break them open. It is also safe against x-rays. You can use a nuclear bomb to evaporate the box and contents and it is gone, but you can't open it. –  gnasher729 Mar 26 at 17:47
add comment

In simple words: There are two different encryptions taking place:

  • First there is the public/private key encryption. The client uses the public key of the server (which is included in the certificate) to encrypt some information that only the server can decrypt using it's private key.

  • Based on this information a session key is derived, that is only known to the server and the client. This session key is used to encrypt that data.

This is a very rough summary.

There is a lot more taking place to prevent various kinds of attack:

  • For example the client tries to validate the certificate of the server to ensure that he is not talking to a man in the middle.
  • There are different algorithms and key lengths for the session keys that have to be negotiated
  • Random numbers that are only used once are used to prevent replay attacks.
  • The Diffie-Hellman key exchange protocol can be used to generate a session key that cannot be reconstructed by someone who recorded the encrypted data transmission and gets access to the private key of the server at a later time (Perfect forward secrecy).
  • ...
share|improve this answer
add comment

I think of the six answers already up, gowenfawr's explains it best. Read that first as this is simply an addendum.

On Diffie-Hellman

Several answers mention Diffie-Helman exchanges. These are implemented in a minority of exchanges. A DH exchange is signed by the server's key to prevent a MITM attack. Because the key is not encrypted to a public key, it cannot be recovered by using a captured private key against captured traffic of a key exchange. This is the idea of Perfect Foward Secrecy. OpenSSL provides for both "regular" and DH key exchanges depending on configuration.

On MITM / Signature chains

Both public-key and DH exchanges prevent somebody from observing the connection and deriving the key. This is based on a whole bunch of math problems that you can research / look at Thomas' answer to understand. The problem with either is the MITM attack. For public key cryptography, this is fixed by either knowing the public key beforehand (even if the exchange is observed) or by way of a certificate chain. Examples: I trust Alice, and Alice signed Bob's key certifying it really is his. Also known as Google is certified by... err, Google. It appears they're in Firefox as their own CA. So, random_bank's_ssl is signed by Verisign, and my browser trusts Verisign to only issue legitimate certs.

Problems do exist with this model when you run into things like a certificate authority being compromised. In that case, an MITM attack becomes possible.

share|improve this answer
add comment

Look at Diffie Hellman : http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

For performances reasons, the connection is encrypted with symetric key. But the symetric key is generated during connection etablishement and never exchanged inc lear, but using asymetric cryptography.

Asymetric cryptography is a technique were two key are needed : a public one and a private one. What is crypted with the public key has to be decrypted with the private key and the other way around. So both computer can exchange data based on each other public keys. But only the owner of the corresponding private key can decrypt it. The private key is never exchanged, so, even if you have sniffed everything, you cannot decrypt anything. Thoses technics are expansive, so are used to exchange the key for symetric cryptography's key and not data themsleves.

share|improve this answer
While Diffie Hellman can be used and has the nice property of forward secrecy, it is normally not used for performance reasons. –  Hendrik Brummermann Aug 15 '11 at 19:44
@Hederik: But it's the easiest cryptography protocol that gives secrecy in a communication channel the attacker can only listen to. –  Hubert Kario Aug 16 '11 at 10:05
add comment

The key thing there is asymmetrical, or public key encryption. It means you have two pieces of key, public and private, and a mathematical function that is easy to calculate to one direction but very, very hard to calculate to the other.

So, when servers sends its public key, we can use the public key to easily encrypt our stuff, but only with the another key of the pair, private key in this case, you can easily decrypt it.

share|improve this answer
add comment

The EcoParty Conference announced a tool called BEAST that reportedly decrypts SSL3/TLS1.0 traffic and lower, presumably by observing it.

Here is a link to the news report

I'm sure over the coming days we will hear more about this, the workarounds and limitations.

This section below will be updated as more information is discovered

This hack assumes the attacker can somehow see your network traffic; though spyware or through a network capture. Poorly administered machines, and Wifi users are the most likely the usual suspects… though not limited to that use-case.

There are reports that we can mitigate this risk by changing the SSL*/TLS 1.0 cipher list to RC4, and not supporting older combinations. Another mitigation is to increase the length of the authentication token, which would slow down the attack. Modifying the Siteminder and ASP.net membership authentication cookie configuration may help here.

Just so you know this vulnerability is exposed by the same people who announced the “Padding Attack on ASP.NET” last year. That old issue puts every IIS webserver at risk just by being turned on, which appears to be more serious than this attack.

Do share any links you find that mention or confirm these vulnerable scenarios, or mitigations here. As it stands now, some of this is speculation and not vetted by Cryptology experts.

share|improve this answer
BEAST seems to be an attack against HTTPS only, but this flaw seems to be in SSL3/TLS1.0 . Are other applications which use SSL/TLS 1.0 vulnerable to a similar non-JavaScript attack? –  Stefan Lasiewski Sep 21 '11 at 23:35
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.