HTTPS的定义

简单来讲，HTTPS就是安全的HTTP，我们知道HTTP是运行在TCP层之上的，HTTPS在HTTP层和TCP层之间加了一个SSL层，SSL向上提供加密和解密的服务，对HTTP比较透明，这样也便于服务器和客户端的实现以及升级。

HTTPS为什么安全？

HTTPS安全是由一套安全机制来保证的，主要包含这4个特性：机密性、完整性、真实性和不可否认性。

机密性是指传输的数据是采用Session Key（会话密钥）加密的，在网络上是看不到明文的。

• 完整性是指为了避免网络中传输的数据被非法篡改，使用MAC算法来保证消息的完整性。

• 真实性是指通信的对方是可信的，利用了PKI（Public Key Infrastructure 即『公钥基础设施』）来保证公钥的真实性。

• 不可否认性是这个消息就是你给我发的，无法伪装和否认，是因为使用了签名的技术来保证的。

对称加密和非对称加密

HTTPS有对称加密和非对称加密两种算法，目的都是把明文加密成密文，区别是密钥的个数不一样，对称加密是一把密钥，这把密钥可以加密明文，也可以解密加密后的密文，常见的对称加密算法有AES、DES、RC4，目前最常用的是AES。

非对称加密是两把密钥，分别是公钥和私钥，公钥加密的密文只有相对应的私钥才能解密，私钥加密的内容也只有相对应的公钥才能解密，其中公钥是公开的，私钥是自己保存，不能公开，常见的非对称加密算法有RSA和ECC（椭圆曲线算法）。

SSL结合了这两种加密算法的优点，通过非对称加密来协商对称加密的密钥，握手成功之后便可使用对称加密来做加密通信，对于RSA来说，客户端是用RSA的公钥把预主密钥加密后传给服务器，服务器再用私钥来解密，双方再通过相同的算法来生成会话密钥，之后的应用层数据就可以通过会话密钥来加密通信。

签名

SSL中还有一个使用非对称加密的地方就是签名，签名的目的是让对方相信这个数据是我发送的，而不是其他人发送的。

密钥安全强度与性能对比

加密之后的数据破解难度就体现在密钥的长度上，密钥越长，破解难度也越大，但是运算的时间也越长，性能也就越差。相同安全强度下，对称密钥长度在最短，ECC次之，RSA密钥长度则最长。

目前比较常用的密钥长度是：对称密钥128位、ECC 256位、RSA 2048位。

RSA和ECC在SSL中更多的是用来签名，通过测试发现，ECC 的签名性能比RSA好很多，但是RSA的验签性能比ECC更好，所以RSA更适合于验证签名频繁而签名频度较低的场景，ECC更适合于签名频繁的场景，在SSL场景中，ECC算法性能更好。

公钥基础设施（PKI）

简单的说，PKI就是浏览器和CA，CA是整个安全机制的重要保障，我们平时用的证书就是由CA机构颁发，其实就是用CA的私钥给用户的证书签名，然后在证书的签名字段中填充这个签名值，浏览器在验证这个证书的时候就是使用CA的公钥进行验签。

证书

那CA在PKI中又是怎样发挥作用的呢，首先，CA的作用就是颁发证书，颁发证书其实就是使用CA的私钥对证书请求签名文件进行签名，其次，CA颁发的证书浏览器要信任，浏览器只需要用CA的公钥进行验签成功就表示这个证书是合法可信的，这就需要浏览器内置CA的公钥，也就是内置CA的证书。一般来说，操作系统都会内置权威CA的证书，有的浏览器会使用操作系统内置的CA证书列表，有的浏览器则自己维护的CA证书列表，比如Firefox。

