即时通讯开法中HTTPS是对称加密还是非对称加密？

无论是即时通讯IM还是其它应用，在网络安全意识增强的今天，很多场景下使用HTTPS是肯定没错的。对于即时通讯IM的开发人员来说，长连接用TLS这没疑问，短连接用HTTPS也没问题，但我想问你一个{BANNED}最佳基础的面视问题：HTTPS到底用的是对称加密还是非对称加密？要回答这个问题，显然需要再梳理一下HTTPS的技术原理了。

随着 HTTPS 建站的成本下降，现在大部分的网站都已经开始用上 HTTPS 协议。大家都知道 HTTPS 比 HTTP 安全，也听说过与 HTTPS 协议相关的概念有 SSL 、非对称加密、 CA证书等。

但对于以下灵魂三拷问可能就答不上了：

    1）为什么用了 HTTPS 就是安全的？
    2）HTTPS 的底层原理如何实现？
    3）用了 HTTPS 就一定安全吗？

不用担心，本文将在解答“HTTPS到底用的是对称加密还是非对称加密？”的同时层层深入，从原理上把 HTTPS 的安全性讲透，您也将同时理解上述问题。

大家可能都听说过 HTTPS 协议之所以是安全的是因为 HTTPS 协议会对传输的数据进行加密，而加密过程是使用了非对称加密实现。但其实：HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

① 证书验证阶段：

    1）浏览器发起 HTTPS 请求；
    2）服务端返回 HTTPS 证书；
    3）客户端验证证书是否合法，如果不合法则提示告警。

② 数据传输阶段：

    1）当证书验证合法后，在本地生成随机数；
    2）通过公钥加密随机数，并把加密后的随机数传输到服务端；
    3）服务端通过私钥对随机数进行解密；
    4）服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输。

为什么数据传输是用对称加密？

首先：非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的。

另外：在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。

为什么需要 CA 认证机构颁发证书？

HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。

首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的“中间人攻击”问题。

过程原理如下：

    1）本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器；
    2）中间人服务器返回中间人自己的证书；
    3）客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输；
    4）中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密；
    5）中间人以客户端的请求内容再向正规网站发起请求；
    6）因为中间人与服务器的通信过程是合法的，正规网站通过建立的安全通道返回加密后的数据；
    7）中间人凭借与正规网站建立的对称加密算法对内容进行解密；
    8）中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输；
    9）客户端通过与中间人建立的对称加密算法对返回结果数据进行解密。

由于缺少对证书的验证，所以客户端虽然发起的是 HTTPS 请求，但客户端完全不知道自己的网络已被拦截，传输内容被中间人全部窃取。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

证书的合法性依据是什么？

    1）首先：权威机构是要有认证的，不是随便一个机构都有资格颁发证书，不然也不叫做权威机构；
    2）另外：证书的可信性基于信任制，权威机构需要对其颁发的证书进行信用背书，只要是权威机构生成的证书，我们就认为是合法的。

所以权威机构会对申请者的信息进行审核，不同等级的权威机构对审核的要求也不一样，于是证书也分为免费的、便宜的和贵的。

浏览器如何验证证书的合法性？

浏览器发起 HTTPS 请求时，服务器会返回网站的 SSL 证书，浏览器需要对证书做以下验证：

    1）验证域名、有效期等信息是否正确：证书上都有包含这些信息，比较容易完成验证；
    2）判断证书来源是否合法：每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证

    3）判断证书是否被篡改：需要与 CA 服务器进行校验；
    4）判断证书是否已吊销：通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与 CA 服务器的交互，提高验证效率。

以上任意一步都满足的情况下浏览器才认为证书是合法的。

这里插一个我想了很久的但其实答案很简单的问题：

既然证书是公开的，如果要发起中间人攻击，我在官网上下载一份证书作为我的服务器证书，那客户端肯定会认同这个证书是合法的，如何避免这种证书冒用的情况？
其实这就是非加密对称中公私钥的用处，虽然中间人可以得到证书，但私钥是无法获取的，一份公钥是不可能推算出其对应的私钥，中间人即使拿到证书也无法伪装成合法服务端，因为无法对客户端传入的加密数据进行解密。

如果需要浏览器不提示安全风险，那只能使用认证机构签发的证书。但浏览器通常只是提示安全风险，并不限制网站不能访问，所以从技术上谁都可以生成证书，只要有证书就可以完成网站的 HTTPS 传输。