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
6  
+1 very nice question –  Louis Rhys Aug 16 '11 at 1:47
6  
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
    
Only the administrator of the website has the website's key. If you're thinking of the case where the ISP runs the website, then the ISP is not a man in the middle, the ISP is the man. –  Johnny Oct 22 '13 at 23:10
    
@Johnny I'm thinking of the case where the ISP has compromised the certificate somehow. NDF1 explains it below kinda of what I was thinking of. –  Vaughan Hilts Oct 22 '13 at 23:12

13 Answers 13

up vote 207 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
4  
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
4  
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
4  
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
11  
How do you work out x given x cubed modulo n and p and q? –  Justin Feb 24 '12 at 9:46
10  
@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

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
14  
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
2  
what would happen had we not invented asymmetric encryption? –  Louis Rhys Aug 16 '11 at 1:50
8  
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
6  
Viola? Don't you mean Voila? :) –  Tom Aug 16 '11 at 5:45
2  
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

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
4  
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
7  
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
1  
I've always liked this explanation. Much easier to grasp than a bunch of math equations. –  k1DBLITZ Jun 30 at 19:05
    
One thing that is missing here is authentication. i.e Instead of real 'they' put the second lock in step3, some one else might put the second lock. –  balki Dec 14 at 19:32

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

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

A lot of the answers already provided are overlooking the interception capability of the ISP or NSA. Take a look at Room 641A in the AT&T datacenter. There are an estimated 10 to 20 such facilities that have been installed throughout the United States. Also take a look at the One Wilshire building where 260 ISP's connections converge into one building. That location is a prime location for an interception facility.

The fact is an ISP (or the equipment installed by the NSA in the ISP) can intercept and MITM attack an SSL connection and they can do it quite easily actually.

  • Your web browser or operating system has over 500 trusted certificates installed in it. This means that you implicitly trust any website whose certificate has been signed by this certificate.
  • The NSA via secret FISA court order can force any Certificate Authority operating in the United States to give them their root certificate. The court order includes a special non disclosure clause which forces the CA to keep their mouth shut under penalty of jail time if they speak out about it. They may not even need to do this however, they only need to convince the browser vendors to accept one NSA owned certificate as trusted in the browser.
  • As your traffic passes through the ISP they swap out the website's true public key with the NSA's own public key signed by the compromised certificate authority thus performing the MITM attack.
  • Your web browser accepts this false certificate as trusted and you communicate the symmetric encryption key for the exchange back to the NSA/ISP who keep a copy of it and also pass the same key onto the website.
  • Your session with the website is decrypted in real-time with the compromised symmetric key.
  • The decrypted data is sent via fibre optic line to the NSA's headquarters and data center in the basement of Fort Meade. This scans the data for hundreds or thousands of keywords that may indicate various types of threats. Any keywords are red-flagged for an analyst to view and prioritize further action if any. The final data is sent to one of the NSA's data storage facilities in the US. The new storage facility is the Utah datacenter which is likely online already as it was scheduled to be online at the end of last month.

Here's a diagram from nsawatch.org:

the NSA surveillance octopus

share|improve this answer
1  
Wouldn't they just force the operator of the website to hand over their own certificate, which would make the whole thing completely transparent. If the NSA has to create new certificates for every website, then tracking certificate fingerprints will reveal the eavesdropping. For example, if my company's SSL key fingerprint differs between when I access the website at work and when I access it at home, then I'll know the certificate was compromised. Likewise, if they are only tapping my home internet connection, I can look for fingerprint changes that differ between home and another network. –  Johnny Oct 22 '13 at 23:16
1  
@Johnny: that would work somewhat, but user laziness to check cert signatures for every secure site they visit would happen most often. Also, some HTTPS sites change certs on a schedule (say every 6 months), which makes it hard to tell if a cert signature change is indeed valid. –  Nasrus Oct 23 '13 at 1:01
3  
@Johnny Also a large chunk of the internet has been using the Root CA transparent interchangeability bug as a feature. Navigating the modern internet with tools like Certificate Patrol is a nightmare of "legitimate" swaps and switches that a spy agency switch could hide within, like a needle in a haystack. I gave up on using Cert Patorl for that reason. The underlying v3 X.509 standard is broken. –  LateralFractal Oct 23 '13 at 1:27

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

SSL relies on public key cryptography. A server that participates in SSL has a keypair, which has public and private components.

