HTTPS基础讲解

目录

• 1 HTTPS
  • 1.1 为什么需要https
    • 1.1.1 引言
    • 1.1.2 http中间攻击
    • 1.1.3 防止中间人攻击
  • 1.2 HTTPS如何保障安全
    • 1.2.1 TLS/SSL
    • 1.2.2 传输加密的流程
    • 1.2.3 通过证书防止中间人攻击
  • 1.3 HTTPS如何加密数据
    • 1.3.1 对称加密
    • 1.3.2 非对称加密
    • 1.3.3 HTTPS通讯流程
  • 1.4 证书
    • 1.4.1 证书简介
    • 1.4.2 数字签名与摘要
    • 1.4.3 证书格式
    • 1.4.4 如何辨别非法证书
      • 1.4.4.1 完全伪造的证书
      • 1.4.4.2 篡改过的证书

1 HTTPS

点击了解HTTP基础知识

1.1 为什么需要https

1.1.1 引言

HTTP是明文传输的，也就意味着，介于发送端、接收端中间的任意节点都可以知道传输的内容是什么。这些节点可能是路由器、代理等。
举个最常见的例子，用户登陆。用户输入账号，密码，采用HTTP的话，只要在代理服务器上做点手脚就可以拿到你的密码了。
用户登陆 --> 代理服务器（做手脚）--> 实际授权服务器
在发送端对密码进行加密？没用的，虽然别人不知道你原始密码是多少，但能够拿到加密后的账号密码，照样能登陆

1.1.2 http中间攻击

HTTP 协议使用起来确实非常的方便，但是它存在一个致命的缺点：不安全。
我们知道 HTTP 协议中的报文都是以明文的方式进行传输，不做任何加密，这样会导致什么问题呢？下面来举个例子：

小明在 JAVA 贴吧发帖，内容为我爱JAVA：

被中间人进行攻击，内容修改为我爱PHP

可以看到在 HTTP 传输过程中，中间人能看到并且修改 HTTP 通讯中所有的请求和响应内容，所以使用 HTTP 是非常的不安全的。

1.1.3 防止中间人攻击

这个时候可能就有人想到了，既然内容是明文那我使用对称加密的方式将报文加密这样中间人不就看不到明文了吗，于是如下改造：

双方约定加密方式

使用 AES 加密报文

这样看似中间人获取不到明文信息了，但其实在通讯过程中还是会以明文的方式暴露加密方式和秘钥，如果第一次通信被拦截到了，那么秘钥就会泄露给中间人，中间人仍然可以解密后续的通信：

那么对于这种情况，我们肯定就会考虑能不能将秘钥进行加密不让中间人看到呢？答案是有的，采用非对称加密，我们可以通过 RSA 算法来实现。

在约定加密方式的时候由服务器生成一对公私钥，服务器将公钥返回给客户端，客户端本地生成一串秘钥(AES_KEY)用于对称加密，并通过服务器发送的公钥进行加密得到(AES_KEY_SECRET)，之后返回给服务端，服务端通过私钥将客户端发送的AES_KEY_SECRET进行解密得到AEK_KEY,最后客户端和服务器通过AEK_KEY进行报文的加密通讯，改造如下：

可以看到这种情况下中间人是窃取不到用于AES加密的秘钥，所以对于后续的通讯是肯定无法进行解密了，那么这样做就是绝对安全了吗？

所谓道高一尺魔高一丈，中间人为了对应这种加密方法又想出了一个新的破解方案，既然拿不到AES_KEY，那我就把自己模拟成一个客户端和服务器端的结合体，在用户->中间人的过程中中间人模拟服务器的行为，这样可以拿到用户请求的明文，在中间人->服务器的过程中中间人模拟客户端行为，这样可以拿到服务器响应的明文，以此来进行中间人攻击：

这一次通信再次被中间人截获，中间人自己也伪造了一对公私钥，并将公钥发送给用户以此来窃取客户端生成的AES_KEY，在拿到AES_KEY之后就能轻松的进行解密了。

