关于HTTPS的理解，你知道的也许并没有那么多——详解HTTPS

上面是我用Wireshark工具所抓到的一次完整HTTP请求的样子。

什么是分层网络模型

互联网发展早期，需要解决的一个重要问题就是电脑之间如何传输数据。人们需要找到一种大家都认同的规范，每个想要相互连接的计算机都需要按照规范来办事。这期间有一个协议脱颖而出，他就是现在应用非常广泛的TCP/IP协议，它规定了网络上的计算机要如何找到另一台计算机，并且如何与之建立连接。TCP/IP的发明者还非常有远见地提出了“网络分层”的概念，将复杂的网络通信划分成了多个层次，每个层次只需要关心自己的问题，将大问题划分为了很多个小问题从而解决了网络通信的难题。就像我们写代码需要分层一样(Service,Controller,Dao层等等)，每一层只需要关注自己的功能。 值得注意的是，TCP/IP协议只有四层，而我们现在经常说起的OSI七层网络模型，是由国际标准组织（ISO）后来才提出来的。在此之前，虽然TCP/IP协议非常优秀，但是奈何市面上还是各玩各的，所以ISO想要制定一个大一统的协议，在很多细节上进行了细化，成就了我们现在所看到的七层网络模型。我们简单对比一下OSI七层模型和TCP/IP的四层模型：

虽然OSI七层模型有更细分的设计，但是他也无法撼动TCP/IP已经实行多年的统治地位，所以OSI模型现在更多是一种建议和标准。 在TCP/IP模型中，我们的HTTP协议，TCP协议，IP协议分别位于应用层，传输层和互联网层。当我们发起一次HTTP请求，浏览器会按照HTTP协议的要求，拼装出HTTP的数据，再调用下层TCP协议提供的API将HTTP数据封装到TCP协议中，再往下针对IP协议再一次封装，最后到达物理网络层，数据被发送出去。 目标主机收到数据以后，反过来将包装好的数据一层一层剥开，最终得到我们要传递的信息，然后再一次将要返回的数据经过层层协议的打包返回到源主机。

带着保险箱去旅行

从上面的基础知识我们不难发现，HTTP协议是非常简单且高效。

HTTP直接运行在TCP协议之上，依靠TCP来实现自己的稳定性。HTTP使用明文传输，数据可读性和可扩展性都非常好。

但是它的简单高效也成为了一把双刃剑，原始的HTTP请求就像是在网上裸奔，所有信息都是明文传递，毫无安全可言。随着科技的发展，人们对安全、隐私的要求越来越高，特别是在现在万物互联的时代，敏感信息如果不经过保护直接在网上传播，将造成极大的隐患。

------在这样的历史浪潮中，HTTPs应运而生。

HTTPs与HTTP的区别就在这个s上，它代表的是"TLS"，既安全传输层协议。TLS也是运行在TCP之上的应用层协议，但是与一般传输数据的协议不同，TLS所关心的，只有安全。我们可以认为TLS就是一个运行在TCP上的保险箱，现在我们将需要保护的数据先装入这个保险箱，再经过TCP发送出去，就能实现我们对于安全的需求。我们将HTTP over TCP，变成了HTTP over TLS over TCP。

那么这个保险箱是如何工作的呢？这就是我们今天的重点。

何谓安全

我们考虑一下两个人写信的场景，怎样才能做到安全的远程交流呢？

我不想我们写信的内容被人看懂得想个办法保证内容不被人修改你得在信里面证明你的身份一旦证明了这是你写的，以后你可不许抵赖

如果能够做到这四点，那么我们的信应该是比较安全的，而这四点正好对应了我们信息安全领域中的四个要点，既：

机密性完整性身份认证不可否认

下面我们就逐一来分析一下HTTPs是如何做到这四点的：

1. 机密性

我们知道两台计算机之间要想传输数据，这些数据必然会经过层层路由，这些节点上的每台计算机理论上都能看到我们的数据，所以安全的首要目标就是对我们想要传输的数据进行加密。 根据密码学的知识，摆在我们面前的有两种选择---对称加密和非对称加密。 对称加密使用一把密钥，加密解密都用它，在双方都知道密钥并且妥善保管的情况下理论上非常安全。但是对于我们复杂的网络环境，一台服务器需要服务众多的客户，难道要为每个客户都配置一个对称加密的密钥吗？这显然不现实。

那么非对称加密呢？一把私钥对应一把公钥，私钥加密的内容只有公钥可以解开，公钥加密的内容也只有私钥可以解开，那么我们在服务器上配置一把私钥，再把公钥发给所有客户，是不是就行了呢？

答案是否定的，原因有两点：

服务器是面向大众客户的，公钥必然会公开，谁都可以获取，那么路由的中间节点一样可以拿着这把公钥解析服务器返回的报文。非对称加密的性能无法适应互联网高并发的环境，所有请求都用非对称加密会导致连接异常缓慢，无法使用。

