一篇读懂HTTPS：加密原理、安全逻辑、数字证书等

一、引言

HTTPS（全称： Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。本文，就来深刻介绍下其原理。

补充：限于篇幅，本文对于https的相关技术要点的介绍尽可能简明扼要，如想要详细了解HTTPS的方方面面，请阅读《即时通信安全篇（七）：若是这样来理解HTTPS，一篇就够了》。

（本文同步发布于：http://www.52im.net/thread-2446-1-1.html）

二、相关文章

《即时通信安全篇（七）：若是这样来理解HTTPS，一篇就够了》

《一文读懂Https的安全性原理、数字证书、单项认证、双项认证等》

《HTTPS时代已来，打算更新你的HTTP服务了吗？》

《苹果即将强制实施 ATS，你的APP准备好切换到HTTPS了吗？》

《一分钟理解 HTTPS 到底解决了什么问题》

三、为何须要https

缘由其实很简单：就是由于http不安全。

 

当咱们往服务器发送比较隐私的数据（好比说你的银行卡，身份证）时，若是使用http进行通讯。那么安全性将得不到保障。

首先数据在传输的过程当中，数据可能被中间人抓包拿到，那么数据就会被中间人窃取。

其次数据被中间人拿到后，中间人可能对数据进行修改或者替换，而后发往服务器。

最后服务器收到数据后，也没法肯定数据有没有被修改或替换，固然，若是服务器也没法判断数据就真的是来源于客户端。

总结下来，http存在三个弊端：

1）没法保证消息的保密性；

2）没法保证消息的完整性和准确性；

3）没法保证消息来源的可靠性。

https就是为了解决上述问题应运而生的。

四、基本概念：加密技术、数字证书和数字签名

为了解决http中存在的问题，https采用了一些加解密，数字证书，数字签名的技术来实现。下面先介绍一下这些技术的基本概念。

4.1 对称加密与非对称加密

为了保证消息的保密性，就须要用到加密和解密。加解密算法目前主流的分为对称加密和非对称加密。

（4.1.1）对称加密（共享密匙加密）：

客户端和服务器公用一个密匙用来对消息加解密，这种方式称为对称加密。客户端和服务器约定好一个加密的密匙。客户端在发消息前用该密匙对消息加密，发送给服务器后，服务器再用该密匙进行解密拿到消息。

 

对称加密的优势：对称加密解决了http中消息保密性的问题

对称加密的缺点：对称加密虽然保证了消息保密性，可是由于客户端和服务器共享一个密匙，这样就使得密匙特别容易泄露。

由于密匙泄露风险较高，因此很难保证消息来源的可靠性、消息的完整性和准确性。

 

（4.1.2）非对称加密（公有密匙加密）：

既然对称加密中，密匙那么容易泄露，那么咱们能够采用一种非对称加密的方式来解决。

采用非对称加密时，客户端和服务端均拥有一个公有密匙和一个私有密匙。公有密匙能够对外暴露，而私有密匙只有本身可见。

使用公有密匙加密的消息，只有对应的私有密匙才能解开。反过来，使用私有密匙加密的消息，只有公有密匙才能解开。这样客户端在发送消息前，先用服务器的公匙对消息进行加密，服务器收到后再用本身的私匙进行解密。

 

非对称加密的优势：

1）非对称加密采用公有密匙和私有密匙的方式，解决了http中消息保密性问题，并且使得私有密匙泄露的风险下降；

2）由于公匙加密的消息只有对应的私匙才能解开，因此较大程度上保证了消息的来源性以及消息的准确性和完整性。

非对称加密的缺点：

1）非对称加密时须要使用到接收方的公匙对消息进行加密，可是公匙不是保密的，任何人均可以拿到，中间人也能够。那么中间人能够作两件事，第一件是中间人能够在客户端与服务器交换公匙的时候，将客户端的公匙替换成本身的。这样服务器拿到的公匙将不是客户端的，而是服务器的。服务器也没法判断公匙来源的正确性。第二件是中间人能够不替换公匙，可是他能够截获客户端发来的消息，而后篡改，而后用服务器的公匙加密再发往服务器，服务器将收到错误的消息；

2）非对称加密的性能相对对称加密来讲会慢上几倍甚至几百倍，比较消耗系统资源。正是由于如此，https将两种加密结合了起来。

 

 

 

4.2 数字证书与数字签名

为了解决非对称加密中公匙来源的不安全性。咱们可使用数字证书和数字签名来解决。

（4.2.1）数字证书的申请：

在现实中，有一些专门的权威机构用来颁发数字证书，咱们称这些机构为认证中心（CA Certificate Authority）。

咱们（服务器）能够向这些CA来申请数字证书。

申请的过程大体是：

1）本身本地先生成一对密匙，而后拿着本身的公匙以及其余信息（好比说企业名称啊什么的）去CA申请数字证书。

2）CA在拿到这些信息后，会选择一种单向Hash算法（好比说常见的MD5）对这些信息进行加密，加密以后的东西咱们称之为摘要：

单向Hash算法有一种特色就是单向不可逆的，只要原始内容有一点变化，加密后的数据都将会是千差万别（固然也有很小的可能性会重复，有兴趣的小伙伴鸽巢原理了解一下），这样就防止了信息被篡改。

3）生成摘要后还不算完，CA还会用本身的私匙对摘要进行加密，摘要加密后的数据咱们称之为数字签名。

4）最后，CA将会把咱们的申请信息（包含服务器的公匙）和数字签名整合在一块儿，由此而生成数字证书。

5）而后CA将数字证书传递给咱们。

（4.2.2）数字证书怎么起做用：

