HTTPS笔记

摘自维基百科

超文本传输安全协议(英语:HyperText Transfer Protocol Secure,缩写:HTTPS;常称为 HTTP over TLS、HTTP over SSL 或 HTTP Secure)是一种通过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信,但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的,是提供对网站服务器的身份认证,保护交换数据的隐私与完整性。这个协议由网景公司(Netscape)在 1994 年首次提出,随后扩展到互联网上。

为什么需要HTTPS

HTTP传输面临的风险有:

  1. 窃听风险:黑客可以获知通信内容。
  2. 篡改风险:黑客可以修改通信内容。
  3. 冒充风险:黑客可以冒充他人身份参与通信。

SSL/TSL

如上图所示 HTTPS 相比 HTTP 多了一层 SSL/TLS

SSL(Secure Socket Layer,安全套接字层):1994年为 Netscape 所研发,SSL 协议位于 TCP/IP 协议与各种应用层协议之间,为数据通讯提供安全支持。

TLS(Transport Layer Security,传输层安全):其前身是 SSL,它最初的几个版本(SSL 1.0、SSL 2.0、SSL 3.0)由网景公司开发,1999年从 3.1 开始被 IETF 标准化并改名,发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞,已经很少被使用到。TLS 1.3 改动会比较大,目前还在草案阶段,目前使用最广泛的是TLS 1.1、TLS 1.2。

加密算法

对称加密

有流式、分组两种,加密和解密都是使用的同一个密钥。

例如:DES、AES-GCM、ChaCha20-Poly1305等

非对称加密

加密使用的密钥和解密使用的密钥是不相同的,分别称为:公钥、私钥,公钥和算法都是公开的,私钥是保密的。非对称加密算法性能较低,但是安全性超强,由于其加密特性,非对称加密算法能加密的数据长度也是有限的。

例如:RSA、DSA、ECDSA、 DH、ECDHE

协议设计演变过程

按照上面讲的三个HTTP的传输风险,先来解决第一个问题,然后再去想办法解决第二个问题

注:这是经过我个人理解后的想法,并不是真实的标准。

不完全解决窃听风险

如果我们单纯的使用对称加密算法,按照上图来简单的设计。来加密协议的数据,是不能做到防窃听的,因为第四步中间人是可以接收到服务器公钥,那么服务器发来的数据中间人就可以解密。

而且非对称加密性能较低,在大量数据的传输情况下,这种情况是不理想的,那么这两个问题如何解决?

答案是协议”握手”阶段使用非对称加密加密,之后使用对称加密来加密数据。

  1. 客户端给服务端发送请求
  2. 服务端返回客户端自己的公钥
  3. 客户端产生本次对话的对称密钥 SK,并用公钥 进行加密得到 SK后传给服务端
  4. 服务端收到 SK后用自己的私钥解密得到 SK;若成功,则返回客户端 OK,否则终止对话
  5. 接下来,客户端和服务端的对话均用 SK 加密后传输。

注:这只是一种广泛应用的加密方式,DH加密方式详细可以了解完全吃透 TLS/SSL

解决窃听、篡改、冒充风险

在 HTTPS 的握手阶段,一端向对端发送请求,对端返回自己的公钥;而一端未验证对方的身份和公钥,直接协商密钥。“中间人”看到了这个漏洞,夹在中间截获了对端的公钥,替换成了自己的公钥。正是这步“拿错了公钥”或者说“信错了对端”,使得 HTTPS 为加密(密钥协商的非对称加密和通信数据的对称加密)所做的努力全部泡汤。

这个时候就第三方权威认证机构来证明”服务器”是”可信”的。

那么如何证明服务器是可信的呢?

CA机构

一个权威的认证机构。可以理解为我们老观念里面的讲话比较有威望的”长辈”,告诉你,这个人信得过的。

当然这个比喻可能不恰当,证书申请认证是有三种类型申请的,每种类型的要求也不一样。要求越高,那么这个证书越”可信”。

证书是什么

