Discuz! 官方站 -
Powered by Discuz!
后使用快捷导航没有帐号？
只需一步，快速开始
扫一扫，访问微社区
随时随地，快速访问
只要手机在手，您都可以快速、方便地看贴发帖，与论坛好友收发短消息。
极致优化，畅快"悦"读
独有的论坛界面和触屏设计，手机论坛也变得赏心悦目，操作自如。
即拍即发，分享生活
不管是风景图画，还是新闻现场，拍照发帖一气呵成，让您在论坛出尽风头。
下载客户端后，拍摄二维码快速访问本站:
或者通过以下地址访问:
Powered by关于SSL劫持的常识【转】
众所周知，在国内上网会遇到各种各样不同的人为网络故障，使得我们无法正常访问很多网站。但由于很多人并不熟悉网络，很多时候会无法区分不同的网络故障，导致明明是国内的网络封锁，却认为是服务器故障；或明明是服务器故障，却认为是网络封锁的情况。我觉得有必要说明一下不同网络故障的特征，以及区分它们并解决它们的方法。
　　在国内上网环境中，我们经常遇到的网络故障有：DNS劫持、DNS污染、IP封锁、服务器防火墙IP过滤、服务器宕机、基于关键词的TCP连接重置、无状态的TCP连接重置、SSL证书过滤、SSL劫持、HTTP会话劫持等网络故障。下面我就依次进行说明：
1、DNS劫持
　　DNS劫持会导致我们访问了一些不存在的或不稳定的网站的时候，访问到的却是电信114搜索（详见月光博客《断网后互联星空的浏览器劫持》：/archives/738.html
）或访问Google却显示了Baidu的主页（详见月光博客《Google博客搜索摇身一变成百度》：/archives/1100.html
　　而Baidu现在为了避免这种指责，现在即使Google的域名被劫持到Baidu上，也不会出现Baidu的主页了，而是显示一个空白页。而Google却没有这么做。所以有些诋毁Google的网站就会故意把自己的部分域名指向Google的IP，导致访问这些域名的时候出现了Google的主页，导致人们误以为Google做了DNS劫持。聪明的同学自己可以去做一下这个试验，看看这种情况（其他域名指向Baidu
主页的IP，Baidu显示空白页；其他域名指向Google主页的IP，显示Google主页）是不是真的。具体如何操作在这篇文章中就不提及了。
　　如果需要确认自己是否处在DNS劫持的环境中，我们可以在Windows命令行cmd中使用Windows自带的网络诊断工具nslookup查找一个不存在或不稳定的域名进行一下网络诊断：
　　C:\&nslookup
　　Server: ns-pd.
　　Address: 202.96.209.133
　　Non-authoritative answer:
　　Address: 218.83.175.155
　　我们看到，
本应该是一个不存在的域名，DNS服务器应该告诉我们这个域名不存在，但我们却看到DNS服务器告诉我们这个域名的IP为218.83.175.155（不同地区的114搜索的IP都不同，可能得到的IP并不是218.83.175.155，而是自己所在地区的114搜索的服务器IP地址），而这个IP却是
114搜索的IP，导致我们在浏览器中访问这个网站时看到的是114搜索的网页。
　　如果需要解决DNS劫持的问题，可以把自己的域名解析服务器换乘国外的，比如OpenDNS（详见月光博客《使用OpenDNS解决DNS域名劫持》：/archives/1101.html
）或Google
DNS（详见月光博客《Google推出免费DNS服务》：/archives/2009.html
　　解决之后我们再次使用nslookup查找一下这个网站：
　　 C:\&nslookup
　　Server: google-public-dns-
　　Address: 8.8.8.8
　　*** google-public-dns- can’t find
: Non-existent domain
　　我们看到DNS服务器正确的告诉了我们这个域名不存在，我们不会被劫持到 114搜索了。
　　不过，正如《使用OpenDNS解决DNS域名劫持》（/archives/1101.html
）中最后一段所说的那样，“但是对于DNS污染（/archives/1113.html
）的劫持，使用 OpenDNS也无法解决问题”。那么接下来，我就介绍一下DNS污染。
2、DNS污染
　　由于DNS劫持可以通过把域名解析服务器更换为国外的来解决问题，所以国内的网络审查系统需要使用DNS污染来封锁一些域名。这样，即使使用国外的域名服务器也得不到服务器的正确IP，所以也就无法访问这些服务器了。比如现在著名的微博客始祖twitter主页就遭到了DNS污染。
　　如果需要确认域名遭到了DNS污染而不是其他的故障，首先要了解，DNS劫持是由国内的域名服务器完成的，所以我们把域名服务器换成国外的就可以解决问题；而DNS污染是由网络审查系统完成的，所以即使更换了域名服务器，网络审查系统仍旧可以发送伪造的域名解析结果替换正确的解析结果。所以我们可以通过使用一个不存在的国外IP作为我们的域名服务器进行诊断究竟是DNS劫持还是DNS污染。我们仍旧通过使用nslookup进行网络诊断，选一个不存在的国外IP为144.223.234.234：
　　C:\& 144.223.234.234
　　DNS request timed out.
　　 timeout was 2 seconds.
　　*** Can’t find server name for address 144.223.234.234: Timed
　　Server: UnKnown
　　Address: 144.223.234.234
　　Address: 93.46.8.89
　　我们看到，由于144.223.234.234不存在，理应没有任何返回。但我们却得到了一个错误的IP：93.46.8.89。我们再测试一下刚才被DNS劫持的IP的情况：
　　 C:\&nslookup
144.223.234.234
　　DNS request timed out.
　　 timeout was 2 seconds.
　　*** Can’t find server name for address 144.223.234.234: Timed
　　Server: UnKnown
　　Address: 144.223.234.234
　　DNS request timed out.
　　 timeout was 2 seconds.
　　DNS request timed out.
　　 timeout was 2 seconds.
　　*** Request to UnKnown timed-out
　　我们看到， 没有返回结果，那么它没有被DNS污染。
　　如果要解决DNS污染，我们只能使用各种加密代理进行远程DNS解析、VPN
或利用网络审查系统的漏洞（/archives/2184.html ）了。
　　这里IP封锁指的是国内把国外服务器的IP加入了国内网络审查系统的黑名单，导致大部分地区甚至全国无法直接访问服务器。由于国内的网络审查系统是分布式的，所以有可能出现部分地区可以访问，部分地区不能访问的情况。比如现在知名的云存储服务Dropbox的主页，就是遭到了IP封锁。
　　首先我们把域名服务器设置为国外的，排除了DNS劫持的问题。之后我们诊断一下dropbox的域名是否遭到了DNS污染：
　　C:\&nslookup
144.223.234.234
　　DNS request timed out.
　　 timeout was 2 seconds.
　　*** Can’t find server name for address 144.223.234.234: Timed
　　Server: UnKnown
　　Address: 144.223.234.234
　　DNS request timed out.
　　 timeout was 2 seconds.
　　DNS request timed out.
　　 timeout was 2 seconds.
　　*** Request to UnKnown timed-out
　　显然也没有遭到DNS污染。那么接下去我们可以在没有过滤ICMP协议的网络环境中（有些小区宽带和有些公司的内部网络过滤了ICMP协议，无法使用
tracert），我们可以在Windows命令行cmd中使用Windows自带的网络诊断工具tracert进行一下网络诊断是网站遭到了IP封锁还是其他的故障：
　　C:\&tracert -d
　　Tracing route to
[174.36.30.70]
　　over a maximum of 30 hops:
　　 1 18 ms 19 ms 26 ms 58.35.240.1
　　 2 15 ms 20 ms 29 ms 58.35.240.1
　　 3 13 ms 10 ms 14 ms 124.74.20.45
　　 4 14 ms 14 ms 15 ms 124.74.209.137
　　 5 10 ms 15 ms 14 ms 61.152.86.58
　　 6 * * * Request timed out.
　　 7 * * * Request timed out.
　　 8 * * * Request timed out.
　　我们看到，最后一个IP为61.152.86.58（不同地区的IP不一样），之后就不通了，显然在
61.152.86.58附近遭到了IP封锁。那么我们打开/
查一下61.152.86.58是谁在掌控：
　　您查询的IP:61.152.86.58
　　 * 本站主数据：上海市 电信
　　 * 参考数据一：上海市 电信
　　 * 参考数据二：上海市 电信
　　显然，问题在上海电信这里（其他地区可能是地区的本地电信），而不是dropbox服务器的问题。
4、服务器防火墙IP过滤和服务器宕机
　　把这两点放在一起写是因为这两种情况的对外表现是一样的。但和IP封锁却有很大区别。
IP封锁的最后一个可达IP是中国的，而服务器防火墙IP过滤和服务器当机时的最后一个可达IP却是国外的。比如我们拿75.101.142.137做试验，之前在上面部署过alexa的网站，现在这个IP上暂时没有服务器（可以看成服务器宕机）：
　　 C:\&tracert -d 75.101.142.237
　　Tracing route to 75.101.142.237 over a maximum of 30 hops
　　 1 25 ms 18 ms 18 ms 58.35.240.1
　　 2 25 ms 42 ms 27 ms 58.35.240.1
　　 3 10 ms 15 ms 14 ms 124.74.37.9
　　 4 49 ms 59 ms 12 ms 124.74.209.129
　　 5 14 ms 14 ms 14 ms 61.152.86.142
　　 6 10 ms 14 ms 15 ms 202.97.35.154
　　 7 14 ms 15 ms 14 ms 202.97.34.126
　　 8 194 ms 195 ms 194 ms 202.97.51.138
　　 9 171 ms 170 ms 173 ms 202.97.50.54
　　 10 215 ms 179 ms 175 ms 63.146.27.133
　　 11 279 ms 280 ms 278 ms 67.14.36.6
　　 12 * * * Request timed out.
　　 13 249 ms 249 ms 244 ms 72.21.199.40
　　 14 254 ms 254 ms 254 ms 72.21.222.157
　　 15 250 ms 250 ms 249 ms 216.182.232.53
　　 16 270 ms 270 ms 273 ms 216.182.224.22
　　 17 272 ms 269 ms 289 ms 75.101.160.35
　　 18 * * * Request timed out.
　　 19 * * * Request timed out.
　　 20 * * * Request timed out.
　　我们看到最后一个可达IP为75.101.160.35，然后我们查一下这个IP是谁的呢：
　　 您查询的IP:75.101.160.35
　　 * 本站主数据：美国
　　 * 参考数据一：美国
　　 * 参考数据二：美国 华盛顿州金县西雅图市亚马逊公司
　　显然，这个IP并不是IP封锁，而是服务器故障。
　　如果要解决IP封锁，我们只能通过加密代理、VPN或利用网络审查系统的漏洞（比如西厢计划2）进行访问这些被IP封锁的网站了。
5、基于关键词的TCP连接重置
　　国内的网络审查系统在人们通过http协议访问国外网站时会记录所有的内容，一旦出现某些比较“敏感”的关键词时，就会强制断开TCP连接，记录双方IP并保留一段时间（1分钟左右），我们的浏览器也就会显示“连接被重置”。之后在这一段时间内（1分钟左右），由于我们和服务器的IP被摄查系统记录，我们就无法再次访问这个网站了。我们必须停止访问这个网站，过了这段时间再次访问没有这些关键词的网页，就又能访问这个网站了。
　　由于这些特征，我们判断是否遭到了基于关键词的TCP连接重置的情况也比较容易。如果浏览器显示“连接被重置”，并且在一段时间内无法再次访问这个网站，之后过了这段时间访问这个网站上没有这些关键词的网页又能访问的时候，我们就是遭到了基于关键词的TCP连接重置的故障。
　　正是因为
http协议是明文传输的，所以才能基于关键词进行TCP连接重置。所以如果网站支持https加密访问，我们可以通过https方式访问网站，从而解决这个问题。但如果网站不支持https方式访问，我们只能通过加密代理、VPN或利用网络审查系统的漏洞（比如西厢计划1和2）进行访问了。而且国内的网络审查系统对付https也不是没有其他手段了。除了IP封锁外，还有无状态的TCP连接重置、SSL证书过滤、SSL劫持等手段，下面进行依次介绍。
6、无状态的TCP连接重置
　　由于https是加密传输数据的协议，网络审查系统无法知道通过https协议传输了什么内容，但又不允许民众使用https访问“有害信息”，所以我们的审查系统只要监测到（审查系统只是知道访问了这个网站的https协议，并不知道其中传输的内容）访问了指定网站的https协议（比如Google
Docs的https访问方式），就会强制断开TCP连接。这样，这些网站的https协议在国内就无法直接使用了，很多人被迫使用http协议，从而传输的所有内容被审查系统所记录。
　　无状态的TCP连接重置的结果也是浏览器显示“连接被重置”，只不过无论访问这个服务器上的任何网页都会被重置。如果要解决这个问题，也只能依靠加密代理、VPN或利用网络审查系统的漏洞（正在研究之中）了。
7、SSL证书过滤
　　和无状态的TCP连接重置一样，由于
https是加密传输数据的协议，网络审查系统无法知道通过https协议传输了什么内容，但又不允许民众使用https访问“有害信息”，除了域名污染和无状态的TCP连接重置防止无法审查内容外，审查系统还有SSL证书过滤的审查手段。由于https传输过程中，SSL证书却是明文传输的，所以审查系统可以监测SSL证书是否掰发给指定域名的。如果确实如此，那么就强制断开TCP连接，浏览器也会显示“连接被重置”。SSL证书过滤只发生在使用
https访问网站的时候。
　　SSL证书过滤的情况比较少。如果需要解决这个问题，也只能依靠加密代理、VPN或利用网络审查系统的漏洞了。
8、SSL劫持
　　断开https连接虽然能阻止民众访问“有害信息”，但并不知道访问了什么有害信息。基于这一点，国内审查系统针对https的弱点（信任所有证书颁发机构CA），CNNIC申请成为了顶级证书颁发机构（Root
CA），从而可以发假证书进行中间人攻击，从而破解https传输的内容。详见月光博客《破解Google
Gmail的https新思路》：/archives/2058.html
　　如果遭到了SSL劫持，很难发现。我们通过https访问国外网站的时候必须每次检查一下证书是否为国内的证书颁发机构颁发。如果为国内的证书颁发机构颁发，那么很可能遭到了SSL劫持，必须马上停止继续访问。
　　如果要解决SSL劫持，我们可以去浏览器中禁止比如CNNIC那样的国内证书颁发机构的证书（比如《CNNIC，我不信任你》：http://www.spookzang.net/article/1241
）。但这并不能完全解决问题，如果某一天一个不知名的国内证书颁发机构参与了SSL劫持就很难发现。最终我们还需要依赖加密代理或VPN。
9、 HTTP会话劫持
　　HTTP会话劫持是修改正常的http返回结果，可以在其中加入广告，甚至是病毒木马。而一般上网被
http会话劫持加入广告，很有可能认为是网站自己的广告。由于http协议是明文传输的，http会话劫持也就可以做到。月光博客中《电信级的网络弹出广告》：/archives/335.html
、《获取了电信恶意弹出广告的罪证》：/archives/369.html
和《谁控制了我们的浏览器？》：/archives/439.html
也有详细介绍http会话劫持。HTTP会话劫持通常是ISP为了推送广告而实施的，但并不排除这一手段今后会被网络审查系统所利用。
　　要解决HTTP会话劫持，月光博客中也提供了一种解决思路——《解除ADSL弹出广告的方法》：/archives/604.html
。使用浏览器插件屏蔽广告能解决部分问题，也不能完全解决问题。如果要从技术手段解决HTTP会话劫持，一种办法是使用加密代理和VPN访问所有的网站，包括国内的，但也不能完全解决问题，如果HTTP会话劫持是在服务器附近的路由器上设置的，这种方法也无法解决；另一种办法是针对不同的HTTP会话劫持，我们通过刷路由器固件的方式再劫持回来（dd-wrt和tomato路由器固件支持自定义，可能可以把HTTP会话再劫持回原来的数据），或者针对不同的HTTP会话劫持，使用不同的本地应用层代理服务器进行广告过滤。
　　在国内常见的人为网络故障都介绍完了，同学们都可以区分不同的故障了并加以解决吗？
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。https 可能被这样劫持吗？
在浏览器输入如下域名那浏览器要打开这个网站，首先要解析域名,结果这个域名被黑客劫持到他的私人服务器1.2.3.4,结果我的浏览器和他 的私人服务器1.2.3.4建立SSL连接，他的服务器1.2.3.4也和建立SSL的连接，我收发的数据都通过他的服务器1.2.3.4中转，也就是黑客的服务器1.2.3.4相当于一个https代理服务器，结果我收发的所有数据，他都能看到。可能这样被劫持吗？
即为 HTTPS中间人攻击(Man-in-the-Middle Attack)。原理：示例：
.如果你安装了某个不知名的根证书后，你就可以被劫持。所以在闲的没事儿的时候，不要乱装证书，这是一个非常危险的行为。我见过某团队，在自己的服务器上自己签发了证书，然后让大家安装他的根证书，然后这个企业的同学们在上网时所有的https就都被劫持并窃听了。.如果有某人在一个证书机构仿冒你申请成功了你的域名的证书后，你可以被劫持。这个可能性很小，也是售卖证书的机构们标榜自己的牛逼的行为特性之一。原则上来讲，这样的事情不可能发生。其实现在很多证书颁发机构连google的类似域名的证书都不敢售卖了。.如果你申请了多域名证书后，你的证书被盗取，你可以被支持。这个就是自己内部管理问题了，建议缩短证书的有效期，同时保证好证书在服务器上的安全性。.如果你申请的是一个子证书签发机构，有人私下签发了你的域名的证书后，你可以被劫持。如果自己内部出了问题，颁发出去了一张证书，这时只能把子级证书签发的证书快速去证书签发机构作废。通过所谓的截取会话进行劫持，现在看除非服务器上有漏洞，否则还不可能这么快的劫持。原则上来讲，现在的加密长度实在太长，如果你有足够多的计算机，同时计算能力超强，算出服务器上的随机串，也可以劫持滴 :)
只要服务器上安装的是全球信任的SSL证书，比如超安SSL Pro。超真SSL Pro，被劫持的可能性就很小，几乎为零
理论上有可能。但是你可以识别出来的。因为 https 的特性，攻击者需要向你伪装成服务器，向服务器伪装成你。你和
服务器之间原本密封的信件，被攻击者打开阅读后，重新换了个信封封好，再发给你。（攻击者的私人服务器向你提供了一个伪造的证书，用来维持给你提供的 https 访问。）因为攻击者没有原始蜡封的印章（证书的私钥），所以他从黑市弄了一块（验证不严格的CA给他颁发了一张证书）。如果你发现印章细节（证书内容）可疑，那就有可能受到了 https 中间人攻击。如果是伪造的印章，是可以一眼看穿的（浏览器提示），但是，如果专业的印章刻制机构（CA根证书持有者）被贿赂、被欺骗或出于其他目的，参与了伪造，就看不出来了（浏览器没有提示）。所以，要保管好域名的管理权限和敏感用户名邮箱，防止被拿去私刻印章（申请合法证书）；同时，对那些信誉不好的刻制机构（CA），我们要把他从信任列表中移除，避免被欺骗。扩展阅读：
HTTPS协议不支持代理，也就是说，HTTPS协议保护的是你和目的端的通信，这中间不允许出现代理。目的端的服务器是通过证书来验证身份的，所以这样劫持的后果就是：顺便说一下排名第一的答案，你们的某控件自动给用户种根证书用户造么？是为了连骗证书这一步都免了么？
可以，提供两种思路一，你伪造证书（基本不可能，你把颁发证书的机构全拿下？）二，用在一个网段内做mitm，SSLtrip
可以参考我之前的一个思路：
对于大部分https网站，都是有被 MITM 的风险的首先无论PC还是手机 内部都是有一个受信的CA列表的，所以无论是够是真的受信，只要在这个列表里面1.如果某些受信CA 乱签发证书，可以被利用劫持https回话2.如果装了某些apps 或者软件，同时导入了一些自签发的CA，同样可能会被劫持可以用 certificates spinning 来避免这个问题。
不会，因为用户无法和1.2.3.4建立https连接，因为他的服务器没有ca签发的证书！没有证书，怎么建立https连接呢？除非你搞到一张合法的受信任的假的证书，或者你自己签发一个证书，然后用户点击信任你的证书。这样才能建立你们之间的https.
楼主已经说了输入了，所以ssltrip就没有作用了。但是sslsniff可以劫持，原理就是mitm伪造知乎证书并获取浏览器信任（诱骗用户安装），浏览器和mitm使用假证书通信，mitm再将用户请求转发给知乎服务器通信，完整劫获用户信息。不过这种劫持成本较高，需要用户安装证书，也需要mitm加解密，所以大规模劫持不会这么干。
怎么可能。。。你的证书要通过根证书验证。。。你怎么通过？ 除非你把他们这些机构都黑了（或者收买了）。PS，还有就是申请到真证书，记得好像腾讯曾经有这么一个漏洞，乱发证书，导致了不少钓鱼。
已有帐号？
无法登录？
社交帐号登录