https加密流程

❶ https如何进行加密传输

HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议，更是一件经过艺术家精心设计的艺术品，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的具体描述如下：
1.浏览器将自己支持的一套加密规则发送给网站。
2.网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。
3.浏览器获得网站证书之后浏览器要做以下工作：
a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
c) 使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。
4.网站接收浏览器发来的数据之后要做以下的操作：
a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
b) 使用密码加密一段握手消息，发送给浏览器。
5.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。另外，HTTPS一般使用的加密与HASH算法如下：
非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256

❷ https交互过程

https的交互过程如下：
1、客户端将它所支持的老并算法列表和一个用作产生密钥的随机数发送给服务器。
2、服务器从算法列表中选择一种加密算法，并将它和一份包含服务器公用密钥的证书发送给客户端;该证书还包含了用于认证目的的服务器标识，服务器同时还提供了一个用作产生密钥的随机数。
3、客户端对服务器的证书进行验证，并抽取服务器的公用密钥;然后，再产生一个称作pre_master_secret的随机密码串，并使用服务器的公用密钥对其进行加密(参考非对称加/解密)，并将加密后的信息发送给服务器;
4、客户端与服务器端根据pre_master_secret以及客户端与服务器的随机数值独立计算出加密和MAC密钥知含晌搭锋;
5、客户端将所有握手消息的MAC值发送给服务器;
6、服务器将所有握手消息的MAC值发送给客户端。

❸ HTTPS 加密算法过程

1、HTTP 协议（HyperText Transfer Protocol，超文本传输协议）：是客户端浏览器或其他程序与Web服务器之间的应用层通信协议 。

2、HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：可以理解为HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL，用于安全的 HTTP 数据传输。

3、SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。

4、TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）。

如上图所示 HTTPS 相比 HTTP 多了一层 SSL/TLS。

1、对称加密

有流式、分组两种，加密和解密都是使用的同一个密钥。

例如：DES、AES-GCM、ChaCha20-Poly1305等

2、非对称加密

加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的。非对称加密算法性能较低，但是安全性超强，由于其加密特性，非对称加密算法能加密的数据长度也是有限的。

例如：RSA、DSA、ECDSA、 DH、ECDHE

3、哈希算法

将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多，且算法不可逆。

例如：MD5、SHA-1、SHA-2、SHA-256 等

4、数字签名

签名就是在信息的后面再加上一段内容（信息经过hash后的值），可以证明信息没有被修改过。hash值一般都会加密后（也就是签名）再和信息一起发送，以保证这个hash值不被修改。

C++音视频开发学习资料 ：点击 音视频开发（资料文档+视频教程+面试题）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）

HTTP协议在浏览器/服务器间进行数据的传输是明文的，不做任何的加密，通俗来说，就是“裸奔”，这样会产生什么样的问题那，我们来举一个例子：

在这里插入图片描述

上述我们通过两个人物模仿了服务器和客户端的交互，我们可以看出，小明和小花之间进行数据通信的时候采用的是明文传输的、那么此时很有可能被中间人获取信息、并进行数据篡改，这种行为就叫 中间人攻击。

所以 HTTP 传输面临的风险有：

（1） 窃听风险：黑客可以获知通信内容。

（2） 篡改风险：黑客可以修改通信内容。

（3） 冒充风险：黑客可以冒充他人身份参与通信。

哈哈、此时你是不是不能很愉快的上网冲浪了呀，别担心，我们此时可以对明文进行加密：

这样是不是比原来安全多了呀！但是这样就足够安全了吗？显然不是的，如果小明和小花在第一次聊天的时候，信息被中间人截取到了，那么中间人是不是也就有密钥了，同样可以对数据进行加解密和修改了那

这可怎么办那？ 加密的数据还是不安全的啊？ 别急，上面我们采用的是对称加密（换句话说就是我们发送的密钥技能加密、也能解密，那么中间人只要拿到密钥消息对他而言就是透明的了），我们还可以采用非对称加密方式进行加密数据(非对称加密一般都会有一个私钥和公钥组成。可以通过公钥加密，私钥解密，也可以通过私钥加密，公钥解密两种方式) ，对密钥的传送在格外加一层保护，当小明和小花在建立通信的时候，小花会把公钥KEY发送给小明，当小明拿到公钥KEY 后，会自己生成一个 密钥 KEY2 , 并用 KEY 对KEY2 进行加密（此时小明用的是公钥加密）

