Google disables compression for OpenSSL in Chrome - SSL exploit coming?

Re:Google disables compression for OpenSSL in Chrome - SSL e... by forgotusername on Wednesday September 12, 2012 @01:05PM (#4511670)

Colour me stupid, but is there something to prevent inserting indeterminate padding while sending headers? e.g. imagine a request like

    GET / HTTP/1.0
    X-Pad: GET / HTTP/aaaaaaa

Where X-Pad randomly repeats previous bytes, and perhaps 0..8 bytes of random/repeating variable-length data. By randomizing the effectiveness of the compression, surely this attack can be generally prevented by the browser?

You could argue that given enough samples the noise could be filtered and the attack still remains, but the same could be said the same for many successful patches over the years (TCP sequence number randomization, Kaminsky's DNS issue, etc.), and the number of samples required would be pretty infeasible.

[ Parent | on HN ]

Re:Google disables compression for OpenSSL in Chrome - SSL e... by riannucci on Wednesday September 12, 2012 @02:51PM (#4512335)

I'm fairly certain this could be defeated with a little differential cryptanalysis. Similar approaches to defeating side-channel attacks on smart card power usage have been tried and defeated :/

[ Parent | on HN ]

Re:Google disables compression for OpenSSL in Chrome - SSL e... by caf on Wednesday September 12, 2012 @10:36PM (#4514513)

There's no point - you're better off just disabling TLS compression and doing whatever compression of the body-only at the HTTP level.

[ Parent | on HN ]

Re:Google disables compression for OpenSSL in Chrome - SSL e... by StavrosK on Wednesday September 12, 2012 @10:22PM (#4514453)

If it's random, you can just get enough samples and remove the noise. It'd have to be padding to a given number of bytes, but that probably has a vulnerability too.

[ Parent | on HN ]