Subject: [rtcweb] Why persistent consent for HTTP is a problem

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Jun 2012 15:59:34 -0700

In Martin's review of draft-ietf-rtcweb-security-arch, he (re)raised
the question of persistent consent for camera/microphone access from
pages served over HTTP.  I had thought this issue closed, but in the
discussion at the interim there seemed to be a fair amount of
sentiment that people hadn't understood the security issues and now
believed that this was a bad idea. I agreed to attempt to re-start the
discussion with a clearer description of what the problem was, hence
this message.

Here's the basic attack:
Say that I have given persistent permission to access my camera and
microphone to any page from http://www.example.com/. Now, I go to an
Internet cafe and surf to *any* HTTP page, e.g.,
http://www.google.com/. At this point, any attacker who controls the
wireless network can redirect that access to point to
http://www.example.com/ and inject JS that reads from my camera and
microphone.

That's pretty bad, but made worse by the following facts:
1. It's not that hard for the attacker to open up
popups/popunders/iframes, etc. that are in the domain of example.com
but actually execute code from the attacker.  So, once you've opened
the browser in a hostile environment, the attacker can bug you at
times of his choosing until you close your browser.

2. If your browser does any sort of auto-refresh (e.g., because
the page refreshes itself) then you can get infected even if you
don't do anything deliberate.

3. This also applies if you are using any kind of open wireless
network, such as if your home network doesn't use a strong
enough WPA key.

So, the executive summary is: if you have a persistent permission
for an HTTP site, and you ever use your browser on any insecure
network, an attacker can bug your computer until you close your
browser. This seems bad.

Does this change people's opinions about what the rules should be
about whether browsers permit persistent HTTP permissions?

-Ekr

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 26 Jun 2012 19:52:11 -0400

Not only that, but I find it hard to understand why anyone would need to 
give persistent consent for accessing media devices to any device.

I also thought the issue was closed for good.

(Sorry, I could not be present at the intereem meeting, even remotely...)

Igor

On 6/26/2012 6:59 PM, Eric Rescorla wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Stefan Hakansson LK <[email-masked]>
Date: Wed, 27 Jun 2012 10:21:51 +0200

Would it be feasible to allow only pages delivered over https to use 
persistent consent?

(I think that in certain situations it could be annoying to have to give 
consent every time)

Stefan

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Jun 2012 05:47:04 -0700

> Would it be feasible to allow only pages delivered over https to use

Yes, that is what Iw ould propose.

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 27 Jun 2012 07:23:28 -0700

This makes sense to me.  Persistent consent over http is pretty dangerous. 

> From: [email-masked]
> Date: Wed, 27 Jun 2012 05:47:04 -0700
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: [rtcweb] Why persistent consent for HTTP is a problem
>

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 27 Jun 2012 10:12:44 -0500

> This makes sense to me.  Persistent consent over http is pretty dangerous.

Yes, this makes sense to me as well. Even persistent consent to pages 
served over HTTPS would need some sort of certificate fingerprint 
caching to notify the user if the certificate of the site has changed 
since they provided consent, in my opinion.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Jun 2012 08:57:40 -0700

This discussion is reminiscent of the long-standing joke about the
"ravish me" bit.  We should suggest that browsers hide the "remember
my choice" checkbox for unsecured sites.

Note that I also believe that this needs to include sites with mixed
content.  The idea that a site might degrade into mixed content after
an input device is acquired is probably a corner case that we can
ignore unless someone has a brilliant suggestion.

--Martin

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 27 Jun 2012 12:48:30 -0400

Still, my question is: Why would anyone want to give "persistent 
consent" for device access to any site in the first place?..

Sorry for badgering.

Igor

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Jun 2012 09:55:22 -0700

On 27 June 2012 09:48, Igor Faynberg <[email-masked]> wrote:
> Still, my question is: Why would anyone want to give "persistent consent"
> for device access to any site in the first place?..

That's a matter of a user's trust vs. annoyance tradeoff.  For a site
that a user has relatively high trust in, they might find the
annoyance of having to click through "Do you want to allow
_example.com_ to access your microphone? y/n" every time that they use
that site to make audio calls to be sufficiently high to have a
persistent permission for that site.

