HTTPS基础

转载自：https://www.jianshu.com/p/0e2583071886

本章是HTTPS那些事儿的第一篇文章，其他相关文章请参见：前言
本篇主要讲解Https的基础知识，涉及到以下几点：

• HTTP、SSL/TSL、HTTPS是什么
• HTTPS握手过程
• CA证书是什么

* 注意

本文纯手工打造，转载请注明出处。

HTTP、SSL/TSL、HTTPS是什么

1. HTTP是什么
   HTTP的全程是Hyper-Text Transfer Protocol，它可能是当今互联网上使用的最重要的协议。我们日常通过浏览器访问网站的时候使用的就是该协议，比如使用PC浏览器访问简书的首页，浏览器地址栏中会显示：https://www.jianshu.com/。我特意加粗了https，为什么是https不是http呢？请参见"HTTPS是什么"章节。
2. SSL/TSL是什么
   首先SSL是Secure Sockets Layer的缩写，中文翻译过来是“安全套接层”。它是在上世纪90年代中期，由网景公司设计的。设计该协议的目的是为了解决HTTP采用明文传输，所带来的传输内容会被偷窥（嗅探）和篡改的问题。
   在1999年，SSL 因为应用广泛，成为了互联网上的事实标准。IETF 决定把 SSL 标准化，标准化之后的名称改为 TLS（Transport Layer Security），中文翻译过来是“传输层安全协议”。为什么把SSL和TLS写成SSL/TLS呢，因为这两者其实是同一个东西，只不过是在发展到不同阶段，名称不同而已。
3. HTTPS是什么
   终于说到了重点HTTPS，HTTPS是什么呢？说白了HTTPS就是“HTTP 协议”和“SSL/TLS 协议”的组合，可以把 HTTPS 大致理解为——“HTTP over SSL”或“HTTP over TLS”（反正 SSL 和 TLS 差不多）。
   可以简单理解为在SSL之上传输HTTP协议，举个例子：可以把HTTP看成是纸质信封包装的信，可以被轻易打开并查看信的内容。SSL好比是装信封的保险箱，保险箱需要密码才能打开。加了保险箱之后的信件，需要有密码的人才能查看到，这样信件的传输就更加安全了。

HTTPS握手过程

前面说到SSL是为了解决HTTP明文传输带来的问题，所以SSL采用的是加密传输。发送方通过密钥加密明文，接收方通过密钥解密成明文。该密钥是传输成功的关键，那么这个密钥是怎么来的呢？这就涉及到我们所说的HTTPS握手了，握手结束后发送方和接收方就会得到密钥了。那么HTTPS的握手过程是怎么样的呢？

 

HTTPS握手（单向认证）

1). Client Hello
Client发起连接请求，请求参数包括客户端支持的TLS版本列表、加密算法列表、压缩算法列表、随机数random_C和一些扩展信息
2). Server Hello
Server接收到Client的Hello请求后，根据Server端的配置以及Client Hello发送的参数，筛选出与Client最兼容的TLS版本、加密算法版本、压缩算法版本以及随机数random_S
3). Server证书
向client端发送Server的CA证书
4). Server Hello Finish
通知Client端Server Hello信息发送结束
5). 校验Server证书
Client接收到Server证书后，通过本地的证书信任信息进行校验，确认Server的CA证书是否由可信机构颁发。除此之外，还会校验证书是否还在有效期、域名是否与当前访问域名匹配等
6). Client Key Exchange
Server的CA证书校验通过后，Client生成随机数Pre_Master，并采用Server证书中的公钥加密发送给Server端。此刻，客户端已经获取到全部的生成密钥需要的信息，则通过协商的算法生成通信密钥enc_key：

enc_key=Fuc(**random_C**, **random_S**, **Pre-Master**)

7). Change Cipher Spec
密钥enc_key生成后，通知Server后续的通信Client端都使用enc_key进行加密通信
8). Finish Handshake
结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，使用协商密钥 enc_key 与协商算法将其加密，然后发送给服务器用于验证服务端其生成的enc_key是否正确
9). Change Cipher Spec
Server接收到Client Handshake Finish消息后，生成自己的enc_key，并用enc_key验证Client Handshake Finish信息是否正确。如果正确，则通知Client后续通信Server端都使用协商密钥enc_key进行加密通信
10). Finish Handshake
Server也结合所有当前的通信参数信息生成一段数据并采用协商密钥 enc_key与协商算法加密，并发送到客户端
最后，Client端校验Server Finish Handshake信息，如果校验通过，则会将enc_key作为后续加密通信的密钥。

以上所描述的其实就是我们说所的单向认证过程，如果是双向认证，只是在单向认证的过程中增加Server端对Client端的证书认证过程而已。

CA证书是什么

HTTPS握手过程中，在第3步Server端会发送其CA证书到Client端。这里所说的CA证书的作用是用来证明当前访问的服务器是Client想要访问的服务器，而不是他人伪装成的假服务器。那么这个CA证书是什么呢？
举个生活中的例子：
在你去银行办卡的时候，你要怎么证明你是你呢？一般银行会要求你出示身份证，然后验证身份证是否可信，同时比对上面的照片是不是你。这里所说的身份证就是证明你是你的证据，与我们所说的CA证书作用相同。身份证有一个最大的特性：由国家所信任的公安部门颁发的，银行可以通过公安部门来校验你的身份证是否可信。
所以，为了使CA证书也被大家都信任的话，也引入了类似的机构，该机构称为CA（Certification Authority的简称），该结构颁发的证书称为CA证书。HTTPS握手过程中，Client端会通过本地的证书信任信息校验Server证书，这里所说的证书信任信息其实就是CA机构相关的信息。

CA证书怎么来？

Server端想要获取到CA证书，必须向CA机构提出申请，当CA机构审核通过后，才会为Server颁发证书。那么这个过程涉及到什么信息呢？
首先CA机构会有自己的公私钥ca.pub和ca.pri，Server也需要有自己的公私钥server.pub和server.pri。
在Server提出申请时，需要提供server.pub和服务器信息——明文信息（包括证书申请信息、证书颁发机构、证书过期时间等）。CA接收到请求后，通过各种手段确认Server信息的合法性，通过后会将明文做hash，然后再使用ca.pri对hash进行签名，最后将签名和明文信息明文放到一起，就是我们的CA证书。证书信息类似于下图：

 

CA证书结构

有了证书后，Server端就可以使用证书来发布服务了，Client在会使用CA机构公布的ca.pub对Server的CA证书进行校验：
首先将明文做hash得到h1，然后通过ca.pub来校验h1与证书中的签名，也就是公钥验签的过程。
如果你是JAVA开发人员，可以通过JDK提供的工具KeyTool模拟以上描述的证书申请过程，可以参考本系列的第四篇《使用keytool模拟CA证书颁发过程》。

 

总结

本篇对HTTP、SSL/TSL、HTTPS，以及HTTPS中设计的HTTPS握手和CA证书做了详细描述，解释了HTTPS相关的基本概念。本系列文章后续还会讲述java中的HTTPS那些事儿以及Spring的RestTemplate与HTTPS，如果有兴趣请参见后续文章。可通过此处寻找到本系列文章的目录。