客户端服务器对称加密方案

❶ ssl用哪些加密算法，认证机制

SSL是一个安全协议，它提供使用 TCP/IP 的通信应用程序间的隐私与完整性。因特网的 超文本传输协议（HTTP）使用 SSL 来实现安全的通信。

在客户端与服务器间传输的数据是通过使用对称算法（如 DES 或 RC4）进行加密的。公用密钥算法（通常为 RSA）是用来获得加密密钥交换和数字签名的，此算法使用服务器的SSL数字证书中的公用密钥。

有了服务器的SSL数字证书，客户端也可以验证服务器的身份。SSL 协议的版本 1 和 2 只提供服务器认证。版本 3 添加了客户端认证，此认证同时需要客户端和服务器的数字证书。

详细介绍：网页链接

❷ HTTPS加密原理

HTTP、HTTPS在我们日常开发中是经常会接触到的。

我们也都知道，一般 Android 应用开发，在请求 API 网络接口的时候，很多使用的都是 HTTP 协议；使用浏览器打开网页，也是利用 HTTP 协议。看来 HTTP 真是使用广泛啊，但是，HTTP 是不安全的。利用网络抓包工具就可以知道传输中的内容，一览无余。比如我经常会使用 Fiddler 来抓包，搜集一些有趣的 API 接口。

那么问题来了，如何保证 HTTP 的安全性呢？基本上所有的人都会脱口而出：使用 HTTPS 协议。99.9% 的人都知道 HTTPS 会将传输的内容进行加密，但是接着问具体加密的过程和步骤，很多人就哑口无言了。

为了防止出现这种尴尬的局面，所以今天你就要好好看看这篇的内容了。以后就可以装个逼，哈哈！

先科普一下，加密算法的类型基本上分为了两种：

对称加密的意思就是说双方都有一个共同的密钥，然后通过这个密钥完成加密和解密，这种加密方式速度快，但是安全性不如非对称加密好。

举个例子，现在学霸小明这里有一道数学题的答案：123 。他想把答案传给自己一直暗恋的小红。所以他们双方在考试开考前，约定了一把密钥：456 。那么小明就把答案内容经过密钥加密，即 123 + 456 = 579 ，将 579 写在小纸条上扔给小红。如果此时别人捡到了小纸条，不知道他们是加密传输的，看到上面的 579 ，会误以为答案就是 579 ；如果是小红捡到了，她拿出密钥解密，579 - 456 = 123 ，得到了正确的答案。

这就是所谓的对称加密，加解密效率高，速度快，但是双方任何一方不小心泄露了密钥，那么任何人都可以知道传输内容了。

讲完了对称加密，我们看看啥是非对称加密。

非对称加密就是有两把密钥，公钥和私钥。私钥自己藏着，不告诉任何人；而公钥可以公开给别人。

经过了上次作弊后，小红发现了对称加密如果密钥泄露是一件可怕的事情。所以她和小明决定使用非对称加密。小红生成了一对公钥和私钥，然后把公钥公开，小明就得到了公钥。小明拿到公钥后，把答案经过公钥加密，然后传输给小红，小红再利用自己的私钥进行解密，得到答案结果。如果在这个过程中，其他人得到传输的内容，而他们只有小红公钥，是没有办法进行解密的，所以也就得不到答案，只有小红一个人可以解密。

因此，相比较对称加密而言，非对称加密安全性更高，但是加解密耗费的时间更长，速度慢。

对称加密和非对称加密的具体应用我还是深有体会的，因为所在的公司是做金融支付方面的，所以加解密基本上算是天天见了。

说完加密类型后，我们再来看看 HTTPS 。

我们先来看一个公式：

HTTPS = HTTP + SSL

从这个公式中可以看出，HTTPS 和 HTTP 就差在了 SSL 上。所以我们可以猜到，HTTPS 的加密就是在 SSL 中完成的。

所以我们的目的就是要搞懂在 SSL 中究竟干了什么见不得人的事了？

这就要从 CA 证书讲起了。CA 证书其实就是数字证书，是由 CA 机构颁发的。至于 CA 机构的权威性，那么是毋庸置疑的，所有人都是信任它的。CA 证书内一般会包含以下内容：

正好我们把客户端如何校验 CA 证书的步骤说下吧。

