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

From: carlo von lynX <[email-masked]>
Date: Wed, 15 Jul 2015 14:38:03 +0200

It's not such a big deal, even casual readers understand the
problem and suggest the simple solution:

Someone called Michael writes:
    "local ip doesn’t seem that useful for marketers except as a user fingerprinting tool. They already have your public ip, this helps them differentiate between people behind nat. it’s a bit icky but not such a big deal. This issue blows up again when someone starts using it maliciously, which I’m sure will happen soon enough. I don’t get why exactly we don’t just prompt for this the same way we do camera and mic, it wouldn’t be a huge deal to work that into the spec. That being said, I don’t think it’s actually as big of a deal as it has been made either"

(from https://bloggeek.me/webrtc-new-york-times/ - yet another privacy
 issue with mainstream web browsers, this time thanks to webrtc)

The reason why this is a big deal is because they do NOT already have 
the public IP for some people and de-anonymizing Tor or VPN users can
have life-threatening consequences as described below.
Let me look at your official statements on the topic:

https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-11#page-15
says on the topic of "5.4.  IP Location Privacy" :

	"The API MUST provide a mechanism to allow the JS to
      suppress ICE negotiation (though perhaps to allow candidate
      gathering) until the user has decided to answer the call"

Eh? This is not solving the problem at all since the JS isn't in
the slightest trustworthy.

	"The API MUST provide a mechanism for the calling application 
      JS to indicate that only TURN candidates are to be used."

Dito.

	"The API MUST provide a mechanism for the calling
      application to reconfigure an existing call to add non-TURN
      candidates.  Taken together, this and the previous requirement
      allow ICE negotiation to start immediately on incoming call
      notification, thus reducing post-dial delay, but also to avoid
      disclosing the user's IP address until they have decided to
      answer."

Yet nothing of it actually solves the issue it is supposed to solve,
protecting IP Location Privacy, except when the involved websites
are interested in protecting users from each other - which is just
the least interesting threat model case.

Further below you wrote:

	"Note that the protections provided here assume a non-malicious
   calling service.  As the calling service always knows the users
   status and (absent the use of a technology like Tor) their IP
   address, they can violate the users privacy at will.  Users who wish
   privacy against the calling sites they are using must use separate
   privacy enhancing technologies such as Tor. Combined WebRTC/Tor
   implementations SHOULD arrange to route the media as well as the
   signaling through Tor. Currently this will produce very suboptimal
   performance."

Performance is irrelevant here. The problem is that WebRTC APIs are
available for abuse even if people are not in the slightest interested
in making actual use of them. The entire security assessment document
is bypassing the real threat, as if Tor by itself could solve all
problems and it were enough to just mention it.

So I'll repeat Michael's sort-of key question:

    "I don’t get why exactly we don’t just prompt for this the same way we do camera and mic,"

It could be a single transaction, asking the user to allow access to
all three things in order to allow for rtc apps to be initiated.
There isn't even a need to make an *additional* prompt.

On Tue, Apr 21, 2015 at 05:46:58PM +0200, carlo von lynX wrote:
> Envision the typical young dissident with his Windows PC using
> some VPN to access critical information. My impression is these
> folks are not aware of how much safer they could be by using
> TBB with Tor bridges, and for their purposes all the risks of
> getting fingerprinted aren't even relevant *as long as the
> authorities can't find a way to follow the fingerprinted browser
> to its physical position* (something the NSA probably can, but
> the NSA is outside of this threat model). So until everyone in 
> their social surroundings hasn't been taken away to prison, they 
> will continue as always - and if the web browser in the meantime
> has introduced a way for authorities to reveal their whereabouts,
> that could cost some lives.
> 
> Possibly all the other bugs in the JS "security" model are not 
> half as dangerous to these people than the ability for an authority
> to inject JS code that will reveal the physical IP number of a
> dissident.
> 
> Correct me if I got something wrong but to me it looks like we
> have a serious case of lives at risk, in particular since this
> weakness is now known to the general public.. those authorities
> may be slow and dissidents like to make fun of them in order to
> feel less helpless.. but these authorities might just pick any 
> time soon to start flying webrtc drones into living people.
>  
> I hope I got something wrong.

If nobody answered, I must assume I didn't get anything wrong
(otherwise somebody would have been proud to show me how wrong I am).

No, there exists no technology mailing list that doesn't have
a political aspect to it, because technology is political at all
times. But of course you can go on pretending people like me are
a big bunch of trolls.. amazing how many trolls there are out there.