SSL 证书中包含的具体内容有:

  • 主体的必要信息:版本(version)、序列号(serialNumber)、签名算法(signatureAlgorithm)、颁发者(issuer)、有效期(validity)、使用者(subject)、公钥信息(subjectPublicKeyInfo)
  • 主体的扩展信息(extension):如密钥标识符、证书策略等
  • 数字签名(signature),也称指纹

抽象为下图:

签名计算的伪代码步骤如下:

1
signature = RSA(PriKey_CA, Hash(message))

数字签名生成过程是首先对原文作哈希,把一段不定长的文本映射成固定长度的字符空间,接着再用 CA 机构的私钥对这段定长字符做加密。大大提高了整体的运算效率。

证书的类型

国际主流CA签发的证书通过证书审核的内容划分为3种类型,分别是:DV,OV,EV类型。

  • DV类型证书:中文全称是域名验证型证书,证书审核方式为通过验证域名所有权即可签发证书。此类型证书适合个人和小微企业申请,价格较低,申请快捷,但是证书中无法显示企业信息,安全性较差。在浏览器中显示锁型标志。
  • OV类型证书:中文全称是企业验证型证书,证书审核方式为通过验证域名所有权和申请企业的真实身份信息才能签发证书。目前OV类型证书是全球运用最广,兼容性最好的证书类型。此证书类型适合中型企业和互联网业务申请。在浏览器中显示锁型标志,并能通过点击查看到企业相关信息。支持ECC高安全强度加密算法,加密数据更加安全,加密性能更高。
  • EV类型证书:中文全称是增强验证型证书,证书审核级别为所有类型最严格验证方式,在OV类型的验证基础上额外验证其他企业的相关信息,比如银行开户许可证书。EV类型证书多使用于银行,金融,证券,支付等高安全标准行业。其在地址栏可以显示独特的EV绿色标识地址栏,最大程度的标识出网站的可信级别。支持ECC高安全强度加密算法,加密数据更加安全,加密性能更高。

证书类型的选择一般可以根据申请方的身份类型来进行简单区分:个人申请DV类型证书,中小企业选择OV类型证书,大型企业和银行,金融,支付等行业申请EV类型证书。如果您不清楚自己的行业该如何申请证书,也可以拿同行业的企业证书申请类型进行参考。

申请证书

总结申请证书的过程:用户向 CA 机构提交自己的信息(如域名)和公钥(用户自己生成的非对称加密公钥,用于 TLS 握手阶段和另一端协商密钥用),CA 机构生成数字证书,如下图:

验证证书

收到对端发过来的证书,执行证书申请的“逆过程”即可,总结如下图:

验证数字签名。接受证书的一端先对除数签名的其他部分做一次相同的哈希算法(证书中指明了哈希算法),得到这段文本的哈希映射,记作 H1;获取 CA 机构的公钥对数字签名属性做解码,得到了 CA 机构计算出的哈希映射,记作 H2。对比 H1 和 H2 两个字符串是否严格相等,若是,代表该证书的信息未被篡改,证书有效;否则,证书内容被篡改,证书无效。

若证书有效,接受端会再进行对端的身份校验(验证域名),若身份验证通过,接收端会拿证书上的公钥(也是对端自己生产的非对称加密公钥)加密接下来整个 TLS 握手阶段的信息之后,发送给对端。

这个过程中有一个问题:CA 机构的公钥怎么获取?
回答:提前内置。

操作系统和浏览器在软件安装阶段会在其特定目录下放置一堆的证书。如 Windows 的根证书管理在 certmgr 下:

这些证书都有个特点:权威 CA 机构发布的根证书(Root Certificate)。根证书有几个特点:

  • 没有上层机构再为其本身作数字签名
  • 证书上的公钥即为 CA 机构发布的公钥
  • 权威 CA 机构的自签证书

而这些根证书会跟很多软件,包括操作系统、浏览器一起被安装到用户设备上。即使没有被提前安装好,这些根证书也可以在 CA 机构的官网上获取得到。

注:TLS1.3目前还没时间研究。变化比较大。

以上内容全部摘自: