透视HTTPS建造固若金汤的城堡

公众号：码哥字节，转载请联系公众号

为何有 HTTPS？由于 HTTP 不安全！ 如今的互联网已经再也不是 “田园时代”，“黑暗森林” 已经到来。上网的记录会被轻易截获，网站是否真实也没法验证，黑客能够假装成银行网站，盗取真实姓名、密码、银行卡等敏感信息，威胁人身安全和财产安全。

上网的时候必须步步为营、到处当心，不然就会被不知道埋伏在哪里的黑客所“猎杀”。

HTTPS 如何实现安全通讯？如何构建出固若金汤的网络城堡？主要涉及的知识点以下：

• 了解什么是 HTTPS
• 什么样的才是安全的通讯
• 对称加密与非对称加密、摘要算法、数字签名、完整性校验究竟是什么
• 迁移 HTTPS 的必要性

什么是安全

作事要稳，老司机【码哥字节】开车要安全！无论是戴杜蕾斯仍是安全气囊，“安全相当重要”！

在通讯过程当中，具有如下特性则认为安全：机密性、完整性、不能否认、身份认证

机密性

数据必须保密，只能有信任的人读取，其余人是不可见的秘密。诸葛亮的密报总不能让司马懿知道呀，否则还玩个蛋。通俗的说：就是不能让不相关的人看到不应看的东西。

完整性

也叫做一致性，也就是数据在传输过程当中没有被非法篡改，内容不能多也不能少，一五一十的保持原状。

打个比方，本来张无忌说：“赵敏，么么哒。”，传信的飞鸽被周芷若抓到了，截取了消息，改为了 “赵敏，去死吧！”。这么子搞，倚天屠龙记可能就会被改写了。

不能否认

也就作不可抵赖，不可否认已经发生过的事情。所谓 “君子一言，驷马难追”。“老懒” 这种事情不能发生。

就像尹志平亲密接触了小龙女，过后一直隐瞒否定，装做不知道，这是万万不可的。因此最终就嗝屁了。

身份验证

也就是确认对方的真实身份，“证实你是真的是你”，保证消息发送到可信的人，而不是非法之徒。

好比令狐冲写了一份情书给任盈盈：“盈盈，冲哥哥爱你哟”，可是岳不群看到快递小哥，冒充是令狐冲，截取了情书后回复：“傻逼，白日作梦”。令狐冲不知道这是岳不群的回复，觉得是任盈盈的，笑傲江湖又要重写了……

因此同时具有了机密性、完整性、身份认证、不可够人四个特性，通讯双方的安全才有保证，才是真正的安全。

什么是 HTTPS

到这里，终于轮到 HTTPS 上台了，也就是它为 HTTP 增长了刚刚说的四大安全特性。

HTTPS 实际上是一个“很是简单”的协议，规定了新的协议名“https”，默认端口号 443，至于其余的什么请求 - 应答模式、报文结构、请求方法、URI、头字段、链接管理等等都彻底沿用 HTTP，没有任何新的东西。惟一的差异就是端口号不一样、去掉明文传输。

那 HTTPS 凭啥就变得安全了呢？

就是由于他在 TCP/IP 与 HTTP 之间加上了 SSL/TLS ，从原来的 HTTP over TCP/IP 变成了 HTTP over SSL/TLS，让 HTTP 运行在 安全的 SSL/TLS 协议上，安全开车。

因此重点就是去掌握 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 由记录协议、握手协议、警告协议、变动密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。

浏览器与服务器在使用 TLS 创建链接的时候实际上就是选了一组加密算法实现安全通讯，这些算法组合叫作 “密码套件（cipher suite）”。

套件命名颇有规律，好比“ECDHE-RSA-AES256-GCM-SHA384”。按照 密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法”组成的.

因此这个套件的意思就是：使用 ECDHE 算法进行密钥交换，使用 RSA 签名和身份验证，握手后使用 AES 对称加密，密钥长度 256 位，分组模式 GCM，消息认证和随机数生成使用摘要算法 SHA384。

对称加密与非对称加密

前面提到四个实现安全的必要条件，先说 机密性，也就是消息只能给想给的人看到而且看得懂。

