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

[Florian Bösch]

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.

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 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://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>

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

[Richard Barnes]

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.

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



>
> 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 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://www.github.com/Ayms/node-Tor
>> GitHub : https://www.github.com/Ayms
>>
>
>

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

[Florian Bösch]

>
> In DTLS, each handshake message is assigned a specific sequence
>number within that handshake.  When a peer receives a handshake
>message, it can quickly determine whether that message is the next
>message it expects.  If it is, then it processes it.  If not, it
>queues it for future handling once all previous messages have been
>received.
>
>
The point of receiving UDP packets with fresh unqueued data is performance.
If you queue the packet for future handling, you've thrown that away, and
it begs the question, why don't you just use TCP/IP (which guarantees
ordering)...

On Wed, Dec 2, 2015 at 3:54 PM, Richard Barnes  wrote:

>
>
> 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.
>
> https://tools.ietf.org/html/rfc6347#section-3.2.2
>
>
>
>>
>> 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 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://www.github.com/Ayms/node-Tor
>>> GitHub : https://www.github.com/Ayms
>>>
>>
>>
>

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

[Richard Barnes]

On Wed, Dec 2, 2015 at 10:01 AM, Florian Bösch  wrote:

> In DTLS, each handshake message is assigned a specific sequence
>>number within that handshake.  When a peer receives a handshake
>>message, it can quickly determine whether that message is the next
>>message it expects.  If it is, then it processes it.  If not, it
>>queues it for future handling once all previous messages have been
>>received.
>>
>>
> The point of receiving UDP packets with fresh unqueued data is
> performance. If you queue the packet for future handling, you've thrown
> that away, and it begs the question, why don't you just use TCP/IP (which
> guarantees ordering)...
>

Because the queuing is only done for handshake messages, which are a tiny
fraction of all the messages sent in a typical DTLS session.  Other
messages can be reordered, dropped, etc.



>
> On Wed, Dec 2, 2015 at 3:54 PM, Richard Barnes 
> wrote:
>
>>
>>
>> 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.
>>
>> https://tools.ietf.org/html/rfc6347#section-3.2.2
>>
>>
>>
>>>
>>> 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 <
 vitteayme...@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://www.github.com/Ayms/node-Tor
 GitHub : https://www.github.com/Ayms

>>>
>>>
>>
>

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

[Aymeric Vitte]

Le 01/12/2015 20:41, Brad Hill a écrit :
>> As far as I see it, a "mixed content" has the word "content", which is
> supposed to designate something that can be included in a web page and
> therefore be dangerous.
> 
> "Mixed Content" (and "mixed content blocking") is a term of art that has
> been in use for many years in the browser community.  As such, you are
> correct that it is a bit inadequate in that it's coinage predates the
> widespread use of AJAX-type patterns, but we felt that it was better to
> continue to use and refine a well-known term than to introduce a new
> term. Apologies if this has created any confusion.
> 
> More than just "content", the question boils down to "what does seeing
> the lock promise the user?"  Browsers interpret the lock as a promise to
> the user that the web page / application they are currently interacting
> with is safe according to the threat model of TLS.  That is to say, it
> is protected end-to-end on the network path against attempts to
> impersonate, eavesdrop or modify traffic.  In a modern browser, this
> includes not just fetches of images and script done declaratively in
> HTML, but any kind of potentially insecure network communication.
> 

Then you should follow your rules and apply this policy to WebRTC, ie
allow WebRTC to work only with http.

> In general, we've seen this kind of argument before for building secure
> protocols at layer 7 on top of insecure transports - notably Netflix's
> "Message Security Layer".  Thus far, no browser vendors have been
> convinced that these are good ideas, that there is a way to safely allow
> their use in TLS-protected contexts, or that building these systems with
> existing TLS primitives is not an adequate solution.

Netflix's MSL doc is not clear and just mentions an issue with http (not
ws) inside https, probably they have the very same problem with non
valid certificates.

Browser vendors are convinced that http with ws is better than https
with ws...

Could you please provide an example of serious issue regarding https
with ws?

> 
> In specific, I don't think you'll ever find support for treating Tor
> traffic that is subject to interception and modification after it leaves
> an exit node as equivalent to HTTPS

??? Do you really know the Tor protocol?

And where did you see this in the use cases (something that exits)?

If something has to exit Tor it's obvious that https must be used, the
exit node is by design a potential mitm.

But https inside the Tor protocol.

Using wss to send the Tor traffic does not change anything to this
situation.

This contradiction that you highlight here just shows again that the
current rules are not logical.

, especially since we know there are
> active attacks being mounted against this traffic on a regular basis.
>  (This is why I suggested .onion sites as potentially secure contexts,
> which do not suffer from the same exposure outside of the Tor network.)

Same as above, that's the third or fourth time in this thread that I am
talked about the fb hidden service and its .onion certificate, supposed
to improve some security while it does not (or a very little in case fb
hidden service is not located with the Tor server, but that's more a fb
configuration issue)

That's another proof that https does not improve anything here.

While browsing hidden services could be a use case in the future (once
the "browsing paradox" is solved), I am not talking about this for now,
I am talking about using the Tor protocol or another secure protocole
for multiple services.


> 
> -Brad
> 
> On Tue, Dec 1, 2015 at 5:42 AM Aymeric Vitte  > wrote:
> 
> 
> 
> Le 01/12/2015 05:31, Brad Hill a écrit :
> > Let's keep this discussion civil, please.
> 
> Maybe some wording was a little tough below, apologies for this, the
> logjam attack is difficult to swallow, how something that is supposed to
> protect forward secrecy can do quietly the very contrary without even
> having the keys compromised, it's difficult to understand too why TLS
> did not implement a mechanism to protect the DH client public key.
> 
> >
> > The reasons behind blocking of non-secure WebSocket connections from
> > secure contexts are laid out in the following document:
> >
> > http://www.w3.org/TR/mixed-content/
> >
> > A plaintext ws:// connection does not meet the requirements of
> > authentication, encryption and integrity, so far as the user agent is
> > able to tell, so it cannot allow it.
> 
> The spec just mentions to align the behavior of ws to xhr, fetch and
> eventsource without giving more reasons, or I missed them.
> 
> Let's concentrate on ws here.
> 
> As far as I see it, a "mixed content" has the word "content", which is
> supposed to designate something that can be included in a web page and
> therefore be dangerous.
> 
> WS cannot include anything in a 

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

[Florian Bösch]

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).

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

[Aymeric Vitte]

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 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://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

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

[Brad Hill]

> As far as I see it, a "mixed content" has the word "content", which is
supposed to designate something that can be included in a web page and
therefore be dangerous.

