计算机网络 – HTTPS 认证

HTTPS 认证

• HTTPS 认证
• • HTTPS 认证介绍
  • 单向认证双向认证
  • 单向认证
  • 双向认证
  • 相关问题
  • 证书
  • • 证书找谁签名合适
  • 证书如何验证
  • 中间人攻击
  • • 怎么防御/li>
  • 客户端如果没有内置公钥可以使用HTTPS么/li>
  • 握手不成功常见问题
  • 参考链接

HTTPS 认证

HTTPS 认证介绍

HTTPS基础知识：HTTPS (Secure Hypertext Transfer Protocol)安全超文本传输协议，是一个安全通信通道，它基于HTTP开发用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版,是使用TLS/SSL加密的HTTP协议。 HTTP协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能，可以避免此类问题发生。HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版。HTTPS主要作用是：

1. 对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全;
2. 对网站服务器进行真实身份认证。

TLS/SSL全称安全传输层协议Transport Layer Security, 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。

1. 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
2. 服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书
3. 客户端使用服务端返回的信息验证服务器的合法性，包括：
   1. 证书是否过期
   2. 发型服务器证书的CA是否可靠
   3. 返回的公钥是否能正确解开返回证书中的数字签名
   4. 服务器证书上的域名是否和服务器的实际域名相匹配
      验证通过后，将继续进行通信，否则，终止通信
4. 客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择
5. 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
6. 服务器将选择好的加密方案通过明文方式返回给客户端
7. 客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器
8. 服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。
   在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。

双向认证

双向认证和单向认证原理基本差不多，只是除了客户端需要认证服务端以外，增加了服务端对客户端的认证，具体过程如下：

1. 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
2. 服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书
3. 客户端使用服务端返回的信息验证服务器的合法性，包括：
   1. 证书是否过期
   2. 发型服务器证书的CA是否可靠
   3. 返回的公钥是否能正确解开返回证书中的数字签名
   4. 服务器证书上的域名是否和服务器的实际域名相匹配
      验证通过后，将继续进行通信，否则，终止通信
4. 服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端
5. 验证客户端的证书，通过验证后，会获得客户端的公钥
6. 客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择
7. 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式
8. 将加密方案通过使用之前获取到的公钥进行加密，返回给客户端
9. 客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端
10. 服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。

相关问题

1. 客户端是如何校验公钥证书合法性的/li>
2. Https到底怎么来防止中间人攻击的（Man-in-the-middle attack，缩写：MITM）/li>
3. 客户端如果没有内置公钥可以使用HTTPS么/li>

首先，我们需要了解 HTTPS 握手时使用的加密算法：对称加密算法和非对称加密算法。

了解了这俩种加密方式，再来看客户端如何校验公钥证书合法性，如果出现了中间人攻击，中间替换了公钥证书，客户端是如何校验的然是合法性的问题，服务器和客户端俩个当事人谁说了都不算，由数字证书认证机构（CA,Certificate Authority）和其相关机构颁发的公开密钥证书说了算。

证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名；

客户端在对服务器 say hello 之后，服务器将公开密钥证书发送给客户端，注意这个证书里面包含了公钥+各种信息+签名（私钥对各种信息加密后生成签名），客户端收到公开密钥证书后，相当于收到了一个包裹里面有公钥+各种信息+签名，怎么样使用这三个数据来校验尼，很简单，公钥加密，私钥解，私钥加密公钥也可以解，只要利用公钥对签名进行解密，然后最和各种信息做比较就可以校验出证书的合法性。

证书

私钥：私钥就是一个算法名称加上密码串，自己保存，从不给任何人看
公钥：公钥也是一个算法名称加上密码串，一般不会单独给别人，而是嵌在证书里面一起给别人
CA：专门用自己的私钥给别人进行签名的单位或者机构
申请（签名）文件：在公钥的基础上加上一些申请人的属性信息，比如我是谁，来自哪里，名字叫什么，证书适用于什么场景等的信息，然后带上进行的签名，发给CA（私下安全的方式发送），带上自己签名的目的是为了防止别人篡改文件。
证书文件：证书由公钥加上描述信息，然后经过私钥签名之后得到，一般都是一个人的私钥给另一个人的公钥签名，如果是自己的私钥给自己的公钥签名，就叫自签名。
签名过程：CA收到申请文件后，会走核实流程，确保申请人确实是证书中描述的申请人，防止别人冒充申请者申请证书，核实通过后，会用CA的私钥对申请文件进行签名，签名后的证书包含申请者的基本信息，CA的基本信息，证书的使用年限，申请人的公钥，签名用到的摘要算法，CA的签名。

证书找谁签名合适

别人认不认你的证书要看上面签的是谁的名，所以签名一定要找权威的人来签，否则别人不认，哪谁是权威的人呢就是CA，哪些CA是受人相信的呢就要看软件的配置，配置相信谁就相信谁，比如浏览器里面默认配置的那些，只要是那些CA签名的证书，浏览器都会相信，而你自己写的程序，可以由你自己指定信任的CA。

