

Keep the NSA out of WebRTC - nullc

The upcoming standard for real time communications on the web, WebRTC, currently makes DTLS mandatory to implement: All communications will be encrypted at all times with ephemerally keyed encryption. 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.  This is a massive step forward from today&#x27;s Internet: Even where we have encryption it&#x27;s almost user to service, not user to user and even that can usually be defeated by a downgrading attack.<p>Some parties have been periodically proposing that SDES (&#x27;Security Descriptions&#x27;) be also made mandatory to implement (e.g. http:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;draft-ohlsson-rtcweb-sdes-support-01), and Google&#x27;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.<p>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:&#x2F;&#x2F;tools.ietf.org&#x2F;wg&#x2F;rtcweb&#x2F;  The IETF is an open organization and thoughtful contributions from everyone, especially people who will be building systems using these standards, are welcome.<p>The security architecture draft http:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;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:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;draft-wing-rtcweb-sdes-problems-00.
======
nullc
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.

~~~
straight_talk
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.

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

~~~
nullc
> 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.

------
jokoon
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 ?

~~~
dexen
_> 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...](http://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA.27s_involvement_in_the_design)

~~~
jokoon
DES has been obsolete for a long time now already, AES is the new standard.

------
st3fan
"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.

~~~
nullc
> 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...](http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp-01) 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.

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

~~~
nullc
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?

~~~
rdl
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.

------
erbbysam
Probably limited to webrtc datachannel only, but as a developer, you could add
in a JS OTR implementation -
[https://github.com/arlolra/otr](https://github.com/arlolra/otr)

------
myrddin4
Other relevant links:

[https://www.cdt.org/files/pdfs/CALEAII-
techreport.pdf](https://www.cdt.org/files/pdfs/CALEAII-techreport.pdf)
[http://www.schneier.com/blog/archives/2013/06/the_problems_w...](http://www.schneier.com/blog/archives/2013/06/the_problems_wi_3.html)
[http://sporadicdispatches.blogspot.com/2013/06/webrtc-
securi...](http://sporadicdispatches.blogspot.com/2013/06/webrtc-security-and-
confidentiality.html)

------
celestineanikwe
click to [http://www.unn.edu.ng](http://www.unn.edu.ng) for details

