HTTPS 概念

HTTPS 就是一个有安全保障的 HTTP 通信，我们都知道，http 是明文传输的，http 报文是人肉眼就可识别的 ASCII 码，在通信过程中，http 报文很容易被黑客窃听、篡改、伪造，而在互联网交易中，我们必须保证通信安全，所以就需要像 https 这样有安全层的协议。

那么，https是怎么保障通信安全的呢？什么样的通信可以被称为是安全的，安全的定义是什么？

通常，如果通信过程具备了四个特性，就可以认为是“安全”的，这四个特性是：机密性、完整性，身份认证和不可否认。而HTTPS正是实现了这四个特性，所以被认为是“安全的”。

HTTPS 和 HTTP 的区别：

• http 是超文本传输协议，信息是明文传输，https 则是具有安全性的加密传输协议

• http 基于 tcp 协议，tcp 三次握手之后即可开始 http 通信；https 是在 http 与 tcp 之间加了一个 SSL/TLS 安全层，在 tcp 握手之后，还要进行 TLS 握手，才可以开始通信。

• http 没有身份认证，存在安全隐患；https 使用证书系统来进行身份认证，使用 https 的网站需要到 CA 申请证书，一般免费证书较少，因而需要一定费用。

• http 默认端口是 80，https默认端口 443

HTTPS的基本概念：

SSL：安全套接层，在 OSI 模型中处于第 5 层（会话层）；TLS：1999年，SSL被改名为TLS（传输层安全），正式标准化，所以 TLS1.0 实际上就是 SSLv3.1，目前应用的最广泛的 TLS 是 1.2。

TLS 综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。

浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为“密码套件”。

TLS 的密码套件命名：密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法。

如：ECDHE-RSA-AES256-GCM-SHA38

含义：握手时使用 ECDHE 算法进行密钥交换，用 RSA 签名和身份认证，握手后的通信使用AES 对称算法，密钥长度 256 位，分组模式是 GCM，摘要算法 SHA384 用于消息认证和产生随机数

机密性实现机制

前置知识

为什么要有机密性？

因为 http 是明文传输的，明文的意思就是头部字段等信息直接使用 ASCII 码这种人能看懂的符号传递，很容易被劫取和篡改。当我们使用 http 进行金钱方面的交易时，是毫无安全性可言的。

实现机密性最常用的手段是“加密”，就是把消息用某种方式转换成谁也看不懂的乱码，只有掌握特殊“钥匙”的人才能再转换出原始文本。

这里的“钥匙”就叫做“密钥”，加密前的消息叫“明文”，加密后的乱码叫“密文”，使用密钥还原明文的过程叫“解密”，是加密的反操作，加密解密的操作过程就是“加密算法”。

按照密钥的使用方式，加密可以分为两大类：对称加密和非对称加密。

对称加密

对称加密：加密和解密时使用的密钥都是同一个，是“对称”的。只要保证了密钥的安全，那整个通信过程就可以说具有了机密性。

举个例子，你想要登录某网站，只要事先和它约定好使用一个对称密码，通信过程中传输的全是用密钥加密后的密文，只有你和网站才能解密。黑客即使能够窃听，看到的也只是乱码，因为没有密钥无法解出明文，所以就实现了机密性。

目前最常用的加密算法是 AES（高级加密标准），密钥长度可以是128、192 或 256。

对称算法还有一个“分组模式”的概念，它可以让算法用固定长度的密钥加密任意长度的明文，把小秘密（即密钥）转化为大秘密（即密文），常用的是 GCM、CCM 和Poly1305。

把上面这些组合起来，就可以得到 TLS 密码套件中定义的对称加密算法。比如，AES128-GCM，意思是密钥长度为 128 位的 AES 算法，使用的分组模式是 GCM；ChaCha20-Poly1305 意思是ChaCha20 算法，使用的分组模式是 Poly1305。

非对称加密

