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?
|
|
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. |
|||||||||||
|
|
SPDY necessarily uses TLS over port 443, 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. |
|||
|
|
|
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). |
|||
|
|
