New NSA Leak Shows MITM Attacks Against Major Internet Services | Hacker News Reader

New NSA Leak Shows MITM Attacks Against Major Internet Services

schneier.com

656 pointschopin139 comments

Trevor Perrin and I have been working on a dynamic certificate pinning proposal called TACK to help mitigate these types of attacks: http://tack.io

In the current state of the world, we're all dependent on CA signatures for each connection we make to a website. TACK is a layer of indirection away from CA certificates, such that we'd only be dependent on CA signatures the very first time we contacted a website. It doesn't introduce any new authorities or change the default UX at all.

After the Comodo breaches a few years ago, I put together a talk about these types of attacks, where the fundamental problems lie, and why approaches like DANE are similarly ineffective:

http://youtu.be/8N4sb-SEpcg?t=4m47s

A point worth making here: antisurveillance technology like TACK does more than make it harder for NSA to MITM TLS. As we've apparently discovered, it also makes it possible for us to detect TLS subversion. It is, right now, a major news story if someone has obtained a malicious root certificate; we need to know when that happens and to which CAs those certs chain (which is discoverable from the certificate).

If you don't pay much attention to how TLS works, you should know that NSA (presumably) does not have a magic ability to inject new certs into your root cert repository. If you remove every CA cert from your browser and selectively allow certs, they can't MITM that. The CAs aren't baked into TLS! They're a software configuration detail. And when MITM certs appear on the wire, for them to be honored, they have to somehow chain to a specific CA.

What things like pinning and TACK do is give us the opportunity to discover MITM certificates and start tracing them. If that capability becomes widespread enough, it can potentially foreclose on dragnet TLS MITM attacks, because there will be too much of a risk that deploying a dragnet MITM net will result in the death penalty for the implicated CA.

TACK (and the related efforts) are hugely more important than I think most people think they are. If you want to advocate for something in the wake of the NSA debacle, I think TACK is a great choice.

I have high hopes for TACK too. The fact that it's not CA dependent is a big deal. I wrote a bit about that, and getting by with ditching the root CAs in Firefox here: https://rx4g.com/2013/09/13/of-flying-pigs-and-tofu/

Unfortunately, ditching the root CAs is way harder than it should be, and flat out impossible in a lot of environments. Compulsory trust isn't trust.

You make a interesting point in describing TACK as intrusion detection system. It makes sense against larger adversaries, while the MITM protection make more sense against smaller.

The question I have then is, what happen if look at TACK as an IDS. What is its false positive rate? Can it be lowered? Maybe it should inform the website owner as a way to inform both side of the communication that something eerie is happening.

While an absolute necessity, it doesn't solve the immediate issue of NSLs and widespread use of unnecessary services.

Let's say that the NSA would like to track bitcoin transactions through MtGox. I don't know how easy it would be for them to plug a backdoor into a server in Japan, and let's assume that the NSA can't break the RC4 crypto their web server is configured to use ..

Since MtGox uses Google Analytics, and possibly pull other scripts from Google's CDN, they could either eavesdrop on whatever data comes back from them by default -- or insist that changes are made to ... pick up more.

Yes, absolutely, there are more hurdles. As an extension of this pinning work, Trevor has also been working on a proposal for 3rd party includes that would allow you to specify a hashsum in the include line, as well as a proposal that would fix cookie scoping in backwards compatible way.

That would pretty much cover the use of CDNs that have proper versioning schemes.

Analytics, however, will remain something I'm not overly fond of. For many sites it's unnecessary. For others it's something they could nearly just as easily license and deploy to their own servers. Pulling scripts in from Google Analytics, Statcounter and others -- and especially into privacy concerned apps -- is downright irresponsible.

As I noted here: https://2x.io/read/would-the-nsa-infiltrate-cdns-to-circumve..., even Norway's tax returns site (which hosts info I'd rather not have in any foreign company's hands) use external analytic scripts. They and 90% of the rest of the internet.

No wonder the NSA claim they can circumvent most HTTPS encryption.

even Norway's tax returns site...uses external analytic scripts.

I'm curious who build that? Can they not count the filed docs.

Your tack.io proposal looks great. Do you have any sense as to whether or when it will be adopted?

Faster the more help we get!

As part of my Matasano internship, I've been working on a patch to NSS (Mozilla's crypto library, used by both Firefox and Chrome for TLS) that will give the necessary hooks needed for browsers that use NSS to implement TACK. I'll hopefully be submitting that for review soon (you can see it on bugzilla[1] and fresher in-progress GitHub[2]).

At this point, it mostly makes sense for me to finish that (though I'll have a lot less time when I go back to school, so there might be some work that needs to get done when the review comments come back that I can't get to for awhile, so someone to power that to the finish might be helpful).

But once that's in, we'll need to work on getting patches into the Firefox and Chrome that actually integrate TACK. There's also some other work to do, especially for some other longterm ideas we have (eg. securing communication between mail servers with TACK).

If you're interested in helping, either email Trevor (email is on his website[3]), or email me (danielj@matasano for the next week, personal email in my profile).

1: https://bugzilla.mozilla.org/show_bug.cgi?id=905848

2: https://github.com/jackowayed/mozilla-nss/pull/1

3: http://trevp.net

