How do I securely add a random padding to all ASP.NET AJAX HTTPS responses?

Question

Apparently, it is possible to leak data in an SSL connection based on the size of the HTTPS request and response.

Considering the complexity of the ASP.NET pipeline, how do I securely add a random amount of data that rounds each size up to the nearest 500K?

The security constraints (as I'm aware of now) are

• Don't leak timing information, and always take the same amount of time when generating the extra data

• Always round up to the next 500K value

• The data used as padding doesn't have to be random, our goal is to change the size of the HTTPS response

I'll post the related javascript question (HTTP POST) in a separate question as a courtesy to the PHP users who may not be looking at ASP implementations ;)

Answer 1

Having read the linked articles, I first want to say that best security would probably be clientside; a trusted, secure proxy -- this type of analysis relies upon intimate knowledge of the application, if the attacker can't tell what website your visiting, it can't analyze the responses.

That said, there are things you can do to make YOUR site less vulnerable. But its going to be more complex than just simple padding. One of the examples given is picking a doctor. The list of available doctors is available to all visitors. If you have an auto complete its not hard at all to reduce the number of potential doctors down significantly given that you can watch the traffic. An extreme example would be 500 doctors, only one with a name starting with Z: Dr Zhivago. Thus a 1 letter send that returns one doctor is probably him. Padding the send and receive data won't be enouh to hide this if it is based on a simple rounding up to the nearest 500 bytes. One send and receive that then moves on to the next action on the page is still going to be him. In this type of situation you can do several things -- first is always return MORE than one possibility, even when there is only one, reduce it to just one on the client. Secondly pad the number of REQUESTS, not just the data in the request.

Back to your question, compression makes padding something of a problem as the compressed size leaks. Pad as much as you can with valid data that is filtered out on the client, this will make any attempt to analyze it harder. Be sure that you don't leak padding time when doing your padding.

Finally -- this type of attack would have to be application and possibly user specific. Does anyone really care that much about your traffic?