
Hypertext Transfer Protocol Version 2 - yoavz
http://tools.ietf.org/html/draft-ietf-httpbis-http2-14
======
diafygi
There is so much open wifi nowadays that non-https should really start to be
considered harmful. A large portion of website visitors are probably
connecting via Starbucks, airport wifi, etc., which means their session
cookies are basically public information.

So even given the mass surveillance problems, non-https connections need to
start being treated as Bad Practice and discouraged by the sysadmin community.

~~~
peterwwillis
Devil's Advocate: there is no world wide cabal of wifi hackers trying to steal
the Facebook login cookies of starbucks customers. The lack of security is
real, but the dangers are overblown.

~~~
hackuser
> Devil's Advocate: there is no world wide cabal of wifi hackers trying to
> steal the Facebook login cookies of starbucks customers. The lack of
> security is real, but the dangers are overblown.

Perhaps not, but consider for example that the Starbucks near people with
valuable IP (e.g., many Starbucks in Silicon Valley, in NYC, in Washington DC,
in Redmond WA, in Cambridge MA, in Beverly Hills, in the Hamptons, etc.) would
be valuable targets.

~~~
peterwwillis
A valuable target will always get hacked because they'll be specifically
targeted. For most of them it'll be from spearphishing, but there's a
multitude of ways to attack people even if https is the default. All well
known celebrity hacks are done either by spearphishing or breaking into an
account independent of contact with the person.

And in general it's probably not a good idea to set world-wide standards on
the most used high level protocol in the world based on a few rich people who
use the net from an unsecure device.

~~~
hackuser
> A valuable target will always get hacked because they'll be specifically
> targeted. For most of them it'll be from spearphishing, but there's a
> multitude of ways to attack people even if https is the default.

Yes there are other vulnerabilities, but that's not a reason to fail protect
against this one (taking that reasoning to an extreme, all security is
pointless because there always are other vulnerabilities). The purpose of
security is to increase the cost of a successful attack; https has a high ROI
in many cases. In the example you give, spear-phishing is much more expensive
than sniffing wifi.

------
wmf
For context, this is the really-almost-final draft of HTTP/2\. I would say
speak now or forever hold your peace, but it's even too late for that.

------
stonogo
The best description of this protocol I have seen is "TCP over TCP."

~~~
johnrob
I wonder if most of the mileage here could be gained by simply augmenting
javascript's networking capabilities, enabling the use of non-HTTP servers
(and keeping the HTTP protocol simple).

~~~
stonogo
I'm amused and depressed that the industry is willing to consider almost any
solution -- except using something other than a web browser for tasks that do
not involve browsing the web. Seriously... it works for Spotify, even now.

~~~
api
The world is full of clueless firewall administrators who block everything but
port 80 and 443 because security. It inconveniences users a lot more than
attackers, but if you try explaining this you get a bunch of cargo cultism
about reducing attack surface area, etc.

Never mind that these protocols now tunnel everything and thus have equivalent
attack surface area to just opening your network. I call it cargo cultism
because these people superficially know security buzz-concepts but do not
understand them deeply. The application of security concepts in this
superficial way does tremendous harm, not to mention creating a false sense of
security among the cargo cultists and their followers.

So we engage in an arms race with ourselves. We block everything, then design
protocols to tunnel through our firewalls to reenable all the things we
blocked, then repeat.

SSH is another penultimate tcp over tcp protocol.

The only real solution to the security problems these hacks fix is to fix
operating system app and privilege isolation. But that's more work so let's
just break IP with firewalls and then pretend it secures us.

~~~
xorcist
The firewalls are going to get very expensive once everything runs on port 80.

Unhappy users are sometimes the only way to get policies to change.

------
bkeroack
So TLS still isn't mandatory? Seems like a missed opportunity.

~~~
AlyssaRowan
That's something the browsers are going to deal with. Chrome and Firefox have
explicitly said they'll require HTTP/2 over TLS, full-stop.

The big pushbacks came mostly from middlebox-makers, proxies and the like.
Unsurprising.

The market will decide. I'm sure the remaining browsers will make their own
decisions, and I expect Opera and IE to fall on the TLS side, and then the
decision will be effectively made.

The TLS WG will watch the result with interest, I'm sure, looking forward into
TLS 1.4/2.0/whatever...

~~~
M2Ys4U
IIRC, Microsoft has already stated that IE will support unencrypted HTTP/2.

~~~
AlyssaRowan
That's "under review"...

------
0x0
I'm curious to see how transparent proxies handle all the crazy framing (will
poor software corrupt the bytestream?) and if there will be a wave of exploits
for both client and server implementations; the complexity and subtleties
appear to be almost a magnitude higher than http/1.

~~~
lazyloop
That's simple, they just won't, browsers will only support HTTP/2 over TLS, so
proxies are effectively dead.

~~~
xorcist
Every large web site uses a load balancer, effectively a proxy. I don't
understand why Poul Henning-Kamp's experience with that didn't carry more
weight in the working group.

~~~
wmf
In HTTP terms a reverse proxy is just a Web server (what it does internally is
its own business), not a proxy. HTTP/2 load balancers have no trouble
terminating TLS.

~~~
xorcist
If you disagree with PHK, you have to refute the details in his notes, not
just wave them away. That they can be made to work does not mean there is not
a problem.

~~~
wmf
PHK keeps calling for radical changes to HTTP semantics which other people
don't have the stomach for and would take a decade to deploy even if they did.
In some sense, getting HTTP/2 done quickly clears the field for people like
PHK to start on HTTP/3 sooner.

~~~
xorcist
Not entirely true. PHK outlines some specific issues with HTTP/2 that makes a
load balancer's job harder and/or less performant.

