javascript - 网络协议系列 — 进阶Https基础 - 个人文章

前言

这篇文章实话说我有点虚，因为平时都不怎么研究这一块的，然后涉及到的知识点超多，我只能到处看看资料总结一下相关信息，所以在此我只想说句：
本文章内容只代表个人立场，有错必改！
原本打算一次性总结，后来越扯越多超过字数限制了，就干脆做成http系列文章了，不定时更新原有内容(发现哪里出错的话)，不定时新增系列文章，请见谅!

因为之前写得太臃肿又不够详细，最近刚好复习到这一块的内容，所以决定把这些文章都拆分成更加细致一点，补充详细内容，优化排版布局，目前来看还是应该的，因为自身时间问题和平台编译的问题迟迟未改，只好等都改完之后才发出来。

网络协议系列 — TCP、UDP、SOCKET与参考模型

网络协议系列 — http协议原理构成

网络协议系列 — http1.x、http2.0与连接管理

网络协议系列 — cookie，Session，本地缓存

网络协议系列 — 强缓存与协商缓存机制

网络协议系列 — 特殊字符编码, 转发程序与常见问题简答

网络协议系列 — 进阶Https基础

网络协议系列 — WebSocket协议入门基础

什么是HTTPS协议？(来自百度百科)

HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer)，是以安全为目标的HTTP通道，简单讲是HTTP的安全版。HTTPS的安全基础是SSL，它是一个URI scheme(抽象标识符体系)，句法类同http体系，用于安全的HTTP数据传输。https表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层(在HTTP与TCP之间)。这个系统提供了身份验证与加密通讯方法。现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。主要作用:

建立一个信息安全通道，来保证数据传输的安全
确认网站的真实性，凡是使用了 https 的网站，都可以通过点击浏览器地址栏的锁头标志来查看网站认证之后的真实信息，也可以通过CA机构颁发的安全签章来查询

HTTP和HTTPS的区别

HTTP协议以明文方式发送内容，不提供任何方式的数据加密，因此HTTP协议不适合传输一些敏感信息，比如信用卡号、密码等。
HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

https协议需要到CA申请证书，一般免费证书很少，需要交费；
https协议可以通过CA机构颁发的安全签章或点击浏览器地址栏的锁头标志来查看网站认证之后的真实信息；
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议；
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443；
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全；

(懒，直接百度图片的拿来用的。。)
(更多内容请自行查阅，本节到此为止了。)

Http隐患

在HTTP协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应(但也仅于发送端的IP地址和端口号没有被 Web服务器设定限制访问的前提下)。

存在隐患:

无法确定请求发送至目标的 Web服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的Web 服务器。
无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
无法确定正在通信的对方是否具备访问权限。因为某些 Web服务器上保存着重要的信息，只想发给特定用户通信的权限。
无法判定请求是来自何方、出自谁手。
哪佳是无意义的请求也会照单全收。无法阻止海量请求下的DoS攻击（Denial of Service，拒绝服务攻击)。

虽然使用HTTP协议无法确定通信方，但如果使用SSL则可以。SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定通信方.下面会说到.

SSL(Secure Sockets Layer) && TLS(Transport Layer Security)

SSL是一种在传输层对网络连接进行加密为网络通信提供安全及数据完整性的安全协议，TLS是SSL的升级版。
SSL协议可分为两层：

SSL记录协议(SSL Record Protocol)：它建立在可靠的传输协议(如TCP)之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
SSL握手协议(SSL Handshake Protocol)：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

SSL协议提供的服务主要有:

认证用户和服务器，确保数据发送到正确的客户机和服务器
加密数据以防止数据中途被窃取
维护数据的完整性，确保数据在传输过程中不被改变。

SSL协议的工作流程:

服务器认证阶段：

客户端向服务器发送一个开始请求以便开始一个新的会话连接；
服务器根据客户端的请求确定是否需要生成新的主密钥，如需要则服务器在响应客户端请求时将包含生成主密钥所需的信息；
客户端根据收到的服务器响应信息，产生一个主密钥，并用服务器的公开密钥加密后传给服务器；
服务器取回该主密钥，并返回给客户端一个用主密钥认证的信息，以此让客户端认证服务器。

用户认证阶段

在此之前，服务器已经通过了客户端认证，这一阶段主要完成对客户端的认证。经认证的服务器发送一个请求给客户端，客户端则返回(数字)签名后的请求和其公开密钥，从而向服务器提供认证。

从SSL协议所提供的服务及其工作流程可以看出，SSL协议运行的基础是商家对消费者信息保密的承诺，这就有利于商家而不利于消费者。在电子商务初级阶段，由于运作电子商务的企业大多是信誉较高的大公司，因此这问题还没有充分暴露出来。但随著电子商务的发展，各中小型公司也参与进来，这样在电子支付过程中的单一认证问题就越来越突出。虽然在SSL3.0中通过数字签名和数字证书可实现浏览器和Web服务器双方的身份验证，但是SSL协议仍存在一些问题，比如，只能提供交易中客户与服务器间的双方认证，在涉及多方的电子交易中，SSL协议并不能协调各方间的安全传输和信任关系。在这种情况下，Visa和MasterCard两大信用卡公组织制定了SET协议，为网上信用卡支付提供了全球性的标准。

