
Architecting Websites for the HTTP/2 Era - joeyespo
https://ma.ttias.be/architecting-websites-http2-era/
======
billyhoffman
> HTTP/2 actively discourages the use of compression for secure websites. HTTP
> compression (gzip, deflate, ...) has been known to compromise the SSL/TLS
> security in the "breach" and "CRIME" attacks.

This is a patently wrong statement in an otherwise good article.

There are no known security vulnerabilities with HTTP/1.x's style of
compression That's because HTTP/1.x only supports compressing response bodies.
During SPDY development, the same compression algorithms used for compressing
HTTP responses (gzip/deflate) were applied to compress request and response
headers. This is what lead to the CRIME vulnerability. The solution was to
still use compression, but use a different compression scheme, HPACK, which
(glossing over a ton of technical details) allows compression while avoid
CRIME because it "[uses] separate compression dictionaries are used for each
source of data." HTTP/2 uses HPACK.

Use of TLS compression is not recommended, but that has always been a
performance best practice, since TLS compression is not context aware.

For the love of god, keep using compression with your websites, whether
HTTP/1.x, TLS + HTTP/1.x, or HTTP/2

~~~
agwa
> There are no known security vulnerabilities with HTTP/1.x's style of
> compression That's because HTTP/1.x only supports compressing response
> bodies

You are completely wrong. The BREACH attack showed that you can be vulnerable
to a compression oracle by merely compressing response bodies:
[http://breachattack.com/](http://breachattack.com/)

> For the love of god, keep using compression with your websites, whether
> HTTP/1.x, TLS + HTTP/1.x, or HTTP/2

You can continue compressing files such as CSS that don't reflect any
attacker-controlled content, but compression of dynamic HTML pages is likely
to be insecure.

~~~
richardwhiuk
It's quite depressing that we can't have both compression and encryption at
the same time - text is very compressible - particularly HTML markup...

~~~
cesarb
Theoretically, you can, as long as any secrets within the response body are
represented as a "literal" (that is, uncompressed) within the compressed
stream.

In practice, there isn't a way I know of to mark the relevant parts of the
response body so that the compression, which is usually done as a separate
post-processing step, will know to avoid compressing these parts of the
stream. And it would be very fragile; forgetting to mark a secret as "do not
compress this" would work perfectly fine but reintroduce the vulnerability.

~~~
derefr
Simply enough in HTTP2: lift out the relevant parts of the response body—turn
them into separate resources and refer to them in the original object by their
URL. When the client then requests those dependent objects, deliver them
uncompressed. (And server-hint/push the dependent objects if you can, of
course.)

------
strommen
> Protocol Relative URLS are now considered an anti-pattern

Sorry to sidetrack, but what's wrong with protocol-relative URLs? The only
info I've found is a quote from Paul Irish relating it vaguely to the
China/Github DDOS incident...

I find protocol-relative URLs very helpful for running without HTTPS in my
local environment.

~~~
Mojah
The "problem" with protocol-relative URLs, is that it's possible to include
HTTP content if the parent was HTTP.

Since HTTPs is preferred for both security and privacy, we should give as
little options as possible to use the insecure HTTP protocol and force HTTPs
everywhere.

As you mention though, in dev-environments it's a convenient hack to use plain
old HTTP. However, in production, preferring HTTPs would be considered the way
to go.

------
yc1010
Hehe the "adblock detected" popup on this page is witty

~~~
Mojah
It generates mixed feelings, some appreciate it, others think I'm a complete
ass for asking. :-)

~~~
derefr
I would suggest only asking the _second_ time people land on your site. The
first time, they're probably not going to do it, because they just came in via
some article link and are thinking they probably won't see your site again.

------
nickysielicki
One thought I had while reading though this is that HTTP2 really isn't just a
hypertext transfer protocol anymore, it's going to be used for everything.

~~~
dragonwriter
> One thought I had while reading though this is that HTTP2 really isn't just
> a hypertext transfer protocol anymore, it's going to be used for everything.

That's not any different from HTTP/1.1.

