13

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?

Improve this question
3

1 Answer 1

Reset to default
8

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.

Improve this answer
5
  • With regard to adding the padding and hiding the timing, what do you think about this ASP.NET idea, and the suggested Security.SE improvement to MSFT's idea as a logical pattern to generate the padding?
    – makerofthings7
    Commented Sep 30, 2011 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
    Commented Sep 30, 2011 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
    Commented Sep 30, 2011 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
    Commented Sep 30, 2011 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
    Commented Sep 30, 2011 at 15:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .