417

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?

Stevoisiak
  • 1,515
  • 1
  • 11
  • 27
Joshua Carmody
  • 4,465
  • 4
  • 15
  • 11
  • 18
    Watch 1. SSL explained - http://www.youtube.com/watch?v=a72fHRr6MRU and 2. What is HTTPS? - http://www.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
  • 2
    Possible duplicate of [How does SSL/TLS work?](https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work) – Dmitry Grigoryev Mar 28 '17 at 13:35

14 Answers14

416

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 (it 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 its 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 its 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).

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 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
  • 10
    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
  • 8
    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
  • 30
    How do you work out _x_ given _x_ cubed modulo _n_ and _p_ and _q_? – Justin Feb 24 '12 at 09:46
  • 16
    @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 _x3_ modulo _n_, with _d_ as exponent. There are reasonably clear explanations on the [Wikipedia page on RSA](http://en.wikipedia.org/wiki/RSA_%28algorithm%29). – Thomas Pornin Feb 24 '12 at 12:22
  • This is a great, thorough answer! – sshow Apr 12 '12 at 07:33
  • 1
    Would it be true to say that n only has 4 factors: 1, p, q an n? – Hoytman Apr 16 '14 at 15:12
  • 3
    If _p_ and _q_ are two distinct prime integers, and _n = pq_, then there are exactly four positive integers which divide _n_, and these are _1_, _p_, _q_, and _n_ itself. The _1_ and _n_ values are often said to be "trivial divisors" while _p_ and _q_ are difficult to compute. Strictly speaking, only _p_ and _q_ are called "factors", which is why "divisor" would be a more exact terminology here. – Thomas Pornin Apr 16 '14 at 17:09
  • I guess after reading all that I don't understand how an attacker couldn't watch the computer he's attempting to gain access to generate the key that is sent to the other party to start the secure connection. –  Apr 24 '14 at 18:08
  • @greg: How can you watch that computer do things, unless you already have access to it? (Answer: Heartbleed) – Ben Voigt Apr 24 '14 at 22:44
  • If the attacker is watching the computer _itself_ from the inside, then public key exchange is useless. It only protects against someone observing the communication, not someone monitoring the internal state of the server itself. – forest Jun 22 '18 at 02:06
137

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".

Francesco
  • 231
  • 3
  • 10
gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 30
    At this point it's important to mention that the public key is [signed](http://en.wikipedia.org/wiki/Digital_signature) by a trusted authority, meaning even if the attacker is a [man in the middle](http://en.wikipedia.org/wiki/Man-in-the-middle_attack), 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
  • 3
    what would happen had we not invented asymmetric encryption? – Louis Rhys Aug 16 '11 at 01:50
  • 15
    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 03:44
  • 11
    Viola? Don't you mean Voila? :) – Tom Aug 16 '11 at 05:45
  • 10
    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
  • gowenfawr - +1 Thanks very much for your answer. I had heard of asymmetric encryption but had forgot about it when contemplating this question. Your answer was very easy understand. I accepted Thomas Pornin's answer though because I felt he really explained the mechanism thoroughly. – Joshua Carmody Aug 16 '11 at 15:14
  • @gowenfawr yes it's one of the most fascinating thing, i learned about it from https://www.coursera.org/course/crypto course and ever since i have gotten increasingly interested in cryptography and bitcoins. – Muhammad Umer Sep 20 '14 at 04:32
  • @gowenfawr Thank you for such a simplified answer! I have been confident this is how it worked for a while now but since everyone wants to provide details about every layer in the OSI model, it's impossible to find a validation of my understanding. – DotNetRussell Jul 31 '15 at 17:53
  • but if we are using asymmetric encryption, why is it important that `only the client and the server can know the session (public?) encryption key`? if the communication cannot be decrypted using the public key but only its matching private key, why can't the public key be unsecurely sent ? – amphibient Nov 17 '16 at 23:32
  • 2
    @amphibient, because the session key is a symmetric encryption key used to encrypt actual data. Asymmetric keys are only good for encrypting small amounts of data (like single-digit K). So the public-key based asymmetric encryption is used to securely exchange a small secret key which is then used for symmetric encryption of high-volume data. – gowenfawr Nov 18 '16 at 03:58
  • thanks, that makes sense. however, isn't [this popular answer](http://security.stackexchange.com/a/8309/20014) based on a different assumption, which is that data exchange post handshake also follows asymmetric encryption and not symmetric, like you say? – amphibient Nov 22 '16 at 22:14
  • 2
    @amphibient The answer you linked to appears to omit a very important detail: After the initial exchange that serves to establish the shared secret key, the server and client switch to symmetric encryption using that secret key. This is done for a few different reasons, not the least of which is performance: with key lengths that provide reasonable security, asymmetric encryption is very slow, so you want to minimize the amount of traffic you encrypt using it. Symmetric encryption, on the other hand, can be extremely fast yet secure. – user Mar 21 '17 at 16:28
  • +1 For "I was aiming for easy to grok". – Amir Fo Apr 22 '18 at 16:36
87

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.

evil otto
  • 971
  • 5
  • 3
  • 9
    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
  • 12
    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 '14 at 17:47
  • 1
    I've always liked this explanation. Much easier to grasp than a bunch of math equations. – k1DBLITZ Jun 30 '14 at 19:05
  • 1
    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 '14 at 19:32
  • 4
    I like the imagery :) Wouldn't asymmetric encryption be more like this though: server sends empty box and his open snap-on padlock without key, client puts a padlock with one key in (keeps second key), snaps server's padlock on, sends box away? – tanius Feb 02 '15 at 02:40
  • 2
    @tanius, not quite. The client gets the server's open padlock, generates a combination lock code, which it writes down and puts in the box, then locks the box with the server's pad lock. The server opens its own padlock with the corresponding key, then writes down the combo code for use during the session. From then on they just use combination locks. (symmetric key). Actually, I might be saying the same thing you are, not sure. – Arlen Beiler Aug 17 '17 at 00:12
  • I cannot understand how the analogy represent public key cryptography. Can someone explain – Suraj Jain Mar 19 '18 at 04:00
  • 1
    This physical analogy represents Three-pass protocol, and which is somewhat different from what other answers have in them, so it cannot be used as analogy for those answers, it is different, I request poster to add that note. – Suraj Jain Mar 19 '18 at 04:14
