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.

If the ISP carries my data, why do people seem to think they cannot see the contents? Wouldn't they be holding the key?

share|improve this question

marked as duplicate by Adnan, Xander, TildalWave, Gilles, NULLZ Oct 23 '13 at 2:48

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

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
add comment

5 Answers

up vote 6 down vote accepted

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
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
add comment

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
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
@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
@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
add comment

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
add comment

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
add comment

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
add comment

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