48

There are exerpts, that say that using https can be broken by the NSA by now.

So is https still a solution for secure web-browsing?

source: http://www.digitaltrends.com/web/nsa-has-cracked-the-encryption-protecting-your-bank-account-gmail-and-more/

Encryption techniques used by online banks, email providers, and many other sensitive Internet services to keep your personal data private and secure are no match for the National Security Agency

rubo77
  • 2,350
  • 10
  • 26
  • 48
  • https is itself a protocol, which can choose from one of a number of different algorithms, _some_ of which are already known to be broken. Which one to use is negotiated between the server and the client, so if they pick a known broken one... – Clockwork-Muse Jun 10 '14 at 13:23
  • 41
    [Worry about the $5 wrench](https://xkcd.com/538/), first. – Rubber Duck Jun 10 '14 at 13:24
  • 3
    Can't the NSA just compel all server owners (online stores, banks, ISPs, major back-bone companies etc) to install MITM devices, such that all traffic can be compromised? It's not about technical know-how - employers do this already - it's that there's no legal defence against it, and they won't even be allowed to tell people it's happening. –  Jun 11 '14 at 10:06
  • 1
    @rubo77: I think you are implying it ever was secure from the NSA ... Which was never the case, if you used Windows anyway. – Quandary Jun 11 '14 at 11:05
  • 1
    I don't believe anything is NSA safe. If you are using software or hardware you did not produce and maintain yourself it could be infiltrated by NSA or other agencies. And if you did produce it yourself you probably did something wrong ;) – PiTheNumber Jun 12 '14 at 14:05

5 Answers5

57

Basically, the NSA is able to decrypt most of the Internet. They're doing it primarily by cheating, not by mathematics.

-- Bruce Schneier

Now, your question is "So is HTTPS still a solution for secure web-browsing?"

The answer is, as safe as it ever was, unless your opponent is the NSA. The reports you're referencing do not identify a generic weakness that can be taken advantage of by random actors, by organized crime, by your ex-wife. There's no systemic failure here, just proof that a sufficiently funded, authorized, and skilled attacker can compromise lots of endpoints. And we knew that.

carlspring
  • 103
  • 3
gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 3
    In other words, there *is* a systemic failure; it just encompasses more than TLS specifically: software is universally insecure and buggy enough that a sufficiently advanced attacker can compromise pretty much any endpoint. – Matt Nordhoff Jun 10 '14 at 20:52
  • 3
    @MattNordhoff Can you cite any concrete examples where the NSA has used bugs/vulnerabilities to compromise TLS? From examples like Lavabit we know what they'd rather just compel companies to hand over their private key, and I don't see what's stopping them from compelling a CA to sign a certificate for them either. Plus there's instances like where they tapped Google's internal network after SSL had been terminated. – thexacre Jun 10 '14 at 23:08
  • 1
    "The answer is, as safe as it ever was" Begging the question. How safe was it ever? – Paul Draper Dec 29 '20 at 20:51
35

People say a lot of things. Not everything is true, of course.

HTTPS is HTTP-within-SSL. SSL, now known as TLS, is about the best publicly known encryption and integrity protocol for bidirectional streams of bytes. What this means is that there is no publicly known way to break it, provided that it was implemented and deployed properly (I admit that it is a big "if").

This implies the following:

  • If the NSA, or any other scarecrow entity that you choose to be your personal nemesis, can break SSL, then they know something that the rest of the World does not. This is advanced technology. History shows that advanced technology is, in the long run, irresistible. Therefore, resistance is futile.

  • If some people claim that NSA can break SSL, then this means that not only the NSA knows something more than the general public (i.e. experts in the field); it also means that these people are savvy to that secret knowledge, too. This raises the question of how they would know it. Either they are also members of some powerful and secret organization (and then, why would you trust them ?), or what they say is pure speculative baloney.

What works very well, though, it not breaking the cryptographic protocol upfront. Bribing an intern on the server side is so much cheaper. It would make no sense for the NSA to invest billions of dollars into cracking algorithms, when a few thousand bucks in the right pocket would do the trick.

This idea of NSA breaking algorithms is what I call the gaming fantasy. It emerges in the mind of people who like video games. A game has rules. Rules are a real comfort for a troubled mind. Here, the proponent of that theory will implicitly, but strongly, assume that since he uses a given cryptographic protocol (say, SSL) to secure his data transfers, his arch-enemy is thereby constrained to act only at a logical level and to defeat him on the ground of cryptography only. This is the fantasy of a basement-dwelling geek who wants to believe that his living habits are an actually efficient survival strategy.

(I blame the Matrix for that.)

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 11
    -1 This sounds like NSA would need to bribe someone from the target company, whereas they only need cooperation of a big CA authority to workaround most HTTPS connections without the target knowing about it. – Christian Strempfer Jun 10 '14 at 15:02
  • 1
    @Chris which ironically (?) means that self-signed CAs are actually more secure against this kind of attack. – Michael Jun 10 '14 at 16:27
  • @Michael true. Too bad they're inherently more insecure because the average user can't verify each self-signed cert without jumping through hoops :/ – Eric Lagergren Jun 10 '14 at 17:02
  • @Michael - I don't see how you can conclude that self-signed certs are more secure from Chris' comment. Care to elaborate? – TTT Jun 10 '14 at 18:45
  • 5
    If you do it correctly, you produce a keypair where the private key is secret and give just the public key to the CA to get a certificate signing it. These certs are just as secure as the self-signed ones. However, several CAs (GlobalSign, GoGetSSL, GlobalSSL) will produce the keys for you, arguing most users aren't tech-savvy enough to do it themselves. Of course, these certs are not secure at all when someone 'persuades' the CA to hand the keys over. – Guntram Blohm Jun 10 '14 at 19:05
  • @TTT if an NSA-like organization tries to get your self-signed CA private key it's a lot more likely you'll know it (break in to your house, trip your router/server alerts, etc.) than if they just coerce a third-party company to secretly give it to them. – Michael Jun 10 '14 at 19:25
  • @GuntramBlohm, Micheal, I've never heard of a CA generating a private key before. I just did a quick search on GlobalSign's site and couldn't find anything about that. Do you have a reference perhaps? – TTT Jun 10 '14 at 19:50
  • On the globalsign web page, look for AutoCSR. My original reference is the german c't magazine, so the article http://www.heise.de/ct/heft/2014-12-Wie-CAs-das-Vertrauen-in-die-SSL-Technik-weiter-untergraben-2189639.html is in german as well. What google translate produces is not great, but at least comprehensible. – Guntram Blohm Jun 10 '14 at 20:01
  • @GuntramBlohm, thanks for the reference. Well, perhaps the type of website that would end up using an AutoCSR is one that you can be pretty sure the NSA wouldn't be interested in. And even if they were, to Tom's original point, it would just be too easy to pay off the IT guy rather than trying to convince the CA to give it up. – TTT Jun 10 '14 at 20:41
  • "This begs the question of how they would know it." Or they're one of the handful of people with access to information from Snowden or another whistleblower. Of course, those people tend *not* to sound like raving conspiracy theorists. :-) – Matt Nordhoff Jun 10 '14 at 21:24
  • 1
    As Brian commented on another answer it's also possible to create a fake certificate and do a MITM attack. So they wouldn't need the private key. But probably they don't have to go so far, because a lot of companies will cooperate. – Christian Strempfer Jun 11 '14 at 02:48
  • 1
    It wouldn't be unprecedented for the security services to discover cryptanalytic techniques before civilian cryptanalysts - for example, the NSA are believed to have been aware of differential cryptanalysis before it was discovered by civilians. – James_pic Jun 11 '14 at 08:48
  • @James_pic that was a different world. In today's world, super smart academics are working on this stuff all the time... – Ohad Schneider Aug 12 '17 at 12:38
17

There are a number of attacks on HTTPS in practical use, that the NSA probably or plausibly has:

  • Given the number of CAs in the world, it is pretty well certain that some of them are either knowingly or unknowingly subverted by the NSA. It would be very hard to rule out that one or more of the organizations trusted by browsers are actually NSA founded and operated. So most likely the NSA can issue itself certificates for any domain it pleases, in any name it please, that your browser will accept. Even if you check the name of the organization in the browser address bar, you probably don't check that the issuer is "the right one" for your bank. That's kind of what certificate pinning is about.

  • Heartbleed. The NSA may well have known about it up to 2 years before the rest of the world, which would mean that a hefty proportion of sites were subject to leaking their admin passwords and/or certificate private keys. In some sense heartbleed is over now, but not every site that was possibly vulnerable has revoked its old certificates, and it's a warning that show-stopping flaws can be undetected for years. There could be more.

  • Hacking operations. The NSA can throw every attack in the book at a server, plus some attacks only in its own secret books, in attempt to control the machine or acquire its private key. The same goes for the client. Of course this doesn't necessarily lead to an attack "on HTTPS", it might capture/control the decrypted traffic, but it still means that HTTPS does not imply "hidden from the NSA".

  • Physical operations. I suspect this is rare overall, never mind incredibly unlikely to be used on you or me, but the NSA can send guys to do stuff. As can related organizations such as the CIA or law-enforcement. The FBI and US Attorneys have shown in the past that they're prepared to accept intelligence from spooks in criminal cases and lie to a court about its source. It seems likely to me that under extreme circumstances they would be equally prepared to perform ostensibly criminal acts to enable NSA surveillance. An overseas CIA operation to do likewise probably wouldn't even be a crime in the US. Naturally it might well be a local crime, but breaking local law is kind of the point of the CIA ;-)

  • The NSA has the most effective known man-in-the-middle capacity. It has, as it were, its own boxes in the major internet routes: undersea cables, ISPs and suchlike. According to some of the Snowden documents it has working systems to actively intercept connections between specified endpoints. This alone is not sufficient to break HTTPS of course, but combined with factors above it means that whatever keys they obtain do translate to practical attacks.

  • The article you link to talks about Bullrun and other related programs. The fact that the NSA takes multiple approaches suggests that they don't have an all-purpose point and click break of SSL or its algorithms, at least not one that's cheap and practical to widely deploy. It's difficult to really understand the NSA's strategic assessments, but one might think that if they had that then they wouldn't need to take the risk of collaborating with big internet companies on specific subversions. Bruce Schneier (and probably others) has highlighted documents that refer to a trade-off performed by the NSA to judge whether a particular target is valuable enough to justify using certain attacks, especially attacks whose frequent use would tend to lead to them being discovered. I forget the details.

