Re: Moving forward on improving HTTP's security

On Thu, Nov 14, 2013 at 12:02 PM, Roberto Peon <grmocg@gmail.com> wrote:
> Yes, it basically is not reliably deployable over port 80. Websocket-secure
> is deployable. At the last conference of web developers that I attended, it
> was highly recommended that WS: not be used and instead to use WSS:.

Agreed. However it didn't need a decree from above. People can
converge to WSS based on profit, not based on law.

If WebSocket was mandated to be on HTTPS channel only, it would have
seen a lot less enthusiasm and implementations.

Even if you think WS is totally useless, what is the harm that it can
possibly cause by including it? What's the drive to forbid it?

>
> -=R
>
> On Nov 14, 2013 7:13 AM, "Zhong Yu" <zhong.j.yu@gmail.com> wrote:
>>
>> On Wed, Nov 13, 2013 at 9:24 PM, Roberto Peon <grmocg@gmail.com> wrote:
>> > As far as I've seen, most small businesses get little enough traffic
>> > that
>> > they wouldn't notice any difference w.r.t CPU usage.
>> > .. and if it bothers them, they'd use HTTP/1.1 for web stuff, or are
>> > already
>> > doing so.
>> >
>> > In any case, it is extremely likely that HTTP/2.0 on port 80 is nearly
>> > undeployable for the web today. There are too many MITM proxies out
>> > there
>> > that expect port 80 to carry only a subset of HTTP/1.1, and make a mess
>> > of
>> > anything else.
>>
>> If that's the case, WebSocket is also "undeployable" since it tunnels
>> though port 80 as well.
>>
>>
>> >
>> > So, any web deployment of HTTP/2 that is going to be reliable WILL use
>> > encryption, and WILL incur the cost of encryption.
>> >
>> > .. as such, the only real question here is simply about authentication.
>> >
>> > I do expect that we'll see HTTP/2.0 in the clear, but that would be
>> > inside
>> > of a VPN or other private network, and Mark's original email was talking
>> > about the web usecase.
>> >
>> > -=R
>> >
>> >
>> > On Wed, Nov 13, 2013 at 7:01 PM, Frédéric Kayser <f.kayser@free.fr>
>> > wrote:
>> >>
>> >> This also means HTTP/2 is not for everyone, it's only for big business,
>> >> and you cannot get the speed benefit without some hardware investments.
>> >> It also means that speed consciousness webdesigners will still have to
>> >> continue using the awful CSS sprites trick when their target server is
>> >> still
>> >> HTTP/1.1 based.
>> >> HTTP/2 sounded like a magical speed promise… that would be quickly
>> >> adopted, but now it just looks like an alternative solely made for the
>> >> big
>> >> guys.
>> >>
>> >> Roberto Peon wrote:
>> >>
>> >> > The radio far dominates battery life considerations w.r.t IO on
>> >> > mobile
>> >> > devices, so if we were super worried about that, we'd be working on
>> >> > getting
>> >> > the best possible compression algorithm for entity-bodies.
>> >> >
>> >> > I note that with Mark's proposed 'C':
>> >> > Encryption is not mandatory- one simply uses HTTP/1.1 if one don't
>> >> > want
>> >> > encryption. Noone is thus forced to do anything: they're not forced
>> >> > to spend
>> >> > more CPU, etc., unless they believe the benefit outweighs the cost.
>> >> >
>> >> > Honestly, this is where we are anyway. We don't have the power, even
>> >> > if
>> >> > we wished it, to throw away HTTP/1.X and so we'll always be competing
>> >> > against its cost/benefit.
>> >> >
>> >> > I'm pretty happy with either 'C' or any other proposal that provides
>> >> > strong downgrade protection.
>> >> >
>> >> > -=R
>> >>
>> >>
>> >

Received on Thursday, 14 November 2013 18:12:37 UTC