基于原始研究中的“建议”:
https://www.openssl.org/~bodo/ssl-poodle.pdf
如果进行中间人攻击(MITM)截获通信,假设客户端的“Hello”与加密在明文传播,那么什么会阻止MITM在降级过程中删除TLS_FALLBACK_SCSV标志(从而使所提出的机制变得低效)?无论如何这种机制本身并不完全有效(因为现有的SSL3.0浏览器会受到影响 - 否则支持就可以完全从服务器端删除):只是在Chrome推广TLS_FALLBACK_SCSV的借口下...
基于原始研究中的“建议”:
https://www.openssl.org/~bodo/ssl-poodle.pdf
如果进行中间人攻击(MITM)截获通信,假设客户端的“Hello”与加密在明文传播,那么什么会阻止MITM在降级过程中删除TLS_FALLBACK_SCSV标志(从而使所提出的机制变得低效)?无论如何这种机制本身并不完全有效(因为现有的SSL3.0浏览器会受到影响 - 否则支持就可以完全从服务器端删除):只是在Chrome推广TLS_FALLBACK_SCSV的借口下...
即使是明文,它仍然被签名。 如果MiM修改了此标志,则所有握手完成的签名/哈希都不匹配。 客户端将检测到它作为握手失败。
您的答案在邮件列表中: http://marc.info/?l=openssl-users&m=141355872416212&w=2
您可以在此处找到有关TLS_FALLBACK_SCSV标志的一些信息: http://wiki.opensslfoundation.com/index.php/SSL_MODE_SEND_FALLBACK_SCSV
基本上,MiM执行的操作是强制客户端降级与网络相关或使TLS握手失败,然后可以成功地强制降级。但是由于签名/哈希,MiM无法调整完整的握手。