14

I've been looking at SPDY for increased performance, particularly with full-site SSL. I understand most of what it does, but I've not had time to go through and do a full review of it. What should I know about it before enabling it? Are there any security implications I should be aware of?

Polynomial
  • 132,208
  • 43
  • 298
  • 379

3 Answers3

11

SPDY has been reported to be vulnerable to the CRIME attack, but this will be patched in next protocol version. The specifics of CRIME target HTTP cookies, so the fixed protocol will do something special when compressing cookies (namely, it will not compress cookies with the rest of the headers; instead, it will use a dedicated channel to transport the cookie values, with a specific code stating "same cookie than previously").

As a general rule, encryption leaks data length, and compression (any kind of compression) makes the length dependent on the data byte values, thus increasing the information leakage. Encryption and compression don't mix well together. I personally would recommend not activating SPDY for HTTPS. For plain HTTP, however, go on; it won't make things worse security-wise than the mere fact of using plain HTTP.

It would be interesting to gather some hard data on the actual bandwidth benefits of SPDY. Google initially boasted about making page loading "55% faster" but this was in lab conditions. Actual speed-ups may vary quite widely on the kind of request that the site handles. As usual, there is no performance issue unless demonstrated by unambiguous measures.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • The site will have HTTPS enabled site-wide, so I think I'll avoid SPDY. I'll certainly consider it for future projects though, and I'll keep an eye out for that new protocol update. – Polynomial Jan 24 '13 at 14:38
  • FWIW, I've seen improvements in the range of 30-50% using Firefox as a client - but the problem was finding sites supporting SPDY (apart from Google). – symcbean Jan 25 '13 at 09:46
  • 2
    The *next version* from the linked article was 2 versions ago. Chrome iterates *fast*. – tylerl Jan 28 '13 at 07:59
  • 5
    FWIW, both Firefox and Chrome disabled SPDY header compression before the CRIME attack was made public - and it has stayed this way. Hence, neither browser is susceptible to the attack. As far as benefits of SPDY.. There have been plenty of studies since the original whitepaper, both done by Google and third parties. For example, focusing on mobile: https://developers.google.com/speed/articles/spdy-for-mobile – igrigorik Jan 28 '13 at 08:12
  • Note that crime initially targeted cookies, but there is no reason it has to. It could just as easily target any sensitive data in a compressed, encrypted package of which the attacker can control some part. – atk Sep 27 '14 at 04:13
5

SPDY necessarily uses TLS, since unencrypted traffic so frequently gets mangled by well-meaning HTTP proxies. This means that SPDY is largely incompatible with locations that employ proxies that intercept and decode TLS traffic.

SPDY decreases the overhead of HTTP traffic; so applications that involve a lot of small HTTP requests would see a large speedup, use cases involving a small number of large requests would see a minor speedup if any.

Chrome v21 disables header compression in SPDY because of the CRIME cookie compression issue, so it's theoretically immune to that particular attack as of some time ago. Supposedly there was going to be a more elegant/permanent fix in v22 or v23, but I don't have the changelogs to compare. Chrome is currently at v24.

It is unlikely that there remain any known security-related issues; as best as my research can show, you're as safe with SPDY as your are with HTTPS -- whatever you want to take that to mean.

If you have a "normal" website with the standard asset collection, SPDY probably won't provide more than a few dozen milliseconds of speedup. So in that case it's not really worth the trouble. But if you have a highly-interactive AJAX-heavy application with many small queries and updates being shuttled around, SPDY provides an elegant solution to the natural impedance mismatch interactivity and HTTP.

Community
  • 1
tylerl
  • 82,225
  • 25
  • 148
  • 226
3

While it's true that SPDY protocol versions prior to 4 (still in progress) are vulnerable to the CRIME attack, actual browser implementations of SPDY are not known to be vulnerable. Firefox currently simply effectively disables request header compression, and Google Chrome places each cookie in its own Huffman group. Adam Langley goes into further details in his blog post on the matter.

If you have HTTPS enabled site-wide, then using SPDY should be a very sizable win. Note that when Google search switched to using SSL by default, despite the cost of HTTPS, it was actually faster for SPDY capable browsers (like Google Chrome).

William Chan
  • 31
  • 1