Try facing the responsibility that lies upon you and you alone
because corporations are by definition non-ethical. You, the
technician, are the only ethical element in the equation. If you
don't speak up on this issue, you will be responsible. Time is
not on your side and the later you act, the more expensive it
will get. Acting irresponsible now will harm the public image
of WebRTC more and more. As Michael suggests it is only a question
of time until some wikileak tells a story of WebRTC being abused
for catching dissidents, or whatever else could possibly go wrong.

I don't care, I don't have any stakes in this business. I don't 
mind if more browsers follow the good example of Torbrowser to 
disable WebRTC entirely.

-- 
  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: tim panton <[email-masked]>
Date: Wed, 15 Jul 2015 14:48:52 +0100

<Rant>
There are 4 ip addresses involved here -
Lets assume a user with a PC - wifi connected to an ADSL router and using a VPN

1) External VPN address : the IP address of the exit node from the VPN - this is already known to everyone.
2) Internal VPN address : the IP address of the VPN interface on the PC end of the VPN tunnel - not known - but not ‘secret'
3) ISP address : the address allocated by the ISP for the ADSL router - this is the one that TOR and other VPNs mask
4) local IP address: the address returned by the router - typically 192.168.0.2 or some such - this is not known 

With current VPN configs (and I assume TOR) webRTC reveals all of these.
The critical one is  ISP address (correct me if I’m wrong) - This can reveal location and identity via the ISP’s business database.

A small change to the VPN configuration will hide the ISP address - you just have to set the default route to 2) rather than 3)
then the STUN queries will return the external VPN address - which is what you revealed anyway by loading the page.

'Just ask the user to enable webRTC' is a sledgehammer to crack a nut. 

You are forgoing the huge advantages (including privacy) of P2P crypto in webRTC just because the existing VPN 
suppliers can’t figure out a default route and update their scripts.

The cynical part of me wonders if people with skin in the VPN game don’t want an easy to use P2P crypto in the browser…..
</Rant>

Tim.
P.S. actually I’m ‘surprisingly reasonable’ in person - so I’m happy to discuss off-line if that helps.
P.P.S I have a second rant about why you want P2P to travel over the local net where possible - but that can wait….

> On 15 Jul 2015, at 13:38, carlo von lynX <[email-masked]> wrote:
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 15 Jul 2015 15:52:59 +0200

+1

I would add another type for completeness:

5) external HTTP Proxy, which behaves like 1)

Best regards
Sergio

---

From: Daniel Roesler <[email-masked]>
Date: Wed, 15 Jul 2015 07:40:03 -0700

On Jul 15, 2015 5:38 AM, "carlo von lynX" <[email-masked]>
wrote:
>
> As Michael suggests it is only a question

FYI, in the leaked Hacking Team emails, they discussed using the WebRTC
exploit.

https://wikileaks.org/hackingteam/emails/emailid/119217

---

From: carlo von lynX <[email-masked]>
Date: Wed, 15 Jul 2015 18:41:30 +0200

Concerning the HT mail, of course they find a local IP of little
interest when you already p0wn the entire computer.

> <Rant>

You are welcome to rant AFTER you have done your homework.
Instead you postponed it by several weeks which made it worse.

> The critical one is  ISP address (correct me if I’m wrong) - This can reveal location and identity via the ISP’s business database.

Point one, all of this discussion and explanation belongs into
draft-ietf-rtcweb-security-arch. That is your homework for today.

> then the STUN queries will return the external VPN address - which is what you revealed anyway by loading the page.

This does not sound like something your average Egyptian
dissident will be able and sufficiently early informed about
to go about.

I frequently see this pattern of saying privacy problem X
can be solved by manual intervention Y and it is not our
problem if the general public will be unable to do such a
manual intervention.

Yes it is your problem.

It is not okay to dismiss problems this way.

Also the "solution" you suggest AFAIU does not work for people
who use Tor in a non-NATted environment, for example on a
fixed system in a university library with a static IP address.
We know that browsers will allow fingerprinting even through
Tor but it is a different calibre of problem if a browser
actually allows the attacker to find out the REAL public IP
of a person.

> 'Just ask the user to enable webRTC' is a sledgehammer to crack a nut. 

No. It's like asking the user to click on the telephone icon
before making a phone call. It is normal. What is abnormal is
to have a web browser that is supposed to browse the web be
enabled to do crazy non-web things without asking anyone.

You guys are completely losing the perspective of normal human beings.

And it's nothing new, you know these documents yourself:

https://www.torproject.org/projects/torbrowser/design/#proxy-obedience

WebRTC not respecting SOCKS configuration is a huge no-go.

https://www.torproject.org/projects/torbrowser/design/#fingerprinting-linkability

