当前位置：首页 > 前端 > 正文内容

经得住拷问的HTTPS原理解析

放牧的风4年前 (2021-03-24)前端1232

此文涵盖的大致内容：

理解HTTPS原理的概念
什么是对称加密和非对称加密？
什么是数字签名？怎么生成？怎么校验？
啥时候是对称加密？啥时候是非对称加密？啥时候进行算法加密？什么算法？
第三方机构包含哪些？
HTTPS 是什么？具体流程
HTTPS和HTTP的区别
现在网站为什么不都用HTTPS？

HTTPS 是在 HTTP 和 TCP 之间建立了一个安全层，HTTP 与 TCP 通信的时候，必须先进过一个安全层，对数据包进行加密，然后将加密后的数据包传送给 TCP，相应的 TCP 必须将数据包解密，才能传给上面的 HTTP。

一、基本概念及理解

TLS/SSL 的功能实现主要依赖于三类基本算法

散列函数、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

非对称加密是实现身份认证和密钥协商；

对称加密是对信息进行加密；

SSL和TLS的区别？

SSL和TLS都是加密协议，有网络请求的地方就可以使用这两种协议在传输层进行加密，确保数据传输的安全，SSL是TLS的前身，网景在1995年发布了直接发布了SSL 2.0版本，1.0版本没有对外发布。由于漏洞的原因，版本2.0也只是昙花一现，网景在1996年就发布了SSL3.0。随后在1999年的时候，基于SSL3.0版本，网景发布了TLS1.0版本(虽然TLS1.0在SSL3.0基础上的改动不太大，但是这些改动都是非常重要的)。

我们现在应该使用TLS协议，因为在2011年和2015年的时候SSL2.0和SSL3.0就已经分别被弃用了，而且由于漏洞的缘故，如果你的服务器配置了SSL的协议，还得手动将他们禁用掉。所以我们只给服务器配置TLS协议就好了，有的服务对TLS版本有要求，你可以在SSL Server Test查看服务器的证书及协议等配置。

现在TLS主流版本是1.2。

SSL/TLS协议和证书的关系

为保证网络安全，我们需要给服务器颁发证书，这个证书可以自己生成，但是自己颁发证书是不安全的，可以被别人伪造，所以我们一般都是在第三方认证机构购买证书 。那么问题来了，证书到底和协议是否有关联，我们是否需要区分SSL证书和TLS证书呢？答案是否定的，证书不依赖协议，和协议没有太大关联，我们也不需要去纠结是使用SSL证书和TLS证书，协议由服务器配置决定，证书是配合协议一块使用的。

私钥、公钥、对称密钥的区别？分别是什么？

对称密钥只有一个,可以是字符串,也可以是数字,对应的加密方法是对称加密。

公钥和私钥成对出现.公开的密钥叫公钥，只有自己知道的叫私钥

举个例子:
A,B双方准备进行系统间的通信，基于安全的考虑，采用数据加密通信。这时候，A有自己的公私钥，分别是A公和A私，B也有自己的公私钥，分别是B公和B私。通信前，双方需要交换公钥，这时候，A手上的密钥有:A私和B公，B手上的密钥有:B私和A公
通信时，A使用B公进行敏感信息的加密，使用A私签名。B收到信息后，使用B私进行敏感信息解密，使用A公进行验签。反之亦然。

从上面可以总结:

1.公钥和私钥成对出现.公开的密钥叫公钥，只有自己知道的叫私钥 2.公钥用于敏感信息的加密,私钥用于签名.所以公钥的作用是保证数据安全,私钥的作用的标记信息的发送方.

3.用公钥加密的数据只有对应的私钥可以解密,用私钥签名只有对应的公钥可以验签.

4.用公私钥加解密的方式叫作非对称加密.

5.其实通信双方使用同一对公私钥也是可以的.

对称加密

这种方式加密和解密同用一个密钥。加密和解密都会用到密钥。以对称加密方式加密时必须将密钥也发给对方。

Q1：许许多多的客户端，不可能都用同一秘钥进行信息加密，该怎么办呢？

解决办法：一个客户端使用一个密钥进行加密

Q2：既然不同的客户端使用不同的密钥，那么对称加密的密钥如何传输？

解决办法：只能是「一端生成一个秘钥，然后通过HTTP传输给另一端」

Q3：这个传输密钥的过程，又如何保证加密？「如果被中间人拦截，密钥也会被获取,」那么你会说对密钥再进行加密，那又怎么保存对密钥加密的过程，是加密的过程？

解决办法：非对称加密

为什么使用非对称加密

以对称加密方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落人攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥，所以使用非对称加密。

非对称加密

采用的算法是RSA、ECC、DH等

加密使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

具体做法

发送密文的一方使用公钥进行加密处理“密钥”，对方收到被加密的信息后，再使用自己的私有密钥进行解密。这样可以确保交换的密钥是安全的前提下，之后使用对称加密方式进行通信交换报文。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

非对称加密，有以下特点：

