Re: Moving forward on improving HTTP's security

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

-=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
> >>
> >>
> >
>