W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Moving forward on improving HTTP's security

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Thu, 14 Nov 2013 11:46:38 -0600
Message-ID: <CACuKZqFoqrQY8kxawi6oe_j4QN0rcR9+7ivKsAQQBLnSNamGUw@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Roberto Peon <grmocg@gmail.com>, Frédéric Kayser <f.kayser@free.fr>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Nov 14, 2013 at 11:34 AM, Patrick McManus <pmcmanus@mozilla.com> wrote:
> On Thu, Nov 14, 2013 at 12:13 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:
>> If that's the case, WebSocket is also "undeployable" since it tunnels
>> though port 80 as well.
> that's right. The failure rate of cleartext websockets is much higher than
> SSL wss:// websockets. (the failure rate is almost twice as large in
> firefox). That's a significant part of the driver here. Websockets made a
> mistake by even specifying cleartext. I was there and I've learned that
> lesson.

Would it have been a bigger mistake if WebSocket only works on secure
channel? Would that encourage or discourage the deployment of
WebSocket? I think it would definitely have been a deterrent.

In the current scheme, the service provide can try ws:// first. It
might work very satisfactorily (e.g. if most users connect from home
computers). If it does not, the service provider can upgrade to wss://
without too much hassle.

> cleartext just doesn't work as, roberto keeps saying.

Aren't websocket frames masked with random bits?

> The only question in my mind is whether or not to require a real
> PKI-as-we-know-it authenticated cert. That has tradeoffs - but at least we
> expect it would operate.
Received on Thursday, 14 November 2013 17:47:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC