SSL真的安全吗？ https 底层原理揭秘

SSL：

• 公钥，私钥 （保护数据）
• 签名 （保护公钥）进行摘要的生成

---

http （80） 数据走80端口
https (80,443) 数据走80端口， 443 （公钥传输）证书.. (异步，避免阻塞)

服务器对数据进行加密（非对称加密）。涉及加密算法。

对称加密： 加密 和 解密 是一套算法。
非对称加密： 加密和解密不是一套算法。
算法不通。

RSA（非对称加密算法）：

• 加密端有私钥。 私钥用来加密数据。 私钥可以生成公钥。 （私钥时明文。私钥越长 安全性越高，越难破解，性能越差，数据量会变大）
• 由私钥产生 公钥。 公钥（明文） 用来解密数据。
• 解密端：需要公钥解密。

传输数据：

• 发送端：私钥加密
• 接收端：公钥解密

加密算法：

md5 sha1 sha256 … 生成固定长度的字符串。这些不可逆，不是加密，只是生成摘要，用来校验数据的。

请求端 （浏览器） 都会实现 HTTP HTTPS 的协议。 请求是HTTPS时会去 80端口拿数据 443 拿证书。

拦截住：

• socket 数据
• 公钥
• 签名摘要

服务端传输数据是存在隐患的，都会经过公网，很多环节 不可控会被拦截。（浏览器-> 操作系统-> 主机硬件-> 路由器 -> ISP 服务提供商）

数据传输是Socket 包 （谁发的，发给谁的） 会进行数据压缩。

443 端口会下发一个公钥给浏览器，这时 传输的数据socket包就会被加密了。 数据就看不懂了。 （若拦截时，把443的公钥也拦截，数据依然会被解密查看）

查看后能不能改：（破坏数据）

• 拦截修改后，浏览器在用原来的公钥去解密时，是解不开的。
• 顺便把公钥 也进行改了。（用自己的私钥生成公钥，用自己的私钥加密修改后的数据， 把自己的公钥发给浏览器）。是否可行？ 不行，因为存在签名，保证数据传输不被篡改
• 可以给自己的公钥重新生成签名摘要。 上面的问题就解决了。

解决上面的问题是签名保证不能被修改，所以不能自己进行签名，应该别人进行签名。（第三方签名） 第三方是被双方可信赖的，（浏览器和 服务器）
第三方对公钥进行第二次加密。

1. 服务器端 把自己的公钥提交给第三方， 拿第三方的私钥 对服务器端的公钥进行加密。公钥被加密，还是一个公钥。
2. 浏览器接收数据，（CA的公钥是在浏览器内置的）对公钥进行解密（拿第三方的公钥）得到 服务端公钥 —> 在解密数据 ————> 拿到数据，
   CA.public –> Ser.public –> Ser.Realpublic
3. 传输过程中，如果被拦截CA 的公钥拦截 ， 数据可以看，但是装不回去了，用自己私钥 加密的话，你自己的公钥没有被第三方认可。

二次加密的过称叫做签名。 不存在这个过程的话，之前数据是可以改的。

CA 最大的风险就是私钥丢失

证书

Ser.public + CA. 加密 （国家 ，公司 (多)域名 ….） 签名