SIGAINT email service targeted by 70 bad TOR exit nodes | Hacker News Reader

SIGAINT email service targeted by 70 bad TOR exit nodes

lists.torproject.org

181 pointssp33253 comments

    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.

>There are currently zero known cases of intelligence agencies forcing CAs to sign bogus certs.

https://www.eff.org/deeplinks/2011/05/syrian-man-middle-agai...

https://www.eff.org/deeplinks/2011/08/iranian-man-middle-att...

http://securityaffairs.co/wordpress/32469/hacking/china-runs...

http://thehackernews.com/2014/10/chinese-government-executes...

> https://www.eff.org/deeplinks/2011/05/syrian-man-middle-agai....

> The attack is not extremely sophisticated: the certificate is invalid in user's browsers, and raises a security warning.

> https://www.eff.org/deeplinks/2011/08/iranian-man-middle-att....

DigiNotar was compromised, not compelled.

> http://securityaffairs.co/wordpress/32469/hacking/china-runs....

> the connection was established with a self-signed digital certificate.

> http://thehackernews.com/2014/10/chinese-government-executes....

> but the company’s SSL certificate is replaced by the intruders for a self-signed one

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.

France did it:

https://nakedsecurity.sophos.com/2013/12/09/serious-security...

http://googleonlinesecurity.blogspot.com/2013/12/further-imp...

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.

Most of those are not cases where a CA was forced to sign anything, that's just the government using their own untrusted CA.

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.

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.

Most normal users.

The 90%+ of computer users who have no idea how to install a different operating system?

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.

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.

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.

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.

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.

> The agencies complained a lot in the 90s about this technology, then they stopped complaining. So, they've either stopped doing their job, or

.... or they realised that nobody was deploying SSL outside of login forms and credit card purchases.

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.

I think it is mostly a result of their threat model -- they're a service which seeks to make things harder for those entities in particular.

not only that, but Chrome can pin certificates: chrome://net-internals/#hsts

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.

I wonder if keybase.io would work

And how are you authenticating keybase.io? SSL?

No, with a merkle tree and bitcoin: https://keybase.io/docs/server_security/merkle_root_in_bitco...

So we're basically just trusting keybase.io to do verification, instead of the CA system, Why them and not anyone else?

No. We're not. We're trusting math.

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.

> if your certificate gets compromised, that's it, game over man, game over.

We must choose between either "compromised -> scorched earth" or "compromised -> social engineering jackpot".

If you can distribute the key, you don't need to use a self signed. You can get a CA signed key,and distribute that, which is strictly more secure.

From an email further down in the thread https://lists.torproject.org/pipermail/tor-talk/2015-April/0...

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.

Almost all of them were younger than one month and they seem to have joined the network in small batches.

https://lists.torproject.org/pipermail/tor-talk/2015-April/0...

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!).

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.

70 exit nodes less than a month old all running the exact same config doesn't seem like a state actor to me.

Lizardsquad had thousands of exit nodes spun up all running the exact same config. It doesn't take state actor effort to do this.

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?

After 25 times, you'd have a 50/50 chance of having gone through those nodes at least once.

I don't think so because the chance of using a node is an independent event. So you will most likely have the same chance every time.

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.

Tor uses entry guards [0] to mitigate this kind of an attack.

[0]: https://www.torproject.org/docs/faq.html.en#EntryGuards

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.

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.

[1] https://www.torproject.org/docs/faq.html.en#ChangePaths

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).

[1] http://sigaintevyh2rzvw.onion/upgrade.html

> 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.)

The MITM could insert malicious javascript, or delete all your emails.

And PGP doesn't encrypt the subject.

Re: State level actor

How much does it cost to rent 70 boxes? Not that much I imagine.

Maybe a dumb question, but would running Tor exit node(s) on their own server(s) help in this situation?

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.

[0] https://trac.torproject.org/projects/tor/wiki/doc/ExitEnclav...

Reply on news.ycombinator.com