And if local IP information is so super harmless, then why is it
an obvious reason for TBB devs to disable the entire thing?
I presume for the reasons I stated before.

So when you do your homework please include all the points that
I am making. Add your solid arguments to counter them.

> suppliers can’t figure out a default route and update their scripts.

I don't know about VPN suppliers, I never used any VPN really,
but it sounds like you have a moral obligation to venture out
and inform them about the security problem you are introducing
and to make sure they protect their users before anyone gets
harmed.

Also don't tell me any fairy tales about P2P crypto in web
browsers. There is no architectural way you can provide E2E
crypto that isn't in one way or another MITM'able by the
involved servers. You are at *best* adding to the choice of
opportunistic cryptography. Don't be so excessively proud
of that considering that REAL P2P with REAL E2E authentication
is out there and would have deserved better attention.

> The cynical part of me wonders if people with skin in the VPN game don’t want an easy to use P2P crypto in the browser…..

No idea about that, but I am certain the number of people with skin
in the WebRTC game are in the majority on this mailing list - and
you wouldn't like to be ignored in any privacy debate a priori just
because you're in the WebRTC game, right? But if you go on this way,
that is likely to be the outcome. By the time you start thinking of
the consequences of your actions your credibility may already be
gone downhill.

> </Rant>

Thanks for exposing your feelings.

> P.S. actually I’m ‘surprisingly reasonable’ in person - so I’m happy to discuss off-line if that helps.

Me too, but this is very much on topic.

> P.P.S I have a second rant about why you want P2P to travel over the local net where possible - but that can wait….

I already have P2P over the local net, so the local IP
is indeed relevant in my configuration.

---

From: tim panton <[email-masked]>
Date: Wed, 15 Jul 2015 20:27:31 +0100

> On 15 Jul 2015, at 17:41, carlo von lynX <[email-masked] <mailto:[email-masked]>> wrote:
> 

Um, if you check back in the archives, I brought this issue up earlier this year.
I think it is important.

https://mailarchive.ietf.org/arch/msg/rtcweb/VnStGD7Emmvc1-QOPRtY2cFF79E <https://mailarchive.ietf.org/arch/msg/rtcweb/VnStGD7Emmvc1-QOPRtY2cFF79E>

> draft-ietf-rtcweb-security-arch. That is your homework for today.

Thanks.

> dissident will be able and sufficiently early informed about

I have zero expectation that the Egyptian dissident should do this. 
I do expect their software provider to keep up with developments.

> problem if the general public will be unable to do such a

That isn’t what I meant. I expect secure software providers to keep their
software abreast of new developments. 

> It is not okay to dismiss problems this way.

I’m really sorry you think I’m dismissing this problem, I’m not.
I happen to have the (no doubt under informed) opinion that
this isn’t as simple as it has been made out to be.

> fixed system in a university library with a static IP address.

That is an interesting case. In that instance hiding the local IP would be 
valuable. I thought however those users would normally run a TOR os off 
a usb stick in a VM. That would probably mask the local IP.

> actually allows the attacker to find out the REAL public IP

I totally agree. My solution is imho a better fix, since it
also protects against many other apps that might get started from
a browser page (email, dns, ipv6 tunnels, flash, mp3 players etc).

> enabled to do crazy non-web things without asking anyone.

No, really not. I want the VPN folks and the Tor folks to update their
scripts after consultations about the best way forward.

> https://www.torproject.org/projects/torbrowser/design/#proxy-obedience <https://www.torproject.org/projects/torbrowser/design/#proxy-obedience>
> 

I’m SOCKs ignorant.

> 
> https://www.torproject.org/projects/torbrowser/design/#fingerprinting-linkability <https://www.torproject.org/projects/torbrowser/design/#fingerprinting-linkability>
> 

I have no idea, but I fear it is because no one has split these issues out.

> and to make sure they protect their users before anyone gets

Yep, I’ve been doing that, I clearly haven’t spoken to enough people
but there is only so much homework I can do.

> is out there and would have deserved better attention.

I think putting PFS strong crypto in the hands of 2bn people and 
1m web developers is something to be slightly proud of.

I’m of the view that there are _useful_ instances of P2P crypto
in-browser - we will clearly have to disagree about that.

> the consequences of your actions your credibility may already be

I’m not ignoring anyone or their views, just challenging the conclusions they
have drawn by providing a different viewpoint.

T.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 15 Jul 2015 22:47:19 +0200

> and to make sure they protect their users before anyone gets
Sorry, I lost it.

You're lecturing us (many of whom have used VPNs regularly for the last
20 years, some of whom have implemented them) about what we should tell
VPN suppliers, and you haven't even *used* a VPN?

