I think this is misleading. I now believe that the NSA has the private keys for substantially all SSL certs in use, and I expect that a non-trivial percentage of Tor nodes are run by the government.
SSL certs require cooperation of a trusted registrar even for the biggest companies -- Google's is signed by Equifax, for example. Given what we've seen in the last few days, requesting keys from the root CAs is a no-brainer.
For Tor, a bunch of attacks are possible by owning only a small percentage of all nodes. Recently, Tor was issuing a "call for relays" due to a dwindling number of participants that was endangering the network. Considering that Tor came out of Navy research, if you don't think they have a statistically interesting number of nodes, you're crazy. If they don't, it's only because they don't think that Tor is an interesting source right now.
TL;DR: Security depends on your threat model, and while I think that Tor and HTTPS provide strong protection from run-of-the-mill attackers, I don't think that either provides meaningful security if you're worried about the NSA.
> SSL certs require cooperation of a trusted registrar even for the biggest companies -- Google's is signed by Equifax, for example. Given what we've seen in the last few days, requesting keys from the root CAs is a no-brainer.
Getting a root's key does not enable them to decrypt the traffic. Getting the server's SSL private key USUALLY means you can retroactively decrypt, but it is possible (though uncommon) for servers to be configured to use ephemeral keys (EDH modes) which provide perfect forward secrecy (that is, the property that the session key can't be recovered even with later compromise of the server's long-term key).
Interesting sidenote: AFAIK there are no widely-supported (TLS 1.1 or below) methods of mitigating the BEAST attack while enabling PFS - those modes are TLS 1.2+ which isn't widely spoken yet.
This is all irrelevant though. The issue is with the tech companies giving them the plaintext data themselves. No amount of transport-layer encryption helps with that.
I can't update my original post now, but I stand corrected. I "remembered" uploading the private key with the CSR last time I went through the process, but must have misremembered. Well, that's some good news I guess. The NSA could still easily request the private key from the company, of course.
A certificate is an attestation (signature) by a CA's private key that a given PUBLIC key is yours, that anyone with the CA's public key can verify.
The CSR does not contain your private key.
NONE OF THIS MATTERS. This is not about bulk-decrypting SSL, though I'm sure NSA does that when and where they can, too. This is about coordinated, automated, integrated methods of transmitting the plaintext.
Why should they bother getting a key and scraping gmail's payloads when they could just have Google give them an API? Furthermore, this method would continue working perfectly even ifwhen services switched to ephemeral key modes that provide PFS.
A key thing to point out, all a root CA does is verify your public key. The NSA can't get Google's private key from Equifax and they can't even impersonate Google if the end user is using Chrome even if Equifax signed a cert for them. The reason is because Chrome basically checks to see if the cert matches up with a known good copy.
Also, if your platform supports it, Gmail has perfect forward secrecy meaning that even if the NSA records all HTTPS traffic to gmail and later demands Google's private key they can't decrypt any of that captured traffic.
Tor on the other hand is a problem. It has several fundamental flaws as you pointed out like by controlling some gateway nodes and a few others you can start breaking any sort of secrecy that you would get from Tor. Really the only good thing about Tor is that it's well known. I really wish Tor would just die and people would move over to something better like I2P where it's an anonymous network, not just a kludged together anonymous proxy with hidden services slapped on as an afterthought.
I was under the impression having the ability to subpoena a key or cert from either the CA or the company issued the cert would give the NSA carte blanche on decrypting any (encrypted) data they may have gathered by other means.
Since I don't seem to be understanding the associated technology as well as I thought I was, could you point me towards some relevant reading on this topic? How/Why are the current implementations of HTTPS considered to have perfect forward security?
With regard to your latter question, [1] gives a good overview on PFS in TLS. You'll need to exchange keys using (EC)DHE, essentially.
As for subpoenaing keys: Most CAs will allow for you to generate your key pair and certificate signing request on your own hardware. You'd then submit the CSR which the CA would in turn generate a signed certificate from. The private key should never be shared with the CA.
In order to eavesdrop on communications, the NSA would then need to subpoena each targeted company's key. Wide reach is easy (go for the 5-10 biggest fish), comprehensive reach nigh impossible.
I think you are in the risk of a man-in-the-middle attack if the website's private key is compromised. Someone forces a proxy server between you and the website, via DNS spoofing or ARP IP take over in the subnet. When you try to go to the website, you land on the proxy which has the website's private key (and the cert) to initiate SSL connection with your browser assuming the website's identity. The proxy then turns around to make another SSL connection to the real website on your behalf, ferrying data back and forth between two connections, capturing all your "secure" traffic.
With SSL, both parties negotiate synchronous encryption (like in AES) and key exchange (like in RSA) for that, the trust is established with signed certificates obtained from a 3rd party. Which is/was fine on paper and concept, the implementation sucks and we don't have alternatives to that.
With any CA's (or better, the right one's) private key, they could still use it to stage a MITM attack on the website, assuming they have the right access.
All Convergence does is delegate to another 3rd party, which may lead to the conclusion there may be an attack in progress, that you may not have noticed before. You still have to trust another stranger that may offer you some perspective on issued and signed certificates (or not).
Convegernce i.e. refused to work with CDNs which may have different certificates for the same domain for example, which may be completly valid.
The key of public key crypto (like in RSA) was to make key management easier and independent of a 3rd party, to avoid further bloat, overhead and complexity.
This is the same for Certificate Transparency/Pinning mentioned earlier, given the details it looks very strong on paper, but the implementation will suck in r/l terms.
The important part of the diagram for Tor is the first NSA character, as you can see it still shows "Location" before you are routed through the Tor relay.
With the location information it is possible to correlate the exit information via pattern matching, though it would take considerable analysis, this can be done by logging volume and timing information on the two sides. I am sure there are even better techniques to analyze exit/entry correlations, especially if you're not using a secure browser.
So having a private VPS doesn't really matter, in fact it can make matters worse because you are adding layers that can be "watched" before you hit an entry node, the more data that can be logged the easier it is to track.
You're best option is to choose random nodes, connect at random times and also look into using Tor bridges. If possible using several different IPS's or even better random wi-fi hotspots, though this is hardly convenient for most users.
> With the location information it is possible to correlate the exit information via pattern matching, though it would take considerable analysis, this can be done by logging volume and timing information on the two sides. I am sure there are even better techniques to analyze exit/entry correlations, especially if you're not using a secure browser.
I've thought the same. But I've also thought that if this is indeed possible, why does Silk Road still exist? Or does this analysis only apply Tor clients connecting to websites, and not Tor hidden services?
Hidden service routing works quite differently that regular exiting traffic. Twice the number of relays are involved, and the traffic is end-to-end encrypted instead of being visible to any relay (such as an exit node). Correlation attacks are always possible to a global passive adversary (which NSA may or may not be), but as far as I can tell, they seem much harder to pull off against hidden services.
AFAIK Silk road just deals in a bit of drugs (relatively low volume too, all things considered).
For intelligence agencies, having evidence (even if inadmissible) of smaller crimes, is just leverage -- and leverage against people that might be able to render useful services (eg: provide deniable assets for framing someone with drugs).
Now, if Silk Road did most of it's trade in weapons grade plutonium, things might be different.
Remember, the whole reason the NSA-thing is a news story, is that it is illegal wire tapping. The feds can't use this for setting up a case.
An excellent illustration for those already familiar with the concepts.
However, I not sure its that easy to understand for those who don't know what "location" means, and the text is slightly small and hard to read. It would be a great improvement if they showed a small help text if one hovered over a label inside one of the yellow boxes.
The term "IP address" would be similarly confusing. What would help is if they explained in context what it means, for example when a lawyer of one's ISP knows about location and site (possible termination of contract, providing it to NSA, selling it and so on).
Also, using a help window when hovering would be a quite better UX than a glossary.
https encrypts the host header (indeed all the http headers), so yes it does encrypt the domain in that respect. What it can't encrypt is the destination IP address, which would be reverse looked up to the domain if everything was configured right in the DNS.
Seeing as HTTPS sites could not previously share an IP address, making it obvious which site communications with any given IP address was directed towards, an extension was developed that now sends the desired host unencrypted before the encrypted package.
This doesn't yield any more information that could previously be derived, but does allow you to serve as many HTTPS sites from a single host as you wish.
Most https clients support server name indication (http://en.wikipedia.org/wiki/Server_Name_Indication), which effectively allows the "Host" header content to be presented before a server-side certificate is chosen (and therefore before the session is encrypted), to supported name-based virtual hosting.
Do you have any sense how many nodes (or I guess how much bandwidth or even something else I'm not thinking of) it would take to make a material difference on the speed of the network?
Maybe I'm misinformed, but I thought the big problem has less to do with data in transit than it does with the destinations (Google, Facebook, Microsoft, etc) working hand-in-hand with the NSA? What am I missing?
As long as you aren't using a service with your actual data.
If I use Tor to connect to facebook and input my personal information, Tor is only protecting my data in transit. The NSA can still request the data from my account from facebook.
With a Tor hidden service, the NSA cannot necessarily find the service provider. Of course, neither can I, so there is a whole different set of threats (and it could be the NSA providing the service in the first place) but it does help a little with this specific problem.
Nothing, but they would still not know where the traffic is coming from. The "Onion" defined in the Tor protocol is unwrapped layer by layer by each node. So the NSA has a choice where no option would help them too much:
1. Be the first node you access and be able to see your IP but not your traffic
2. Be the last node and be able to see your traffic but not your IP
3. Be a middle node and see neither
I don't believe that's possible. If they have two nodes then they're still not a part of a defined path. For instance, someone can go through their entrance node and come out someone else's exit node and vice-versa. The NSA would have no idea who is going through where and shouldn't be able to correlate the data.
Frankly, I think you have to assume that the NSA is already doing this. I also think you have to assume they have the private keys for every major CA in the world.
Worth noting: Having the private keys for all the CA's in the world just means that they could launch a man-in-the-middle attack against a secure service. (Which would be easy for a rudimentary traceroute to detect.) Not that they could decrypt SSL traffic talking directly to my server, for example.
The susceptibility to this kind of attack is a big part of the knock that a lot of people have against HTTPS. It's generally been ignored as "too hard to pull off" - but it's also generally been assumed that your own government won't bother recording your communications without probable cause.
Anyway, unless they were targeting a specific service (which they usually aren't, they usually target a person) it would require too much effort to set this up for all the secure services they use.
Security professionals have hypothesized many attacks against the anonymity of the tor onion and what you describe is pretty close to one of them.
If the NSA was to create tons Tor nodes (enter, exit, and relay), the onion may be broken.
Tor is by no means perfect. It is only obfuscating.
It is easy to see how this is broken if you click the TOR button on this thing and then imagine the TOR nodes say NSA on them.
I think it is more fun to imagine security this way (extremely challenging and like you are protecting yourself from the perfect attacker, and the NSA is a good face to put on the perfect attacker). People don't realize how much trust they are putting in their hosting provider, cell carrier, etc.etc. It's insane.
There isn't really such category as a tor 'enter' node. Any node can be the first node of the chain, but it has no idea whether it is the first or one in the middle of the chain. Essentially, it's as if the 'entrance node' is running on your computer.
That means that no node knows the source of the traffic, and only the exit node knows the destination.
For the NSA to effectively monitor Tor, they'd need to run a large proportion of the nodes - one paper thought it would require an attacker to run at least one third of the network.
If the NSA has the logs of ISPs that carry one third of the world's traffic, couldn't they execute the attack without running any Tor nodes? Or am I misunderstanding the onion protocol?
How legal is operating a Tor node?
I'm thinking of putting up a machine (and a VPS) to just run a node.
I just don't want to get into legal trouble for running a(n exit) node.
Running a regular node is fine as you're routing encrypted information for the Tor network - your unlikely to get any hassle although check your countries laws on crypto first.
Running an exit node may be a different story. You could get false DMCA takedown notices or get charged with someone else's crime. Think of it this way; you're running an open proxy. Uses of Tor can send any traffic through your connection. That being said, some ISPs are ok with it, others won't tolerate it.
Bitcoin transactions are chained, that may compromise you.
But you could use an anon currency-exchange or currency-bridge like paysafecard.com to obtain some value and obtain bitcoin with that value and never use that bitcoin key again to avoid that.
If not there should be. You send X amount of bitcoins to a middle man who then gives you X amount back. Technically they will be different coins and they'll go to a different account #, so you can't trace anything.
That's not the issue, in general. The issue is more that a lot of hosting providers will close your account to cover themselves and avoid having to deal with the potential liability.
If you don't want to deal with possible legal issues running an exit node you could get servers using an anonymous prepaid credit card and made up contact info. If LE ever subpoenas your provider you can just shut the server down and abandon it.
Why does the graphic portray police as mean angry people. Police are good people who provide a valuable service. They do a good thing. They are not the enemy.
No, they don't, they do a bad thing. In actual fact, all cops are bastards. Their primary function in society is to defend the property rights of the capitalist class against the working class, thus preserving inequality.
Ignoring for a moment the validity of this statement, can I ask why you visit a site that is primarily about business news/Silicon Valley Hacker errata if you're not a fan of the 'bourgeois'?
Because it's Hacker News, not Bourgeois News. And I know this site is tied to an ideology that reimagines the "DIY" (for want of a better term) aspect of the hacker tradition as a kind of pro-capitalist (or at least "DIY capitalist") thing, but I don't think most hackers are capitalists, even on this site. For me, anti-authoritarianism has always been a central tenet of the hacker tradition, which for me goes hand-in-hand with anti-capitalism. I acknowledge that most hackers are not explicitly/consciously anti-capitalist.
Assuming the NSA is tapping ISP cables, and siphoning all unencrypted data of the web, and that they need to ask the big companies in the slides for the encrypted data, would EFF's "HTTPS Everywhere" help with all the websites that are not encrypted, like say Reddit?
I thought "HTTPS everywhere" is just switching your connection from HTTP to HTTPS when the site you are visiting is on the list of sites known to support their services over HTTPS.
That's hilarious. I guess the EFF knows that most of it's supporters are sysadmins, ironically the one class of people with the most direct and unfettered ability to violate privacy--and a track record of having done so.
Since nearly every Tor-exit has working reverse-lookup or by using https://check.torproject.org/ it is easy to deny access to Tor-users while authenticating.
I'm sure they can "ask nicely" to get a working cert from a CA. It's why newer versions of browsers are implementing certificate pinning, which should help (but not solve) with the issue by locking the browser to a specific certificate.
I would continue under the assumption that they can and do. If confidentiality and authenticity is mission critical, you need to be using a hidden service rather than relying on SSL. A hidden service does not exit the network and does not rely on external validation.
If you're running secure site, you should use your certificate & signature. Even then NSA could well be capable of creating fake certificate, but it would be expensive. But that would stop others without huge computing capacity. Of course this requires that you're able to deliver your own CA information securely to your site users. Also end users should disable trust for any browser/OS build-in CAs.
This has been my question in this whole mess, if we assume NSA can and does subpoena the keys and certs as opposed to the direct data (and the NSA were copying data en masse, which now seems likely) would that not make HTTPS essentially useless?
The NSA is not the average guy listening in on your wifi and then using your CC to buy stuff online. HTTPS protects against those, and it does so relatively efficiently.
Sorry, I should have clarified that it negates HTTPS in the context of the NSA (and presumably other government actors around the world), still great protection from getting your facebook session hijacked over wifi.
What about protection from the average NSA sysadmin or analyst with slightly less moral fiber than Edward Snowden? (or gambling debt, or a mental disease, or an obsession with your significant other etc.)
well, it is serious, in that it's the most likely weak point in tor. however, exactly how serious is still an open question.
remember - what the nsa wants is both your location and the site. your location alone only means that you were using the internet (and tor, which itself might be regarded a suspicious). the site alone only means someone was using the site. what the NSA have to do is connect those.
so everything depends on whether the two NSA people can "join up the dots" (graphically, in that diagram, the dark blue dots joining them). because there's nothing "obvious" that tells them that the message with the location is connected to the message with the site.
if they can't make that connection, then they don't know anything useful.
but if they can make that connection, then they know that you (well, someone at your location - an open wifi might give you a little deniability, for example) looked at that site.
the way they might be able to do it is by comparing traffic patterns. if they can show, for example, that every time you send a request, the site receives a request, and if that happens again and again, so reliably that it cannot be chance, then they can make the connection.
so it depends on things like the frequency with which you look at the site, the amount of (tor) traffic when you are around, and the ability of the NSA to assemble and correlate large amounts of data.
[disclaimer: not an expert; i don't know the current state of play on how bad a problem this is; i just know it's a known issue. and if i were going up against the nsa, i wouldn't trust tor alone - i'd use an anonymous, disposable, portable connection device, and keep data to an absolute minimum.]
Would it be helpful to run a forwarding (at least non-exit, possibly entry) Tor node on one’s own computer to mask the Tor traffic actually originating from this machine?
i think it might, but only at about the level of adding an extra tor hop (the NSA can compare requests in and out, and try to detect which ones out are extra).
We don't know. It slightly depends on how much worse things get in the US. You might get a permanent flag in "your file" as a potential troublemaker, but so might living in the wrong neighborhood, or going to the wrong bar, or being acquainted with someone under NSA suspicion. It's impossible to know what will or will not be put in the file, or which flags will give you grief (without you ever knowing why) when visiting an airport or when applying for a job.
They only see the location of the user entering Tor, which is only really an issue if using Tor itself is illegal, or they also control the exit node you are using. In the second case, it would be possible (though unlikely) for them to correlate the entry and exit through bandwidth and timing.
By location they mean your IP (from which they can get your address, by asking the ISP). As long as they can't links the two captured packets, they just know that you're using Tor.
Well your IP determines your location. That other evasdropper is from your ISP, since you first connect to your ISP and then Tor.
Your ISP potentially knows your location which is what the NSA evasdropper gets.
And since its shared with amongst both the evasdropper, potentially NSA knows your location even if you use Tor. They should have indicated that too I guess.
There is no level on anonymity, either you are, or you are not.
Addendum for achievement:
Connect to Tor from a public accessible network/wifi that is free from surveillance using a pristine installation and never use that network-device again.
Addendum 2: If you use the network device twice, you may achieve only pseudonymity.
Valid point that anonymity is a binary property, but, if you wanted to talk about levels you could perhaps measure the level of difficulty of finding your identity, or the likelihood of accurately doing so.
The tradeoff is the same as keysize in crypto. It is time.
If you choose to communicate a second time from the same endpoint with the same equipment you may achieve only pseudonymity.
Since Tor doesn't limit the encapsulated protocols, it depends on the implementation and awareness of the user and you can't put a number or percentage on that.
Imho the Tor-role has changed, it provides access against censorship, DPI, region-partioning and hidden services.
Simply try to access youtube or any other global service via different tor exits, that may be intresting, not from an anonymity point of view.
There may be information leaking (as in fingerprinting) from your device (that you are not aware of) that would allow very easy correlation, like in a mac address or existing session cookie, similar address in a public open network or whatever you can imagine to compromise your anonymity, that gives an adversary any advance to successfully correlate your current session with one of your previous sessions.
At this event your anonymity becomes a pseudonym.
The next step would be to try to reproduce or predict behavior and setup a trigger for that information.
If the loss (compromise) of anonymity or pseudonymity may lead to imprisonment, torture, assassination or death this maybe an issue to consider.
If you try to obfuscate your access to porn, it is a completly different story.
SSL certs require cooperation of a trusted registrar even for the biggest companies -- Google's is signed by Equifax, for example. Given what we've seen in the last few days, requesting keys from the root CAs is a no-brainer.
For Tor, a bunch of attacks are possible by owning only a small percentage of all nodes. Recently, Tor was issuing a "call for relays" due to a dwindling number of participants that was endangering the network. Considering that Tor came out of Navy research, if you don't think they have a statistically interesting number of nodes, you're crazy. If they don't, it's only because they don't think that Tor is an interesting source right now.
TL;DR: Security depends on your threat model, and while I think that Tor and HTTPS provide strong protection from run-of-the-mill attackers, I don't think that either provides meaningful security if you're worried about the NSA.