You can argue that "stealing someone's private SSL key" or "becoming a CA" isn't "an attack on HTTPS", but it really is for what lay people usually mean by "HTTPS". It's not an attack on the algorithms used, but HTTPS isn't just the algorithms, it's the whole system. Including the rather sprawling key distribution mechanism.

Whether HTTPS is a solution for secure web-browsing is another matter. If you're a US citizen, then your duly elected government has determined that it is perfectly "secure" to have your internet traffic observed by the NSA. Indeed, more "secure" than allowing the bad guys' traffic to be unobserved. The definition of "bad guys" is widening now that the NSA doesn't address itself solely to foreign threats as originally mandated, but also to domestic security and criminal concerns. The same applies in other countries, especially those close allies of the US who share intel with the NSA. Wooo!

It's relatively unlikely that the NSA cares about you or me in particular. Based on what we've seen of the Snowden documents it's relatively likely that if they can intercept and decrypt a particular piece of traffic with minimal marginal effort, then they will, and as such it seems likely that a good proportion of innocuous HTTPS traffic is not "secure". Naturally most of that data never reaches a human analyst, but it's available.

For me the significance of the Snowden documents wasn't that any techniques in it left people thinking, "that's amazing, we never knew that was mathematically possible". AFAIK no specific cryptographic techniques have been revealed. The news was the confirmation that the NSA has worked itself far into the infrastructure, so that security fails even without a genuine "cryptographic break".