"Before Netscape, Barksdale had worked as CEO of McCaw Cellular/AT&T Wireless and, before that, as Vice President and COO of FedEx. [...] President George W. Bush appointed him to the President's Foreign Intelligence Advisory Board."

https://en.wikipedia.org/wiki/Jim_Barksdale

http://www.nytimes.com/2013/07/04/us/monitoring-of-snail-mai...

http://www.mozilla.org/security/announce/2013/mfsa2013-53.ht...

http://www.wired.com/threatlevel/2013/09/freedom-hosting-fbi...

https://www.schneier.com/essay-448.html

https://www.schneier.com/blog/archives/2013/06/blowback_from...

"I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I fetch web pages from other sites by sending mail to a program (see git://git.gnu.org/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly. I usually try lynx first, then a graphical browser if the page needs it.

I also browse from other people's computers, with their permission. Since I don't identify myself to the sites I visit, this browsing can't be connected with me.

One consequence of this method is that most of the surveillance methods used on the Internet can't see me.

Another consequence is that I never pay for anything on the Web. Anything on the net that requires payment, I don't do.

I would not mind paying for a copy of an e-book or music recording on the Internet if I could do so anonymously, and it were ethical in other ways (no DRM or EULA). But that option almost never exists. I keep looking for ways to make it happen."

http://stallman.org/stallman-computing.html

We have some large websites on board to deploy it, and Trevor has been working with browser vendors to get it integrated. The latter has been pretty slow going, but there is interest.

This isn't a promise or official or anything, but I'm fairly sure that Silent Circle will be interested in deploying TACK. I can put it on the table, if you want, but anything that increases security will be welcome.

Also, how does TACK relate to certificate pinning? The introduction has a few differences (e.g. tack expiration), but the two techniques seem pretty similar, am I missing something?

That would be great, we have a mailing list interested people should monitor, we'll definitely let people know once things get far enough for sites to start testing the waters.

https://lists.riseup.net/www/arc/tack

Regarding certificate pinning: TACK is a different "style" of pinning, it lets you pin to a self-managed signing key instead of certificate keys. So it gives you more control and security than CA pinning, if you're willing to assume more key management responsibilities (storing a TACK private key, and using it to sign new TLS keys).

I think there's room for both approaches: I'd like to see CA pinning be made easy enough that most sites could deploy a fairly safe, simple pin to popular CAs, while high-security sites make use of TACK pins.

But we'll see how things go.

Thanks, I will sign up to the list now. So, if I understand it correctly, TACK allows you to become your own CA.

I will read the spec for more information (e.g. what prevents the MITM from becoming my CA?) but it sounds very interesting, thanks again.

Re "become your own CA" - that's basically the idea.

The "pin activation" algorithm is intended to make it difficult for a MITM to foist bad pins on clients, and to limit the lifetime of such pins.

Maybe browser vendors will take it more seriously now, and with more urgency.

Especially one who's already had other services attacked. (Google)

Moxie, have you had any success with getting TACK into OpenSSL builds with the various distributions?

It's not a big deal to rebuild nginx/apache but I would think that getting TACK to ship default with OpenSSL would go a long way in getting more adoption.

We have support for a"ServerInfo" file checked into OpenSSL. This is a file with PEM blobs that can specify TACK and similar data (e.g. Certificate Transparency) that an OpenSSL server will return to clients if requested. This is a generic mechanism for TLS Extensions instead of TACK-specific, but it's what we need.

It will hopefully appear in OpenSSL 1.0.2. We'll be submitting Apache patches for it shortly. Daniel Jackoway (in this thread somewhere) is working on the NSS (client-side) corollary.

Any chance this is backported to 0.9.8 series? I still see a ton of installs using 0.9.x

Don't think they do that with new features, but not totally sure.

Will you be able to make Convergence for Chrome, too (especially now with "packaged apps" and whatnot)?

I've been running Firefox with CertPatrol add-on and if there's one take away is that simple client-side pinning generates so much noise that it conditions you into completely ignoring any certificate changes. Way, way too many websites either change their certs regularly or they use a CDN (and sometimes more than one) so that the page ends up getting a different cert on virtually every load. The most obvious example is Twitter's web interface - I am not a heavy user, but I still need to click through a dozen certificate changes per day.

TACK is certainly a must-have and I'm really looking forward it being a native part of browsers, but there will still be likely a lot of (high-profile) websites that won't play along :-/

[0] http://patrol.psyced.org

the way to interpret this situation is to treat high-certificate-churn https sites as though they are plain http. the software UI should communicate "I give up, I can't trust this site anymore" and stop annoying you with attempts to manage the noise

>In the current state of the world, we're all dependent on CA signatures for each connection we make to a website.

Now that you mentioned it, are those safe from say a government agency having access to the companies that serve as certificate authorities? Or is it all a house of cards, as it is now?

Some CAs make more of an effort to secure their crown jewels than others, but for the most part, it's a big house of cards.

Which is why nothing serious happens to Comodo and Verisign when they get hacked: anybody knowledgeable is already aware that a certificate means very little on its own, and we can't stop the internet anyway, so hey, life goes on.

Does OCSP stapling help or hurt? How similar to TACK?

It doesn't really impact the MiTM attacks described in the article.

An attacker who is able to sit in the middle with their own trusted cert is simply going to not bother passing the stapled OCSP response along. The victims browser will do an OCSP lookup (or not...) for the trusted cert the attacker provided, and that will succeed.

