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 <pyalot@gmail.com> 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.

https://tools.ietf.org/html/rfc6347#section-3.2.2



>
> On Wed, Dec 2, 2015 at 2:05 PM, Aymeric Vitte <vitteaymeric@gmail.com>
> wrote:
>
>>
>>
>> Le 02/12/2015 13:18, Florian Bösch a écrit :
>> > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte <vitteaymeric@gmail.com
>> > <mailto:vitteaymeric@gmail.com>> 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 https://github.com/Ayms/node-Tor#security, 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:
>> https://github.com/Ayms/node-Tor#pieces-and-sliding-window for WebRTC
>>
>> And again, adding a TLS layer on top of all this is of complete no use.
>>
>> --
>> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
>> Check the 10 M passwords list: http://peersm.com/findmyass
>> Anti-spies and private torrents, dynamic blocklist:
>> http://torrent-live.org
>> Peersm : http://www.peersm.com
>> torrent-live: https://github.com/Ayms/torrent-live
>> node-Tor <https://github.com/Ayms/torrent-livenode-Tor> :
>> https://www.github.com/Ayms/node-Tor
>> GitHub : https://www.github.com/Ayms
>>
>
>