中间人这样为所欲为，就没有办法制裁下吗，当然有啊，接下来我们看看 HTTPS 是怎么解决通讯安全问题的。

1.2 HTTPS如何保障安全

HTTPS其实就是 secure http 的意思啦，也就是HTTP的安全升级版。稍微了解网络基础的都知道，HTTP是应用层协议，位于HTTP协议之下是传输协议TCP。TCP负责传输，HTTP则定义了数据如何进行包装。
HTTP --> TCP （明文传输）
HTTPS相对于HTTP有哪些不同呢？其实就是在HTTP跟TCP中间加多了一层加密层TLS/SSL 。

1.2.1 TLS/SSL

通俗的讲，TLS、SSL其实是类似的东西，SSL是个加密套件，负责对HTTP的数据进行加密。TLS是SSL的升级版。现在提到HTTPS，加密套件基本指的是TLS。
HTTPS 其实是SSL+HTTP的简称,当然现在SSL基本已经被TLS取代了，不过接下来我们还是统一以SSL作为简称，SSL协议其实不止是应用在HTTP协议上，还在应用在各种应用层协议上，例如：FTP、WebSocket。
其实SSL协议大致就和上一节非对称加密的性质一样，握手的过程中主要也是为了交换秘钥，然后再通讯过程中使用对称加密进行通讯，大概流程如下：

1.2.2 传输加密的流程

原先是应用层将数据直接给到TCP进行传输，现在改成应用层将数据给到TLS/SSL，将数据加密后，再给到TCP进行传输。
大致如图所示

就是这么回事。将数据加密后再传输，而不是任由数据在复杂而又充满危险的网络上明文裸奔，在很大程度上确保了数据的安全。这样的话，即使数据被中间节点截获，坏人也看不懂。

1.2.3 通过证书防止中间人攻击

中间人获取信息后，模拟客户端和服务器，并使用伪造的服务器证书发送给客户端的情况，是一种常见的中间人攻击手法。为了避免这种情况，SSL/TLS 协议和浏览器等客户端采取了多种措施：

• 证书链验证
  客户端会验证服务器证书是否由受信任的证书颁发机构（CA）签署。证书链验证过程如下：
  服务器提供的证书会包括一个完整的证书链，根证书在客户端的受信任证书库中。
  客户端验证从服务器证书到根证书的整个链条。如果任意一个证书不匹配或无效，连接将被终止。
• 证书透明度（Certificate Transparency, CT）
  这是一个公开的日志系统，所有颁发的证书都会被记录在透明日志中。客户端可以检查收到的证书是否在这些日志中，并验证其合法性。通过这种方式，可以防止恶意CA颁发伪造的证书。
• 在线证书状态协议（Online Certificate Status Protocol, OCSP）
  OCSP用于检查证书是否被吊销。客户端在连接服务器时，会请求OCSP响应，确认证书仍然有效。如果证书被吊销，客户端将拒绝连接。
• HTTP严格传输安全（HTTP Strict Transport Security, HSTS）
  HSTS允许服务器告知浏览器只能通过HTTPS连接，并拒绝所有HTTP连接。这可以防止降级攻击，中间人无法通过强制降级到HTTP来进行中间人攻击。
• 证书钉扎（Certificate Pinning）
  证书钉扎将特定服务器的证书或公钥绑定到客户端，确保只有特定的证书或公钥可以用于该服务器。即使中间人使用伪造的证书，也无法通过验证。
• 域名系统安全扩展（DNSSEC）
  DNSSEC通过对DNS数据进行签名，确保DNS响应的真实性和完整性，防止中间人篡改DNS记录并进行流量劫持。
• 双因素认证（2FA）
  即使在建立安全连接后，中间人成功截获了会话，双因素认证提供了额外的安全层，防止未经授权的访问

1.3 HTTPS如何加密数据