I'm not sure how OCSP caching is implemented in the browsers that implement OCSP in the first place (is there a spec for caching?), but as it's a method for checking the revocation status of certs, it can't be cached long.

I am not sure what it uses to validate but I have a ocsp stapling file I made

openssl test reports

     OCSP Response Status: successful (0x0)
     Cert Status: good
     This Update: Sep  8 xx:xx:xx 2013 GMT
     Next Update: Sep 10 xx:xx:xx 2013 GMT

        Validity
            Not Before: Aug 22 xx:xx:xx 2013 GMT
            Not After : Oct  2 xx:xx:xx 2013 GMT

So that's quite a long cache. I thought it would fail after the 10th but apparently it is using the CA valid date range?

If this is true, and that NSA has been MITMing providers like Google, they are undermining the already shabby trust the US cloud-industry has attempted to build. I doubt Google and friends are very happy about that, since that's their one big basket where all the money comes in.

NSA in their eagerness to do rampant spying on everyone have had quite some collateral. They have decided to compromise the one thing which allows us to communicate securely on the internet: trust.

Right now we need to find out which (root?) CAs are compromised by the NSA. Long term it would probably be a very wise decision to revoke any US-based CA from the default trusted-list of browsers and OSes.

We cannot have untrustworthy CAs in a system based on trust. That's simply not an option.

Edit: As I've been pondering for a while (and which was also pointed out on reddit) we now have a situation where self-signed certs are more secure than CA-issued ones. They are the only ones you know can't be faked. How backwards is that?

The NSA is ruining the internet one piece at a time. The NSA needs to be dismantled.

The HSTS commits /maybe/ suggest that Google thinks a Verisign intermediate was signing MITMs for Google properties. They just blacklisted "VeriSignClass3SSPIntermediateCA"

See: https://chromiumcodereview.appspot.com/23523051

Note that the associated bug is private (https://code.google.com/p/chromium/issues/detail?id=173460).

There's a good explanation of the "bad_static_spki_hashes" parameter here: http://ritter.vg/blog-cas_and_pinning.html

if that's the case, how did they get the private key from verisign? was it stolen? did verisign simply give them it? or was it obtained under some kind of legal process? if it was under a legal process, doesn't this raise additional questions about the judicial overview - did they realise how broad this was?

Sounds like it could be any of those things: they use all those tactics.

http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet...

Because strong encryption can be so effective, classified N.S.A. documents make clear, the agency’s success depends on working with Internet companies — by getting their voluntary collaboration, forcing their cooperation with court orders or surreptitiously stealing their encryption keys or altering their software or hardware.

N.S.A. documents show that the agency maintains an internal database of encryption keys for specific commercial products, called a Key Provisioning Service, which can automatically decode many messages. If the necessary key is not in the collection, a request goes to the separate Key Recovery Service, which tries to obtain it.

How keys are acquired is shrouded in secrecy, but independent cryptographers say many are probably collected by hacking into companies’ computer servers, where they are stored. To keep such methods secret, the N.S.A. shares decrypted messages with other agencies only if the keys could have been acquired through legal means. “Approval to release to non-Sigint agencies,” a GCHQ document says, “will depend on there being a proven non-Sigint method of acquiring keys.”

Sounds like there are plenty of possibilities: they have agents working at verisign/they broke into verisign (either physically or electronically)/they just asked and verisign said ok/they used legal processes.

> they used legal process

They used a secret legal process. There, fixed that one for you!

Didn't Assange say in a (secretly?) recorded video where he was talking with Schmidt and another person that while the Americans got trusted root keys from Diginotar, the Chinese hacked Verisign and grabbed their root keys? I'll see if I can find the video.

Great tip! It's not exactly what you laid out, but here's the interview you're probably thinking of (ctrl+f verisign): http://wikileaks.org/Transcript-Meeting-Assange-Schmidt

Quoting Julian Assange: I have been told actually that VeriSign... has actually given keys to the US government. Not all, but a particular key.

Very interesting.

I don't get why everybody talks about Verisign or others giving them "keys". The NSA just need certificates for their own key, right? The only private key that Verisign could give them would be their signing key, which seems much too powerful and central for a signing authority to hand out.

Raw decode of the cert that has been blacklisted. http://pastebin.com/4wJXTsR4 Let the speculation begins.

The checkin says "Win32/Sirefef.gen!C" uses it somehow. A virus that acts as a CA?

Didn't the slides show that it was the Diginotar compromise?

> We cannot have untrustworthy CAs in a system based on trust. That's simply not an option.

The entire CA trust model is broken. In the trust model, any CA can issue certs for any domain; so a Chinese CA could issue Google certs, or a US CA could issue certs for the Dutch government.

Self-signed certs with certificate pinning are indeed more likely to be secure than CA certs. Of course, you can do both; CA signed certs (which does add a small amount of trustworthiness, as the CA is at least supposed to do a little work to verify a real-world identity), and use certificate pinning to avoid this kind of attack.

DANE[0] (in combination w/ DNSSEC[1]) is starting to sound really good right about now... except that, you know, the U.S. also runs several root nameservers.

[0]: https://tools.ietf.org/html/rfc6698 [1]: https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex...

Root servers simply serve the content for the root zone, ICANN generates the contents of the root zone and signs it using an elaborate system of trust: http://dns.icann.org/ksk/

This. In a recent post a commenter discussed how Bruce uses a machine not connected to any network ever for highly sensitive material. The problem with that is we really have no adequate indication of exactly what in all of this is really compromised. The conspiracy theorist in me suggests the whole of the internet in all its layers have been nurtured by our government. Exactly what part of that the NSA was involved in seems irrelevant. I have to wonder which operating systems, which network devices or any other devices that can run code and listen in.

The only advice if any of it were true would be to scrap it all and start over. Scrap multiple decades of work by really smart people due to a few "bad seeds" being planted during the harvest? Unfortunately that's the only true remedy unless someone can really unwind the rootkit in our lives that is the NSA. It's an analogy of a computer being infected with a virus. Do we try to go back to a backup we hope isn't compromised or do we reformat and start over? We're all trying the former because I don't think anyone really has a grasp on or even wants to think about the latter (I certainly don't).