信任一个CA就是说你相信你手上拿到的CA的证书是正确的，这是安全的前提，CA的证书是怎么到你手里的，这个不属于规范的范畴，不管你是U盘拷贝的，还是怎么弄来得，反正你得确保拿到的CA证书没问题，比如浏览器、操作系统等，安装好了之后里面就内置了很多信任的CA的证书。

那么CA的证书又是谁签的名呢般CA都是分级的，CA的证书都是由上一级的CA来签名，而最上一级CA的证书是自签名证书。

证书如何验证

下面以浏览器为例，说明证书的验证过程：

1. 在TLS握手的过程中，浏览器得到了网站的证书
2. 打开证书，查看是哪个CA签名的这个证书
3. 在自己信任的CA库中，找相应CA的证书，
4. 用CA证书里面的公钥解密网站证书上的签名，取出网站证书的校验码（指纹），然后用同样的算法（比如sha256）算出出网站证书的校验码，如果校验码和签名中的校验码对的上，说明这个证书是合法的，且没被人篡改过
5. 读出里面的CN，对于网站的证书，里面一般包含的是域名
6. 检查里面的域名和自己访问网站的域名对不对的上，对的上的话，就说明这个证书确实是颁发给这个网站的
7. 到此为止检查通过

如果浏览器发现证书有问题，一般是证书里面的签名者不是浏览器认为值得信任的CA，浏览器就会给出警告页面，这时候需要谨慎，有可能证书被掉包了。如访问12306网站，由于12306的证书是自己签的名，并且浏览器不认为12306是受信的CA，所以就会给警告，但是一旦你把12306的根证书安装到了你的浏览器中，那么下次就不会警告了，因为你配置了浏览器让它相信12306是一个受信的CA。

中间人攻击

第一种：客户端say hello 后，被代理服务器拦截，然后他再向我们真正的服务器发相同的say hello，这时候服务器不知道你是谁，给了代理服务器公开密钥证书，然后代理服务器再把证书转发给客户端，客户端校验没毛病，然后用公钥加密的随机字符串发给代码服务器，这个时候代理服务器懵逼了，因为他没有私钥，解密不到随机字符串到底是什么，好吧，他虽然看不懂，但是还是把这一坨东西原封不动的给了服务器，服务器一看，没毛病，再把加密信息给代理服务器，代理服务器，因为不知道刚才的随机字符串是什么，而这个时候客户端和服务器已经不再使用公钥加密，而是使用了共享密钥加密，而关键的关键就是密钥就是刚才的随机字符串。代理服务器再次懵逼，就看数据来来回回，可是他看不懂，这样的中间人，只能算蠢萌的中转人，这也就是使用了HTTPS之后，packetCapture截取到的数据都是乱码的原因。

第二种：客户端say hello 后，被代理服务器拦截，代理服务器也有CA颁发的证书，他把自己的合法证书发给客户端，客户端用证书里面的公钥解密签名之后，得到了各种信息，一看信息都对上了，没毛病信任。然后代理服务器宰相真正的服务器say hello，服务器下发真正的证书，代理服务器假装自己是客户端，信任了证书，然后校验通过，发用真正公钥加密后的随机数给服务器，服务器当然能解开，也就是代理服务器作为客户端和真正的服务器建立了合法的通信。再看客户端在校验了代理服务器自己的证书后也建立了合法的通信，这个时候，代理服务器作为中间人，因为他有自己的私钥和真正的公钥，可以欺上瞒下，俩边的信息都从它这里过了一次，信息被他偷窥到。攻击成功。

怎么防御/h3>

客户端内置真正的公钥，当代理服务器把它自己的证书传过来的时候，客户端用内置的公钥去解密证书中的签名，因为不是真正的私钥加密的所以解密失败，校验也就失败，连接中断。这也就是客户端信任所有的证书的风险—被中间人攻击。

客户端如果没有内置公钥可以使用HTTPS么/h2>

解析到这里，想必大家也知道第三个问题的答案 ：客户端如果没有内置公钥可以使用HTTPS么然可以，只是不安全，会被MITM。

握手不成功常见问题

配置好了之后还是连不上，一般会是下面几种问题：

• 版本不一致，有一方的版本太低，另一方为了安全不同意跟它通信
• 无法就cipher suite达成一致，有一方支持的加密算法太弱，安全程度不够
• 证书有问题，没法通过验证
• 服务器端需要验证客户端的证书，而客户端没有配置

参考链接

HTTP和HTTPS协议，看一篇就够了
想不通HTTPS如何校验证书合法性来看
SSL/TLS 双向认证(一) – SSL/TLS工作原理
SSL/TLS及证书概述

文章知识点与官方知识档案匹配，可进一步学习相关知识网络技能树认识身边的计算机网络常见的网络设备22712 人正在系统学习中

来源：InfiniteYuan