Https是怎样保证安全的

443与80端口

443端口是浏览器与服务器协商如何进行安全传输数据的，真正的数据交换依旧使用的是80端口。

整个流程

1. 浏览器：将自己支持的加密算法列表通过443端口发送给服务端
2. 服务端：收到后与自己支持的算法列表进行比较，选出一种双方都支持的算法，将算法名称回传给浏览器，协商完成
3. 浏览器：使用协商的加密算法对请求原文进行加密，通过80端口发送给服务端
4. 服务端：将收到的请求密文使用协商的算法进行解密，经过处理后，将响应原文使用协商的算法进行加密，回传浏览器
5. 浏览器：浏览器收到响应密文后使用协商的算法进行解密，拿到响应原文，进行渲染

无论是加密还是解密，都需要使用到key，即密钥（通常所说的“盐”）。

由于浏览器与服务器之间存在很多网络设备和中间商，如路由器、猫、ISP等，那么，如何安全地让浏览器和服务端都知道密钥成为一个关键问题。

对称加密

加密和解密使用同一密钥，常用的对称加密算法如AES、DES。

在网络环境中是无法绝对保证密钥安全传输（不被拦截）的，只要中间商拿到密钥，即可对数据进行加解密，从而进行伪装篡改。

非对称加密

加密和解密使用不同的密钥，常用的如RSA。

由于加密和解密使用的密钥不同，因此需要有两个密钥。

发送方将自己的原始密钥进行加密后得到一个加密密钥。原始密钥称为私钥，加密密钥称为公钥。

私钥自己保管，公钥可发送给接收方。

由于服务端安全性能相比浏览器来说更高，因此私钥一般都是由服务端进行生成保管。

公钥和私钥总是成对存在的，使用私钥加密的数据只能用公钥解密，使用公钥加密的数据只能用私钥解密。

简而言之：私钥加密公钥解，公钥加密私钥解。

• 私钥加密公钥解 - 可篡改，如：

中间商伪装成服务端与浏览器通信

1. 中间商使用假私钥生成假公钥
2. 中间商拦截真密文和真公钥，使用真公钥解密，得到真原文
3. 篡改真原文，得到假原文
4. 使用假私钥加密假原文，得到假密文
5. 将假密文和假公钥发送给浏览器
6. 浏览器使用假公钥解密假密文，得到假原文

• 公钥加密私钥解 - 只能查看不能篡改

HTTPS的核心思想就是公钥加密私钥解密。

由于公钥加密的数据只能私钥解密，而私钥保存在服务端，因此公钥加密的数据只能被拦截后可查看加密数据，但是不能解密与篡改。但中间商可以伪装成浏览器与服务端进行通信。

通过以上过程描述可知，不安全的核心原因在于公钥在传输过程中被拦截。

因此，要彻底解决安全问题的关键在于公钥不传输。

第三方CA

可信的第三方CA机构通过与操作系统公司合作将CA公钥（即证书）内置进浏览器，从而达到公钥不传输的方法。过程如下：

1. 第三方将CA私钥加密得到CA公钥
2. 通过与OS公司合作将CA公钥（即证书）内置进浏览器，从而达到公钥不传输的方法
3. 服务端将服务器公钥提交给给CA，用CA私钥加密服务器公钥，得到密文
4. 将密文发送给浏览器
5. 浏览器使用内置的CA公钥解密，得到原文，即服务器公钥
6. 浏览器用解密出的服务器公钥加密数据，与服务器交互

由于CA公钥未经网络传输，因此中间商无法获得CA公钥，也就无法解密出服务器公钥，也就无法伪装成浏览器与服务端进行通信，从而达到安全的目的。

重要说明

CA解决的问题不是数据是否被偷窥，而是让浏览器判断网站的真实性（即防钓鱼网站）。

CA私钥加密的数据原文包括服务器公钥+服务器域名+服务器公钥摘要等信息，并明文告知浏览器该公钥是哪个网站下发的，即CA将证书与网站进行了绑定。

浏览器解密后会校验域名、摘要与明文信息进行比较，判断数据的合法性。

补充说明

单向加密

无法根据密文（在有意义的时间内）推导出原文的加密方式，只能通过判断两个密文是否相同的方式判断原文是否正确。

摘要算法

一种单向加密算法，常见如MD5、CRC、SHA等，过程如下：

1. 提取原文特征
2. 使用哈希算法将特征加密，得到摘要
3. 将原文、摘要算法、摘要信息一块发送出去
4. 接收方收到数据后，使用收到的摘要算法加密收到的原文，将得到的摘要信息与收到的摘要信息对比，一致说明原文内容正确

哈希算法

将任意长度的二进制值串映射为固定长度的二进制值串的算法

优秀哈希算法标准：

1. 单向性：通过密文不可推导出原文
2. 原始数据敏感：即使原文只修改1位，得到的密文也大不相同
3. 散列冲突小：由于原始数据无限多，而密文长度一定，通过鸽巢（抽屉）理论可知，散列冲突无法避免，只能尽量降低
4. 算法效率高

哈希算法应用场景

• 安全加密：如生成唯一标识、数据校验
• 负载均衡：如将会话ID计算hash，取模服务器数量
• 数据分片
• 分布式存储