在通信过程中，即使中间人一开始就获取到了公钥KEY ,但是他不知道私钥，就对数据无法进行解密，仍旧是没办法获取KEY2。这样加密后，数据是不是就安全多了呀。这种情况下就可以和妹子愉快的进行聊天了吗？别急、所谓道高一尺魔高一丈，常言道：流氓不可怕，就怕流氓有文化。这种状态下我们的数据，相当来说是比较安全的，但是如果此时中间人获取公钥后，发送给小明一个伪公钥，又会产生什么问题那？

好吧，说到这里，大家是不是快恨死这个中间人了啊，哈哈~~~还有据俗话别忘记了，魔高一尺道高一丈，对于这种情况。我们可以借助与第三方证书平台，证书平台具备产生证书的功能，服务器（小花）可以去证书机构申请证书，证书机构通过小花提供的信息（网址、机构、法人等、公钥），生成公钥和私钥（证书机构的），通过私钥进行数据的非对称加密生成证书、将证书颁发给小花。那么此时小花就可以在进行数据交互的时候，传递证书了。

小明只需要知道证书的发证机构、就可以很方便的获取到证书的公钥、从而对证书进行校验并获取公钥、然后进行后续的操作。

那么此时小伙伴是不是又有疑问了，如果 中间人 获取到证书、并伪造证书给小明、怎么破？？？

不错不错、如果大家有这个想法的话，说明大家都在认真思考了。那么我们假设中间人获取到了证书、中间人也可以在证书机构获取公钥，并通过证书机构公钥获取 服务器发送的公钥，中间人此时也可以自己生成公钥，并向证书机构申请证书、并发送伪证书给小明，但是因为证书是经过签名认证的，包含（网址、机构、法人等、公钥）等信息，小明在拿到伪证书后，通过证书公钥很容易就发现证书是不合法的(网址、法人的信息可定不符，否则申请不到证书的)。

上述我们分享的内容就是HTTPS的主体思想，HTTPS增加了SSL安全层，上述介绍的所有认证流程都是在SSL安全层完成验证的。今天我就分享HTTPS的实现原理就说这么多了。 ﹏

HTTPS 缺点：

（1）SSL 证书费用很高，以及其在服务器上的部署、更新维护非常繁琐。

（2）HTTPS 降低用户访问速度（多次握手）。

（3）网站改用HTTPS 以后，由HTTP 跳转到 HTTPS 的方式增加了用户访问耗时（多数网站采用302跳转）。

（4）HTTPS 涉及到的安全算法会消耗 CPU 资源，需要增加大量机器（https访问过程需要加解密）。

❹ https传输过程

HTTPS传输过程主要涉及到对称加密和非对称加密两种方式，对称加密用来加密数据内容，非对称加密用来加密对称加密的秘钥。

加密和解密使用相同的密钥

使用公钥进行加密，私钥进行解密；私钥加密的话就使用公钥解密

A向B发送消息 使用B的公钥进行加密 B收到密文后使用自己的私钥进行解密 反之亦然

https协议采用的就是这种加密方式

为了解决在对称加密/非对称加密中公钥被窃取的情况。

A先生成一个对话密钥，然后把对话密钥发送给B。但是这个对话密钥要经过B的公钥进行加密，B收到后用自己的私钥进行解密。这样就解决了对称加密时公钥容易被截取的缺陷。

实际上就是对称加密的密钥进行非对称加密

B的公钥是在最开始连接建立的时候发送给A的。假如这个时候有一个中间人截取了B的公钥，然后将自己的公钥发送给A。A在给B发送消息时，想用B的公钥进行加密。但实际上用的是中间人的公钥。中间人截取了A给B发送的消息，然后用自己的私钥解密。就可以随意读取消息的内容。
此外，中间人也可以使用B的公钥来加密一些消息传输给B，让B以为中间人就是A

用于防止中间人攻击

数字证书是由专业的机构颁发的CA（Certificate Authority）机构

CA机构通过服务端提供的相关信息生成证书，证书的主要内容有：公钥（Public Key）、ISSUER（证书的发布机构）、Subject（证书持有者）、证书有效期、签名算法、指纹及指纹算法。

数字证书是如何保证公钥来自请求的服务器呢？数字证书上由持有人的相关信息，通过这点可以确定其不是一个中间人；但是证书也是可以伪造的，如何保证证书为真呢？

浏览器接收到证书以后，就要开始进行验证工作了。首先从证书中得知证书的颁发机构，然后从浏览器系统中去寻找此颁发机构的根证书。上面我们也看到，世界上权威CA机构的根证书都是预先嵌入到浏览器中的，如果在浏览器系中没有找到对应的根证书，就代表此机构不是受信任的，那么就会警告无法确认证书的真假，比如以前打开12360网站就会提示，现在不会了