对安全或密码学基础有了解的同学，应该知道常见的加密手段。一般来说，加密分为对称加密、非对称加密（也叫公开密钥加密）。

1.3.1 对称加密

对称加密的意思就是，加密数据用的密钥，跟解密数据用的密钥是一样的。
对称加密的优点在于加密、解密效率通常比较高。缺点在于，数据发送方、数据接收方需要协商、共享同一把密钥，并确保密钥不泄露给其他人。此外，对于多个有数据交换需求的个体，两两之间需要分配并维护一把密钥，这个带来的成本基本是不可接受的
点击了解加密之对称Base64,DES,PBE

1.3.2 非对称加密

非对称加密的意思就是，加密数据用的密钥（公钥），跟解密数据用的密钥（私钥）是不一样的。
什么叫做公钥呢？其实就是字面上的意思——公开的密钥，谁都可以查到。因此非对称加密也叫做公开密钥加密。
相对应的，私钥就是非公开的密钥，一般是由网站的管理员持有。
公钥、私钥两个有什么联系呢？
简单的说就是，通过公钥加密的数据，只能通过私钥解开。通过私钥加密的数据，只能通过公钥解开。
很多同学都知道用私钥能解开公钥加密的数据，但忽略了一点，私钥加密的数据，同样可以用公钥解密出来。而这点对于理解HTTPS的整套加密、授权体系非常关键。
点击了解加密之非对称RSA,DH,DSA,ECC

1.3.3 HTTPS通讯流程

概括来说，现在网络HTTPS简化的加密通信的流程就是：

• 客户访问某网站X，网站将自己的证书给到客户（其实是给到浏览器，客户不会有感知）
• 浏览器从证书中拿到某网站X的公钥A
• 浏览器生成一个只有自己知道的对称密钥B，用公钥A加密，并传给某网站X（其实是有协商的过程，这里为了便于理解先简化）
• 某网站X通过私钥解密，拿到对称密钥B
• 浏览器、 某网站X之后的数据通信，都用密钥B进行加密

注意：对于每个访问某网站X的用户，生成的对称密钥B理论上来说都是不一样的。比如客户1、客户2、客户3，可能生成的就是B1、B2、B3.
参考下图：（附上 原图出处 ）

1.4 证书

1.4.1 证书简介

在正式介绍证书的格式前，科普下数字签名和摘要，然后再对证书进行介绍。
为什么呢？因为数字签名、摘要是证书防伪非常关键的武器。

1.4.2 数字签名与摘要

简单的来说，摘要就是对传输的内容，通过hash算法计算出一段固定长度的串（是不是联想到了文章摘要）。然后，在通过CA的私钥对这段摘要进行加密，加密后得到的结果就是数字签名

明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名

结合上面内容，我们知道，这段数字签名只有CA的公钥才能够解密。
接下来，我们再来看看神秘的“证书”究竟包含了什么内容，然后就大致猜到是如何对非法证书进行预防的了。
加密之数字证书和PFX信息交换

1.4.3 证书格式

证书格式来自这篇不错的文章《 OpenSSL 与 SSL 数字证书概念贴 》(直接百度即可)
内容非常多，这里我们需要关注的有几个点：

• 证书包含了颁发证书的机构的名字 -- CA(证书颁发机构)
• 证书内容本身的数字签名（用CA(证书颁发机构)私钥加密）
• 证书持有者的公钥
• 证书签名用到的hash算法

此外，有一点需要补充下，就是：

• CA(证书颁发机构)本身有自己的证书，江湖人称“根证书”。这个“根证书”是用来证明CA(证书颁发机构)的身份的，本质是一份普通的数字证书。
• 浏览器通常会内置大多数主流权威CA(证书颁发机构)的根证书。

主要的证书格式：

1. 证书版本号(Version)
   版本号指明X.509证书的格式版本，现在的值可以为:
   0: v1
   1: v2
   2: v3
   也为将来的版本进行了预定义

