HTTPS及CA证书详解_服务器证书通常包含哪些内容

HTTPS

术语解释

1. HTTP

http，超文本传输协议，是基于请求响应的一个无状态的应用层协议，初衷主要是用来发布和接收web网页内容。监听端口号是80

2. SSL/TLS(Secure sockets Layer/transport layer security)

SSL称为安全套接层，有网景公司设计，主要用来解决HTTP协议明文传输导致内容被偷窥和篡改的缺点。
TLS叫做传输层安全协议。1999年，SSL被IETF标准化改名为TLS。

3. HTTPS

https其实就是http协议和SSL/TLS的组合。

4. 对称加密

即加解密使用相同的密钥。

http的历史

HTTP1.1 长连接，即请求一次数据后可以不断开；节省带宽，即可以单独发送header，如果有权限请求，服务器返回100，没有则返回401，还可以进行部分数据请求，即断点续传；增加host处理

HTTPS协议如何运行的

一个https协议实际是由两次http协议传输完成，分为八步

1. 客户端发出https请求，连接443端口
2. 服务器准备好自己的私钥和公钥证书
3. 服务器将自己的公钥证书发给客户端
4. 客户端验证证书是否来自服务器，并产生随机的会话密钥，然后使用服务器的公钥加密
5. 客户端将会话密钥的密文发给服务器
6. 服务器使用自己的私钥解密，得到会话密钥，并使用会话密钥对需要传输的数据加密
7. 服务器将数据的密文发给客户端
8. 客户端使用会话密钥解密，得到数据

HTTPS原理

首先http是明文传输，它会经过很多节点，比如路由器，通信运行商等等，如果消息被不发分子接受，它就可以看到，甚至可以进行中间人攻击，就是让双方不知道的情况下篡改信息。而加密便是最好的方式。对称加密和非对称加密都是候选，用哪个呢？我们挨个来分析一下。

1. 对称加密可行性

基础知识我们已经了解过对称加密，既然对称加密要求通信双方拥有相同的密钥，那如何一方产生的密钥在保证会被泄露发给另一方呢？

使用对称加密再加密，死循环了。不可行。

2. 非对称加密可行性

那采用非对称加密呢，服务器将自己的公钥给浏览器，浏览器的数据通过公钥加密后传给服务器，这些数据只有服务器的私钥能解密。

这样看似可行，浏览器如何拿到服务器的公钥呢，又怎么保证这是服务器的公钥而不是其他人伪造的呢，这个问题便引出了我们稍后讨论的公钥证书。在这里我们假定客户端可以拿到服务器的公钥，并确认其身份。

既然浏览器到服务器的数据可以保证，那服务器到浏览器的数据同样采用非对称加密是否可行？

抛开安全性的问题，这里需要考虑到对称加密和非对称加密的效率问题。非对称加密的加解密速度相对于对称加密来说比较慢。如果数据量特别大的话，还是得采用对称加密的方式。

那问题又回来了，如何保证对称加密的密钥在传输中不被泄露呢？

答案就是通过非对称加密协商密钥。

3. 非对称加密+对称加密方案

浏览器请求连接后，服务器将自己的公钥发给浏览器，浏览器生成用于对称加密的密钥，并将其用服务器公钥加密后发给服务器，这样服务器和浏览器都拥有了对称加密密钥，此后便可以通过对称加密来加密数据。

这样一来，数据的机密性得到了保证。

遗留问题以及可能的方案

在上面的部分中，我们遗留了几个问题。

浏览器如何拿到服务器公钥呢?

• 服务器直接将公钥发给客户端。但是中间人可以通过截取服务器公钥，把自己的公钥发给浏览器，浏览器便会使用中间人的公钥加密对称密钥。因此中间人可以获取到对称密钥，从而可以一直监听之后的数据通信。
• 建立一个公钥的目录表，所有用户可以从中获取响应服务器的公钥，同样该目录表可能被伪造。

浏览器如何确定拿到的公钥就是服务器的公钥？

上面两种方法究其原因是因为安全性，无法保证公钥的真实性。归根到底是可信。

• 那是否可以设置一个可信的管理机构，管理机构为每个用户维护公钥目录，每个用户拥有该管理机构的公钥。当与服务器通信时，便可以通过管理机构来请求响应服务器的公钥。管理机构通过自己的私钥对服务器的公钥加密，而用户可以使用管理机构的公钥解密。因为管理机构私钥只有自己拥有，因此服务器公钥是不可能被其他人伪造的。

这样看似可行，不过也有缺点，每个用户和其他人或者服务器联系，都需要请求该机构，该机构容易成为系统的瓶颈，出现一个单点故障问题。同时，因为公钥保存在该机构，容易受到敌手的窜扰。

CA证书

那另一个方法便是我们要讨论的，公钥证书。

公钥证书由证书管理机构（Certificate Authority, CA）为用户（即服务器）建立，包含了以下内容：

1. 证书的发布机构
2. 证书的有效期
3. 证书的所有者
4. 公钥
5. 签名使用的算法
6. 指纹及指纹使用的算法

服务器将证书发给浏览器，客户便可以通过证书认定公钥是否是证书所有者的，且信息是否经过篡改。

公钥证书是如何做到的呢

证书管理机构CA在设置好所有信息后，对证书首先使用指纹算法（即进行一次hash），然后使用签名算法（使用CA自己的私钥加密）对hash作签名。并把签名和证书一起颁发给服务器。当浏览器请求时，服务器需要将证书和签名一起发给浏览器。

浏览器收到证书以后，使用权威机构的公钥解密签名，并将证书进行hash，并且将两者信息对比，如果相同便可以证明证书信息是没有被修改的。

1. 其他的中间人如果进行伪造并篡改签名，因为证书是使用权威机构的私钥生成的，浏览器使用权威机构的公钥解密后和信息不匹配，从而不会信任该服务器。
2. 如果第三方同样获取到了权威机构颁发的证书和签名，他可能进行重放攻击，但是解密后的信息和证书的信息也不会匹配。
3. hash的作用是为了保证证书信息的完整性。在上面在签名之前有一个hash的操作，看上去不进行hash同样可以实现。这里的hash与加密的开销有很大关系，因为非对称加密是很耗时的，对hash后的数据进行加密会大大减少加密开销。至于安全性还有待研究
4. 那这个权威机构的公钥怎么来的呢，我们上面说的都是为了证明服务器的公钥确实是该服务器的公钥吧，同样道理，该权威机构的公钥也可以通过其父权威机构来证明它的可信性。而当我们安装操作系统时，已经内嵌了可信的证书发布机构。