There is also a security benefit from persistence.  Requiring
click-through trains users to click through.  A user that is trained
in this fashion becomes easier to exploit.

Note that the manifestation of persistence is still entirely left to
browser implementers.  If and how they implement the feature is up to
them.  No doubt it will be subject to careful design and extensive
testing.

--Martin

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 28 Jun 2012 07:38:56 -0700

Accepting persistent consent over a HTTP connection seems like a really really bad idea to me. Among other things, I would hope the IESG would just say no to this.

---

From: Göran Eriksson AP <[email-masked]>
Date: Thu, 28 Jun 2012 23:39:35 +0200

+1

Sent from my iPad

---

From: Anne Raby <[email-masked]>
Date: Thu, 28 Jun 2012 20:45:29 -0400

Hi,

Concerning the SIP Early Media example in draft-ietf-rtcweb-jsep-01 I had some interrogations about the usage of the "pranswer" state when the Offerer receives the answer in a 180 response from the Anserer[1]. What is the advantage of using the "pranswer" state over the "answer"?

Copy of the example:

A.2.6. Handling early media (e.g. 1-800-FEDEX), using SIP

   This example demonstrates how early media could be handled; for
   simplicity, only the offerer side of the call is shown.

   // Call is initiated toward Answerer
   OffererJS->OffererUA:   pc = new PeerConnection();
   OffererJS->OffererUA:   pc.addStream(localStream, null);
   OffererUA->OffererJS:   onicecandidate(candidate);
   OffererJS->OffererUA:   offer = pc.createOffer(null);
   OffererJS->OffererUA:   pc.setLocalDescription("offer", offer);
   OffererJS:              sip = createInvite(offer);
   OffererJS->AnswererJS:  SIP INVITE w/ SDP

   // 180 Ringing is received by offerer, w/ SDP
   OffererJS:              answer = parseResponse(sip);
1->OffererJS->OffererUA:   pc.setRemoteDescription("pranswer", answer);
   OffererUA->OffererJS:   onaddstream(remoteStream);

   // ICE Completes (at Offerer)
   OffererUA->OffererJS:   onopen();
2->OffererUA->AnswererUA:  Media

   // 200 OK arrives at Offerer
3->OffererJS:              answer = parseResponse(sip);
   OffererJS->OffererUA:   pc.setRemoteDescription("answer", answer);
   OffererJS->AnswererJS:  ACK

I am assuming the example is using Reliable Provisional Response since the Media seems to be flowing from Offerer to Answerer before the 200 OK and ACK [2]. Below, I depict my understanding of the associated SIP:

   UAC(offerer)          UAS(answerer)
    | F1  INVITE (SDP)    |
    |-------------------->|
    | F2 180-rel (SDP)    |
    |<--------------------|
    
    | F3   PRACK (no SDP) |
    |-------------------->|
    | F4 200 PRA (no SDP) |
    |<--------------------|
    |                     |
    | F5  200 INV (SDP)   |
    |<--------------------|
    | F6     ACK          |
    |-------------------->|
  
I am trying to reconcile this example with RFC3261, RFC3262 and RFC3264. With the help of RFC 6337, I understand that if a UAC receives a SDP answer in a reliable response, it should ignore any SDP ANSWER in a subsequent response in the same INVITE transaction. If the 2nd SDP is different then the UAC should only consider the 1st SDP answer.

If this is the case, then the SDP answer from the 200 OK should be the same as in the 180. What is then the advantage of using the "pranswer" state? I am trying to figure out in which case the "pranswer" could be used?

Thanks for helping me better understand this JSEP SIP early media example.

Best regards,

Anne

-----------------------------------------
ANNE RABY 
-----------------------------------------
Ericsson Canada
Business Unit Networks, PDU Converged Core, H2S
8500 Décarie
Mont-Royal, Québec, H4P 2N2, Canada
Phone +1 514 345-7900 x16685
Mobile +1 514 502-3073
[email-masked]
www.ericsson.com