3 ms·

Good point, you could possibly correlate the PDF size to determine what document it was. Didn't think of that. It still doesn't make HTTPS a bad idea though :)

rjsw 11y ago
Sending a known source text using encryption isn't usually a good idea if you want to keep the key secret.
- djcapelis 11y ago
  If it were that easy to get keys HTTPS would be fucked.
- nitrogen 11y ago
  HTTPS uses a new key for every session.
  - dogma1138 11y ago
    Most web servers out there implement one form of another of key reuse usually via a dedicated SSL Session Cache otherwise their CPU's would melt ;) One of the main reasons that SSL is relatively cheap right now is that not only you have some level of hardware acceleration, but web servers are now every good at managing and reusing SSL sessions. On NGINX the default TTL for an SSL session is 5min without constant keep alive, however on most installations that I've seen this has been extended significantly. You can store about 4000 sessions in 1 MB of data, that vs the amount of CPU cycles a handshake will take is a no brainier for most server owners. You can however configure your clients not to reuse an existing session, not sure how well servers will behave in that scenario, some servers which implement TLS actually use that feature as a security measure. mod_tls by default iirc only accepts SSL data sessiona with the same key as the SSL control session while the SSL session is in cache which makes some clients (old curl for example) actually incompatible with it so you might have issues when you trying to pull a file from an HTTPS or FTPS/SFTP service.
    - e12e 11y ago
      Reusing the session key implies that the client already knows the shared secret. Sure, if a client goes through his work-place, ssl-stripping proxy, then you might see that minitor@proxy.nsa.gov retrieved documentX, and that drone@proxy.nsa.gov retrieved the same document with the same session - but the traffic would be different unless all response headers were the same. And the proxy could just log the access anyway.
comex 11y ago
The server could partially mitigate such an attack, at the cost of a bit of bandwidth, by appending junk to round file sizes up to the nearest multiple of, say, 1MB. Not something I envision your average site doing, but a site like Cryptome...
- cpach 11y ago
  I’ve been thinking about this too. It would be great if it would suffice with small amounts of junk. But that might just be wishful thinking from my side. Apparently some folks at Stanford/Microsoft researched this problem already in ’02: http://infolab.stanford.edu/~qsun/research/identification.pdf http://infolab.stanford.edu/~qsun/research/identification.pd...
  - comex 11y ago
    Cryptome also has the advantage of mostly serving individual large files, rather than HTML/CSS/JS with a lot of bursty dependent requests. The exponential rather than linear padding suggested by that paper sounds like a good idea, as it better reflects the typical distribution of file sizes. Small amounts of junk might be significantly more effective than nothing. I had to remind myself this is not like a crypto timing attack where the attacker usually gets to retry the operation as many times as they want, making even large random padding potentially susceptible to statistical analysis; a user will usually download a particular document from a server at most a few times. However, these days I'd say the bandwidth of good Internet connections is high enough compared to typical single-digit-MB PDF sizes that relatively large amounts of junk shouldn't inconvenience users too much; I just tested and got ~2.2MB/s from Cryptome, which is not terribly high, but definitely high enough that, say, doubling a 5MB PDF to 10MB would be no big deal. For the user, anyway. I have no idea what Cryptome's bandwidth costs look like.

rjsw 11y ago

Sending a known source text using encryption isn't usually a good idea if you want to keep the key secret.

djcapelis 11y ago
If it were that easy to get keys HTTPS would be fucked.
nitrogen 11y ago
HTTPS uses a new key for every session.
- dogma1138 11y ago
  Most web servers out there implement one form of another of key reuse usually via a dedicated SSL Session Cache otherwise their CPU's would melt ;) One of the main reasons that SSL is relatively cheap right now is that not only you have some level of hardware acceleration, but web servers are now every good at managing and reusing SSL sessions. On NGINX the default TTL for an SSL session is 5min without constant keep alive, however on most installations that I've seen this has been extended significantly. You can store about 4000 sessions in 1 MB of data, that vs the amount of CPU cycles a handshake will take is a no brainier for most server owners. You can however configure your clients not to reuse an existing session, not sure how well servers will behave in that scenario, some servers which implement TLS actually use that feature as a security measure. mod_tls by default iirc only accepts SSL data sessiona with the same key as the SSL control session while the SSL session is in cache which makes some clients (old curl for example) actually incompatible with it so you might have issues when you trying to pull a file from an HTTPS or FTPS/SFTP service.
  - e12e 11y ago
    Reusing the session key implies that the client already knows the shared secret. Sure, if a client goes through his work-place, ssl-stripping proxy, then you might see that minitor@proxy.nsa.gov retrieved documentX, and that drone@proxy.nsa.gov retrieved the same document with the same session - but the traffic would be different unless all response headers were the same. And the proxy could just log the access anyway.

comex 11y ago

The server could partially mitigate such an attack, at the cost of a bit of bandwidth, by appending junk to round file sizes up to the nearest multiple of, say, 1MB. Not something I envision your average site doing, but a site like Cryptome...

cpach 11y ago
I’ve been thinking about this too. It would be great if it would suffice with small amounts of junk. But that might just be wishful thinking from my side. Apparently some folks at Stanford/Microsoft researched this problem already in ’02: http://infolab.stanford.edu/~qsun/research/identification.pdf http://infolab.stanford.edu/~qsun/research/identification.pd...
- comex 11y ago
  Cryptome also has the advantage of mostly serving individual large files, rather than HTML/CSS/JS with a lot of bursty dependent requests. The exponential rather than linear padding suggested by that paper sounds like a good idea, as it better reflects the typical distribution of file sizes. Small amounts of junk might be significantly more effective than nothing. I had to remind myself this is not like a crypto timing attack where the attacker usually gets to retry the operation as many times as they want, making even large random padding potentially susceptible to statistical analysis; a user will usually download a particular document from a server at most a few times. However, these days I'd say the bandwidth of good Internet connections is high enough compared to typical single-digit-MB PDF sizes that relatively large amounts of junk shouldn't inconvenience users too much; I just tested and got ~2.2MB/s from Cryptome, which is not terribly high, but definitely high enough that, say, doubling a 5MB PDF to 10MB would be no big deal. For the user, anyway. I have no idea what Cryptome's bandwidth costs look like.