May I suggest that the strong opinions being delivered here might be
better served with slightly more respect for the fact that some of us
actually have some experience worth considering?

Just *explaining* this problem is complicated. And most of the
"headline" statements made about this problem are either completely
wrong or very incomplete.
Being clear about what needs protection, and from what threat, is just
the first step on the way to finding a consensus solution.

And I don't think we're even there yet.

(I recently learned of a couple of reasons why people think the local IP
address (the 192.168 ones) are valuable to learn for some services - in
that particular case, many would consider that particular purpose to
have value to society. But it shows that once we reveal information,
that information can be used in many different ways - some less obvious
than others.)

Harald

-- 
Surveillance is pervasive. Go Dark.

---

From: carlo von lynX <[email-masked]>
Date: Thu, 16 Jul 2015 10:42:25 +0200

Harald, sorry if after getting ignored once and getting a rant
on my second inquiry I start getting grumpy.. still let's stay
on topic and figure this issue out.. I still hope I and everyone
in blogland is wrong on this and exposing local IP is actually
not problematic.. but the webrtc documentations should elaborate
on this scenario and evaluate carefully in-depth on anything
that could possibly go wrong, if they intend to recover credibility
on this terrain rather than strengthening the general feeling that
browser vendors are bulldozering over humans and citizen anytime
the business model suggests so.

> https://mailarchive.ietf.org/arch/msg/rtcweb/VnStGD7Emmvc1-QOPRtY2cFF79E <https://mailarchive.ietf.org/arch/msg/rtcweb/VnStGD7Emmvc1-QOPRtY2cFF79E>

Thank you. I see you brought up the same issues. Would have
appreciated receiving such a pointer back in April when I first
asked. Unfortunately I cannot read the follow-up discussion as
somebody at IETF had the great idea of making the archives
depend on Javascript execution. I don't grant execution of foreign
code on my machines to any unencrypted or untrustworthy sources.
Is there any reply I should read? What's its hash code?

> I do expect their software provider to keep up with developments.

Yes, I dare to speak out of my 25 years of experience on the
Internet even if I didn't have to use much VPN ever. I can
imagine plenty of constellations where the VPN is NOT supposed
to take over all communications on the system but rather offer
a side route into a company's servers or suchlike. Therefore
I worry if the software provider can always come up with a
configuration that still does what the customers expect and
at the same time deals with the new backdoor introduced by WebRTC.
Of course anyone with better understanding can help clear up
these worries.

> software abreast of new developments. 

Uh, not sure if that is an established pattern in the industry.
Usually somebody does whatever fits into their business model
best, then there is a public outcry and possibly some bloodspill,
then all the players look at how they can make a good impression
by reducing the collateral damages.. but if that doesn't work out
cheap and easy.. tant pis. Let's continue with business.

> this isn’t as simple as it has been made out to be.

Well, in case of doubt it is important to pick the conservative
option until the issue is properly analyzed rather than hoping
for the general public to forget about the problem.

> a usb stick in a VM. That would probably mask the local IP.

Now that this is more clear, have another look at my original mail
that describes how such a dissident would use any Windows OS system
standing around. I doubt anything advanced like TAILS sticks are
out there as merely possessing one could be life-threatening.

We are talking about people that act out of a need to act with
very little understanding of technology. They would likely
only start wondering if what they did was safe after they got
caught. By introducing new vulnerabilities we may be tipping
some very shaky balances to the wrong side. It is quite likely
that a whole lot of people unconsciously rely on the principle
that a web browser configured to use a proxy will actually do so.

> a browser page (email, dns, ipv6 tunnels, flash, mp3 players etc).

If you can convince Microsoft to update all the OS's in such countries
in a way that VPN can no longer be configured to function in parallel
to direct Internet access, that could be a viable solution to this
problem. Introduces a new problem of not being backward compatible
to other use cases of VPNs, correct?

Again, expecting the dissidents to be magically internetworked and
inform each other quickly enough on safer practices that only a few
like us know about and may actually not be safer since they imply
singling people out of the masses of Windows users... acting differently
than the rest of the population can be a death sentence.. well then your 
proposed solution to the problem may not work out for real humans
with real problems.

> scripts after consultations about the best way forward.

Breaking the proxy principle is neither a Tor nor a VPN problem.
It's just browser vendors breaking a promise given to users that
configured proxies would be respected.

> I’m SOCKs ignorant.

So we all have our knowledge deficiencies...
good to be honest about them.

> I have no idea, but I fear it is because no one has split these issues out.

So let's dissect some more until we know what we are doing.

> but there is only so much homework I can do.

