根据以下论文,可以通过检查 AJAX 调用并将大小参数用作加密预言机来解密 HTTPS 流量。
我应该在每个 HTTPS GET 或 POST 旁边发送可变长度的有效负载吗?这足以保护自己免受这种攻击吗?
HTTPS 响应是否也应附加可变长度字符串?
随机长度数据的随机附加应该有多大?
根据以下论文,可以通过检查 AJAX 调用并将大小参数用作加密预言机来解密 HTTPS 流量。
我应该在每个 HTTPS GET 或 POST 旁边发送可变长度的有效负载吗?这足以保护自己免受这种攻击吗?
HTTPS 响应是否也应附加可变长度字符串?
随机长度数据的随机附加应该有多大?
从外部只能看到交换数据的长度,即请求的总长度,以及响应的总长度(四舍五入为对称密码块大小的倍数,例如如果使用AES,则为16字节;但 RC4 完全不四舍五入)。为避免泄露任何信息,所有请求和所有响应都应具有完全相同的大小;所以填充应该有一个可变的大小,这取决于填充数据的长度。如果您添加具有随机长度但概率分布不依赖于填充请求或响应的大小的填充,则如果该请求定期执行,则可以统计地重建原始请求长度。
填充字节不需要是随机的。只有长度是“从外面”可见的。您可以使用常量字节值(例如,自定义 HTTP 标头X-Padding: ZZZZZZZZZ
,其内容'Z'
为适当长度的序列)。使用随机数据实际上可能会通过计时泄漏额外的信息(如果随机生成器不是很快,攻击者可以观察客户端或服务器的反应时间并推断填充的大小,从而间接获得真实的请求或响应长度)。
总是以固定大小为目标是浪费网络带宽,因为所有请求都将具有最大可能请求的大小,并且所有响应都具有最大可能响应的大小。@Paŭlo 建议填充到给定值的下一个倍数(例如,直到下一个长度是 500 字节的倍数)是适当的:它比总是填充到相同的长度泄漏更多,但它不会泄漏很多; 并且避免浪费网络资源。