react网站开发,高陵县建设局网站,化工网站模板下载,wordpress 前端发帖230-TLS是什么
1.http不安全
由于 HTTP 天生“明文”的特点#xff0c;整个传输过程完全透明#xff0c;任何人都能够在链路中截获、修改或者伪造请求 / 响应报文#xff0c;数据不具有可信性 #xff1b;
“代理服务”。它作为 HTTP 通信的中间人#xff0c;在数据上下…230-TLS是什么
1.http不安全
由于 HTTP 天生“明文”的特点整个传输过程完全透明任何人都能够在链路中截获、修改或者伪造请求 / 响应报文数据不具有可信性
“代理服务”。它作为 HTTP 通信的中间人在数据上下行的时候可以添加或删除部分头字段也可以使用黑白名单过滤 body 里的关键字甚至直接发送虚假的请求、响应而浏览器和源服务器都没有办法判断报文的真伪 。
这对于网络购物、网上银行、证券交易等需要高度信任的应用场景来说是非常致命的。如果没有基本的安全保护使用互联网进行各种电子商务、电子政务就根本无从谈起
对于安全性要求不那么高的新闻、视频、搜索等网站来说由于互联网上的恶意用户、恶意代理越来越多也很容易遭到“流量劫持”的攻击在页面里强行嵌入广告或者分流用户导致各种利益损失
对于你我这样的普通网民来说HTTP 不安全的隐患就更大了上网的记录会被轻易截获网站是否真实也无法验证黑客可以伪装成银行网站盗取真实姓名、密码、银行卡等敏感信息威胁人身安全和财产安全
2、安全的实现
通常认为如果通信过程具备了四个特性就可以认为是“安全”的这四个特性是机密性、完整性身份认证和不可否认
机密性Secrecy/Confidentiality是指对数据的“保密”只能由可信的人访问对其他人是不可见的“秘密”简单来说就是不能让不相关的人看到不该看的东西。
完整性Integrity也叫一致性是指数据在传输过程中没有被窜改不多也不少“完完整整”地保持着原状 。
机密性虽然可以让数据成为“秘密”但不能防止黑客对数据的修改黑客可以替换数据调整数据的顺序或者增加、删除部分数据破坏通信过程 。
身份认证Authentication是指确认对方的真实身份也就是“证明你真的是你”保证消息只能发送给可信的人。
如果通信时另一方是假冒的网站那么数据再保密也没有用黑客完全可以使用冒充的身份“套”出各种信息加密和没加密一样
不可否认Non-repudiation/Undeniable也叫不可抵赖意思是不能否认已经发生过的行为不能“说话不算数”“耍赖皮”。
3、HTTPS的介绍
新的协议名“https”默认端口号 443
至于其他的什么请求 - 应答模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用 HTTP
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9MoeGXqi-1618498415299)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1617727930979.png)]
HTTPS 凭什么就能做到机密性、完整性这些安全特性呢
秘密就在于 HTTPS 名字里的“S”它把 HTTP 下层的传输协议由 TCP/IP 换成了 SSL/TLS由“HTTP over TCP/IP”变成了“HTTP over SSL/TLS”让 HTTP 运行在了安全的 SSL/TLS 协议上可参考第 4 讲和第 5 讲收发报文不再使用 Socket API而是调用专门的安全接口。
4、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 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。
浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信这些算法的组合被称为“密码套件”cipher suite也叫加密套件。
TLS 的密码套件命名非常规范格式很固定。基本的形式是“密钥交换算法 签名算法 对称加密算法 摘要算法”比如刚才的密码套件的意思就是
“握手时使用 ECDHE 算法进行密钥交换用 RSA 签名和身份认证握手后的通信使用 AES 对称算法密钥长度 256 位分组模式是 GCM摘要算法 SHA384 用于消息认证和产生随机数。”
5、OpenSSL
①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 是开源的所以它还有一些代码分支比如 Google 的 BoringSSL、OpenBSD 的 LibreSSL这些分支在 OpenSSL 的基础上删除了一些老旧代码也增加了一些新特性虽然背后有“大金主”但离取代 OpenSSL 还差得很远。
小结
因为 HTTP 是明文传输所以不安全容易被黑客窃听或窜改通信安全必须同时具备机密性、完整性身份认证和不可否认这四个特性HTTPS 的语法、语义仍然是 HTTP但把下层的协议由 TCP/IP 换成了 SSL/TLSSSL/TLS 是信息安全领域中的权威标准采用多种先进的加密技术保证通信安全OpenSSL 是著名的开源密码学工具包是 SSL/TLS 的具体实现。
课下作业
你能说出 HTTPS 与 HTTP 有哪些区别吗你知道有哪些方法能够实现机密性、完整性等安全特性呢
课外延伸 240-对称加密与非对称加密
①引入
实现机密性最常用的手段是“加密”encrypt就是把消息用某种方式转换成谁也看不懂的乱码只有掌握特殊“钥匙”的人才能再转换出原始文本。
这里的“钥匙”就叫做“密钥”key加密前的消息叫“明文”plain text/clear text加密后的乱码叫“密文”cipher text使用密钥还原明文的过程叫“解密”decrypt是加密的反操作加密解密的操作过程就是“加密算法”。
由于 HTTPS、TLS 都运行在计算机上所以“密钥”就是一长串的数字但约定俗成的度量单位是“位”bit而不是“字节”byte。比如说密钥长度是 128就是 16 字节的二进制串密钥长度 1024就是 128 字节的二进制串。
按照密钥的使用方式对称加密和非对称加密
1、对称加密
“对称加密”很好理解就是指加密和解密时使用的密钥都是同一个是“对称”的。只要保证了密钥的安全那整个通信过程就可以说具有了机密性。
TLS 里有非常多的对称加密算法可供选择比如 RC4、DES、3DES、AES、ChaCha20 等但前三种算法都被认为是不安全的通常都禁止使用目前常用的只有 AES 和 ChaCha20。
AES 的意思是“高级加密标准”Advanced Encryption Standard密钥长度可以是 128、192 或 256。它是 DES 算法的替代者安全强度很高性能也很好而且有的硬件还会做特殊优化所以非常流行是应用最广泛的对称加密算法。
ChaCha20 是 Google 设计的另一种加密算法密钥长度固定为 256 位纯软件运行性能要超过 AES曾经在移动客户端上比较流行但 ARMv8 之后也加入了 AES 硬件优化所以现在不再具有明显的优势但仍然算得上是一个不错算法。
1.1、加密分组模式
对称算法还有一个“分组模式”的概念它可以让算法用固定长度的密钥加密任意长度的明文把小秘密即密钥转化为大秘密即密文。
最早有 ECB、CBC、CFB、OFB 等几种分组模式但都陆续被发现有安全漏洞所以现在基本都不怎么用了。最新的分组模式被称为 AEADAuthenticated Encryption with Associated Data在加密的同时增加了认证的功能常用的是 GCM、CCM 和 Poly1305。
把上面这些组合起来就可以得到 TLS 密码套件中定义的对称加密算法。
把上面这些组合起来就可以得到 TLS 密码套件中定义的对称加密算法。
比如AES128-GCM意思是密钥长度为 128 位的 AES 算法使用的分组模式是 GCMChaCha20-Poly1305 的意思是 ChaCha20 算法使用的分组模式是 Poly1305。
2、非对称加密
对称加密看上去好像完美地实现了机密性但其中有一个很大的问题如何把密钥安全地传递给对方术语叫“密钥交换”。
它有两个密钥一个叫**“公钥”public key一个叫“私钥”private key。两个 密钥是不同的“不对称”公钥可以公开给任何人使用而私钥必须严格保密。 公钥和私钥有个特别的“单向”**性虽然都可以用来加密解密但公钥加密后只能用私钥解密反过来私钥加密后也只能用公钥解密。 非对称加密可以解决“密钥交换”的问题。网站秘密保管私钥在网上任意分发公钥你想 要登录网站只要用公钥加密就行了密文只能由私钥持有者才能解密。而黑客因为没有私 钥所以就无法破解密文。
非对称加密算法的设计要比对称算法难得多在 TLS 里只有很少的几种比如 DH、 DSA、RSA、ECC 等。
RSA 可能是其中最著名的一个几乎可以说是非对称加密的代名词它的安全性基于“整 数分解”的数学难题使用两个超大素数的乘积作为生成密钥的材料想要从公钥推算出私 钥是非常困难的。 10 年前 RSA 密钥的推荐长度是 1024但随着计算机运算能力的提高现在 1024 已经不 安全普遍认为至少要 2048 位。 ECCElliptic Curve Cryptography是非对称加密里的“后起之秀”它基于“椭圆曲线 离散对数”的数学难题使用特定的曲线方程和基点生成公钥和私钥子算法 ECDHE 用于 密钥交换ECDSA 用于数字签名。
目前比较常用的两个曲线是 P-256secp256r1在 OpenSSL 称为 prime256v1和 x25519。P-256 是 NIST美国国家标准技术研究所和 NSA美国国家安全局推荐使 用的曲线而 x25519 被认为是最安全、最快速的曲线。
RSA 的运算速度是非常慢的2048 位的加解密大约是 15KB/S微秒或毫秒级而 AES128 则是 13MB/S纳秒级差了几百倍。
TLS 里使用的混合加密方式其实说穿了也很简单
在通信刚开始的时候使用非对称算法比如 RSA、ECDHE首先解决密钥交换的问题。
然后用随机数产生对称算法使用的**“会话密钥”session key**再用公钥加密。因为会 话密钥很短通常只有 16 字节或 32 字节所以慢一点也无所谓。
对方拿到密文后用私钥解密取出会话密钥。这样双方就实现了对称密钥的安全交换后续就不再使用非对称加密全都使用对称加密。
小结 加密算法的核心思想是“把一个小秘密密钥转化为一个大秘密密文消息”守 住了小秘密也就守住了大秘密 对称加密只使用一个密钥运算速度快密钥必须保密无法做到安全的密钥交换常 用的有 AES 和 ChaCha20 非对称加密使用两个密钥公钥和私钥公钥可以任意分发而私钥保密解决了密钥交 换问题但速度慢常用的有 RSA 和 ECC 把对称加密和非对称加密结合起来就得到了“又好又快”的混合加密也就是 TLS 里使 用的加密方式。
课下作业
加密算法中“密钥”的名字很形象你能试着用现实中的锁和钥匙来比喻一下吗在混合加密中用到了公钥加密因为只能由私钥解密。那么反过来私钥加密后任何人 都可以用公钥解密这有什么用呢[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-imKXuxyq-1618498415306)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618418756034.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MD9vWDiS-1618498415308)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618418766692.png)] 250-数字签名与证书
1.1、摘要算法
实现完整性的手段主要是摘要算法Digest Algorithm也就是常说的散列函数、哈希 函数Hash Function。 你可以把摘要算法近似地理解成一种特殊的压缩算法它能够把任意长度的数据“压缩”成 固定长度、而且独一无二的“摘要”字符串就好像是给这段数据生成了一个数字“指纹”。 换一个角度也可以把摘要算法理解成特殊的“单向”加密算法它只有算法没有密钥 加密后的数据无法解密不能从摘要逆推出原文。
摘要算法实际上是把数据从一个“大空间”映射到了“小空间”所以就存在“冲 突”collision也叫碰撞的可能性就如同现实中的指纹一样可能会有两份不同的原 文对应相同的摘要。好的摘要算法必须能够“抵抗冲突”让这种可能性尽量地小。
因为摘要算法对输入具有“单向性”和“雪崩效应”输入的微小不同会导致输出的剧烈变 化所以也被 TLS 用来生成伪随机数PRFpseudo random function。
你一定在日常工作中听过、或者用过 MD5Message-Digest 5、SHA-1Secure Hash Algorithm 1它们就是最常用的两个摘要算法能够生成 16 字节和 20 字节长度 的数字摘要。但这两个算法的安全强度比较低不够安全在 TLS 里已经被禁止使用了
目前 TLS 推荐使用的是 SHA-1 的后继者SHA-2。 SHA-2 实际上是一系列摘要算法的统称总共有 6 种常用的有 SHA224、SHA256、SHA384分别能够生成 28 字节、32 字节、48 字节的摘要。
1.2、完整性
摘要算法保证了“数字摘要”和原文是完全等价的。所以我们只要在原文后附上它的摘要就能够保证数据的完整性。
不过摘要算法不具有机密性如果明文传输那么黑客可以修改消息后把摘要也一起改了网站还是鉴别不出完整性。 所以真正的完整性必须要建立在机密性之上在混合加密系统里用会话密钥加密消息和摘要这样黑客无法得知明文也就没有办法动手脚了。这有个术语叫哈希消息认证码HMAC。
1.3、数字签名
加密算法结合摘要算法我们的通信过程可以说是比较安全了。但这里还有漏洞就是通信的两个端点endpoint。
就像一开始所说的黑客可以伪装成网站来窃取信息。而反过来他也可以伪装成你向网站发送支付、转账等消息网站没有办法确认你的身份钱可能就这么被偷走了。
现实生活中解决身份认证的手段是签名和印章只要在纸上写下签名或者盖个章就能够证明这份文件确实是由本人而不是其他人发出的。
这个东西就是非对称加密里的“私钥”使用私钥再加上摘要算法就能够实现“数字签名”同时实现“身份认证”和“不可否认”。
数字签名的原理其实很简单就是把公钥私钥的用法反过来之前是公钥加密、私钥解密现在是私钥加密、公钥解密。
但又因为非对称加密效率太低所以私钥只加密原文的摘要这样运算量就小的多而且得到的数字签名也很小方便保管和传输。
签名和公钥一样完全公开任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开拿到摘要后再比对原文验证完整性就可以像签署文件一样证明消息确实是你发的。
刚才的这两个行为也有专用术语叫做“签名”和“验签”。
只要你和网站互相交换公钥就可以用“签名”和“验签”来确认消息的真实性因为私钥保密黑客不能伪造签名就能够保证通信双方的身份。
1.4、数字证书和 CA
到现在综合使用对称加密、非对称加密和摘要算法我们已经实现了安全的四大特性是 不是已经完美了呢 不是的这里还有一个**“公钥的信任”问题**。因为谁都可以发布公钥我们还缺少防止黑客伪造公钥的手段也就是说怎么来判断这个公钥就是你或者某宝的公钥呢
找一个公认的可信第三方让它作为“信任的起点递归的终点”构建起公钥的信任链。
这个“第三方”就是我们常说的CACertificate 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。你必须相信否则整个证书信任链就走不下去了。
有了这个证书体系操作系统和浏览器都内置了各大 CA 的根证书上网的时候只要服务器发过来它的证书就可以验证证书里的签名顺着证书链Certificate Chain一层层地验 证直到找到根证书就能够确定证书是可信的从而里面的公钥也是可信的。
我们的实验环境里使用的证书是“野路子”的自签名证书在 Linux 上用 OpenSSL 命令行签发肯定是不会被浏览器所信任的所以用 Chrome 访问时就会显示成红色标记为不安全。但你只要把它安装进系统的根证书存储区里让它作为信任链的根就不会再有危险警告。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DD1p1PF7-1618498415308)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618419775781.png)]
1.5、证书体系的弱点
证书体系PKIPublic Key Infrastructure虽然是目前整个网络世界的安全基础设施但绝对的安全是不存在的它也有弱点还是关键的**“信任”**二字。
如果 CA 失误或者被欺骗签发了错误的证书虽然证书是真的可它代表的网站却是假的。 还有一种更危险的情况CA 被黑客攻陷或者 CA 有恶意因为它即根证书是信任的源头整个信任链里的所有证书也就都不可信了。
这两种事情并不是“耸人听闻”都曾经实际出现过。所以需要再给证书体系打上一些补丁。
针对第一种开发出了 CRL证书吊销列表Certificate revocation list和 OCSP在线证书状态协议Online Certificate Status Protocol及时废止有问题的证书。
对于第二种因为涉及的证书太多就只能操作系统或者浏览器从根上“下狠手”了撤销对 CA 的信任列入“黑名单”这样它颁发的所有证书就都会被认为是不安全的。
小结
今天的内容可以简单概括为四点
摘要算法用来实现完整性能够为数据生成独一无二的“指纹”常用的算法是 SHA- 2数字签名是私钥对摘要的加密可以由公钥解密后验证实现身份认证和不可否认公钥的分发需要使用数字证书必须由 CA 的信任链来验证否则就是不可信的作为信任链的源头 CA 有时也会不可信解决办法有 CRL、OCSP还有终止信任。
课后作业
1、为什么公钥能够建立信任链用对称加密算法里的对称密钥行不行呢 2. 假设有一个三级的证书体系Root CA 一级 CA 二级 CA你能详细解释一下证书信任链的验证过程吗
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ridWyP1q-1618498415309)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618420004619.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6aohSf4L-1618498415310)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618420018197.png)] 260-TLS1.2连接过程解析
1.1HTTPS建立连接
浏览器首先要从 URI 里提取出协议名和域名。因为 协议名是“https”所以浏览器就知道了端口号是默认的 443它再用 DNS 解析域名得到目标的 IP 地址然后就可以使用三次握手与网站建立 TCP 连接了。
在 HTTP 协议里建立连接后浏览器会立即发送请求报文。但现在是 HTTPS 协议它需要再用另外一个“握手”过程在 TCP 上建立安全连接之后才是收发 HTTP 报文。 这个“握手”过程与 TCP 有些类似是 HTTPS 和 TLS 协议里最重要、最核心的部分懂了它你就可以自豪地说自己“掌握了HTTPS”。
1.2、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它非常简单就是一个“通知”告诉对方后续的数据都将使用加密保护。那么反过来在它之前数据都是明文的。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-h8QXbNNe-1618498415311)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618420469965.png)]
1.3、 抓包的准备工作
TLS 握手的前几个消息都是明文的能够在 Wireshark 里直接看。但只要出现了“Change Cipher Spec”后面的数据就都是密文了看到的也就会是乱码不知道究竟是什么东西。
为了更好地分析 TLS 握手过程你可以再对系统和 Wireshark 做一下设置让浏览器导出握手过程中的秘密信息这样 Wireshark 就可以把密文解密还原出明文。
首先你需要在 Windows 的设置里新增一个系统变量“SSLKEYLOGFILE”设置浏览器日志文件的路径如“D:\http_study\www\temp\sslkey.log”具体的设置过程就不详细说了可以在设置里搜索“系统变量”。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vRt1F7cy-1618498415311)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618420600327.png)]
设置好之后过滤器选择“tcp port 443”就可以抓到实验环境里的所有 HTTPS 数据了。 如果你觉得麻烦也没关系GitHub 上有抓好的包和相应的日志用 Wireshark 直接打开就行。
1.4、ECDHE 握手过程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-r9vI8uZB-1618498415312)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618420677147.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-prgZcKWV-1618498415313)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618420690904.png)]
在 TCP 建立连接之后浏览器会首先发一个“Client Hello”消息也就是跟服务器“打招呼”。里面有客户端的版本号、支持的密码套件还有一个随机数ClientRandom用于后续生成会话密钥。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-j8Qo9o0N-1618498415314)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618420821516.png)]
这个的意思就是“我这边有这些这些信息你看看哪些是能用的关键的随机数可得留着。”
作为“礼尚往来”服务器收到“Client Hello”后会返回一个“Server Hello”消息。把版本号对一下也给出一个随机数Server Random然后从客户端的列表里选一个作为本次通信使用的密码套件在这里它选择 了“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384”
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oPKUkGFF-1618498415315)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618420890500.png)]
这个的意思就是“版本号对上了可以加密你的密码套件挺多我选一个最合适的吧 用椭圆曲线加 RSA、AES、SHA384。我也给你一个随机数你也得留着。”
然后服务器为了证明自己的身份就把证书也发给了客户端Server Certificate。 接下来是一个关键的操作因为服务器选择了 ECDHE 算法所以它会在证书后发送“Server Key Exchange”消息里面是椭圆曲线的公钥Server Params用来实现密钥交换算法再加上自己的私钥签名认证。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QEcIHZcQ-1618498415316)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618420937023.png)]
这相当于说“刚才我选的密码套件有点复杂所以再给你个算法的参数和刚才的随机数一样有用别丢了。为了防止别人冒充我又盖了个章。”
之后是“Server Hello Done”消息服务器说“我的信息就是这些打招呼完毕。”
这样第一个消息往返就结束了两个 TCP 包结果是客户端和服务器通过明文共享了三个信息Client Random、Server Random 和 Server Params。
客户端这时也拿到了服务器的证书那这个证书是不是真实有效的呢
这就要用到第 25 讲里的知识了开始走证书链逐级验证确认证书的真实性再用证书公钥验证签名就确认了服务器的身份“刚才跟我打招呼的不是骗子可以接着往下走。”
然后客户端按照密码套件的要求也生成一个椭圆曲线的公钥Client Params用“Client Key Exchange”消息发给服务器。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Dmv3eATE-1618498415317)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618421047982.png)]
现在客户端和服务器手里都拿到了密钥交换算法的两个参数**Client Params、Server Params**就用 ECDHE 算法一阵算算出了一个新的东西叫“Pre-Master”其实也是一个随机数。 至于具体的计算原理和过程因为太复杂就不细说了但算法可以保证即使黑客截获了之前的参数也是绝对算不出这个随机数的。 现在客户端和服务器手里有了三个随机数Client Random、Server Random 和 Pre-Master。用这三个作为原始材料就可以生成用于加密会 话的主密钥叫“MasterSecret”。而黑客因为拿不到“Pre-Master”所以也就得不到主密钥。
为什么非得这么麻烦非要三个随机数呢
这就必须说 TLS 的设计者考虑得非常周到了他们不信任客户端或服务器伪随机数的可靠性为了保证真正的**“完全随机”“不可预测”**把三个不可靠的随机数混合起来那么“随机”的程度就非常高了足够让黑客难以猜测。
你一定很想知道“Master Secret”究竟是怎么算出来的吧贴一下 RFC 里的公式
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cduDSBZi-1618498415318)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618421177987.png)]
这里的“PRF”就是伪随机数函数它基于密码套件里的最后一个参数比如这次的SHA384通过摘要算法来再一次强化“Master Secret”的随机性。
主密钥有 48 字节但它也不是最终用于通信的会话密钥还会再用 PRF 扩展出更多的密钥比如客户端发送用的会话密钥client_write_key、服务器发送用的会话密钥server_write_key等等避免只用一个密钥带来的安全隐患。
有了主密钥和派生的会话密钥握手就快结束了。客户端发一个“Change Cipher Spec”然后再发一个“Finished”消息把之前所有发送的数据做个摘要再加密一下让服务器做个验证。
意思就是告诉服务器“后面都改用对称算法加密通信了啊用的就是打招呼时说的AES加密对不对还得你测一下。
服务器也是同样的操作发“Change Cipher Spec”和“Finished”消息双方都验证加密解密 OK握手正式结束后面就收发被加密的 HTTP 请求和响应了。
1.5、RSA 握手过程
如今主流的 TLS 握手过程这与传统的握手有两点不同。 第一个使用 ECDHE 实现密钥交换而不是 RSA所以会在服务器端发出“Server KeyExchange”消息。
第二个因为使用了 ECDHE客户端可以不用等到服务器发回“Finished”确认握手完毕立即就发出 HTTP 报文省去了一个消息往返的时间浪费。这个叫“TLS False Start”意思就是“抢跑”和“TCP Fast Open”有点像都是不等连接完全建立就提 前发应用数据提高传输的效率。
大体的流程没有变只是“Pre-Master”不再需要用算法生成而是客户端直接生成随机数然后用服务器的公钥加密通过“Client Key Exchange”消息发给服务器。服务器再用私钥解密这样双方也实现了共享三个随机数就可以生成主密钥。
1.6、双向认证
不过上面说的是“单向认证”握手过程只认证了服务器的身份而没有认证客户端的身份。这是因为通常单向认证通过后已经建立了安全通信用账号、密码等简单的手段就能够确认用户的真实身份。
但为了防止账号、密码被盗有的时候比如网上银行还会使用 U 盾给用户颁发客户端证书实现“双向认证”这样会更加安全。
双向认证的流程也没有太多变化只是在“Server Hello Done”之后“Client Key Exchange”之前客户端要发送“Client Certificate”消息服务器收到后也把证书链走一遍验证客户端的身份。
小结
今天我们学习了 HTTPS/TLS 的握手内容比较多、比较难不过记住下面四点就可以。
HTTPS 协议会先与服务器执行 TCP 握手然后执行 TLS 握手才能建立安全连接握手的目标是安全地交换对称密钥需要三个随机数第三个随机数“Pre-Master”必须加密传输绝对不能让黑客破解“Hello”消息交换随机数“Key Exchange”消息交换“Pre-Master”“Change Cipher Spec”之前传输的都是明文之后都是对称密钥加密的密文
课后作业
1.密码套件里的那些算法分别在握手过程中起了什么作用 2. 你能完整地描述一下 RSA 的握手过程吗 你能画出双向认证的流程图吗 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5yc82gLH-1618498415318)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618421538193.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UkHx2i87-1618498415319)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618421548220.png)]
270-TLS1.3特性解析
TLS1.2 已经是 10 年前2008 年的“老”协议了虽然历经考验但毕竟“岁月 不饶人”在安全、性能等方面已经跟不上如今的互联网了。 于是经过四年、近 30 个草案的反复打磨TLS1.3 终于在去年2018 年“粉墨登场”再次确立了信息安全领域的新标准。
TLS1.3 的三个主要改进目标兼容、安全与性能。
1.1、最大化兼容性
由于 1.1、1.2 等协议已经出现了很多年很多应用软件、中间代理官方称 为“MiddleBox”只认老的记录协议格式更新改造很困难甚至是不可行设备僵化。
在早期的试验中发现一旦变更了记录头字段里的版本号也就是由 0x303TLS1.2改为 0x304TLS1.3的话大量的代理服务器、网关都无法正确处理最终导致 TLS 握手失败。
为了保证这些被广泛部署的“老设备”能够继续使用避免新协议带来的“冲击” TLS1.3 不得不做出妥协保持现有的记录格式不变通过“伪装”来实现兼容使得 TLS1.3 看上去“像是”TLS1.2。
那么该怎么区分 1.2 和 1.3 呢 这要用到一个新的扩展协议Extension Protocol它有点“补充条款”的意思通过在记录末尾添加一系列的“扩展字段”来增加新的功能老版本的 TLS 不认识它可以直接忽 略这就实现了“后向兼容”。 在记录头的 Version 字段被兼容性“固定”的情况下只要是 TLS1.3 协议握手 的**“Hello”消息后面就必须有“supported_versions”扩展**它标记了 TLS 的版本号使用它就能区分新旧协议。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-s0UyrgRU-1618498415320)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618421750005.png)]
TLS1.3 利用扩展实现了许多重要的功能比 如“supported_groups”“key_share”“signature_algorithms”“server_name”等 这些等后面用到的时候再说。
1.2、强化安全
TLS1.2 在十来年的应用中获得了许多宝贵的经验陆续发现了很多的漏洞和加密算法的弱点所以 TLS1.3 就在协议里修补了这些不安全因素。
比如 伪随机数函数由 PRF 升级为 HKDFHMAC-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-fHFvrdof-1618498415320)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618421897072.png)]
这里还要特别说一下废除 RSA 和 DH 密钥交换算法的原因。
上一讲用 Wireshark 抓包时你一定看到了浏览器默认会使用 ECDHE 而不是 RSA 做密钥交换这是因为它不具有**“前向安全”Forward Secrecy**。
假设有这么一个很有耐心的黑客一直在长期收集混合加密系统收发的所有报文。如果加密系统使用服务器证书里的 RSA 做密钥交换一旦私钥泄露或被破解使用社会工程学或者巨型计算机那么黑客就能够使用私钥解密出之前所有报文的“Pre-Master”再算出会话密钥破解所有密文。
这就是所谓的**“今日截获明日破解”**。
而 ECDHE 算法在每次握手时都会生成一对临时的公钥和私钥每次通信的密钥对都是不同的也就是“一次一密”即使黑客花大力气破解了这一次的会话密钥也只是这次通信被攻击之前的历史消息不会受到影响仍然是安全的。 所以现在主流的服务器和浏览器在握手阶段都已经不再使用 RSA改用 ECDHE而TLS1.3 在协议里明确废除 RSA 和 DH 则在标准层面保证了“前向安全”。
1.3 提升性能
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 基本一样了。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AbBRUQ2R-1618498415321)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618422061150.png)]
1.3 握手分析
目前 Nginx 等 Web 服务器都能够很好地支持 TLS1.3但要求底层的 OpenSSL 必须是1.1.1而我们实验环境里用的 OpenSSL 是 1.1.0所以暂时无法直接测试 TLS1.3。
注意“Client Hello”里的扩展**“supported_versions”表示这是 TLS1.3“supported_groups”是支持的曲线“key_share”**是曲线对应的参数。
这就好像是说
“还是照老规矩打招呼这边有这些这些信息。但我猜你可能会升级所以再多给你一些东西也许后面用的上咱们有话尽量一口气说完。”
服务器收到“Client Hello”同样返回“Server Hello”消息还是要给出一个随机数 Server Random和选定密码套件。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tUZQzTKa-1618498415322)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618422201970.png)]
表面上看和 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 里的内 容很多还有一些特性没有谈到后面会继续讲。
为了兼容 1.1、1.2 等“老”协议TLS1.3 会“伪装”成 TLS1.2新特性在“扩展”里 实现1.1、1.2 在实践中发现了很多安全隐患所以 TLS1.3 大幅度删减了加密算法只保留了ECDHE、AES、ChaCha20、SHA-2 等极少数算法强化了安全TLS1.3 也简化了握手过程完全握手只需要一个消息往返提升了性能。
课下作业
TLS1.3 里的密码套件没有指定密钥交换算法和签名算法那么在握手的时候会不会有问 题呢结合上一讲的 RSA 握手过程解释一下为什么 RSA 密钥交换不具有“前向安全”。TLS1.3 的握手过程与 TLS1.2 的“False Start”有什么异同
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0MkkxN26-1618498415323)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618422380535.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Uq7iUeDY-1618498415324)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618422389606.png)] 280-HTTPS的优化
HTTPS 连接大致上可以划分为两个部分第一个是建立 连接时的非对称加密握手第二个是握手后的对称加密报文传输。
由于目前流行的 AES、ChaCha20 性能都很好还有硬件优化报文传输的性能损耗可以说是非常地小小到几乎可以忽略不计了。所以通常所说的“HTTPS 连接慢”指的就是刚开始建立连接的那段时间。
在 TCP 建连之后正式数据传输之前HTTPS 比 HTTP 增加了一个 TLS 握手的步骤这个步骤最长可以花费两个消息往返也就是 2-RTT。而且在握手消息的网络耗时之外还会有其他的一些“隐形”消耗比如
产生用于密钥交换的临时公私钥对ECDHE 验证证书时访问 CA 获取 CRL 或者 OCSP 非对称加密解密处理“Pre-Master”。
在最差的情况下也就是不做任何的优化措施HTTPS 建立连接可能会比 HTTP 慢上几百毫秒甚至几秒这其中既有网络耗时也有计算耗时就会让人产生“打开一个 HTTPS 网站好慢啊”的感觉。
不过刚才说的情况早就是“过去时”了现在已经有了很多行之有效的 HTTPS 优化手段运用得好可以把连接的额外耗时降低到几十毫秒甚至是“零”。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-s8pxgOyv-1618498415324)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618422564136.png)]
1.1、 硬件优化
在计算机世界里的“优化”可以分成“硬件优化”和“软件优化”两种方式先来看看有哪 些硬件的手段。
HTTPS 连接是计算密集型而不是 I/O 密集型。所以如果你花大价钱去买网卡、带宽、SSD 存储就是“南辕北辙”了起不到优化的效果。
那该用什么样的硬件来做优化呢
首先你可以选择更快的 CPU最好还内建 AES 优化这样即可以加速握手也可以加速传输。
其次你可以选择“SSL 加速卡”加解密时调用它的 API让专门的硬件来做非对称加解密分担 CPU 的计算压力。
不过“SSL 加速卡”也有一些缺点比如升级慢、支持算法有限不能灵活定制解决方案等。
所以就出现了第三种硬件加速方式“SSL 加速服务器”用专门的服务器集群来彻底“卸载”TLS 握手时的加密解密计算性能自然要比单纯的“加速卡”要强大的多。
1.2、软件优化
软件优化的方式相对来说更可行一些性价比高能够“少花钱多办事”。 软件方面的优化还可以再分成两部分一个是软件升级一个是协议优化。
软件升级实施起来比较简单就是把现在正在使用的软件尽量升级到最新版本比如把Linux 内核由 2.x 升级到 4.x把 Nginx 由 1.6 升级到 1.16把 OpenSSL 由 1.0.1 升级到1.1.0/1.1.1。
由于这些软件在更新版本的时候都会做性能优化、修复错误只要运维能够主动配合这种软件优化是最容易做的也是最容易达成优化效果的。
但对于很多大中型公司来说硬件升级或软件升级都是个棘手的问题有成千上万台各种型号的机器遍布各个机房逐一升级不仅需要大量人手而且有较高的风险可能会影响正常的线上服务。
所以在软硬件升级都不可行的情况下我们最常用的优化方式就是在现有的环境下挖掘协议自身的潜力。
1.3 协议优化
从刚才的 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”等指令配置服务器使用的密码套件 和椭圆曲线把优先使用的放在前面例如
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vBB6P12K-1618498415325)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618422851316.png)]
1.4 证书优化
除了密钥交换握手过程中的证书验证也是一个比较耗时的操作服务器需要把自己的证书链全发给客户端然后客户端接收后再逐一验证。 这里就有两个优化点一个是证书传输一个是证书验证。
服务器的证书可以选择椭圆曲线ECDSA证书而不是 RSA 证书因为 224 位的 ECC 相当于 2048 位的 RSA所以椭圆曲线证书的“个头”要比 RSA 小很多即能够节约带宽也能减少客户端的运算量可谓“一举两得”。
客户端的证书验证其实是个很复杂的操作除了要公钥解密验证多个证书签名外因为证书还有可能会被撤销失效客户端有时还会再去访问 CA下载 CRL 或者 OCSP 数据这又会产生 DNS 查询、建立连接、收发数据等一系列网络通信增加好几个 RTT。
CRLCertificate revocation list证书吊销列表由 CA 定期发布里面是所有被撤销信任的证书序号查询这个列表就可以知道证书是否有效。
但 CRL 因为是“定期”发布就有“时间窗口”的安全隐患而且随着吊销证书的增多列表会越来越大一个 CRL 经常会上 MB。想象一下每次需要预先下载几 M 的“无用数据”才能连接网站实用性实在是太低了。
所以现在 CRL 基本上不用了取而代之的是 OCSP在线证书状态协议Online Certificate Status Protocol向 CA 发送查询请求让 CA 返回证书的有效状态。
但 OCSP 也要多出一次网络请求的消耗而且还依赖于 CA 服务器如果 CA 服务器很忙那响应延迟也是等不起的。
于是又出来了一个“补丁”叫“OCSP Stapling”OCSP 装订它可以让服务器预先访问 CA 获取 OCSP 响应然后在握手时随着证书一起发给客户端免去了客户端连接 CA服务器查询的时间。
1.4 会话复用
到这里我们已经讨论了四种 HTTPS 优化手段硬件优化、软件优化、协议优化、证书优化那么还有没有其他更好的方式呢
我们再回想一下 HTTPS 建立连接的过程先是 TCP 三次握手然后是 TLS 一次握手。这后一次握手的重点是算出主密钥“Master Secret”而主密钥每次连接都要重新计算未免有点太浪费了如果能够把“辛辛苦苦”算出来的主密钥缓存一下“重用”不就可以免去了握手和计算的成本了吗
这种做法就叫“会话复用”TLS session resumption和 HTTP Cache 一样也是提高 HTTPS 性能的“大杀器”被浏览器和服务器广泛应用。
会话复用分两种第一种叫“Session ID”就是客户端和服务器首次连接后各自保存一个会话的 ID 号内存里存储主密钥和其他相关的信息。当客户端再次连接时发一个 ID 过来服务器就在内存里找找到就直接用主密钥恢复会话状态跳过证书验证和密钥交换只用一个消息往返就可以建立安全通信。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hWYO46pQ-1618498415326)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618423083004.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hDeVUnkj-1618498415327)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618423095145.png)]
通过抓包可以看到服务器在“ServerHello”消息后直接发送了“Change Cipher Spec”和“Finished”消息复用会话完成了握手。
1.4 会话票证
“Session ID”是最早出现的会话复用技术也是应用最广的但它也有缺点服务器必须保存每一个客户端的会话数据对于拥有百万、千万级别用户的网站来说存储量就成了大问题加重了服务器的负担。 于是又出现了第二种“Session Ticket”方案。
它有点类似 HTTP 的 Cookie存储的责任由服务器转移到了客户端服务器加密会话信息用“New Session Ticket”消息发给客户端让客户端保存。
重连的时候客户端使用扩展“session_ticket”发送“Ticket”而不是“Session ID” 服务器解密后验证有效期就可以恢复会话开始加密通信。
不过“Session Ticket”方案需要使用一个固定的密钥文件ticket_key来加密 Ticket为了防止密钥被破解保证“前向安全”密钥文件需要定期轮换比如设置为一小时或者一天。
1.5 预共享密钥
“False Start”“Session ID”“Session Ticket”等方式只能实现 1-RTT而 TLS1.3 更 进一步实现了**“0-RTT”原理和“Session Ticket”差不多但在发送 Ticket 的同时会 带上应用数据Early Data免去了 1.2 里的服务器确认步骤这种方式叫“Pre-** shared Key”简称为“PSK”。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mObWW2Zt-1618498415327)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618423280586.png)]
但“PSK”也不是完美的它为了追求效率而牺牲了一点安全性容易受到“重放攻 击”Replay attack的威胁。黑客可以截获“PSK”的数据像复读机那样反复向服务器发送。解决的办法是只允许安全的 GET/HEAD 方法参见第 10 讲在消息里加入时间戳、“nonce”验证或者“一次性票证”限制重放。
小结
可以有多种硬件和软件手段减少网络耗时和计算耗时让 HTTPS 变得和 HTTP 一样快最可行的是软件优化应当尽量使用 ECDHE 椭圆曲线密码套件节约带宽和计算量还能实现“False Start”服务器端应当开启“OCSP Stapling”功能避免客户端访问 CA 去验证证书会话复用的效果类似 Cache前提是客户端必须之前成功建立连接后面就可以用“Session ID”“Session Ticket”等凭据跳过密钥交换、证书验证等步骤直接开始加密通信。
课下作业 你能比较一下“Session ID”“Session Ticket”“PSK”这三种会话复用手段的异同 吗 你觉得哪些优化手段是你在实际工作中能用到的应该怎样去用 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eJIzqxV9-1618498415328)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618423348610.png)] [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Dr00u5uQ-1618498415328)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618423357164.png)] 290-迁移到HTTPS
1/迁移的必要性
如果你做移动应用开发的话那么就一定知道Apple、Android、某信等开发平台在2017 年就相继发出通知要求所有的应用必须使用 HTTPS 连接禁止不安全的 HTTP。
在台式机上主流的浏览器 Chrome、Firefox 等也早就开始“强推”HTTPS把 HTTP 站点打上“不安全”的标签给用户以“心理压力”。
Google 等搜索巨头还利用自身的“话语权”优势降低 HTTP 站点的排名而给 HTTPS更大的权重力图让网民只访问到 HTTPS 网站。
这些手段都逐渐“挤压”了纯明文 HTTP 的生存空间“迁移到 HTTPS”已经不是“要不 要做”的问题而是“要怎么做”的问题了。HTTPS 的大潮无法阻挡如果还是死守着HTTP那么无疑会被冲刷到互联网的角落里。
2、迁移的顾虑
据我观察阻碍 HTTPS 实施的因素还有一些这样、那样的顾虑我总结出了三个比较流行的观点“慢、贵、难”。
所谓**“慢”**是指惯性思维拿以前的数据来评估 HTTPS 的性能认为 HTTPS 会增加服务器的成本增加客户端的时延影响用户体验。
所谓**“贵”**主要是指证书申请和维护的成本太高网站难以承担。
所谓的**“难”**是指 HTTPS 涉及的知识点太多、太复杂有一定的技术门槛不能很快上手。
为了推广 HTTPS很多云服务厂商都提供了一键申请、价格低廉的证 书而且还出现了专门颁发免费证书的 CA其中最著名的就是“Let’s Encrypt”。
3.申请证书
要把网站从 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 客户端会自动添加这样的定期任务完全不用你操心。
4.配置HTTPS
定了证书接下来就是配置 Web 服务器在 443 端口上开启 HTTPS 服务了。 这在 Nginx 上非常简单只要在“listen”指令后面加上参数“ssl”再配上刚才的证书文件就可以实现最基本的 HTTPS。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-97voIkn4-1618498415329)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618449334322.png)]
为了提高 HTTPS 的安全系数和性能你还可以强制 Nginx 只支持 TLS1.2 以上的协议打开“Session Ticket”会话复用。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yuQaJGnb-1618498415329)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618449359504.png)]
密码套件的选择方面我给你的建议是以服务器的套件优先。这样可以避免恶意客户端故意选择较弱的套件、降低安全等级然后密码套件向 TLS1.3“看齐”只使用 ECDHE、AES和 ChaCha20支持“False Start”。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Sbnk4zzw-1618498415330)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618449383133.png)]
如果你的服务器上使用了 OpenSSL 的分支 BorringSSL那么还可以使用一个特殊的“等价密码组”Equal preference cipher groups特性它可以让服务器配置一组“等价”的密码套件在这些套件里允许客户端优先选择比如这么配置
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3nh7JVw8-1618498415331)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618449411916.png)]
如果客户端硬件没有 AES 优化服务器就会顺着客户端的意思优先选择与 AES“等价”的 ChaCha20 算法让客户端能够快一点。 全部配置完成后你可以访问“SSLLabs”网站https://www.ssllabs.com/测试网站的安全程度它会模拟多种客户端发起测试打出一个综合的评分。
5.服务器名称指示
配置 HTTPS 服务时还有一个“虚拟主机”的问题需要解决。 在 HTTP 协议里多个域名可以同时在一个 IP 地址上运行这就是“虚拟主机”Web 服务器会使用请求头里的 Host 字段参见第 9 讲来选择。
但在 HTTPS 里因为请求头只有在 TLS 握手之后才能发送在握手时就必须选择“虚拟主机”对应的证书TLS 无法得知域名的信息就只能用 IP 地址来区分。所以最早的时候每个 HTTPS 域名必须使用独立的 IP 地址非常不方便。
那么怎么解决这个问题呢
这还是得用到 TLS 的“扩展”给协议加个SNIServer Name Indication的“补充条款”。它的作用和 Host 字段差不多客户端会在“Client Hello”时带上域名信息这样服务器就可以根据名字而不是 IP 地址来选择证书。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-58sSZx3z-1618498415332)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618449625440.png)]
Nginx 很早就基于 SNI 特性支持了 HTTPS 的虚拟主机但在 OpenResty 里可还以编写Lua 脚本利用 Redis、MySQL 等数据库更灵活快速地加载证书。
6.重定向跳转
现在有了 HTTPS 服务但原来的 HTTP 站点也不能马上弃用还是会有很多网民习惯在地址栏里直接敲域名或者是旧的书签、超链接默认使用 HTTP 协议访问。
所以我们就需要用到第 18 讲里的“重定向跳转”技术了把不安全的 HTTP 网址用 301或 302“重定向”到新的 HTTPS 网站这在 Nginx 里也很容易做到使 用“return”或“rewrite”都可以。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Mhqgv6Un-1618498415332)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618449690347.png)]
但这种方式有两个问题。一个是重定向增加了网络成本多出了一次请求另一个是存在安全隐患重定向的响应可能会被“中间人”窜改实现“会话劫持”跳转到恶意网站。
不过有一种叫“HSTS”HTTP 严格传输安全HTTP Strict Transport Security的技术可以消除这种安全隐患。HTTPS 服务器需要在发出的响应头里添加一个“Strict-Transport-Security”的字段再设定一个有效期
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Pb7rZa45-1618498415333)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618449761842.png)]
这相当于告诉浏览器我这个网站必须严格使用 HTTPS 协议在半年之内182.5 天都不允许用 HTTP你以后就自己做转换吧不要再来麻烦我了。
有了“HSTS”的指示以后浏览器再访问同样的域名的时候就会自动把 URI 里 的“http”改成“https”直接访问安全的 HTTPS 网站。这样“中间人”就失去了攻击 的机会而且对于客户端来说也免去了一次跳转加快了连接速度。
如果在实验环境的配置文件里用“add_header”指令添加“HSTS”字段
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NF0hcp4O-1618498415334)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618449822810.png)]
那么 Chrome 浏览器只会在第一次连接时使用 HTTP 协议之后就会都走 HTTPS 协议。
小结
今天我介绍了一些 HTTPS 迁移的技术要点掌握了它们你就可以搭建出一个完整的HTTPS 站点了。 但想要实现大型网站的“全站 HTTPS”还是需要有很多的细枝末节的工作要做比如使用CSPContent Security Policy的各种指令和标签来配置安全策略使用反向代理来集中“卸载”SSL话题太大以后有机会再细谈吧。 从 HTTP 迁移到 HTTPS 是“大势所趋”能做就应该尽早做 升级 HTTPS 首先要申请数字证书可以选择免费好用的“Let’s Encrypt” 配置 HTTPS 时需要注意选择恰当的 TLS 版本和密码套件强化安全 原有的 HTTP 站点可以保留作为过渡使用 301 重定向到 HTTPS。 课下作业 结合你的实际工作分析一下迁移 HTTPS 的难点有哪些应该如何克服 参考上一讲你觉得配置 HTTPS 时还应该加上哪些部分
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zgIzKUL4-1618498415334)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618450394347.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NknMx1dk-1618498415335)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1618450406549.png)]
浏览器我这个网站必须严格使用 HTTPS 协议在半年之内182.5 天都不允许用 HTTP你以后就自己做转换吧不要再来麻烦我了。
有了“HSTS”的指示以后浏览器再访问同样的域名的时候就会自动把 URI 里 的“http”改成“https”直接访问安全的 HTTPS 网站。这样“中间人”就失去了攻击 的机会而且对于客户端来说也免去了一次跳转加快了连接速度。
如果在实验环境的配置文件里用“add_header”指令添加“HSTS”字段
[外链图片转存中…(img-NF0hcp4O-1618498415334)]
那么 Chrome 浏览器只会在第一次连接时使用 HTTP 协议之后就会都走 HTTPS 协议。
小结
今天我介绍了一些 HTTPS 迁移的技术要点掌握了它们你就可以搭建出一个完整的HTTPS 站点了。 但想要实现大型网站的“全站 HTTPS”还是需要有很多的细枝末节的工作要做比如使用CSPContent Security Policy的各种指令和标签来配置安全策略使用反向代理来集中“卸载”SSL话题太大以后有机会再细谈吧。 从 HTTP 迁移到 HTTPS 是“大势所趋”能做就应该尽早做 升级 HTTPS 首先要申请数字证书可以选择免费好用的“Let’s Encrypt” 配置 HTTPS 时需要注意选择恰当的 TLS 版本和密码套件强化安全 原有的 HTTP 站点可以保留作为过渡使用 301 重定向到 HTTPS。 课下作业 结合你的实际工作分析一下迁移 HTTPS 的难点有哪些应该如何克服 参考上一讲你觉得配置 HTTPS 时还应该加上哪些部分
[外链图片转存中…(img-zgIzKUL4-1618498415334)]
[外链图片转存中…(img-NknMx1dk-1618498415335)]
