12

According to the following paper, it is possible to decrypt HTTPS traffic by inspecting AJAX calls and using the size parameter as a cryptographic oracle.

  1. Should I be sending a variable length payload alongside every HTTPS GET or POST? Is that sufficient in protecting myself from this attack?

  2. Should the HTTPS response have a variable length string appended as well?

  3. How large should that random appendage of random length data be?

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 2
    Related [Are URLs viewed during HTTPS transactions to one or more websites from a single IP distinguishable?](http://security.stackexchange.com/questions/4388/are-urls-viewed-during-https-transactions-to-one-or-more-websites-from-a-single-i/4418#4418) – makerofthings7 Sep 30 '11 at 01:20
  • 4
    Actually, instead of using a random-sized padding, a padding to the next multiple of a fixed size would be much more effective, I think. – Paŭlo Ebermann Sep 30 '11 at 12:29
  • 1
    AFAIK, this does not just apply to HTTP/TLS, but also HTTP/TCP/IP/ESP, HTTP/TCP/IP/WPA-CCMP, and potentially other technologies where privacy and integrity is provided below IP. – curiousguy Jul 12 '12 at 23:28

1 Answers1

9

From the outside, one can only see the length of the exchanged data, i.e. the total length of the request, and the total length of the response (rounded to a multiple of the symmetric cipher block size, e.g. 16 bytes if AES is used; but not rounded at all with RC4). To avoid leaking any information, all requests and all responses should have exactly the same size; so the padding should have a variable size which depends on the length of the padded data. If you add padding with a random length but with a probability distribution which does not depend on the size of the padded request or response, then the original request length can be reconstructed statistically if that request is performed on a regular basis.

There is no need for the padding bytes to be random. Only the length is visible "from the outside". You can use constant byte values (e.g. a custom HTTP header X-Padding: ZZZZZZZZZ with, as contents, a sequence of 'Z' of appropriate length). Using random data could actually leak extra information through timing (if the random generator is not very fast, the attacker could observe the client or server reaction time and deduce the size of the padding, thus indirectly obtaining the true request or response length).

Always targeting a fixed size is wasteful of network bandwidth, because all requests will have the size of the largest possible request, and all responses the size of the largest possible response. @Paŭlo's suggestion of padding up to the next multiple of a given value (e.g. up to the next length which is a multiple of 500 bytes) is appropriate: it leaks a bit more than always padding to the same length, but it does not leak much; and it avoids wasting network resources.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • With regard to adding the padding and hiding the timing, what do you think about [this ASP.NET idea](http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx), and the [suggested Security.SE improvement to MSFT's idea](http://security.stackexchange.com/questions/1828/when-does-one-need-to-be-concerned-with-leaking-timing-information-in-net/1830#1830) as a logical pattern to generate the padding? – makerofthings7 Sep 30 '11 at 13:25
  • 1
    @makerofthings: The Microsoft page describes a crude workaround which is "statistically weak". Making the decrypt-and-check-MAC operation in SSL a constant-time operation is the right way to do it, as was pointed out when this attack was first discovered... in 2002 (by Vaudenay). In that case, this is best done in the SSL implementation itself, by _always_ checking the MAC, even if the decryption failed with a "bad padding". – Thomas Pornin Sep 30 '11 at 13:43
  • Just so I understand, should I, or should I not be, adding padding (of a 500 byte multiple) to both HTTPS requests and responses, but do so in a way that doesn't leak timing information? Is the best approach to hide timing oracles to always take a fixed amount of time when generating and appending the padding to the output stream (extrapolation of the second link)? – makerofthings7 Sep 30 '11 at 14:01
  • 1
    @makerofthings: _If_ you fear leaking information through length (that's not an attack I saw in practice), then you should add some padding such that the _total size_ (not the size of the padding) is a fixed size, or (next best thing) a multiple of 500. _If_ you fear such leaks then you shall also fear leaks through timing, which imply the same kind of padding, but timewise (if possible, the total processing time should be independent of the actual data). – Thomas Pornin Sep 30 '11 at 14:58
  • My intent is to assemble a template of security best practices for ASP.NET/MVC for the very paranoid. "Secure by default" taken to the next level. At the very least, even if the feature is disabled then the customer will appreciate I accounted for it. Perhaps this will result in a contract renewal :) – makerofthings7 Sep 30 '11 at 15:02