在推动公司的全站 HTTPS + HSTS ，整理用到的知识，供以后查阅只用。
1. HTTP 背景知识
1.1 HTTP/0.9
单行协议，极其简单。
请求：由单行指令构成，以唯一可用方法 GET 开头，其后跟目标资源路径
GET /mypage.html
响应：只包含响应文档本身
<HTML>
这是一个非常简单的HTML页面
</HTML>
缺点：
- 只能传输 HTML 文件，无法传输其他类型的文件
- 无法判断请求执行的结果
1.2 HTTP/1.0
构建可扩展性，HTTP/1.0 扩展了以下的内容，使之用途更广泛：
- 发送信息中包含协议版本信息
- 增加状态码用于代表执行结果的成功或者失败
- 引入 HTTP 头的概念，对于请求和响应，允许传输元数据，使协议变得更灵活，扩展性更强
- 在 HTTP 头中增加 Content-Type 类型，具备了传输其他类型文档的能力
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
一个包含图片的页面
<IMG SRC="/myimage.gif">
</HTML>
缺点：
- 以上新扩展作为一种尝试出现，并未被引入到标准中
1.3 HTTP/1.1
标准化的协议，HTTP/1.0 多种不同的实现方式在实际运行中显得十分混乱，HTTP/1.1 统一了标准并引入多项的改进内容：
- 默认长连接机制，节省多次 TCP 连接建立消耗的时间
- Pipelie 机制，允许第一个应答被完全发送之前就发送第二个请求
- Chunked 编码传输
- Header 中引入 host
- 更详细的 Cache 机制
一次完整的请求流程如下：
GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
(content)
注意
- HTTP 协议已经稳定使用超过 15 年，期间进行过两次修订RFC 2616 发布于1999年6月，而另外两个文档 RFC 7230-RFC 7235 发布于2014年6月
- 由于 HTTP 协议明文传输数据，基于安全的考虑，网景公司在 HTTP 的基础上创建了一个额外的加密传输层：SSL。（SSL 1.0 没有在公司以外发布过）
1.4 HTTP2
为了更优异的表现，谷歌实践了一个实验性的协议 SPDY 协议旨在解决 HTTP/1.x 中存在的诸如连接复用、头部冗余等问题。SPDY 协议位于 HTTP 和 SSL 之间，属于应用层协议，主要特性如下：
- 多路复用
- 请求优先级
- header 压缩
- 服务端推送
SPDY 协议成为了 HTTP/2 协议的基础，可以看到 HTTP2 协议的很多特性跟 SPDY 协议提供的是有主体是重合的，但仍有少许差异点：
- HTTP/2 可以在 TCP 上直接使用，不像 SPDY 那样必须在 TLS 上
- 添加了新的头部压缩算法 HPACK
- 添加了控制帧的种类
- 完善协议商讨和 Server Push 的流程
2. HTTPS 出现的原因
2.1 原因
一种新技术的出现必然是因为当前技术无法满足当时社会的要求。从安全性的角度对比下 HTTP 和 HTTPS 协议：
| 安全性 | HTTP | HTTPS |
|---|---|---|
| 窃听风险 | 信息明文传递，可被拦截窃听 | 信息加密传输 |
| 篡改风险 | 被拦截下的信息可被篡改 | 信息校验，接收方可通过校验机制发现篡改行为 |
| 伪装风险 | 无法验证对端的真实性 | 身份校验 |
注意：
- 由于对数据进行加解密，决定了它天生比 HTTP 慢
2.2 HTTPS 协议组成
HTTPS 是在 HTTP 上建立 SSL/TLS 加密层，并对传输数据进行加密。
SSL/TLS 协议的基本过程是：
- 客户端向服务端索要并验证公钥
- 双方协商生产「对话密钥」
- 双方使用对话密钥通信
步骤1、2 为「握手阶段」，完成的详细过程见下图：
注 「握手阶段」所有的通信都是明文的
- （ClientHello）客户端向服务端提供以下信息：
- 支持的协议版本
- 客户端生成的随机数，稍后用于生成「对话密钥」
- 支持的加密方法
- 支持的压缩方法
- （ServerHello）服务端回应：
- 确认使用的加密通信协议版本
- 服务端生成的随机数，稍后用于生成「对话密钥」
- 确定使用的加密方法
- 服务器证书
- 客户端回应
- 一个随机数。用于服务器公钥加密，防止被窃听
- 编码改变通知，表示随后的信息都将用双方协商好的加密方法和密钥发送
- 客户端握手结束通知，表示客户端的握手阶段已经结束
- 服务器最后回应
- 编码改变通知，表示随后的信息都将用双方协商好的加密方法和密钥发送
- 服务器握手结束通知，表示服务器的握手阶段已经结束。
以上是从理论的层面上大致了解了下 SSL/TLS 做了什么，后面文章会从实际使用中抓包分析真实过程。
3. HSTS 解决了什么问题
3.1 概念
HSTS HTTP 严格传输安全，网站可以选择使用 HSTS 策略，来让浏览器强制使用 HTTPS 与网站进行通信，以减少回话被劫持的风险。
3.2 作用
抵御 SSL 剥离攻击， SSL剥离的实施方法是阻止浏览器与服务器创建HTTPS连接。它的前提是用户很少直接在地址栏输入https://，用户总是通过点击链接或3xx重定向，从HTTP页面进入HTTPS页面。所以攻击者可以在用户访问HTTP页面时替换所有https://开头的链接为http://，达到阻止HTTPS的目的。
HSTS 可以很大程度上解决 SSL 剥离攻击，因为只要浏览器与服务器创建过一次安全连接，之后浏览器会强制使用 HTTPS。
4. 待扩展知识点
- 长连接 & Pipelie 机制
- SPDY 协议
- SSL & TLS 协议实现
- HSTS demo
175
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
