Keep the NSA out of WebRTC
8 comments
Sorry for the wall of text. I think this is a place where the people on Hacker News can actually _do something_ about the surveillance.
But bringing in a bunch of unformed yelling people into the IETF won't help. Bringing in a bunch of concerned but informed people _can_ make a difference. But like most things that make a difference it will take a bit more of your time than just clicking a form.
But bringing in a bunch of unformed yelling people into the IETF won't help. Bringing in a bunch of concerned but informed people _can_ make a difference. But like most things that make a difference it will take a bit more of your time than just clicking a form.
Democracy, liberty, privacy need at least a few percent of the population to invest a substantial amount of effort. If those few percent are missing the totalitarian state is unavoidable.
This is silly and trying to tie it into the recent NSA revelations is disingenuous. SDES:
(a) will not be enabled by default; the developer would have to enable it explicitly?* ;
(b) is mainly intended for compatibility with existing SIP systems rather than new applications, and
(c) is no worse against an attack with even a slight level of detectability, where the server can do whatever kind of interception it wants by modifying the page JavaScript. (The exception is browser extensions.)
* I am not sure if this is actually true; the SDES draft's statement that users of SDES "can be informed of the necessary precautions" suggests that it is, but the problems draft suggests a downgrade attack, and both are somewhat confusing. I would try to figure it out for myself, but WebRTC is one of the most complicated standards I have ever even begun to understand. In any case, if it's possible for a webapp to end up using SDES without explicitly enabling it, that is a bug and should be fixed. There would probably be more productive ways to go about this than posting on HN about the NSA taking over WebRTC.
(a) will not be enabled by default; the developer would have to enable it explicitly?* ;
(b) is mainly intended for compatibility with existing SIP systems rather than new applications, and
(c) is no worse against an attack with even a slight level of detectability, where the server can do whatever kind of interception it wants by modifying the page JavaScript. (The exception is browser extensions.)
* I am not sure if this is actually true; the SDES draft's statement that users of SDES "can be informed of the necessary precautions" suggests that it is, but the problems draft suggests a downgrade attack, and both are somewhat confusing. I would try to figure it out for myself, but WebRTC is one of the most complicated standards I have ever even begun to understand. In any case, if it's possible for a webapp to end up using SDES without explicitly enabling it, that is a bug and should be fixed. There would probably be more productive ways to go about this than posting on HN about the NSA taking over WebRTC.
> This is silly and trying to tie it into the recent NSA revelations is disingenuous [...] (a) will not be enabled by default; the developer would have to enable it explicitly?* ;
The point of showing the relationship here is to point out that site/service operators ("The developer") in your example cannot be trusted to not be coerced into acting against the user's interest.
> (b) is mainly intended for compatibility with existing SIP systems
WebRTC cannot be directly compatible with existing SIP systems because the data transport channel must use ICE to negotiate permission to send. (Otherwise JS bugs on webpage could turn random browsers into traffic flooders.
> where the server can do whatever kind of interception it wants by modifying the page JavaScript
SDES always sends the cryptographic keys to the signaling service, so the traffic can be undetectably captured. DTLS-SRTP does not make them available at all— even to the JS. So you never get unconditionally undetectable capture— at worst you get is capture which is only detectable by users that bother to page-info->media->session ID and compare.
> a downgrade attack
Whenever a less secure channel exists you can be forced into using it by blocking the more secure one. In particular, the thread model pointed out by the recent revelations is that the "developer" (site operator) can be secretly acting against the user's best interest.
> NSA taking over WebRTC
Huh? I wasn't ambiguous about who was pushing it because I wanted to suggest it was some shadowy force. I don't think it particularly matters _who_ is pushing it. I believe that when technology creates backdoors available to third parties those backdoors will eventually be used. As an engineer in this space I believe we can only protect the public by building systems which, to the best of our ability, are structurally immune to being subverted.
The point of showing the relationship here is to point out that site/service operators ("The developer") in your example cannot be trusted to not be coerced into acting against the user's interest.
> (b) is mainly intended for compatibility with existing SIP systems
WebRTC cannot be directly compatible with existing SIP systems because the data transport channel must use ICE to negotiate permission to send. (Otherwise JS bugs on webpage could turn random browsers into traffic flooders.
> where the server can do whatever kind of interception it wants by modifying the page JavaScript
SDES always sends the cryptographic keys to the signaling service, so the traffic can be undetectably captured. DTLS-SRTP does not make them available at all— even to the JS. So you never get unconditionally undetectable capture— at worst you get is capture which is only detectable by users that bother to page-info->media->session ID and compare.
> a downgrade attack
Whenever a less secure channel exists you can be forced into using it by blocking the more secure one. In particular, the thread model pointed out by the recent revelations is that the "developer" (site operator) can be secretly acting against the user's best interest.
> NSA taking over WebRTC
Huh? I wasn't ambiguous about who was pushing it because I wanted to suggest it was some shadowy force. I don't think it particularly matters _who_ is pushing it. I believe that when technology creates backdoors available to third parties those backdoors will eventually be used. As an engineer in this space I believe we can only protect the public by building systems which, to the best of our ability, are structurally immune to being subverted.
I never thought some technology standard could be lobbied by something like the NSA.
I mean most devs right now are doing web apps in JS, so obviously if you manage to restraint browsers from being able to do simple simple, raw p2p, you've won another battle against the making of a tech like bittorrent.
I so wish bittorrent inc could pick up on that... The web is not secure, but p2p networks are much more. Someone really have to make p2p networks more accessible and more functional for tech unsavvy people. Bittorrent sync already makes a great job at that, but that's not really enough, it's just files, not discussion groups or private messages.
Why not starting with just a anonymous p2p discussion system, without moderation or identification ? 4chan works that way, and they manage it pretty well, doesn't seem to bother many people. I emphasis on the without moderation or identification, because I guess there will be security flaws allowing to thwart messages.
Any reflexion on such systems ?
I mean most devs right now are doing web apps in JS, so obviously if you manage to restraint browsers from being able to do simple simple, raw p2p, you've won another battle against the making of a tech like bittorrent.
I so wish bittorrent inc could pick up on that... The web is not secure, but p2p networks are much more. Someone really have to make p2p networks more accessible and more functional for tech unsavvy people. Bittorrent sync already makes a great job at that, but that's not really enough, it's just files, not discussion groups or private messages.
Why not starting with just a anonymous p2p discussion system, without moderation or identification ? 4chan works that way, and they manage it pretty well, doesn't seem to bother many people. I emphasis on the without moderation or identification, because I guess there will be security flaws allowing to thwart messages.
Any reflexion on such systems ?
> I never thought some technology standard could be lobbied by something like the NSA.
Has been done already, and to a good effect:
http://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA.27...
Has been done already, and to a good effect:
http://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA.27...
DES has been obsolete for a long time now already, AES is the new standard.
check out bitmessage
"With DTLS-SRTP content interception will always be _possible_ to detect (e.g. by comparing session IDs) and when coupled with something like Persona (BrowserID) MITM becomes infesable."
I don't think this is correct.
1) interception is usually about passively recording something. It is totally possible for some party to intercept a DTLD-SRTP session without being noticed. The session would just be encrypted. So it depends on how much CPU power or knowledge about crypto or protocol vulnerabilities the attacker has to turn that intercepted encrypted session into something useable.
2) Persona does not prevent against MITM. It operates at a completely different level. At is basics it is just a mechanism to get a verified email address from a user.
You are correct about SDES and signaling servers. Unfortunately you always need someone in the middle because even in 2013 probably 99.9% of 'things' on the internet are behind NAT.
There are probably secure options to encrypt the SDES before it goes via the signaling server but nobody has really explored that fully.
I don't think this is correct.
1) interception is usually about passively recording something. It is totally possible for some party to intercept a DTLD-SRTP session without being noticed. The session would just be encrypted. So it depends on how much CPU power or knowledge about crypto or protocol vulnerabilities the attacker has to turn that intercepted encrypted session into something useable.
2) Persona does not prevent against MITM. It operates at a completely different level. At is basics it is just a mechanism to get a verified email address from a user.
You are correct about SDES and signaling servers. Unfortunately you always need someone in the middle because even in 2013 probably 99.9% of 'things' on the internet are behind NAT.
There are probably secure options to encrypt the SDES before it goes via the signaling server but nobody has really explored that fully.
> I don't think this is correct.
You may have adopted a somewhat definition of interception then I was intending there. Certainly it will not prevent traffic analysis but the content of the communication can not be discerned by a computationally bounded adversary under the assumption that the underlying cryptography is secure (and if it isn't... there are bigger issues). Modern cryptography isn't something you just wave CPU power at: the energy required to crack these constructs via brute force on non-reversible computers is not currently available to man kind.
> 2) Persona does not prevent against MITM.
Persona is, effectively, a distributed PKI system that binds ephemeral signing keys to a human recognizable identity. There is, in fact, a draft on using Persona (or any other cryptographic identity service) to authenticate the WebRTC session IDs: http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp... but it only protects against server-cooperating MITM if DTLS-SRTP is used and not SDES.
> Unfortunately you always need someone in the middle because even in 2013 probably 99.9% of 'things' on the internet are behind NAT
Having a signaling intermediary and and ICE/TURN service to get past NAT is completely orthogonal to having ephemerally keyed end-to-end encryption which cannot be tampered with by site controlled JS.
With DTLS-SRTP you can have a conversation signaled and NAT traversed by, say, Facebook which cannot be spied on by Facebook without— at a minimum— causing the two endpoints to show and record different session fingerprints making any interception detectable.
You may have adopted a somewhat definition of interception then I was intending there. Certainly it will not prevent traffic analysis but the content of the communication can not be discerned by a computationally bounded adversary under the assumption that the underlying cryptography is secure (and if it isn't... there are bigger issues). Modern cryptography isn't something you just wave CPU power at: the energy required to crack these constructs via brute force on non-reversible computers is not currently available to man kind.
> 2) Persona does not prevent against MITM.
Persona is, effectively, a distributed PKI system that binds ephemeral signing keys to a human recognizable identity. There is, in fact, a draft on using Persona (or any other cryptographic identity service) to authenticate the WebRTC session IDs: http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp... but it only protects against server-cooperating MITM if DTLS-SRTP is used and not SDES.
> Unfortunately you always need someone in the middle because even in 2013 probably 99.9% of 'things' on the internet are behind NAT
Having a signaling intermediary and and ICE/TURN service to get past NAT is completely orthogonal to having ephemerally keyed end-to-end encryption which cannot be tampered with by site controlled JS.
With DTLS-SRTP you can have a conversation signaled and NAT traversed by, say, Facebook which cannot be spied on by Facebook without— at a minimum— causing the two endpoints to show and record different session fingerprints making any interception detectable.
I'm like 19033349x more concerned about CALEA in WebRTC than anything with the NSA. My concern would be WebRTC configured in a way to be construed as an "interconnected voice system".
If you're ruled to need to comply with CALEA, and don't, you're shut down.
If you're ruled to need to comply with CALEA, and don't, you're shut down.
This is why decenteralized systems are important. WebRTC itself can be used in an entirely peer to peer manner.
Do you foresee CALEA being successfully imposed on open source software (e.g. firefox) where users connect directly to each other without an intermediate server?
Do you foresee CALEA being successfully imposed on open source software (e.g. firefox) where users connect directly to each other without an intermediate server?
It would require a new interpretation of CALEA. Right now, even "non-interconnected voice over IP" (e.g. Teamspeak) isn't covered by CALEA.
They do use some pretty bullshit stretching to count e.g. Skype as "interconnected" even though only a tiny minority of calls touch SkypeOut/PSTN.
I'm curious how this works if you have a disinterested third party running the interconnect; e.g. if I took TeamSpeak and set up a SIP trunk, does that make all teamspeak "interconnected voice over ip"?
I think some new "general purpose centralized voip" CALEA interpretation is the next most likely. I wouldn't be surprised if that happened already in some cases, at least semi-officially. ("it would be a shame if we had to seize a bunch of your servers every time we have a subpoena, you should just give us a nice UI and we'll even pay you per use...")
Going after pure peer to peer stuff is hardest. Commercial software would be easier, obviously, than open source, since you could apply some commercial levers/threats.
They do use some pretty bullshit stretching to count e.g. Skype as "interconnected" even though only a tiny minority of calls touch SkypeOut/PSTN.
I'm curious how this works if you have a disinterested third party running the interconnect; e.g. if I took TeamSpeak and set up a SIP trunk, does that make all teamspeak "interconnected voice over ip"?
I think some new "general purpose centralized voip" CALEA interpretation is the next most likely. I wouldn't be surprised if that happened already in some cases, at least semi-officially. ("it would be a shame if we had to seize a bunch of your servers every time we have a subpoena, you should just give us a nice UI and we'll even pay you per use...")
Going after pure peer to peer stuff is hardest. Commercial software would be easier, obviously, than open source, since you could apply some commercial levers/threats.
Huh? Even with WebRTC you need signaling. Unless you know your peer IP address AND neither end are behind a NAT.
Probably limited to webrtc datachannel only, but as a developer, you could add in a JS OTR implementation - https://github.com/arlolra/otr
click to http://www.unn.edu.ng for details
Some parties have been periodically proposing that SDES ('Security Descriptions') be also made mandatory to implement (e.g. http://tools.ietf.org/html/draft-ohlsson-rtcweb-sdes-support-01), and Google's WebRTC stack already supports it. SDES sends the crypto keys over the signaling channel, making them visible to all the signaling servers at a minimum. SDES-SDES makes passive and undetectable monitoring possible and provides a false sense of security in a world where powerful parties bend the rule of law to engage in massive surveillance.
If you care about building infrastructure which ensures individual privacy I strongly encourage becoming informed and an active participant in the IETF RTCWeb working group: http://tools.ietf.org/wg/rtcweb/ The IETF is an open organization and thoughtful contributions from everyone, especially people who will be building systems using these standards, are welcome.
The security architecture draft http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-06 and the mailing list archives are good starting points as well as the Wing draft on problems with SDES: http://tools.ietf.org/html/draft-wing-rtcweb-sdes-problems-00.