十分钟了解HTTPS

1、为何要用HTTPS——HTTP协议的缺陷

1. 通讯使用明文（不加密），内容可能会被窃听

2. 不能验证通讯方的身份，因此请求和响应都有多是攻击者发送的

   数据包在由A到B的过程当中，可能经历不少次路由转发，这个过程当中数据包可能会被劫持和替换，A和B都没法肯定收到的信息是否就是对方发送的。

3. 没法证实报文的完整性，多是通过篡改的信息。

   一样是在A到B传输过程当中，数据包被劫持、篡改以后继续传输，虽然接收方收到的数据包就是发送方发送的那个，可是内容已经遭到篡改，这样没法保证报文的完整性。

2、HTTPS是怎么克服这些缺陷的？

2.1 HTTPS是什么？

HTTPS： 在HTTP通讯时增长一层TLS通讯，之前是HTTP直接和TCP通讯，如今HTTP先与TLS通讯，再由TLS和TCP进行通讯。HTTPS拥有加密、证书校验身份、准确性校验这些功能，避免了HTTP的三个缺陷。

TLS的前身是SSL，TLS 1.0一般被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。

HTTP创建通讯时，只须要进行TCP三次握手就能够开始传输数据了，而HTTPS在创建通讯时，先进行TCP三次握手，再进行TLS握手，而后开始发送数据。

2.2 HTTPS的加密功能

加密技术分为：

1. 共享密钥加密，也叫对称密钥加密，只有一把密钥，通讯方必须先将密钥发送给接收方，而后接收方使用密钥对密文解密，可是密钥发送的过程很难保证安全，一旦密钥被窃取，就不能保证加密的安全了。

2. 公开密钥加密，即非对称密钥加密，有两把密钥，公钥public key 和私钥private key

   公钥是公开的，能够随意发布，任何人均可以得到。A使用B发布的公钥加密报文，B接收后使用本身的私钥进行解密，这样私钥不须要传输，也就没必要担忧被窃取的风险。

对称加密处理速度要比非对称加密要快，因此在保证安全的基础上，应多使用对称加密方式。TLS采用非对称加密的加密方式，HTTPS采用混合加密机制： 大部分通讯使用对称密钥加密，但首次交换共享密钥时是使用非对称加密的方式，这样就既保证了安全，又速度最快。

2.3 HTTPS的身份认证功能

按照上文介绍的非对称加密方式，会有一个安全缺陷：客户端怎么知道拿到的公钥是否就是服务端发放的公钥呢，由于在拿到的过程当中，公钥有可能被掉包。因而为了不这个缺陷，引入了证书的概念。

公钥证书

为了保证公钥是目标服务器发行的公钥，须要使用权威第三方机构（如下称为CA机构）颁发的公钥证书：

• 服务器去CA机构申请证书，机构颁发加数字签名的公钥证书，数字签名可使用CA机构的公钥来验证；
• 服务器把公钥证书以公开密钥加密方式传给客户端；
• 浏览器内会植入经常使用CA机构的公钥；
• 客户端从浏览器拿到CA机构的公钥，并用它验证收到的公钥证书的数字签名，验证经过，证实服务器的公钥值得信任，客户端就从公钥证书取出公钥。

总结一下就是服务器传递的公钥上有CA的签名，客户端经过验证签名证明服务器的身份，并安全地获得公钥。

HTTPS首次交换共享密钥使用的是非对称加密方式，这种加密方式会使用公钥证书来验证服务端的身份。而想要验证客户端的身份就不是那么容易了，须要用户去申请证书，并且权威机构的证书是要花钱的，因此客户端身份验证充满挑战。现状是，仅有特殊用途的业务实现了客户端证书，好比那些可支撑客户端证书支出费用的业务，例如银行网银就采用了客户端证书。

2.4 HTTPS的完整性校验功能

在HTTPS的通讯流程中，应用层发送数据时，会附加一种叫作MAC的报文摘要，MAC可以查知报文是否遭到篡改，从而保护报文的完整性。

3、HTTPS创建通讯的过程简介

HTTPS首次创建通讯时，假设C是客户端client，S是服务器端server，以SSL为例：

 

1. C/S会先进行TCP三次握手；

2. 而后C发送Client Hello报文及其余SSL信息，表示开始SSL通讯过程；

3. S收到后回以Server Hello及其余SSL信息，此外S还发送公钥证书，随后发送Server Hello Done通知Client SSL握手协商部分结束

   即SSL第一次握手结束，这个过程最重要的是S把公钥证书交给了C；

4. C验证公钥证书有效性，而后取出公钥，而后：

   • 回以Client Key Exchange报文，报文中包含经过公钥加密过的Pre-master-secret是一个随机密码串。
   • C接着发送Change Cipher Spec报文，告诉S此报文后的通讯会用Pre-master-secret进行加密。
   • C发送Finished报文，并包含上述所有报文的总体校验值。此次握手协商可否成功，要看S是否正确解密该报文。

5. S收到加密过的pre-master secret，用本身的私钥获得pre-master secret，而后：

   • 发送Change Cipher Spec报文

   • S发送Finished报文。

6. C/S使用pre-master secret+客户端随机数+服务端随机数通过一系列算法，生成master secret 主密钥，使用master secret生成对称密钥session key，以后传输的收据均使用session key加密解密。

至此，SSL链接创建完成，这个过程最重要的是C把Pre-master-secret用上一步传递的公钥加密后传给S。以后开始进行HTTP通讯，并用共享密钥对通讯进行对称加密。

4、HTTPS的问题

当使用SSL时，它的处理速度变慢：

1. 通讯速度变慢，由于除了HTTP请求和响应，还要进行SSL通讯，通讯量会增长
2. 由于C/S端都要加密解密，更耗计算资源，SSL加速器能够改善S端问题

建议的是若是非敏感信息使用HTTP通讯，只有在包含我的信息等敏感数据时，才利用HTTPS进行通讯。特别是访问量较多的网站在加密处理时，会承担较大的负载，能够仅在须要信息隐藏时才加密，以节约资源。可是查看淘宝、京东都是全部请求都采用的HTTPS，也有搜索到一些讲部分页面采用HTTP，部分页面采用HTTPS的部署方法的博文，由于如今我对部署这一块的东西还比较生疏，因此后续有时间再关注。

默认端口

1. HTTP默认端口80
2. HTTPS默认端口443

下面咱们来聊一聊HTTPS如何作到防劫持。

SSL握手

先来看看HTTPS创建链接的过程，相比HTTP的三次握手，HTTPS在三次握手以后多了SSL握手。以下图：

 

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证书，而一般系统内置根证书都是大型机构的根证书，几乎没法伪造。若是非要作一个只能是自签名证书。

 

Paste_Image.png

浏览器拿着对方的自签名证书和系统证书进行校验，结果必定是以下图所示：

 

Paste_Image.png

若是他要假冒其余机构颁发证书，由于没有颁发机构的秘钥，那么这个证书的指纹必定没办法对上，仍是同样会报警。

 

Paste_Image.png

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

 

12306

记住，不要随便安装受信任证书，不然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了。

参考

1. 深刻理解HTTPS协议
2. 《图解HTTP》
3. HTTPS工做原理
4. SSL的保密性、真实性、完整性和不能否认性
5. Nginx部署部分https与部分http

做者：superMaryyy连接：https://juejin.im/post/5b762e726fb9a009c72cb73f来源：掘金著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。