如果我们找到了证书颁发机构的根证书，那么就从根证书中取得那个根公钥，用根公钥去解密此证书的数字签名，成功解密的话就得到证书的指纹和指纹算法，指纹是证书内容通过指纹算法计算得到的一个hash值，这里我们称之为h1，h1代表证书的原始内容；然后用指纹算法对当前接收到的证书内容再进行一次hash计算得到另一个值h2，h2则代表当前证书的内容，如果此时h1和h2是相等的，就代表证书没有被修改过。如果证书被篡改过，h2和h1是不可能相同的，因为hash值具有唯一性，不同内容通过hash计算得到的值是不可能相同的

有人说假如证书上的指纹是不法分子伪造的，伪造是没有用的，因为你伪造的指纹不可能用CA机构的根私钥去加密（根私钥是CA机构绝对保密的），伪造者只能拿自己的秘钥去加密这个伪造的指纹，但当我们拿机构的根公钥去解密伪造指纹的时候是不可能成功的（加密内容只能由一对公钥私钥解密）

在证书没有被修改过的基础上，再检查证书上的使用者的URL（比如csdn.net）和我们请求的URL是否相等，如果相等，那么就可以证明当前浏览器链接的网址也是正确的，而不是一些钓鱼网之类的

但如果浏览器的连接被某个中间人截取了，中间人也可以发一个由权威的CA机构颁发的证书给浏览器，然后也可以通过证书没有被篡改的验证，但是在证书没有被篡改的前提下，通过对比证书上的URL和我们请求的URL是否相同，我们还是可以判断当前证书是不是服务器发的证书。可以这么理解，因为URL具有唯一性，所以中间人的证书的上的URL和我们的证书的URL是不可能相同的，如果中间人修改了自己证书上的URL，那么就通过不了证书没有被篡改的验证，所以中间人的证书也是欺骗不了我们的

到这里我们认证了三点信息：

https就是在http和tcp之间加入了一层SSL层。https的安全基础就是ssl。

https协议就是由http+ssl组成的可以进行加密传输和身份认证的网络协议。https的作用：

所以在证书验证阶段使用的是非对称加密（即生成会话密钥的阶段），在内容传输的时候还是对称加密

握手阶段我们需要注意三点：

从上面可以得知，整个会话过程中（包括握手以及之后的数据传输）服务器的公钥和私钥只用到了一次

❺ 网站如何添加https：//加密认证教程

网站想实现https加密访问，必须申请部署SSL证书。SSL证书的申请流程如下：

第一步，生成并提交CSR（证书签署请求）文件

CSR文件一般都可以通过在线生成（或服务器上生成），申请人在制作的同时系统会产生两个秘钥，公钥CSR和密钥KEY。选择了SSL证书申请之后，提交订单并将制作生成的CSR文件一起提交到证书所在的CA颁发机构。

第二步，CA机构进行验证

CA机构对提交的SSL证书申请有两种验证方式：

第一种是域名认证。系统自动会发送验证邮件到域名的管理员邮箱（这个邮箱是通过WHOIS信息查询到的域名联系人邮箱）。管理员在收到邮件之后，确认无误后点击我确认完成邮件验证。所有型号的SSL证书都必须进行域名认证。

第二种是企业相关信息认证。对于SSL证书申请的是OV SSL证书或者EV SSL证书的企业来说，除了域名认证，还得进行人工核实企业相关资料和信息，确保企业的真实性。

第三步，CA机构颁发证书

由于SSL证书申请的型号不同，所验证的材料和方式有些区别，所以颁发时间也是不同的。

如果申请的是DV SSL证书最快10分钟左右就能颁发。如果申请的是OV SSL证书或者EV SSL证书，一般3-7个工作日就能颁发。
等SSL证书颁发之后，将其正确部署到服务器上就可以实现https加密访问了。

❻ https是如何加密的

HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，且看下图。

1. 客户端发起HTTPS请求

这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

2. 服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3. 传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4. 客户端解析证书

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5. 传送加密信息

这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6. 服务段解密信息

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息

这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

8. 客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

❼ 基于国密算法SM2 SSL证书的https加密, 如何实现

SSL握手协议的过程
国密SSL握手协议过程如下：
(1)交换Hello消息来协商密码套件，交换随机数，决定是否会话重用；
(2)交换必要的参数，协商预主密钥
(3)交换证书信息，用于验证对方
(4)使用预主密钥和交换的随机数生成主密钥
(5)向记录层提供安全参数
(6)验证双方计算的安全参数的一致性、握手过程的真实性和完整性