> Right now we need to find out which (root?) CAs are compromised by the NSA.

Given that basically all CAs people actually use (even in Europe) are owned by US companies, I would estimate something close to 100% of them have cooperated with the NSA at some point. Obviously there are non-US CAs like China's CNNIC but most of them won't actually sell you a certificate.

If the NSA is doing this "legally" via secret courts etc... Then you have to assume every company subject to US law can't be trusted.

We already know that we can't trust most major US companies. What compromised CAs mean is that we also can't even trust non-US companies due to our dependence on US CAs for TLS to actually be usable.

...and any CA outside the US is compromised by China, India, UK, etc.

This doesn't just affect services that are hosted by Google, but also encrypted sites that pull scripts in from Google Analytics, Google's CDN, etc.

I wrote a semiparanoid rant about this a couple of days ago ... but didn't think I'd be this close to the truth.

https://2x.io/read/would-the-nsa-infiltrate-cdns-to-circumve...

For what it's worth Moxie Marlinspike gave a talk a few years back about some of the major issues with SSL as it is and had an anecdote about how bad Verisign's security is including the fact that they had a major breach in which several certs were taken.

https://www.youtube.com/watch?v=Z7Wl2FW2TcA

Holy shit.

This means that The Netherlands was a high-level target with Diginotar, and they hit the frickin' jackpot.

Just for reference, read this: http://nl.wikipedia.org/wiki/Hack_bij_DigiNotar

The Diginotar hack basically exposed all of the information about the Dutch that NSA could ever want to digg through: Information about licenseplates (RDW) Tax info (DigiD) Phone records (OPTA) and the complete dutch encrypted government infrastructure (PKI Overheid)

Let's see what traction this new info will get now in The Netherlands...

My understanding was DigiNotar was pretty strongly linked to an Iranian government affiliated hacker. Indeed, the breach was caught because someone man in the middled gmail in Iran and Chrome's certificate fingerprinting caught it.

Although the NSA certainly has reason to spy on Iran, why risk discovery this way? They can legally compel Google to give them the email of foreigners in a foreign country.

So maybe NSA had DigiNotar's key, but the hack that shut it down was done by someone else.

Or perhaps the Iran link was a misdirection. They were worried that people would notice the MITMed certs, so they MITMed a lot of Iranian customers to make it look like the attack came from there.

> They can legally compel Google to give them the email of foreigners in a foreign country.

They can, but they may wish to be more subtle than that. For example, if they were engaged in economic espionage, they might not want that story to break, and would be worried that someone at Google may leak the story. If they had to ask Google, there would be more people who would know about what's going on.

Plant hackers in Iran (or just buy Iranian blackhats). Hack someone. If you're caught, blame the Iranians. Two birds, one stone.

Here's some pretty detailed info in English: http://threatpost.com/final-report-diginotar-hack-shows-tota...

I still don't have a DigiD (which is a real pain in many ways) simply because I don't think they have the technical expertise to create a system with information like that that I would trust. It's just too juicy a target.

If it is true that the NSA MITMed Google connections, then one could draw the conclusion that the NSA doesn't actually have a direct connection to Google data centers (as claimed by Google). If they had such a connection, then why would they use MITM attacks against people?