CA 证书中的 Hash 值，其实是用证书的私钥进行加密后的值（证书的私钥不在 CA 证书中）。然后客户端得到证书后，利用证书中的公钥去解密该 Hash 值，得到 Hash-a ；然后再利用证书内的签名 Hash 算法去生成一个 Hash-b 。最后比较 Hash-a 和 Hash-b 这两个的值。如果相等，那么证明了该证书是对的，服务端是可以被信任的；如果不相等，那么就说明该证书是错误的，可能被篡改了，浏览器会给出相关提示，无法建立起 HTTPS 连接。除此之外，还会校验 CA 证书的有效时间和域名匹配等。

接下来我们就来详细讲一下 HTTPS 中的 SSL 握手建立过程，假设现在有客户端 A 和服务器 B ：

到此，SSL 握手过程就讲完了。可能上面的流程太过于复杂，我们简单地来讲：

我们可以发现，在 HTTPS 加密原理的过程中把对称加密和非对称加密都利用了起来。即利用了非对称加密安全性高的特点，又利用了对称加密速度快，效率高的好处。真的是设计得非常精妙，令人赞不绝口。

好了，HTTPS 加密原理到这就讲的差不多了，不知道电脑前的你有没有看懂呢？

如果有哪里不明白的地方，可以在底下留言交流。

bye ~~

❸ 在对信息进行加密时,对称密码算法适合处理什么类型的信息

对称密码算法，又称对称加密算法，是一种加密和解密过程中使用相同密钥的加密算法。由于对称加密算法的计算速度快且加密效率较高，它通常适合处理以下类型的信息：
1. 大量数据卖判：对于需要加密大量数据的场景，如文件存储、数据库加密等，对称加密算法是一个很好的选择。由于其加密和解密速度快，对称加密算法可以在很短的时间内处理大量数据，降低系统的延迟。
2. 实时通信：在实时通信场景中，如语音通话、即时消息等，对称锋孝加密算法可以提供低延迟的加密解密服务。这有助银配稿于保持实时通信的流畅性和用户体验。
3. 传输层安全：在网络传输中，对称加密算法可以确保数据的安全性和完整性。例如，传输层安全协议（TLS）就使用了对称加密算法来加密客户端和服务器之间的通信数据。
然而，对称加密算法的一个缺点是密钥管理问题。在数据传输过程中，双方需要共享相同的密钥。密钥的传输和管理可能带来安全隐患。为解决这个问题，通常采用非对称加密算法（如RSA）在安全信道上交换对称加密密钥，之后使用对称加密算法进行数据加密。这种组合方式充分发挥了对称加密算法和非对称加密算法的优势，实现了高效且安全的数据加密通信。

❹ 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原理是什么，如何加密

https作用：

1.保护隐私：所有信息都是加密传播，第三方无法窃听数据。如果使用HTTP明文传输数据的话，很可能被第三方劫持数据，那么所输入的密码或者其他个人资料都被暴露在他人面前，后果可想而知。

2.数据完整性：一旦第三方篡改了数据，接收方会知道数据经过了篡改，这样便保证了数据在传输过程中不被篡改 —— 数据的完整性。

3.身份认证：第三方不可能冒充身份参与通信，因为服务器配备了由证书颁发机构（Certificate

Authority，简称CA）颁发的安全证书，可以证实服务器的身份信息，防止第三方冒充身份。（也有少数情况下，通信需要客户端提供证书，例如银行系统，需要用户在登录的时候，插入银行提供给用户的USB，就是需要客户端提供证书，用来验证客户的身份信息。）

https原理：

http+ssl证书=https

像目前JoySSL品牌的ssl证书很优质，有着多种品牌证书，价格方面性价比也很高。JoySSL：https安全证书

❻ 移动端与后端数据传输加密