实现机密性的手段就是 加密（encrypt），也就是将本来明文消息使用加密算法转换成别人看不懂的密文，只有掌握特有的 密钥 的人才能解密出原始内容。就好像是诸葛亮将发给关二爷密报的内容经过一种转换算法转成其余的内容，司马懿看不懂。关二爷持有解密该内容的关键钥匙。

钥匙也就是 密钥（key），未加密的消息叫作 明文 （plain text/clear text），加密后的内容叫作 密文（cipher text），经过密钥解密出原文的过程叫作 解密（decrypt），而加解密的整个过程就是 加密算法。

因为 HTTPS、TLS 都运行在计算机上，因此“密钥”就是一长串的数字，但约定俗成的度量单位是“位”（bit），而不是“字节”（byte）。好比，说密钥长度是 128，就是 16 字节的二进制串，密钥长度 1024，就是 128 字节的二进制串。

加密算法一般有两大类：对称加密和非对称加密。

对称加密

加密和解密使用的密钥都是同一个，是 “对称的”。双方只要保证不会有泄露其余人知道这个密钥，通讯就具备机密性。

对称加密算法常见的有 RC四、DES、3DES、AES、ChaCha20 等，但前三种算法都被认为是不安全的，一般都禁止使用，目前经常使用的只有 AES 和 ChaCha20。

AES 的意思是“高级加密标准”（Advanced Encryption Standard），密钥长度能够是 12八、192 或 256。它是 DES 算法的替代者，安全强度很高，性能也很好，并且有的硬件还会作特殊优化，因此很是流行，是应用最普遍的对称加密算法。

加密分组模式

对称算法还有一个 “分组模式”的概念，目的是经过算法用固定长度的密钥加密任意长度的明文。

最新的分组模式被称为 AEAD（Authenticated Encryption with Associated Data），在加密的同时增长了认证的功能，经常使用的是 GCM、CCM 和 Poly1305。

非对称加密

有对称加密，为什么还搞出一个非对称加密呢？

对称加密确实解决了机密性，只有相关的人才能读取出信息。可是最大的问题是：如何安全的把密钥传递对方，专业术语 “密钥交换”。

这个很容易理解，对称加密的密钥在飞鸽传书过程当中被打鸟的敌军捕获窃取，那么就能随意加解密收发做战密报数据了，诸葛亮的密报没有机密可言。

因此非对称加密诞生了。

由两个密钥组成，分别是 公钥（public key） 和 “私钥（private key）”，两个密钥是不同的，这也就是不对称的由来，公钥能够任何人使用，私钥则本身保密。

这里须要注意的是：公钥和私钥均可以用来加密解密，公钥加密的密文只能用私钥解密，反之亦然。

服务端保存私钥，在互联网上分发公钥，当访问服务器网站的时候使用授予的公钥加密明文便可，服务端则使用对应的私钥来解密。敌军没有私钥也就没法破解密文了。

TLS 中常见的加密算法有 DH、RSA、ECC、DSA 等。其中的 RSA 最经常使用，它的安全性基于“整数分解”的数学难题，使用两个超大素数的乘积做为生成密钥的材料，想要从公钥推算出私钥是很是困难的。

ECC（Elliptic Curve Cryptography）是非对称加密里的“后起之秀”，它基于“椭圆曲线离散对数”的数学难题，使用特定的曲线方程和基点生成公钥和私钥，子算法 ECDHE 用于密钥交换，ECDSA 用于数字签名。

比起 RSA，ECC 在安全强度和性能上都有明显的优点。160 位的 ECC 至关于 1024 位的 RSA，而 224 位的 ECC 则至关于 2048 位的 RSA。由于密钥短，因此相应的计算量、消耗的内存和带宽也就少，加密解密的性能就上去了，对于如今的移动互联网很是有吸引力。

如今咱们为了机密性从对称加密到非对称加密，而非对称加密还解决了密钥交换不安全的问题。那么是否能够直接使用非对称加密来实现机密性呢？

答案是否认的！

由于非对称加密运算速度比较慢。因此须要二者结合，混合模式实现机密性问题，同时又有很好的性能。

加密流程以下所示：

1. 先建立一个随机数的对称加密密钥，会话密钥（session key）；
2. 使用会话密钥加密须要传输的明文消息，由于对称加密性能较好，接着再使用非对称加密的公钥对会话密钥加密，由于会话密钥很短，一般只有 16 字节或 32 字节，因此加密也不会太慢。这里主要就是解决了非对称加密的性能问题，同时实现了会话密钥的机密交换。
3. 另外一方接收到密文后使用非对称加密的私钥解密出上一步加密的 会话密钥，接着使用会话密钥解密出加密的消息明文。

