I know we could SSL sigaint.org, but if it is a state-actor
they could just use one of their CAs and mill a key.
Please don't use that argument. It's like not putting a lock on your door because thieves can just bust it open anyway.
It's true at face value, but you are ignoring that a) it keeps smaller attackers at bay and b) it makes noise when it breaks. In case of SSL the noise is that a user receives a valid but unusual certificate, which can be caught by something like the SSL Observatory (http://tor.stackexchange.com/a/1879).
Yeah, the fact that they would make such an argument is a big red flag to stay away from their service.
There are currently zero known cases of intelligence agencies forcing CAs to sign bogus certs. If SIGAINT is the first victim of this approach then they will have done the whole security community a service by catching it and the CA that was coerced will be revoked.
But if they never use SSL at all then it's wide open to anyone at all, not even just governments. And it's hardly like governments are the only threats against people who use such services.
I don't see any evidence of an intelligence agency being involved or of the CA being forced to sign the certs.
>ANSSI has found that the intermediate CA certificate was used in a commercial device, on a private network, to inspect encrypted traffic with the knowledge of the users on that network.
Fair point. I think the American TLAs know that the very day they are even once caught red-handed with a bogus CA-signed cert, the browser vendors will quickly start beefing up security with measures like DANE, making any attack on HTTPS even harder. This could also be disastrous to the breached CA's business, if browsers start rejecting it, which in turn could have major political implications - the overall revenue of the American CA companies measures in billions.
Surely they would have otherwise already done it, right? They certainly have the capability to compel a CA to do it.
Aside: There are literally dozens of CA keys baked into end user applications. An intel agency would only need to force some specific CA to sign a bogus cert if that agency somehow managed to not have the private key material to any of them. Any one will do to turn the padlock green, and that cert can be injected in a very targeted way.
The agencies complained a lot in the 90s about this technology, then they stopped complaining. So, they've either stopped doing their job, or ...
There's tons of CAs that can subvert security for most sites using SSL but also, if any of those CAs are caught issuing a bogus cert, which the cert presented to the user is proof of, they will be immediately blacklisted like DigiNotar and suddenly a whole CA is gone just for getting caught using it once.
Catching one of these forged certs "in the wild" is harder if it only ever appears on the targets connection. If they happen to be anyone other than the fraction of a percent of users who understand things like "pinning", it is very low risk (today at least).
The ability to generate a CA cert trusted by a consumer CA store is a valuable asset that, like any intel asset, must be rationally deployed.
And yet, TrustWave gets to keep their certificate despite doing the same thing intentionally (as opposed to accidentally through incompetence). The system does not work.
Nobody is going to stop one trusting of the huge CAs like DigiCert or Verisign over something like that. It'd be like deciding you're not going to use Windows because there is a bug in it - you're too dependent on it to give it up and the alternatives are just as bad.
If Verisign was discovered to be routinely minting fake certs for the US Govt then they would be revoked. It would probably take over a year and involve huge amounts of pain but yes, it could be done. CAs sell a commodity product and are entirely replaceable.
Who is too dependent on Windows and has no superior alternatives? This is a laughably weak argument that's getting weaker every day. It sounds like a personal problem.
I've continued to inflict Linux upon myself as my main (laptop!) OS for 12 years now, but you're deluded if you think it has any place on normal human being's computer. Windows works and is expected.
Expecting the user to spend hours/days learning a new system for reasons that aren't their own is bad assumption to make.
They don't even provide evidence as to why they think a state-actor is targeting them. The message seems like it was also built to promote their service.
Thar argument also assumes SSL using the traditional CA model. A self-signed certificate would completely eliminate a state actor or other rogue CA, as long as you have some other secure channel of disseminating the correct certificate publicly.
Trusting math alone is not enough. One of the reasons the CA system works is that there is a person who can be in the loop when things go cactus. With things like keybase, if your certificate gets compromised, that's it, game over man, game over. CAs, you can get certs replaced and the compromised certificate becomes worthless.
However, this does show the need for a generic method of certificate pinning. Using a DNS record type or the like would be able to add to the trust model, and make it much harder for a malicious actor to use a fake key, all without tying your trust database to a financial transaction.
the diversity here is interesting. My hunch is that we are looking at 38 popped boxes.... The question to me is: Do they all have something in common? What was the vector of compromise?
Curiously enough, they all run Debian stable (according to the SSH version string "SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2” ALL of them spit out on port 22 — no exception!).
Attacks like that are easy to spot and easy to shut down. New exit nodes gain trust over time, so having a bunch of brand-new nodes is not as useful as having a few dozen old, trusted nodes. This looks like an experiment, not an attempt to take over the network.
> While these relays account for 6% of the total number of exit relays, they only sum up to 2.7% of exit probability, which is what really matters.
If that probability is on a per-tor-session basis, that is actually not very in favor of the user. My combinatorics are a bit rusty, but wouldn't your odds of being in the 2.7% increase significantly each time you use the tor network?
Your Tor session should change exit nodes at least once every 10 minutes.[1] Ignoring everything else (e.g. pressing the new session button on TBB, restarting the browser, failed connections etc.), this gives us
p(using a bad node)=1-(.973)^(t/10)
where t is how many minutes you've been using Tor. So if you've actively used Tor for more than 4 1/2 hours over the past month, it's more likely than not that you've used one of these nodes.
Entry guards do nothing for bad exits... sticking to particular exits across sessions would significantly harm your privacy in a way that entry guards do not.
Right! I mean cumulatively, after connecting 25 times, you have a 50/50 chance that at least one of those connections went through one of these nodes. (1 - 0.027) ^ 25 ~= 0.5
Nit: I think that should be 1-(1-.0.27)^25 ~= 0.5. Obviously it ends up being about 1/2 either way, but you're measuring the chance that you used one of the nodes, not that you avoided all of them.
Interesting analysis. And that's absolutely correct, the exit probability is what makes the difference.
It could be that they were all popped boxes running the same config, or it could be basic devops making sure all boxes setup have the same config. Both seem equally plausible, IMO.
I'd guess all of them are VPS instances. When you order a VPS, most hosts will run a full OS update before delivering it to you. (this is a feature of cloud-init, which is fairly standard) So, if you ordered all Debian instances at the same time, they'd all have the same SSH version string even if you didn't do anything special.
The guy apparently sells the SSL for an account upgrade[1], which IMHO is kinda bad practice. The SSL is the only thing keeping away low and average level attacks easily.
> The attacker doesn't seem to be after passwords (they probably have some of them now). We get less than 1 user of 42K complaining about their account being hijacked every 3 months.
Hm, I wonder how many of the 42k users have paid for an upgrade. I always had the feeling that many services would have a considerable amount of users/clients if they had a counter-part running on TOR and accepting bitcoins (or any alt-coin).
> The SSL is the only thing keeping away low and average level attacks easily.
The password is meant to authenticate the user to the server; the user is meant to authenticate to other users through the use of PGP. In theory it shouldn't be too big a deal to lose control of your password, because your emails should all be encrypted. (Though theres certainly a lot of metadata that someone with your password could glean that you'd much rather they didn't.)
It is possible to run a Tor node as an exit enclave[0], ie. a node that allows exits to its own IP address on specific ports. For example DuckDuckGo runs a Tor node with the IP 184.72.106.52 that allows exits to 184.72.106.52 ports 80 and 443.
However newer versions of Tor do not honour enclaves for various reasons.
The Tor software doesn't encourage people to make this decision (based on the developers' judgement that random path selection is safest for most users and for the health of the network), but you can configure it to use (or not use) particular exit nodes by editing the Torrc file. Historically you could also see the particular path, including geolocation of the relays you were using, with the Vidalia software, and also pick a particular exit for a particular connection with the ".exit" address notation.
So although the Tor developers don't want to encourage most people to do it routinely, you can choose to view and/or select Tor paths if you really want to.
It's true at face value, but you are ignoring that a) it keeps smaller attackers at bay and b) it makes noise when it breaks. In case of SSL the noise is that a user receives a valid but unusual certificate, which can be caught by something like the SSL Observatory (http://tor.stackexchange.com/a/1879).