1、SSL全景式说明
最常见的SSL的应用是在HTTPS中，主要是在传输层之上，应用层之下，加入了一层加密层，构建一条安全的信道，来传输应用层的数据，传输层的TCP仅保证了传输数据不丢包，但是未保证数据在传输的过程中不被窃听，篡改，甚至有可能访问的对端本身就是一个伪装的对端，比如出现了DNS劫持的情况。
SSL主要就是为了解决上述3个问题，来保证 数据的保密性，数据的完整性以及完成身份认证。
SSL的协议先后经历过SSL1.0，SSL2.0 和SSL3.0版本，较新的版本为TLS1.0，TLS1.1，TLS1.2，TLS1.3。TLS 1.3为最新版本。早期版本如SSLV2和SSLV3均有较严重漏洞，均已废弃
主流的SSL的实现为openssl（https://www.openssl.org）和mbedtls（https://tls.mbed.org/）。
2、密码学工具
SSL对核心问题的解决依赖于密码学工具，涉及到的密码学原理主要包括三种。分别是对称加密算法，非对称加密算法，以及摘要算法。
对称加密算法
对称加密算法的核心是发送端和接收端使用同样的密钥，对数据进行加密和解密。
优点是相对于后续介绍的非对称加密算法来说执行很快。
缺点是密钥管理存在风险，任意一端保有的密钥泄露，就会导致传输数据的泄密。
常见的对称加密算法包括，DES，3DES，AES，RC4等等。其中DES以现在的计算能力非常容易被破解。
目前应用最多的为AES(advanced encryption standard)。
对称加密算法由于其高效性在实际的解决方案中被广泛应用，用于解决数据传输过程中的数据的保密性的问题。但对称加密算法的前提是双端都要持有密钥，很显然双端的密钥获取有两种方式，一种是提前通过某种方式预置密钥到发送端和接收端，显然这种方式存在巨大的泄露风险，另一种便是在执行信息交换前，通过某种安全的方式来实时交换共同的密钥，这也是目前主流的解决方案，非对称加密算法就是为了解决这个问题应运而生的。
非对称加密算法
非对称算法的核心目的是在尚不安全的信道，进行密钥的交换，同时要保证该密钥不被任何人窃取，显然这个密钥不能以明文的方式在信道上传输。
主流的解决方案有两种类型，第一类是最常见的包含公私钥类的密钥交互算法，第二类是DH类密钥交换算法。如下表格说明了两种类型的非对称加密算法的协商过程。
| 公私钥类的密钥交互算法（以RSA为例） | DH类密钥交换算法（以DHE为例） |
|---|---|
| 1、客户端发起请求，服务器端回复公钥 | 1、客户端申请开始DHE交换流程 |
| 2、客户端用随机数算法生成密钥S，使用公钥加密生成C，发送给服务器 | 2、服务端选定大数p和q,生成随机值Xb。p和q为全世界公认的一对值。发送Pb和DHE参数p和q给客户端。（Pb=q^Xb mod p） |
| 3、服务器收到C后，使用公钥对应的私钥进行解密，得到S，通知客户端ok | 3、客户端收到DHE参数p和q之后，生成Xa，计算得到Pa，返回给服务器端 |
| 4、客户端和服务端后续使用S加密来交换数据 | 4、同时客户端根据收到的Pb，根据Xa和Pb计算得到Sa(Sa=Pb^Xa mod p) |
| 5、服务器端收到Pa后，根据Xb和Pa计算得到Sb | |
| 6、Sa=Sb=S，客户端和服务端使用S来交换数据。 | |
可以看到DH类密钥交换算法相对于公私钥类密钥交换算法稍为复杂，公私钥类算法存在前向不安全问题，受限于私钥是否安全保存。而DH类密钥交换算法，每条会话都会新生成一个密钥，且交换依赖于公开的大数p和q，没有服务器私钥介入密钥交换的流程。
第一类公私钥类的密钥交换算法主要包括RSA算法，ECDH算法。
第二类DH类密钥交换算法的主要包括DHE算法，ECDHE算法。
非对称加密算法辅助对称加密算法，完成保证数据保密性的任务，同时在身份认证中也发挥重要作用，后续会继续描述
摘要算法
摘要算法的核心是生成数据的一段标签，该标签的生成是不可逆的，即无法通过标签反向地推导出数据。同时摘要算法的输出长度是固定的。
常见的摘要算法包括：md5，sha(根据长度分为sha256,sha384等等)，mac
很显然摘要算法可以用于数据的完整性校验，保证数据不被篡改。很多网站在发布软件安装包时也会附上安装包的MD5值，让使用者方便地判断下载的文件是否与发布的文件的一致，或者是被篡改。
3、SSL解决方案-数字证书
如节1所述，SSL主要解决数据的保密性，数据的完整性以及完成身份认证
数据的保密性可以通过对称加密算法配合非对称加密算法解决，数据的完整性可通过摘要算法解决。那么身份认证如何解决呢？
可以联想到我们实际生活中，找工作时需要有大学颁发的大学毕业证书，才能让用人单位信任你的学习能力。购买食品饮料时，外包装会有食品药品监督管理局印发的凭证，证明自己可靠的食品。
网络上的服务端或者说网站亦是如此，需要提供某种证书凭证来证明自己是一个可信的服务端，这种证书往往是通过某个公开权威机构获得的，同时我们也可以使用该证书去权威机构那边认证，这就是所谓的数字证书。
数字证书的生成与认证，大量地用到了上述的对称，非对称，以及摘要算法。
证书内容包含的最主要信息是 证书的拥有者，证书的颁发者，证书的截止日期，证书公钥，以及附加的用于认证的签名。
签名是通过对签发的数字证书的内容进行摘要，然后对得到的结果用根证书的私钥进行加密得到的值。而证书的颁发者也会发布证书，这种证书称为根证书，拥有者和颁发者是同一机构，包含有证书公钥。根证书是可以用于认证根证书签发的证书的证书，在主流的浏览器chrome,ie,firefox，以及主流的操作系统windos,mac,linux,ios,android中都会内置很多根证书机构的根证书。
所有希望在网上提供宣称自己是可靠安全服务的服务端，都需要去根证书机构申请得到签发的证书。但互联网上网站和服务如雨后春笋般多，根证书机构根本来不及处理，就会签发一些中间证书，也就是证书中间商，这些中间商的证书是由根证书机构签发过的，服务器希望申请证书也可以去这些中间商机构申请签发，通过中间商签发的证书也能够经过认证，这就是证书的链式认证。
具体证书的生成和认证流程，以及该流程中是如何应用上述加密算法，在如下表格中作了简单说明。
| 证书生成 | 证书认证 |
|---|---|
| 1、使用工具生成公钥与私钥，比如openssl工具（这点也可能是完全直接由机构生成） | 1、服务器将证书返回给客户端 |
| 2、构造证书，把公钥嵌入证书 | 2、客户端将返回的证书除了签名外，进行摘要计算，得到R1 |
| 3、缴纳费用给根证书或者中间证书机构，并提供证书 | 3、客户端根据证书找到签发的证书，用签发证书的公钥对签名进行解密，得到R2 |
| 4、对证书做摘要，并用根证书的私钥加密摘要，作为签名 | 4、比较R1和R2是否一致，结果通过就说明认证通过，信任服务端。 |
| 5、证书生成完成，可以分发给后续需要连接的客户端 | |
4、SSL协议流程
通过上述梳理可以明确基于SSL协议的连接的典型核心流程如下序列展示。
上述流程说明了SSL对数据传输中的核心安全问题的解决方案，但是对称加密算法有多种，非对称加密算法亦有多种，实际在单次连接中，只需要用到对应各一种算法即可，而且不可能所有的终端都实现了所有的算法，故而SSL协议就定义了SSL报文的交互流程，用于协商具体使用何种算法，当然也包括认证。
一个典型的SSL报文交互流程如下
典型的SSL报文包含两个部分，RECORD层和HANDSHAKE层。
RECORD层即头部，包含内容类型，协议版本和长度。HANDSHAKE层根据内容类型，各有差异。
最核心的协商流程包含以下环节（内容类型），并非所有环节都是必须环节
| 内容类型 | 内容含义 | 是否必须 |
|---|---|---|
| Client Hello | 客户端发起SSL连接请求，发送包含加密套件（cipher suite）等核心字段和部分扩展字段 | 是 |
| Server Hello | 服务器端回应client hello, 返回支持的TLS版本，选定的加密套件和压缩方式等等 | 是 |
| Server certificate | 服务器端发送证书 | 是 |
| Server key exchange | 发送DH类密钥交互算法中客户端所需的密钥 | 否，仅在DH类密钥交互算法握手时需要 |
| Certificate request | 服务器端请求客户端发送证书认证 | 否，仅双向认证时需要 |
| Server hello done | 告知客户端 服务器端的握手阶段报文发送完毕 | 是 |
| Client certificate | 返回服务器客户端的证书 | 否，仅双向认证时需要 |
| Client key exchange | 根据不同的密钥交互类型， DH类或者公私钥类，返回服务器端所需的运算生成密钥的参数 | 是 |
| Change Cipher | 表示后面发送的数据会用密钥加密 | 是 |
| … | 还包括其他一些环节 |
典型的DH类密钥交换流程的交互流程如下：
不过需要注意的是一个TCP报文中可能包含多个SSL报文，比如服务器端的hello报文和证书就可能在一个TCP报文中返回。
这里最关键的协商内容之一是在Client hello中发送的加密套件，类似如下的形态，服务器端会在其中选择支持的套件在Server hello的Cipher Suite字段中返回所选择使用的加密套件。
如果是如下的例子：
这表示秘钥交换和身份认证使用RSA算法，注意此处身份认证应该就是Server certificate环节证书的验证方式，使用RC4_128为对称加密算法，SHA1为摘要算法。
或者是如下的例子：
这表示密钥交换是使用ECDHE算法，故而就会存在 Server key exchange 环节，身份认证使用ECDSA算法，对称加密使用AES_128_CBC算法，摘要使用SHA1算法。
在网上可以搜到的白名单形式的nginx的常见SSL配置也是如下的形式，其中ssl_ciphers中的配置也可按照如下方式理解：
server {
listen 443 ssl;
# ssl验证相关配置
ssl_session_timeout 5m; #缓存有效期
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
#加密算法
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #安全链接可选的加密协议
ssl_prefer_server_ciphers on; #使用服务器端的首选算法
location / {
root html;
index index.html index.htm;
}
}
其中ECDHE-RSA-AES128-GCM-SHA256就意味着密钥交换是使用ECDHE算法，故而就会存在 Server key exchange 环节，身份认证使用RSA算法，对称加密使用AES128-GCM算法，摘要使用SHA256算法。
Openssl和mbedtls就是通过对编程实现密码学算法，并实现了上述的SSL协商协议，完成协商后，通过应用算法于实际数据进行消息传输。
不过上述加密工具当然也可单独进行使用。
5、参考
了解的过程中参考了如下csdn的博客专题，本文的核心内容也是基于该系列博客对SSL的完整流程进行了梳理，如有描述不清的地方，可移步该系列博客。
https://blog.csdn.net/mrpre/category_9270159.html
https://blog.csdn.net/qq_38265137/article/details/90112705
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
