Advertisement
GStreamer Conference 2013, 22-23 Oct, Edinburgh
GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.
| |||||||||||||
Encouraging a wider viewEncouraging a wider viewPosted Sep 26, 2013 16:30 UTC (Thu) by freemars (subscriber, #4235)Parent article: Encouraging a wider view
re: the CA Problem One problem is our current https:// scheme confuses authenticated and encrypted, which aren't the same thing at all. I'm trying to push the need for a couple new web standards. In the familiar https: some certificate authority -- possibly squirming under the thumb of a Three Letter Agency -- swears blind the web site is the one it claims to be. In the new httpe: the website owner swears blind she generated the public and private keys and nobody else knows them (both). The website owner may be squirming as well; the hope is the various TLAs will soon run out of thumbs. Also, it's a lot harder to keep several million national security letters secret than 50. The httpe: webserver should do a couple other tricks to help security -- it should automatically generate new keys at irregular intervals (say daily-to-monthly plus once per reboot) to make brute force attacks less fruitful. It negotiates a session key with the browser client before a specific page is requested, reducing the amount of metadata that can be collected. It should be willing to carry a bit of water for the browser -- doing some Tor-style session forwarding to try to reduce man in the middle attacks. My final new web version would be httpes: where the web server and browser software establish an encrypted session first, then verify the web server has been blessed by some CA, and finally moves on to send the page. This is the standard I would want my bank to use.
(Log in to post comments)
Encouraging a wider view Posted Sep 26, 2013 17:02 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
> In the new httpe: the **MITM attacker** swears blind she generated the public and private keys and nobody else knows them (both).
FTFY. Encryption is pointless if you don't know who the decryption key belongs to.
> It should be willing to carry a bit of water for the browser -- doing some Tor-style session forwarding to try to reduce man in the middle attacks.
If you're using a Tor-style protocol in .onion mode (no outproxy) then you don't need any other encryption. The traffic is already secured end-to-end. You just need authentication, so that you know who you're talking to.
Encouraging a wider view Posted Oct 1, 2013 9:39 UTC (Tue) by intgr (subscriber, #39733) [Link]
> FTFY. Encryption is pointless if you don't know who the decryption key belongs to.
No! This is the fallacy that got us into the whole wiretapping problem in the first place.
The reality is, eavesdropping unencrypted traffic is simply too easy and too cheap. MITMing connections such that it doesn't break any clients/servers, is complicated. And most importantly, MITM is very easy to detect by someone controlling the endpoints.
While it's true that corporate and public access networks could get away with large-scale MITM, it would be unacceptable to do it on every end-user who pays for their own network bandwidth -- on the scale at which NSA is currently eavesdropping. And it simply cannot be done on someone else's network that you have compromised, without raising red flags all over.
Further, if your protocol initiates encryption *before* opportunistic authentication, then any MITM risks breaking this authentication if they don't know in advance. While the attacker could probe the server to check whether it provides certificates, there are edge cases that would still break. In the case of SSL, URL-specific client certificate authentication: the server renegotiates in the middle of a SSL session, after receiving the HTTP request to an authenticated URL.
All of this was already anticipated in a tcpcrypt IETF draft in 2011, but sadly the project looks dead for now. (Though there was some discussion about resurrecting it recently: http://www.ietf.org/mail-archive/web/perpass/current/msg0...)
Encouraging a wider view Posted Oct 1, 2013 12:48 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
> And most importantly, MITM is very easy to detect by someone controlling the endpoints.
this is only true if you can validate who the key belongs to, otherwise you have no way to detect the difference between a legitimate remote endpoint and a MITM endpoint
Yes, doing encryption even without validating the remote endpoint will raise the cost of doing a MITM, but is it enough?
I suggest that you take a look at the report from Ted Tso about how he discovered a MITM aimed at the MIT IMTP server.
Encouraging a wider view Posted Oct 1, 2013 13:24 UTC (Tue) by intgr (subscriber, #39733) [Link]
> 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.
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.
Encouraging a wider view Posted Sep 26, 2013 17:57 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Convergence[1] might be worth looking into as well.
|
|||||||||||||