有一对秘钥，【公钥】和【私钥】。
公钥加密的内容，只有私钥可以解开，私钥加密的内容，所有的公钥都可以解开，这里说的【公钥都可以解开，指的是一对秘钥】。
公钥可以发送给所有的客户端，私钥只保存在服务器端。
信息传输一对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信。

非对称加密，有以下缺点：

公钥是公开的，所以针对私钥加密的信息，黑客截获后可以使用公钥进行解密，获取其中的内容；
公钥并不包含服务器的信息，使用非对称加密算法无法确保服务器身份的合法性，存在中间人攻击的风险，服务器发送给客户端的公钥可能在传送过程中被中间人截获并篡改；
使用非对称加密在数据加密解密过程需要消耗一定时间，降低了数据传输效率；

对称加密和非对称秘钥的区别：

对称加密需要发送生成的秘钥给对方；非对称加密不需要发送用来解密的私有秘钥。
安全性：对称加密发送秘钥容易落入攻击者之手，这样就失去了加密的意义；非对称加密的公开秘钥可以随意发布，任何人都可以获得
对称加密的好处是解密的效率比较快；非对称加密的好处是可以使得传输的内容不能被破解，因为就算你拦截到了数据，但是没有对应的私钥，也是不能破解内容的

对称加密+非对称加密（HTTPS采用这种方式）

HTTPS将对称加密与非对称加密结合起来，充分利用两者各自的优势。在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

具体做法是：发送密文的一方使用公钥进行加密处理“密钥”，对方收到被加密的信息后，再使用自己的私有密钥进行解密。这样可以确保交换的密钥是安全的前提下，之后使用对称加密方式进行通信交换报文。所以，HTTPS采用对称加密和非对称加密两者并用的混合加密机制。

CA认证和第三方认证有什么区别

第三方认证是指与交易双方没有切实的利益关系并被国家认可授权的有资历审核认证的单位，包括很多如，CA认证、CE认证、QA/QC认证等等。拿CE认证来说，产品要想在欧盟市场上自由流通，就必须经国CE认证，加贴“ CE ”标志，以表明产品符合欧盟《技术协调与标准化新方法》指令的基本要求，这是欧盟法律对产品提出的一种强制性要求。

CA认证是CA中心进行的认证。CA（Certificate Authority），称为电子商务认证中心，是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。CA认证是第三方认证的一种，应用于电子商务方面。

附：我觉得第三方认证也可以叫做第三方数字证书认证

二、数字签名 + 第三方认证

数据无法被解密，但可能被篡改，解决报文可能遭篡改问题 —— 比对数字签名

网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？那就是校验数字签名。

先普及摘要的含义：对需要传输的文本，做一个HASH计算（SHA1，SHA2）

数字签名如何生成

一段文本 ----hash函数----》消息摘要 ----私钥加密----》数字签名

将一段文本先用Hash函数生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文一起传送给接收者。接下来就是接收者校验数字签名的流程了。

其实此处的发送者就是Sever，接受者是Client。

校验（比对）数字签名流程

收到原文和数字签名之后，需要比对校验。

步骤：
1. 数字签名 ----发送者的公钥解密----》 消息摘要1   
2. 原文  ----hash函数----》 消息摘要2   
3. 消息摘要1 与 消息摘要2 比对

如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，
否则说明信息被修改过，因此数字签名能够验证信息的完整性。复制代码

接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。

举个例子：假设消息传递在Kobe，James两人之间发生。James将消息连同数字签名一起发送给Kobe，Kobe接收到消息后，通过校验数字签名，就可以验证接收到的消息就是James发送的。当然，这个过程的前提是Kobe知道James的公钥。问题来了，和消息本身一样，公钥不能在不安全的网络中直接发送给Kobe，或者说拿到的公钥如何证明是James的？

此时就需要引入了证书颁发机构（Certificate Authority，简称CA），CA数量并不多，Kobe客户端内置了所有受信任CA的证书。CA对James的公钥（和其他信息）数字签名后生成证书。

为什么是发送者的公钥？请求公钥的过程是数字签名的过程还是校验数字签名的过程？

下面的【数字证书认证机构的业务流程】能给与答案，请继续看。

解决通信方身份可能被伪装的问题 —— 数字证书（第三方认证）

客户端无法识别传回公钥是中间人的，还是服务器的，也就是客户端可能拿到的公钥是假的，这是问题的根本，我们可以通过某种规范可以让客户端和服务器都遵循某种约定，那就是通过「第三方认证的方式」

数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。

数字证书认证机构的业务流程

服务器的运营人员向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;
CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
如信息审核通过，CA会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名; 【数字签名生成的过程】
客户端 Client 向服务器 Server 发出请求时，Server 返回证书文件;
客户端 Client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。【校验数字签名的过程】
客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。

如果仅仅是第三方认证，没有数字签名（只是对网站信息进行第三方机构私钥加密）

第三方认证机构是一个公开的平台，中间人可以去获取。

数字签名：将网站的信息，通过特定的算法加密，比如MD5,加密之后，再通过服务器的私钥进行加密，形成「加密后的数字签名」。

可能会发生以下情况