(更详细内容请看大神阮一峰的SSL/TLS协议运行机制的概述，下文也会讲解握手内容)

加密算法

HTTPS常见的算法简单讲解:

1、对称加密

加密(encryption)与解密(decryption)用的是同样的密钥(secret key)

优点: 快速、简单
缺点: 密钥的管理与分配风险大

例如：DES、AES-GCM、ChaCha20-Poly1305等

例子：日常点外卖例子，客户和外卖平台协定一个密钥，客户发送请求时候用这个密钥加密，外卖平台用同样密钥解密，这样只要他们协定的密钥不被第三者知道，即使其他人截取了请求也破解不出原本的信息。
问题来了，如果他们的密钥也是通过网络传输的话，是不是就有泄露的危机？到时候顺藤摸瓜就能把客户的账号信息密码全部掌握在手。为什么不私下协定？如果客户多的话肯定不行，如果客户少的话也没什么必要，等倒闭就好了。

2、非对称加密

加密使用的密钥和解密使用的密钥是不相同的，分别是公开密钥(publickey)和私有密钥(privatekey)。
公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密
公开密钥与和算法都是公开的，私有密钥是保密的。非对称加密算法性能较低，但是安全性超强，由于其加密特性，非对称加密算法能加密的数据长度也是有限的。

优点: 安全
缺点: 加密和解密花费时间长、速度慢，只适合对少量数据进行加密

例如：RSA、DSA、ECDSA、 DH、ECDHE
常见的方式是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。

例子：继续说回上面，外卖平台会生成一对公钥和私钥然后把公钥发给客户，私钥自己私下保存。然后客户的请求信息都会使用公钥加密之后再发送，外卖平台可以使用私钥将其解开，即使其他人截取了请求也破解不出原本的信息。
到了这心思敏捷的会想到，不对，既然公开密钥与和算法都是公开的，那其他人也能够得到进而冒充请求，所以为了解决这种情况不仅外卖平台有自己的公钥和私钥，同理客户端也需要有自己的公钥和私钥，即两端都用自己生成的密钥进行通信。

大概流程：

A要向B发送信息，A和B都要产生一对用于加密和解密的公钥和私钥。
A的私钥保密，A的公钥告诉B；B的私钥保密，B的公钥告诉A。
A要给B发送信息时，A用B的公钥加密信息，因为A知道B的公钥。
A将这个消息发给B(已经用B的公钥加密消息)。
B收到这个消息后，B用自己的私钥解密A的消息。其他所有收到这个报文的人都无法解密，因为只有B才有B的私钥。

3、哈希算法

哈希算法并不是一个特定的算法而是一类算法的统称。哈希算法也叫散列算法，任意数据通过一个函数转换成长度固定的数据串(通常用16进制的字符串表示)来保证文件唯一性的标志，函数与数据串之间形成一一映射的关系。

优点:

占用空间小，一般固定长度结果就能代替原数据去做些验证比较；
数据差敏感，即使差别小也得到不同结果；
逆推难度大，跟算法有关；
碰撞几率小，跟算法有关；

缺点:

即使一些无关紧要微小的改变也会得到不同结果；
逆推可能；
碰撞可能；

例如：MD5、SHA-1、SHA-2、SHA-256 等

4、数字签名

数字签名技术是将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
数字签名是个加密的过程，数字签名验证是个解密的过程

优点:

必须依赖于被签名消息的比特模式，这有利于根据数字特性做出更复杂的甄别模式，从而达到更优秀的加/解密效果；
通过利用密码学的技术，使用时相对于签名者来说信息具有唯一性，以防伪造和否认；
在算法上是可验证的，因此数字签名更加严谨和科学；
更加精确地满足了签名的不可模仿性；

缺点: 信息网络系统的管理机制和技术漏洞是数字签名技术应用的最大威胁和挑战
(更多内容请自行查阅，本节到此为止了。)

CA数字证书

上面说的非对称加密其实问题还是存在的，公钥怎么发送给对方？不管是放在公网地址让人下载还是建立连接再发给对方，你都没法验证是真是假的，因为每个人都可以创建自己的密钥。如果有人能冒充外卖平台发给你一个公钥使用，那你的安全就捏在对方手上了。

这种信息安全问题必须有权威部门背书才能让人信服，CA是证书的签发机构，它是PKI的核心。CA是负责签发证书、认证证书、管理已颁发证书的机关。它要制定政策和具体步骤来验证、识别用户身份，并对用户证书进行签名，以确保证书持有者的身份和公钥的拥有权，CA是可以信任的第三方。

