HTTPS-PKI笔记

1. 前置知识

• 机密性：对称加密
• 完整型：消息验证码（MAC）
• 可用性：数字签名（DSA）

1.1. DH密钥协商算法

通讯双方任何一方无法独自计算出一个会话密钥，通讯双方各自保留一部分关键信息，再讲另外一部分信息告诉对方，双方有了全部信息才能计算出相同的会话秘钥

---

ECC算法和DH结合使用，用于密钥磋商，这个密钥交换算法称为ECDH。交换双方可以在不共享任何秘密的情况下协商出一个密钥

由于 ECDH 密钥交换协议不验证公钥发送者的身份，因此无法阻止中间人攻击。如果监听者 Mallory 截获了 Alice 的公钥，就可以替换为他自己的公钥，并将其发送给 Bob。Mallory 还可以截获 Bob 的公钥，替换为他自己的公钥，并将其发送给 Alice。这样，Mallory 就可以轻松地对 Alice 与 Bob 之间发送的任何消息进行解密。他可以更改消息，用他自己的密钥对消息重新加密，然后将消息发送给接收者。

为了解决此问题，Alice 和 Bob 可以在交换公钥之前使用数字签名对公钥进行签名。有两种方法可以实现此目的：

• 用安全的媒体（例如语音通信或可信载运商）在双方之间传输数字签名密钥。
• 使用公共证书颁发机构 (CA) 向双方提供可信数字签名密钥。

1.2. PKI(Public Key Infrastructure，公钥基础设施)

1.2.1. 意义

To enable the validation of, and to give legal meaning to digital signatures.

• To allows mutual authentication using public-key technology.
• Does not dictate the use of a specific public-key cryptographic algorithm, nor does it define a specific hash algorithm

实现数字签名的验证，并赋予数字签名以法律意义。

• 允许使用公钥技术进行相互认证。
• 不规定使用特定的公钥加密算法，也不定义特定的哈希算法。

安全性来源

• 法律
• 自身私钥安全

1.2.2. 证书