从上面我们知道，因为没有比对过程，所以中间人也向第三方认证机构进行申请，然后拦截后把所有的信息都替换成自己的，客户端仍然可以解密，并且无法判断这是服务器的还是中间人的，最后造成数据泄露

数字签名的作用

能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
数字签名能确定消息的完整性,证明数据是否未被篡改过。

Client是如何去对比两者数字签名的呢？

浏览器会去安装一些比较权威的第三方认证机构的公钥，比如VeriSign、Symantec以及GlobalSign等等。
验证数字签名的时候，会直接从本地拿到相应的第三方的公钥，对私钥加密后的数字签名进行解密得到真正的签名。
然后客户端利用签名生成规则进行签名生成，看两个签名是否匹配，如果匹配认证通过，不匹配则获取证书失败。

小结

CA是颁发证书机构（Certificate Authority）的简称
客户端会内置信任CA的证书信息(包含公钥)，服务端返回的证书中有申请者公钥。
证书的合法性取决于对比信息摘要
CA是否信任依赖于客户端内置信任的CA
公钥是从服务器请求来的
数字签名的生成：网站信息通过特定的算法加密，比如MD5，加密之后，用第三方机构的私钥（Server的私钥）再次加密
数字证书包含两个特别重要的信息：网站公钥、数字签名
通信方身份可能被伪装 —— 第三方证书
数据无法被解密，但可能被篡改，解决报文可能遭篡改问题 —— 校验数字签名
如果仅仅是第三方认证，没有数字签名（只是对网站信息进行第三方机构私钥加密），造成数据泄露，所以HTTPS通过【证书 + 数字签名】来保证安全

三、HTTPS工作流程（TLS 1.2 握手过程）

Client发起一个HTTPS请求，连接443端口。这个过程可以理解成是【请求公钥的过程】。
Server端收到请求后，会把申请好的数字证书（也可以认为是公钥证书）返回给Client。
浏览器安装后会自动带一些权威第三方机构公钥，使用匹配的公钥对数字签名进行解密。根据签名生成的规则对网站信息进行本地签名生成，然后两者比对【（解密后的签名和对网站信息用hash函数生成的签名比对，其实这也是数字签名校验的过程，上面写的数字签名校验实例没有经过CA）】。通过比对两者签名，匹配则说明认证通过【（也可以说是证书合法，并且客户端内置的CA是信任的）】，不匹配则获取证书失败。
在安全拿到服务器公钥后，客户端Client使用伪随机数生成器随机生成一个对称密钥，使用【服务器公钥】（证书的公钥）加密这个【对称密钥】，发送给Server(服务器)。

5.服务器Server通过自己的私钥，对信息解密，至此得到了【对称密钥】，此时两者都拥有了相同的【对称密钥】，接下来，就可以通过该对称密钥对传输的信息加密/解密啦。

Server使用对称密钥加密“明文内容A”，发送给Client。
Client使用对称密钥解密响应的密文，得到“明文内容A”。
Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”。

请求到的公钥的作用：

解密数字签名（匹配的公钥是服务器拿到的跟浏览器自带的第三方机构公钥匹配成功的公钥）
加密Client使用伪随机数随机生成的一对称秘钥（这步骤开始对称加密，把对称秘钥发送给Server，这个步骤经过非对称加密之后变成安全的了）

HTTPS工作中啥时候是非对称加密，啥时候是对称加密？

Server安全拿到对称秘钥之后，也就是Client和Server都拥有了相同的【对称秘钥】之后，开始对称加密；认之前是非对称加密。换句话说，在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

四、HTTP 与 HTTPS 的区别

HTTP 是明文传输协议，HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。
HTTPS比HTTP更加安全，对搜索引擎更友好，利于SEO,谷歌、百度优先索引HTTPS网页;
HTTPS需要用到SSL证书，而HTTP不用【（HTTPS是安装SSL的服务器，HTTP是未安装SSL的服务器）】;
HTTPS标准端口443，HTTP标准端口80;
HTTPS基于传输层，HTTP基于应用层;
HTTPS在浏览器显示绿色安全锁，HTTP没有显示;

五、既然HTTPS那么安全可靠，那为何不所有的Web网站都使用HTTPS

首先，很多人还是会觉得HTTPS实施有门槛，这个门槛在于需要权威CA颁发的SSL证书。从证书的选择、购买到部署，传统的模式下都会比较耗时耗力。
其次，HTTPS普遍认为性能消耗要大于HTTP，因为与纯文本通信相比，加密通信会消耗更多的CPU及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。但事实并非如此，用户可以通过性能优化、把证书部署在SLB或CDN，来解决此问题。举个实际的例子，“双十一”期间，全站HTTPS的淘宝、天猫依然保证了网站和移动端的访问、浏览、交易等操作的顺畅、平滑。通过测试发现，经过优化后的许多页面性能与HTTP持平甚至还有小幅提升，因此HTTPS经过优化之后其实并不慢。
除此之外，想要节约购买证书的开销也是原因之一。要进行HTTPS通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。
最后是安全意识。相比国内，国外互联网行业的安全意识和技术应用相对成熟，HTTPS部署趋势是由社会、企业、政府共同去推动的。