mod

极客时间专栏/透视HTTP协议/安全篇/23 | HTTPS是什么？SSL|TLS又是什么？.md

@@ -0,0 +1,138 @@
+<audio id="audio" title="23 | HTTPS是什么？SSL/TLS又是什么？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/60/27/606366f47954111645ec28ffab6f4127.mp3"></audio>
+
+从今天开始，我们开始进入全新的“安全篇”，聊聊与安全相关的HTTPS、SSL、TLS。
+
+在[第14讲](https://time.geekbang.org/column/article/103746)中，我曾经谈到过HTTP的一些缺点，其中的“无状态”在加入Cookie后得到了解决，而另两个缺点——“明文”和“不安全”仅凭HTTP自身是无力解决的，需要引入新的HTTPS协议。
+
+## 为什么要有HTTPS？
+
+简单的回答是“**因为HTTP不安全**”。
+
+由于HTTP天生“明文”的特点，整个传输过程完全透明，任何人都能够在链路中截获、修改或者伪造请求/响应报文，数据不具有可信性。
+
+比如，前几讲中说过的“代理服务”。它作为HTTP通信的中间人，在数据上下行的时候可以添加或删除部分头字段，也可以使用黑白名单过滤body里的关键字，甚至直接发送虚假的请求、响应，而浏览器和源服务器都没有办法判断报文的真伪。
+
+这对于网络购物、网上银行、证券交易等需要高度信任的应用场景来说是非常致命的。如果没有基本的安全保护，使用互联网进行各种电子商务、电子政务就根本无从谈起。
+
+对于安全性要求不那么高的新闻、视频、搜索等网站来说，由于互联网上的恶意用户、恶意代理越来越多，也很容易遭到“流量劫持”的攻击，在页面里强行嵌入广告，或者分流用户，导致各种利益损失。
+
+对于你我这样的普通网民来说，HTTP不安全的隐患就更大了，上网的记录会被轻易截获，网站是否真实也无法验证，黑客可以伪装成银行网站，盗取真实姓名、密码、银行卡等敏感信息，威胁人身安全和财产安全。
+
+总的来说，今天的互联网已经不再是早期的“田园牧歌”时代，而是进入了“黑暗森林”状态。上网的时候必须步步为营、处处小心，否则就会被不知道埋伏在哪里的黑客所“猎杀”。
+
+## 什么是安全？
+
+既然HTTP“不安全”，那什么样的通信过程才是安全的呢？
+
+通常认为，如果通信过程具备了四个特性，就可以认为是“安全”的，这四个特性是：机密性、完整性，身份认证和不可否认。
+
+**机密性**（Secrecy/Confidentiality）是指对数据的“保密”，只能由可信的人访问，对其他人是不可见的“秘密”，简单来说就是不能让不相关的人看到不该看的东西。
+
+比如小明和小红私下聊天，但“隔墙有耳”，被小强在旁边的房间里全偷听到了，这就是没有机密性。我们之前一直用的Wireshark ，实际上也是利用了HTTP的这个特点，捕获了传输过程中的所有数据。
+
+**完整性**（Integrity，也叫一致性）是指数据在传输过程中没有被篡改，不多也不少，“完完整整”地保持着原状。
+
+机密性虽然可以让数据成为“秘密”，但不能防止黑客对数据的修改，黑客可以替换数据，调整数据的顺序，或者增加、删除部分数据，破坏通信过程。
+
+比如，小明给小红写了张纸条：“明天公园见”。小强把“公园”划掉，模仿小明的笔迹把这句话改成了“明天广场见”。小红收到后无法验证完整性，信以为真，第二天的约会就告吹了。
+
+**身份认证**（Authentication）是指确认对方的真实身份，也就是“证明你真的是你”，保证消息只能发送给可信的人。
+
+如果通信时另一方是假冒的网站，那么数据再保密也没有用，黑客完全可以使用冒充的身份“套”出各种信息，加密和没加密一样。
+
+比如，小明给小红写了封情书：“我喜欢你”，但不留心发给了小强。小强将错就错，假冒小红回复了一个“白日做梦”，小明不知道这其实是小强的话，误以为是小红的，后果可想而知。
+
+第四个特性是**不可否认**（Non-repudiation/Undeniable），也叫不可抵赖，意思是不能否认已经发生过的行为，不能“说话不算数”“耍赖皮”。
+
+使用前三个特性，可以解决安全通信的大部分问题，但如果缺了不可否认，那通信的事务真实性就得不到保证，有可能出现“老赖”。
+
+比如，小明借了小红一千元，没写借条，第二天矢口否认，小红也确实拿不出借钱的证据，只能认倒霉。另一种情况是小明借钱后还了小红，但没写收条，小红于是不承认小明还钱的事，说根本没还，要小明再掏出一千元。
+
+所以，只有同时具备了机密性、完整性、身份认证、不可否认这四个特性，通信双方的利益才能有保障，才能算得上是真正的安全。
+
+## 什么是HTTPS？
+
+说到这里，终于轮到今天的主角HTTPS出场了，它为HTTP增加了刚才所说的四大安全特性。
+
+HTTPS其实是一个“非常简单”的协议，RFC文档很小，只有短短的7页，里面规定了**新的协议名“https”，默认端口号443**，至于其他的什么请求-应答模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用HTTP，没有任何新的东西。
+
+也就是说，除了协议名“http”和端口号80这两点不同，HTTPS协议在语法、语义上和HTTP完全一样，优缺点也“照单全收”（当然要除去“明文”和“不安全”）。
+
+不信你可以用URI“[https://www.chrono.com](https://www.chrono.com)”访问之前08至21讲的所有示例，看看它的响应报文是否与HTTP一样。
+
+```
+https://www.chrono.com
+https://www.chrono.com/11-1
+https://www.chrono.com/15-1?name=a.json
+https://www.chrono.com/16-1
+
+```
+
+<img src="https://static001.geekbang.org/resource/image/40/b0/40fbb989a9fd2217320ab287e80e1fb0.png" alt="">
+
+你肯定已经注意到了，在用HTTPS访问实验环境时Chrome会有不安全提示，必须点击“高级-继续前往”才能顺利显示页面。而且如果用Wireshark抓包，也会发现与HTTP不一样，不再是简单可见的明文，多了“Client Hello”“Server Hello”等新的数据包。
+
+这就是HTTPS与HTTP最大的区别，它能够鉴别危险的网站，并且尽最大可能保证你的上网安全，防御黑客对信息的窃听、篡改或者“钓鱼”、伪造。
+
+你可能要问了，既然没有新东西，HTTPS凭什么就能做到机密性、完整性这些安全特性呢？
+
+秘密就在于HTTPS名字里的“S”，它把HTTP下层的传输协议由TCP/IP换成了SSL/TLS，由“**HTTP over TCP/IP**”变成了“**HTTP over SSL/TLS**”，让HTTP运行在了安全的SSL/TLS协议上（可参考第4讲和第5讲），收发报文不再使用Socket API，而是调用专门的安全接口。
+
+<img src="https://static001.geekbang.org/resource/image/50/a3/50d57e18813e18270747806d5d73f0a3.png" alt="">
+
+所以说，HTTPS本身并没有什么“惊世骇俗”的本事，全是靠着后面的SSL/TLS“撑腰”。只要学会了SSL/TLS，HTTPS自然就“手到擒来”。
+
+## SSL/TLS
+
+现在我们就来看看SSL/TLS，它到底是个什么来历。
+
+SSL即安全套接层（Secure Sockets Layer），在OSI模型中处于第5层（会话层），由网景公司于1994年发明，有v2和v3两个版本，而v1因为有严重的缺陷从未公开过。
+
+SSL发展到v3时已经证明了它自身是一个非常好的安全通信协议，于是互联网工程组IETF在1999年把它改名为TLS（传输层安全，Transport Layer Security），正式标准化，版本号从1.0重新算起，所以TLS1.0实际上就是SSLv3.1。
+
+到今天TLS已经发展出了三个版本，分别是2006年的1.1、2008年的1.2和去年（2018）的1.3，每个新版本都紧跟密码学的发展和互联网的现状，持续强化安全和性能，已经成为了信息安全领域中的权威标准。
+
+目前应用的最广泛的TLS是1.2，而之前的协议（TLS1.1/1.0、SSLv3/v2）都已经被认为是不安全的，各大浏览器即将在2020年左右停止支持，所以接下来的讲解都针对的是TLS1.2。
+
+TLS由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。
+
+浏览器和服务器在使用TLS建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为“密码套件”（cipher suite，也叫加密套件）。
+
+你可以访问实验环境的URI“/23-1”，对TLS和密码套件有个感性的认识。
+
+<img src="https://static001.geekbang.org/resource/image/5e/24/5ead57e03f127ea8f244d715186adb24.png" alt="">
+
+你可以看到，实验环境使用的TLS是1.2，客户端和服务器都支持非常多的密码套件，而最后协商选定的是“ECDHE-RSA-AES256-GCM-SHA384”。
+
+这么长的名字看着有点晕吧，不用怕，其实TLS的密码套件命名非常规范，格式很固定。基本的形式是“密钥交换算法+签名算法+对称加密算法+摘要算法”，比如刚才的密码套件的意思就是：
+
+“握手时使用ECDHE算法进行密钥交换，用RSA签名和身份认证，握手后的通信使用AES对称算法，密钥长度256位，分组模式是GCM，摘要算法SHA384用于消息认证和产生随机数。”
+
+## OpenSSL
+
+说到TLS，就不能不谈到OpenSSL，它是一个著名的开源密码学程序库和工具包，几乎支持所有公开的加密算法和协议，已经成为了事实上的标准，许多应用软件都会使用它作为底层库来实现TLS功能，包括常用的Web服务器Apache、Nginx等。
+
+OpenSSL是从另一个开源库SSLeay发展出来的，曾经考虑命名为“OpenTLS”，但当时（1998年）TLS还未正式确立，而SSL早已广为人知，所以最终使用了“OpenSSL”的名字。
+
+OpenSSL目前有三个主要的分支，1.0.2和1.1.0都将在今年（2019）年底不再维护，最新的长期支持版本是1.1.1，我们的实验环境使用的OpenSSL是“1.1.0j”。
+
+由于OpenSSL是开源的，所以它还有一些代码分支，比如Google的BoringSSL、OpenBSD的LibreSSL，这些分支在OpenSSL的基础上删除了一些老旧代码，也增加了一些新特性，虽然背后有“大金主”，但离取代OpenSSL还差得很远。
+
+## 小结
+
+1. 因为HTTP是明文传输，所以不安全，容易被黑客窃听或篡改；
+1. 通信安全必须同时具备机密性、完整性、身份认证和不可否认这四个特性；
+1. HTTPS的语法、语义仍然是HTTP，但把下层的协议由TCP/IP换成了SSL/TLS；
+1. SSL/TLS是信息安全领域中的权威标准，采用多种先进的加密技术保证通信安全；
+1. OpenSSL是著名的开源密码学工具包，是SSL/TLS的具体实现。
+
+## 课下作业
+
+1. 你能说出HTTPS与HTTP有哪些区别吗？
+1. 你知道有哪些方法能够实现机密性、完整性等安全特性呢？
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+<img src="https://static001.geekbang.org/resource/image/05/4a/052e28eaa90a37f21ae4052135750a4a.png" alt="unpreview">
+
+

极客时间专栏/透视HTTP协议/安全篇/24 | 固若金汤的根本（上）：对称加密与非对称加密.md

@@ -0,0 +1,146 @@
+<audio id="audio" title="24 | 固若金汤的根本（上）：对称加密与非对称加密" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/67/ca/67d40f007e6e960a7835e04c986212ca.mp3"></audio>
+
+在上一讲中，我们初步学习了HTTPS，知道HTTPS的安全性是由TLS来保证的。
+
+你一定很好奇，它是怎么为HTTP增加了机密性、完整性，身份认证和不可否认等特性的呢？
+
+先说说机密性。它是信息安全的基础，缺乏机密性TLS就会成为“无水之源”“无根之木”。
+
+实现机密性最常用的手段是“**加密**”（encrypt），就是把消息用某种方式转换成谁也看不懂的乱码，只有掌握特殊“钥匙”的人才能再转换出原始文本。
+
+这里的“钥匙”就叫做“**密钥**”（key），加密前的消息叫“**明文**”（plain text/clear text），加密后的乱码叫“**密文**”（cipher text），使用密钥还原明文的过程叫“**解密**”（decrypt），是加密的反操作，加密解密的操作过程就是“**加密算法**”。
+
+所有的加密算法都是公开的，任何人都可以去分析研究，而算法使用的“密钥”则必须保密。那么，这个关键的“密钥”又是什么呢？
+
+由于HTTPS、TLS都运行在计算机上，所以“密钥”就是一长串的数字，但约定俗成的度量单位是“位”（bit），而不是“字节”（byte）。比如，说密钥长度是128，就是16字节的二进制串，密钥长度1024，就是128字节的二进制串。
+
+按照密钥的使用方式，加密可以分为两大类：**对称加密和非对称加密**。
+
+## 对称加密
+
+“对称加密”很好理解，就是指加密和解密时使用的密钥都是同一个，是“对称”的。只要保证了密钥的安全，那整个通信过程就可以说具有了机密性。
+
+举个例子，你想要登录某网站，只要事先和它约定好使用一个对称密钥，通信过程中传输的全是用密钥加密后的密文，只有你和网站才能解密。黑客即使能够窃听，看到的也只是乱码，因为没有密钥无法解出明文，所以就实现了机密性。
+
+<img src="https://static001.geekbang.org/resource/image/8f/49/8feab67c25a534f8c72077680927ab49.png" alt="">
+
+TLS里有非常多的对称加密算法可供选择，比如RC4、DES、3DES、AES、ChaCha20等，但前三种算法都被认为是不安全的，通常都禁止使用，目前常用的只有AES和ChaCha20。
+
+AES的意思是“高级加密标准”（Advanced Encryption Standard），密钥长度可以是128、192或256。它是DES算法的替代者，安全强度很高，性能也很好，而且有的硬件还会做特殊优化，所以非常流行，是应用最广泛的对称加密算法。
+
+ChaCha20是Google设计的另一种加密算法，密钥长度固定为256位，纯软件运行性能要超过AES，曾经在移动客户端上比较流行，但ARMv8之后也加入了AES硬件优化，所以现在不再具有明显的优势，但仍然算得上是一个不错的算法。
+
+## 加密分组模式
+
+对称算法还有一个“**分组模式**”的概念，它可以让算法用固定长度的密钥加密任意长度的明文，把小秘密（即密钥）转化为大秘密（即密文）。
+
+最早有ECB、CBC、CFB、OFB等几种分组模式，但都陆续被发现有安全漏洞，所以现在基本都不怎么用了。最新的分组模式被称为AEAD（Authenticated Encryption with Associated Data），在加密的同时增加了认证的功能，常用的是GCM、CCM和Poly1305。
+
+把上面这些组合起来，就可以得到TLS密码套件中定义的对称加密算法。
+
+比如，AES128-GCM，意思是密钥长度为128位的AES算法，使用的分组模式是GCM；ChaCha20-Poly1305的意思是ChaCha20算法，使用的分组模式是Poly1305。
+
+你可以用实验环境的URI“/24-1”来测试OpenSSL里的AES128-CBC，在URI后用参数“key”“plain”输入密钥和明文，服务器会在响应报文里输出加密解密的结果。
+
+```
+https://www.chrono.com/24-1?key=123456
+
+algo  = aes_128_cbc
+plain = hello openssl
+enc   = 93a024a94083bc39fb2c2b9f5ce27c09
+dec   = hello openssl
+
+```
+
+## 非对称加密
+
+对称加密看上去好像完美地实现了机密性，但其中有一个很大的问题：如何把密钥安全地传递给对方，术语叫“**密钥交换**”。
+
+因为在对称加密算法中只要持有密钥就可以解密。如果你和网站约定的密钥在传递途中被黑客窃取，那他就可以在之后随意解密收发的数据，通信过程也就没有机密性可言了。
+
+这个问题该怎么解决呢？
+
+你或许会说：“把密钥再加密一下发过去就好了”，但传输“加密密钥的密钥”又成了新问题。这就像是“鸡生蛋、蛋生鸡”，可以无限递归下去。只用对称加密算法，是绝对无法解决密钥交换的问题的。
+
+所以，就出现了非对称加密（也叫公钥加密算法）。
+
+它有两个密钥，一个叫“**公钥**”（public key），一个叫“**私钥**”（private key）。两个密钥是不同的，“不对称”，公钥可以公开给任何人使用，而私钥必须严格保密。
+
+公钥和私钥有个特别的“**单向**”性，虽然都可以用来加密解密，但公钥加密后只能用私钥解密，反过来，私钥加密后也只能用公钥解密。
+
+非对称加密可以解决“密钥交换”的问题。网站秘密保管私钥，在网上任意分发公钥，你想要登录网站只要用公钥加密就行了，密文只能由私钥持有者才能解密。而黑客因为没有私钥，所以就无法破解密文。
+
+<img src="https://static001.geekbang.org/resource/image/89/17/89344c2e493600b486d5349a84318417.png" alt="">
+
+非对称加密算法的设计要比对称算法难得多，在TLS里只有很少的几种，比如DH、DSA、RSA、ECC等。
+
+RSA可能是其中最著名的一个，几乎可以说是非对称加密的代名词，它的安全性基于“**整数分解**”的数学难题，使用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是非常困难的。
+
+10年前RSA密钥的推荐长度是1024，但随着计算机运算能力的提高，现在1024已经不安全，普遍认为至少要2048位。
+
+ECC（Elliptic Curve Cryptography）是非对称加密里的“后起之秀”，它基于“**椭圆曲线离散对数**”的数学难题，使用特定的曲线方程和基点生成公钥和私钥，子算法ECDHE用于密钥交换，ECDSA用于数字签名。
+
+目前比较常用的两个曲线是P-256（secp256r1，在OpenSSL称为prime256v1）和x25519。P-256是NIST（美国国家标准技术研究所）和NSA（美国国家安全局）推荐使用的曲线，而x25519被认为是最安全、最快速的曲线。
+
+ECC名字里的“椭圆”经常会引起误解，其实它的曲线并不是椭圆形，只是因为方程很类似计算椭圆周长的公式，实际的形状更像抛物线，比如下面的图就展示了两个简单的椭圆曲线。
+
+<img src="https://static001.geekbang.org/resource/image/b4/ba/b452ceb3cbfc5c644a3053f2054b1aba.jpg" alt="">两个简单的椭圆曲线：y^2=x^3+7，y^2=x^3-x
+
+比起RSA，ECC在安全强度和性能上都有明显的优势。160位的ECC相当于1024位的RSA，而224位的ECC则相当于2048位的RSA。因为密钥短，所以相应的计算量、消耗的内存和带宽也就少，加密解密的性能就上去了，对于现在的移动互联网非常有吸引力。
+
+实验环境的URI“/24-2”演示了RSA1024，你在课后可以动手试一下。
+
+## 混合加密
+
+看到这里，你是不是认为可以抛弃对称加密，只用非对称加密来实现机密性呢？
+
+很遗憾，虽然非对称加密没有“密钥交换”的问题，但因为它们都是基于复杂的数学难题，运算速度很慢，即使是ECC也要比AES差上好几个数量级。如果仅用非对称加密，虽然保证了安全，但通信速度有如乌龟、蜗牛，实用性就变成了零。
+
+实验环境的URI“/24-3”对比了AES和RSA这两种算法的性能，下面列出了一次测试的结果：
+
+```
+aes_128_cbc enc/dec 1000 times : 0.97ms, 13.11MB/s
+
+rsa_1024 enc/dec 1000 times : 138.59ms, 93.80KB/s
+rsa_1024/aes ratio = 143.17
+
+rsa_2048 enc/dec 1000 times : 840.35ms, 15.47KB/s
+rsa_2048/aes ratio = 868.13
+
+```
+
+可以看到，RSA的运算速度是非常慢的，2048位的加解密大约是15KB/S（微秒或毫秒级），而AES128则是13MB/S（纳秒级），差了几百倍。
+
+那么，是不是能够把对称加密和非对称加密结合起来呢，两者互相取长补短，即能高效地加密解密，又能安全地密钥交换。
+
+这就是现在TLS里使用的**混合加密**方式，其实说穿了也很简单：
+
+在通信刚开始的时候使用非对称算法，比如RSA、ECDHE，首先解决密钥交换的问题。
+
+然后用随机数产生对称算法使用的“**会话密钥**”（session key），再用公钥加密。因为会话密钥很短，通常只有16字节或32字节，所以慢一点也无所谓。
+
+对方拿到密文后用私钥解密，取出会话密钥。这样，双方就实现了对称密钥的安全交换，后续就不再使用非对称加密，全都使用对称加密。
+
+<img src="https://static001.geekbang.org/resource/image/e4/85/e41f87110aeea3e548d58cc35a478e85.png" alt="">
+
+这样混合加密就解决了对称加密算法的密钥交换问题，而且安全和性能兼顾，完美地实现了机密性。
+
+不过这只是“万里长征的第一步”，后面还有完整性、身份认证、不可否认等特性没有实现，所以现在的通信还不是绝对安全，我们下次再说。
+
+## 小结
+
+1. 加密算法的核心思想是“把一个小秘密（密钥）转化为一个大秘密（密文消息）”，守住了小秘密，也就守住了大秘密；
+1. 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换，常用的有AES和ChaCha20；
+1. 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢，常用的有RSA和ECC；
+1. 把对称加密和非对称加密结合起来就得到了“又好又快”的混合加密，也就是TLS里使用的加密方式。
+
+## 课下作业
+
+1. 加密算法中“密钥”的名字很形象，你能试着用现实中的锁和钥匙来比喻一下吗？
+1. 在混合加密中用到了公钥加密，因为只能由私钥解密。那么反过来，私钥加密后任何人都可以用公钥解密，这有什么用呢？
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+<img src="https://static001.geekbang.org/resource/image/b4/d7/b437f2b898a2f3424bd8812d9a0dcbd7.png" alt="unpreview">
+
+

极客时间专栏/透视HTTP协议/安全篇/25 | 固若金汤的根本（下）：数字签名与证书.md

@@ -0,0 +1,152 @@
+<audio id="audio" title="25 | 固若金汤的根本（下）：数字签名与证书" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ac/7b/acc313467c268709079037625577c67b.mp3"></audio>
+
+上一讲中我们学习了对称加密和非对称加密，以及两者结合起来的混合加密，实现了机密性。
+
+但仅有机密性，离安全还差的很远。
+
+黑客虽然拿不到会话密钥，无法破解密文，但可以通过窃听收集到足够多的密文，再尝试着修改、重组后发给网站。因为没有完整性保证，服务器只能“照单全收”，然后他就可以通过服务器的响应获取进一步的线索，最终就会破解出明文。
+
+另外，黑客也可以伪造身份发布公钥。如果你拿到了假的公钥，混合加密就完全失效了。你以为自己是在和“某宝”通信，实际上网线的另一端却是黑客，银行卡号、密码等敏感信息就在“安全”的通信过程中被窃取了。
+
+所以，在机密性的基础上还必须加上完整性、身份认证等特性，才能实现真正的安全。
+
+## 摘要算法
+
+实现完整性的手段主要是**摘要算法**（Digest Algorithm），也就是常说的散列函数、哈希函数（Hash Function）。
+
+你可以把摘要算法近似地理解成一种特殊的压缩算法，它能够把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”。
+
+换一个角度，也可以把摘要算法理解成特殊的“单向”加密算法，它只有算法，没有密钥，加密后的数据无法解密，不能从摘要逆推出原文。
+
+<img src="https://static001.geekbang.org/resource/image/28/d8/2865d2c77466efb7a480833bcb27f9d8.png" alt="">
+
+摘要算法实际上是把数据从一个“大空间”映射到了“小空间”，所以就存在“冲突”（collision，也叫碰撞）的可能性，就如同现实中的指纹一样，可能会有两份不同的原文对应相同的摘要。好的摘要算法必须能够“抵抗冲突”，让这种可能性尽量地小。
+
+因为摘要算法对输入具有“单向性”和“雪崩效应”，输入的微小不同会导致输出的剧烈变化，所以也被TLS用来生成伪随机数（PRF，pseudo random function）。
+
+你一定在日常工作中听过、或者用过MD5（Message-Digest 5）、SHA-1（Secure Hash Algorithm 1），它们就是最常用的两个摘要算法，能够生成16字节和20字节长度的数字摘要。但这两个算法的安全强度比较低，不够安全，在TLS里已经被禁止使用了。
+
+目前TLS推荐使用的是SHA-1的后继者：SHA-2。
+
+SHA-2实际上是一系列摘要算法的统称，总共有6种，常用的有SHA224、SHA256、SHA384，分别能够生成28字节、32字节、48字节的摘要。
+
+你可以用实验环境的URI“/25-1”来测试一下TLS里的各种摘要算法，包括MD5、SHA-1和SHA-2。
+
+```
+https://www.chrono.com/25-1?algo=md5
+https://www.chrono.com/25-1?algo=sha1
+https://www.chrono.com/25-1?algo=sha256
+
+```
+
+## 完整性
+
+摘要算法保证了“数字摘要”和原文是完全等价的。所以，我们只要在原文后附上它的摘要，就能够保证数据的完整性。
+
+比如，你发了条消息：“转账1000元”，然后再加上一个SHA-2的摘要。网站收到后也计算一下消息的摘要，把这两份“指纹”做个对比，如果一致，就说明消息是完整可信的，没有被修改。
+
+如果黑客在中间哪怕改动了一个标点符号，摘要也会完全不同，网站计算比对就会发现消息被窜改，是不可信的。
+
+不过摘要算法不具有机密性，如果明文传输，那么黑客可以修改消息后把摘要也一起改了，网站还是鉴别不出完整性。
+
+所以，真正的完整性必须要建立在机密性之上，在混合加密系统里用会话密钥加密消息和摘要，这样黑客无法得知明文，也就没有办法动手脚了。
+
+这有个术语，叫哈希消息认证码（HMAC）。
+
+<img src="https://static001.geekbang.org/resource/image/c2/96/c2e10e9afa1393281b5633b1648f2696.png" alt="">
+
+## 数字签名
+
+加密算法结合摘要算法，我们的通信过程可以说是比较安全了。但这里还有漏洞，就是通信的两个端点（endpoint）。
+
+就像一开始所说的，黑客可以伪装成网站来窃取信息。而反过来，他也可以伪装成你，向网站发送支付、转账等消息，网站没有办法确认你的身份，钱可能就这么被偷走了。
+
+现实生活中，解决身份认证的手段是签名和印章，只要在纸上写下签名或者盖个章，就能够证明这份文件确实是由本人而不是其他人发出的。
+
+你回想一下之前的课程，在TLS里有什么东西和现实中的签名、印章很像，只能由本人持有，而其他任何人都不会有呢？只要用这个东西，就能够在数字世界里证明你的身份。
+
+没错，这个东西就是非对称加密里的“**私钥**”，使用私钥再加上摘要算法，就能够实现“**数字签名**”，同时实现“身份认证”和“不可否认”。
+
+数字签名的原理其实很简单，就是把公钥私钥的用法反过来，之前是公钥加密、私钥解密，现在是私钥加密、公钥解密。
+
+但又因为非对称加密效率太低，所以私钥只加密原文的摘要，这样运算量就小的多，而且得到的数字签名也很小，方便保管和传输。
+
+签名和公钥一样完全公开，任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开，拿到摘要后，再比对原文验证完整性，就可以像签署文件一样证明消息确实是你发的。
+
+<img src="https://static001.geekbang.org/resource/image/84/d2/84a79826588ca35bf6ddcade027597d2.png" alt="">
+
+刚才的这两个行为也有专用术语，叫做“**签名**”和“**验签**”。
+
+只要你和网站互相交换公钥，就可以用“签名”和“验签”来确认消息的真实性，因为私钥保密，黑客不能伪造签名，就能够保证通信双方的身份。
+
+比如，你用自己的私钥签名一个消息“我是小明”。网站收到后用你的公钥验签，确认身份没问题，于是也用它的私钥签名消息“我是某宝”。你收到后再用它的公钥验一下，也没问题，这样你和网站就都知道对方不是假冒的，后面就可以用混合加密进行安全通信了。
+
+实验环境的URI“/25-2”演示了TLS里的数字签名，它使用的是RSA1024。
+
+## 数字证书和CA
+
+到现在，综合使用对称加密、非对称加密和摘要算法，我们已经实现了安全的四大特性，是不是已经完美了呢？
+
+不是的，这里还有一个“**公钥的信任**”问题。因为谁都可以发布公钥，我们还缺少防止黑客伪造公钥的手段，也就是说，怎么来判断这个公钥就是你或者某宝的公钥呢？
+
+真是“按下葫芦又起了瓢”，安全还真是个麻烦事啊，“一环套一环”的。
+
+我们可以用类似密钥交换的方法来解决公钥认证问题，用别的私钥来给公钥签名，显然，这又会陷入“无穷递归”。
+
+但这次实在是“没招”了，要终结这个“死循环”，就必须引入“外力”，找一个公认的可信第三方，让它作为“信任的起点，递归的终点”，构建起公钥的信任链。
+
+这个“第三方”就是我们常说的**CA**（Certificate Authority，证书认证机构）。它就像网络世界里的公安局、教育部、公证中心，具有极高的可信度，由它来给各个公钥签名，用自身的信誉来保证公钥无法伪造，是可信的。
+
+CA对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“**数字证书**”（Certificate）。
+
+知名的CA全世界就那么几家，比如DigiCert、VeriSign、Entrust、Let’s Encrypt等，它们签发的证书分DV、OV、EV三种，区别在于可信程度。
+
+DV是最低的，只是域名级别的可信，背后是谁不知道。EV是最高的，经过了法律和审计的严格核查，可以证明网站拥有者的身份（在浏览器地址栏会显示出公司的名字，例如Apple、GitHub的网站）。
+
+不过，CA怎么证明自己呢？
+
+这还是信任链的问题。小一点的CA可以让大CA签名认证，但链条的最后，也就是**Root CA**，就只能自己证明自己了，这个就叫“**自签名证书**”（Self-Signed Certificate）或者“**根证书**”（Root Certificate）。你必须相信，否则整个证书信任链就走不下去了。
+
+<img src="https://static001.geekbang.org/resource/image/8f/9c/8f0813e9555ba1a40bd2170734aced9c.png" alt="">
+
+有了这个证书体系，操作系统和浏览器都内置了各大CA的根证书，上网的时候只要服务器发过来它的证书，就可以验证证书里的签名，顺着证书链（Certificate Chain）一层层地验证，直到找到根证书，就能够确定证书是可信的，从而里面的公钥也是可信的。
+
+我们的实验环境里使用的证书是“野路子”的自签名证书（在Linux上用OpenSSL命令行签发），肯定是不会被浏览器所信任的，所以用Chrome访问时就会显示成红色，标记为不安全。但你只要把它安装进系统的根证书存储区里，让它作为信任链的根，就不会再有危险警告。
+
+<img src="https://static001.geekbang.org/resource/image/a5/8f/a55051ca7ae941ae04791cdddde6658f.png" alt="">
+
+## 证书体系的弱点
+
+证书体系（PKI，Public Key Infrastructure）虽然是目前整个网络世界的安全基础设施，但绝对的安全是不存在的，它也有弱点，还是关键的“**信任**”二字。
+
+如果CA失误或者被欺骗，签发了错误的证书，虽然证书是真的，可它代表的网站却是假的。
+
+还有一种更危险的情况，CA被黑客攻陷，或者CA有恶意，因为它（即根证书）是信任的源头，整个信任链里的所有证书也就都不可信了。
+
+这两种事情并不是“耸人听闻”，都曾经实际出现过。所以，需要再给证书体系打上一些补丁。
+
+针对第一种，开发出了CRL（证书吊销列表，Certificate revocation list）和OCSP（在线证书状态协议，Online Certificate Status Protocol），及时废止有问题的证书。
+
+对于第二种，因为涉及的证书太多，就只能操作系统或者浏览器从根上“下狠手”了，撤销对CA的信任，列入“黑名单”，这样它颁发的所有证书就都会被认为是不安全的。
+
+## 小结
+
+今天我们学习了数字签名和证书、CA，是不是有种“盗梦空间”一层套一层的感觉？你可以在课后再去各大网站，结合它们“小锁头”里的信息来加深理解。
+
+今天的内容可以简单概括为四点：
+
+1. 摘要算法用来实现完整性，能够为数据生成独一无二的“指纹”，常用的算法是SHA-2；
+1. 数字签名是私钥对摘要的加密，可以由公钥解密后验证，实现身份认证和不可否认；
+1. 公钥的分发需要使用数字证书，必须由CA的信任链来验证，否则就是不可信的；
+1. 作为信任链的源头CA有时也会不可信，解决办法有CRL、OCSP，还有终止信任。
+
+## 课下作业
+
+1. 为什么公钥能够建立信任链，用对称加密算法里的对称密钥行不行呢？
+1. 假设有一个三级的证书体系（Root CA=&gt;一级CA=&gt;二级CA），你能详细解释一下证书信任链的验证过程吗？
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+<img src="https://static001.geekbang.org/resource/image/37/57/37c59439c36e75f610fe84c22009cc57.png" alt="">
+
+

极客时间专栏/透视HTTP协议/安全篇/26 | 信任始于握手：TLS1.2连接过程解析.md

@@ -0,0 +1,192 @@
+<audio id="audio" title="26 | 信任始于握手：TLS1.2连接过程解析" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/29/e8/296bb845794dbb049778d7725589bde8.mp3"></audio>
+
+经过前几讲的介绍，你应该已经熟悉了对称加密与非对称加密、数字签名与证书等密码学知识。
+
+有了这些知识“打底”，现在我们就可以正式开始研究HTTPS和TLS协议了。
+
+## HTTPS建立连接
+
+当你在浏览器地址栏里键入“**https**”开头的URI，再按下回车，会发生什么呢？
+
+回忆一下[第8讲](https://time.geekbang.org/column/article/100502)的内容，你应该知道，浏览器首先要从URI里提取出协议名和域名。因为协议名是“https”，所以浏览器就知道了端口号是默认的443，它再用DNS解析域名，得到目标的IP地址，然后就可以使用三次握手与网站建立TCP连接了。
+
+在HTTP协议里，建立连接后，浏览器会立即发送请求报文。但现在是HTTPS协议，它需要再用另外一个“握手”过程，在TCP上建立安全连接，之后才是收发HTTP报文。
+
+这个“握手”过程与TCP有些类似，是HTTPS和TLS协议里最重要、最核心的部分，懂了它，你就可以自豪地说自己“掌握了HTTPS”。
+
+## TLS协议的组成
+
+在讲TLS握手之前，我先简单介绍一下TLS协议的组成。
+
+TLS包含几个子协议，你也可以理解为它是由几个不同职责的模块组成，比较常用的有记录协议、警报协议、握手协议、变更密码规范协议等。
+
+**记录协议**（Record Protocol）规定了TLS收发数据的基本单位：记录（record）。它有点像是TCP里的segment，所有的其他子协议都需要通过记录协议发出。但多个记录数据可以在一个TCP包里一次性发出，也并不需要像TCP那样返回ACK。
+
+**警报协议**（Alert Protocol）的职责是向对方发出警报信息，有点像是HTTP协议里的状态码。比如，protocol_version就是不支持旧版本，bad_certificate就是证书有问题，收到警报后另一方可以选择继续，也可以立即终止连接。
+
+**握手协议**（Handshake Protocol）是TLS里最复杂的子协议，要比TCP的SYN/ACK复杂的多，浏览器和服务器会在握手过程中协商TLS版本号、随机数、密码套件等信息，然后交换证书和密钥参数，最终双方协商得到会话密钥，用于后续的混合加密系统。
+
+最后一个是**变更密码规范协议**（Change Cipher Spec Protocol），它非常简单，就是一个“通知”，告诉对方，后续的数据都将使用加密保护。那么反过来，在它之前，数据都是明文的。
+
+下面的这张图简要地描述了TLS的握手过程，其中每一个“框”都是一个记录，多个记录组合成一个TCP包发送。所以，最多经过两次消息往返（4个消息）就可以完成握手，然后就可以在安全的通信环境里发送HTTP报文，实现HTTPS协议。
+
+<img src="https://static001.geekbang.org/resource/image/69/6c/69493b53f1b1d540acf886ebf021a26c.png" alt="">
+
+## 抓包的准备工作
+
+这次我们在实验环境里测试TLS握手的URI是“/26-1”，看了上面的图你就可以知道，TLS握手的前几个消息都是明文的，能够在Wireshark里直接看。但只要出现了“Change Cipher Spec”，后面的数据就都是密文了，看到的也就会是乱码，不知道究竟是什么东西。
+
+为了更好地分析TLS握手过程，你可以再对系统和Wireshark做一下设置，让浏览器导出握手过程中的秘密信息，这样Wireshark就可以把密文解密，还原出明文。
+
+首先，你需要在Windows的设置里新增一个系统变量“**SSLKEYLOGFILE**”，设置浏览器日志文件的路径，比如“D:\http_study\www\temp\sslkey.log”（具体的设置过程就不详细说了，可以在设置里搜索“系统变量”）。
+
+<img src="https://static001.geekbang.org/resource/image/70/42/70b36338611d5a249a7d2fc448f06d42.png" alt="">
+
+然后在Wireshark里设置“Protocols-TLS”（较早版本的Wireshark里是“SSL”），在“(Pre)-Master-Secret log filename”里填上刚才的日志文件。
+
+<img src="https://static001.geekbang.org/resource/image/02/e7/0274e31e74e92b61892ec11cc3cd58e7.png" alt="">
+
+设置好之后，过滤器选择“**tcp port 443**”，就可以抓到实验环境里的所有HTTPS数据了。
+
+如果你觉得麻烦也没关系，GitHub上有抓好的包和相应的日志，用Wireshark直接打开就行。
+
+## ECDHE握手过程
+
+刚才你看到的是握手过程的简要图，我又画了一个详细图，对应Wireshark的抓包，下面我就用这个图来仔细剖析TLS的握手过程。
+
+<img src="https://static001.geekbang.org/resource/image/9c/1e/9caba6d4b527052bbe7168ed4013011e.png" alt="">
+
+在TCP建立连接之后，浏览器会首先发一个“**Client Hello**”消息，也就是跟服务器“打招呼”。里面有客户端的版本号、支持的密码套件，还有一个**随机数（Client Random）**，用于后续生成会话密钥。
+
+```
+Handshake Protocol: Client Hello
+    Version: TLS 1.2 (0x0303)
+    Random: 1cbf803321fd2623408dfe…
+    Cipher Suites (17 suites)
+        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
+        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
+
+```
+
+这个的意思就是：“我这边有这些这些信息，你看看哪些是能用的，关键的随机数可得留着。”
+
+作为“礼尚往来”，服务器收到“Client Hello”后，会返回一个“Server Hello”消息。把版本号对一下，也给出一个**随机数（Server Random）**，然后从客户端的列表里选一个作为本次通信使用的密码套件，在这里它选择了“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384”。
+
+```
+Handshake Protocol: Server Hello
+    Version: TLS 1.2 (0x0303)
+    Random: 0e6320f21bae50842e96…
+    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
+
+```
+
+这个的意思就是：“版本号对上了，可以加密，你的密码套件挺多，我选一个最合适的吧，用椭圆曲线加RSA、AES、SHA384。我也给你一个随机数，你也得留着。”
+
+然后，服务器为了证明自己的身份，就把证书也发给了客户端（Server Certificate）。
+
+接下来是一个关键的操作，因为服务器选择了ECDHE算法，所以它会在证书后发送“**Server Key Exchange**”消息，里面是**椭圆曲线的公钥（Server Params）**，用来实现密钥交换算法，再加上自己的私钥签名认证。
+
+```
+Handshake Protocol: Server Key Exchange
+    EC Diffie-Hellman Server Params
+        Curve Type: named_curve (0x03)
+        Named Curve: x25519 (0x001d)
+        Pubkey: 3b39deaf00217894e...
+        Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
+        Signature: 37141adac38ea4...
+
+```
+
+这相当于说：“刚才我选的密码套件有点复杂，所以再给你个算法的参数，和刚才的随机数一样有用，别丢了。为了防止别人冒充，我又盖了个章。”
+
+之后是“**Server Hello Done**”消息，服务器说：“我的信息就是这些，打招呼完毕。”
+
+这样第一个消息往返就结束了（两个TCP包），结果是客户端和服务器通过明文共享了三个信息：**Client Random、Server Random和Server Params**。
+
+客户端这时也拿到了服务器的证书，那这个证书是不是真实有效的呢？
+
+这就要用到第25讲里的知识了，开始走证书链逐级验证，确认证书的真实性，再用证书公钥验证签名，就确认了服务器的身份：“刚才跟我打招呼的不是骗子，可以接着往下走。”
+
+然后，客户端按照密码套件的要求，也生成一个**椭圆曲线的公钥（Client Params）**，用“**Client Key Exchange**”消息发给服务器。
+
+```
+Handshake Protocol: Client Key Exchange
+    EC Diffie-Hellman Client Params
+        Pubkey: 8c674d0e08dc27b5eaa…
+
+```
+
+现在客户端和服务器手里都拿到了密钥交换算法的两个参数（Client Params、Server Params），就用ECDHE算法一阵算，算出了一个新的东西，叫“**Pre-Master**”，其实也是一个随机数。
+
+至于具体的计算原理和过程，因为太复杂就不细说了，但算法可以保证即使黑客截获了之前的参数，也是绝对算不出这个随机数的。
+
+现在客户端和服务器手里有了三个随机数：**Client Random、Server Random和Pre-Master**。用这三个作为原始材料，就可以生成用于加密会话的主密钥，叫“**Master Secret**”。而黑客因为拿不到“Pre-Master”，所以也就得不到主密钥。
+
+为什么非得这么麻烦，非要三个随机数呢？
+
+这就必须说TLS的设计者考虑得非常周到了，他们不信任客户端或服务器伪随机数的可靠性，为了保证真正的“完全随机”“不可预测”，把三个不可靠的随机数混合起来，那么“随机”的程度就非常高了，足够让黑客难以猜测。
+
+你一定很想知道“Master Secret”究竟是怎么算出来的吧，贴一下RFC里的公式：
+
+```
+master_secret = PRF(pre_master_secret, &quot;master secret&quot;,
+                    ClientHello.random + ServerHello.random)
+
+```
+
+这里的“PRF”就是伪随机数函数，它基于密码套件里的最后一个参数，比如这次的SHA384，通过摘要算法来再一次强化“Master Secret”的随机性。
+
+主密钥有48字节，但它也不是最终用于通信的会话密钥，还会再用PRF扩展出更多的密钥，比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key）等等，避免只用一个密钥带来的安全隐患。
+
+有了主密钥和派生的会话密钥，握手就快结束了。客户端发一个“**Change Cipher Spec**”，然后再发一个“**Finished**”消息，把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证。
+
+意思就是告诉服务器：“后面都改用对称算法加密通信了啊，用的就是打招呼时说的AES，加密对不对还得你测一下。”
+
+服务器也是同样的操作，发“**Change Cipher Spec**”和“**Finished**”消息，双方都验证加密解密OK，握手正式结束，后面就收发被加密的HTTP请求和响应了。
+
+## RSA握手过程
+
+整个握手过程可真是够复杂的，但你可能会问了，好像这个过程和其他地方看到的不一样呢？
+
+刚才说的其实是如今主流的TLS握手过程，这与传统的握手有两点不同。
+
+第一个，使用ECDHE实现密钥交换，而不是RSA，所以会在服务器端发出“Server Key Exchange”消息。
+
+第二个，因为使用了ECDHE，客户端可以不用等到服务器发回“Finished”确认握手完毕，立即就发出HTTP报文，省去了一个消息往返的时间浪费。这个叫“**TLS False Start**”，意思就是“抢跑”，和“TCP Fast Open”有点像，都是不等连接完全建立就提前发应用数据，提高传输的效率。
+
+实验环境在440端口（[https://www.chrono.com:440/26-1](https://www.chrono.com:440/26-1)）实现了传统的RSA密钥交换，没有“False Start”，你可以课后自己抓包看一下，这里我也画了个图。
+
+<img src="https://static001.geekbang.org/resource/image/cb/d2/cb9a89055eadb452b7835ba8db7c3ad2.png" alt="">
+
+大体的流程没有变，只是“Pre-Master”不再需要用算法生成，而是客户端直接生成随机数，然后用服务器的公钥加密，通过“**Client Key Exchange**”消息发给服务器。服务器再用私钥解密，这样双方也实现了共享三个随机数，就可以生成主密钥。
+
+## 双向认证
+
+到这里TLS握手就基本讲完了。
+
+不过上面说的是“**单向认证**”握手过程，只认证了服务器的身份，而没有认证客户端的身份。这是因为通常单向认证通过后已经建立了安全通信，用账号、密码等简单的手段就能够确认用户的真实身份。
+
+但为了防止账号、密码被盗，有的时候（比如网上银行）还会使用U盾给用户颁发客户端证书，实现“**双向认证**”，这样会更加安全。
+
+双向认证的流程也没有太多变化，只是在“**Server Hello Done**”之后，“**Client Key Exchange**”之前，客户端要发送“**Client Certificate**”消息，服务器收到后也把证书链走一遍，验证客户端的身份。
+
+## 小结
+
+今天我们学习了HTTPS/TLS的握手，内容比较多、比较难，不过记住下面四点就可以。
+
+1. HTTPS协议会先与服务器执行TCP握手，然后执行TLS握手，才能建立安全连接；
+1. 握手的目标是安全地交换对称密钥，需要三个随机数，第三个随机数“Pre-Master”必须加密传输，绝对不能让黑客破解；
+1. “Hello”消息交换随机数，“Key Exchange”消息交换“Pre-Master”；
+1. “Change Cipher Spec”之前传输的都是明文，之后都是对称密钥加密的密文。
+
+## 课下作业
+
+1. 密码套件里的那些算法分别在握手过程中起了什么作用？
+1. 你能完整地描述一下RSA的握手过程吗？
+1. 你能画出双向认证的流程图吗？
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+<img src="https://static001.geekbang.org/resource/image/93/14/93d002084d9bf8283bab3e34e3f4bf14.png" alt="unpreview">
+
+

极客时间专栏/透视HTTP协议/安全篇/27 | 更好更快的握手：TLS1.3特性解析.md

@@ -0,0 +1,183 @@
+<audio id="audio" title="27 | 更好更快的握手：TLS1.3特性解析" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ac/aa/ac1b38c2d8b6278fffc5ef099f7edeaa.mp3"></audio>
+
+上一讲中我讲了TLS1.2的握手过程，你是不是已经完全掌握了呢？
+
+不过TLS1.2已经是10年前（2008年）的“老”协议了，虽然历经考验，但毕竟“岁月不饶人”，在安全、性能等方面已经跟不上如今的互联网了。
+
+于是经过四年、近30个草案的反复打磨，TLS1.3终于在去年（2018年）“粉墨登场”，再次确立了信息安全领域的新标准。
+
+在抓包分析握手之前，我们先来快速浏览一下TLS1.3的三个主要改进目标：**兼容**、**安全与性能**。
+
+## 最大化兼容性
+
+由于1.1、1.2等协议已经出现了很多年，很多应用软件、中间代理（官方称为“MiddleBox”）只认老的记录协议格式，更新改造很困难，甚至是不可行（设备僵化）。
+
+在早期的试验中发现，一旦变更了记录头字段里的版本号，也就是由0x303（TLS1.2）改为0x304（TLS1.3）的话，大量的代理服务器、网关都无法正确处理，最终导致TLS握手失败。
+
+为了保证这些被广泛部署的“老设备”能够继续使用，避免新协议带来的“冲击”，TLS1.3不得不做出妥协，保持现有的记录格式不变，通过“伪装”来实现兼容，使得TLS1.3看上去“像是”TLS1.2。
+
+那么，该怎么区分1.2和1.3呢？
+
+这要用到一个新的**扩展协议**（Extension Protocol），它有点“补充条款”的意思，通过在记录末尾添加一系列的“扩展字段”来增加新的功能，老版本的TLS不认识它可以直接忽略，这就实现了“后向兼容”。
+
+在记录头的Version字段被兼容性“固定”的情况下，只要是TLS1.3协议，握手的“Hello”消息后面就必须有“**supported_versions**”扩展，它标记了TLS的版本号，使用它就能区分新旧协议。
+
+其实上一讲Chrome在握手时发的就是TLS1.3协议，你可以看一下“Client Hello”消息后面的扩展，只是因为服务器不支持1.3，所以就“后向兼容”降级成了1.2。
+
+```
+Handshake Protocol: Client Hello
+    Version: TLS 1.2 (0x0303)
+    Extension: supported_versions (len=11)
+        Supported Version: TLS 1.3 (0x0304)
+        Supported Version: TLS 1.2 (0x0303)
+
+```
+
+TLS1.3利用扩展实现了许多重要的功能，比如“supported_groups”“key_share”“signature_algorithms”“server_name”等，这些等后面用到的时候再说。
+
+## 强化安全
+
+TLS1.2在十来年的应用中获得了许多宝贵的经验，陆续发现了很多的漏洞和加密算法的弱点，所以TLS1.3就在协议里修补了这些不安全因素。
+
+比如：
+
+- 伪随机数函数由PRF升级为HKDF（HMAC-based Extract-and-Expand Key Derivation Function）；
+- 明确禁止在记录协议里使用压缩；
+- 废除了RC4、DES对称加密算法；
+- 废除了ECB、CBC等传统分组模式；
+- 废除了MD5、SHA1、SHA-224摘要算法；
+- 废除了RSA、DH密钥交换算法和许多命名曲线。
+
+经过这一番“减肥瘦身”之后，TLS1.3里只保留了AES、ChaCha20对称加密算法，分组模式只能用AEAD的GCM、CCM和Poly1305，摘要算法只能用SHA256、SHA384，密钥交换算法只有ECDHE和DHE，椭圆曲线也被“砍”到只剩P-256和x25519等5种。
+
+减肥可以让人变得更轻巧灵活，TLS也是这样。
+
+算法精简后带来了一个意料之中的好处：原来众多的算法、参数组合导致密码套件非常复杂，难以选择，而现在的TLS1.3里只有5个套件，无论是客户端还是服务器都不会再犯“选择困难症”了。
+
+<img src="https://static001.geekbang.org/resource/image/ee/65/eeeb1d30acbc0e69541ce0620346b765.jpg" alt="">
+
+这里还要特别说一下废除RSA和DH密钥交换算法的原因。
+
+上一讲用Wireshark抓包时你一定看到了，浏览器默认会使用ECDHE而不是RSA做密钥交换，这是因为它不具有“**前向安全**”（Forward Secrecy）。
+
+假设有这么一个很有耐心的黑客，一直在长期收集混合加密系统收发的所有报文。如果加密系统使用服务器证书里的RSA做密钥交换，一旦私钥泄露或被破解（使用社会工程学或者巨型计算机），那么黑客就能够使用私钥解密出之前所有报文的“Pre-Master”，再算出会话密钥，破解所有密文。
+
+这就是所谓的“**今日截获，明日破解**”。
+
+而ECDHE算法在每次握手时都会生成一对临时的公钥和私钥，每次通信的密钥对都是不同的，也就是“一次一密”，即使黑客花大力气破解了这一次的会话密钥，也只是这次通信被攻击，之前的历史消息不会受到影响，仍然是安全的。
+
+所以现在主流的服务器和浏览器在握手阶段都已经不再使用RSA，改用ECDHE，而TLS1.3在协议里明确废除RSA和DH则在标准层面保证了“前向安全”。
+
+## 提升性能
+
+HTTPS建立连接时除了要做TCP握手，还要做TLS握手，在1.2中会多花两个消息往返（2-RTT），可能导致几十毫秒甚至上百毫秒的延迟，在移动网络中延迟还会更严重。
+
+现在因为密码套件大幅度简化，也就没有必要再像以前那样走复杂的协商流程了。TLS1.3压缩了以前的“Hello”协商过程，删除了“Key Exchange”消息，把握手时间减少到了“1-RTT”，效率提高了一倍。
+
+那么它是怎么做的呢？
+
+其实具体的做法还是利用了扩展。客户端在“Client Hello”消息里直接用“**supported_groups**”带上支持的曲线，比如P-256、x25519，用“**key_share**”带上曲线对应的客户端公钥参数，用“**signature_algorithms**”带上签名算法。
+
+服务器收到后在这些扩展里选定一个曲线和参数，再用“key_share”扩展返回服务器这边的公钥参数，就实现了双方的密钥交换，后面的流程就和1.2基本一样了。
+
+我为1.3的握手过程画了一张图，你可以对比1.2看看区别在哪里。
+
+<img src="https://static001.geekbang.org/resource/image/4d/b0/4d1df4d07dbb1c2500fc4ea69ecf7ab0.png" alt="">
+
+除了标准的“1-RTT”握手，TLS1.3还引入了“0-RTT”握手，用“pre_shared_key”和“early_data”扩展，在TCP连接后立即就建立安全连接发送加密消息，不过这需要有一些前提条件，今天暂且不说。
+
+## 握手分析
+
+目前Nginx等Web服务器都能够很好地支持TLS1.3，但要求底层的OpenSSL必须是1.1.1，而我们实验环境里用的OpenSSL是1.1.0，所以暂时无法直接测试TLS1.3。
+
+不过我在Linux上用OpenSSL1.1.1编译了一个支持TLS1.3的Nginx，用Wireshark抓包存到了GitHub上，用它就可以分析TLS1.3的握手过程。
+
+<img src="https://static001.geekbang.org/resource/image/7a/db/7a2bc39fdbb421cf72a01e887e9156db.png" alt="">
+
+在TCP建立连接之后，浏览器首先还是发一个“**Client Hello**”。
+
+因为1.3的消息兼容1.2，所以开头的版本号、支持的密码套件和随机数（Client Random）结构都是一样的（不过这时的随机数是32个字节）。
+
+```
+Handshake Protocol: Client Hello
+    Version: TLS 1.2 (0x0303)
+    Random: cebeb6c05403654d66c2329…
+    Cipher Suites (18 suites)
+        Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
+        Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
+        Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
+    Extension: supported_versions (len=9)
+        Supported Version: TLS 1.3 (0x0304)
+        Supported Version: TLS 1.2 (0x0303)
+    Extension: supported_groups (len=14)
+        Supported Groups (6 groups)
+            Supported Group: x25519 (0x001d)
+            Supported Group: secp256r1 (0x0017)
+    Extension: key_share (len=107)
+        Key Share extension
+            Client Key Share Length: 105
+            Key Share Entry: Group: x25519
+            Key Share Entry: Group: secp256r1
+
+```
+
+注意“Client Hello”里的扩展，“**supported_versions**”表示这是TLS1.3，“**supported_groups**”是支持的曲线，“**key_share**”是曲线对应的参数。
+
+这就好像是说：
+
+“还是照老规矩打招呼，这边有这些这些信息。但我猜你可能会升级，所以再多给你一些东西，也许后面用的上，咱们有话尽量一口气说完。”
+
+服务器收到“Client Hello”同样返回“Server Hello”消息，还是要给出一个**随机数**（Server Random）和选定密码套件。
+
+```
+Handshake Protocol: Server Hello
+    Version: TLS 1.2 (0x0303)
+    Random: 12d2bce6568b063d3dee2…
+    Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
+    Extension: supported_versions (len=2)
+        Supported Version: TLS 1.3 (0x0304)
+    Extension: key_share (len=36)
+        Key Share extension
+            Key Share Entry: Group: x25519, Key Exchange length: 32
+
+```
+
+表面上看和TLS1.2是一样的，重点是后面的扩展。“**supported_versions**”里确认使用的是TLS1.3，然后在“**key_share**”扩展带上曲线和对应的公钥参数。
+
+服务器的“Hello”消息大概是这个意思：
+
+“还真让你给猜对了，虽然还是按老规矩打招呼，但咱们来个‘旧瓶装新酒’。刚才你给的我都用上了，我再给几个你缺的参数，这次加密就这么定了。”
+
+这时只交换了两条消息，客户端和服务器就拿到了四个共享信息：**Client Random**和**Server Random**、**Client Params**和**Server Params**，两边就可以各自用ECDHE算出“**Pre-Master**”，再用HKDF生成主密钥“**Master Secret**”，效率比TLS1.2提高了一大截。
+
+在算出主密钥后，服务器立刻发出“**Change Cipher Spec**”消息，比TLS1.2提早进入加密通信，后面的证书等就都是加密的了，减少了握手时的明文信息泄露。
+
+这里TLS1.3还有一个安全强化措施，多了个“**Certificate Verify**”消息，用服务器的私钥把前面的曲线、套件、参数等握手数据加了签名，作用和“**Finished**”消息差不多。但由于是私钥签名，所以强化了身份认证和和防窜改。
+
+这两个“Hello”消息之后，客户端验证服务器证书，再发“Finished”消息，就正式完成了握手，开始收发HTTP报文。
+
+虽然我们的实验环境暂时不能抓包测试TLS1.3，但互联网上很多网站都已经支持了TLS1.3，比如[Nginx](https://www.nginx.com/)、[GitHub](https://github.com/)，你可以课后自己用Wireshark试试。
+
+在Chrome的开发者工具里，可以看到这些网站的TLS1.3应用情况。
+
+<img src="https://static001.geekbang.org/resource/image/44/3c/44d8c3349ffdea5a1e4e13d222bc743c.png" alt="">
+
+## 小结
+
+今天我们一起学习了TLS1.3的新特性，用抓包研究了它的握手过程，不过TLS1.3里的内容很多，还有一些特性没有谈到，后面会继续讲。
+
+1. 为了兼容1.1、1.2等“老”协议，TLS1.3会“伪装”成TLS1.2，新特性在“扩展”里实现；
+1. 1.1、1.2在实践中发现了很多安全隐患，所以TLS1.3大幅度删减了加密算法，只保留了ECDHE、AES、ChaCha20、SHA-2等极少数算法，强化了安全；
+1. TLS1.3也简化了握手过程，完全握手只需要一个消息往返，提升了性能。
+
+## 课下作业
+
+1. TLS1.3里的密码套件没有指定密钥交换算法和签名算法，那么在握手的时候会不会有问题呢？
+1. 结合上一讲的RSA握手过程，解释一下为什么RSA密钥交换不具有“前向安全”。
+1. TLS1.3的握手过程与TLS1.2的“False Start”有什么异同？
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+<img src="https://static001.geekbang.org/resource/image/ab/64/ab532f0074ddb136cd96c76c3a385164.png" alt="unpreview">
+
+

极客时间专栏/透视HTTP协议/安全篇/28 | 连接太慢该怎么办：HTTPS的优化.md

@@ -0,0 +1,166 @@
+<audio id="audio" title="28 | 连接太慢该怎么办：HTTPS的优化" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/3e/02/3e5a61bf873fe75c1dc93dfc5c08d602.mp3"></audio>
+
+你可能或多或少听别人说过，“HTTPS的连接很慢”。那么“慢”的原因是什么呢？
+
+通过前两讲的学习，你可以看到，HTTPS连接大致上可以划分为两个部分，第一个是建立连接时的**非对称加密握手**，第二个是握手后的**对称加密报文传输**。
+
+由于目前流行的AES、ChaCha20性能都很好，还有硬件优化，报文传输的性能损耗可以说是非常地小，小到几乎可以忽略不计了。所以，通常所说的“HTTPS连接慢”指的就是刚开始建立连接的那段时间。
+
+在TCP建连之后，正式数据传输之前，HTTPS比HTTP增加了一个TLS握手的步骤，这个步骤最长可以花费两个消息往返，也就是2-RTT。而且在握手消息的网络耗时之外，还会有其他的一些“隐形”消耗，比如：
+
+- 产生用于密钥交换的临时公私钥对（ECDHE）；
+- 验证证书时访问CA获取CRL或者OCSP；
+- 非对称加密解密处理“Pre-Master”。
+
+在最差的情况下，也就是不做任何的优化措施，HTTPS建立连接可能会比HTTP慢上几百毫秒甚至几秒，这其中既有网络耗时，也有计算耗时，就会让人产生“打开一个HTTPS网站好慢啊”的感觉。
+
+不过刚才说的情况早就是“过去时”了，现在已经有了很多行之有效的HTTPS优化手段，运用得好可以把连接的额外耗时降低到几十毫秒甚至是“零”。
+
+我画了一张图，把TLS握手过程中影响性能的部分都标记了出来，对照着它就可以“有的放矢”地来优化HTTPS。
+
+<img src="https://static001.geekbang.org/resource/image/c4/ed/c41da1f1b1bdf4dc92c46330542c5ded.png" alt="">
+
+## 硬件优化
+
+在计算机世界里的“优化”可以分成“硬件优化”和“软件优化”两种方式，先来看看有哪些硬件的手段。
+
+硬件优化，说白了就是“花钱”。但花钱也是有门道的，要“有钱用在刀刃上”，不能大把的银子撒出去“只听见响”。
+
+HTTPS连接是计算密集型，而不是I/O密集型。所以，如果你花大价钱去买网卡、带宽、SSD存储就是“南辕北辙”了，起不到优化的效果。
+
+那该用什么样的硬件来做优化呢？
+
+首先，你可以选择**更快的CPU**，最好还内建AES优化，这样即可以加速握手，也可以加速传输。
+
+其次，你可以选择“**SSL加速卡**”，加解密时调用它的API，让专门的硬件来做非对称加解密，分担CPU的计算压力。
+
+不过“SSL加速卡”也有一些缺点，比如升级慢、支持算法有限，不能灵活定制解决方案等。
+
+所以，就出现了第三种硬件加速方式：“**SSL加速服务器**”，用专门的服务器集群来彻底“卸载”TLS握手时的加密解密计算，性能自然要比单纯的“加速卡”要强大的多。
+
+## 软件优化
+
+不过硬件优化方式中除了CPU，其他的通常可不是靠简单花钱就能买到的，还要有一些开发适配工作，有一定的实施难度。比如，“加速服务器”中关键的一点是通信必须是“异步”的，不能阻塞应用服务器，否则加速就没有意义了。
+
+所以，软件优化的方式相对来说更可行一些，性价比高，能够“少花钱，多办事”。
+
+软件方面的优化还可以再分成两部分：一个是**软件升级**，一个是**协议优化**。
+
+软件升级实施起来比较简单，就是把现在正在使用的软件尽量升级到最新版本，比如把Linux内核由2.x升级到4.x，把Nginx由1.6升级到1.16，把OpenSSL由1.0.1升级到1.1.0/1.1.1。
+
+由于这些软件在更新版本的时候都会做性能优化、修复错误，只要运维能够主动配合，这种软件优化是最容易做的，也是最容易达成优化效果的。
+
+但对于很多大中型公司来说，硬件升级或软件升级都是个棘手的问题，有成千上万台各种型号的机器遍布各个机房，逐一升级不仅需要大量人手，而且有较高的风险，可能会影响正常的线上服务。
+
+所以，在软硬件升级都不可行的情况下，我们最常用的优化方式就是在现有的环境下挖掘协议自身的潜力。
+
+## 协议优化
+
+从刚才的TLS握手图中你可以看到影响性能的一些环节，协议优化就要从这些方面着手，先来看看核心的密钥交换过程。
+
+如果有可能，应当尽量采用TLS1.3，它大幅度简化了握手的过程，完全握手只要1-RTT，而且更加安全。
+
+如果暂时不能升级到1.3，只能用1.2，那么握手时使用的密钥交换协议应当尽量选用椭圆曲线的ECDHE算法。它不仅运算速度快，安全性高，还支持“False Start”，能够把握手的消息往返由2-RTT减少到1-RTT，达到与TLS1.3类似的效果。
+
+另外，椭圆曲线也要选择高性能的曲线，最好是x25519，次优选择是P-256。对称加密算法方面，也可以选用“AES_128_GCM”，它能比“AES_256_GCM”略快一点点。
+
+在Nginx里可以用“ssl_ciphers”“ssl_ecdh_curve”等指令配置服务器使用的密码套件和椭圆曲线，把优先使用的放在前面，例如：
+
+```
+ssl_ciphers   TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:EECDH+CHACHA20；
+ssl_ecdh_curve              X25519:P-256;
+
+```
+
+## 证书优化
+
+除了密钥交换，握手过程中的证书验证也是一个比较耗时的操作，服务器需要把自己的证书链全发给客户端，然后客户端接收后再逐一验证。
+
+这里就有两个优化点，一个是**证书传输**，一个是**证书验证**。
+
+服务器的证书可以选择椭圆曲线（ECDSA）证书而不是RSA证书，因为224位的ECC相当于2048位的RSA，所以椭圆曲线证书的“个头”要比RSA小很多，即能够节约带宽也能减少客户端的运算量，可谓“一举两得”。
+
+客户端的证书验证其实是个很复杂的操作，除了要公钥解密验证多个证书签名外，因为证书还有可能会被撤销失效，客户端有时还会再去访问CA，下载CRL或者OCSP数据，这又会产生DNS查询、建立连接、收发数据等一系列网络通信，增加好几个RTT。
+
+CRL（Certificate revocation list，证书吊销列表）由CA定期发布，里面是所有被撤销信任的证书序号，查询这个列表就可以知道证书是否有效。
+
+但CRL因为是“定期”发布，就有“时间窗口”的安全隐患，而且随着吊销证书的增多，列表会越来越大，一个CRL经常会上MB。想象一下，每次需要预先下载几M的“无用数据”才能连接网站，实用性实在是太低了。
+
+所以，现在CRL基本上不用了，取而代之的是OCSP（在线证书状态协议，Online Certificate Status Protocol），向CA发送查询请求，让CA返回证书的有效状态。
+
+但OCSP也要多出一次网络请求的消耗，而且还依赖于CA服务器，如果CA服务器很忙，那响应延迟也是等不起的。
+
+于是又出来了一个“补丁”，叫“OCSP Stapling”（OCSP装订），它可以让服务器预先访问CA获取OCSP响应，然后在握手时随着证书一起发给客户端，免去了客户端连接CA服务器查询的时间。
+
+## 会话复用
+
+到这里，我们已经讨论了四种HTTPS优化手段（硬件优化、软件优化、协议优化、证书优化），那么，还有没有其他更好的方式呢？
+
+我们再回想一下HTTPS建立连接的过程：先是TCP三次握手，然后是TLS一次握手。这后一次握手的重点是算出主密钥“Master Secret”，而主密钥每次连接都要重新计算，未免有点太浪费了，如果能够把“辛辛苦苦”算出来的主密钥缓存一下“重用”，不就可以免去了握手和计算的成本了吗？
+
+这种做法就叫“**会话复用**”（TLS session resumption），和HTTP Cache一样，也是提高HTTPS性能的“大杀器”，被浏览器和服务器广泛应用。
+
+会话复用分两种，第一种叫“**Session ID**”，就是客户端和服务器首次连接后各自保存一个会话的ID号，内存里存储主密钥和其他相关的信息。当客户端再次连接时发一个ID过来，服务器就在内存里找，找到就直接用主密钥恢复会话状态，跳过证书验证和密钥交换，只用一个消息往返就可以建立安全通信。
+
+实验环境的端口441实现了“Session ID”的会话复用，你可以访问URI<br>
+“[https://www.chrono.com:441/28-1](https://www.chrono.com:441/28-1)”，刷新几次，用Wireshark抓包看看实际的效果。
+
+```
+Handshake Protocol: Client Hello
+    Version: TLS 1.2 (0x0303)
+    Session ID: 13564734eeec0a658830cd…
+    Cipher Suites Length: 34
+
+
+Handshake Protocol: Server Hello
+    Version: TLS 1.2 (0x0303)
+    Session ID: 13564734eeec0a658830cd…
+    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
+
+```
+
+通过抓包可以看到，服务器在“ServerHello”消息后直接发送了“Change Cipher Spec”和“Finished”消息，复用会话完成了握手。
+
+<img src="https://static001.geekbang.org/resource/image/12/ac/125fe443a147ed38a97a4492045d98ac.png" alt="">
+
+## 会话票证
+
+“Session ID”是最早出现的会话复用技术，也是应用最广的，但它也有缺点，服务器必须保存每一个客户端的会话数据，对于拥有百万、千万级别用户的网站来说存储量就成了大问题，加重了服务器的负担。
+
+于是，又出现了第二种“**Session Ticket**”方案。
+
+它有点类似HTTP的Cookie，存储的责任由服务器转移到了客户端，服务器加密会话信息，用“New Session Ticket”消息发给客户端，让客户端保存。
+
+重连的时候，客户端使用扩展“**session_ticket**”发送“Ticket”而不是“Session ID”，服务器解密后验证有效期，就可以恢复会话，开始加密通信。
+
+这个过程也可以在实验环境里测试，端口号是442，URI是“[https://www.chrono.com:442/28-1](https://www.chrono.com:442/28-1)”。
+
+不过“Session Ticket”方案需要使用一个固定的密钥文件（ticket_key）来加密Ticket，为了防止密钥被破解，保证“前向安全”，密钥文件需要定期轮换，比如设置为一小时或者一天。
+
+## 预共享密钥
+
+“False Start”“Session ID”“Session Ticket”等方式只能实现1-RTT，而TLS1.3更进一步实现了“**0-RTT**”，原理和“Session Ticket”差不多，但在发送Ticket的同时会带上应用数据（Early Data），免去了1.2里的服务器确认步骤，这种方式叫“**Pre-shared Key**”，简称为“PSK”。
+
+<img src="https://static001.geekbang.org/resource/image/11/ab/119cfd261db49550411a12b1f6d826ab.png" alt="">
+
+但“PSK”也不是完美的，它为了追求效率而牺牲了一点安全性，容易受到“重放攻击”（Replay attack）的威胁。黑客可以截获“PSK”的数据，像复读机那样反复向服务器发送。
+
+解决的办法是只允许安全的GET/HEAD方法（参见[第10讲](https://time.geekbang.org/column/article/101518)），在消息里加入时间戳、“nonce”验证，或者“一次性票证”限制重放。
+
+## 小结
+
+1. 可以有多种硬件和软件手段减少网络耗时和计算耗时，让HTTPS变得和HTTP一样快，最可行的是软件优化；
+1. 应当尽量使用ECDHE椭圆曲线密码套件，节约带宽和计算量，还能实现“False Start”；
+1.  服务器端应当开启“OCSP Stapling”功能，避免客户端访问CA去验证证书；
+1. 会话复用的效果类似Cache，前提是客户端必须之前成功建立连接，后面就可以用“Session ID”“Session Ticket”等凭据跳过密钥交换、证书验证等步骤，直接开始加密通信。
+
+## 课下作业
+
+1. 你能比较一下“Session ID”“Session Ticket”“PSK”这三种会话复用手段的异同吗？
+1. 你觉得哪些优化手段是你在实际工作中能用到的？应该怎样去用？
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+<img src="https://static001.geekbang.org/resource/image/a2/ab/a251606fb0637c6db45b7fd6660af5ab.png" alt="unpreview">
+
+

极客时间专栏/透视HTTP协议/安全篇/29 | 我应该迁移到HTTPS吗？.md

@@ -0,0 +1,187 @@
+<audio id="audio" title="29 | 我应该迁移到HTTPS吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/00/fe/0066de60d6234eee65329be1555eb2fe.mp3"></audio>
+
+今天是“安全篇”的最后一讲，我们已经学完了HTTPS、TLS相关的大部分知识。不过，或许你心里还会有一些困惑：
+
+“HTTPS这么复杂，我是否应该迁移到HTTPS呢？它能带来哪些好处呢？具体又应该怎么实施迁移呢？”
+
+这些问题不单是你，也是其他很多人，还有当初的我的真实想法，所以今天我就来跟你聊聊这方面的事情。
+
+## 迁移的必要性
+
+如果你做移动应用开发的话，那么就一定知道，Apple、Android、某信等开发平台在2017年就相继发出通知，要求所有的应用必须使用HTTPS连接，禁止不安全的HTTP。
+
+在台式机上，主流的浏览器Chrome、Firefox等也早就开始“强推”HTTPS，把HTTP站点打上“不安全”的标签，给用户以“心理压力”。
+
+Google等搜索巨头还利用自身的“话语权”优势，降低HTTP站点的排名，而给HTTPS更大的权重，力图让网民只访问到HTTPS网站。
+
+这些手段都逐渐“挤压”了纯明文HTTP的生存空间，“迁移到HTTPS”已经不是“要不要做”的问题，而是“要怎么做”的问题了。HTTPS的大潮无法阻挡，如果还是死守着HTTP，那么无疑会被冲刷到互联网的角落里。
+
+目前国内外的许多知名大站都已经实现了“全站HTTPS”，打开常用的某宝、某东、某浪，都可以在浏览器的地址栏里看到“小锁头”，如果你正在维护的网站还没有实施HTTPS，那可要抓点紧了。
+
+## 迁移的顾虑
+
+据我观察，阻碍HTTPS实施的因素还有一些这样那样的顾虑，我总结出了三个比较流行的观点：“慢、贵、难”。
+
+所谓“慢”，是指惯性思维，拿以前的数据来评估HTTPS的性能，认为HTTPS会增加服务器的成本，增加客户端的时延，影响用户体验。
+
+其实现在服务器和客户端的运算能力都已经有了很大的提升，性能方面完全没有担心的必要，而且还可以应用很多的优化解决方案（参见[第28讲](https://time.geekbang.org/column/article/111287)）。根据Google等公司的评估，在经过适当优化之后，HTTPS的额外CPU成本小于1%，额外的网络成本小于2%，可以说是与无加密的HTTP相差无几。
+
+所谓“贵”，主要是指证书申请和维护的成本太高，网站难以承担。
+
+这也属于惯性思维，在早几年的确是个问题，向CA申请证书的过程不仅麻烦，而且价格昂贵，每年要交几千甚至几万元。
+
+但现在就不一样了，为了推广HTTPS，很多云服务厂商都提供了一键申请、价格低廉的证书，而且还出现了专门颁发免费证书的CA，其中最著名的就是“**Let’s Encrypt**”。
+
+所谓的“难”，是指HTTPS涉及的知识点太多、太复杂，有一定的技术门槛，不能很快上手。
+
+这第三个顾虑比较现实，HTTPS背后关联到了密码学、TLS、PKI等许多领域，不是短短几周、几个月就能够精通的。但实施HTTPS也并不需要把这些完全掌握，只要抓住少数几个要点就好，下面我就来帮你逐个解决一些关键的“难点”。
+
+## 申请证书
+
+要把网站从HTTP切换到HTTPS，首先要做的就是为网站申请一张证书。
+
+大型网站出于信誉、公司形象的考虑，通常会选择向传统的CA申请证书，例如DigiCert、GlobalSign，而中小型网站完全可以选择使用“Let’s Encrypt”这样的免费证书，效果也完全不输于那些收费的证书。
+
+“**Let’s Encrypt**”一直在推动证书的自动化部署，为此还实现了专门的ACME协议（RFC8555）。有很多的客户端软件可以完成申请、验证、下载、更新的“一条龙”操作，比如Certbot、acme.sh等等，都可以在“Let’s Encrypt”网站上找到，用法很简单，相关的文档也很详细，几分钟就能完成申请，所以我在这里就不细说了。
+
+不过我必须提醒你几个注意事项。
+
+第一，申请证书时应当同时申请RSA和ECDSA两种证书，在Nginx里配置成双证书验证，这样服务器可以自动选择快速的椭圆曲线证书，同时也兼容只支持RSA的客户端。
+
+第二，如果申请RSA证书，私钥至少要2048位，摘要算法应该选用SHA-2，例如SHA256、SHA384等。
+
+第三，出于安全的考虑，“Let’s Encrypt”证书的有效期很短，只有90天，时间一到就会过期失效，所以必须要定期更新。你可以在crontab里加个每周或每月任务，发送更新请求，不过很多ACME客户端会自动添加这样的定期任务，完全不用你操心。
+
+## 配置HTTPS
+
+搞定了证书，接下来就是配置Web服务器，在443端口上开启HTTPS服务了。
+
+这在Nginx上非常简单，只要在“listen”指令后面加上参数“ssl”，再配上刚才的证书文件就可以实现最基本的HTTPS。
+
+```
+listen                443 ssl;
+
+ssl_certificate       xxx_rsa.crt;  #rsa2048 cert
+ssl_certificate_key   xxx_rsa.key;  #rsa2048 private key
+
+ssl_certificate       xxx_ecc.crt;  #ecdsa cert
+ssl_certificate_key   xxx_ecc.key;  #ecdsa private ke
+
+```
+
+为了提高HTTPS的安全系数和性能，你还可以强制Nginx只支持TLS1.2以上的协议，打开“Session Ticket”会话复用：
+
+```
+ssl_protocols               TLSv1.2 TLSv1.3;
+
+ssl_session_timeout         5m;
+ssl_session_tickets         on;
+ssl_session_ticket_key      ticket.key;
+
+```
+
+密码套件的选择方面，我给你的建议是以服务器的套件优先。这样可以避免恶意客户端故意选择较弱的套件、降低安全等级，然后密码套件向TLS1.3“看齐”，只使用ECDHE、AES和ChaCha20，支持“False Start”。
+
+```
+ssl_prefer_server_ciphers   on;
+
+
+ssl_ciphers   ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE+AES128:!MD5:!SHA1;
+
+```
+
+如果你的服务器上使用了OpenSSL的分支BorringSSL，那么还可以使用一个特殊的“等价密码组”（Equal preference cipher groups）特性，它可以让服务器配置一组“等价”的密码套件，在这些套件里允许客户端优先选择，比如这么配置：
+
+```
+ssl_ciphers 
+[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305];
+
+```
+
+如果客户端硬件没有AES优化，服务器就会顺着客户端的意思，优先选择与AES“等价”的ChaCha20算法，让客户端能够快一点。
+
+全部配置完成后，你可以访问“[SSLLabs](https://www.ssllabs.com/)”网站，测试网站的安全程度，它会模拟多种客户端发起测试，打出一个综合的评分。
+
+下图就是GitHub网站的评分结果：
+
+<img src="https://static001.geekbang.org/resource/image/a6/1b/a662d410dfdaa8ab44b36cbb68ab8d1b.png" alt="">
+
+## 服务器名称指示
+
+配置HTTPS服务时还有一个“虚拟主机”的问题需要解决。
+
+在HTTP协议里，多个域名可以同时在一个IP地址上运行，这就是“虚拟主机”，Web服务器会使用请求头里的Host字段（参见[第9讲](https://time.geekbang.org/column/article/100513)）来选择。
+
+但在HTTPS里，因为请求头只有在TLS握手之后才能发送，在握手时就必须选择“虚拟主机”对应的证书，TLS无法得知域名的信息，就只能用IP地址来区分。所以，最早的时候每个HTTPS域名必须使用独立的IP地址，非常不方便。
+
+那么怎么解决这个问题呢？
+
+这还是得用到TLS的“扩展”，给协议加个**SNI**（Server Name Indication）的“补充条款”。它的作用和Host字段差不多，客户端会在“Client Hello”时带上域名信息，这样服务器就可以根据名字而不是IP地址来选择证书。
+
+```
+Extension: server_name (len=19)
+    Server Name Indication extension
+        Server Name Type: host_name (0)
+        Server Name: www.chrono.com
+
+```
+
+Nginx很早就基于SNI特性支持了HTTPS的虚拟主机，但在OpenResty里可还以编写Lua脚本，利用Redis、MySQL等数据库更灵活快速地加载证书。
+
+## 重定向跳转
+
+现在有了HTTPS服务，但原来的HTTP站点也不能马上弃用，还是会有很多网民习惯在地址栏里直接敲域名（或者是旧的书签、超链接），默认使用HTTP协议访问。
+
+所以，我们就需要用到第18讲里的“重定向跳转”技术了，把不安全的HTTP网址用301或302“重定向”到新的HTTPS网站，这在Nginx里也很容易做到，使用“return”或“rewrite”都可以。
+
+```
+return 301 https://$host$request_uri;             #永久重定向
+rewrite ^  https://$host$request_uri permanent;   #永久重定向
+
+```
+
+但这种方式有两个问题。一个是重定向增加了网络成本，多出了一次请求；另一个是存在安全隐患，重定向的响应可能会被“中间人”窜改，实现“会话劫持”，跳转到恶意网站。
+
+不过有一种叫“**HSTS**”（HTTP严格传输安全，HTTP Strict Transport Security）的技术可以消除这种安全隐患。HTTPS服务器需要在发出的响应头里添加一个“**Strict-Transport-Security**”的字段，再设定一个有效期，例如：
+
+```
+Strict-Transport-Security: max-age=15768000; includeSubDomains
+
+```
+
+这相当于告诉浏览器：我这个网站必须严格使用HTTPS协议，在半年之内（182.5天）都不允许用HTTP，你以后就自己做转换吧，不要再来麻烦我了。
+
+有了“HSTS”的指示，以后浏览器再访问同样的域名的时候就会自动把URI里的“http”改成“https”，直接访问安全的HTTPS网站。这样“中间人”就失去了攻击的机会，而且对于客户端来说也免去了一次跳转，加快了连接速度。
+
+比如，如果在实验环境的配置文件里用“add_header”指令添加“HSTS”字段：
+
+```
+add_header Strict-Transport-Security max-age=15768000; #182.5days
+
+```
+
+那么Chrome浏览器只会在第一次连接时使用HTTP协议，之后就会都走HTTPS协议。
+
+## 小结
+
+今天我介绍了一些HTTPS迁移的技术要点，掌握了它们你就可以搭建出一个完整的HTTPS站点了。
+
+但想要实现大型网站的“全站HTTPS”还是需要有很多的细枝末节的工作要做，比如使用CSP（Content Security Policy）的各种指令和标签来配置安全策略，使用反向代理来集中“卸载”SSL。
+
+简单小结一下今天的内容：
+
+1. 从HTTP迁移到HTTPS是“大势所趋”，能做就应该尽早做；
+1. 升级HTTPS首先要申请数字证书，可以选择免费好用的“Let’s Encrypt”；
+1. 配置HTTPS时需要注意选择恰当的TLS版本和密码套件，强化安全；
+1. 原有的HTTP站点可以保留作为过渡，使用301重定向到HTTPS。
+
+## 课下作业
+
+1. 结合你的实际工作，分析一下迁移HTTPS的难点有哪些，应该如何克服？
+1. 参考上一讲，你觉得配置HTTPS时还应该加上哪些部分？
+
+欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
+
+<img src="https://static001.geekbang.org/resource/image/db/ec/dbe386f94df8f69fc0b32d2b52e3b3ec.png" alt="unpreview">
+
+<img src="https://static001.geekbang.org/resource/image/56/63/56d766fc04654a31536f554b8bde7b63.jpg" alt="unpreview">