"Mixed Content" (and "mixed content blocking") is a term of art that has
been in use for many years in the browser community.  As such, you are
correct that it is a bit inadequate in that it's coinage predates the
widespread use of AJAX-type patterns, but we felt that it was better to
continue to use and refine a well-known term than to introduce a new term.
Apologies if this has created any confusion.

More than just "content", the question boils down to "what does seeing the
lock promise the user?"  Browsers interpret the lock as a promise to the
user that the web page / application they are currently interacting with is
safe according to the threat model of TLS.  That is to say, it is protected
end-to-end on the network path against attempts to impersonate, eavesdrop
or modify traffic.  In a modern browser, this includes not just fetches of
images and script done declaratively in HTML, but any kind of potentially
insecure network communication.

In general, we've seen this kind of argument before for building secure
protocols at layer 7 on top of insecure transports - notably Netflix's
"Message Security Layer".  Thus far, no browser vendors have been convinced
that these are good ideas, that there is a way to safely allow their use in
TLS-protected contexts, or that building these systems with existing TLS
primitives is not an adequate solution.

In specific, I don't think you'll ever find support for treating Tor
traffic that is subject to interception and modification after it leaves an
exit node as equivalent to HTTPS, especially since we know there are active
attacks being mounted against this traffic on a regular basis.  (This is
why I suggested .onion sites as potentially secure contexts, which do not
suffer from the same exposure outside of the Tor network.)

-Brad

On Tue, Dec 1, 2015 at 5:42 AM Aymeric Vitte  wrote:

>
>
> Le 01/12/2015 05:31, Brad Hill a écrit :
> > Let's keep this discussion civil, please.
>
> Maybe some wording was a little tough below, apologies for this, the
> logjam attack is difficult to swallow, how something that is supposed to
> protect forward secrecy can do quietly the very contrary without even
> having the keys compromised, it's difficult to understand too why TLS
> did not implement a mechanism to protect the DH client public key.
>
> >
> > The reasons behind blocking of non-secure WebSocket connections from
> > secure contexts are laid out in the following document:
> >
> > http://www.w3.org/TR/mixed-content/
> >
> > A plaintext ws:// connection does not meet the requirements of
> > authentication, encryption and integrity, so far as the user agent is
> > able to tell, so it cannot allow it.
>
> The spec just mentions to align the behavior of ws to xhr, fetch and
> eventsource without giving more reasons, or I missed them.
>
> Let's concentrate on ws here.
>
> As far as I see it, a "mixed content" has the word "content", which is
> supposed to designate something that can be included in a web page and
> therefore be dangerous.
>
> WS cannot include anything in a page by itself, it is designed to
> discuss with external entities, for other purposes than fetching
> resources (images, js, etc) from web servers that are logically tied to
> a domain, in that case you can use xhr or other fetching means instead.
>
> Therefore it is logical to envision that those external entities used
> with WS are not necessarily web servers and might not have valid
> certificates.
>
> WS cannot hurt anything unless the application decides to insert the
> results in the page, which is not something problematic with WS only,
> the application is loaded via https, so is supposed to be secure but if
> it is doing wrong things nothing can save you, even wss.
>
> Unlike usual fetching means, in case of malicious use WS cannot really
> hurt like scaning URLs, this is a specific protocol not talked by anybody.
>
> As a result of the current policy, if we want to establish WS with
> entities that can't have a valid certificate, we must load the code via
> http which is obviously completely insecure.
>
> So forbiding WS with https is just putting the users at risk and prevent
> any current or future uses of ws with entities that can't have a valid
> certificate, therefore reducing the interest and potential of ws to
> something very small.
>
>
> >
> > If there is a plausible mechanism by which browsers could distinguish
> > external communications which meet the necessary security criteria using
> > protocols other than TLS or authentication other than from the Web PKI,
> > there is a reasonable case to be made that such could be considered as
> > potentially secure origins and URLs.  (as has been done to some extent
> > for WebRTC, as you have already noted)
> >
>
> To some extent yes... maybe some 

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

[Aymeric Vitte]

Le 01/12/2015 05:31, Brad Hill a écrit :
> Let's keep this discussion civil, please.  

Maybe some wording was a little tough below, apologies for this, the
logjam attack is difficult to swallow, how something that is supposed to
protect forward secrecy can do quietly the very contrary without even
having the keys compromised, it's difficult to understand too why TLS
did not implement a mechanism to protect the DH client public key.

> 
> The reasons behind blocking of non-secure WebSocket connections from
> secure contexts are laid out in the following document:
> 
> http://www.w3.org/TR/mixed-content/
> 
> A plaintext ws:// connection does not meet the requirements of
> authentication, encryption and integrity, so far as the user agent is
> able to tell, so it cannot allow it.  

The spec just mentions to align the behavior of ws to xhr, fetch and
eventsource without giving more reasons, or I missed them.

Let's concentrate on ws here.

As far as I see it, a "mixed content" has the word "content", which is
supposed to designate something that can be included in a web page and
therefore be dangerous.

WS cannot include anything in a page by itself, it is designed to
discuss with external entities, for other purposes than fetching
resources (images, js, etc) from web servers that are logically tied to
a domain, in that case you can use xhr or other fetching means instead.

Therefore it is logical to envision that those external entities used
with WS are not necessarily web servers and might not have valid
certificates.

WS cannot hurt anything unless the application decides to insert the
results in the page, which is not something problematic with WS only,
the application is loaded via https, so is supposed to be secure but if
it is doing wrong things nothing can save you, even wss.

Unlike usual fetching means, in case of malicious use WS cannot really
hurt like scaning URLs, this is a specific protocol not talked by anybody.

As a result of the current policy, if we want to establish WS with
entities that can't have a valid certificate, we must load the code via
http which is obviously completely insecure.

So forbiding WS with https is just putting the users at risk and prevent
any current or future uses of ws with entities that can't have a valid
certificate, therefore reducing the interest and potential of ws to
something very small.


> 
> If there is a plausible mechanism by which browsers could distinguish
> external communications which meet the necessary security criteria using
> protocols other than TLS or authentication other than from the Web PKI,
> there is a reasonable case to be made that such could be considered as
> potentially secure origins and URLs.  (as has been done to some extent
> for WebRTC, as you have already noted)
> 

To some extent yes... maybe some other solutions could be studied via
something like letsencrypt to get automatically something like temporary
valid certificates (which then might eliminate the main topic of this
discussion if feasible)


> If you want to continue this discussion here, please:
> 
> 1) State your use cases clearly for those on this list who do not
> already know them.  You want to "use the Tor protocol" over websockets? 

Note: I am not affiliated at all to the Tor project

Yes, that's already a reality with projects such as Peersm and Flashproxy.

Peersm has the onion proxy function inside browsers which establishes
Tor circuits with Tor nodes using WS.

Flashproxy connects a censored Tor user to a Tor node and relays the Tor
protocol using WS between both.

> To connect to what?  Why? 