• 证书标准规范X.509
  • 版本号(Version Number）
  • 序列号（Serial Number）：由CA维护的为它所发的每个证书分配的一的列号，用来追踪和撤销证书。
  • 签名算法（Signature Algorithm）
  • 颁发者（Issuer）
  • 主体(Subject) : 证书拥有者的标识信息（Distinguished Name），如："C=CN，ST=Beijing, L=Beijing, CN=person.org.example.com”；
    • 域名
    • 公司信息
  • 主体的公钥信息(SubJect Public Key Info）
    • Issuer Unique Identifier
    • 主体公钥（Subject Unique Identifier）：公钥的内容
    • Ext:
      • 公钥算法 (Public Key Algorithm) …
  • CA’s Signature
• X.509 BASE64编码(PEM格式)，后缀为：.pem .cer .crt
  • PEM：Privacy Enhanced Mail

-----BEGIN CERTIFICATE-----
asdasdasdasd
...
asdasdasd
-----END CERTIFICATE-----

• SSL证书通用名（CN）通配符

  SSL通配符证书是在一个单一的证书中，在通用名（域名）中包含一个“*”通配符字段。这使得该证书可以保护无限数量的多个子域名（主机）。例如，一个通配符证书*. domain.com ，可用于www.domain.com ， mail.domain.com ，pay.domain.com …

1.2.3. CA(Certificate Of Authority,认证中心)

所谓的CA，通俗来说就是担保人，互联网上所有身份的担保人。 trusted party.

比如说Google需要向用户证明自己是Google，那么Google就需要找到一家靠谱的CA，请工作人员核对各项手续和身份证明，然后为Google签发一张数字证书（Certificate）。在证书上,记载着Google的所有身份信息，和一个CA签下的数字签名（Signature）。

而CA的私钥（Private Key），是用来签名的一段二进制数据，通俗来说就是CA手里的那根签字笔。一旦这根签字笔外泄出去，那么攻击者就能够随心所欲地签发任何证书，伪装成Google、微软、中国银行等任何一家公司/机构，直接颠覆整个互联网的信用体系。用户将无法分辨网线对面到底是银行还是黑客，只能任人宰割，这可以说是不亚于“互联网崩溃”级别的大地震。

工作内容：

• CA’s signature provides secure binding of the public key with its rightful owner’s identity.

1.2.4. RA

RA扮演的角色相当于是一个防火墙或者说签证官，所有的申请都要先交给RA。审核通过之后，申请才会被上呈到CA手里等待确认。在CA和RA之间，存在一条双向认证的保密信道。只有手握RA私钥的人，才会被当做RA来对待，才有资格向上提交申请。这就保证了CA的通信接口不会直接对外暴露，减少了防守方的工作压力

1.3. 自签名证书

如果不面对公众服务，仅面对小部分的内网服务，那是没问题的，没必要去买证书

在客户机上安装用于签发证书的CA到可信区域即可

• 通过openssl生成证书

1.4. 证书链

根证书

根证书是CA认证中心给自己颁发的证书,是信任链的起始点。安装根证书意味着对这个CA认证中心的信任

中间证书

证书颁发机构（CA）不会直接从根目录颁发服务器证书（即SSL证书），因为这种行为是存在不安全因素，因为一旦发生错误颁发或者需要撤销root,则使用root签名的每个证书都会被撤销信任。

因此，为了避免这种风险发生，CA机构一般会引用中间根。CA机构使用其私钥对中间根进行签名，使浏览器信任中间根。然后CA机构使用中间根证书的私钥来签署用户申请的SSL证书。这种中间根的形式可以重复多次，即使用中间根签署另一个中间件，然后CA机构通过中间件签署SSL证书

证书链(Certificate Chain)

信任锚证书CA 环节可以对中间证书签名；中间证书的所有者可以用自己的私钥对另一个证书签名

Web 浏览器已预先配置了一组浏览器自动信任的根 CA 证书。来自其他证书授权机构的所有证书都必须附带证书链，以检验这些证书的有效性

---

Starting from the top: Root CA issues certificates to sub CAs, which issues certificates to sub-sub CAs, and …., finally down to the end users. This sequence of certificates forms a Chain of Trust or Certificate Chain. 本质上就是不停的发证书

• Alice’s Certificate Chain

查看浏览器受“信任的根证书颁发机构”列表

1.5. 撤销（Revocation）

原因

• The user’s private key is believed to have been compromised（泄露）.
• The CA’s private key is believed to have been compromised.
• The user should no longer be certified by this CA.
• The user no longer needs this certificate.
• etc

防止抵赖和否认（protection against repudiation, or false denial）

证书吊销列表(CRL)

证书吊销列表 (Certificate Revocation List ，简称： CRL) 是 PKI 系统中的一个结构化数据文件，该文件包含了证书颁发机构 (CA) 已经吊销的证书的序列号及其吊销日期。

CA系统生成CRL以后，放到LDAP服务器中或Web服务器的合适位置，供用户查询或下载

1.6. 过程

• LDPA：Lightweight Directory Access Protocol（轻量目录访问协议）

1.6.1. 证书申请过程

• 用户申请
  • 公钥和自己的身份信息 => 安全服务器
  • 安全服务器 => RA
• RA审核
  • 如果RA同意用户申请证书的请求，则对证书申请信息做数字签名；否则拒绝用户的申请
• CA发行证书
  • 用户申请和RA签名 => CA
  • CA对RA数字签名做认证，如果验证通过，则同意用户请求，颁发证书，然后将证书输出。如果验证不通过，则拒绝证书申请
• RA转发证书
  • 首先将证书输出到LDAP服务器以提供目录浏览
  • 知用户证书发行成功，告知证书序列号，到指定的网址去下载证书
• 用户证书获取
  • 用户使用证书序列号去指定网址下载自己的数字证书，只有持有与申请时提交的公钥配对的私钥才能下载成功

1.6.2. 证书验证过程

接收方收到消息证书后，使用CA公钥对数字签名解密生成消息摘要，对证书内容进行hash生成摘要，两份摘要进行比对可证明证书内容的完整性与真实性（具体还要看日期、找LDAP服务器验证CRl等等等）

• 使用CA私钥进行签名和公钥解密，可以证明证书确实是由CA发布的（CA的公钥一般来说由浏览器开发商内置在浏览器的内部）
• 两份摘要的对比结果，可以证明证书内容是否在传输过程中被改动

X.509 - Authentication

1.6.3. 证书撤销过程

• 用户申请：用户向RA发送一封签名加密邮件，申请撤销证书。
• RA审核：注册机构同意证书撤销，并对申请签名。
• CA更新CRL：CA验证证书撤销请求的RA签名，如果正确，则同意申请，并更新CRL，并输出。
• RA转发CRL：注册中心收到CRL，以多种方式将CRL公布（包括LDAP服务器）。
• 用户告知：用户访问LDAP服务器，下载或浏览CRL。

2. 基本内容

2.1. http

<method><request-URL><version>
<headers>

<entity-body>

2.2. https

2.2.1. 证书验证阶段

• 浏览器发起 HTTPS 请求
  • 支持的加密以及版本
• 服务端返回 HTTPS 证书
• 客户端验证证书是否合法（根ca），如果不合法则提示告警

2.2.2. 数据传输阶段

• 当证书验证合法后，在本地生成随机数

• 通过证书公钥加密随机数，并把加密后的随机数传输到服务端

• 服务端通过私钥对随机数进行解密

• 服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

  • 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送
  • 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验

• 四次握手后；用”会话密钥”加密内容

3. 哪些没加密

• 只有ip和端口不加密，其他的都加密了
  • domain（域）暴露，path（目录）不暴露

While HTTPS encrypts the entire HTTP request and response, the DNS resolution and connection setup can reveal other information, such as the full domain or subdomain and the originating IP address, as shown above.

Additionally, attackers can still analyze encrypted HTTPS traffic for “side channel” information. This can include the time spent on site, or the relative size of user input.

IP地址和目标域名在通信过程中未加密。 甚至加密的流量也可以间接显示某些信息，例如在网站上花费的时间，所请求的资源或提交的信息的大小

3.1. http攻击

3.2. HTTPS中间人攻击

• 没有对证书校验
  • 身份伪造
• 没有对主机名验证
  • 身份伪造
• CA被攻击导致私钥泄露
  • 中间人攻击（也就是身份伪造）

证书的作用不只是HTTPS加密。可以用于伪造VPN认证、文档、邮件、数字签名，借此实现潜入公司内网等目的。

为了获得SSL加密通信的内容，中间人需要获得加密所使用的会话密钥。中间人采用的方法是，装成目标网站，向客户端出示一个伪造的同名服务器数字证书。为了这个伪造的证书通过客户端的检验，中间人必须让签发这个伪证书的CA的根证书进入客户端的受信任列表

4. 参考

• 【深入浅出HTTPS】_屎蛋的铲屎官-CSDN博客
• CA 机构是如何保护自己私钥的？ - Gh0u1L5的回答 - 知乎
• PKI/CA工作原理及架构 - 简书
• 数字证书及CA详解_lk2684753的博客-CSDN博客
• The HTTPS-Only Standard - The HTTPS-Only Standard