IETF Logo Mail Archive

Re: [rtcweb] Resolving RTP/SDES question in Paris

Harald Alvestrand <harald@alvestrand.no> Tue, 20 March 2012 15:40 UTC

Return-Path: <harald@alvestrand.no>
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 5EA8021F85A0 for <rtcweb@ietfa.amsl.com>; Tue, 20 Mar 2012 08:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level:
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 vTq4EFncusoB for <rtcweb@ietfa.amsl.com>; Tue, 20 Mar 2012 08:40:04 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 51DED21F8598 for <rtcweb@ietf.org>; Tue, 20 Mar 2012 08:40:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8DAAA39E132; Tue, 20 Mar 2012 16:40:03 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vga9TdMn6cV6; Tue, 20 Mar 2012 16:40:02 +0100 (CET)
Received: from [78.65.120.97] (host-78-65-120-97.homerun.telia.com [78.65.120.97]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 867D539E0E7; Tue, 20 Mar 2012 16:40:02 +0100 (CET)
Message-ID: <4F68A4CC.9090306@alvestrand.no>
Date: Tue, 20 Mar 2012 16:39:56 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: Roman Shpount <roman@telurix.com>
References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <CALiegfnkYVEpmPV-zSL_4wOY-HiFZN-qJCQCiioaS=5NaqhLZw@mail.gmail.com> <CAD5OKxvtOAxMBx6xDnyfTnEq76oDEm6uj1xL6wGjjrtKUAHy3g@mail.gmail.com> <CABcZeBNZiotPmCfT53uEo+O0xw4xv6tXW1M_G-3A5BHuncsduA@mail.gmail.com> <CAD5OKxvYOY5JZ2mYNGiH1poUBQkyOOycePFijH5H+SxtcdqujQ@mail.gmail.com> <CABkgnnVe-b6Sv=R67bMJk_NQqQwdrRUn6rBm7Gu_CMcfPQwtEg@mail.gmail.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <CAD5OKxsVp7px9bHAgxgdqPMxRgppcVUDKt8JHBhyq9qqW3pAMg@mail.gmail.com>
In-Reply-To: <CAD5OKxsVp7px9bHAgxgdqPMxRgppcVUDKt8JHBhyq9qqW3pAMg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------010107050405090001030409"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
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: Tue, 20 Mar 2012 15:40:05 -0000

On 03/20/2012 02:40 PM, Roman Shpount wrote:
> Once again, I understand how this helps in case of HTTPS, but how 
> would this help in case of WebRTC? Media description is carried in 
> some sort of application defined protocol (can even be transmitted 
> over an encrypted SCTP data channel or encrypted in javaScript), so 
> monitoring proxy cannot reliably modify it. I understand how it can be 
> allowed to fake the signature on modified SDP by inserting a 
> certificate in the browser, but how would the proxy get to the SDP in 
> the first place?

"this" = inserting a trust root in the browser?

Once you trust the root I inserted, I can intercept all your HTTPS 
connections, and thus I can replace all the Javascript you think you are 
loading from your trusted provider with Javascript of my choice.

Once your browser is running my Javascript, I can do anything the 
original application could - with the privilleges you granted to that 
application.

I think that's more or less "game over" when it comes to security.


> _____________
> Roman Shpount
>
>
> On Tue, Mar 20, 2012 at 6:41 AM, Harald Alvestrand 
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>
>     On 03/17/2012 10:14 PM, Igor Faynberg wrote:
>>     ..
>>
>>     On 3/17/2012 4:45 PM, Martin Thomson wrote:
>>>     ... Then I explicitly place a trust anchor for that
>>>     certificate in your browser.
>>
>>     How?  I thought the browser would never allow that to happen. (I
>>     assumed it would come provisioned with anchors,  or would allow
>>     anchor provision through some different channel.)
>>
>     Igor,
>
>     in Chrome, go to chrome://settings/certificates, choose the
>     "authorities" tab, and note the presence of the "import" button.
>
>     All browsers (as far as I know) have similar mechanisms.
>     "Owning" your computer will achieve this goal both in its
>     corporate meaning and in its hacker meaning.
>
>
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>

v2.23.0 | Report a Bug | By Email