总结一下就是使用非对称加密算法来加密会话密钥，使用对称加密算法来加密消息明文，接收方则使用非对称加密算法的私钥解密出会话密钥，再利用会话密钥解密消息密文。

这样混合加密就解决了对称加密算法的密钥交换问题，并且安全和性能兼顾，完美地实现了机密性。

后面还有完整性、身份认证、不能否认等特性没有实现，因此如今的通讯还不是绝对安全。

摘要算法与完整性

摘要算法的主要目的就是实现完整性，经过常见的散列函数、哈希函数实现。

咱们能够简单理解成这事一种特殊的压缩算法，将任意长度的明文数据处理成固定长度、又是独一无二的“摘要”字符串，就是该数据的指纹。

同时摘要算法是单向加密算法，没有密钥，加密后的数据也没法解密，也就是不能从“摘要”推导出明文。

好比咱们听过或者用过的 MD5（Message-Digest 5）、SHA-1（Secure Hash Algorithm 1），它们就是最经常使用的两个摘要算法，可以生成 16 字节和 20 字节长度的数字摘要。

完整性实现

有了摘要算法生成的数字摘要，那么咱们只须要在明文数据附上对应的摘要，就能保证数据的完整性。

可是因为摘要算法不具备机密性，不能明文传输，不然黑客能够修改消息后把摘要也一块儿改了，网站仍是鉴别不出完整性。

因此完整性仍是要创建在机密性上，咱们结合以前提到的混合加密使用 ”会话密钥“ 加密明文消息 + 摘要，这样的话黑客也就没法获得明文，没法作修改了。这里有个专业术语叫“哈希消息认证码（HMAC）”。

好比诸葛亮使用上面提到的混合加密过程给关二爷发消息：“明天攻城” + “SHA-2 摘要”，关二爷收到后使用密钥将解密出来的会话密钥解密出明文消息，同时对明文消息使用解密出来的摘要算法进行摘要计算，接着比对两份“摘要”字符串是否一致，若是一致就说明消息完整可信，没有被敌军修改过。

消息被修改是很危险的，要以史为鉴，好比赵高与李斯伪造遗诏，直接把扶苏给送西天了，这太可怕了。

总结下就是经过摘要比对防止篡改，同时利用混合加密实现密文与摘要的安全传输。

数字签名和 CA

到这里已经很安全了，可是仍是有漏洞，就是通讯的两头。黑客能够假装成网站来窃取信息。而反过来，他也能够假装成你，向网站发送支付、转帐等消息，网站没有办法确认你的身份，钱可能就这么被偷走了。

如今如何实现身份认证呢？

现实生活中，解决身份认证的手段是签名和印章，只要在纸上写下签名或者盖个章，就可以证实这份文件确实是由本人而不是其余人发出的。

非对称加密依然能够解决此问题，只不过跟以前反过来用，使用私钥再加上摘要算法，就可以实现“数字签名”，同时实现“身份认证”和“不能否认”。

就是把公钥私钥的用法反过来，以前是公钥加密、私钥解密，如今是私钥加密、公钥解密。但又由于非对称加密效率过低，因此私钥只加密原文的摘要，这样运算量就小的多，并且获得的数字签名也很小，方便保管和传输。

重点就是使用非对称加密的“私钥”加密原文的摘要，对方则使用非对称加密的公钥解密出摘要，再比对解密出的原文经过摘要算法计算摘要与解密出的摘要比对是否一致。这样就能像签署文件同样证实消息确实是你发送的。

只要你和网站互相交换公钥，就能够用“签名”和“验签”来确认消息的真实性，由于私钥保密，黑客不能伪造签名，就可以保证通讯双方的身份。

CA

到这里彷佛已经大功告成，惋惜还不是。

综合使用对称加密、非对称加密和摘要算法，咱们已经实现了安全的四大特性，是否是已经完美了呢？

不是的，这里还有一个“公钥的信任”问题。由于谁均可以发布公钥，咱们还缺乏防止黑客伪造公钥的手段，也就是说，怎么来判断这个公钥就是你或者张三丰的公钥呢？

