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

2015-12-02 Thread 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

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

2015-12-02 Thread 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 >

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

2015-12-02 Thread 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

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

2015-12-02 Thread 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

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

2015-12-02 Thread 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 >

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

2015-12-02 Thread 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

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

2015-12-02 Thread 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

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

2015-12-01 Thread 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

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

2015-12-01 Thread 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

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

2015-11-30 Thread 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

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

2015-11-30 Thread 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

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

2015-11-30 Thread 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

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

2015-11-30 Thread 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

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

2015-11-30 Thread 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

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

2015-11-30 Thread 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

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

2015-11-30 Thread 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

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

2015-11-30 Thread 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

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

2015-11-30 Thread 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

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

2015-11-30 Thread 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

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

2015-11-30 Thread 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