对称加密有一个缺点，就是无法解决“密钥交换”问题，因为在对称加密算法中只要持有密钥就可以解密。如果你和网站约定的密钥在传递途中被黑客窃取，那他就可以在之后随意解密收发的数据，通信过程也就没有机密性可言了。

所以，就出现了非对称加密，也叫公钥加密算法。它有两个密钥，一个叫“公钥”（public key），一个叫“私钥”（private key）。两个密钥是不同的，“不对称”，公钥可以公开给任何人使用，而私钥必须严格保密。

公钥和私钥有个特别的“单向”性，虽然都可以用来加密解密，但公钥加密后只能用私钥解密，反过来，私钥加密后也只能用公钥解密。非对称加密可以解决“密钥交换”的问题。网站秘密保管私钥，在网上任意分发公钥，你想要登录网站只要用公钥加密就行了，密文只能由私钥持有者才能解密。而黑客因为没有私钥，所以就无法破解密文。

RSA是最著名的非对称加密算法，它的安全性基于“整数分解”的数学难题，使用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是非常困难的。

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

HTTPS的加密方式

混合加密

非对称加密虽然没有“密钥交换”问题，但因为它们都是基于复杂的数学难题，运算速度很慢，比对称加密算法差了好几个数量级。如果仅用非对称加密，虽然保证了安全，但通信速度有如乌龟蜗牛，实用性就变成了零。

所以，TLS里使用了”混合加密“方式：

• 在通信刚开始的时候使用非对称加密算法，比如 RSA、ECDHE，首先解决密钥交换的问题；【用随机数产生对称加密算法使用的“会话密钥”（session key），再用公钥加密。因为会话密钥很短，通常只有 16 字节或 32 字节，所以慢一点也无所谓。对方拿到密文后用私钥解密，取出会话密钥。这样，双方就实现了对称密钥的安全交换。】
• 后续全都使用对称加密进行通信。

完整性实现机制

完整性用来保证通信数据没有被篡改过。

为什么需要完整性？因为黑客虽然拿不到会话密钥，无法破解密文，但可以通过窃听收集到足够多的密文，再尝试着修改、重组后发给网站。如果没有完整性保证，服务器只能“照单全收”，然后他就可以通过服务器的响应获取进一步的线索，最终就会破解出明文。

摘要

实现完整性的手段主要是 摘要算法，也就是常说的散列函数、哈希函数。

可以把摘要算法近似地理解成一种特殊的压缩算法，它能够把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”。也可以把摘要算法理解成特殊的“单向”加密算法，它只有算法，没有密钥，加密后的数据无法解密，不能从摘要逆推出原文。

最常用的摘要算法有 MD5、SHA-1，它们能够生成 16 字节和 20 字节长度的数字摘要。但这两个算法的安全强度比较低，不够安全，在 TLS 里已经被禁止使用了。

目前 TLS 推荐使用的是 SHA-1 的后继者：SHA-2，SHA-2 实际上是一系列摘要算法的统称，总共有 6 种，常用的有 SHA224、SHA256、SHA384，分别能够生成 28 字节、32 字节、48 字节的摘要

摘要算法保证了“数字摘要”和原文是完全等价的。所以，我们只要在原文后附上它的摘要，就能够保证数据的完整性。

比如，你发了条消息：“转账 1000 元”，然后再加上一个 SHA-2 的摘要。网站收到后也计算一下消息的摘要，把这两份“指纹”做个对比，如果一致，就说明消息是完整可信的，没有被修改。如果黑客在中间哪怕改动了一个标点符号，摘要也会完全不同，网站计算比对就会发现消息被窜改，是不可信的。

身份认证和不可否认

数字签名

数字签名就是经过私钥加密后的摘要。

为什么要对摘要使用私钥加密？