The "direct access" that the NSA has to Google accounts probably requires sending a request for some set of information to Google. It likely needs to be signed off on (even if it's all automated). I'd imagine the NSA would like to hide some activities, especially corporate espionage, even from the watchers at Google--it reduces the risk of anyone at Google growing a spine.

If you can't be sure your "backdoor" can be kept alive indefinitely, you better get used to using multiple approaches.

Requests to Google may be audited or logged; Google have an incentive to do this so they can pass the buck when the inevitable evidence of abuse comes out.

The NSA, on the other hand, would prefer there to be no audit trail so there's no evidence of the inevitable abuses.

Hard to know for-sure, but it could be something as basic as redundancy. If one method of information-capture was eventually disallowed, they'd have an alternative. Or if one method of information-capture required more oversight than they wanted - they'd have an alternative.

It would also stand to reason that the court/LEO requests to Google for data are just a CYA/formality with respect to them "legally" getting the authorization to read the data.

They likely have the access to all the data they want. They use the legal vectors for requests just to see what the companies would give them on the request, and can compare the difference between the provided data vs the slurped data.

A bit surprised at the shock here, CAs are, for the most part, in the lawful intercept business and have been as long as they've existed.

Moxie Marlinspike and others have been talking about this for years. Its a recognized problem, and thats why apps that are serious about protecting communications have been moving to a pinning model.

Obviously this sucks at the browser level, though Chrome protect does this with Google properties (and others?) at the CA level now, but at the app level it's very doable and should be something you're implementing.

Please give some references about this "pinning model," as I'm having difficulty finding anything via google. Thanks.

Parent is refering to public key pinning. Chrome for instance has been doing it the last couple years [1].

Also see Moxie's comment in this very thread. [2]

[1] https://www.imperialviolet.org/2011/05/04/pinning.html

[2] https://news.ycombinator.com/item?id=6381673

Funny. I tried to submit the original Globo/Fantastico story to HN 4 days ago (http://g1.globo.com/fantastico/noticia/2013/09/nsa-documents...) but was blocked as spam.

Schneier's credibility makes a lot of difference.

Of course. A simple visit to http://www.schneierfacts.com will tell you why.

If I had to design a system to break TLS (and I had the authority of a secretive government agency), selected MITM attacks would be exactly what I would use.

Large-scale MITM attacks, i.e. ones against a huge section of the population, really have a lot of disadvantages. First, there are always cautious people who check certs religiously, sometimes with browser addons to help (in fact I see that peterwwillis linked to some below). So, if you execute a large-scale MITM effort, you run the risk of being discovered. Note that if the NSA can compel Google to turn over its secret key(s), this isn't an issue, but I am operating under the assumption that we don't want to give away our MITMing easily.

Second, broad MITMs require a lot of resources to be effective. To MITM all of Google's traffic requires network capacity equivalent to Google's, no small thing (though I suspect very much within the power of the NSA if it were deemed necessary). There's a lot of data on the internet at any one time.

Third, the fact that you must have physical servers on physical networks sitting between Google and the target means that the MITM server's IP address will be the one that targeted clients appear under. That is, if you have a single server MITMing thousands of requests, all of them will appear from the same IP address. That's another risk of being discovered if the MITM is too broad and the servers are too beefy. Although, this assumes that people on the other end are doing some sort of analytics --- maybe not true. But intel agencies are pretty paranoid, so whatever.

Fourth, it still pretty much gets the job done anyway, with less cost: passively sniff traffic for, say, DNS requests to resolve suspicious domains, or plaintext connections that have suspicious contents. Passive sniffing requires less computational power than actual MITMs, and it can be done without raising any red flags. Plus, even if you miss someone suspicious, just get a NSL for Google to hand over all the data anyway in the worst case.

Fourth, if an investigation ever were launched about my breaking of TLS, targeted attacks look great. See, we don't target the American people --- only specific connections that are "suspicious" are targeted. Broad-scale MITMs seem very illegal-wiretap-y, but the targeted connections look very legitimate, at least in comparison.

So, these reasons are why I've always held the belief that the government is not executing large-scale MITM/dragnet collection of encrypted communications ... and hence TLS is effective, so long as you're not the one being targeted.

If a MITM attacker is confident they control all paths between a server and a victim, they need not alter IP addresses on packets in transit. To pull this off, the attacker must be near the victim (e.g. compromise a broadband router), thereby reducing the number of targets, or near the server (e.g. compromise every link into a multihomed datacenter), thereby reducing the number of sites intercepted.

Some firefox add-ons to help defend against mitm:

Certificate Patrol (notifies you when certs change) https://addons.mozilla.org/en-us/firefox/addon/certificate-p...

Force-TLS (force websites to always use HTTPS) https://addons.mozilla.org/en-us/firefox/addon/force-tls/

Perspectives (compare certs with peers to verify authenticity) https://addons.mozilla.org/en-us/firefox/addon/perspectives/

> Some firefox add-ons to help defend against mitm:

In theory yes, but not more than 10 minutes ago Cert Patrol noticed that Amazon have changed the CA for the SSL cert for an image server.

What am I supposed to do? It is interesting info, but if I reject the cert then I can't be sure my connection is secure. If I accept it... I can't be sure my connection isn't MiTMed.

The human factor is always the weak link.

The nature of certificates means a site can use more than one. If you use such a site, you can try to notice the pattern of which certs they use and if it changes, but it's not going to be perfect. If you choose to only use sites which use one certificate it might be a big help. Here are some more useful plugins for Firefox:

HTTPS Everywhere (preset list of sites to use only HTTPS on) https://www.eff.org/https-everywhere

Safe (shows you when a site might not or isn't using HTTPS) https://addons.mozilla.org/en-US/firefox/addon/safe/

If you want to keep your information private, don't put anything on an internet-connected device that wasn't encrypted on an airgapped computer first.

Also Monkeysphere and HTTPS Everywhere (which Force-TLS sounds similar to):

http://web.monkeysphere.info/download/ https://www.eff.org/https-everywhere

Certificate Patrol is kind of useless for all Google properties, since they constantly swap out certificates on most of their domains every few days. Ironically, these are probably the most important sites you need to be worried about MITMs with, but you'll constantly be ignoring them with Certificate Patrol.

I use Certificate Patrol at home. For Google this is not a very useful add-on as the certificates change all the time. Especially for Google I lost track whether these changes are legitimate or not. Since I only search with Google and have no account with them that's a fine enough trade-off for me. Where I using more sensitive services I'd be worried.

I've tried using Certificate Patrol, but Google and Facebook use loads of different certificates for the same URLs -- I guess it's a side-effect of large CDNs. Guess which websites I read the most? I ended up clicking Yes without reading, defeating the purpose of the tool -- a bit like what usually happens with NoScript.

Weird. This has been submitted in less than two hours, has 90 points, but it is at the bottom of the front page. Other stories from 6+ hours ago with less points are at the top.

This has been the case for nearly all NSA related stories in the past week. There is a lot of flagging going on. I'd be interested in a data dump of who is doing the flagging and getting an idea if it's an indicator that the HN community as a whole doesn't want these stories or if it's just a small, but vigilant subset.

https://news.ycombinator.com/item?id=6369530

The documents mention the DigiNotar hack explicitly. What I do not understand is that the hack was detected when (afair) Iranian authorities tried to MITM Google connections, so the hack was claimed to come from an Iranian hacker. This begs the question whether this is wrong and the NSA hacked DigiNotar genuinely or they just used the breach (perhaps then only known to them) to fake certificates themselves. One may also take into account that DigiNotar was responsible for Netherlands public key infrastructure. This made DigiNotar possibly an even more valuable target.

If memory serves, the Internet in Iran is state-controlled. While it was a user in Iran who initially discovered the MITM'ing being performed and the obvious assumption is that it was the Iranian government MITM'ing its citizens, it is also quite possible that it was (e.g.) the NSA MITM'ing (everyone|a group of people) in Iran (possibly attempting to MITM connections from Iranian officials/nuclear power plants/etc.).

At one point does the NSA become considered a terrorist organization in and of itself? It seems to me that they have stared too long into the abyss.

They become a terrorist organization when they target civilians to cause terror. Fortunately there's no evidence that they do.

Terrorists are groups with relatively small power who use dramatic methods. The NSA is quite the opposite; as a governmental organization attached to a very powerful government they would lot be called terriers for their actions, but rather something like totalitarians or tyrants.

They already are in my book.

Can you expand on that? Under what definition of terrorism is the NSA a terrorist organization?

It seems to me that their intent to be as clandestine as possible makes them distinctly non-terroristic.

Spreading terror.

That's not their goal, though. If anything they'd prefer that everyone in the world didn't know they existed whatsoever, which is quite the opposite to what any terrorist group would like.

You could call what they do criminal, but it's not terroristic.

"Terrorism" is, admittedly, a very ill defined term. Academics have been arguing for decades about whether or not State actions against their own people can be labelled "terrorism" or not. Given that, I won't quote a dictionary or textbook definition, but rather say that I see them contributing as a part of a larger system that seems to meet some definitions of "terrorist", at least if you believe in the existence of "state terrorism".

It seems to me that their intent to be as clandestine as possible makes them distinctly non-terroristic.

Yeah, I'll admit that's an arguable point. I haven't even made up my own mind on the "intent" aspect.

All told, labeling them a "criminal" organization would probably be better, but I think it would be wrong to overlook the role they play in allowing the US government to use fear as a tool of control.

> One document [1] published by Fantastico, apparently taken from an NSA presentation [...]

> Another screenshot [2] implies is that the 2011 DigiNotar hack was either the work of the NSA, or exploited by the NSA.

I doubt that those 2 documents are original slides or screenshots from NSA material. They both are written with the familiar rounded font that Globo uses for all its text [3]

[1] http://www.scribd.com/doc/166819124

[2] http://imgur.com/a/g3UGP#1

[3] http://www.fonts.com/font/urw/vag-rundschrift?siteId=2c670c8...)

The simplified view given in the documentcloud link begs a question: just which CA certificate(s) is/are controlled by NSA?

Because in order to pull that MITM off, they either need to have the target service's CA - or they have the ability to fake any certificate. My guess is on the latter.

And that means at least one commonly accepted CA certificate is effectively compromised.

Afaik it is not necessary that a root CA is compromised. Sufficient would be to compromise any intermediate CA who is not on a revocation list. How to circumvent Googles certificate pinning in Chrome, I have no good idea. They would need to compromise any certificate in the chain.

And here I was thinking I was being an all paranoid nutter when I expressed privacy concerns with US hosted CDNs and analytics services ..

https://2x.io/read/would-the-nsa-infiltrate-cdns-to-circumve...

Eventually we will find out enough about what the NSA can do that the entire internet is as good as screwed. If they can get away with MITM against just about any secure site then how does the internet economy function any more?

consider that, if there have been undetected rampant MITM attacks, the economy never noticed or cared.

the economy side of things will be fine. the economy of what the internet is used for isn't really the concern, here. arguably, even with rampant MITM attacks going on, e-commerce is loads more secure that what we've had for in place for the past 5,000 years.

this is much more than an economic issue.

I'd say this is likely bullshit at least that it was done against a Brazilian company. Why take the risk of getting caught and burning your ability to do this when you can get the information from Google?

1) Chrome(and some plugins) pin's certificates and would notice a man in the middle attack(unless it was done with google's key). Sure, most corporate targets probably use IE, but if anyone uses chrome on or one of these plugins on the network, you've both alerted your target and exposed a presumably tightly guarded ability. Hell, if it get's reported, you've probably burned the ability. Of course, you might be able to filter out both the plugins and chrome, but it's a risk.

2) NSA could legitimately just ask for the company's emails from Google. Petrobras is a Brazilian company in Brazil staffed by Brazilians and as such a legally allowed target for Foreign Surveillance without either the NSA's twisted definitions of search and who is a US national. Google is legally required to hand over the information by the Foreign Intelligence Surveillance Amendment Act of 2008. Why authorize an operation that could reveal both the CA's you have in your pocket and you network penetration exploits?