这个“第三方”就是咱们常说的CA（Certificate Authority，证书认证机构）。它就像网络世界里的公安局、教育部、公证中心，具备极高的可信度，由它来给各个公钥签名，用自身的信誉来保证公钥没法伪造，是可信的。

CA 对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证实公钥关联的各类信息，造成“数字证书”（Certificate）。

OpenSSL

它是一个著名的开源密码学程序库和工具包，几乎支持全部公开的加密算法和协议，已经成为了事实上的标准，许多应用软件都会使用它做为底层库来实现 TLS 功能，包括经常使用的 Web 服务器 Apache、Nginx 等。

因为 OpenSSL 是开源的，因此它还有一些代码分支，好比 Google 的 BoringSSL、OpenBSD 的 LibreSSL，这些分支在 OpenSSL 的基础上删除了一些老旧代码，也增长了一些新特性，虽然背后有“大金主”，但离取代 OpenSSL 还差得很远。

总结下就是：OpenSSL 是著名的开源密码学工具包，是 SSL/TLS 的具体实现。

迁移 HTTPS 必要性

若是你作移动应用开发的话，那么就必定知道，Apple、Android、某信等开发平台在 2017 年就相继发出通知，要求全部的应用必须使用 HTTPS 链接，禁止不安全的 HTTP。

在台式机上，主流的浏览器 Chrome、Firefox 等也早就开始“强推”HTTPS，把 HTTP 站点打上“不安全”的标签，给用户以“心理压力”。

Google 等搜索巨头还利用自身的“话语权”优点，下降 HTTP 站点的排名，而给 HTTPS 更大的权重，力图让网民只访问到 HTTPS 网站。

这些手段都逐渐“挤压”了纯明文 HTTP 的生存空间，“迁移到 HTTPS”已经不是“要不要作”的问题，而是“要怎么作”的问题了。HTTPS 的大潮没法阻挡，若是仍是死守着 HTTP，那么无疑会被冲刷到互联网的角落里。

顾虑

阻碍 HTTPS 实施的因素还有一些这样、那样的顾虑，我总结出了三个比较流行的观点：“慢、贵、难”。

而“慢”则是惯性思惟，拿之前的数据来评估 HTTPS 的性能，认为 HTTPS 会增长服务器的成本，增长客户端的时延，影响用户体验。

其实如今服务器和客户端的运算能力都已经有了很大的提高，性能方面彻底没有担忧的必要，并且还能够应用不少的优化解决方案

所谓“贵”，主要是指证书申请和维护的成本过高，网站难以承担。

这也属于惯性思惟，在早几年的确是个问题，向 CA 申请证书的过程不只麻烦，并且价格昂贵，每一年要交几千甚至几万元。

但如今就不同了，为了推广 HTTPS，不少云服务厂商都提供了一键申请、价格低廉的证书，并且还出现了专门颁发免费证书的 CA，其中最著名的就是“Let’s Encrypt”。

所谓的“难”，是指 HTTPS 涉及的知识点太多、太复杂，有必定的技术门槛，不能很快上手。

总结

从什么是安全咱们延展出 HTTPS，解释了什么是 HTTPS，以及与 HTTP 的区别。HTTPS 主要就是经过 SSL/TLS 实现安全，而安全咱们又接触了什么是对称加密与非对称加密，非对称加密性能较弱，因此咱们使用非对称加密来加密对称加密的“会话密钥”，利用会话密钥加密明文解决了性能问题。

经过混合加密实现了机密性，利用摘要算法实现了完整性，经过数字签名使用非对称加密的“私钥”加密原文的摘要，对方则使用非对称加密的公钥解密出摘要，再比对解密出的原文经过摘要算法计算摘要与解密出的摘要比对是否一致实现了身份认证与不能否认。

若是以为阅读后对你有帮助，但愿多多分享、点赞与在看素质三连不作白嫖者。

关注 【码哥字节】解锁更多硬核。

推荐阅读

如下几篇文章阅读量与读者反馈都很好，推荐你们阅读：

• RESTful 最佳实践
• Tomcat 架构原理解析到架构设计借鉴
• Tomcat 高并发之道原理拆解与性能调优
• 数据库系统设计概述

公众号后台回复 ”加群“，加入读者技术群，里面有阿里、腾讯的小伙伴一块儿探讨技术。

参考内容

[透视 HTTP 协议]