对 SSL 的 Padding Oracle 攻击中，第一轮为何能假设 Padding 是 0x01??

[tony1016]

按照其思想，我们具有的条件是

• 可以改变 IV 向量
• 可以观察服务器的返回状态是 500 还是 200

其做法在第一轮是发送 00 00 00 00 00 00 00 01 开始的 IV ，测试如果服务器返回 200 ，则认为找到了中间值，使其异或 VI 得到的明文最终 Padding 为 0x01 。

这里有一点不明白，如果中价值是 XX XX XX XX XX XX 02 00 ，那么我的 IV 为 00 00 00 00 00 00 00 02 时，因为异或的结果依然满足 Padding 的要求（但其 Padding 是 0x02），此时如果当作 0x01 处理，岂不是误导了后面的结论？？

[maemual]

刚好昨晚学习了 CBC Padding Attack ，不知道 SSL Padding Oracle 攻击是否一样。

首先，这里 IV 其实是一个随机的串，只是我在控制最后一位，尝试使得返回 200 。按照我昨晚学习的思路，这里不是直接认为最后 Padding 一定是 01 ，而是 01 的可能性最大，并且因为我们只控制 IV 的最后一位，所以通常也使得最后 Padding 是 01 。

不知道你是在哪看的，还是细节有些不一样。我看的介绍，此时得到一个 200 的返回之后，还需要一步 推测 Pading 是几位，也就是几的过程。

这个过程就不细介绍了。推荐可以看一下 www.crypto101.io 的 PDF 的 7.9 节。

[tony1016]

@maemual 问对领路人，胜读十年书啊。

我看到的资料，包括什么云舒写的分析（ http://www.icylife.net/yunshu/attachments/Padding-Oracle-Attack.pdf ）,都只是把原作者的这一篇 http://blog.gdssecurity.com/labs/2010/9/14/automated-padding-oracle-attacks-with-padbuster.html 翻译了一遍，其中很重要的 padding 长度推测，只字未提。

非常感谢您的回答

[breeswish]

你说的是对的，在这种情况下第一位会有两种情况， padding 都是正确的，不过这是很容易可以识别出的情况，因为推测出的中间值是不对的，在下一轮中这个中间值是不能推测出正确 padding 的，可以被过滤掉。

[tony1016]

@breeswish 我曾经也在想，可能在方法回溯的过程中，一定会推到出矛盾的地方，因此将结果过滤掉。查看 @maemual 提供的资料，我发现一种更好的验证逻辑。因为如果 padding 是 0x01 的话， IV 的倒数第二位是什么，并不影响 padding 是否 valid 。可以通过变换 IV 的倒数第二位来证明， padding 是 0x01

[maemual]

@tony1016 有道理。昨天看的是理论的解法。实际运作中，直接冲着 padding 是 01 ，然后通过 IV 倒数第二位来验证，不管是否能碰出其他位数的 padding ，这样实际操作中更简单直接一点。

[wzxjohn]

@maemual 这个文档很棒诶！不知道有没有人做了翻译。。。

[tony1016]

把整个过程又梳理了一下，写了篇博文，供大家把玩儿

https://story.tonylee.name/2016/03/08/guan-yu-cbczhong-padding-oraclegong-ji-de-zai-jie-du/