Hacker News Reader

Comment by kyro | Hacker News Reader

Is this information the NSA could've attained left to their own devices, or is this sort of stuff only accessible with help from service providers, eg Facebook and Google?

What I'm trying to ask is: with all the hullabaloo Google, Facebook, Yahoo, Microsoft, etc have made about individual, manual reviews of information requests, are we still being lied to? I suspect that we obviously haven't been told the whole story by these companies, and that they are a lot more implicit in this than they let on, but this article seems almost like definitive proof that they did indeed allow unlimited access to user information.

If this is saying what I think it's saying, then I feel seriously back stabbed by the startup darlings -- Zuckerberg, Brin and Page, etc -- that so many people here love and idolize. They should absolutely be held accountable.

View on HN

If you can tap large Internet connections then you can siphon off all HTTP and SMTP traffic and from there it's trivial to reconstruct sessions and from there get application level stuff.

I was doing similar things in the mid-1990s on shared Ethernet. It's really only a question of speed and scale and then of writing code that recognizes particular traffic (such as "this HTTP connection is a Facebook chat session").

Interesting. So then this can be done with zero assistance from service providers? Could providers have taken any steps to render that stream of information inaccessible? And if so, is it a costly effort?

Yes, use HTTPS for everything. It's not a surprise that all the logos in this PowerPoint have since moved large portions of their traffic to SSL. SSL isn't perfect (you can still see what domain someone is requesting), but it does prevent a lot of the snooping outlined in the presentation (without vendor participation, it's always possible that Facebook is siphoning off their messages).

Why would we assume that TLS is safe? The NSA could just as easily compromise the CAs and get all the certificates they need.

Not exactly. Compromising a CA would let them fool a browser into thinking that a fake Google certificate is a real one. However, if Google were diligent, they could publish their valid cert signatures anywhere they like, and users could check the signatures of the certs that are presented as genuine.

The TSA can't crack or impersonate a cert at will; they can only 1) try to trick you into accepting a phony one or 2) demand/steal the private key from the site.

Wouldn't having the private cert allow you to decrypt all communications encrypted using that cert?

Traditionally you generate an SSL public and private key, and send only the public key to the certificate authority for signing, so compromising the certificate authority doesn't give you the private key.

It does however give you the ability to issue yourself new public keys to conduct man-in-the-middle attacks [1]. If you compromise the same CA as the site whose traffic you're trying to intercept, you can bypass certificate pinning which is supposed to detect MITM attacks. So for example you can MITM gmail without certificate pinning detecting it if you compromise Verisign, Equifax or GeoTrust [2]

[1] http://googleonlinesecurity.blogspot.co.uk/2011/08/update-on... [2] http://src.chromium.org/viewvc/chrome/trunk/src/net/http/tra...

Google is actually quite diligent in this regard and have caught CAs with their pants down in the past.

They're taking it a step further and using certificate pinning in Chrome to catch MITM attacks in real time across a large portion of the internet. http://blog.chromium.org/2011/06/new-chromium-security-featu...

It's not scalable at all, but cuts out a large attack vector for a lot of communications. It wouldn't take a ton of pinned certificates to make a big dent in these NSA programs--really just look at the logos and make sure that each has their certificates pinned.

So let's assume the NSA still has these capabilities (a fairly reasonable assumption), and with SSL/HTTPS as a fairly feasible security option, how would these capabilities be possible? Either services aren't committed to and endorsing the use HTTPS/SSL and/or they are actively granting access to user information. Are those two reasonable conclusions?

I'm trying to understand why services are not taking a more active role in protecting their users' information if they are claiming to taking our privacy seriously.

To me, it comes down to being either incompetent or a liar, or both.

Did nobody look at the PowerPoint itself? From page 17 (http://www.theguardian.com/world/interactive/2013/jul/31/nsa...):

> * Show me all the VPN startups in country X, and give me the data so I can decrypt and discover the users.

> * These events are easily browsable in XKEYSCORE

As I understand it (and I may be wrong), most encrypted VPN traffic uses SSL. Given that XKeyscore data is only held for a few days (due to the immense volume) and given how nonchalantly they just throw out that they can decrypt VPN traffic, it sounds to me like they've either got the root SSL certs and are MITM'ing every connection they can or they've somehow broken SSL, either by breaking the actual encryption used or by exploiting vulnerabilities in how browsers handle it. If that's the case, then they don't need to ask Google or anyone else for your data, they can just read anything they want.

Poul-Henning Kamp: """With expenditures of this scale, there are a whole host of things one could buy to weaken encryption. I would contact providers of popular cloud and "whatever-as-service" providers and make them an offer they couldn't refuse: on all HTTPS connections out of the country, the symmetric key cannot be random; it must come from a dictionary of 100 million random-looking keys that I provide. The key from the other side? Slip that in there somewhere, and I can find it (encrypted in a Set-Cookie header?)."""

http://queue.acm.org/detail.cfm?id=2508864

That's an interesting idea.

Even better would be for the NSA to penetrate Thwate, Verisign etc and make the keys they "generate" non-random (perhaps only for a subset of certificates sold)

Yes, it seems like they have broken VPN or SSL in some way.

Perhaps they own or subsidize many of the cheaper VPN like has been rumoured for Private Internet Access? https://www.privateinternetaccess.com/

Uh, no. We aren't subsidized by the NSA or any part of any government or any organization or person for that matter. We bootstrapped Private Internet Access with 500$ and a lot of caffeine and have been profitable since our second month in operation.

We believe what the NSA is referring to when talking about "VPN startups" is the initial stages of PPTP sessions. PPTP has been crackable for a while, check out moxie's cloudcracker.com. We believe it highly unlikely that they have broken OpenVPN (which is what our application uses) or SSL.

Please see our stance on PRISM: https://www.privateinternetaccess.com/blog/2013/06/prism/

My question is, if they did this, why did each company have it's own join date in the prism timeline? wouldn't it just all happen at once? if they were tapping pipelines then the data would be collected regardless of the system, yet they all had very distinct dates that they were onboarded.

The PRISM program, which requires cooperation from service providers, is just one of the methods they use to collect user data. "Upstream" collection (beam splitters on fiber, etc) is separate and distinct from this, and yields a different set of data.