True.

> 1m web developers is something to be slightly proud of.

Perspective accepted.

> in-browser - we will clearly have to disagree about that.

I think we could improve the user's ability to ensure end-to-end
authentication beyond server-based negotiation. Something like
rendering persistent public keys into QR codes and having people
exchange those QR codes at cocktail parties and hackathons.

Servers would still be able to provide the signaling code, but users
would be granted a guarantee that the E2E connection is authentic.

> have drawn by providing a different viewpoint.

Moi aussi.

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 16 Jul 2015 14:13:54 -0700

On 7/16/15 1:42 AM, carlo von lynX wrote:
> I don't grant execution of foreign code on my machines to any 
> unencrypted or untrustworthy sources.

If you can get everyone to do that, we won't even need RTCWEB

Matthew Kaufman

---

From: Randell Jesup <[email-masked]>
Date: Fri, 17 Jul 2015 00:06:15 -0400

> would be granted a guarantee that the E2E connection is authentic.

Have you read the 'identity' support in the webrtc/rtcweb specs?  Or 
played with early implementations at 
https://mozilla.github.io/webrtc-landing/pc_test.html?

This is something we've cared about, since the beginning of this work.  
We're also working out speccing calls where the JS application can't get 
access to the datastreams (via WebAudio/canvas/etc).  There's a lot of 
work to do to spec this all out, and more to be done to implement it - 
but these things are part of the goals of WebRTC.  Witness also that we 
decided to not only not require SDES (which puts keys directly in the 
hands of the servers), but to actively require not supporting SDES.  
We've also moved to requires PFS encryption 
(https://hacks.mozilla.org/2015/02/webrtc-requires-perfect-forward-secrecy-pfs-starting-in-firefox-38/)

I'll also note that WebRTC+DataChannels can be used to build 
non-centralized encrypted communication services using (for example) 
distributed-hash addressing and a web of datachannel connections, such 
that there's no single easily-blocked locus for communications (like 
blocking twitter.com).  There's a *bunch* of work to build a good, 
secure service around this - but now it's feasible to do with just some 
JS shared on a thumb drive (or any number of ways online - done right, 
perhaps even in high-density QR-ish codes with compressed code to 
bootstrap into the network.  The webtorrent clients are the first step 
towards this.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email [email-masked]!  Way too much spam

---

From: carlo von lynX <[email-masked]>
Date: Fri, 17 Jul 2015 10:29:42 +0200

Sorry for summoning up a change of topic.
The main thread on the safety of browser users affected by the
webrtc apis against their will is still open and unresolved.
Here we just talk about the young dreams of a Javascript generation:

> https://mozilla.github.io/webrtc-landing/pc_test.html?

I know that the JS community is very adamant exploring fertile
new grounds doing crazy things... I was to "data terra nemo"
just recently.. I understand there is plenty of good intentions.
I presume you have heard of where they likely lead to.

> distributed-hash addressing and a web of datachannel connections,

Yes, these kind of good intentions.. the juvenile enthusiasm that
thinks something as complicated as DHTs can be quickly thrown into
a browser with "some JS on a thumb drive."

My knowledge indicates the security issues with cheap off-the-mill DHT
tech are impressive. It took gnunet a dozen of years to develop a
sybil-attack resistant DHT routing system. Go ahead and show
me how you will ship THAT in a bunch of .js files. Or do you think
the world will be done any good if you throw even more insecure
web apps at it?

>From my understanding of technology JS dreamers are building castles 
on houses of cards and distracting entire communities of young minds
from contributing to technologies that could actually work to
repair the damage the Internet has afflicted democracy.

But maybe you have some papers proving how a web-based distributed
hash table can be made sybil-attack resistant and secure from
eavesdropping. To me that is only achievable with such large
amounts of low-level code and packet routing that it totally 
blows the architectural options of a web browser.

So what's your take on this.. will you admit your plan is
unlikely to work out or come up with wild arguments just so
you can continue down the path of good intentions?

---

From: Tim Panton <[email-masked]>
Date: Mon, 20 Jul 2015 13:23:08 +0100

> On 16 Jul 2015, at 09:42, carlo von lynX <[email-masked] <mailto:[email-masked]>> wrote:
> 

It turns out that I was completely wrong. The browsers are currently so 
thorough in their discovery of available interfaces and routes that no
amount of changes by the sys admin or VPN supplier will fix this problem.

Sorry about that. 

>> this isn’t as simple as it has been made out to be.

At least I was right here. - It is even more complex than I believed.

> out there as merely possessing one could be life-threatening.

Here too I find that I was wrong and the current situation not what I assumed
and is unsatisfactory.

Most SOCKS proxies don't have support for ICE/STUN nor arbitrary UDP.
The current browser implementations (backed by the ICE spec) take the view that
if SOCKS doesn’t do UDP, then they should go directly and send UDP anyhow.

I’m not clear that this is what a user might expect. 
An alternative might be to detect a proxy config _only_ offer TURN over TLS 
candidates (and route the traffic over the proxy) - This would result in
poor audio/video but would be more in keeping with the spirit of the proxy config.

(a variant might be to inspect the proxy in detail and use the address whitelists
to filter allowed traffic somehow?) 

>> a browser page (email, dns, ipv6 tunnels, flash, mp3 players etc).

Turns out I was wrong - sigh - as I said the browsers are more aggressive
in finding routes than I assumed (or indeed than my ICE implementations are).

> good to be honest about them.

And now that I’ve educated myself somewhat, I’m agreeing with you.

> So let's dissect some more until we know what we are doing.

Which turns out to be the only useful contribution my <rant/> made.

> would be granted a guarantee that the E2E connection is authentic.

https://yopet.us <https://yopet.us/> :-) 

Tim.

---

From: Tim Panton <[email-masked]>
Date: Mon, 20 Jul 2015 12:53:59 +0100

> On 16 Jul 2015, at 09:42, carlo von lynX <[email-masked]> wrote:
> 

Sorry about that. 

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk

---

From: Tim Panton <[email-masked]>
Date: Mon, 20 Jul 2015 12:53:59 +0100

Sorry about that. 

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk <http://www.westhawk.co.uk/>

---

From: Tim Panton <[email-masked]>
Date: Mon, 20 Jul 2015 12:53:59 +0100

Sorry about that.

---

From: Tim Panton new <[email-masked]>
Date: Mon, 20 Jul 2015 13:14:59 +0100

Sorry about that.

---

From: carlo von lynX <[email-masked]>
Date: Fri, 31 Jul 2015 12:47:12 +0200

Alright, thanks Tim for digging deeper and confirming that
we have a serious problem here. Unfortunately everybody
else is talking of other things and giving the impression
we are having just a side discussion.. and the problem 
remains: WebRTC threatens lives of dissidents. If we can't
publish news that rtcweb has fixed the problem then the
logical consequence is to publish that n months have passed 
and rtcweb is still not willing to fix the issue.... which
can be interpreted as a political news all on its own - how
industry does not care about collateral damages. Certainly
we can't just keep quiet and let this become a working 
strategy to ignore issues.

So, dear folks, this is your chance to keep the next
shitstorm from coming your way. Do something!

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Jul 2015 09:53:09 -0400

> shitstorm from coming your way. Do something!
In IETF we typically discuss technical issues and not political PR. So, the
other discussions that you so blatantly ignore are actually about the
actual technical implications of webrtc on user privacy and possible ways
to improve it. If you have a particular technical solution that you want
propose then please do so. Screaming that industry needs to do something or
else the puppy will die is not helpful.

Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Fri, 31 Jul 2015 09:44:56 -0700

On the Chrome side, we have taken the concrete step of allowing this
functionality to be controlled via a Chrome extension:
https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia/reviews?hl=en

We are still sorting out some issues, which is why it is currently opt-in
(i.e., an extension). However, we expect to have a more comprehensive
solution in the near future.

On Fri, Jul 31, 2015 at 6:53 AM, Roman Shpount <[email-masked]> wrote:

> In IETF we typically discuss technical issues and not political PR. So,
> the other discussions that you so blatantly ignore are actually about the

---

From: Adam Roach <[email-masked]>
Date: Fri, 31 Jul 2015 13:47:08 -0500

On 7/31/15 11:44, Justin Uberti wrote:
> We are still sorting out some issues, which is why it is currently 
> opt-in (i.e., an extension). However, we expect to have a more 
> comprehensive solution in the near future.

Mozilla is taking the same approach for Firefox; for details, see:

https://groups.google.com/forum/#!topic/mozilla.dev.media/L6Rx9ubSjMc

/a

---

From: Daniel Roesler <[email-masked]>
Date: Fri, 31 Jul 2015 11:59:01 -0700

I very much sympathize with carlo's frustration with this working
group. So far the response here to the introduced privacy exploits has
been pretty appalling. As you mentioned in the other consent thread,
this standard is the first time a browser can send requests over
non-default route network interfaces.

<strong>_This is a life threatening issue!_</strong>

Many, many, many Chinese/Arab/Persian users buy VPNs to get around
censorship and participate in free speech. The default configurations
for these VPNs set the default route, but often still allow requests
to be made over the real network interface (due to the way Windows
configures VPNs). Thus, when ICE sends STUN requests through that real
network interface, they expose the real IP of the VPN user. So any
website can silently identify VPN users, which can lead to a knock a
the door. If you don't believe me, just search for "ipleak" on
twitter[1] and see how many foreign language references there are to
the exploit test page.

Very real implication: Loading a website (or even an embedded ad) is
now much more life-threatening than it was before.

Thanks everyone! Great work!

I've heard many times on threads here that this is the fault of the
VPN user for not configuring their VPN better. I couldn't disagree
more. Up until WebRTC, the browser wasn't able to make non-default
route requests, which means that up until WebRTC, you couldn't expose
your real IP just by visiting a webpage. So WebRTC is the thing that
triggered exposure of the user, not their VPN configuration. Also,
blaming the user when they are using the default configuration (and
don't know any better) and you introduced something that exposes them
is offensive.

So far there have been two proposed solutions, both of which help
solve the issue.

1. Restrict STUN requests to default route. This obviously has
performance implications, so I understand why people here are hesitant
to require this.

2. Prompt the user for consent before sending STUN requests. This
would prevent silent IP leak exploits like the one we saw in the wild
embedded on the NYTimes.

How about a combined solution?

a) By default, restrict STUN requests to the default route.

b) Add an option to PeerConnection to use non-default routes, too.

