Re: [rtcweb] Same location media

Bernard Aboba <> Thu, 20 October 2011 18:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B250721F84F8 for <>; Thu, 20 Oct 2011 11:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.477
X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id le-Ic86kaNGx for <>; Thu, 20 Oct 2011 11:05:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 929F121F8BE4 for <>; Thu, 20 Oct 2011 11:05:40 -0700 (PDT)
Received: from BLU152-W47 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 11:05:40 -0700
Message-ID: <BLU152-W47FFB556E3F8FAB1EE9F5193EB0@phx.gbl>
Content-Type: multipart/alternative; boundary="_95846c9f-2599-47d5-99bc-64d865dfd76f_"
X-Originating-IP: []
From: Bernard Aboba <>
Date: Thu, 20 Oct 2011 11:05:39 -0700
Importance: Normal
In-Reply-To: <>
References: <>, <BLU152-W274DC7DC92EF49307BC57D93EB0@phx.gbl>, <>, <BLU152-W6591495353D395650050F293EB0@phx.gbl>, <>, <BLU152-W404F6E9A2510EBAC9F1C1F93EB0@phx.gbl>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Oct 2011 18:05:40.0297 (UTC) FILETIME=[E0784390:01CC8F52]
Subject: Re: [rtcweb] Same location media
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, 20 Oct 2011 18:05:41 -0000

Yes, Turn over TLS is non-distinguishable.  However, we've found deep inspection firewalls that will actually attempt to parse the TLS negotiation.  This creates brittleness to extensions in general.  Anything that is not "vanilla" could potentially fall prey, including TLS extensions, Websockets, etc.  Sad, but true.

Date: Thu, 20 Oct 2011 13:58:40 -0400
Subject: Re: [rtcweb] Same location media

On Thu, Oct 20, 2011 at 1:02 PM, Bernard Aboba <> wrote:

[BA] With respect to TURN with TCP/TLS we have found some firewalls that actually do deep packet inspection.  So if you're sending to TCP port 80 and aren't using HTTP, or are sending to port 443 and aren't using TLS (or are using TLS extensions the firewall doesn't understand), the firewall can block.   So yes, it is important to support TURN with TCP/TLS, but it should be recognized that even with that, there will still be a significant percentage of failures. 


TURN over TLS is non-distinguishable (unless I am missing something) from HTTPS connection. It is using the same TLS transport as HTTPS and firewall cannot inspect the actual data transmitted. Firewall can probably do some sort of heuristics based on packet sizes, but this will not be reliable enough to distinguish TURN over TLS from HTTPS (or real time media over HTTPS). In any case, if people are persistent enough they will find the way to block RTC connections regardless of the protocol used.

Roman Shpount