CA分为根CA，二级CA，三级CA，三级CA证书由二级CA的私钥签名，二级CA证书由根CA的私钥签名，根CA是自签名的，不会给用户证书签名，我们平时用的证书都是由二级CA或者三级CA签名的，这样就形成了一个证书链，浏览器在验签的时侯一层层往上验证，直到用内置的根CA证书的公钥来验签成功就可以表示用户证书是合法的证书。
根证书已经内置在浏览器或者操作系统里了，在SSL握手时就不需要发根CA证书了，只需要提供中间二级三级CA证书和用户证书就可以。

交叉证书

交叉证书的应用场景是这样的：假如现在阿里云成为一个新的根CA机构，那阿里云签发的证书想要浏览器信任的话，阿里云的根证书就需要内置在各大操作系统和浏览器中，这需要较长时间的部署，那在没有完全部署完成之前，阿里云签发的证书怎么才能让浏览器信任呢，这就需要用到交叉证书了。

上图中，根证书A是一个所有浏览器都内置了的根证书，B是一个新的根证书，用户证书D是由根证书 B的二级CA B1来签发的，但是根证书B并没有在浏览器中内置，所以浏览器不会信任用户证书D，这是因为浏览器在验签时只验证到B1这一层然后找不到根证书B就无法验证下去了。

如果二级CA B1证书是由根证书A来签名，那这个问题就解了，所以新的根证书机构B会将二级CA证书（准确地讲是二级CA的证书签名请求文件）给老的根证书A来签名，然后得到一个新的中间证书就是交叉证书。

浏览器在验证的时侯用了新的信任链，这样就可以解决用户证书的信任问题。

当B的根证书全部部署完成后，再替换成自己的二级CA就可以了。

证书分类

证书分有三类：DV、OV、EV

DV证书只校验域名的所有权，所以我们在申请DV证书的时候CA会提供几种验证域名所有权的方法：比如文件校验、DNS校验、邮件校验，DV证书支持单域名、多域名和泛域名，但不支持多个泛域名，只支持一个泛域名，一般价格比较便宜，具体价格跟域名的数量有关，域名越多价格越高。

OV证书要验证组织机构，在申请证书时CA会打电话确认这个域名是否真的属于相应的公司或者机构，OV证书是单域名、多域名、泛域名和多个泛域名都支持，价格一般比DV证书要贵。

EV证书的校验就更细了，比如组织机构的地址之类的，EV证书会在地址栏上显示组织机构的名称，EV证书只支持单域名或者多个域名，不支持泛域名，而且更贵，所以普通用户一般不会用EV证书。

证书吊销

证书是有生命周期的，如果证书的私钥泄漏了那这个证书就得吊销，一般有两种吊销方式：CRL和OCSP。

CRL是CA机构维护的一个已经被吊销的证书序列号列表，浏览器需要定时更新这个列表，浏览器在验证证书合法性的时候也会在证书吊销列表中查询是否已经被吊销，如果被吊销了那这个证书也是不可信的。可以看出，这个列表随着被吊销证书的增加而增加，列表会越来越大，浏览器还需要定时更新，实时性也比较差。

所以，后来就有了 OCSP 在线证书状态协议，这个协议就是解决了 CRL 列表越来越大和实时性差的问题而生的。有了这个协议，浏览器就可以不用定期更新CRL了，在验证证书的时候直接去CA服务器实时校验一下证书有没有被吊销就可以，是解决了CRL的问题，但是每次都要去CA服务器上校验也会很慢，在网络环境较差的时候或者跨国访问的时候，体验就非常差了，OCSP虽然解决了CRL的问题但是性能却很差。所以后来就有了OCSP stapling。

OCSP stapling主要解决浏览器OCSP查询性能差的问题，本来由浏览器去CA的OCSP服务器查询证书状态的，现在改由域名的服务器去查询，将OCSP的结果告诉浏览器即可，一般服务器的网络性能要好于用户电脑的网络，所以OCSP stapling的性能是最好的。但是并不是所有的服务器都支持OCSP stapling，所以目前浏览器还是比较依赖CRL，证书吊销的实时性要求也不是特别高，所以定期更新问题也不大。