HTTPS采用的加密方式及认证方式解读

HTTPS的混合加密机制

https采用共享密钥加密和公开密钥加密两者并用的混合加密机制。

若密钥能够实现安全交换，那就有可能考虑仅使用公开密钥加密来通信（但这也不是最安全的实现方案）。但是公开密钥加密与共享密钥加密相比，其处理速度要慢很多。因此若在通信时使用公开密钥加密方式，效率就很低。

实际运用中：交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。充分利用两者优势，将多种方式组合起来用于通信。

共享密钥加密（对称加密）

加密和解密同用一个密钥的方式称为共享密钥加密（Common crypto system），也被叫做对称密钥加密。

加密和解密使用相同的密钥。只要攻击者（第三者）拿到密钥，就可以解读报文的内容。

以共享密钥方式加密时必须将密钥也发送给对方。发送密钥就存在被窃听的风险，但不发送，对方就不能解密。 密钥若能安全送达，那数据也应该能安全送达。

公开密钥加密

公开密钥加密使用一对非对称的密钥

使用两把密钥的公开密钥加密。

共享密钥加密方式很好的解决了共享密钥加密的困难。一把叫做私有密钥（private key)，一把叫做公开密钥（public key）。

私有密钥不能让其他任何人知道，而公开密钥可以随意发布，任何人都可以获得。

使用公开密钥加密的方式，发送密文的一方使用对方公开的密钥进行加密处理，对方收到加密的信息后，在使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，就不怕私有密钥被攻击者窃听。

要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这不是轻易可以做到的。如果能对一个非常大的整数做到快速的因式分解，那么密码破解还是存在希望的。但以目前的技术来看还是不太好实现的。

web传输没有绝对的安全。

在报文交互开始时，服务端会将公钥发送给客户端，此时攻击者可以伪造报文内容，让客户端获取到被篡改后的公钥。客户端再次发送报文时，使用攻击者的公钥对报文加密，攻击者拿到用户的加密报文信息，可以轻松的破解。

这和明文传输相比，只是换了个马甲而已。无法证明公开密钥本身就是货真价实的公开密钥。

那么客户端怎么知道拿到的公钥就是正确的呢？怎么保证客户端接收到的一定是公钥一定是自己服务器发送过来的公钥呢？这里就要加上新的帮手：证明公开密钥正确性的证书

保证web通信安全性 - 数字证书

关键词： 两对公钥和私钥；数字签名

这个过程就是 客户端在验证自己服务器发来的公钥的正确性。

证明公开密钥正确性的证书

由数字证书认证机构（CA，certificate authority）和其相关机构颁发的公开密钥证书。

数字证书的生成

首先服务器的运营人员向CA机构提出公开密钥的申请。CA在判明提出者的身份后，会对已申请的公开密钥做数字签名（用CA机构自己的私钥计算出的数字签名）。

然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。

数字证书的具体验证流程

1. 服务端将公钥证书发给客户端
2. 客户端拿到公钥证书后，使用CA的公开密钥（内置在浏览器的程序中），向CA验证公钥证书上的数字签名，以确认服务器公钥的真实性。
3. 使用自己服务器的公钥对报文进行加密传输
4. 服务端使用对应的私钥解密