一篇文章读懂HTTPS及其背后的加密原理
HTTPS（全称： Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。
1、为什么需要https
使用https的原因其实很简单，就是因为http的不安全。
当我们往服务器发送比较隐私的数据（比如说你的银行卡，身份证）时，如果使用http进行通信。那么安全性将得不到保障。
首先数据在传输的过程中，数据可能被中间人抓包拿到，那么数据就会被中间人窃取。
其次数据被中间人拿到后，中间人可能对数据进行修改或者替换，然后发往服务器。
最后服务器收到数据后，也无法确定数据有没有被修改或替换，当然，如果服务器也无法判断数据就真的是来源于客户端。
总结下来，http存在三个弊端：
- 无法保证消息的保密性
- 无法保证消息的完整性和准确性
- 无法保证消息来源的可靠性
https就是为了解决上述问题应运而生的。
2、基本概念
为了解决http中存在的问题，https采用了一些 (加解密，数字证书，数字签名)的技术来实现。下面先介绍一下这些技术的基本概念
对称加密与非对称加密:
为了保证消息的保密性，就需要用到加密和解密。加解密算法目前主流的分为对称加密和非对称加密。
1.对称加密（共享密匙加密）：客户端和服务器公用一个密匙用来对消息加解密，这种方式称为对称加密。客户端和服务器约定好一个加密的密匙。客户端在发消息前用该密匙对消息加密，发送给服务器后，服务器再用该密匙进行解密拿到消息。
对称加密的优点：
- 对称加密解决了http中消息保密性的问题
对称加密的缺点：
- 对称加密虽然保证了消息保密性，但是因为客户端和服务器共享一个密匙，这样就使得密匙特别容易泄露。
- 因为密匙泄露风险较高，所以很难保证消息来源的可靠性、消息的完整性和准确性。
2.非对称加密（公有密匙加密）：既然对称加密中，密匙那么容易泄露，那么我们可以采用一种非对称加密的方式来解决。
采用非对称加密时，客户端和服务端均拥有一个公有密匙和一个私有密匙。公有密匙可以对外暴露，而私有密匙只有自己可见。
使用公有密匙加密的消息，只有对应的私有密匙才能解开。反过来，使用私有密匙加密的消息，只有公有密匙才能解开。这样客户端在发送消息前，先用服务器的公匙对消息进行加密，服务器收到后再用自己的私匙进行解密。
非对称加密的优点：
- 非对称加密采用公有密匙和私有密匙的方式，解决了http中消息保密性问题，而且使得私有密匙泄露的风险降低。
- 因为公匙加密的消息只有对应的私匙才能解开，所以较大程度上保证了消息的来源性以及消息的准确性和完整性。
非对称加密的缺点：
- 非对称加密时，需要使用到接收方的公匙对消息进行加密，但是公匙不是保密的，任何人都可以拿到，中间人也可以。 那么中间人可以做两件事，第一件是中间人可以在客户端与服务器交换公匙的时候，将客户端的公匙替换成自己的。这样服务器拿到的公匙将不是客户端的，而是服务器的。服务器也无法判断公匙来源的正确性。第二件是中间人可以不替换公匙，但是他可以截获客户端发来的消息，然后篡改，然后用服务器的公匙加密再发往服务器，服务器将收到错误的消息。
- 非对称加密的性能相对对称加密来说会慢上几倍甚至几百倍，比较消耗系统资源。正是因为如此，https将两种加密结合了起来。
数字证书 与数字签名：
为了解决非对称加密中公匙来源的不安全性。我们可以使用数字证书和数字签名来解决。
1.数字证书的申请
在现实中，有一些专门的权威机构用来颁发数字证书，我们称这些机构为认证中心（CA Certificate Authority）。
我们（服务器）可以向这些CA来申请数字证书。
申请的过程大致是：
自己本地先生成一对密匙，然后拿着自己的公匙以及其他信息（比如说企业名称啊什么的）去CA申请数字证书。
CA在拿到这些信息后，会选择一种单向Hash算法（比如说常见的MD5）对这些信息进行加密，加密之后的东西我们称之为摘要。
单向Hash算法有一种特点就是单向不可逆的，只要原始内容有一点变化，加密后的数据都将会是千差万别（当然也有很小的可能性会重复，有兴趣的小伙伴鸽巢原理了解一下），这样就防止了信息被篡改。
生成摘要后还不算完，CA还会用自己的私匙对摘要进行加密，摘要加密后的数据我们称之为数字签名。
最后，CA将会把我们的申请信息（包含服务器的公匙）和数字签名整合在一起，由此而生成数字证书。然后CA将数字证书传递给我们。
2.数字证书怎么起作用
服务器在获取到数字证书后，服务器会将数字证书发送给客户端，客户端就需要用CA的公匙解密数字证书并验证数字证书的合法性。那我们如何能拿到CA的公匙呢？
我们的电脑和浏览器中已经内置了一部分权威机构的根证书，这些根证书中包含了CA的公匙。
之所以是根证书，是因为现实生活中，认证中心是分层级的，也就是说有*认证中心，也有下面的各个子级的认证中心，是一个树状结构，计算机中内置的是最*机构的根证书，不过不用担心，根证书的公匙在子级也是适用的。
客户端用CA的公匙解密数字证书，如果解密成功则说明证书来源于合法的认证机构。解密成功后，客户端就拿到了摘要。
此时，客户端会按照和CA一样的Hash算法将申请信息生成一份摘要，并和解密出来的那份做对比，如果相同则说明内容完整，没有被篡改。最后，客户端安全的从证书中拿到服务器的公匙就可以和服务器进行安全的非对称加密通信了。服务器想获得客户端的公匙也可以通过相同方式。
下图用图解的方式说明一般的证书申请及其使用过程。
1、https原理
通过上面的学习，我们了解对称加密与非对称加密的特点和优缺点，以及数字证书的作用。https没有采用单一的技术去实现，而是根据他们的特点，充分的将这些技术整合进去，以达到性能与安全最大化。 这套整合的技术我们称之为SSL（Secure Scoket Layer 安全套接层）。所以https并非是一项新的协议，它只是在http上披了一层加密的外壳。 https=http+SSL
https的建立
先看一下建立的流程图：
这里把https建立到断开分为6个阶段，12过程。下面将对12个过程一 一做解释
另外，在以上流程图中，应用层发送数据时会附加一种叫做MAC（Message Authentication Code）的报文摘要。MAC能够查知报文是否遭到篡改，从而保证报文的完整性。
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的通信。
经过上面的介绍，我们可以看出https先是利用数字证书保证服务器端的公匙可以安全无误的到达客户端。然后再用非对称加密安全的传递共享密匙，最后用共享密匙安全的交换数据。
下面再用图解来形象的说明一下，此图比上面数字证书的图更加的详细一些（图片来源于《图解HTTP》）
1、https的使用
https那么的安全，是不是我们在什么场景下都要去使用https进行通信呢？答案是否定的。
1.https虽然提供了消息安全传输的通道，但是每次消息的加解密十分耗时，消息系统资源。所以，除非在一些对安全性比较高的场景下，比如银行系统，购物系统中我们必须要使用https进行通信，其他一些对安全性要求不高的场景，我们其实没必要使用https。
2.使用https需要使用到数字证书，但是一般权威机构颁发的数字证书都是收费的，而且价格也是不菲的，所以对于一些个人网站特别是学生来讲，如果对安全性要求不高，也没必要使用https。
HTTPS 的工作原理
我们为什么需要HTTPS？
主要有三个原因：
- 保护隐私(Privacy)：所有信息都是加密传播，第三方无法窃听数据。如果使用HTTP明文传输数据的话，很可能被第三方劫持数据，那么所输入的密码或者其他个人资料都被暴露在他人面前，后果可想而知。
- 数据完整性(Integraty)：一旦第三方篡改了数据，接收方会知道数据经过了篡改，这样便保证了数据在传输过程中不被篡改 —— 数据的完整性。
- 身份认证(Identification)：第三方不可能冒充身份参与通信，因为服务器配备了由证书颁发机构（Certificate Authority，简称CA）颁发的安全证书，可以证实服务器的身份信息，防止第三方冒充身份。（也有少数情况下，通信需要客户端提供证书，例如银行系统，需要用户在登录的时候，插入银行提供给用户的USB，就是需要客户端提供证书，用来验证客户的身份信息。）
HTTPS是什么？SSL/TLS是什么？
- HTTP协议(HyperText Transfer Protocol，超文本传输协议)是大家最熟悉的一种协议，它是一个用于传输超媒体文档的协议，它位于OSI网络协议模型的应用层。但是它是明文传输协议，是非常不安全的，容易被人篡改和窃取数据。
- SSL(Secure Socket Layer) —— 网景(Netscape)公司设计的主要用于web的安全传输协议。它位于TCP传输层协议和应用层协议之间。（它没有被划分在OSI网络协议模型中，且认为它是应用层的子层。）
- 众所周知，网景公司20世纪90年代在和微软的竞争中最终败下阵来，之后网景公司将SSL协议的管理权转交给IETF(Internet Engineering Task Force, www.ietf.org)。于是IETF将SSL作了标准化，重新命名为TLS(Transport Layer Security)。在1999年，TLS 1.0诞生了（其实也就是SSL 3.1）。
- HTTPS(HyperText Transfer Protocol Secure)是建立在SSL/TLS协议之上，信息通信通过SSL/TLS进行加密，最后一个S就是Secure的缩写，代表安全的意思，HTTPS = HTTP + SSL/TLS。
- 实际上现代的浏览器已经基本不使用SSL，使用的都是TLS，SSL 3.0于2015年已经寿终正寝 —— 各大浏览器也不支持了。但是由于SSL这个术语存在的时间太长，很多地方还是广泛的使用它，但是要清楚其实它说的是TLS。
- 有调查显示现在绝大部分浏览器（> 99.5%)都使用TLS 1.2或者TLS 1.3。只有不足1%的浏览器仍然使用TLS 1.0或者TLS 1.1。
- TLS 1.2仍然是主流协议（本文写于2020年初），相信将来逐渐TLS 1.3将会作为主流协议。
- 很多浏览器将会开始不支持TLS 1.0和1.1:
- Google将在Chrome 72中不推荐使用TLS 1.0和1.1，而Chrome 81之后将会完全不支持。
- Mozilla的Firefox，微软的Edge和IE以及苹果的Safari 都会分别于2020年逐渐移除对TLS 1.0和1.1的支持。
- 那么一些还在使用TLS 1.0和1.1的网站就得*升级到TLS 1.2或者TLS 1.3。
- 要关闭浏览器对TLS 1.0和1.1的支持，可以在Internet选项中修改：
SSL/TLS的工作原理
需要理解SSL/TLS的工作原理，我们需要掌握加密算法。加密算法有两种：对称加密和非对称加密：
- 对称加密：通信双方使用相同的密钥进行加密。特点是加密速度快，但是缺点是需要保护好密钥，如果密钥泄露的话，那么加密就会被别人破解。常见的对称加密有AES，DES算法。
- 非对称加密：它需要生成两个密钥：公钥(Public Key)和私钥(Private Key)。公钥顾名思义是公开的，任何人都可以获得，而私钥是私人保管的。相信大多程序员已经对这种算法很熟悉了：我们提交代码到github的时候，就可以使用SSH key：在本地生成私钥和公钥，私钥放在本地.ssh目录中，公钥放在github网站上，这样每次提交代码，不用麻烦的输入用户名和密码了，github会根据网站上存储的公钥来识别我们的身份。公钥负责加密，私钥负责解密；或者，私钥负责加密，公钥负责解密。这种加密算法安全性更高，但是计算量相比对称加密大很多，加密和解密都很慢。常见的非对称算法有RSA。
SSL/TLS是利用了对称加密和非对称加密的特点。先来看下整个SSL/TLS的握手过程，之后我们再分步骤详细解读，每一步都干了些什么。
1.当TCP建立连接之后，TLS握手的第一步由客户端发起，发送ClientHello的消息到服务器。
ClientHello消息包含：
- 客户端支持的SSL/TLS版本
- 客户端支持的加密套件(Cipher Suites)
- 会话Idsession id（如果有的值的话，服务器端会复用对应的握手信息，避免短时间内重复握手）
- 随机数client-random
延伸阅读：
加密套件名如：“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256”，这么长的名字看着有点晕吧，不用怕，其实它的命名非常规范，格式很固定。基本的形式是“密钥交换算法-服务身份验证算法-对称加密算法-握手校验算法”。
2.然后服务器端在收到这个ClientHello，从中选择服务器支持的版本和套件，发送ServerHello消息：
- 服务器所能支持的最高SSL/TLS版本
- 服务器选择的加密套件
- 随机数server-random
- 会话Idsession id(用于下次复用当前握手的信息，避免短时间内重复握手。)
随后服务器发送服务器的安全证书(含公钥)。
如果需要客户端也提供证书的话，还会发出客户端证书请求(Client Certificate Request)，只有少数金融机构才需要客户端也提供客户端证书。
此后客户端发送Server Hello Done消息表示Hello阶段完成。
3.客户端收到ServerHello后，会对收到的证书进行验证。
我们来看一下为什么可以通过CA(Certificate Authority，证书颁发机构)签发的证书来确认网站的身份？
当我们安装操作系统或者浏览器的时候，会安装一组可信任的CA（根证书CA包括GlobalSign、GeoTrust、Verisign等）列表。根CA如GlobalSign就在我们的可信任的CA列表里，你的浏览器或者操作系统含有GlobalSign的公钥。
先来看一下Google的证书，当你访问Google的时候，Google会发给你它的证书。证书中包含颁发机构的签名以及服务器的公钥。
浏览器首先用哈希函数对明文信息的摘要做哈希得到一个哈希值（用到的就是证书中的签名哈希算法SHA256），然后用根CA的公钥对根证书的签名作解密得到另一个哈希值（用到的算法就是RSA非对称算法），如果两个哈希值相等则说明证书没有被篡改过。当然还需校验证书中服务器名称是否合法以及验证证书是否过期。
这样就免受中间人攻击了，因为假如有中间人修改了证书的内容（如将证书中的公钥替换成自己的公钥），那么将获得不同的哈希值，从而两个哈希值不匹配导致验证失败。如果要绕过这个机制，中间人必须要也替换签名，使签名也相匹配。而做到这一点就需要破解到了根证书的密钥（而这是不可能的，中间人必然会失败）。浏览器会出现以下画面，告诉你正在遭受中间人攻击，因为证书被篡改了：
那聪明的你肯定也想到了，如果你开发了一个系统还在测试阶段，还没有正式申请一张证书，那么你可以为服务器自签名一张证书，然后将证书导入客户端的CA信任列表中。
信任链机制
可以看到证书路径是GlobalSign Root CA-R2 -> GTS CA 1O1->*.google.com。因为我们的浏览器信任GlobalSign Root CA，根据信任链机制，你相信了根CA颁发的证书，也要相信它签名的子CA颁发的证书，也要相信子CA签名的子子CA的证书…而我们通过一级级的校验，如果从根证书到最下层的证书都没有被篡改过，我们就相信最下层的这个服务器证书是合法的。所以在这个机制中，你就需要无条件的相信根证书的颁发机构。
如果通过验证，客户端生成一个随机数pre-master，用于密钥交换过程。
4.密钥交换过程：客户端用第三步中服务器的证书中拿到服务器的公钥，用这个公钥加密（算法是加密套件中的密钥交换算法，譬如ECDHE算法）生成密文发送给服务器。
5.客户端用server-random + client-random + pre-master一起计算出对称密钥master secret。
6.服务器收到第四步的信息之后，用服务器的私钥对密文进行解密得到密钥pre-master。
因为只有服务器有私钥，可以针对客户端发出的加密过的信息进行解密得到pre-master，这样就保证了只有服务器和客户端知道pre-master。服务器端也可以用server-random + client-random + pre-master一起计算出对称密钥master secret。
现在客户端和服务器均有密钥master secret了，后面就可以用它来进行加密和解密了。
为什么不能只用一个pre-master作为之后加密的对称密钥？
虽然只有服务器有私钥，能够解密pre-master呀，但仅用它作为master secret是不够安全的，这是因为要以防客户端的pre-master并不是随机数的情况。加上另外两个随机数client-random以及server-random（而这两个随机数和时间有相关性），这样就能保证最后生成的master secret一定是随机数。
7.客户端用master secret加密了一条握手完成的消息发送给服务器。
8.服务器端也回发了一条用master secret加密的握手完成的消息。
9.当两方都收到对方发送的握手消息之后，也成功解密后，就可以用master secret愉快的开始数据加密和解密了。
综上，整个握手过程主要是通过一系列步骤通过非对称加密的算法交换得到了master secret，这个步骤通常需要几百毫秒，但是就是这一顿猛操作之后使得只有服务器和客户端知道master secret。之后的通信又利用了高效的对称算法对所有信息进行加密和解密，虽然加密和解密也需要耗时耗流量，不过信息是完全不可能被别人篡改和破解的，这一点损耗还是值得的。
理解 HTTPS 的工作原理
HTTPS，也称作HTTP over TLS。 TLS的前身是SSL，TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。本文着重描述TLS协议的1.2版本。
下图描述了在TCP/IP协议栈中TLS(各子协议）和HTTP的关系
Credit: Kaushal Kumar Panday From: SSL Handshake and HTTPS Bindings on IIS
其中Handshake protocol，Change Ciper Spec protocol和Alert protocol组成了SSL Handshaking Protocols。
HTTPS和HTTP协议相比提供了
- 数据完整性：内容传输经过完整性校验
- 数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥
- 身份认证：第三方无法伪造服务端（客户端）身份
其中，数据完整性和隐私性由TLS Record Protocol保证，身份认证由TLS Handshaking Protocols实现。
总览
使用RSA算法的SSL握手过程是这样的：
Source: Keyless SSL: The Nitty Gritty Technical Details
- [明文] 客户端发送随机数client_random和支持的加密方式列表
- [明文] 服务器返回随机数server_random，选择的加密方式和服务器证书链
- [RSA] 客户端验证服务器证书，使用证书中的公钥加密premaster secret发送给服务端
- 服务端使用私钥解密premaster secret
- 两端分别通过client_random，server_random和premaster secret生成master secret，用于对称加密后续通信内容
证书（Digital certificate）
那么什么是证书呢？
证书中包含什么信息：
- 证书信息：过期时间和序列号
- 所有者信息：姓名等
- 所有者公钥
为什么服务端要发送证书给客户端？
--互联网有太多的服务需要使用证书来验证身份，以至于客户端（操作系统或浏览器等）无法内置所有证书，需要通过服务端将证书发送给客户端。
客户端为什么要验证接收到的证书？
中间人攻击
客户端<------------攻击者<------------服务端
伪造证书 拦截请求
客户端如何验证接收到的证书？
为了回答这个问题，需要引入数字签名（Digital Signature）。
+---------------------+
| A digital signature |
|(not to be confused |
|with a digital |
|certificate) | +---------+ +--------+
| is a mathematical |----哈希--->| 消息摘要 |---私钥加密--->| 数字签名 |
|technique used | +---------+ +--------+
|to validate the |
|authenticity and |
|integrity of a |
|message, software |
|or digital document. |
+---------------------+
将一段文本通过哈希（hash）和私钥加密处理后生成数字签名。
假设消息传递在Bob，Susan和Pat三人之间发生。Susan将消息连同数字签名一起发送给Bob，Bob接收到消息后，可以这样验证接收到的消息就是Susan发送的
+---------------------+
| A digital signature |
|(not to be confused |
|with a digital |
|certificate) | +---------+
| is a mathematical |----哈希--->| 消息摘要 |
|technique used | +---------+
|to validate the | |
|authenticity and | |
|integrity of a | |
|message, software | 对
|or digital document. | 比
+---------------------+ |
|
|
+--------+ +---------+
| 数字签名 |---公钥解密--->| 消息摘要 |
+--------+ +---------+
当然，这个前提是Bob知道Susan的公钥。更重要的是，和消息本身一样，公钥不能在不安全的网络中直接发送给Bob。
此时就引入了证书颁发机构（Certificate Authority，CA），CA数量并不多，Bob客户端内置了所有受信任CA的证书。CA对Susan的公钥（和其他信息）数字签名后生成证书。
Susan将证书发送给Bob后，Bob通过CA证书的公钥验证证书签名。
Bob信任CA，CA信任Susan 使得 Bob信任Susan，信任链（Chain Of Trust）就是这样形成的。
事实上，Bob客户端内置的是CA的根证书（Root Certificate），HTTPS协议中服务器会发送证书链（Certificate Chain）给客户端。
TLS协议
TLS协议包括TLS Record Protocol和TLS Handshake Protocol。总览中的流程图仅涉及到TLS Handshake Protocol。
TLS Record Protocol
在TLS协议中，有四种子协议运行于Record protocol之上
- Handshake protocol
- Alert protocol
- Change cipher spec protocol
- Application data protocol
Record protocol起到了这样的作用
- 在发送端：将数据（Record）分段，压缩，增加MAC(Message Authentication Code)和加密
- 在接收端：将数据（Record）解密，验证MAC，解压并重组
值得一提的是，Record protocol提供了数据完整性和隐私性保证，但Record类型（type）和长度（length）是公开传输的
Record Protocol有三个连接状态（Connection State），连接状态定义了压缩，加密和MAC算法。所有的Record都是被当前状态（Current State）确定的算法处理的。
TLS Handshake Protocol和Change Ciper Spec Protocol会导致Record Protocol状态切换。
empty state -------------------> pending state ------------------> current state
Handshake Protocol Change Cipher Spec
初始当前状态（Current State）没有指定加密，压缩和MAC算法，因而在完成TLS Handshaking Protocols一系列动作之前，客户端和服务端的数据都是明文传输的；当TLS完成握手过程后，客户端和服务端确定了加密，压缩和MAC算法及其参数，数据（Record）会通过指定算法处理。
其中，Record首先被加密，然后添加MAC（message authentication code）以保证数据完整性。
TLS Handshaking Protocols
Handshakeing protocols包括Alert Protocol，Change Ciper Spec Protocol和Handshake protocol。本文不会详细介绍Alert Protocol和Change Ciper Spec Protocol。
使用RSA算法的握手过程是这样的（已在总览中提到）
Source: Keyless SSL: The Nitty Gritty Technical Details
客户端和服务端在握手hello消息中明文交换了client_random和server_random，使用RSA公钥加密传输premaster secret，最后通过算法，客户端和服务端分别计算master secret。其中，不直接使用premaster secret的原因是：保证secret的随机性不受任意一方的影响。
除了使用RSA算法在公共信道交换密钥，还可以通过Diffie–Hellman算法。Diffie–Hellman算法的原理是这样的：
By Original schema: A.J. Han Vinck, University of Duisburg-Essen SVG version: Flugaal [Public domain], via Wikimedia Commons
使用Diffie–Hellman算法交换premaster secret的流程
Source: Keyless SSL: The Nitty Gritty Technical Details
小结：
TLS Handshaking Protocols协商了TLS Record Protocol使用的算法和所需参数，并验证了服务端身份；TLS Record Protocol在协商后保证应用层数据的完整性和隐私性。
TLS Handshaking Protocol的核心是在公开信道上传递premaster secret。
Q&A
为什么传输内容不直接使用非对称加密？
性能
HTTPS能保证正常连接？
no
There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support.
攻击者甚至可以直接丢弃双方的数据包。
服务端如何验证客户端身份？
通过Client Certificate
This message conveys the client’s certificate chain to the server; the server will use it when verifying the CertificateVerify message (when the client authentication is based on signing) or calculating thepremaster secret (for non-ephemeral Diffie- Hellman). The certificate MUST be appropriate for the negotiated cipher suite’s key exchange algorithm, and any negotiated extensions.
Alert protocol有什么作用？
Closure Alerts：防止Truncation Attack
In a truncation attack, an attacker inserts into a message a TCP code indicating the message has finished, thus preventing the recipient picking up the rest of the message. To prevent this, SSL from version v3 onward has a closing handshake, so the recipient knows the message has not ended until this has been performed.
Error Alerts：错误处理
master secret是如何计算的
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
[0..47];
加密，压缩和MAC算法参数是如何计算的
Handshaking Protocols使得客户端和服务端交换了三个参数：client_random，server_random和master_secret，通过以下算法生成算法所需要的参数
To generate the key material, compute
key_block = PRF(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.`server_random ` +
SecurityParameters.`client_random`);
until enough output has been generated. Then, the key_block is
partitioned as follows:
client_write_MAC_key[SecurityParameters.mac_key_length]
server_write_MAC_key[SecurityParameters.mac_key_length]
client_write_key[SecurityParameters.enc_key_length]
server_write_key[SecurityParameters.enc_key_length]
client_write_IV[SecurityParameters.fixed_iv_length]
server_write_IV[SecurityParameters.fixed_iv_length]
The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key
使用Diffie-Hellman算法的TLS握手细节
5分钟图解HTTPS加密原理，SSL/TLS尽在掌握！
互联网时代，我们无时不刻沉浸在网络的浪潮。不知道大家是否注意到，在访问一写涉及到支付/金融/登录/网购等敏感业务时，会发现这些网站都会被重定向到https:// 的 URL ，比如：
- 地址为绿色, 表示使用了加密传输，安全且可信任;
- 地址为红色, 则表示虽然开启了加密, 但网站身份未验证, 不保证中间不会被人篡改。
从我们在地址栏敲下 https:// 网站那一刹那, 到内容显示到我们面前, 中间经过了哪些过程了? 浏览器根据什么来判断, 当前网站网址是安全的还是未验证的? 今天就跟大家一起探索互联网外交安全策略SSL/TLS协议运行机制。
SSL/TLS协议的由来
由来
最早期的通信是不使用SSL/TLS的HTTP通信，也就是没有加密的通信。在人们的信息传递过程中存在了很多的问题：被第三方窃听，被第三方修改通信内容，被第三方冒充他人身份参与通信。种种信息安全问题得到大家的重视。大家都希望能有一种加密的信息传输，能够保证信息安全，SSL/TLS协议诞生。
历史发展
互联网加密通信协议的历史，几乎与互联网一样长：
1994年，NetScape公司设计了SSL 1.0版，但是未发布；
1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞；
1996年，SSL 3.0版问世，得到大规模应用；
1999年，互联网工程任务组（IETF）标准化了一种名为TLS的新协议，这是SSL的升级版本；
2006年和2008年，TLS两次升级，分别更新至TLS 1.1和TLS 1.2。紧接着2011年发布了TLS 1.2的修订版；
TLS 1.3的最终版本于2018年8月发布，包含许多安全性和性能改进。
由此可见，SSL和TLS简单地可以理解为是同一种协议的不同版本，故它们总是成对出现。
SSL/TLS在TCP/IP参考模型中的位置
SSL/TLS其实是一个协议族而非单个协议，由SSL/TLS握手协议、修改密文协议、报警协议以及记录协议四部分组成。
SSL/TLS协议自身可分为两层：主要的有SSL记录协议和SSL握手协议。
SSL记录协议建立在可靠的传输协议，如TCP之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
SSL握手协议建立在SSL记录协议之上，用于在实际的数据传输开始前，通信双方进行身份认证、协商交换密钥等。
SSL/TLS如何实现安全保障呢
使用SSL/TLS协议，能够使我们在互联网上的通信做到“看不懂、改不掉、仿不了”，这组安全协议真的很复杂！分别对信息安全的机密性、完整性和可认证性做了确认。
机密性：当通信双方确信没有人能够理解他们的对话内容时，通信被认为是保密的。使用对称加密可以实现通信的机密性。
完整性：SSL/TLS具有校验机制，握手协议中定义了MAC，一旦信息被篡改，通信双方会立即发现并采取措施。
可认证性：为防止恶意攻击者冒充合法网站，网站需要通过证书和公钥加密来向Web浏览器证明自己的身份，在此过程中，浏览器需要两件事情来信任证书：证明另一方是证书的持有者，并证明证书是可信的。
在互联网通信中，通过建立共享密钥和证明证书的所有权的过程来实现机密性和可认证性，SSL/TLS协议则是通过“握手”流程来实现这两点，当中的完整性是由握手协议定义的MAC来实现。那么，如此至关重要的“握手”流程是怎么样的呢？
详解“握手”流程
"握手阶段"涉及四次通信，我们一个个来看。需要注意的是，"握手阶段"的所有通信都是明文的。
客户端发出请求（ClientHello）
客户端向服务器发出请求，会带上以下信息：
- 一个客户端生成的随机数
- 支持的加密方式，即图中的Cipher Suite
- 支持SSL/TLS协议的版本号
- Session ID，如果是之前断开的会话，会带上Session ID用来恢复会话。
- 签名使用的哈希算法
服务器回应（SeverHello）
服务器响应客户端的请求，如果上一步带上了Session ID，则直接恢复会话，否则带上以下信息给客户端：
- 选择SSL/TLS协议版本号
- 选择加密方式
- 一个服务器生成的随机数
- 服务器证书
客户端会在这里校验服务器证书的合法性，包括检测证书有效时间，以及证书中域名与当前会话域名是否匹配，并沿着信任链查找顶层证书颁发者是否是操作系统信任的CA机构。
客户端回应
客户端校验服务器证书的合法性，生成premaster secret，向服务器发送以下信息：
- 用服务器证书取出的公钥加密后的premaster secret，这里的premaster secret其实是另一个随机数
- 加密约定改变通知，通知服务器，以后的通信都适用协商好的加密方法和密钥进行加密
- 客户端握手结束通知。这个报文也是验证消息，是前面发送的所有内容的哈希值，用来供服务器校验。
服务器最后确认
这是握手过程的最后一步，服务器会把以下信息发送给客户端：
- 加密约定改变通知，通知客户端，以后的通信都适用协商好的加密方法和密钥进行加密
- 服务器握手结束通知，该报文也作为校验消息，供客户端验证。
到这个时候，客户端和服务器同时拥有了3个随机数，使用这三个随机数生成的密钥，将被用于后续通信的对称加密。
题外话
1.如何保证公钥属于被访问的合法网站？
将公钥放在数字证书中，签发证书的CA是被信任的，故公钥是被信任的。
2.为什么要这么复杂地产生会话密钥，何不直接传输商定好的密钥更方便？
随着攻击手段的不断发展，任何传输过程都不受信任，即使将会话密钥进行加密传输，都有被窃取的危险。因此采用Diffle-Hellman密钥协商算法，在传输过程中能够始终不出现会话密钥本身，会话密钥仅在握手结束时在客户端和服务器本地各自生成。
3.既然产生对称的会话密钥很复杂，为什么不采用可避免密钥泄露问题的公钥加密？
因为公钥加密相比于对称加密，计算速度很慢，不适用于通信时的大量数据加密。
4.在握手过程中如何确认服务器是私钥持有者？
客户端无法看见服务器的私钥，那就让服务器证明它可以使用私钥即可，服务器使用私钥对客户端已知的信息进行数字签名，若客户端能够用服务器的公钥认证该数字签名，则可确定对方持有相应私钥。