Re: [rtcweb] Notes on security for browser-based screen/application sharing

Randell Jesup <randell-ietf@jesup.org> Fri, 22 March 2013 17:33 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CDB21F8D20 for <rtcweb@ietfa.amsl.com>; Fri, 22 Mar 2013 10:33:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsNzfgmhG0KQ for <rtcweb@ietfa.amsl.com>; Fri, 22 Mar 2013 10:33:44 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 579D021F8C8C for <rtcweb@ietf.org>; Fri, 22 Mar 2013 10:33:44 -0700 (PDT)
Received: from pool-98-111-140-34.phlapa.fios.verizon.net ([98.111.140.34]:2291 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <randell-ietf@jesup.org>) id 1UJ5qZ-00064t-Mj for rtcweb@ietf.org; Fri, 22 Mar 2013 12:33:43 -0500
Message-ID: <514C95A8.5030507@jesup.org>
Date: Fri, 22 Mar 2013 13:32:24 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CABcZeBPs=znh-BUCRoVkPC1UuQt-xxf-COD+SGE59ASBzRZbJQ@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB11342CB58@xmb-aln-x02.cisco.com> <CABcZeBN2R=dKYtoLEstNuT2K89k+Y_gD8_OdRS5MQOJNSzY5Kg@mail.gmail.com> <CABkgnnUXPqH9JLcH8o-oKdirb6H-iGtKJ752h9jL0+_8usD6ZA@mail.gmail.com>
In-Reply-To: <CABkgnnUXPqH9JLcH8o-oKdirb6H-iGtKJ752h9jL0+_8usD6ZA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
Subject: Re: [rtcweb] Notes on security for browser-based screen/application sharing
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2013 17:33:45 -0000

On 3/22/2013 1:10 PM, Martin Thomson wrote:
> The modern web reality is that any one page consists of content from
> many different sources, so restricting to one source is impractical.
> From an implementation perspective, it might be possible to restrict
> to untainted content (the content that the page origin can access),
> but that would probably result in something that is virtually useless.
>   Just like that interesting (redacted) document that contains
> (redacted).

Correct, and likely be be highly annoying and highly confusing to users.

It really does come down to a trust (or trust and verify) model.  Do you 
trust the JS application?  Can you verify the JS application is the one 
you think it is?  Is there any way to whitelist or blacklist 
applications (from the browser maker or by the user)?   If you're going 
to install/trust/whatever an app, is there an equivalent to 
virus/spyware scanning?

You might be able to (in screen/app sharing) lock out the ability to 
redirect the MediaStream to anywhere but a specific PeerConnection, and 
have chrome that tells you "this is being shared with a connection to 
<identity>" using the identity stuff already proposed, and in other ways 
leverage the "secure call" stuff ekr proposed in Boston.  However, 
there's the converse side at reception - you have to protect it there as 
well - no grabbing a copy from a <video> element, no looping it out to 
another peerconnection (without user consent), no recording (without 
user consent), no other way to access the content of the decoded stream.

Armoring a screenshare against leaks to the application will be tough, 
but it might (just) be possible.  Layering both mechanisms (trust and 
armoring) might be better than relying on just one.

I wonder if mechanisms like out-of-band passcodes (similar to what 
Remote Assistance uses IIRC) that one or both users must enter into the 
chrome might help.

Ah, such easy problems....

-- 
Randell Jesup
randell-ietf@jesup.org