c) When createOffer() or createAnswer() is called, if the non-default
routes flag is present, ask the user for consent. If there are video
or audio streams already attached to the peerconnection, assume that
consent has already been obtained (since getUserMedia asks for
consent).

This solution is backwards compatible with existing webapps, and
minimizes the introduction of any new prompts. The only change in user
experience is when a webapp explicitly wants to use non-default routes
for their connection. If a webapp is okay with the default route, then
they can silently add a data channel (no prompts).

I very much do not agree with Justin/Chrome's proposal to add a
configuration extension that requires a user to opt-in to restricting
non-default route STUN requests. That's like having the setting to
show the warning for self-signed https certificates turned off by
default and asking users to turn it on if they really want to be safe.
The default behavior should be safe.

Daniel

[1]: https://twitter.com/search?q=ipleak

On Fri, Jul 31, 2015 at 6:53 AM, Roman Shpount <[email-masked]> wrote:
> On Fri, Jul 31, 2015 at 6:47 AM, carlo von lynX
> <[email-masked]> wrote:
>>
> other discussions that you so blatantly ignore are actually about the actual
> technical implications of webrtc on user privacy and possible ways to
> improve it. If you have a particular technical solution that you want

---

From: Justin Uberti <[email-masked]>
Date: Fri, 31 Jul 2015 12:27:20 -0700