The Tor protocol is just an example, let's see it as another secure
protocol.

If we go further, we can imagine what I described here:
https://mailman.stanford.edu/pipermail/liberationtech/2015-November/015680.html

Which mentions the "browsing paradox" too.

Not usual I believe (last paragraph, the idea is not to proxy only to
URLs as it is today but to proxy to interfaces, such as ws,xhr and
WebRTC), but this will happen one day (maybe I should patent this too...)

Applications are numerous and not restricted to those examples.

 Why is it important to bootstrap an
> application like this over regular http(s) instead of, for example, as
> an extension or modified user-agent like TBB?

The Tor Browser is designed for secure browsing, because for example
solving the "browsing paradox" and having the onion proxy inside
browsers is not enough to insure secure anonymous browsing, Tor
Browser's features will still be required.

Some applications need some modifications of the browser, some others
need extensions but plenty of applications could be installed from the
web sites directly.

The obvious advantages are: no installation, works on any
device/platform, no dev/maintenance of the application for different
platforms with the associated risks (sw integrity) and complexity for
the users (not talking here about the problematic aspect of code loading
for a web 

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

[Aymeric Vitte]

Not sure that you know what you are talking about here, maybe influenced
by fb's onion things, or you misunderstood what I wrote.

I am not talking about the Tor network, neither the Hidden services, I
am talking about the Tor protocol itself, that's different and it is
known to be strong, but this is just an example, let's see it as another
secure protocol to connect browsers to other entities that can not have
valid certificates for obvious reasons.

Whatever number of bits are used for RSA/sym crypto/SHA the Tor protocol
is resistant to the logjam trivial DH_export quasi undetectable
downgrade attack that nobody anticipated during years, on purpose or
not, I don't know, but that's obvious that the DH client public key for
TLS could have been protected by the public key of the server, like the
Tor protocol is doing, so maybe you should refrain your compliments
about TLS.

And the Tor protocol have TLS on top of it, so below the right sequence
is ws + TLS + Tor protocol.

And it checks that the one you are connected to is the one with whom you
have established the TLS connection (who can be a MITM again, but you
don't care, you just want to be sure with whom you are discussing with,
like what WebRTC is trying to do)

But again, that's not really the subject of the discussion, the subject
is what is really the problem of letting an interface that has access to
nothing (WS) work with https? Knowing that you can use it with another
protocol that you can estimate better, but could be worse, again what
does it hurt?

Or just deprecate ws because if it has to work only with entities that
own valid certificates, then it's of quasi no use for the future.

Le 30/11/2015 21:00, Brad Hill a écrit :
> I don't think there is universal agreement among browser engineers (if
> anyone agrees at all) with your assertion that the Tor protocol or even
> Tor hidden services are "more secure than TLS".  TLS in modern browsers
> requires RSA 2048-bit or equivalent authentication, 128-bit symmetric
> key confidentiality and SHA-256 or better integrity.If .onion
> identifiers and the Tor protocol crypto were at this level of strength,
> it would be reasonable to argue that a .onion connection represented a
> "secure context", and proceed from there.  In the meantime, with .onion
> site security (without TLS) at 80-bits of truncation of a SHA-1 hash of
> a 1024 bit key, I don't think you'll get much traction in insisting it
> is equivalent to or better than TLS.
> 
> On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte  > wrote:
> 
> Redirecting this to WebApps since it's probable that we are facing a
> design mistake that might amplify by deprecating non TLS connections. I
> have submitted the case to all possible lists in the past, never got a
> clear answer and was each time redirected to another list (ccing
> webappsec but as a whole I think that's a webapp matter, so please don't
> state only that "downgrading a secure connection to an insecure one is
> insecure").
> 
> The case described below is simple:
> 
> 1- https page loading the code, the code establishes ws + the Tor
> protocol to "someone" (who can be a MITM or whatever, we don't care as
> explained below)
> 
> 2- http page loading the code, the code establishes ws + the Tor
> protocol
> 
> 3- https page loading the code, the code establishes wss + the Tor
> protocol
> 
> 4- https page loading the code, the code establishes normal wss
> connections
> 
> 3 fails because the WS servers have self-signed certificates.
> 
> What is insecure between 1 and 2? Obviously this is 2, because loading
> the code via http.
> 
> Even more, 1 is more secure than 4, because the Tor protocol is more
> secure than TLS.
> 
> It's already a reality that projects are using something like 1 and will
> continue to build systems on the same principles (one can't argue that
> such systems are unsecure or unlikely to happen, that's not true, see
> the Flashproxy project too).
> 
> But 1 fails too, because ws is not allowed inside a https page, so we
> must use 2, which is insecure and 2 might not work any longer later.
> 
> Service Workers are doing about the same, https must be used, as far as
> I understand Service Workers can run any browser instance in background
> even if the spec seems to focus more on the offline aspects, so I
> suppose that having 1 inside a (background) Service Worker will fail
> too.
> 
> Now we have the "new" "progressive Web Apps" which surprisingly present
> as a revolution the possibility to have a web app look like a native app
> while it can be done on iOS since the begining, same thing for some
> offline caching features that were possible before, but this indeed
> brings new things, hopefully we can have one day something like all the
> cordova features 

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

[Richard Barnes]

On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte 
wrote:

> Not sure that you know what you are talking about here, maybe influenced
> by fb's onion things, or you misunderstood what I wrote.
>
> I am not talking about the Tor network, neither the Hidden services, I
> am talking about the Tor protocol itself, that's different and it is
> known to be strong, but this is just an example, let's see it as another
> secure protocol to connect browsers to other entities that can not have
> valid certificates for obvious reasons.
>

HTTPS gives you the following essential properties:
1. Authentication: You know that you're talking to who you think you're
talking to.
2. Confidentiality: Nobody else can see what you're saying
3. Integrity: Nobody else can interfere with your communications

Show me another protocol that achieves those properties, and maybe we'll
have something to talk about.  Tor doesn't.

--Richard


Whatever number of bits are used for RSA/sym crypto/SHA the Tor protocol
> is resistant to the logjam trivial DH_export quasi undetectable
> downgrade attack that nobody anticipated during years, on purpose or
> not, I don't know, but that's obvious that the DH client public key for
> TLS could have been protected by the public key of the server, like the
> Tor protocol is doing, so maybe you should refrain your compliments
> about TLS.
>
> And the Tor protocol have TLS on top of it, so below the right sequence
> is ws + TLS + Tor protocol.
>
> And it checks that the one you are connected to is the one with whom you
> have established the TLS connection (who can be a MITM again, but you
> don't care, you just want to be sure with whom you are discussing with,
> like what WebRTC is trying to do)
>
> But again, that's not really the subject of the discussion, the subject
> is what is really the problem of letting an interface that has access to
> nothing (WS) work with https? Knowing that you can use it with another
> protocol that you can estimate better, but could be worse, again what
> does it hurt?
>
> Or just deprecate ws because if it has to work only with entities that
> own valid certificates, then it's of quasi no use for the future.
>
> Le 30/11/2015 21:00, Brad Hill a écrit :
> > I don't think there is universal agreement among browser engineers (if
> > anyone agrees at all) with your assertion that the Tor protocol or even
> > Tor hidden services are "more secure than TLS".  TLS in modern browsers
> > requires RSA 2048-bit or equivalent authentication, 128-bit symmetric
> > key confidentiality and SHA-256 or better integrity.If .onion
> > identifiers and the Tor protocol crypto were at this level of strength,
> > it would be reasonable to argue that a .onion connection represented a
> > "secure context", and proceed from there.  In the meantime, with .onion
> > site security (without TLS) at 80-bits of truncation of a SHA-1 hash of
> > a 1024 bit key, I don't think you'll get much traction in insisting it
> > is equivalent to or better than TLS.
> >
> > On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte  > > wrote:
> >
> > Redirecting this to WebApps since it's probable that we are facing a
> > design mistake that might amplify by deprecating non TLS
> connections. I
> > have submitted the case to all possible lists in the past, never got
> a
> > clear answer and was each time redirected to another list (ccing
> > webappsec but as a whole I think that's a webapp matter, so please
> don't
> > state only that "downgrading a secure connection to an insecure one
> is
> > insecure").
> >
> > The case described below is simple:
> >
> > 1- https page loading the code, the code establishes ws + the Tor
> > protocol to "someone" (who can be a MITM or whatever, we don't care
> as
> > explained below)
> >
> > 2- http page loading the code, the code establishes ws + the Tor
> > protocol
> >
> > 3- https page loading the code, the code establishes wss + the Tor
> > protocol
> >
> > 4- https page loading the code, the code establishes normal wss
> > connections
> >
> > 3 fails because the WS servers have self-signed certificates.
> >
> > What is insecure between 1 and 2? Obviously this is 2, because
> loading
> > the code via http.
> >
> > Even more, 1 is more secure than 4, because the Tor protocol is more
> > secure than TLS.
> >
> > It's already a reality that projects are using something like 1 and
> will
> > continue to build systems on the same principles (one can't argue
> that
> > such systems are unsecure or unlikely to happen, that's not true, see
> > the Flashproxy project too).
> >
> > But 1 fails too, because ws is not allowed inside a https page, so we
> > must use 2, which is insecure and 2 might not work any longer later.
> >
> > Service Workers are doing about the same, https must be used, as far
> 

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

[Aymeric Vitte]

Redirecting this to WebApps since it's probable that we are facing a
design mistake that might amplify by deprecating non TLS connections. I
have submitted the case to all possible lists in the past, never got a
clear answer and was each time redirected to another list (ccing
webappsec but as a whole I think that's a webapp matter, so please don't
state only that "downgrading a secure connection to an insecure one is
insecure").

The case described below is simple:

1- https page loading the code, the code establishes ws + the Tor
protocol to "someone" (who can be a MITM or whatever, we don't care as
explained below)

2- http page loading the code, the code establishes ws + the Tor protocol

3- https page loading the code, the code establishes wss + the Tor protocol

4- https page loading the code, the code establishes normal wss connections

3 fails because the WS servers have self-signed certificates.

What is insecure between 1 and 2? Obviously this is 2, because loading
the code via http.

Even more, 1 is more secure than 4, because the Tor protocol is more
secure than TLS.

It's already a reality that projects are using something like 1 and will
continue to build systems on the same principles (one can't argue that
such systems are unsecure or unlikely to happen, that's not true, see
the Flashproxy project too).

But 1 fails too, because ws is not allowed inside a https page, so we
must use 2, which is insecure and 2 might not work any longer later.

Service Workers are doing about the same, https must be used, as far as
I understand Service Workers can run any browser instance in background
even if the spec seems to focus more on the offline aspects, so I
suppose that having 1 inside a (background) Service Worker will fail too.

Now we have the "new" "progressive Web Apps" which surprisingly present
as a revolution the possibility to have a web app look like a native app
while it can be done on iOS since the begining, same thing for some
offline caching features that were possible before, but this indeed
brings new things, hopefully we can have one day something like all the
cordova features inside browsers + background/headless browser instances.

So we are talking about web apps here, not about a web page loading
plenty of http/https stuff, web apps that can be used as
independant/native apps or nodes to relay traffic and therefore discuss
with some entities that can't be tied to a domain and can only use
self-signed certificates (like WebRTC peers, why do we have a security
exception here allowing something for WebRTC and not for this case?).

Then 1 must be possible with WS and Service Workers, because there are
no reasons why it should not be allowed and this will happen in the
future under different forms (see the link below), that's not illogical,
if you use wss then you expect it to work as such (ie fail with
self-signed certificates for example), if you use ws (what terrible
things can happen with ws exactly? ws can't access the DOM or whatever)
then you are on your own and should better know what you are doing,
that's not a reason to force you to use much more insecure 2.

Such apps can be loaded while navigating on a web site, entirely (ie the
web site is the app), or for more wide distribution from different sites
than the original app site via an iframe (very ugly way) or extracted as
a component (cool way, does not seem to be foreseen by anybody) with
user prompt/validation ("do you want to install application X?")
possibly running in background when needed in a sandboxed context with
service workers.

Le 25/11/2015 17:43, Aymeric Vitte a écrit :
> 
> 
> Le 20/11/2015 12:35, Richard Barnes a écrit :
>> On Thu, Nov 19, 2015 at 8:40 AM, Hanno Böck  wrote:
>>
 It's amazing how the same wrong arguments get repeated again and
 again...

>> +1000
>>
>> All of these points have been raised and rebutted several times.  My
>> favorite reference is:
>>
>> https://konklone.com/post/were-deprecating-http-and-its-going-to-be-okay
>>
>>
>>
> 
> You might not break the current internet but its future.
> 
> Example: https://bugzilla.mozilla.org/show_bug.cgi?id=917829
> 
> How do you intend to solve this? ie the case of an entity that just
> cannot have valid certificates and/or implements a secure protocol on
> top of an insecure one (ws here for Peersm project, the other party can
> be by design a "MITM" but we completely don't care per the secure
> protocol used, the MITM will not know what happens next)?
> 
> Like WebRTC too, but there is an exception for that one, self-signed
> certificates are (by some luck) accepted.
> 
> It's obvious that browsers will be used for new services involving those
> mechanisms in the future, like P2P systems as sketched here:
> https://mailman.stanford.edu/pipermail/liberationtech/2015-November/015680.html
> 

-- 
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass

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

[Brad Hill]

I don't think there is universal agreement among browser engineers (if
anyone agrees at all) with your assertion that the Tor protocol or even Tor
hidden services are "more secure than TLS".  TLS in modern browsers
requires RSA 2048-bit or equivalent authentication, 128-bit symmetric key
confidentiality and SHA-256 or better integrity.If .onion identifiers
and the Tor protocol crypto were at this level of strength, it would be
reasonable to argue that a .onion connection represented a "secure
context", and proceed from there.  In the meantime, with .onion site
security (without TLS) at 80-bits of truncation of a SHA-1 hash of a 1024
bit key, I don't think you'll get much traction in insisting it is
equivalent to or better than TLS.

On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte 
wrote:

> Redirecting this to WebApps since it's probable that we are facing a
> design mistake that might amplify by deprecating non TLS connections. I
> have submitted the case to all possible lists in the past, never got a
> clear answer and was each time redirected to another list (ccing
> webappsec but as a whole I think that's a webapp matter, so please don't
> state only that "downgrading a secure connection to an insecure one is
> insecure").
>
> The case described below is simple:
>
> 1- https page loading the code, the code establishes ws + the Tor
> protocol to "someone" (who can be a MITM or whatever, we don't care as
> explained below)
>
> 2- http page loading the code, the code establishes ws + the Tor protocol
>
> 3- https page loading the code, the code establishes wss + the Tor protocol
>
> 4- https page loading the code, the code establishes normal wss connections
>
> 3 fails because the WS servers have self-signed certificates.
>
> What is insecure between 1 and 2? Obviously this is 2, because loading
> the code via http.
>
> Even more, 1 is more secure than 4, because the Tor protocol is more
> secure than TLS.
>
> It's already a reality that projects are using something like 1 and will
> continue to build systems on the same principles (one can't argue that
> such systems are unsecure or unlikely to happen, that's not true, see
> the Flashproxy project too).
>
> But 1 fails too, because ws is not allowed inside a https page, so we
> must use 2, which is insecure and 2 might not work any longer later.
>
> Service Workers are doing about the same, https must be used, as far as
> I understand Service Workers can run any browser instance in background
> even if the spec seems to focus more on the offline aspects, so I
> suppose that having 1 inside a (background) Service Worker will fail too.
>
> Now we have the "new" "progressive Web Apps" which surprisingly present
> as a revolution the possibility to have a web app look like a native app
> while it can be done on iOS since the begining, same thing for some
> offline caching features that were possible before, but this indeed
> brings new things, hopefully we can have one day something like all the
> cordova features inside browsers + background/headless browser instances.
>
> So we are talking about web apps here, not about a web page loading
> plenty of http/https stuff, web apps that can be used as
> independant/native apps or nodes to relay traffic and therefore discuss
> with some entities that can't be tied to a domain and can only use
> self-signed certificates (like WebRTC peers, why do we have a security
> exception here allowing something for WebRTC and not for this case?).
>
> Then 1 must be possible with WS and Service Workers, because there are
> no reasons why it should not be allowed and this will happen in the
> future under different forms (see the link below), that's not illogical,
> if you use wss then you expect it to work as such (ie fail with
> self-signed certificates for example), if you use ws (what terrible
> things can happen with ws exactly? ws can't access the DOM or whatever)
> then you are on your own and should better know what you are doing,
> that's not a reason to force you to use much more insecure 2.
>
> Such apps can be loaded while navigating on a web site, entirely (ie the
> web site is the app), or for more wide distribution from different sites
> than the original app site via an iframe (very ugly way) or extracted as
> a component (cool way, does not seem to be foreseen by anybody) with
> user prompt/validation ("do you want to install application X?")
> possibly running in background when needed in a sandboxed context with
> service workers.
>
> Le 25/11/2015 17:43, Aymeric Vitte a écrit :
> >
> >
> > Le 20/11/2015 12:35, Richard Barnes a écrit :
> >> On Thu, Nov 19, 2015 at 8:40 AM, Hanno Böck  wrote:
> >>
>  It's amazing how the same wrong arguments get repeated again and
>  again...
> 
> >> +1000
> >>
> >> All of these points have been raised and rebutted several times.  My
> >> favorite reference is:
> >>
> >>
> 

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

[Crispin Cowan]

“Secure against which threats?” is the question. TLS, with its stronger crypto, 
is more secure against an adversary that wants to read the content of your 
messages. ToR is more secure against an adversary that wants to detect that you 
visit a particular site, are associated with particular social media content, 
and get your real IP address to hunt you down. They are dramatically different 
adversaries, and different victim profiles, so comparing which is “more secure” 
is meaningless.

From: Brad Hill [mailto:hillb...@gmail.com]
Sent: Monday, November 30, 2015 12:01 PM
To: Aymeric Vitte ; Web Applications Working Group WG 
(public-webapps@w3.org) 
Cc: public-webapp...@w3.org
Subject: Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just 
fine]

I don't think there is universal agreement among browser engineers (if anyone 
agrees at all) with your assertion that the Tor protocol or even Tor hidden 
services are "more secure than TLS".  TLS in modern browsers requires RSA 
2048-bit or equivalent authentication, 128-bit symmetric key confidentiality 
and SHA-256 or better integrity.If .onion identifiers and the Tor protocol 
crypto were at this level of strength, it would be reasonable to argue that a 
.onion connection represented a "secure context", and proceed from there.  In 
the meantime, with .onion site security (without TLS) at 80-bits of truncation 
of a SHA-1 hash of a 1024 bit key, I don't think you'll get much traction in 
insisting it is equivalent to or better than TLS.

On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte 
> wrote:
Redirecting this to WebApps since it's probable that we are facing a
design mistake that might amplify by deprecating non TLS connections. I
have submitted the case to all possible lists in the past, never got a
clear answer and was each time redirected to another list (ccing
webappsec but as a whole I think that's a webapp matter, so please don't
state only that "downgrading a secure connection to an insecure one is
insecure").

The case described below is simple:

1- https page loading the code, the code establishes ws + the Tor
protocol to "someone" (who can be a MITM or whatever, we don't care as
explained below)

2- http page loading the code, the code establishes ws + the Tor protocol

3- https page loading the code, the code establishes wss + the Tor protocol

4- https page loading the code, the code establishes normal wss connections

3 fails because the WS servers have self-signed certificates.

What is insecure between 1 and 2? Obviously this is 2, because loading
the code via http.

Even more, 1 is more secure than 4, because the Tor protocol is more
secure than TLS.

It's already a reality that projects are using something like 1 and will
continue to build systems on the same principles (one can't argue that
such systems are unsecure or unlikely to happen, that's not true, see
the Flashproxy project too).

But 1 fails too, because ws is not allowed inside a https page, so we
must use 2, which is insecure and 2 might not work any longer later.

Service Workers are doing about the same, https must be used, as far as
I understand Service Workers can run any browser instance in background
even if the spec seems to focus more on the offline aspects, so I
suppose that having 1 inside a (background) Service Worker will fail too.

Now we have the "new" "progressive Web Apps" which surprisingly present
as a revolution the possibility to have a web app look like a native app
while it can be done on iOS since the begining, same thing for some
offline caching features that were possible before, but this indeed
brings new things, hopefully we can have one day something like all the
cordova features inside browsers + background/headless browser instances.

So we are talking about web apps here, not about a web page loading
plenty of http/https stuff, web apps that can be used as
independant/native apps or nodes to relay traffic and therefore discuss
with some entities that can't be tied to a domain and can only use
self-signed certificates (like WebRTC peers, why do we have a security
exception here allowing something for WebRTC and not for this case?).

Then 1 must be possible with WS and Service Workers, because there are
no reasons why it should not be allowed and this will happen in the
future under different forms (see the link below), that's not illogical,
if you use wss then you expect it to work as such (ie fail with
self-signed certificates for example), if you use ws (what terrible
things can happen with ws exactly? ws can't access the DOM or whatever)
then you are on your own and should better know what you are doing,
that's not a reason to force you to use much more insecure 2.

Such apps can be loaded while navigating on a web site, entirely (ie the
web site is the app), or for more wide distribution from different sites
than the original 

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

[Richard Barnes]

On Mon, Nov 30, 2015 at 5:52 PM, Aymeric Vitte 
wrote:

> You must be kidding, the logjam attack showed the complete failure of
> TLS


Sure, protocols have bugs, and bugs get fixed.  The things we require for
HTTPS aren't even design goals of Tor.



> and your 1/2/3 (notwithstanding the useless discussions about CAs &
> co), which does not apply to the Tor protocol that you don't know
> apparently but that fulfills 1/2/3
>

I know Tor plenty well.  It's good for what it's designed for (e.g.,
anonymity), but it's not designed to meet the requirements of HTTPS.

You may be interested in this Tor blog post that points out some advantages
of doing HTTPS over Tor:

https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs



> I am not a Tor advocate, this is just an example illustrating why there
> are no reasons to forbid ws with https, and ws with https with service
> workers, and ws with https with future things, do you think that
> browsers will continue to discuss in the future with good old entities
> tied to a good old domain with a good old certificate?
>
> Then what about WebRTC and DTLS self-signed certificates that the web is
> trying to secure by some strange ways?
>

You seem to be missing the fact that WebRTC has additional security layers
on top of the certificates.  The WebRTC connection process requires the
website to specify the key fingerprint of the remote party, so you're
secure against any attacker besides the website.  And if you don't trust
that site, there's an identity layer that can provide additional
authentication.

https://w3c.github.io/webrtc-pc/#sec.identity-proxy

--Richard




>
> Le 30/11/2015 22:45, Richard Barnes a écrit :
> >
> >
> > On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte  > > wrote:
> >
> > Not sure that you know what you are talking about here, maybe
> influenced
> > by fb's onion things, or you misunderstood what I wrote.
> >
> > I am not talking about the Tor network, neither the Hidden services,
> I
> > am talking about the Tor protocol itself, that's different and it is
> > known to be strong, but this is just an example, let's see it as
> another
> > secure protocol to connect browsers to other entities that can not
> have
> > valid certificates for obvious reasons.
> >
> >
> > HTTPS gives you the following essential properties:
> > 1. Authentication: You know that you're talking to who you think you're
> > talking to.
> > 2. Confidentiality: Nobody else can see what you're saying
> > 3. Integrity: Nobody else can interfere with your communications
> >
> > Show me another protocol that achieves those properties, and maybe we'll
> > have something to talk about.  Tor doesn't.
> >
> > --Richard
> >
> >
> > Whatever number of bits are used for RSA/sym crypto/SHA the Tor
> protocol
> > is resistant to the logjam trivial DH_export quasi undetectable
> > downgrade attack that nobody anticipated during years, on purpose or
> > not, I don't know, but that's obvious that the DH client public key
> for
> > TLS could have been protected by the public key of the server, like
> the
> > Tor protocol is doing, so maybe you should refrain your compliments
> > about TLS.
> >
> > And the Tor protocol have TLS on top of it, so below the right
> sequence
> > is ws + TLS + Tor protocol.
> >
> > And it checks that the one you are connected to is the one with whom
> you
> > have established the TLS connection (who can be a MITM again, but you
> > don't care, you just want to be sure with whom you are discussing
> with,
> > like what WebRTC is trying to do)
> >
> > But again, that's not really the subject of the discussion, the
> subject
> > is what is really the problem of letting an interface that has
> access to
> > nothing (WS) work with https? Knowing that you can use it with
> another
> > protocol that you can estimate better, but could be worse, again what
> > does it hurt?
> >
> > Or just deprecate ws because if it has to work only with entities
> that
> > own valid certificates, then it's of quasi no use for the future.
> >
> > Le 30/11/2015 21:00, Brad Hill a écrit :
> > > I don't think there is universal agreement among browser engineers
> (if
> > > anyone agrees at all) with your assertion that the Tor protocol or
> even
> > > Tor hidden services are "more secure than TLS".  TLS in modern
> browsers
> > > requires RSA 2048-bit or equivalent authentication, 128-bit
> symmetric
> > > key confidentiality and SHA-256 or better integrity.If .onion
> > > identifiers and the Tor protocol crypto were at this level of
> strength,
> > > it would be reasonable to argue that a .onion connection
> represented a
> > > "secure context", and proceed from there.  In the meantime, with
> .onion
> > > site security (without TLS) at 80-bits of 

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

[Aymeric Vitte]

What are you talking about?

The logjam attack just shows that you (spec security experts of major
internet companies) are incompetent, or just knew about it.

You don't know Tor "plenty well", I am not referring at all to hidden
services, the fb case, or the ridiculous related case of a https cert
over a .onion

And for WebRTC which "requires the website to specify the key
fingerprint of the remote party, so you're secure against any attacker
besides the website", this is a really funny (not to say completely
stupid) solution involving a "website"
(https://github.com/Ayms/node-Tor#security), which shows again that you
are completely missing my point, a "website" is not the future and web
apps must be able to work without a "website", so with entities that
cannot have valid certificates.

Maybe some projects like letsencrypt should study the case.

Let's stop talking about Tor, please just explain why ws cannot be used
with https.

Le 01/12/2015 00:08, Richard Barnes a écrit :
> On Mon, Nov 30, 2015 at 5:52 PM, Aymeric Vitte  > wrote:
> 
> You must be kidding, the logjam attack showed the complete failure of
> TLS
> 
> 
> Sure, protocols have bugs, and bugs get fixed.  The things we require
> for HTTPS aren't even design goals of Tor.
> 
>  
> 
> and your 1/2/3 (notwithstanding the useless discussions about CAs &
> co), which does not apply to the Tor protocol that you don't know
> apparently but that fulfills 1/2/3
> 
> 
> I know Tor plenty well.  It's good for what it's designed for (e.g.,
> anonymity), but it's not designed to meet the requirements of HTTPS.
> 
> You may be interested in this Tor blog post that points out some
> advantages of doing HTTPS over Tor:
> 
> https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs
> 
>  
> 
> I am not a Tor advocate, this is just an example illustrating why there
> are no reasons to forbid ws with https, and ws with https with service
> workers, and ws with https with future things, do you think that
> browsers will continue to discuss in the future with good old entities
> tied to a good old domain with a good old certificate?
> 
> Then what about WebRTC and DTLS self-signed certificates that the web is
> trying to secure by some strange ways?
> 
> 
> You seem to be missing the fact that WebRTC has additional security
> layers on top of the certificates.  The WebRTC connection process
> requires the website to specify the key fingerprint of the remote party,
> so you're secure against any attacker besides the website.  And if you
> don't trust that site, there's an identity layer that can provide
> additional authentication.
> 
> https://w3c.github.io/webrtc-pc/#sec.identity-proxy
> 
> --Richard
> 
> 
>  
> 
> 
> Le 30/11/2015 22:45, Richard Barnes a écrit :
> >
> >
> > On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte  
> > >>
> wrote:
> >
> > Not sure that you know what you are talking about here, maybe
> influenced
> > by fb's onion things, or you misunderstood what I wrote.
> >
> > I am not talking about the Tor network, neither the Hidden
> services, I
> > am talking about the Tor protocol itself, that's different and
> it is
> > known to be strong, but this is just an example, let's see it
> as another
> > secure protocol to connect browsers to other entities that can
> not have
> > valid certificates for obvious reasons.
> >
> >
> > HTTPS gives you the following essential properties:
> > 1. Authentication: You know that you're talking to who you think
> you're
> > talking to.
> > 2. Confidentiality: Nobody else can see what you're saying
> > 3. Integrity: Nobody else can interfere with your communications
> >
> > Show me another protocol that achieves those properties, and maybe
> we'll
> > have something to talk about.  Tor doesn't.
> >
> > --Richard
> >
> >
> > Whatever number of bits are used for RSA/sym crypto/SHA the
> Tor protocol
> > is resistant to the logjam trivial DH_export quasi undetectable
> > downgrade attack that nobody anticipated during years, on
> purpose or
> > not, I don't know, but that's obvious that the DH client
> public key for
> > TLS could have been protected by the public key of the server,
> like the
> > Tor protocol is doing, so maybe you should refrain your
> compliments
> > about TLS.
> >
> > And the Tor protocol have TLS on top of it, so below the right
> sequence
> > is ws + TLS + Tor protocol.
> >
> > And it checks that the one you are connected to is the one
> with whom you
> > have 

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

[Florian Bösch]

On Mon, Nov 30, 2015 at 10:45 PM, Richard Barnes 
wrote:

> 1. Authentication: You know that you're talking to who you think you're
> talking to.
>

And then Dell installs a their own root authority on machines they ship, or
your CA of choice gets pwn'ed or the NSA uses some undisclosed backdoor in
the EC they managed to smuggle into the constants, or somebody combines a
DNS poison/grab with a non verified (because piss poor CA) double
certificate, or you hit one of the myriad of bugs that've plaqued TLS
implementations (particularly certain large and complex ones that're
basically one big ball of gnud which shall remain unnamed).

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

[Aymeric Vitte]

You must be kidding, the logjam attack showed the complete failure of
TLS and your 1/2/3 (notwithstanding the useless discussions about CAs &
co), which does not apply to the Tor protocol that you don't know
apparently but that fulfills 1/2/3

I am not a Tor advocate, this is just an example illustrating why there
are no reasons to forbid ws with https, and ws with https with service
workers, and ws with https with future things, do you think that
browsers will continue to discuss in the future with good old entities
tied to a good old domain with a good old certificate?

Then what about WebRTC and DTLS self-signed certificates that the web is
trying to secure by some strange ways?

Le 30/11/2015 22:45, Richard Barnes a écrit :
> 
> 
> On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte  > wrote:
> 
> Not sure that you know what you are talking about here, maybe influenced
> by fb's onion things, or you misunderstood what I wrote.
> 
> I am not talking about the Tor network, neither the Hidden services, I
> am talking about the Tor protocol itself, that's different and it is
> known to be strong, but this is just an example, let's see it as another
> secure protocol to connect browsers to other entities that can not have
> valid certificates for obvious reasons.
> 
> 
> HTTPS gives you the following essential properties:
> 1. Authentication: You know that you're talking to who you think you're
> talking to.
> 2. Confidentiality: Nobody else can see what you're saying
> 3. Integrity: Nobody else can interfere with your communications
> 
> Show me another protocol that achieves those properties, and maybe we'll
> have something to talk about.  Tor doesn't.
> 
> --Richard
> 
> 
> Whatever number of bits are used for RSA/sym crypto/SHA the Tor protocol
> is resistant to the logjam trivial DH_export quasi undetectable
> downgrade attack that nobody anticipated during years, on purpose or
> not, I don't know, but that's obvious that the DH client public key for
> TLS could have been protected by the public key of the server, like the
> Tor protocol is doing, so maybe you should refrain your compliments
> about TLS.
> 
> And the Tor protocol have TLS on top of it, so below the right sequence
> is ws + TLS + Tor protocol.
> 
> And it checks that the one you are connected to is the one with whom you
> have established the TLS connection (who can be a MITM again, but you
> don't care, you just want to be sure with whom you are discussing with,
> like what WebRTC is trying to do)
> 
> But again, that's not really the subject of the discussion, the subject
> is what is really the problem of letting an interface that has access to
> nothing (WS) work with https? Knowing that you can use it with another
> protocol that you can estimate better, but could be worse, again what
> does it hurt?
> 
> Or just deprecate ws because if it has to work only with entities that
> own valid certificates, then it's of quasi no use for the future.
> 
> Le 30/11/2015 21:00, Brad Hill a écrit :
> > I don't think there is universal agreement among browser engineers (if
> > anyone agrees at all) with your assertion that the Tor protocol or even
> > Tor hidden services are "more secure than TLS".  TLS in modern browsers
> > requires RSA 2048-bit or equivalent authentication, 128-bit symmetric
> > key confidentiality and SHA-256 or better integrity.If .onion
> > identifiers and the Tor protocol crypto were at this level of strength,
> > it would be reasonable to argue that a .onion connection represented a
> > "secure context", and proceed from there.  In the meantime, with .onion
> > site security (without TLS) at 80-bits of truncation of a SHA-1 hash of
> > a 1024 bit key, I don't think you'll get much traction in insisting it
> > is equivalent to or better than TLS.
> >
> > On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte  
> > >>
> wrote:
> >
> > Redirecting this to WebApps since it's probable that we are
> facing a
> > design mistake that might amplify by deprecating non TLS
> connections. I
> > have submitted the case to all possible lists in the past,
> never got a
> > clear answer and was each time redirected to another list (ccing
> > webappsec but as a whole I think that's a webapp matter, so
> please don't
> > state only that "downgrading a secure connection to an
> insecure one is
> > insecure").
> >
> > The case described below is simple:
> >
> > 1- https page loading the code, the code establishes ws + the Tor
> > protocol to "someone" (who can be a MITM or whatever, we don't
> 

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

[Jim Manico]

How about the many of the Tor endpoints being compromised? Does that 
show a complete failure of Tor? I would say no. 
http://www.ibtimes.co.uk/tor-anonymity-network-compromised-following-potential-raid-by-law-enforcement-agencies-1480620


Most folks who really care about this stuff use Tor and use TLS for all 
services. And perhaps write services with secure code. And keep your 
machines free of malware, etc, etc, etc. Depending on any one of these 
technologies is not so helpful in 2015.


Aloha,
Jim


On 12/1/15 1:08 AM, Richard Barnes wrote:
On Mon, Nov 30, 2015 at 5:52 PM, Aymeric Vitte > wrote:


You must be kidding, the logjam attack showed the complete failure of
TLS


Sure, protocols have bugs, and bugs get fixed.  The things we require 
for HTTPS aren't even design goals of Tor.


and your 1/2/3 (notwithstanding the useless discussions about CAs &
co), which does not apply to the Tor protocol that you don't know
apparently but that fulfills 1/2/3


I know Tor plenty well.  It's good for what it's designed for (e.g., 
anonymity), but it's not designed to meet the requirements of HTTPS.


You may be interested in this Tor blog post that points out some 
advantages of doing HTTPS over Tor:


https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs

I am not a Tor advocate, this is just an example illustrating why
there
are no reasons to forbid ws with https, and ws with https with service
workers, and ws with https with future things, do you think that
browsers will continue to discuss in the future with good old entities
tied to a good old domain with a good old certificate?

Then what about WebRTC and DTLS self-signed certificates that the
web is
trying to secure by some strange ways?


You seem to be missing the fact that WebRTC has additional security 
layers on top of the certificates. The WebRTC connection process 
requires the website to specify the key fingerprint of the remote 
party, so you're secure against any attacker besides the website.  And 
if you don't trust that site, there's an identity layer that can 
provide additional authentication.


https://w3c.github.io/webrtc-pc/#sec.identity-proxy

--Richard



Le 30/11/2015 22:45, Richard Barnes a écrit :
>
>
> On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte

> >>
wrote:
>
> Not sure that you know what you are talking about here,
maybe influenced
> by fb's onion things, or you misunderstood what I wrote.
>
> I am not talking about the Tor network, neither the Hidden
services, I
> am talking about the Tor protocol itself, that's different
and it is
> known to be strong, but this is just an example, let's see
it as another
> secure protocol to connect browsers to other entities that
can not have
> valid certificates for obvious reasons.
>
>
> HTTPS gives you the following essential properties:
> 1. Authentication: You know that you're talking to who you think
you're
> talking to.
> 2. Confidentiality: Nobody else can see what you're saying
> 3. Integrity: Nobody else can interfere with your communications
>
> Show me another protocol that achieves those properties, and
maybe we'll
> have something to talk about.  Tor doesn't.
>
> --Richard
>
>
> Whatever number of bits are used for RSA/sym crypto/SHA the
Tor protocol
> is resistant to the logjam trivial DH_export quasi undetectable
> downgrade attack that nobody anticipated during years, on
purpose or
> not, I don't know, but that's obvious that the DH client
public key for
> TLS could have been protected by the public key of the
server, like the
> Tor protocol is doing, so maybe you should refrain your
compliments
> about TLS.
>
> And the Tor protocol have TLS on top of it, so below the
right sequence
> is ws + TLS + Tor protocol.
>
> And it checks that the one you are connected to is the one
with whom you
> have established the TLS connection (who can be a MITM
again, but you
> don't care, you just want to be sure with whom you are
discussing with,
> like what WebRTC is trying to do)
>
> But again, that's not really the subject of the discussion,
the subject
> is what is really the problem of letting an interface that
has access to
> nothing (WS) work with https? Knowing that you can use it
with another
> protocol that you can estimate better, but could be worse,
again what
> does it hurt?
>
> Or just deprecate ws because if it has to work only with

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

[Brad Hill]

Let's keep this discussion civil, please.

The reasons behind blocking of non-secure WebSocket connections from secure
contexts are laid out in the following document:

http://www.w3.org/TR/mixed-content/

A plaintext ws:// connection does not meet the requirements of
authentication, encryption and integrity, so far as the user agent is able
to tell, so it cannot allow it.

If there is a plausible mechanism by which browsers could distinguish
external communications which meet the necessary security criteria using
protocols other than TLS or authentication other than from the Web PKI,
there is a reasonable case to be made that such could be considered as
potentially secure origins and URLs.  (as has been done to some extent for
WebRTC, as you have already noted)

If you want to continue this discussion here, please:

1) State your use cases clearly for those on this list who do not already
know them.  You want to "use the Tor protocol" over websockets?  To connect
to what?  Why?  Why is it important to bootstrap an application like this
over regular http(s) instead of, for example, as an extension or modified
user-agent like TBB?

2) Describe clearly why and how the protocol you propose to use meets the
necessary guarantees a user expects from an https page.

3) Describe clearly how the user agent can determine, before any
degradation in the security state of the context is possible, that only a
protocol meeting these requirements will be used.

Ad-hominem and security nihilism of the forms "TLS / PKI is worthless so
why bother trying to enforce any security guarantees" or "other insecure
configurations like starting with http are allowed, so why not allow this
insecure configuration, too" are not appropriate or a good use of anyone's
time on this list.  Please refrain from continuing down these paths.

thank you,

Brad Hill, as co-chair

On Mon, Nov 30, 2015 at 6:25 PM Florian Bösch  wrote:

> On Mon, Nov 30, 2015 at 10:45 PM, Richard Barnes 
> wrote:
>
>> 1. Authentication: You know that you're talking to who you think you're
>> talking to.
>>
>
> And then Dell installs a their own root authority on machines they ship,
> or your CA of choice gets pwn'ed or the NSA uses some undisclosed backdoor
> in the EC they managed to smuggle into the constants, or somebody combines
> a DNS poison/grab with a non verified (because piss poor CA) double
> certificate, or you hit one of the myriad of bugs that've plaqued TLS
> implementations (particularly certain large and complex ones that're
> basically one big ball of gnud which shall remain unnamed).
>