Imagine you have a special lockbox with two keys: one key can lock the box, and another can unlock the box. If your friend wants to send you a secret message, he only needs the locking key, and you can keep the unlocking key private.

In fact, you can freely give out your locking key to everyone. You decide to leave out copies of your special lockboxes and locking keys on your front porch so anyone can have a copy. Soon, everyone in your whole town can send you secret messages in mail. You've made your locking key public.

If your friend Alice wants to send you a secret message, she puts her message inside a lockbox and locks it with a copy of your public locking key. The postmaster of your town is very suspicious of you and Alice, but -- even though he, too, has access to your public key -- he cannot open the lockbox. Only you, the sole owner of the private unlocking key, can open the box that Alice locked.

Thus, your ISP (here, the postmaster) has access to your public key, but that doesn't help them decrypt messages encrypted with your public key. Your public key only encrypts, and only your private key decrypts. Thus, your private key never leaves your possession, so no has access to it except you, and therefore no one can eavesdrop on your messages.

There's a bit more protection that SSL gives you (e.g., suppose the postmaster throws away Alice's box and sends a new message to you pretending to be Alice), but this should clarify why your ISP can't simply decrypt your messages.

share|improve this answer
2  
This is an excellent answer - thanks a lot! –  Vaughan Hilts Oct 22 '13 at 21:10
    
I have a question. we encrypt data using an algorithm and decrypt it using contrary of algorithm. so if we have the raw data and the public key, why we can not decrypt encrypted data using contrary of the encryption algorithm? –  Amirreza Nasiri May 14 at 19:18
    
@AmirrezaNasiri Public-key systems are based on mathematical problems that are extremely difficult to perform in reverse. See the discrete logarithm problem for one such problem: for a = b^k mod q, it is trivial to compute a if you know b, k and q. However, it is difficult to find k, even if you know a, b, and q. The Wikipedia article has a good example and explanation. –  apsillers May 14 at 19:44

If I put my black hat on (not this black hat... actually that hat also works):

An ISP can simply perform a man-in-the-middle-attack on any of your HTTP downloads of applications or their patches and thus update the browser trust chain directly or update it indirectly with a self-destructing trojan.

Microsoft only requires drivers to be code-signed; digital signatures for applications and application-equivalent executable data are not enforced by default*. Most consumer operating systems are no better if simply because mandatory application code-signing (and identity verification) would cost just enough to drastically shrink the size of their software ecology.

* I make a point of not linking to Microsoft Answers unless I have to. Their trained monkeys are obviously using broken typewriters.

share|improve this answer
    
Nice suggestion there. :D –  Wolfer Oct 23 '13 at 12:50
    
MITM-ing the patch process is an excellent point...but to me it seems that the ISP would have to compromise the private key of the update server to do so (which I think is encroaching into NSA/TLA territory). Have you any incidents in mind? –  scuzzy-delta Oct 23 '13 at 21:23
    
@scuzzy-delta The update servers of larger organisations are likely digital signed in manner checked by the patch process (Blizzard games for example); but in the main most initial downloads are not restricted to HTTPS access channel and most updates are neither signed nor checked by patch automation if automation exists. In theory our brand new OEM computer should come with a ROM medium of Root CAs verified by auditors independent of the OEM, and everything downloaded afterwards using HTTPS or a signed equivalent. –  LateralFractal Oct 23 '13 at 23:07

Transport Layer Security (which is what Secure Sockets Layer is now called) involves methods of securely exchanging cryptographic keys over an insecure communications channel (like the internet).

Yes, this means that the ISP can see the key exchange information as it passes back and forth, and yet still has insufficient information to read the message stream once a secure connection has been established.

A very strange concept, and it's quite a new bit of work. The most common example of this is called Diffie-Hellman Key Exchange, and was only invented in the 1970's.

The Wikipedia article has all the delicious mathematical detail, but I find the image below (from Wikimedia) illustrates the concept perfectly. Look at it, think about it, even try it out for yourself, and you'll find that there is no way for an opponent to derive the private key from the publicly viewable information.

enter image description here

share|improve this answer

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

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

No, they wouldn't hold the key as the connection you are making is between you and the target site (e.g. Amazon) so the ISP would have no knowledge of the key.

The more general question of how SSL/TLS works is answered here.

share|improve this answer

Your Answer

 
discard

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.