> don't know any better) and you introduced something that exposes them

I don't really want to debate nits, but this is not true. Flash has had
this 'feature', since the beginning of the modern browser era.
Regardless, we think we can do better.

> The default behavior should be safe.
I concur. As I said, what we have done in Chrome so far is just the first
step.

Opt-in allows us to ensure the solution a) works and b) doesn't break
anything, in a more contained population. Once we are confident with this,
we can move forward with a more comprehensive solution.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Jul 2015 15:28:05 -0400

> <strong>_This is a life threatening issue!_</strong>

I actually appreciate the seriousness of the issue. I think part of the
reason this group did not respond in more timely manner is that not
everyone realized the behavior change (use of non-default routes). Once it
was clarified, the issue started to be handled. I understand that this and
any other security issue can be extremely frustrating to the end users, but
people, including people who build web browsers or design web browser
standards do make mistakes.

> Thanks everyone! Great work!

Once again, it took a while to understand the real nature of the problem.
At least for me it took a while to identify what exactly changed and why it
is different from previous browser behavior.

> don't know any better) and you introduced something that exposes them

I actually agree with you here. I've spent considerable amount of effort to
explain the problem with VPN since I did not think it was completely
understood.

> they can silently add a data channel (no prompts).

Justin is probably the best person to evaluate this solution. It looks
workable to me.

> The default behavior should be safe.
I think you do not correctly characterize what Justin/Chrome is doing here.
It is not a final solution. It is a way to test the final solution before
it gets widely deployed. Since this is a major change for the browsers I
appreciate the need to deploy this carefully and gradually.
_____________
Roman Shpount

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 31 Jul 2015 21:10:19 +0100

On 31/07/15 20:28, Roman Shpount wrote:
> I actually appreciate the seriousness of the issue.

I'm wondering if there's anything we could (get someone to)
do so that issues like this get handled better in future?

