Re: [rtcweb] SRTP and "marketing"

Roman Shpount <> Thu, 29 March 2012 05:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04EB321E8037 for <>; Wed, 28 Mar 2012 22:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.827
X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 06WsZq4F+8sR for <>; Wed, 28 Mar 2012 22:42:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C726321E8015 for <>; Wed, 28 Mar 2012 22:42:58 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so2945885pbb.31 for <>; Wed, 28 Mar 2012 22:42:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=LPGllpoOw3hw3cjuNzrHWGxIxQScuDs/Zq6xK19Ev2U=; b=ZRXx8pc2P2jIC5gqPWw7Lu4FhTbcsJboukxPHGDvm2Z7nii2uU2oHCshRSwSpe06Do jI8zA20STv3q6BF8Flg1/fGgG3S7uSv9NlIC2cYtodE+cY/GEG9KeRLIjmHtAJYotRdF LZRNvhqsQhpomgSwni4moj0VxhiAcdD1gFw4UJIAZptnMsp4hadUW419vDR4Qxh+nR5g SNZwDf1h0DcrZzL1t/CGwRx6RlOJyDFPMvkgSjsnSaogg5hQui3tOAFpgFDYo7LhVVaB zxrsOTkq8yDD0uDRAH7eFh1epOCj6wEEUMe2sCtaudx+axSfMCiOK3Q9+4tW1A02xnEV z4eQ==
Received: by with SMTP id hv7mr2800170pbc.133.1332999778559; Wed, 28 Mar 2012 22:42:58 -0700 (PDT)
Received: from ( []) by with ESMTPS id y2sm4234382pbe.67.2012. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 22:42:57 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so2945853pbb.31 for <>; Wed, 28 Mar 2012 22:42:56 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id sx3mr2779986pbc.55.1332999776978; Wed, 28 Mar 2012 22:42:56 -0700 (PDT)
Received: by with HTTP; Wed, 28 Mar 2012 22:42:56 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 29 Mar 2012 01:42:56 -0400
Message-ID: <>
From: Roman Shpount <>
To: "Timothy B. Terriberry" <>
Content-Type: multipart/alternative; boundary=047d7b2edf0331489504bc5b327c
X-Gm-Message-State: ALoCoQkz2fCWgDLptSN6x4ZUaA2kArw1cnMv0vgF90ogukR3szVpaucafCajjNtaBVGh5z+1jTeT
Subject: Re: [rtcweb] SRTP and "marketing"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Mar 2012 05:43:00 -0000

On Wed, Mar 28, 2012 at 10:30 PM, Timothy B. Terriberry <> wrote:

> Hadriel Kaplan wrote:
>> As far as I know, you don't actually "know" that with Skype.  You assume
>> it,
>> because you trust Skype.  They could forge whatever identity they wanted
>> to,
>> and they can insert a recording middlebox if they wanted to, afaict.
>> No one is concerned about that.  They also have skype-in/skype-out to/from
> This is, of course, not true. See, for example,
> http://www.technologyreview.**com/web/38379/<>
> The relevant bit, for those who don't want to read the whole article: '"We
> met using Mumble [which is open-source, uses digital certificate
> authentication, and is regarded by Takriz as more secure than Skype].'
> (brackets in the original).
> Which is not to say that Tunisian rebels never used Skype (the article
> mentions several instances where they did), but it is clearly inaccurate to
> say no one was concerned about it.
And then there is an argument that Skype is a huge security risk exactly
due to the fact that it is using encrypted communications. There were hints
of using Skype communication protocol and Skype client to access files
remotely on the user computer or ability to open ports into a local network
using a Skype client running there (using Skype as a malicious VPN client).
Entire protocol and client are proprietary and were never validated by an
independent party as being secure in a sense of preventing unauthorized
remote access. This is one of the reasons why Skype is not allowed in a lot
of corporate or government networks. Even though this should not apply to
WebRTC since it is going to be an open standard with an intensive peer
review, it would still apply to the web browsers. If web browser software
is compromised due to some sort of attack or malicious plugin (or one of
the browser vendors snooping), and since browser applications will start
establishing unsolicited encrypted connections, there is no easy way to
determine that the browser is not doing something undesirable.  I actually
believe that if sufficient monitoring constraints are not build into a
browser (not to record but at least to monitor who the browser is
exchanging data with and using what protocols), WebRTC would be simply
disabled in most enterprises as a security risk.
Roman Shpount