2. 证书序列号(Serial Number)
   序列号指定由CA(证书颁发机构)分配给证书的唯一的"数字型标识符"。当证书被取消时，实际上是将此证书的序列号放入由CA(证书颁发机构)签发的CRL中，这也是序列号唯一的原因。

3. 签名算法标识符(Signature Algorithm)
   签名算法标识用来指定由CA(证书颁发机构)签发证书时所使用的"签名算法"。算法标识符用来指定CA签发证书时所使用的:
   公开密钥算法，hash算法

4. 签发机构名(Issuer)
   此域用来标识签发证书的CA的X.500 DN(DN-Distinguished Name)名字。包括:
   国家(C)、省市(ST)、地区(L)、组织机构(O)、单位部门(OU)、通用名(CN)、邮箱地址

5. 有效期(Validity)
   指定证书的有效期，包括:
   证书开始生效的日期时间、证书失效的日期和时间
   每次使用证书时，需要检查证书是否在有效期内。

6. 证书用户名(Subject)
   指定证书持有者的X.500唯一名字。包括:
   国家(C)、省市(ST)、地区(L)、组织机构(O)、单位部门(OU)、通用名(CN)、邮箱地址

7. 证书持有者公开密钥信息(Subject Public Key Info)
   证书持有者公开密钥信息域包含两个重要信息:
   证书持有者的公开密钥的值、公开密钥使用的算法标识符。
   此标识符包含公开密钥算法和hash算法。

8. 扩展项(extension)
   X.509 V3证书是在v2的基础上一标准形式或普通形式增加了扩展项，以使证书能够附带额外信息。
   标准扩展是指由X.509 V3版本定义的对V2版本增加的具有广泛应用前景的扩展项，任何人都可以向一些权威机构，如ISO，来注册一些其他扩展，如果这些扩展项应用广泛，也许以后会成为标准扩展项。

9. 签发者唯一标识符(Issuer Unique Identifier)
   签发者唯一标识符在第2版加入证书定义中。此域用在当同一个X.500名字用于多个认证机构时，用一比特字符串来唯一标识签发者的X.500名字。可选

10. 证书持有者唯一标识符(Subject Unique Identifier)
    持有证书者唯一标识符在第2版的标准中加入X.509证书定义。此域用在当同一个X.500名字用于多个证书持有者时，用一比特字符串来唯一标识证书持有者的X.500名字。可选。

11. 签名算法(Signature Algorithm)
    证书签发机构对证书上述内容的签名算法
    example: sha256WithRSAEncryption

12. 签名值(Issuer's Signature)
    证书签发机构对证书上述内容的签名值

1.4.4 如何辨别非法证书

上面提到，某网站X证书包含了如下内容：

1. 证书包含了颁发证书的机构的名字 -- CA
2. 证书内容本身的数字签名（用CA私钥加密）
3. 证书持有者的公钥
4. 证书签名用到的hash算法

浏览器内置的CA的根证书包含了如下关键内容：CA的公钥
好了，接下来针对之前提到的两种非法证书的场景，讲解下怎么识别

1.4.4.1 完全伪造的证书

这种情况比较简单，对证书进行检查：

1. 证书颁发的机构是伪造的：浏览器不认识，直接认为是危险证书
2. 证书颁发的机构是确实存在的，于是根据CA名，找到对应内置的CA根证书、CA的公钥。
3. 用CA的公钥，对伪造的证书的摘要进行解密，发现解不了。认为是危险证书

1.4.4.2 篡改过的证书

假设代理通过某种途径，拿到某网站X的证书，然后将证书的公钥偷偷修改成自己的，然后认为用户要上钩了，其实浏览器会如下操作：

1. 检查证书，根据CA名，找到对应的CA根证书，以及CA的公钥。
2. 用CA的公钥，对证书的数字签名进行解密，得到对应的证书摘要AA
3. 根据证书签名使用的hash算法，计算出当前证书的摘要BB
4. 对比AA跟BB，发现不一致--> 判定是危险证书