4 ms·

> Secure by default > SPDY Choose one, SPDY mandates gzip, and gzip in SSL/TLS is vulnerable to leaking repeated plaintext, eg cookies in nearly every implemen

by richo 13y ago

> Secure by default > SPDY Choose one, SPDY mandates gzip, and gzip in SSL/TLS is vulnerable to leaking repeated plaintext, eg cookies in nearly every implementation. http://en.wikipedia.org/wiki/CRIME_(security_exploit) http://en.wikipedia.org/wiki/CRIME_(security_exploit)

osth 13y ago
I choose HTTP/1.1 pipelining. Uncompressed headers are useful. Ordered records are returned (unlike SPDY), where "HTTP/1.1 200 OK" is the record separator. Been using this for a decade. Can't see the benefit of SPDY. Anyway pipelining is only useful where numerous resources are coming from the same host. But the way the www has evolved, so much (unneeded) crap gets served from ad servers and CDN's. Pipelining isn't going to speed that up. HTTP/1.1 pipelining was never broken. It was usually just turned off (e.g. in Firefox), while most web servers have their max keep alive set around 100. In plain English, what does that mean? It means "Dear User, You have permission to download 100 files at a time from http://stupidwebsite.com http://stupidwebsite.com. That is you can make one request for 100 files, instead of 100 separate requests, each for a single file." And what do Firefox and other braindead web browsers do? They make a separate request for each file. But heay, never mind all those numerous connections to ad servers to retrieve marketing garbage (i.e. not the content you are after), lets concentrate on compressing HTTP headers instead. Brilliant. It's trivial to use pipelining: 1. Feed your HTTP requests through netcat or some equivalent to retrieve the files and save them to a concatenated file, 2. split the concatenated file into separate files if desired, 3. view in your favorite browser. No ad server BS. Now that's "SPEEDY".
- dcsommer 13y ago
  Pipelining falls short of SPDY in several respects. The biggest problem is that it suffers from head of line blocking. One slow request or response prevents others from making progress.
  - osth 13y ago
    I trust in theory this is true, but I've never personally observed this in practice. I guess SPDY fans' marketing of this "feature" would be more convincing if I could see a demonstration. I just don't see any noticeable delays when using pipelining. What strikes me as peculiar about the interest in SPDY is that I never saw any interest in pipelining before SPDY. And I really doubt it was because of potential head of line blocking or lack of header compression. I think users just were not clued in about pipelining. The speed up between not using pipelining and using it is, IME, enormous. 1 connection for 100 files versus 100 connections for 100 files. It is a huge efficiency gain. Yet most users have never even heard of HTTP pipelining, or never tried it. If they really wanted such a big speed up, why wouldn't they use pipelining, or at least try it? Why wouldn't they demand that browsers implement it and turn it on by default? Users are being encouraged to jump right into SPDY, a very recent and relatively untested internal project (e.g. see the CRIME incident) of one company, most users, if not all, having never previously experimented with even basic pipelining, which has been around since the 1999 HTTP/1.1 spec and has support via keep alives in almost all web servers. Noticeable speed gains would be seen if www pages were not so burdened with links to resources on external hosts. That's what's really slowing things down, as browsers make dozens of connections just to load a single page with little content. The speed gains from cutting out all that third party host cruft would make any speed gains from avoiding theoretical potential head of line blocking during pipelining seem miniscule and hardly worth all the effort. If you want to see how much pipelining speeds up getting many files from the same host, you do not need SPDY to do that. Web servers already have the support you need to do HTTP/1.1 pipelining. (Though on rare occasions site admins have keep-alives disabled, like HN for example. In effect these admins are saying, "Sorry, no pipelining for you.")
    - akalin 13y ago
      HTTP pipelining is turned off by default in most browsers due to concerns with buggy proxies and servers (see https://bugzilla.mozilla.org/show_bug.cgi?id=264354 https://bugzilla.mozilla.org/show_bug.cgi?id=264354 ). It may work for you and the particular set of servers you visit, but I suspect browser developers would rather have a browser that by default works with the widest possible range of configurations. Unfortunately, it being turned off by default in most browsers means that most people won't see the benefits from it. Hopefully, the upcoming HTTP/2 standard will fare better (latest draft: https://tools.ietf.org/html/draft-unicorn-httpbis-http2-01 https://tools.ietf.org/html/draft-unicorn-httpbis-http2-01 ). Note that HTTP/2 will be based on SPDY (in particular, SPDY/4 with the new header compressor). Hopefully, when the standard is finalized and we have multiple strong implementations, that will allay the concerns you seem to have with SPDY today. (Disclaimer: I work on SPDY / HTTP/2 for Chromium.)
dcsommer 13y ago
SPDY isn't necessarily insecure. Disabling header compression, for instance, works around the CRIME vulnerability.
- richo 13y ago
  Yeah, and if that didn't directly contravene SPDY's specification it'd be a great option: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3#TOC-2.6.10.1-Compression http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...
  - dcsommer 13y ago
    You can use a compression level of 0. That is, pass through.
    - richo 13y ago
      You can, but then you've got to write this enormous block comment saying "I realise this looks wrong and broken, but ssl is also broken so don't change this constant", until some junior dev inevitably does anyway. Having known vulnerabilities baked into a standard with "weird looking" mitigation strategies is really poor choice IMO. That said, I do see your point. There are also other edgecases, like serving statics on a seperate, uncookied domain that benefit greatly from SPDY in the here and now.
  - akalin 13y ago
    Disabling gzip compression isn't the only workaround to the CRIME attack. For Chromium, Adam Langley patched zlib to differentiate between various classes of data; see https://code.google.com/p/chromium/issues/detail?id=139744#c12 https://code.google.com/p/chromium/issues/detail?id=139744#c... and https://chromiumcodereview.appspot.com/10837057/ https://chromiumcodereview.appspot.com/10837057/ . However, it's more difficult for other SPDY implementations to use the patched zlib, so this isn't an ideal solution. For SPDY/4 / HTTP/2, we will have a custom header compressor which is intended to eliminate CRIME-like attacks: https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-00 https://tools.ietf.org/html/draft-ietf-httpbis-header-compre... . (Disclaimer: I work on SPDY / HTTP/2 for Chromium.)

by richo 13y ago

osth 13y ago

I choose HTTP/1.1 pipelining. Uncompressed headers are useful. Ordered records are returned (unlike SPDY), where "HTTP/1.1 200 OK" is the record separator. Been using this for a decade. Can't see the benefit of SPDY. Anyway pipelining is only useful where numerous resources are coming from the same host. But the way the www has evolved, so much (unneeded) crap gets served from ad servers and CDN's. Pipelining isn't going to speed that up. HTTP/1.1 pipelining was never broken. It was usually just turned off (e.g. in Firefox), while most web servers have their max keep alive set around 100. In plain English, what does that mean? It means "Dear User, You have permission to download 100 files at a time from http://stupidwebsite.com http://stupidwebsite.com. That is you can make one request for 100 files, instead of 100 separate requests, each for a single file." And what do Firefox and other braindead web browsers do? They make a separate request for each file. But heay, never mind all those numerous connections to ad servers to retrieve marketing garbage (i.e. not the content you are after), lets concentrate on compressing HTTP headers instead. Brilliant. It's trivial to use pipelining: 1. Feed your HTTP requests through netcat or some equivalent to retrieve the files and save them to a concatenated file, 2. split the concatenated file into separate files if desired, 3. view in your favorite browser. No ad server BS. Now that's "SPEEDY".

dcsommer 13y ago
Pipelining falls short of SPDY in several respects. The biggest problem is that it suffers from head of line blocking. One slow request or response prevents others from making progress.
- osth 13y ago
  I trust in theory this is true, but I've never personally observed this in practice. I guess SPDY fans' marketing of this "feature" would be more convincing if I could see a demonstration. I just don't see any noticeable delays when using pipelining. What strikes me as peculiar about the interest in SPDY is that I never saw any interest in pipelining before SPDY. And I really doubt it was because of potential head of line blocking or lack of header compression. I think users just were not clued in about pipelining. The speed up between not using pipelining and using it is, IME, enormous. 1 connection for 100 files versus 100 connections for 100 files. It is a huge efficiency gain. Yet most users have never even heard of HTTP pipelining, or never tried it. If they really wanted such a big speed up, why wouldn't they use pipelining, or at least try it? Why wouldn't they demand that browsers implement it and turn it on by default? Users are being encouraged to jump right into SPDY, a very recent and relatively untested internal project (e.g. see the CRIME incident) of one company, most users, if not all, having never previously experimented with even basic pipelining, which has been around since the 1999 HTTP/1.1 spec and has support via keep alives in almost all web servers. Noticeable speed gains would be seen if www pages were not so burdened with links to resources on external hosts. That's what's really slowing things down, as browsers make dozens of connections just to load a single page with little content. The speed gains from cutting out all that third party host cruft would make any speed gains from avoiding theoretical potential head of line blocking during pipelining seem miniscule and hardly worth all the effort. If you want to see how much pipelining speeds up getting many files from the same host, you do not need SPDY to do that. Web servers already have the support you need to do HTTP/1.1 pipelining. (Though on rare occasions site admins have keep-alives disabled, like HN for example. In effect these admins are saying, "Sorry, no pipelining for you.")
  - akalin 13y ago
    HTTP pipelining is turned off by default in most browsers due to concerns with buggy proxies and servers (see https://bugzilla.mozilla.org/show_bug.cgi?id=264354 https://bugzilla.mozilla.org/show_bug.cgi?id=264354 ). It may work for you and the particular set of servers you visit, but I suspect browser developers would rather have a browser that by default works with the widest possible range of configurations. Unfortunately, it being turned off by default in most browsers means that most people won't see the benefits from it. Hopefully, the upcoming HTTP/2 standard will fare better (latest draft: https://tools.ietf.org/html/draft-unicorn-httpbis-http2-01 https://tools.ietf.org/html/draft-unicorn-httpbis-http2-01 ). Note that HTTP/2 will be based on SPDY (in particular, SPDY/4 with the new header compressor). Hopefully, when the standard is finalized and we have multiple strong implementations, that will allay the concerns you seem to have with SPDY today. (Disclaimer: I work on SPDY / HTTP/2 for Chromium.)

dcsommer 13y ago

SPDY isn't necessarily insecure. Disabling header compression, for instance, works around the CRIME vulnerability.

richo 13y ago
Yeah, and if that didn't directly contravene SPDY's specification it'd be a great option: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3#TOC-2.6.10.1-Compression http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...
- dcsommer 13y ago
  You can use a compression level of 0. That is, pass through.
  - richo 13y ago
    You can, but then you've got to write this enormous block comment saying "I realise this looks wrong and broken, but ssl is also broken so don't change this constant", until some junior dev inevitably does anyway. Having known vulnerabilities baked into a standard with "weird looking" mitigation strategies is really poor choice IMO. That said, I do see your point. There are also other edgecases, like serving statics on a seperate, uncookied domain that benefit greatly from SPDY in the here and now.
- akalin 13y ago
  Disabling gzip compression isn't the only workaround to the CRIME attack. For Chromium, Adam Langley patched zlib to differentiate between various classes of data; see https://code.google.com/p/chromium/issues/detail?id=139744#c12 https://code.google.com/p/chromium/issues/detail?id=139744#c... and https://chromiumcodereview.appspot.com/10837057/ https://chromiumcodereview.appspot.com/10837057/ . However, it's more difficult for other SPDY implementations to use the patched zlib, so this isn't an ideal solution. For SPDY/4 / HTTP/2, we will have a custom header compressor which is intended to eliminate CRIME-like attacks: https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-00 https://tools.ietf.org/html/draft-ietf-httpbis-header-compre... . (Disclaimer: I work on SPDY / HTTP/2 for Chromium.)