上面也说过凡是使用了 https 的网站，都可以通过点击浏览器地址栏的锁头标志来查看网站认证之后的真实信息，也可以通过CA机构颁发的安全签章来查询。具体配置我不知道就不说了。

证书的内容包括：电子签证机关的信息、公钥用户信息、公钥、权威机构的签字和有效期等等。
(更多内容请自行查阅，本节到此为止了。)

握手过程专业版

客户端向服务器传送SSL协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。
服务器向客户端传送SSL协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。
客户端利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的发行者的数字签名，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。
客户端随机产生一个用于后面通讯的对称密码，然后用服务器的公钥(服务器的公钥从步骤二中的服务器的证书中获得)对其加密，然后将加密后的Master-Key传给服务器。
如果服务器要求客户端的身份认证(在握手过程中为可选)，客户端可以建立一个随机数然后对其进行数字签名，将这个含有签名的随机数和客户端自己的证书以及加密过的Master-Key一起传给服务器。
如果服务器要求客户的身份认证，服务器必须检验客户端证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行CA 的数字签名，检查客户的证书是否在证书废止列表(CRL)中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的Master-Key，然后执行一系列步骤来产生主通讯密码(客户端也将通过同样的方法产生相同的主通讯密码)。
服务器和客户端用相同的主密码即通话密码，一个对称密钥用于SSL协议的安全数据通讯的加解密通讯。同时在SSL通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。
客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤7中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。
服务器向客户端发出信息，指明后面的数据通讯将使用的步骤7中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。
SSL的握手部分结束，SSL安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

我知道专业术语加上繁体字好多人看不懂，我翻译成白话文给你们看:

握手过程浓缩版

客户端向服务器传送
- SSL协议版本；
- 加密算法种类；
- 随机数A(用于生成对话密钥)；
- 以及其他相关信息；

服务器返回给客户端
- 确定SSL协议版本；
- 确定加密算法；
- 随机数B(用于生成对话密钥)；
- 以及其他相关信息；
- 服务器证书；
- 要求客户端身份认证(可选)；

客户端利用这些信息验证服务器的各种合法性
- 通过继续；
- 否则断开通讯；

客户端生成一个随机数C(用于生成对话密钥)，从服务器的证书中获得的公钥；
- 公钥加密pre-master key传给服务器；
- 如果要求客户端身份认证，生成一个随机数D(用于验证客户提供证书的CA是否可靠)进行数字签名连同公钥加密的随机数C和客户端证书一起传给服务器；

如果服务器要求认证客户端身份，服务器会检验客户端证书和签名随机数C的合法性。
- 通过，服务器用自己的私钥解开得到随机数C；
- 否则断开通讯；

服务器和客户端拥有随机数A，随机数B，随机数C和确定的加密算法，会生成相同的会话密钥，会话密钥用于SSL协议的安全数据通讯的加解密通讯。同时在SSL通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化；

服务器和客户端
- 确认会话密钥；
- 通知握手结束；

SSL握手结束，开始通讯；

(懒，直接百度图片的拿来用的。。)

(更多内容请自行查阅，本节到此为止了。)

握手过程极致简洁版

客户端发送随机数A，支持的加密方法，及其他相关信息等；
服务端发送随机数B，和服务器证书(可以拿到公钥)，并确认加密方法；
客户端发送用公钥加密的随机数C；
服务器用私钥解密得到随机数C；
服务器和客户端用加密方法计算生成对称加密的会话密钥传输数据；
(更多内容请自行查阅，本节到此为止了。)

HTTPS的缺点

CA申请证书费用高，部署更新很麻烦；
频繁地做加密和解密操作认证等一系列操作，消耗资源多，等待时间长；

HTTPS优化

CDN接入

1) CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法，极大减少HTTPS带来的延时

会话缓存

1) 基于会话缓存建立的 HTTPS 连接不需要服务器使用私钥解密获取信息，可以省去CPU的消耗

简化握手

服务器生成并返回Session ID给客户端，当握手时携带上Session ID，服务端后会从自己的内存查找，如果找到便意味著客户端之前已经发生过完全握手，然后可以直接进行简化握手
当握手时携带上Session Ticket，服务器会对它进行解密，如果解密成功了就意味著它是值得信任的，从而可以进行简化握手，直接传输应用层数据。

硬件加速

远程解密

将最消耗 CPU 资源的解密计算任务转移到其它服务器，如此则可以充分发挥服务器的接入能力，充分利用带宽与网卡资源。
远程解密服务器可以选择 CPU 负载较低的机器充当，实现机器资源复用，也可以是专门优化的高计算性能的服务器。

SPDY/HTTP2

1) 利用 TLS/SSL 带来的优势，通过修改协议的方法来提升 HTTPS 的性能，提高下载速度等