I am not a network expert, but won't most of that data still be encrypted through SSL? If that is the case, it would be almost useless since sites like Facebook and Google have made the transition to defaulting to using SSL.
That may be true. However, the giant elephant in the room is the Utah data center.
This is a data center designed to, supposedly, store data on the scale of a yottabyte. I only say "a" yottabyte, because to assume even slightly greater than that is sheer lunacy.
That is freaking massive. If you took all terrorist cells and all terrorist activity for the history of terrorism and terrorist activity, you would not even touch a fraction of a percent utilization. We're talking rain drops in the ocean.
There is no way the NSA is merely watching the bad guys here. The data center is a few magnitudes too large for such a task.
I would assume right now they are merely recording all data, in hopes that one day they will have technology to quickly crack encryption. However, even without knowing what is said (the content), the metadata of connections gives plenty of information on what people are doing.
and yes, agreed - analogous on so many levels - a publicly admitted places where secret government things happen, which can be invoked to give an aura of reality to conspiracy theories true and false alike.
It's already been established that they redefine "collect" as a human actually viewing the data. The admit that they store roughly everything they can on everyone.
The yottabyte stuff is basically BS. HN user Jabbles found a possible source for that, which just says '''The target GIG supports capacities exceeding exabytes (10^18 bytes) and possibly yottabytes (10^24 bytes) of data.'''[0]
Exabytes are eminently reasonable; yottabytes are not.
A yottabyte would take 3.333×10^11 3 terabyte hard disks. A 3.5 inch hard disk has a volume of 376.77344 cm³. The NSA buildings in Bluffdale take up around 1.5 million square feet. That means just the hard discs for a yottabyte would be just a bit less than a kilometer high (901 meters). That's about a 100 meters taller than Burj Khalifa. I think it's unlikely it's designed for anything near a yottabyte.
Clearly they do not yet have a yottabyte worth of data. It would be silly to build a warehousing site like that and have it be full-up with data the day it first opens for business.
I expect these sizing claims (which presumably come from some sort of government statements about the facility) are based on a timeline on the order of ten years or more. A YB in 2024 is going to take a lot less physical space than a YB in 2014.
You'd need a 2-3 order of magnitude increase in storage density to get anywhere near reasonable. I suspect that's not going to happen in 10 years but I don't know the current and projected rates of storage density increases.
Based on that, it sounds like the yottabyte claims refer to raw, unprocessed data collected. Off the bat, I'm willing to believe in a 2 orders of magnitude decrease after data reduction techniques are applied to the raw data. My experience with data collected from telescopes was that we got about 100:1 reduction on the raw data versus what went into permanent storage.
The San Antonio site was news to me, though obviously no big secret since that book was published years ago.
Maybe they haven't filled it up yet. A quick search suggests the whole internet is on the scale of exabytes, so a yottabyte could store a million internets.
Well even ignoring the PRISM part and Google and all that, look on the slide again: "Collection of communications on fiber cables and infrastructure as data flows past"
Yes. Not only that, but Google and Facebook, both of whom have been tarred by the PRISM story, have gone way out of their way to make SSL/TLS more pervasive in the real world, to the point where their efforts are resulting in huge improvements to clientside software.
The problem is that cleartext can't be trusted in the cloud. The only way to really restore confidence is to enable truly private endpoint-to-endpoint secured real time and store-and-forward communication.
Email, however, would not be encrypted. As Google is one of the largest cloud email providers, this could provide a lot of information for the NSA. But I'm not sure Steve Gibson was correct in his assessment. Looking at that final PowerPoint slide from the PRISM deck, it seems that upstream tapping was occurring, but also mentioned PRISM as a separate program. It could be that PRISM was a related router tapping technology or something else entirely.
It depends on where the interception device is installed.
Most of the large-scale sites are doing SSL offloading, so one of the first things that happens is the traffic is decrypted. Often this happens in the front end load balancer.
If the set up is as the WP described:
> “collection managers [to send] content tasking instructions directly to equipment installed at company-controlled locations,”
and this equipment is installed behind the SSL offload devices, it would see all the customer data in the clear.
Nobody has ever presented any evidence ever that NSA has Google's SSL/TLS keys. Not only that, but Google has (a) pinned their public keys so that the browser binary itself can reject bogus- but- signed certificates, and (b) pushed heavily to enable forward secrecy in TLS, which means that even if you compromise their key, you can't decrypt sessions without being an active man in the middle.
That's one, but the basic mechanism --- deriving session keys from RSA-signed DH exchanges --- is old, and is simply a ciphersuite (Google deploys an ECC-version of it for performance).
That proposal is for an ephemeral, per gTLD client key and an example of mutual authentication that aims to defeat _active_ attackers (MITM).
Perfect forward secrecy in TLS is a bit different in that the ephemeral diffie-hellman key exchange sets up a shared key that is protected from a _passive_ attacker that observes the TLS encrypted communication and later gets a copy of the server's public key.
Not quite. Having someone's private SSL key doesn't necessarily let you read the contents of their SSL traffic due to forward secrecy. It does let you sign messages as if you were them, or MITM their traffic.
For instance, on HN, Chrome is currently doing this:
Your connection to news.ycombinator.com is encrypted with 128-bit encryption.
The connection uses TLS 1.2.
The connection is encrypted using AES_128_CBC, with SHA256 for message
authentication and ECDHE_RSA as the key exchange mechanism.
Using ECDHE_RSA, my browser and HN's server will agree upon a key to use for encryption using AES128 in CBC mode. Now in order to read what the server sends me and what I send to the server, you need to break the crypto:
1. Brute force the 128 bit key. This is.. probably not going to happen?
2. Via a weakness in the AES128 algorithm or implementation, you can simplify a brute force into feasibility (AFAIK, no such attack currently exists).
3. Via a passive attack on ECDHE_RSA, you could potentially guess the shared key efficiently and decipher our communications (AFAIK, no such attack currently exists).
So it's not quite as simple as recording encrypted information and obtaining the SSL keys. You need the server to actively remember the keys used for every encrypted connection, and obtain those, too. Or MITM everything and record the unencrypted data.
He says that for gmail for example, it would be encrypted from Gmail to Gmail user, but not Gmail to some other users, through SMTP, because then the data leaving Google is not encrypted anymore.
SMTP is inherently insecure which is why you are not supposed to use e-mail for confidential information. But SSL will still protect almost every other Google property from Search to Hangouts.
Although your post did bring up another question that I never thought about. Does Google even "send" email when it goes from one Gmail user to another? That could theoretically all be handled internally, but it never crossed my mind that they wouldn't use SMTP.
SMTP can be encrypted between servers (though not end-to-end) using STARTTLS, which is getting pretty common. If the mail's being relayed with STARTTLS, you wouldn't be able to read it by tapping the wire. Instead, you'd need to get access to one of the relays, since each one decrypts the message before reencrypting it for the next hop (or you could manage to get yourself inserted as a relay).
Looking at a random email in my Gmail account from a different Gmail user, it looks like they do use SMTP, or at least they are adding headers as if it went by SMTP. But both ends of the SMTP are at the same IP address:
X-Received: from mr.google.com ([10.229.72.135])
by 10.229.72.135 with SMTP id m7mr3900891qcj.17.1370903118607 (num_hops = 1);
Mon, 10 Jun 2013 15:25:18 -0700 (PDT)