基于上述两点，HTTPs做了一个非常聪明的选择，就是混合加密。现在我们在TCP三次握手的基础上再引入TLS的四次握手，而这次会晤的重要目标就是协商出密钥。为了便于理解我们先看一个简单的模型：

客户端通过可靠的渠道获取到服务器的公钥。客户端生成一个随机数作为对称加密的密钥，也就是本次会话的主密钥

(实际上生成主密钥需要Server-Client都参与，通过相同的算法算出来，但是在老版本的RSA交换密钥中最终的安全性还是客户端保证的，所以这里我们简单认为是客户端生成了一个随机数即可，后面会详细讲到)客户端用Server的公钥将主密钥加密传输给Server。后续交换内容均用主密钥进行加密解密。

混合加密.png2. 完整性

机密性我们可以满足之后，来看看第二个需要考虑的重点，完整性。 大家应该也有注意到，我们在HTTPs握手模型中的前几次数据交换也都是明文传输的，因为双方还没有协商出主密钥的时候是无法进行加密传输的。而在这个过程中又有许多关键的信息，这些信息我们需要有一定的手段保证他们不会被人修改。 这时候就需要引入数字签名。 在数字签名中首先要提到的就是摘要算法（也就是我们常说的Hash函数，HTTPs中常见的有SHA-2族等），它的作用是将任意长度的数据映射成一串固定长度的字符串。摘要算法有几个特点：

单向性，无法通过计算出来的字符串反推出原文雪崩效应，即原文中一点点微小的改变也会导致计算出的字符串完全不一样，无法通过规律逆向推导。抵抗冲突，既然是将无限打的数据集映射到有限大的空间中（字符串空间），势必会出现映射冲突的可能，既不同的数据映射出的字符串是相同的。抵抗冲突是摘要算法的一个重要指标，一个好的摘要算法他的冲突概率应该是非常非常小的。

这三个特点使得我们可以很好的验证原文数据的完整性，我们只需要使用SHA-2计算出报文的摘要，将它附在报文后面。接收方收到报文后，再通过同样的算法计算报文的摘要，如果和发送过来的摘要相同，那么就可以验证

数据的完整性。3. 身份认证

有了完整性验证还是不够，我们网络中的人可能太坏了，如果他连摘要也一起修改了呢？这时候还需要为摘要上一把小小的锁，不能让人轻易修改，这就是数字签名。 现在我们将摘要信息用RSA非对称加密中的私钥进行加密，在接收方使用公钥解密验签，即便中间人想要修改摘要，但是他无法得知原始的私钥，所以数字签名是无法伪造的。 客户端接收到请求之后用服务器的公钥将签名解密，再验证完整性，这样既可以保证消息没有被篡改过，又可以保证消息确实是目标服务器发送的。

4. 不可否认

由于存在伪装（任何一方都可能被中间人冒名顶替），所以其中一方可以假装没有收到对方消息或对方收到的消息不是自己发的。 在使用数字签名验签的过程中我们也实现了不可否认的特性，大家可以想一想服务器安全ppt，既然中间人无法获取私钥，也就无法伪造签名。反过来讲，一旦我们验签成功，说明数字签名合法，那么上述信息就确确实实是对应的人发送的，无法抵赖。

5. 公钥的信任问题

有了上述几点的分析，我们为HTTP设计的安全方案似乎已经可以了。但是还有一个致命的问题，就怎么把公钥安全地交到用户手上？ 之前的分析都基于一个假设，无论是非对称交换密钥，还是签名的验签，都需要用到服务器的公钥，并且我们都认为这把公钥一定是和服务器的私钥对应的。但是问题就出在这里，服务器如何安全的把公钥传递给用户？如果在公钥的传递过程中就被人替换，那后续的加密等步骤不就没有意义了吗。 这个时候有同学会说，简单啊，我们把这个公钥加密一下传输给客户不久好了吗？ 。。。。。。 等等，那加密公钥用的密钥又怎么传输？这已经成了一个鸡生蛋的问题，网络协议的制定者们也意识到了这一点，光靠算法等技术手段已经没法了，一定要人为介入打破这个循环。 咣的一声，CA（Certification Authority）闪亮登场。 CA介入之后，它以自己的信誉为各服务器的公钥尽心担保。这时候我们服务器在第一步发送给客户的不再是简单的公钥，而是一连串的信息，包括服务器的域名，服务器持有者等等，当然最重要的还是服务器的公钥。 这些信息并不是简单的发送，他们经过了CA的认证，CA使用自己的私钥对他们进行了签名，生成了数字证书。 然后CA通知微软苹果安卓。。。等终端操作系统提供商：“你们把我(CA)的公钥先放在你们的操作系统里”。这就是我们常说的根证书。 这时候CA的担保工作算是完成了。客户端在收到服务器的数字证书之后，使用内置在设备中的根证书进行验签，取得可信任的服务器公钥，从而解决了公钥的信任问题。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!