近日在网络传得比较离谱的一条消息是对TLS/SSL应用层的窃听。随着瓷翁生日的临近，长城似乎有越蹦越高的趋势，导致不少人对SSL v3的安全性也产生了怀疑，这里客栈尝试用简短的图文解释一下所谓的窃听如何完成，以及通过什么方式避免。
SSL会话破解有三种主要方式：一是通过嵌入系统获取密匙，二是通过巧妙的方式进行Cryptanalysis（密码分析），三是设立中间人执行MITM攻击。
假如攻击者能入侵用户主机或服务器，那用户资料就直接沦为刀俎了，再绕道SSL属于白费力气。因此保持个人系统安全对防止第一类“破解”尤为重要。攻击者并不是在破解SSL协议，而是在直接想办法和你的系统挂钩，盗取加密前和解析后的信息。
本地分析加密会话很简单，类似Http Analyzer的软件支持IE，Firefox，Chrome和Safari几款浏览器的请求记录，它们是站在用户与浏览器之间的看客，而非本地与远程主机之间的黑客（对于不支持的软件，例如Opera或Putty，它是无法记录HTTPS请求的）。
第二种方式因缺乏有效的密码分析，并没有实际应用；SSL v3本身没有已知漏洞，解开会话需要利用客户端和服务器端的漏洞完成（获取密匙）；等同第一类攻击了。
相比之下，最可行的SSL窃听方式是第三类：通过MITM。无需获得密匙，无需本地木马，远程窃听者通过建立两条链接：一条从窃听对象到窃听服务器，另一条从窃听服务器到目的服务器，尝试偷换身份并做到会话窃听。
之前我们也说了，协议本身并没有漏洞，因此浏览器的安全设计和用户的安全意识就成了最受考验的部分。第三类攻击要生成不合法的证书，当今的浏览器在遇到该类证书时都会提示错误，但信息的表达方式各不相同，误导用户接受非法证书也时常发生。
Chrome 3-beta的警告是最显眼的。
Firefox 3.5的警告需要阅读，也算显眼的。
Opera 10的警告包含有用信息，但未必能帮助分析。
Safari 4 on Windows的警告和普通提示没什么区别，一点就过了……
IE7的警告够简洁，但解释不足。不知道IE8如何（安装不能，无法测试）。
IE6的警告有够误导，以多数票计算，这是可以接受的对吧？
为了更好地测试各浏览器在MITM攻击下的反应，这里使用Stanford教学用的简单SSL MITM Proxy来测试。具体设置如下：
先准备好浏览器与Java。下载工具并解压压缩包后，使用命令行工具，转到该目录，并输入以下命令（Linux用户请看Readme）。
这样就会在本地设立一个窃听用的Proxy，它会尝试修改所有加密链接发送的证书，将自己寄生在加密连接上。（注意该Proxy并不需要安装在本地，它可以安装在信息途经的任意服务器上，包括任何Tor节点。）
配置浏览器使用这个代理（localhost:8001），模拟请求通过远程的窃听服务器。和目的服务器配上之后，Proxy就会接收原证书，并制造假证书发送给浏览器，这时浏览器应该提示错误。
假如用户选择接受该证书，则余下的通信可被监听，这些通行将被记录在本地的output.txt，各位可自行瞻仰其详尽程度。
如果你看到的传输内容是一大串数字，请看Encoding是否启用了gzip，那是gzip后的网页数据；Amazon不启用gzip，直接返回HTML代码。
一个简单的SSL窃听就是这样完成的。但如何防止呢？
I. 认真检查URL——这是废话，但也是最致命的用户疏忽。
II. 不要接受非法证书——当前用户关注度不足。
尤其是在存放了个人信息的网站。例子中的非法证书替换了发行者的部分（替换为locahost和stanford），是非常好辨认的错误。实际应用中，普通用户将很难分辨证书的真伪，这时选择拒绝才是上策，不管你有多信任该网站。
对于部分没有证书却强迫使用HTTPS的网站，请避免提交任何涉及个人隐私的信息，以免发生意外（接受非法证书将建立未验证的加密连接，用户和网站都没有办法判断是否有人窃听该链接）。
最后是检查CA机构，CA机构告诉浏览器是否应该相信一个网站：假如你不信任签发证书的那家CA，那它验证的网站你也不应相信（浏览器均内置了CA列表，但根据浏览器的不同，它们支持的CA数量也略有不同）。
III. 不要允许SSL v1和v2——过期的SSL版本。
SSL v1和v2都有已知漏洞，不要允许浏览器降至这两个级别。主流浏览器都有禁止老加密协议的选项。
IV. 使用现代化的浏览器——你想要安全，却继续使用IE6核心？
有些网站存在HTTPS与HTTP混用的问题，这时要小心拦截。虽然无法在远程修改被加密的对象，但未加密对象是可以修改的；若有攻击者插入隐藏表 格或JS代码，数据可能被提交至第三方服务器，而用户不会察觉曾被窃听。IE7+会提醒用户有关“安全与不安全内容同时存在”的问题。
（我发现Opera 10和Safari 4都比较沉默，不会提示“存在未加密对象”，是我没设置对还是它们不受影响就不清楚了。）
实际应用中，由于SSL窃听十分耗费资源，是无法大规模长时间实施的；若你在浏览时经常碰到证书错误的情况，请尝试换用浏览器以排除软件上的错误。若情况继续，祝君好运……话说回来，收买CA机构也许比购买窃听服务器便宜得多；所幸咱们这边没什么大型的CA机构，否则……
大体的解释就这么多了，欢迎留言指教。
完。
2009-09-28 更新：添加了备注，欢迎指教。
来源：http://bitinn.net/5087/
==========
《理解SSL窃听》一文的备注
以下内容在写原文的时候觉得和SSL窃听关系不大，就没加入，这里补充给有兴趣的读者。
关于认真检查URL——请不要只依赖浏览器的“正面反馈”（Positive Feedback）和“负面反馈”（Negative Feedback）进行判断。BlackHat会议几年间公开过的SSL“漏洞攻击”，均是配合浏览器的存在弱点，回避负面反馈，制造虚假的正面反馈来迷惑用户。手段包括替换favicon，通过IDN仿造URL和利用CA认证漏洞等等。有些网站在HTTP登录表格旁附上锁头图片，本身也是一种误导。
关于Cryptanalysis（密码分析）——虽然SSL本身的匙交换没有漏洞，但证书的验证一直是研究人员攻击的对象。2008年末有一队研究人员成功构建了MD5的碰撞哈希（使用200多台PS3和几十张合法证书），证明用MD5算法构造的证书均可以被伪造。不过该证书早已过期，而大部分CA（包括Verisign和Comodo）都已转用SHA-1作为加密算法；用户只要保证系统时间的正确，足以防止攻击者利用现有伪造证书。
关于信任CA——我在文中已提及了少数CA认证流程上的不谨慎，而他们又是除OCSP外的主要验证关卡，因此对CA的检查是首要的（你可以删除不信任的内置root CA，在浏览器选项里）。如今严峻的工作是促进CA扫荡曾经签发的不安全证书，民间亦有偏方，包括SSL Blacklist插件。
（注意：root CA使用什么算法并不重要，重要的是中间层使用的算法。浏览器本身信任root CA，因此不会验证他们的证书。解释1，解释2。）
简单点说，有足够CS知识的攻击者会尽量伪装自己（某些工具能混合多种攻击），但他无法破解SSL：一个警觉的用户也有办法及时察觉异样。
推荐阅读：Decrypting A Wireshark Capture With Ssl Traffic
image via flickr
PS：由于有很多·Linux·users喜欢看到自己的OS，客栈更新了UA检测。这里重申，那东西只是看着好玩，用什么OS是你自己的事。
来源：http://bitinn.net/5122/
相关帖子： http://briteming.blogspot.co.uk/2011/11/few-ideas-for-your-proxy-20.html
--------------------------------------------------------------------------------------------
首先要强调的是，目前没有对SSL v3这个安全协议的可行攻击；所有窃听均需利用客户端（浏览器及用户）的弱点执行，而非对协议本身的直接攻击。So, in before the fear spreads…
SSL会话破解有三种主要方式：一是通过嵌入系统获取密匙，二是通过巧妙的方式进行Cryptanalysis（密码分析），三是设立中间人执行MITM攻击。
假如攻击者能入侵用户主机或服务器，那用户资料就直接沦为刀俎了，再绕道SSL属于白费力气。因此保持个人系统安全对防止第一类“破解”尤为重要。攻击者并不是在破解SSL协议，而是在直接想办法和你的系统挂钩，盗取加密前和解析后的信息。
本地分析加密会话很简单，类似Http Analyzer的软件支持IE，Firefox，Chrome和Safari几款浏览器的请求记录，它们是站在用户与浏览器之间的看客，而非本地与远程主机之间的黑客（对于不支持的软件，例如Opera或Putty，它是无法记录HTTPS请求的）。
第二种方式因缺乏有效的密码分析，并没有实际应用；SSL v3本身没有已知漏洞，解开会话需要利用客户端和服务器端的漏洞完成（获取密匙）；等同第一类攻击了。
相比之下，最可行的SSL窃听方式是第三类：通过MITM。无需获得密匙，无需本地木马，远程窃听者通过建立两条链接：一条从窃听对象到窃听服务器，另一条从窃听服务器到目的服务器，尝试偷换身份并做到会话窃听。
之前我们也说了，协议本身并没有漏洞，因此浏览器的安全设计和用户的安全意识就成了最受考验的部分。第三类攻击要生成不合法的证书，当今的浏览器在遇到该类证书时都会提示错误，但信息的表达方式各不相同，误导用户接受非法证书也时常发生。
Chrome 3-beta的警告是最显眼的。
Firefox 3.5的警告需要阅读，也算显眼的。
Opera 10的警告包含有用信息，但未必能帮助分析。
Safari 4 on Windows的警告和普通提示没什么区别，一点就过了……
IE7的警告够简洁，但解释不足。不知道IE8如何（安装不能，无法测试）。
IE6的警告有够误导，以多数票计算，这是可以接受的对吧？
为了更好地测试各浏览器在MITM攻击下的反应，这里使用Stanford教学用的简单SSL MITM Proxy来测试。具体设置如下：
先准备好浏览器与Java。下载工具并解压压缩包后，使用命令行工具，转到该目录，并输入以下命令（Linux用户请看Readme）。
java -cp iaik_jce.jar; mitm/MITMProxyServer -localHost
localhost -localPort 8001 -outputFile output.txt -keyStore FakeCAStore
-keyStorePassword passphrase -v
这样就会在本地设立一个窃听用的Proxy，它会尝试修改所有加密链接发送的证书，将自己寄生在加密连接上。（注意该Proxy并不需要安装在本地，它可以安装在信息途经的任意服务器上，包括任何Tor节点。）
配置浏览器使用这个代理（localhost:8001），模拟请求通过远程的窃听服务器。和目的服务器配上之后，Proxy就会接收原证书，并制造假证书发送给浏览器，这时浏览器应该提示错误。
假如用户选择接受该证书，则余下的通信可被监听，这些通行将被记录在本地的output.txt，各位可自行瞻仰其详尽程度。
如果你看到的传输内容是一大串数字，请看Encoding是否启用了gzip，那是gzip后的网页数据；Amazon不启用gzip，直接返回HTML代码。
一个简单的SSL窃听就是这样完成的。但如何防止呢？
I. 认真检查URL——这是废话，但也是最致命的用户疏忽。
II. 不要接受非法证书——当前用户关注度不足。
尤其是在存放了个人信息的网站。例子中的非法证书替换了发行者的部分（替换为locahost和stanford），是非常好辨认的错误。实际应用中，普通用户将很难分辨证书的真伪，这时选择拒绝才是上策，不管你有多信任该网站。
对于部分没有证书却强迫使用HTTPS的网站，请避免提交任何涉及个人隐私的信息，以免发生意外（接受非法证书将建立未验证的加密连接，用户和网站都没有办法判断是否有人窃听该链接）。
最后是检查CA机构，CA机构告诉浏览器是否应该相信一个网站：假如你不信任签发证书的那家CA，那它验证的网站你也不应相信（浏览器均内置了CA列表，但根据浏览器的不同，它们支持的CA数量也略有不同）。
III. 不要允许SSL v1和v2——过期的SSL版本。
SSL v1和v2都有已知漏洞，不要允许浏览器降至这两个级别。主流浏览器都有禁止老加密协议的选项。
IV. 使用现代化的浏览器——你想要安全，却继续使用IE6核心？
有些网站存在HTTPS与HTTP混用的问题，这时要小心拦截。虽然无法在远程修改被加密的对象，但未加密对象是可以修改的；若有攻击者插入隐藏表 格或JS代码，数据可能被提交至第三方服务器，而用户不会察觉曾被窃听。IE7+会提醒用户有关“安全与不安全内容同时存在”的问题。
（我发现Opera 10和Safari 4都比较沉默，不会提示“存在未加密对象”，是我没设置对还是它们不受影响就不清楚了。）
实际应用中，由于SSL窃听十分耗费资源，是无法大规模长时间实施的；若你在浏览时经常碰到证书错误的情况，请尝试换用浏览器以排除软件上的错误。若情况继续，祝君好运……话说回来，收买CA机构也许比购买窃听服务器便宜得多；所幸咱们这边没什么大型的CA机构，否则……
大体的解释就这么多了，欢迎留言指教。
完。
2009-09-28 更新：添加了备注，欢迎指教。
来源：http://bitinn.net/5087/
==========
《理解SSL窃听》一文的备注
以下内容在写原文的时候觉得和SSL窃听关系不大，就没加入，这里补充给有兴趣的读者。
关于认真检查URL——请不要只依赖浏览器的“正面反馈”（Positive Feedback）和“负面反馈”（Negative Feedback）进行判断。BlackHat会议几年间公开过的SSL“漏洞攻击”，均是配合浏览器的存在弱点，回避负面反馈，制造虚假的正面反馈来迷惑用户。手段包括替换favicon，通过IDN仿造URL和利用CA认证漏洞等等。有些网站在HTTP登录表格旁附上锁头图片，本身也是一种误导。
关于Cryptanalysis（密码分析）——虽然SSL本身的匙交换没有漏洞，但证书的验证一直是研究人员攻击的对象。2008年末有一队研究人员成功构建了MD5的碰撞哈希（使用200多台PS3和几十张合法证书），证明用MD5算法构造的证书均可以被伪造。不过该证书早已过期，而大部分CA（包括Verisign和Comodo）都已转用SHA-1作为加密算法；用户只要保证系统时间的正确，足以防止攻击者利用现有伪造证书。
关于信任CA——我在文中已提及了少数CA认证流程上的不谨慎，而他们又是除OCSP外的主要验证关卡，因此对CA的检查是首要的（你可以删除不信任的内置root CA，在浏览器选项里）。如今严峻的工作是促进CA扫荡曾经签发的不安全证书，民间亦有偏方，包括SSL Blacklist插件。
（注意：root CA使用什么算法并不重要，重要的是中间层使用的算法。浏览器本身信任root CA，因此不会验证他们的证书。解释1，解释2。）
简单点说，有足够CS知识的攻击者会尽量伪装自己（某些工具能混合多种攻击），但他无法破解SSL：一个警觉的用户也有办法及时察觉异样。
推荐阅读：Decrypting A Wireshark Capture With Ssl Traffic
image via flickr
PS：由于有很多·Linux·users喜欢看到自己的OS，客栈更新了UA检测。这里重申，那东西只是看着好玩，用什么OS是你自己的事。
来源：http://bitinn.net/5122/
相关帖子： http://briteming.blogspot.co.uk/2011/11/few-ideas-for-your-proxy-20.html
--------------------------------------------------------------------------------------------