对称加密：对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高
非对称加密：非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。
方案：将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。
方案的流程介绍：
1、APP客户端需要和服务器进行数据交互，它的APP首先生成了一个随机数作为对称密钥(比如AES加密的密钥)。
2、APP客户端向服务器请求公钥
3、服务器将公钥发送给APP客户端
4、APP客户端使用服务器的公钥将自己的对称密钥(比如AES加密的密钥)加密
5、APP客户端将加密后的对称密钥发送给服务器
6、服务器使用私钥解密得到APP客户端的对称密钥
7、APP客户端与服务器可以使用对称密钥来对沟通的内容进行加密与解密了
App端和后台数据加密分两部分：
1.数据传输的时候加密 （一般采用Https协议在传输层加密）
2.数据本身的加密 （使用各种加密算法）
RSA非对称加密：公钥加密，私钥解密。公钥私钥由服务端生成，公钥放在客户端私密保存，私钥放在服务端。安全性高，运算速度慢
AES对成加密：运算速度快切安全性高
上面网络通信过程是安全的，可以保证通信数据即使被截取了，也无法获得任何有效信息；即使被篡改了，也无法被客户端和服务端验证通过。
具体可参考的博文：（记得后续实践哦）
https://blog.csdn.net/wangjiang_qianmo/article/details/88073848?utm_medium=distribute.pc_relevant.none-task-blog--1.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog--1.channel_param

❼ 对称加密算法的加密算法主要有哪些

1、3DES算法

3DES（即Triple DES）是DES向AES过渡的加密算法（1999年，NIST将3-DES指定为过渡的加密标准），加密算法，其具体实现如下：设Ek()和Dk()代表DES算法的加密和解密过程，K代表DES算法使用的密钥，M代表明文，C代表密文，这样：

3DES加密过程为：C=Ek3(Dk2(Ek1(M)))

3DES解密过程为：M=Dk1(EK2(Dk3(C)))

2、Blowfish算法

BlowFish算法用来加密64Bit长度的字符串。

BlowFish算法使用两个“盒”——unsignedlongpbox[18]和unsignedlongsbox[4,256]。

BlowFish算法中，有一个核心加密函数:BF_En(后文详细介绍）。该函数输入64位信息，运算后，以64位密文的形式输出。用BlowFish算法加密信息，需要两个过程：密钥预处理和信息加密。

分别说明如下：

密钥预处理：

BlowFish算法的源密钥——pbox和sbox是固定的。我们要加密一个信息，需要自己选择一个key，用这个key对pbox和sbox进行变换，得到下一步信息加密所要用的key_pbox和key_sbox。具体的变化算法如下：

1)用sbox填充key_sbox

2)用自己选择的key8个一组地去异或pbox，用异或的结果填充key_pbox。key可以循环使用。

比如说：选的key是"abcdefghijklmn"。则异或过程为：

key_pbox[0]=pbox[0]abcdefgh；

key_pbox[1]=pbox[1]ijklmnab；

…………

…………

如此循环，直到key_pbox填充完毕。

3)用BF_En加密一个全0的64位信息，用输出的结果替换key_pbox[0]和key_pbox[1],i=0；

4)用BF_En加密替换后的key_pbox,key_pbox[i+1]，用输出替代key_pbox[i+2]和key_pbox[i+3]；

5)i+2，继续第4步，直到key_pbox全部被替换；

6)用key_pbox[16]和key_pbox[17]做首次输入（相当于上面的全0的输入），用类似的方法，替换key_sbox信息加密。

信息加密就是用函数把待加密信息x分成32位的两部分:xL,xRBF_En对输入信息进行变换。

3、RC5算法

RC5是种比较新的算法，Rivest设计了RC5的一种特殊的实现方式，因此RC5算法有一个面向字的结构：RC5-w/r/b，这里w是字长其值可以是16、32或64对于不同的字长明文和密文块的分组长度为2w位，r是加密轮数，b是密钥字节长度。

(7)客户端服务器对称加密方案扩展阅读：

普遍而言，有3个独立密钥的3DES（密钥选项1）的密钥长度为168位（三个56位的DES密钥），但由于中途相遇攻击，它的有效安全性仅为112位。密钥选项2将密钥长度缩短到了112位，但该选项对特定的选择明文攻击和已知明文攻击的强度较弱，因此NIST认定它只有80位的安全性。

对密钥选项1的已知最佳攻击需要约2组已知明文，2部，2次DES加密以及2位内存（该论文提到了时间和内存的其它分配方案）。

这在现在是不现实的，因此NIST认为密钥选项1可以使用到2030年。若攻击者试图在一些可能的（而不是全部的）密钥中找到正确的，有一种在内存效率上较高的攻击方法可以用每个密钥对应的少数选择明文和约2次加密操作找到2个目标密钥中的一个。

❽ HTTPS通信时,Web服务器收到加密后的“对称加密用的密钥”,使用什么对其进行解

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

❾ 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