As a side note, the cited slide looks nothing like anything else we have seen and lack security/ handling information (e.g the prominent TS/SCI/ORCON/NOFORN on the top of the prism slides).

Where did you read that it's mail traffic they were after? I'm beginning to strongly believe that it's Google's other services are considered for use in specific attacks.

Imagine if some foreign service, that is outside of an NSL's reach, has communication that the NSA wants to snoop on. If they can't break the crypto, but that service happens to load jQuery off of Google's CDN, or use Google Analytics, the NSA could pull a MITM attack and manipulate the content of the requested scripts.

Those scripts could rather easily act as proxies for the NSA or others, and either hijack sessions or pull data straight out of the protected services.

I'm tooting my own horn here, but that's exactly the kind of thing this blog post speculates on: https://2x.io/read/would-the-nsa-infiltrate-cdns-to-circumve...

AFAIK, Chrome "certificate pinning" may not exactly be what you think "certificate pinning" means. It should be more precisely called "certificate authority pinning". What it means is that Chrome will not trust certs for Google properties except those issued by certain certificate authorities. Reference: https://www.imperialviolet.org/2011/05/04/pinning.html

Unless things changed since I last checked.

In contrast, "real" "certificate pinning" as done in some mobile apps (IIRC Twitter) involves storing the hash of the certificate itself in the app. No other certificate, even from the same CA, will be accepted.

