Coding应该是一辈子的事业，而不是30岁的人。网上有很多文章讲解云端的HTTPS。看完这篇文章，如果还不明白，就骂我没良心吧！图片来自Pexels。以后搞安全的朋友就远离了。本文将带你深入了解HTTPS加解密原理，希望你看完后有所收获：了解HTTPS解决什么问题了解对称加密和非对称加密的原理和使用场景了解CA机构的作用和根证书为什么使用HTTPS近年来，各大公司都在大力推动HTTPS的建设：GoogleChrome将非HTTPS网站标记为不安全。Apple要求APP使用HTTPS进行通信。微信小程序也需要HTTPS协议。那么，我们为什么要做这样的事情呢？我们先来看看HTTP。HTTP（超文本传输??协议）是分布式、协作和超媒体信息系统的应用层协议。可以说HTTP是当代互联网通信的基础。但是HTTP有一个致命的缺陷，就是内容是明文传输的，没有经过任何加密。而这些明文数据会经过WiFi、路由器、运营商、机房等多个物理设备节点。如果中间任何一个节点被监听，传输的内容就会完全暴露。这种攻击技术称为MITM（ManInTheMiddle）中间人攻击。例如，它有点长，但它说明了为什么我对安全性如此着迷。你可以用小时候在课堂上传纸条做类比。你靠着墙坐在教室一边，想把一句“今晚放学我在操场等你”传给坐在窗边的小红，传了六七个人.纵然把钞票对折了，也要防君子不防小人。中间的每个人都可以轻松打开笔记，看看你想说什么。只是还好，要是小刚也喜欢小红，眼看你们两个马上要甜蜜回家，心里不甘心，就改了个字条，改成了“晚上放学你们自己回家”。嗯，我去网吧打游戏。”小红看到你要丢下她一个人打游戏，心里很难过，开始在纸条上质问，“我们说好一起回家的，你打游戏干嘛啊”。在小红的纸条传回去的路上，小刚又改了纸条，“去玩你的游戏吧，我要和小刚一起回家”。于是，你和小红都很伤心，小刚夺走了爱情，你却不知所措。回想一下几年前随处可见的航母劫持事件。当您访问一个正常的网页时，页面上会莫名其妙地出现一些广告标签、重定向脚本和欺骗性的红包按钮。甚至有时候，一个文件本来是要下载的，最后却变成了完全不同的东西。这些都是HTTP明文数据被运营商劫持的现象。各大公司的运营商劫持和员工安全培训都有一个“不要连接陌生的WiFi”，也是出于类似的原因。恶意WiFi的控制者可以看到并篡改HTTP明文传输的信息。为了解决HTTP明文传输数据可能带来的安全问题，1994年Netscape提出了HTTPS（HyperTextTransferProtocolSecure）超文本传输??安全协议。数据通信仍然是HTTP，但使用SSL/TLS对数据包进行加密。HTTPS的实现原理前面说到，HTTPS其实就是通过SSL/TLS对HTTP数据包进行加密传输，那么什么是SSL/TLS呢？SSL（SecureSocketsLayer）安全套接字层和TLS（TransportLayerSecurity）传输层安全协议其实是一套东西。1994年Netscape提出HTTPS协议时，使用SSL进行加密。后来，IETF（InternetEngineeringTaskForce）互联网工程任务组进一步对SSL进行了标准化，并于1999年发布了第一版TLS协议文档TLS1.0。目前最新的TLS协议版本为TLS1.3，于2018年发布。工作流程我们先看一下HTTPS的加解密过程，如下图所示：HTTPS的加解密过程如下：用户发起一个HTTPS请求（比如https://www.mogu.com/)，默认使用服务器的443端口。连接。HTTPS需要一套CA数字证书，其中会包含一个公钥Pub，而对应的私钥Private则在服务器端保密。服务器收到请求，将配置好的包含公钥Pub的证书返回给客户端。客户端收到证书并验证其有效性，主要包括是否在有效期内，证书的域名是否与请求的域名匹配，上层证书是否有效（递归判断，直到根证书建立在系统或浏览器配置的情况下判断）证书），如果没有通过，显示HTTPS警告信息，如果通过，则继续。客户端随机生成一个Key进行对称加密，用证书中的公钥Pub加密后发送给服务器。服务器收到随机Key的密文，用私钥Private与公钥Pub配对解密，得到客户端真正要发送的随机Key。服务器使用客户端发送的随机Key对要传输的HTTP数据进行对称加密，并将密文返回给客户端。客户端使用随机Key对密文进行对称解密，得到HTTP数据的明文。后续的HTTPS请求使用之前交换的随机Key进行对称加密和解密。对称加密和非对称加密既是对称加密又是非对称加密。将有一个公钥，一个私钥和一个随机密钥。为什么这么复杂？这是一套好东西吗？对称加密就是有一个密钥，用它加密一段明文，加密后，只有这个密钥才能解密明文。如果通信双方都持有密钥，天知道你知我，其他人都不会知道，那么通信安全自然就可以得到保障（如果密钥足够强）。但是在HTTPS传输场景下，服务器事先并不知道客户端是谁，你也不可能事先通过互联网悄悄地和各个网站的管理员商量一个通信密钥。那么一定有一个密钥在网上传输的过程。如果在传输过程中被他人监听，那么之后的所有加密都将毫无用处。这时候，我们就需要另一种神奇的加密类型，非对称加密。非对称加密有两个密钥，一个是公钥，一个是私钥。一般来说，使用公钥加密，密文只能用私钥解密。然后，当客户端发起连接请求时，服务器发送公钥，客户端用公钥加密信息，然后将密文发送给服务器，服务器有私钥解密。但是当服务端要返回数据时，如果用公钥加密，客户端没有私钥解密，如果用私钥加密，客户端有公钥解密.但是这个公钥之前已经在网上传输过了，很可能已经有人拿到了，所以不安全，所以这个过程不能只用非对称加密来满足。注意，严格来说，私钥不能用于加密，只能用于签名。这是因为在密码学中生成公钥和私钥时，对不同变量的数学要求是不同的。因此，公钥和私钥抵御攻击的能力也是不同的，在实际使用中是不可互换的。签名功能在HTTPS中也很有用，下面会说明。只有一套公私钥只能保证单向加解密，那么如果我们准备两套公私钥，是不是就可以解决这个问题呢？我们看下面的过程：服务器有一个非对称加密的公钥A1，私钥A2。客户端有非对称加密的公钥B1和私钥B2。客户端向服务器发起请求，服务器返回公钥A1给客户端。浏览器收到公钥A1，将保存的公钥B1发送给服务器。之后，浏览器发送给客户端的所有数据都用公钥B1加密，客户端可以用私钥B2解密。客户端发送给服务器的所有数据都是用公钥A1加密的，服务器可以用私钥A2解密。这时候两个传输方向的数据都经过非对称加密来保证安全，那么为什么不采用这种方案呢？主要原因是非对称加密和解密比对称加密和解密花费更多的时间，这对性能有负面影响。很多损失，大家的体验都很差。因此，我们最终选择了上面介绍的非对称加密+对称加密的方案，再次回顾：服务器有一个非对称加密的公钥A1和私钥A2。客户端发起请求，服务器返回公钥A1给客户端。客户端随机生成一个对称加密密钥K，用公钥A1加密后发送给服务器。服务器收到密文后，用自己的私钥A2对其进行解密，得到对称密钥K。此时就完成了安全的对称密钥交换，解决了对称加密时密钥传输被窃取的问题。之后，双方的通信使用密钥K进行对称加解密。看起来是一个非常完美的方案，兼顾了安全性和性能，但是真的安全吗？CA当局仍然考虑中间人攻击的情况。非对称加密算法是公开的，每个人都可以生成一对公钥和私钥。当服务器返回公钥A1给客户端时，中间人用自己的公钥B1代替，发送给浏览器。浏览器此时什么都不知道，傻傻地用公钥B1加密密钥K发送出去，结果被中间人拦截了。中间人用自己的私钥B2解密得到密钥K，再用服务器的公钥A1加密发送给服务器，完成通信链路，服务器和客户端无感知。HTTPS中介出现这个问题的核心原因是客户端无法确认收到的公钥是否真的是服务端发送的。为了解决这个问题，互联网引入了一个公共信任组织，这就是CA。在使用HTTPS之前，服务器会去认证的CA机构申请数字证书。数字证书包含证书持有者、证书有效期、公钥等信息。服务器将证书发送给客户端，客户端验证证书的身份与要访问的网站的身份一致后，再进行后续的加密操作。但是如果中介比较聪明，只改变了证书的公钥部分，客户端还是无法确认证书是否被篡改过，这时就需要一些防伪技术了。前面提到，在非对称加密中，一般使用公钥进行加密，使用私钥进行解密。私钥加密虽然理论上可行，但不适合数学设计，所以私钥只有解密的功能。什么？除了解密，其实私钥还有一个真正的用途，就是数字签名，其实就是一种防伪技术。只要有人篡改证书，数字签名就必然无法验证。具体过程如下：CA组织有自己的一对公钥和私钥。CA机构在颁发证书时对证书的明文信息进行哈希处理。用私钥对哈希值进行签名，得到数字签名。明文数据和数字签名组成证书，传递给客户端：客户端得到证书，分解为明文部分Text和数字签名Sig1。用CA组织的公钥解签得到Sig2（由于CA组织是一个公开可信的身份，CA组织的证书和公钥信息会内置到系统或浏览器中）。使用证书中声明的哈希算法对明文的text部分进行哈希运算，得到H。当自己计算的哈希值T等于未签名的Sig2时，说明证书是可信的，没有被篡改过。此时签名由CA组织的私钥生成，中介篡改信息后无法获得CA组织的私钥，保证了证书的可信性。请注意，这里有些难以理解的地方。非对称加密的签名过程是私钥对消息进行签名，然后将签名部分连同消息本身发送给对方。收到消息后，使用公钥验证签名。如果签名内容与消息本身一致，则说明消息未被篡改。在这个过程中，系统或浏览器内置CA机构的证书和公钥成为至关重要的一环，也是CA机构公信身份的证明。如果系统或浏览器中没有该CA机构，则客户端无法接受服务器返回的证书，并显示HTTPS警告。实际上，CA机构的证书就是一个信任链。A信任B，B信任C。以Nuggets的证书为例，Nuggets向RapidSSL申请证书，RapidSSL的CA身份由DigiCertGlobal的根CA认证。形成信任链。各级CA机构的私钥是绝对隐私的信息。CA机构的私钥一旦泄露，其公信力将被毁掉。CA组织此前曾多次发生私钥泄露事件，引发了信任危机。所有主要系统和浏览器都必须撤销相应CA的内置根证书。一些旧网站会要求您在使用前下载并安装他们自己的根证书。这意味着本网站所使用的证书无法在系统内置的CA机构与根证书之间形成信任链。您需要自己安装根证书以形成信任。链，这里的风险必须由用户承担。HTTPS的出发点是为了解决HTTP明文传输过程中的信息篡改和监听问题：为了平衡性能和安全性，采用了非对称加密+对称加密。为了保证公钥在传输过程中不被篡改，使用了非对称加密的数字签名功能，通过CA机构和系统根证书的机制来保证HTTPS证书的可信度。作者：怪怪编辑：陶佳龙来源：转载自微信公众号水怪（ID：master0931）
