透视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 协议上，安全开车。

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

浏览器与服务器在使用 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 字节的二进制串。

加密算法通常有两大类：对称加密和非对称加密。

对称加密

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

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

AES 的意思是“高级加密标准”(Advanced Encryption Standard)，密钥长度可以是 128、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)”。

   

   哈希消息认证码(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 实现安全，而安全我们又接触了什么是对称加密与非对称加密，非对称加密性能较弱，所以我们使用非对称加密来加密对称加密的“会话密钥”，利用会话密钥加密明文解决了性能问题。

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