For example I'm wondering if a description of the various
ways in which current VPN services operate and some of the
consequences when things go wrong might be useful input to
WGs faced with similar issues.

I've no idea if someone would be motivated to write that
up, nor for how long such text would be useful but I suspect
there's a document there that'd be good to have. (Or if
there's a non-RFC that has a good survey/description then
a pointer to that would be good.)

Anyway, I'd be happy to help someone who was willing and
able to try that with any process stuff.

Cheers,
S.

---

From: Göran Eriksson AP <[email-masked]>
Date: Fri, 31 Jul 2015 20:21:15 +0000

Good idea. Something like that is useful. And I think some W3C WG(s) may
have an interest/responsibility also in improving on this.

Regards
Göran

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Jul 2015 22:30:05 +0200

> Regardless, we think we can do better.

See also:
https://www.usenix.org/system/files/conference/foci12/foci12-final8.pdf
and
http://www.eecs.qmul.ac.uk/~hamed/papers/PETS2015VPN.pdf

-Ekr

---

From: carlo von lynX <[email-masked]>
Date: Sat, 1 Aug 2015 00:15:15 +0200

> > Regardless, we think we can do better.

Wait wait.. I was developing Flash media apps some time ago in the
pre-Snowden era and I never bumped into any such functionality. My 
business partner of those days just dropped me this link:

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/Socket.html#localAddress

Looks like the feature exists for installed AIR apps, not Flash plugin.
Then he pointed me to Mr Kaufman's leak that RTMFP, which he introduced
into Flash in 2009 AFAIR, can be abused to obtain such IP numbers.

Well, if I who actually wrote push-to-talk apps with RTMP didn't know
that, I doubt any HackingTeam company figured out this method for
de-anonymizing VPN users. Hardly anyone looked at RTMFP all that much
since the only existing server implementation was running at Adobe.

Quite different from the WebRTC case where the API quite clearly 
explains how to get at local IP information.

So let's indeed not excuse this larger problem with a previous problem
that rather wasn't known until this moment where it may seem practical
to leak such info for the sake of argument.

Flash has NOT been offering such a feature since the beginning of
time AFAICT and the sneaky way it got introduced with RTMFP and
apparently wasn't actually secure as such is a too late scandal
in itself.

> http://www.eecs.qmul.ac.uk/~hamed/papers/PETS2015VPN.pdf

Interesting papers, but do they describe a method for Javascript code
in websites to break out of the VPN cage? I didn't see anything like that,
maybe I skipped the content too fast.

Also let's not talk about IPv6.
It is not relevant for the dissident scenario of today and by the time
industry stops preferring NAT over IPv6 we'd better already be deploying
public-key based routing whereby worldwide IP addressing is no longer
a worthwhile goal. Thus it is my assumption that IPv6 will hardly ever
play a relevant role in Internet history.

---

From: carlo von lynX <[email-masked]>
Date: Sat, 1 Aug 2015 00:27:48 +0200

> standards do make mistakes.

Woah, everyone reading those blogs understood the seriousness of the
problem except for the developers that culled themselves into the idea
of everyone out there having gotten everything wrong? Whoops.

> > How about a combined solution?

Sounds like going in the right direction. I still haven't understood
why there can't be one single prompt that allows a site to do webrtc
things.. allowing mic, cam *AND* STUN access in a single gesture.
Anything else would be intransparent anyway.

> > The default behavior should be safe.

Yes, the proposal completely fails the scenario I described. You
can't expect non-tech people that are simply using a web browser to
understand why they suddenly need to flick some switches or install
some odd addons in order to not get deanonymized. WebRTC needs a
general opt-in.

> appreciate the need to deploy this carefully and gradually.

Features need to be introduced carefully, but this isn't a feature.
This is a top notch security bug risking human lives and I can't
believe it takes months of talking to get anything going here.
This needs to be shut down first, then experiment alternate routes.
Period.

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 31 Jul 2015 17:18:33 -0700

> of everyone out there having gotten everything wrong? Whoops.

I understood the magnitude of the issue, and I still think you're 
overreacting.

> some odd addons in order to not get deanonymized. WebRTC needs a

Disagree.

> This needs to be shut down first, then experiment alternate routes.
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.

Matthew Kaufman

---

From: Philipp Hancke <[email-masked]>
Date: Sat, 1 Aug 2015 03:45:13 +0200 (CEST)

> de-anonymizing VPN users.

At least hackingteam didn't figure out the webrtc method themselves either 
according to https://wikileaks.org/hackingteam/emails/emailid/119217

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?

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

And it is P2P. It has to exchange some ip addresses somehow.
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.

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

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

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

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?