Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

On Wed, Dec 2, 2015 at 9:36 AM, Florian Bösch <> wrote:

> 1) Encryption between Alice and Bob by means of an asymmetric
> public/private key exchange protocol cannot be secure if both also exchange
> the keys and none has a method to verify the keys they got are the correct
> ones. Chuck who might control the gateway over which either Alice or Bob
> communicate can simply substitute his own public key for either of the two.
> The whole point of certificates is that the sought out endpoint can provide
> a set of credentials that're signed by a certificate authority, which is in
> a chain of trust up to the root authority which is implicitly trusted.
> 2) You cannot obtain the benefits of UDP (out of order packages as fast as
> they come) and yet retain the benefits of asymmetric public/private key
> encryption schemes which rely on packages arriving in order. Attempting to
> get both will result in detrimental performance or non existent security.

I think that if you read the DTLS spec, you'll see that it handles
reordering just fine.

> On Wed, Dec 2, 2015 at 2:05 PM, Aymeric Vitte <>
> wrote:
>> Le 02/12/2015 13:18, Florian Bösch a écrit :
>> > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte <
>> > <>> wrote:
>> >
>> >     Then you should follow your rules and apply this policy to WebRTC,
>> ie
>> >     allow WebRTC to work only with http.
>> >
>> >
>> > Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP.
>> > Also WebRTC does P2P, and there's no certificates/authorities there (you
>> > could encrypt, but I don't think it does even when using TCP/IP (which
>> > it doesn't in case of streaming video over UDP).
>> See, WebRTC uses DTLS with
>> self-signed certifcates + a third party mechanism supposed to secure the
>> connection.
>> As a matter of fact this is almost exactly the same mechanism used by
>> the Tor network, where the CERTS cells use the long term ID key of a Tor
>> node to make sure that you are discussing with that one.
>> This does not prevent of course from discussing with a malicious node
>> not identified as such with valid long term ID keys, which is not a
>> problem for Tor (but is a problem for WebRTC), as long as it behaves as
>> expected, and if it does not, this will be detected.
>> The above mechanism is specific to the Tor network, for other uses of
>> the Tor protocol an alternative is explained here:
>> for WebRTC
>> And again, adding a TLS layer on top of all this is of complete no use.
>> --
>> Get the torrent dynamic blocklist:
>> Check the 10 M passwords list:
>> Anti-spies and private torrents, dynamic blocklist:
>> Peersm :
>> torrent-live:
>> node-Tor <> :
>> GitHub :

Received on Wednesday, 2 December 2015 14:55:31 UTC