Encouraging a wider view [LWN.net]

Encouraging a wider view

Posted Oct 1, 2013 13:24 UTC (Tue) by intgr (subscriber, #39733)
In reply to: Encouraging a wider view by dlang
Parent article: Encouraging a wider view

> this is only true if you can validate who the key belongs to

I meant to say if you control *both* endpoints, then it's easy to detect altered traffic by simply comparing the data sent from one end and data received on the other end.

And it doesn't matter that there are very few people actually checking it. Even if it's just some developers debugging SSL issues while developing an SSL library. If NSA (or anyone) was MITMing a significant portion of Internet traffic, someone, somewhere will notice that things are amiss. Once detected and reported, ISPs and middlemen can be forced to cease or explain what's going on. Organizations like EFF may get involved, like they did to detect BitTorrent throttling: https://www.eff.org/pages/switzerland-network-testing-tool

It's simply impossible to remain hidden if you do traffic manipulation on a large scale.

Compare it to our current situation with un-encrypted Internet: nobody has any who is eavesdropping what; there's no way to detect passive eavesdropping. Igorance is bliss?

> report from Ted Tso about how he discovered a MITM aimed at the MIT IMTP server

I can't find this report on Google, but it seems you're actually proving my point -- MITM will be detected if it's done on a sufficiently large scale. If the traffic was in the clear, there's no way at all that anyone could detect it.

The large-scale MITM attack in Iran against Gmail was also detected because encryption was used.

(Log in to post comments)

Encouraging a wider view

Posted Oct 1, 2013 13:38 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

they don't need to change any data as part of their MITM (the NSA wants to read the data, not change it), so just comparing what was sent with what was received would not help any.

Ted discovered this because he had the particular cert pinned (i.e. he knew who the cert belonged to), so when he saw a different cert, he knew something was wrong.

and the new cert that was being presented was 'valid', just not the correct one.

so this seems like exactly the case that having encryption without knowing who the cert belongs to would have done no good.

Encouraging a wider view

Posted Oct 1, 2013 13:51 UTC (Tue) by intgr (subscriber, #39733) [Link]

> they don't need to change any data as part of their MITM

The what? You can't eavesdrop on any modern crypto protocol (including SSL, tcpcrypt) without modifying traffic. Even if the connection is un-authenticated.

> and the new cert that was being presented was 'valid'

They had to swap the certificate. They modified the traffic. The modification was detected. Which was my point.

Encouraging a wider view

Posted Oct 1, 2013 14:55 UTC (Tue) by freemars (subscriber, #4235) [Link]

Exactly. An attacker (let's call her 'Nsa') needs to decrypt packets and re-encrypt them with her faked key. And this needs to be done in real time, or Nsa's cover is blown. This is a DoS attack against Nsa.

Encouraging a wider view

Posted Oct 4, 2013 18:01 UTC (Fri) by elanthis (guest, #6227) [Link]

> And this needs to be done in real time, or Nsa's cover is blown. This is a DoS attack against Nsa.

No. The NSA just needs to store the encrypted packets and then decrypt them later at their leisure. They've already admitted to doing this in many cases.

Let's not also forget that even with a MITM attack, they aren't routing all packets to their buildings for real-time decryption. They're still injecting the code to read the unencrypted traffic into the existing infrastructure (either at the end-points or at a common existing intermediary) and then streaming that data efficiently to their data stores.

There's nothing to DoS.

Encouraging a wider view

Posted Oct 4, 2013 20:06 UTC (Fri) by khim (subscriber, #9252) [Link]

No. The NSA just needs to store the encrypted packets and then decrypt them later at their leisure.

That's totally different kind of attack. Almost undetectable, yes, but also millions of billion times more computationally expensive.

They've already admitted to doing this in many cases.

The've admitted that they keep encrypted sessions but nobody knows how many of them they can actually decrypt.

And if they can “decrypt them later at their leisure” it's still “DoS attack against NSA” - just somewhat less effective.

Let's not also forget that even with a MITM attack, they aren't routing all packets to their buildings for real-time decryption.

It's the only way to perform a MITM attack, sorry.

They're still injecting the code to read the unencrypted traffic into the existing infrastructure (either at the end-points or at a common existing intermediary) and then streaming that data efficiently to their data stores.

There are no "common existing intermediary" if you, e.g. connect to Google from your home and they need permit from court to actually hack your computer. Yes, I know, they can hack Google itself and/or your computer but now we are at stage “asteroid can kill you any time thus it's pointless to watch traffic lights”.

Encouraging a wider view

Posted Oct 1, 2013 16:33 UTC (Tue) by nybble41 (subscriber, #55106) [Link]

> I meant to say if you control *both* endpoints, then it's easy to detect altered traffic by simply comparing the data sent from one end and data received on the other end.

This presumes that you have a secure way of knowing what data was actually sent, on a channel not controlled by the MITM attacker. If you have such a channel, why not just use that instead?

Anyway, "useless" was perhaps a bit strong. Unauthenticated encryption would make it more difficult to implement large-scale passive eavesdropping operations like the NSA's, but it doesn't offer any actual privacy guarantees. It's more on the level of security through obscurity, since it won't protect you against a determined, active attack. Given the choice, you should always authenticate. Certainly you should never transmit any truly private data without authenticating the receiver--you could be handing your secrets directly to your worst enemy and you'd never know it until it was too late.

If the information _isn't_ truly private, though, why bother encrypting it in the first place? Just raising the noise level to hide the real secrets?

Encouraging a wider view

Posted Oct 2, 2013 10:05 UTC (Wed) by intgr (subscriber, #39733) [Link]

> Unauthenticated encryption would make it more difficult to implement large-scale passive eavesdropping operations like the NSA's

You're missing my point. It's not just "more difficult"; it's extremely unlikely that they could get away with it on a large scale.

Even with unauthenticated encryption, they would have to perform active MITM attacks to eavesdrop on encrypted connections. There is no such thing as passive MITM, they have to decrypt and re-encrypt all data passing through. If it's done on a large scale, it will eventually be detected by tech-savvy users, even if by accident. Since you can collect evidence about the traffic manipulation, you can demand explanations from your ISP -- unlike passive eavesdropping, which is undetectable. You can tell them to stop altering data sent via a connection you paid for or lose business.

It would very likely force NSA to limit eavesdropping only to people being targeted, instead of the ubiquitous surveillance we have now. Yes, it won't "guarantee privacy", but it would make the majority of us more secure.

> This presumes that you have a secure way of knowing what data was actually sent, on a channel not controlled by the MITM attacker

Only in theory. In practice it's impossible to fool everyone all of the time about what traffic is being captured. Imagine tcpdump running over a MITMed SSH session; in order to fool the user, they would have to detect what packets are being printed out onto the console and substitute all that with the ones the person is "supposed" to see. Or what about Wireshark running over VNC? The attacker would have to re-render whole images passing over the network to cover up what traffic is being captured.

Not to mention that SSH does authentication (key pinning), so I don't think that's even on the table.

> Given the choice, you should always authenticate.

Yes, nobody is arguing against that.