Steve Jessop
  • 2,008
  • 10
  • 14
8

@gowenfawr has it right: for normal use TLS/SSL is safe to use, if implemented properly. When the NSA is in play, forget about it.

  • First of all, when the SSL-key is given out by an American company, they can get the private key and decrypt any traffic from and to that server.
  • Is the key created elsewhere - like your own privately generated key?! They'll hack your router, your laptop or break into your house, and do whatever they need to get what they want! Is this likely? Not really I guess.
rubo77
  • 2,350
  • 10
  • 26
  • 48
SPRBRN
  • 7,379
  • 6
  • 33
  • 37
  • 5
    Not likely, but still more likely than cracking SSL. That's when encryption is a success. When breaking into someone's house and beating them with a wrench is a more efficient solution. – Cruncher Jun 10 '14 at 15:51
  • 3
    @SPRBRN - I believe your first point is incorrect. Wouldn't private keys remain private regardless of what country the CA is in? – TTT Jun 10 '14 at 18:43
  • 1
    @TTT - not if the CA discloses the private keys to the NSA. – Brian Jun 10 '14 at 18:54
  • 10
    @Brian CAs don't have access to the private keys. They *sign* your *public key*. – Kevin Jun 10 '14 at 18:57
  • @Kevin - Good point. I was thinking of the CA's private keys and how an American CA will presumably sign an NSA's fake cert for the domain. That would still require a MITM attack, though. – Brian Jun 10 '14 at 19:05
  • @TTT, you're correct that the private key is not generated by the CA and should not be given to it. (I've bought an official certificate once about six years ago, a long time ago and I don't remember the specifics but recall generating a certificate, so I'll take your word for it.) The CA signs the public key. Isn't that enough to compromise the certificate? Can the NSA use this with a MITM attack? – SPRBRN Jun 11 '14 at 08:32
  • Simply having someone's private key does not allow them to decrypt existing SSL traffic since the symmetric key for encryption is normally negotiated using some form of Diffie-Hellman key exchange. It does allow them to spoof the real server in a man-in-the-middle attack, and then decrypt that data, but that is more difficult to do since you must be "in the middle". If the old-style RSA key exchange from SSLv2 is used, then yes, all traffic captured can be decrypted assuming the initial hello exchange was captured. – penguin359 Jun 11 '14 at 12:40
  • @penguin359 I think you're wrong about "normally". All SSL/TLS specs through current 1.2 support plain-RSA key exchange, all implementations I've seen support it without demur, and https://www.trustworthyinternet.org/ssl-pulse/ (Qualys) currently shows only 5% of the "top million web sites" supporting "Forward Secrecy" (DH) "with most browsers". If you say connections to "servers run by competent security-minded operators" yes, but sadly those conditions are too often not met. – dave_thompson_085 Jun 12 '14 at 08:36
3

https can be used in a secure way, which even the NSA can probably not break at the moment. But this does not mean all use it this way. Also, there are implementation problems (like heartbleed). And even if https itself and its usage are completely NSA proof their are still enough web application problems unrelated to https, because https only secures the transport of the data, not the application logic or data storage. And as long as the data are stored at the provider in clear (like mails) they can simply invoke the law to get access to this data.

In summary, https can be used in a secure way, but its usage is only a small (but essential) part of the overall web-browsing security.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • What about Quantum Insert beating the ordinary server by faster delivery times from a MITM backbone router coupled with the NSA using the keys from a NSL'd CA to issue valid certificates, is there any way for a user to 'use TLS securely' in this scenario? – JKAbrams Nov 15 '14 at 23:15
  • It can be but it does not need to be. If the client has an already established trust relationship to the real server it will detect the attack, if not it will trust the certificate because it is signed by a trusted CA (directly or via intermediate CAs). Trust relationships can be established by public key pinning, which can be either explicit built into the browser (Chrome has this for years and Firefox just started), via header on first use (HPKP, implemented in Chrome) or implicit on first use (certificate patrol extension). – Steffen Ullrich Nov 16 '14 at 04:53