服务器在获取到数字证书后，服务器会将数字证书发送给客户端，客户端就须要用CA的公匙解密数字证书并验证数字证书的合法性。那咱们如何能拿到CA的公匙呢？咱们的电脑和浏览器中已经内置了一部分权威机构的根证书，这些根证书中包含了CA的公匙。

 

之因此是根证书，是由于现实生活中，认证中心是分层级的，也就是说有顶级认证中心，也有下面的各个子级的认证中心，是一个树状结构，计算机中内置的是最顶级机构的根证书，不过不用担忧，根证书的公匙在子级也是适用的。

客户端用CA的公匙解密数字证书，若是解密成功则说明证书来源于合法的认证机构。解密成功后，客户端就拿到了摘要。

此时，客户端会按照和CA同样的Hash算法将申请信息生成一份摘要，并和解密出来的那份作对比，若是相同则说明内容完整，没有被篡改。最后，客户端安全的从证书中拿到服务器的公匙就能够和服务器进行安全的非对称加密通讯了。服务器想得到客户端的公匙也能够经过相同方式。

下图用图解的方式说明通常的证书申请及其使用过程：

 

五、https的工做原理

经过上面的学习，咱们了解对称加密与非对称加密的特色和优缺点，以及数字证书的做用。https没有采用单一的技术去实现，而是根据他们的特色，充分的将这些技术整合进去，以达到性能与安全最大化。这套整合的技术咱们称之为SSL（Secure Scoket Layer 安全套接层）。

因此https并不是是一项新的协议，它只是在http上披了一层加密的外壳。 

 

先看一下https链接的创建流程图：

 

如上图所，这里把https链接创建到断开分为6个阶段，12过程。

下面将对12个过程一 一作解释：

1）客户端经过发送Client Hello报文开始SSL通讯。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密匙长度等）；

2）服务器可进行SSL通讯时，会以Server Hello报文做为应答。和客户端同样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容时从接收到的客户端加密组件内筛选出来的；

3）服务器发送证书报文。报文中包含公开密匙证书；

4）最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束；

5）SSL第一次握手结束以后，客户端以Client Key Exchange报文做为回应。报文包含通讯加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密匙进行加密；

6）接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文以后的通讯会采用Pre-master secret密匙加密；

7）客户端发送Finished报文。该报文包含链接至今所有报文的总体校验值。此次握手协商是否可以成功，要以服务器是否可以正确解密该报文做为断定标准；

8）服务器一样发送Change Cipher Spec报文；

9）服务器一样发送Finished报文；

10）服务器和客户端的Finished报文交换完毕以后，SSL链接就算创建完成。固然，通讯会收到SSL的保护。今后处开始进行应用层协议的通讯，即发送HTTP请求；

11）应用层协议通讯，即发送HTTP相应；

12）最后由客户端断开链接。断开链接时，发送close_notify报文。上图作了一些省略，这步以后再发送TCP FIN报文来关闭与TCP的通讯。

另外，在以上流程图中，应用层发送数据时会附加一种叫作MAC（Message Authentication Code）的报文摘要。MAC可以查知报文是否遭到篡改，从而保证报文的完整性。

下面再用图解来形象的说明一下，此图比上面数字证书的图更加的详细一些（图片来源于《图解HTTP》）：

 

通过上面的介绍，咱们能够看出https先是利用数字证书保证服务器端的公匙能够安全无误的到达客户端。而后再用非对称加密安全的传递共享密匙，最后用共享密匙安全的交换数据。

六、必定要用https吗？

https那么的安全，是否是咱们在什么场景下都要去使用https进行通讯呢？答案是否认的。

1）https虽然提供了消息安全传输的通道，可是每次消息的加解密十分耗时，消息系统资源。因此，除非在一些对安全性比较高的场景下，好比银行系统，购物系统中咱们必需要使用https进行通讯，其余一些对安全性要求不高的场景，咱们其实不必使用https。

2）使用https须要使用到数字证书，可是通常权威机构颁发的数字证书都是收费的，并且价格也是不菲的，因此对于一些我的网站特别是学生来说，若是对安全性要求不高，也不必使用https。

七、参考资料

[1] 通俗理解数字签名，数字证书和https

[2]一个故事讲完https

[3] 图解HTTP

附录：更多安全方面的文章

《即时通信安全篇（一）：正确地理解和使用Android端加密算法》

《即时通信安全篇（二）：探讨组合加密算法在IM中的应用》

《即时通信安全篇（三）：经常使用加解密算法与通信安全讲解》

《即时通信安全篇（四）：实例分析Android中密钥硬编码的风险》

《即时通信安全篇（五）：对称加密技术在Android平台上的应用实践》

《即时通信安全篇（六）：非对称加密技术的原理与应用实践》

《即时通信安全篇（七）：用JWT技术解决IM系统Socket长链接的身份认证痛点》

《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》

《理论联系实际：一套典型的IM通讯协议设计详解（含安全层设计）》

《微信新一代通讯安全解决方案：基于TLS1.3的MMTLS详解》

《来自阿里OpenIM：打造安全可靠即时通信服务的技术实践分享》

《简述实时音视频聊天中端到端加密（E2EE）的工做原理》

《移动端安全通讯的利器——端到端加密（E2EE）技术详解》

《Web端即时通信安全：跨站点WebSocket劫持漏洞详解(含示例代码)》

《通俗易懂：一篇掌握即时通信的消息传输安全原理》

《IM开发基础知识补课(四)：正确理解HTTP短链接中的Cookie、Session和Token》

《快速读懂量子通讯、量子加密技术》

《即时通信安全篇（七）：若是这样来理解HTTPS原理，一篇就够了》

《一分钟理解 HTTPS 到底解决了什么问题》

《一篇读懂HTTPS：加密原理、安全逻辑、数字证书等》

>> 更多同类文章 ……

（本文同步发布于：http://www.52im.net/thread-2446-1-1.html）