35

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

NDF1
  • 663
  • 5
  • 7
  • 2
    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 01:01
  • 7
    @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](https://addons.mozilla.org/en-US/firefox/addon/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 01:27
  • 1
    @suriv It's not a dubious assertion, it's fact. Check out [National Security Letters](https://en.wikipedia.org/wiki/National_security_letter) or the [Foreign Intelligence Surveillance Act](https://en.wikipedia.org/wiki/United_States_Foreign_Intelligence_Surveillance_Court#Secret_law). – NDF1 Oct 17 '15 at 02:02
  • @NDF1 neither of those articles supports your assertion in any way. In fact, they contradict it: "By law, NSLs can request only non-content information, for example, transactional records and phone numbers dialed" – suriv Oct 17 '15 at 03:22
  • 2
    [Do some research on your own](https://nakedsecurity.sophos.com/2014/01/29/lavabit-appeals-contempt-of-court-ruling-surrounding-handover-of-ssl-keys/). See also [Key disclosure laws](https://en.wikipedia.org/wiki/Key_disclosure_law).They can compel a company or individual to hand over an SSL key via court order. FISA deals with secret court orders so if it's related to national security it won't ever see the light of day. If it's in the interest of national security to force a CA to hand over their root signing certificate they'll do it. Of course American CAs are all vulnerable to this. – NDF1 Oct 17 '15 at 04:01
24

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).
  • ...
Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121
18

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-Hellman 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.

Bruno Rohée
  • 5,221
  • 28
  • 39
Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
13

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.

apsillers
  • 5,780
  • 27
  • 33
  • 1
    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 '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](http://en.wikipedia.org/wiki/Discrete_logarithm) 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 '14 at 19:44
11

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

For performances reasons, the connection is encrypted with symmetric key. But the symmetric key is generated during connection establishment and never exchanged in clear, but using asymmetric cryptography.

Asymmetric 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. Those technics are expansive, so are used to exchange the key for symmetric cryptography's key and not data themselves.

deadalnix
  • 211
  • 1
  • 4
10

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

scuzzy-delta
  • 9,303
  • 3
  • 33
  • 54
7

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.

LateralFractal
  • 5,143
  • 18
  • 41
  • 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
4

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.

Zds
  • 171
  • 2
4

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.

makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 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
3

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.

Community
  • 1
sahmeepee
  • 139
  • 3
-1

There are lots of great answers here, especially the ones that talk about the issues beyond performing DH or ECDH (e.g. client side corruption/cert installation/cert hijacking, et cetera.)

If you're ignoring the local machine itself and simply worried about MITM - you need DH/ECDH AND SSL pinning. SSL pinning is becoming more common, but is still not ubiquitous today. This means that your ISP can simply pretend to be your server as long as it has a valid SSL in your root chain of trust. SSL pinning ensures that the SSL cert used by the server you connected to IS the cert of the server you're trying to get to.

Again, if you're looking to be safe from the government or hackers - this is not enough. If you're looking to keep your ISP from looking through your data - this is probably enough.

WTH
  • 1
  • 1
    While this might be useful advice for TLS in general, I am not sure it actually answers the specific question asked here. – Anders Mar 28 '17 at 13:33
  • It's a better than one above which just says "because 'magic'"... Odd to downvote because I didn't bother to copy all the other answers but instead added to them with the things that are actually important in modern SSL/TLS connections. This is why I specifically pointed out that many of the answers are good and cover some of the reasons why you can't decrypt the data - and then I point out that they're incomplete. I can MITM you with ECDH/DH despite what the highest rated answer states - because that answer is incomplete. Without pinning and a secure local trust store - you're insecure. – WTH Jul 07 '17 at 18:10
  • 2
    I'm not saying that the information you provide is bad or wrong - it isn't. I'm saying it isn't answering the question. Question: "How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it?" Answer: "You need DH/ECDH and SSL pinning." Thats not a match. – Anders Jul 07 '17 at 21:55
  • Surely you then downvoted the answers starting with: "A lot of the answers already provided are overlooking the interception capability of the ISP" "I think of the six answers already up, gowenfawr's explains it best. Read that first as this is simply an addendum." "If I put my black hat on (not this black hat... actually that hat also" "The key thing there is asymmetrical, or public key encryption" "The EcoParty Conference announced a tool called BEAST" then - because none of them answer the question either. It's not a big deal, it just seems rather petty. That's not what DV is for. – WTH Jul 09 '17 at 14:43