You are correct chrome pins the authority, not the cert. And at least as for 2011, they don't just pin their own sub authority, they include a couple of real authorities who's keys the NSA might have.

https://www.imperialviolet.org/2011/05/04/pinning.html

I believe Chrome only "pins" certain certificates and almost certainly doesn't pin every SSL certificate you may happen to come across -- this is what the EFF's Observatory[0] and browser plugins like Certificate Patrol[1] are for -- although I may very well be wrong on that.

Also, a March 2010 research paper by Christopher Soghoian and Sid Stamm "in which they present evidence that certificate authorities (CAs) may be cooperating with government agencies to help them spy undetected on 'secure' encrypted communications."[2]

More details on that from the EFF[3] but if we assume that the government can obtain Google's private keys then they could almost certainly carry this out undetected, IMO.

[0]: https://www.eff.org/observatory

[1]: https://addons.mozilla.org/en-US/firefox/addon/certificate-p...

[2]: http://files.cloudprivacy.net/ssl-mitm.pdf

[3]: https://www.eff.org/deeplinks/2010/03/researchers-reveal-lik...

I think it pin's google's certificates. The article claims The goal of the attack was to "impersonate Google security certificates."

I'm not saying NSA doesn't have the ability, just the implication that it was used against Brazil is likely wrong.

> I think it pin's google's certificates.

That's what I understand as well but I don't think they pin much more than that -- and certainly not every SSL certificate on every site one might connect to.

Technically FISA only allows surveillance of foreign nationals or powers in association with a terrorist investigation[1]. No idea how closely this is enforced.

HOWEVER, there is plenty of other legislation enabling the NSA to spy on non-US parties in different circumstances.

[1] http://en.wikipedia.org/wiki/Foreign_Intelligence_Surveillan...

There is no implied relation in the presentation between MITM attacks and the attack on Petrobras

They're merely on the same presentation describing attacks and targets

This might also be an indication that their advances in attacking commonly used ciphers are not that major - it does not make that much sense to perform a relatively complex MITM attack if you are able to just break the used cipher.

Not so, active MITM is absolutely required if you want to get around PFS.

I wondered the same thing regarding them requesting private keys a while ago. If they could break the ciphers, why would they need the keys?

"Google directly by performing a man-in-the-middle attack to impersonate Google security certificates."

Which CA did they use to get those certs, they should be obliterated from trust networks.

Flying Pig - I wonder if it has something to do with the "With sufficient trust pigs fly just fine". Seems to summarize very well the NSA approach towards its mandates.

It's worth noting that Chrome's use of TLS Channel ID makes it unlikely this attacks can be pulled if the end user has a ChannelID capable browser.

Applied Cryptography mentions the 'Interlock Protocol' [1]. Why is something like this not used in today's protocols to try and detect MITM attacks?

1 - http://en.wikipedia.org/wiki/Interlock_protocol

It sounds like the interlock protocol only protects against MITMs that try to modify the conversation. It seems likely that most MITMing is for the purpose of merely reading a conversation, not modifying it. The wiki page also describes an attack against the protocol, so it might not be very effective.

Cut the cables. The USA should be kicked off the internet. They've proven they can't be trusted.

It is irresponsible on behalf of the rest of the world to allow this behavior to continue. Maybe after US businesses have experienced enormous economic damages they will change their way.