• 因为黑客可以在修改数据内容的同时把摘要也修改掉，这样摘要就起不到任何作用了，所以要对摘要进行加密，防止被同时替换内容和摘要
• 使用私钥加密，公钥解密的好处：无法被伪造。因为私钥保密，中间人没有私钥，就算窃取了数字签名，对签名进行修改，这时用公钥就解不开签名了，客户端也就发现消息被篡改了。

数字证书

还有一个问题，就是黑客冒充某网站给客户端一个假的公钥，如果你拿到了假的公钥，混合加密就完全失效了。所以，为了解决公钥的信任问题，需要引入“数字证书”。

数字证书就是可信任的权威机构（CA）颁发的服务器相关信息和其公钥。服务器通过向客户端提供证书来证明自己确实是某某网站。CA的公钥是公开的，客户端拿到证书后用CA公钥解开就可以拿到服务器公钥了。

操作系统和浏览器都内置了各大 CA 的根证书，上网的时候只要服务器发过来它的证书，就可以验证证书里的签名，顺着证书链一层层地验证，直到找到根证书，就能够确定证书是可信的，从而里面的公钥也是可信的

通信过程中，

服务器需提供：

• 数据内容（会话密钥加密）
• 数字签名（服务器私钥加密后的摘要）
• 数字证书（CA私钥加密的服务器公钥）

客户端收到后：

• 先用CA公钥解密证书，把服务器公钥拿出来
• 使用服务器公钥解密数字签名，得到摘要
• 使用摘要算法对内容进行计算，算出的摘要与刚才解密出的摘要进行对比，如果一模一样，说明数据是完整的，没被篡改的

身份认证：使用CA颁发的数字证书来证明这个公钥确实是某某服务器的公钥。

不可否认：如果能用某某服务器的公钥解开数字签名，就说明这个消息只能是某某服务器发出的，不可能是别人冒充的，因为只有配对的公钥能解开唯一的私钥加密过的文件。

TLS 握手过程

在 http 协议中，TCP三次握手成功后，浏览器会立即发送请求报文；但是https协议，它还需要另一个握手过程（TLS握手），在TCP上建立安全连接，之后才是收发报文。TLS握手的主要目的是使用非对称加密交换对称密钥，这个对称密钥是由三个随机数生成的。

TLS握手一共4个回合：

1.客户端发出请求

• 支持的协议版本，比如TLS 1.0版
• 一个客户端生成的随机数，稍后用于生成"会话密钥"
• 支持的密码套件（支持的加密方法）

2.服务器回应

• 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
• 一个服务器生成的随机数，稍后用于生成"会话密钥"
• 确认使用的加密方法，比如RSA公钥加密
• 服务器证书

3.客户端回应

客户端收到服务器回应以后，开始走证书链逐级验证，确认证书的真实性，如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信：

如果证书真实有效，从证书中拿出服务器公钥，向服务器发送下面三项信息：

• 一个用服务器公钥加密随机数（pre-master key），防止被窃听
• 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送（Change Cipher Spec）
• 客户端握手结束通知（Finished），表示客户端的握手阶段已经结束。这一项是把之前所有发送的数据做个摘要（hash值），再加密一下，供服务器校验

上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。

4.服务器的最后回应

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。

然后，向客户端最后发送下面信息：

• 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送（Change Cipher Spec）
• 服务端握手结束通知（Finished），表示服务端的握手阶段已经结束。这一项是把之前所有发送的数据做个摘要（hash值），再加密一下，供客户端校验

TLS握手结束后，双方开始使用对称会话密钥进行加密通信。

HTTPS的优缺点

优点

• 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

• HTTPS 协议是由 SSL/TLS+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 http 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。

• HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

• 谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等 HTTP 网站，采用 HTTPS 加密的网站在搜索结果中的排名将会更高”。

缺点

• HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近 50%，增加 10% 到 20% 的耗电；

• HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗

• SSL 证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

• HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

参考文献

极客时间：透视TTP协议

SSL/TLS协议运行机制的概述