------
ChikkaChiChi
Is there any particular reason why more work isn't being done on developing
new protocols?

It seems like given the past 20 years of the web there is clearly a need of a
presentation protocol, a stateful application protocol, and a stateless
application protocol.

Seems like it makes more sense to separate them.

~~~
michaelsbradley
OPC UA is a relatively new standard worth a look for those in the market for a
stateful application protocol that provides both an information model and
transport layer. One downside is that, presently, only member organizations of
the OPC Foundation are given full access to the specifications and reference
implementations. Membership is certainly affordable, but interest and adoption
might be accelerated if the specs and reference clients/servers were publicly
accessible. Perhaps if the Foundation received enough enthusiastic inquiries
they might change their policy in that regard.

[http://en.wikipedia.org/wiki/OPC_Unified_Architecture](http://en.wikipedia.org/wiki/OPC_Unified_Architecture)

[https://opcfoundation.org/about/opc-technologies/opc-
ua/](https://opcfoundation.org/about/opc-technologies/opc-ua/)

------
nly
The accompanying HTTP header compression standard seems a lot more terrifying
on the complexity scale, compared to Googles suggestion with SPDY of just
dumping everything through zlib:

[http://tools.ietf.org/html/draft-ietf-httpbis-header-
compres...](http://tools.ietf.org/html/draft-ietf-httpbis-header-
compression-09)

~~~
agl
But dumping everything through zlib turned out to be a security hole:
[http://en.wikipedia.org/wiki/CRIME](http://en.wikipedia.org/wiki/CRIME).

I wrote some terrible, terrible code for Chromium to patch zlib in order to
segment different sources of data and compress them separately while still
being wire compatible with zlib. I'll be very happy when I can remove it.

~~~
bsdetector
Just like it turned out that minimized HTTP was faster than SPDY:
[http://research.microsoft.com/apps/pubs/?id=170059](http://research.microsoft.com/apps/pubs/?id=170059)

I'm not sure what the motivation is behind HTTP2/SPDY. There have been
consistent misinformation from Google about the performance of it (for
instance including initial connection time for HTTP but omitting it for SPDY,
using an outdated HTTP stack, not using HTTP pipelining) so I doubt the
motivation is performance.

It looks like just not-invented-here bloat, but I wouldn't be surprised to
find out that the SPDY connection to google-analytics.com is kept open and
reused across tabs.

~~~
rakoo
> It looks like just not-invented-here bloat

To me, the real advantage are:

\- native multiplexing on a single TCP socket. No more connection pools, no
more domain sharding...

\- the server is now able to send data at arbitrary moments.

Here's a concrete example: how would you do a webchat ? You need bidirectional
communication, potentially initiated by any party. Easy solution: use
websockets.

With SPDY/HTTP2, you can use POSTs for sending messages and Server-sent events
for receiving messages. You don't need to pool them, you don't need something-
over-HTTP like websockets is; you just use standard HTTP semantics.

~~~
bsdetector
I actually agree with you for the most part. Google wants with HTTP2/SPDY to
foster an internet based on highly stateful applications, the web as a remote
GUI to their servers, rather than mostly stateless documents as it has been. I
don't see this as an improvement.

------
wyager
To those saying HTTP2 should require HTTPS: do you really want to be stuck
with our shitty CA model for even longer?

~~~
diafygi
Alternative? Non-https is really harmful to users who browse via open wifi.

~~~
stephenr
_can be_ really harmful, in some applications

I don't need to know that my connection to lol cats is secure and
uninterrupted.

~~~
harshreality
Let's assume a simple video site and html5 video.

Do you want to bet there are no vulnerabilities in your browser's mp4/vp8
decoder? If there are, anyone can MITM your non-SSL connection and compromise
the video decoding process, limited only by their cleverness and by whatever
sandboxing your browser employs.

~~~
stephenr
Why does it have to be video?

Some of the simplest sites around are plain text or text and images. Why do I
need SSL or TLS to view either of these?

I am very aware that anything authenticated should be carried over an
encrypted connection - I'm not arguing against that. I'm saying there are use-
cases that do not require it.

~~~
AlyssaRowan
Because otherwise nation-state adversaries can see everything you read.

IETF position on this is pretty clear after the technical plenary last year.

~~~
stephenr
Again, why does it matter if you or Barack Obama or Kimg Jung Un knows that I
like looking at Captain Picard meme pictures? How can you tell me that
REQUIRES an encrypted connection?

You know what might actually make some fucking sense. Enforce SSL/TLS where it
is needed - disable HTTP Auth, Cookies, Location Services, Local Storage, etc
over plain HTTP connections.

------
BorisMelnik
Anyone have a link to a overview type blog post of the changes? This is a tad
foreign for a guy like me who has little experience of this layer of the OSI
model.

~~~
wmf
[http://queue.acm.org/detail.cfm?id=2555617](http://queue.acm.org/detail.cfm?id=2555617)

[https://www.mnot.net/blog/2014/01/30/http2_expectations](https://www.mnot.net/blog/2014/01/30/http2_expectations)

[https://www.mnot.net/talks/http2-wtf/#/](https://www.mnot.net/talks/http2-wtf/#/)

~~~
BorisMelnik
very cool, thank you wmf that first one did the trick! I really can't beleive
how hacked together / behind the original specification is compared to 2.

------
ksec
So what exactly is from HTTP2 to SPDY except for the TLS encryption?

------
kevinpaladin
"Expires: January 31, 2015" \- What does it mean?

~~~
wmf
All Internet-drafts "expire" because they're intended to be work-in-progress
documents that should either be updated to a new draft, finalized into an RFC,
or abandoned. In this case, HTTP/2 will become an RFC long before January.