If the USA were kicked off the internet, US businesses would be far from the only ones that would experience enormous economic damages.

Absolutely. IMO it would hurt the rest of the world more. However I don't think it is unreasonable to start thinking about this as a possible solution. This would be a drastic action but its severity is matched by the issue at hand.

Relevant (and just posted on the Cryptome list): http://www.freelists.org/post/cryptome/MITM-Manipulation-of-...

https://tools.ietf.org/html/rfc6091 http://web.monkeysphere.info/

Google cache version:

http://webcache.googleusercontent.com/search?q=cache:www.sch...

If you worry about the NSA spying on your company, DUMP MPLS WAN networking ASAP, it's unencrypted and basically just VLANS at layer 3.

The easiest way to snoop on all internal company data is to sniff those MPLS links at ISPs.

Wait. They access google directly... without depend on routing your traffic and tramp your SSL to get a lot of compressed js and ajax traffic.

So... maybe this was only needed or relevant before have direct access ?

MITMing a Google server doesn't _necessarily_ mean that they want the info Google has. Google host a number of libraries such as Analytics and jQuery which are widely used on other sites. The attack could have been to send a modified version of those so that websites (other that Google) transmit information that is normally kept on the client (e.g. sending the key to the NSA in an app that normally does client-side encryption).

Great point.

Then I understand better the relevance. Thanks.

The ephemeral session keys should protect against the MITM attacker getting anything but another encrypted stream of data, right?

No, MITM works by spoofing identity. Certificate pinning is what can protect you from a MITM with the ability to sign certificates that say "google". Ephemeral keys only protect the session from being decrypted by a passive adversary.

Only if you can prove that your ephemeral session keys were negotiated with the intended destination. With a MITM, here's what you think is happening:

  Encrypt Outbound ==> Decrypt Inbound
     at Source         at Destination

  Decrypt Inbound <== Encrypt Outbound
     at Source         at Destination

The ==> and <== indicate secure steps. How do you know your secure connection isn't with the Attacker who then transparently proxies all communications back and forth using a separately negotiated secure connection with the Destination? To you it looks secure, but in reality what happens is this:

  Encrypt Outbound ==> Decrypt/Intercept --> Re-Encrypt  ==> Decrypt Inbound
   at Source              at Attacker        at Attacker     at Destination

  Decrypt Inbound <== Re-Encrypt  <-- Decrypt/Intercept <== Encrypt Outbound
     at Source        at Attacker       at Attacker          at Destination

The --> and <-- indicate nonsecure steps. This happens through all phases from SSL handshake to streaming of data and, if the Attacker is able to use a certificate that you trust, the interception will generally go unnoticed.

Some security solutions actually rely on doing MITM to read secure packets to identify malware, etc. Really stupid.

One more reason to not use any of the giant email providers like Yahoo, Google, and Hotmail.

Your small email providers (or your datacenter or ISP if you host your own) are still subject to the laws of the country in which they reside and will comply with legally valid court orders. Alternative email providers will not protect you. Only encryption can do that. (Or better legal protections for emails.)

You are the sole person responsible for the security of your communications. You simply cannot trust any third party to keep your communications secure. Public-key crypto goes a long way here.

And what makes any smaller providers any more safe?

A smaller provider with fewer clients probably provides a lower ROI for the NSA because of the economy of scale, although if they are specifically targeting you, it may still not make a meaningful difference.

There is a trade-off here, sure there are fewer people that they can listen in on like that but presumably a smaller provider will also be a softer target, possibly much softer.

I don't understand your question.

Bigger targets are always more interesting for mass surveillance, because, by definition, they have more users.

And that's what the recent revelations are all about: Mass surveillance.

Obviously, bitter targets are also more interesting for private/non-NSA/non-state hackers.

That one piece of news is about corporate spyonage, not mass surveilance.

The size of the email provider wouldn't make any difference.

Actually, they can be quite a bit safer. If they're small enough the NSA might not have any existing targets on them, which means they won't have tried to find a way to intercept their traffic yet. They could just do SSL traffic inspection, but it's too costly (and practically impossible) to do that everywhere, so they have to do it on specific target networks, which involves a lot of work to get the thing in the right place on the network.

It would be a huge pain in the ass to cover all the smaller providers.

One thing the leaks have reveal is that the NSA invested significant effort in compromising/backdooring hardware. Now if I were intent on compromising hardware to increase my reach, my prime targets are going to be the makers of routing & switching hardware. Someone like Cisco perhaps.

Do you have any idea how many such hardware blackboxes lie between any two locations on the net? All that would be needed is a single vulnerable/backdoored one in that path, configure it to DNAT & SNAT through your MITM host ..

I highly doubt there're very many places out of that reach. Especially not smaller providers.

edit: s/setups/providers/g

When you start going down that line of reasoning, virtually every chip in every computer in the world "could" be backdoored. Again, the costs and technical challenges of doing this wholesale across a long line of products across many hardware vendors is practically impossible. I'd be more worried using Huawei gear, anyway.

At this point I might just feel more secure running Huawei gear (as I type this at home on a Lenovo Thinkpad connected to an Aerohive access point plugged into a Cisco ASA firewall).

Bucket Brigade is a better term for this kind of attack. Non-gendered speech and all.

Reply on news.ycombinator.com