Subject: Re: [rtcweb] Prompt for mic, camera *and* network access

From: carlo von lynX <[email-masked]>
Date: Sun, 2 Aug 2015 04:21:06 +0200

On Fri, Jul 31, 2015 at 05:18:33PM -0700, Matthew Kaufman wrote:
> I understood the magnitude of the issue, and I still think you're
> overreacting.
> 
> Disagree.

That is both irrelevant. Either you disprove the scenario I described
as non-critical or you fix the bug.

> If you're worried about "top notch security bugs risking human
> lives" there's at least a dozen I'd tackle before thinking about
> this one. It allows browsers to do little more than people have been
> accepting for years, in their browsers.

Name some. We have plenty of bugs allowing to trace a user being
the same user as yesterday, but we don't have many that produce
the IP number of that person's home so authority knows where to
pick her up.

-- 
  E-mail is public! Talk to me in private using encryption:
         http://loupsycedyglgamf.onion/LynX/
          irc://loupsycedyglgamf.onion:67/lynX
         https://psyced.org:34443/LynX/

---

From: carlo von lynX <[email-masked]>
Date: Sun, 2 Aug 2015 04:21:42 +0200

On Sat, Aug 01, 2015 at 03:45:13AM +0200, Philipp Hancke wrote:
> At least hackingteam didn't figure out the webrtc method themselves
> either according to
> https://wikileaks.org/hackingteam/emails/emailid/119217

Exactly, so they wouldn't have figured out the RTMFP possibility until
Mr Kaufman informed us about it.

The only agency that has enough financing to keep people actively
looking for this sort of flaws is the NSA, and the NSA is not the
threat model in this situation. We are talking of a lot less proficient
folks digging up some methods from the Internet and applying it against
dissidents in their own country. They know of the WebRTC method since
that got published and maybe since a few mails they also know about RTMFP.

> Now if you assume a smarter opponent than that, why is that opponent not
> smart enough to have figured out the RTMFP method as well?

I don't. HackingTeam is about the best a country like Sudan can afford.

> Granted, RTMFP is a pretty tough nut to reverse engineer but it had
> been done back in late 2010.

I know who did so. It's less than a handful of people I assume and none
of them saw the secret service potential of local IP numbers, including
the folks at Adobe supervising Mr Kaufman's work. So the fact that nobody
ever cared to mention this loophole was enough to keep it out of range
for oppressive regimes.

> And it is P2P. It has to exchange some ip addresses somehow.

I would expect this to already be a notion beyond the competences of
Egyptian or Syrian authorities... until you said it.

> Even despite the encryption scheme, you can use wireshark to see
> ice-like packets. Their content will be unreadable, but the IP
> addresses tell you what is going on.

Sure, but have the ever thought of wiresharking the traffic of
chatroulette close enough to notice that there are IPs in there?
No, because whenever they caught anyone using chatroulette they
already knew his IP number. Why should they care to wireshark
deeper? Whereas if there ever were dissidents looking at chat-
roulette (I doubt that) through a VPN or Tor (even less likely)
then it bypassed them entirely so there was nothing to wireshark.

> I do recall LOL'ing when finding out that Adobe leaked 10.x server
> addresses in the early days of cirrus.

How are servers related to this?

> >Hardly anyone looked at RTMFP all that much since the only
> >existing server implementation was running at Adobe.
> 
> I disagree with your "hardly anyone" FWIW.

But you cannot disprove my danger scenario for dissidents, so that's
enough to still take this issue seriously.

> >Quite different from the WebRTC case where the API quite clearly
> >explains how to get at local IP information.
> 
> I do not understand your argument. RTMFP did not expose the local IP
> information at the API level. However, that did not mean it was not
> discoverable as explained above.

And that is exactly the point. Persian authorities would never figure
out that a custom flash movie using RTMFP would have helped them do
their job, but it's easy to put into practice what's openly stated in
a documentation.. especially after there has been a major shitstorm
about it.

> Assuming that your point is that WebRTC shouldn't expose this and
> use a signaling channel that isn't under control of the browser, how
> would that increase security?

I'm saying that WebRTC should not do anything until it has gotten
permission from the user. Dissidents would be alert and block the 
transaction. The only situation a dissident would want to use WebRTC
is when the VPN is turned off and she is calling her mother to talk
about what to cook for dinner. But if WebRTC is allowed to do what
it likes to do even when she is crawling government sites for
information useful to the resistance movement... well then that is
bad as it can cause the bad guys to come to her house and search
her computer for incriminating material (which they would probably
find, because your average dissident isn't an OPSEC Appelbaum type).

Being a person out of millions is protection.
Deanonymization can spell imprisonment, torture and worse.