本站于2023年9月4日。收到“大连君*****咨询有限公司”通知
说我们IIS7站长博客，有一篇博文用了他们的图片。
要求我们给他们一张图片6000元。要不然法院告我们

为避免不必要的麻烦，IIS7站长博客，全站内容图片下架、并积极应诉
博文内容全部不再显示，请需要相关资讯的站长朋友到必应搜索。谢谢！

另祝：版权碰瓷诈骗团伙，早日弃暗投明。

相关新闻：借版权之名、行诈骗之实，周某因犯诈骗罪被判处有期徒刑十一年六个月

叹！百花齐放的时代,渐行渐远!

---

　　在HTTP里，一切都是明文传输的，流量在途中可随心所欲的被控制。而在线使用的 WebApp，流量里既有通信数据，又有程序的界面和代码，劫持简直轻而易举。

　　HTTPS虽然不是绝对安全，但运营商要想劫持也不是这么简单的事情。

　　下面我们来聊一聊HTTPS如何做到防劫持。

　　先来看看HTTPS建立连接的过程，相比HTTP的三次握手，HTTPS在三次握手之后多了SSL握手。如下图：

　　整个流程大概如下：

　　1.浏览器将自己支持的一套加密规则发送给网站。

　　2.网站部署了一组SSL秘钥，分私钥和秘钥。

　　3.网站从浏览器的加密规则中选出一组加密算法与HASH算法，并将自己的身份信息（公钥）以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。

　　4.获得网站证书之后浏览器要做以下工作：

　　a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。

　　b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。

　　c) 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密。这个加密过程是非对称加密，即公钥加密，私钥解密。私钥只在网站服务器上存储，其他人无法获得这个私钥，也就无法解密。可理解为公钥是锁，私钥是钥匙，客户端将随机数用公钥锁上，经过网络传输到服务器，整个过程就算有人拦截了信息，由于没有私钥解锁，也就无法解密。

　　CA证书校验

　　5.将生成的所有信息发送给网站。

　　6.网站接收浏览器发来的数据之后，使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。

　　7.使用密码加密一段握手消息，发送给浏览器。

　　8.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。

　　这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。

　　备注：非对称加密算法用于在握手过程中加密生成的密码，对称加密算法用于对真正传输的数据进行加密，而HASH算法用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键，因此在传输的时候使用了非对称加密算法对其加密。非对称加密算法会生成公钥和私钥，公钥只能用于加密数据，因此可以随意传输，而网站的私钥用于对数据进行解密，所以网站都会非常小心的保管自己的私钥，防止泄漏。

　　如何防劫持

　　对于HTTP请求来说，常见的劫持有DNS劫持和内容劫持。

　　举个网上的例子，有人在知乎问过一个问题。

　　在浏览器输入如下域名https:// www.zhihu.com那浏览器要打开这个网站，首先要解析域名www.zhihu.com,结果这个域名被黑客劫持到他的私人服务器1.2.3.4,结果我的浏览器和他 的私人服务器1.2.3.4建立SSL连接，他的服务器1.2.3.4也和www.zhihu.com建立SSL的连接，我收发的数据都通过他的服务器1.2.3.4中转，也就是黑客的服务器1.2.3.4相当于一个https代理服务器，结果我收发的所有数据，他都能看到。可能这样被劫持吗？

　　这个黑客的攻击就是通常说的中间人攻击，跳转1.2.3.4就是DNS劫持，DNS被劫持到一个非源端的IP上。我们根据上文SSL握手的流程来分析一下，这种可能性是否存在。

　　首先如果黑客要跟你的浏览器建立SSL连接，那么他需要有一个CA证书，而通常系统内置根证书都是大型机构的根证书，几乎无法伪造。如果非要做一个只能是自签名证书。

　　浏览器拿着对方的自签名证书和系统证书进行校验。

　　如果他要假冒其他机构颁发证书，因为没有颁发机构的秘钥，那么这个证书的指纹一定没办法对上，还是一样会报警。

　　除非用户自己主动导入一个自己信任的证书。

　　记住，不要随便安装受信任证书，否则HTTPS也帮不了你。我们平时为了调试HTTPS请求，使用Charles/MitmProxy进行抓包，也需要在手机端导入一个证书，让用户选择信任安装，目的就是将Charles/MitmProxy作为中间人代理，如果没有用户信任安装证书的过程，也同样无法解析HTTPS的请求包。

　　还有人就说了，我可以让用户回落到HTTP协议啊，中间人用HTTPS跟服务器通信，然后用HTTP跟客户端通信——要知道大部分用户在地址栏输入URL时，并没有指定协议的习惯，都是打www开头而不是打https://www开头，能用HTTPS全是Web+Server上80端口301+Location到HTTPS的功劳。

　　看起来似乎中间人充当了一个替换页面里HTTPS资源到HTTP的反向代理，好像可行性还是很高。

　　但是只要利用HSTS（HTTP+Strict+Transport+Security，RFC6797）就可以解决这个问题。通过在HTTP+Header中加入Strict-Transport-Security的声明，告诉浏览器在一定时间内必须通过HTTPS协议访问本域名下的资源。

　　这种情况下，只要用户曾经在安全网络环境下访问过一次某站，中间人在指定时间内也无法让其回落到HTTP。

　　解决完DNS劫持，再看内容劫持就简单多了。

　　你作为一个中间人，你没有服务器私钥A，是不能解密客户端发送的内容的，如果你没有客户端自己生成的密钥B，所以你也不能解密客户端发过去的内容的。

　　总结：

　　1.CA证书保证了公钥的可靠性。

　　2.服务端私钥+公钥的非对称加解密保证了客户端生成的随机数传输安全，不会被中间人拦截获取。But，非对称加密对服务端开销大。

　　3.所以利用随机数的对称加密保证后续通讯的安全性，也可以降低服务器的解密开销。

　　4.HTTPS只针对传输内容进行加密，保证的是客户端和网站之间的信息就算被拦截也无法破解。如果不是全站HTTPS，仅仅只是在登录页采用HTTPS，那些HTTP连接的页面同样是危险的，从HTTP->HTTPS跳转依然可能被劫持。国内的部分银行就是这样，对安全性的考量还比不上百度，百度早就全站HTTPS了。

　　如果你对Charles的自签名证书选择不信任，那么Charles也无法做到中间人解密。

　　整个过程：手机----》Charles ----》 服务器， Charles 即充当了服务端又充当了客户端，才使得数据能够正常的交互，在一次请求中数据被两次加解密，一次是手机到Charles，一次是Charles到真正的服务端。这个过程中最重要的一环就是手机端安装的根证书！