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

Igor Faynberg <igor.faynberg@alcatel-lucent.com> Tue, 20 March 2012 18:46 UTC

Return-Path: <igor.faynberg@alcatel-lucent.com>
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 D43F021F8557 for <rtcweb@ietfa.amsl.com>; Tue, 20 Mar 2012 11:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.312
X-Spam-Level:
X-Spam-Status: No, score=-7.312 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 lktyWwn7pBvR for <rtcweb@ietfa.amsl.com>; Tue, 20 Mar 2012 11:46:21 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0FA21F8555 for <rtcweb@ietf.org>; Tue, 20 Mar 2012 11:46:21 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q2KIkHQi028527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Mar 2012 13:46:18 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2KIkHlO005920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Mar 2012 13:46:17 -0500
Received: from [135.244.33.178] (faynberg.lra.lucent.com [135.244.33.178]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2KIkFxF000632; Tue, 20 Mar 2012 13:46:16 -0500 (CDT)
Message-ID: <4F68D077.8060803@alcatel-lucent.com>
Date: Tue, 20 Mar 2012 14:46:15 -0400
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>
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>
In-Reply-To: <4F685ED9.2050109@alvestrand.no>
Content-Type: multipart/alternative; boundary="------------040506050507000604020604"
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
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
Reply-To: igor.faynberg@alcatel-lucent.com
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 18:46:21 -0000

Harald,

Many thanks!  I did just what you suggested, and spent happy three hours 
figuring out what is going on.  I found something that claims to be my 
own certificate, allegedly signed by me (which I swear I have never 
done) as well as many other certificates from the authorities I never 
knew (nor could find any information about).  On top of all, I found two 
certificates that allege being issued by Microsoft, while they are 
marked as fraudulent. (So somenone is checking this stuff and takes action?)

The above report speaks for itself.

The key finding though is that the browser interface in NOT the only way 
to get the certificates in.  Anyone can put them in a directory, and 
this a big problem for the "hacker meaning."   Incidentally, this is not 
only the browser matter--same holds for the OS.

If root certificates were to be installed only through the browser 
administrative interface, I imagine the browser could send me a warning 
or even deny the installation.  I know there is a lot to think through 
on how to bootstrap this process, but I think it should  be possible to 
achieve.  But in this case it appears to me that the browser would need 
to have its own independent file system controlled only through the 
administrative interface.

It also appears to me that the interface should be password-protected so 
that only the legitimate owner (including corporate) can control the 
installation of root certificates. If the hacker who does not know the 
administrative password just got  access to my computer (say, via JS), 
there is no way for this hacker to  install the certificate.

I know that this issue takes off on a tangent from the RTCWeb 
discussion, so I don't want to start that. But I wanted to acknowledge 
your message and thank you for responding.  Maybe we could talk about 
this with you, Hui-Lan, and Eric off-line.

Igor

On 3/20/2012 6:41 AM, Harald Alvestrand wrote:
> 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.
>
>