SSL双向认证和SSL单向认证的流程和区别

SSL单向认证具体过程

 

image.png

• ①客户端的浏览器向服务器传送客户端SSL协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。

• ②服务器向客户端传送SSL协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。

• ③客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA是否可靠，发行者证书的公钥能否正确解开服务器证书的"发行者的数字签名"，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开;如果合法性验证通过，将继续进行第四步。

• ④用户端随机产生一个用于后面通讯的"对称密码"，然后用服务器的公钥(服务器的公钥从步骤②中的服务器的证书中获得)对其加密，然后将加密后的"预主密码"传给服务器。

• ⑤如果服务器要求客户的身份认证(在握手过程中为可选)，用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的"预主密码"一起传给服务器。

• ⑥如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA是否可靠，发行CA 的公钥能否正确解开客户证书的发行CA的数字签名，检查客户的证书是否在证书废止列表(CRL)中。检验如果没有通过，通讯立刻中断;如果验证通过，服务器将用自己的私钥解开加密的"预主密码 "，然后执行一系列步骤来产生主通讯密码(客户端也将通过同样的方法产生相同的主通讯密码)。

• ⑦服务器和客户端用相同的主密码即"通话密码"，一个对称密钥用于SSL协议的安全数据通讯的加解密通讯。同时在SSL通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。

• ⑧客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。

• ⑨服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。

• ⑩-SSL的握手部分结束，SSL安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

SSL单向认证只要求站点部署了ssl证书就行，任何用户都可以去访问(IP被限制除外等)，只是服务端提供了身份认证。

SSL双向认证具体过程

 

image.png

• ① 浏览器发送一个连接请求给安全服务器。

• ② 服务器将自己的证书，以及同证书相关的信息发送给客户浏览器。

• ③ 客户浏览器检查服务器送过来的证书是否是由自己信赖的CA中心（如沃通CA）所签发的。如果是，就继续执行协议;如果不是，客户浏览器就给客户一个警告消息：警告客户这个证书不是可以信赖的，询问客户是否需要继续。

• ④ 接着客户浏览器比较证书里的消息，例如域名和公钥，与服务器刚刚发送的相关消息是否一致，如果是一致的，客户浏览器认可这个服务器的合法身份。

• ⑤ 服务器要求客户发送客户自己的证书。收到后，服务器验证客户的证书，如果没有通过验证，拒绝连接;如果通过验证，服务器获得用户的公钥。

• ⑥ 客户浏览器告诉服务器自己所能够支持的通讯对称密码方案。

• ⑦ 服务器从客户发送过来的密码方案中，选择一种加密程度最高的密码方案，用客户的公钥加过密后通知浏览器。

• ⑧ 浏览器针对这个密码方案，选择一个通话密钥，接着用服务器的公钥加过密后发送给服务器。

• ⑨ 服务器接收到浏览器送过来的消息，用自己的私钥解密，获得通话密钥。

• ⑩ 服务器、浏览器接下来的通讯都是用对称密码方案，对称密钥是加过密的。

双向认证则是需要服务端与客户端提供身份认证，只能是服务端允许的客户能去访问，安全性相对于要高一些。

SSL/TLS 工作流

图一 SSL/TLS 工作流

CA: 证书授权中心( certificate authority)。 它呢，类似于国家出入境管理处一样，给别人颁发护照；也类似于国家工商管理局一样，给公司企业颁发营业执照。
它有两大主要性质：
1) CA本身是受信任的 // 国际认可的
2) 给他受信任的申请对象颁发证书 // 和办理护照一样，要确定你的合法身份，你不能是犯罪分子或造反派。当然，你需要被收保护费，同时，CA可以随时吊销你的证书。
证书长啥样？其实你的电脑中有一堆CA证书。你可以看一看嘛：
360浏览器: 选项/设置-> 高级设置 -> 隐私于安全 -> 管理 HTTPS/SSL 证书 -> 证书颁发机构
火狐浏览器: 首选项 -> 高级 -> 证书 -> 查看证书 -> 证书机构
chrome浏览器: 设置 -> 高级 -> 管理证书 -> 授权中心
ubuntu: /etc/ssl/certs
这些都是 CA 的证书！
CA 的证书 ca.crt 和 SSL Server的证书 server.crt 是什么关系呢？
1) SSL Server 自己生成一个 私钥/公钥对。server.key/server.pub // 私钥加密，公钥解密！
2) server.pub 生成一个请求文件 server.req. 请求文件中包含有 server 的一些信息，如域名/申请者/公钥等。
3) server 将请求文件 server.req 递交给 CA，CA验明正身后，将用 ca.key和请求文件加密生成 server.crt
4) 由于 ca.key 和 ca.crt 是一对, 于是 ca.crt 可以解密 server.crt.
在实际应用中：如果 SSL Client 想要校验 SSL server.那么 SSL server 必须要将他的证书 server.crt 传给 client.然后 client 用 ca.crt 去校验 server.crt 的合法性。如果是一个钓鱼网站，那么CA是不会给他颁发合法server.crt证书的，这样client 用ca.crt去校验，就会失败。比如浏览器作为一个 client,你想访问合法的淘宝网站https://www.taobao.com, 结果不慎访问到 https://wwww.jiataobao.com ,那么浏览器将会检验到这个假淘宝钓鱼网站的非法性，提醒用户不要继续访问！这样就可以保证了client的所有https访问都是安全的。

2.2 单向认证双向认证
何为SSL/TLS单向认证，双向认证？
单向认证指的是只有一个对象校验对端的证书合法性。
通常都是client来校验服务器的合法性。那么client需要一个ca.crt,服务器需要server.crt,server.key
双向认证指的是相互校验，服务器需要校验每个client,client也需要校验服务器。
server 需要 server.key 、server.crt 、ca.crt
client 需要 client.key 、client.crt 、ca.crt

2.3 证书详细工作流

图二 证书详细工作流

1）申请认证：服务器需自己生成公钥私钥对pub_svr & pri_svr，同时根据 pri_svr 生成请求文件 csr,提交给CA，csr中含有公钥、组织信息、个人信息(域名)等信息。(图一中server.req就是csr请求文件)
2）审核信息：CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等。
3）签发证书：如信息审核通过，CA会向申请者签发认证文件-证书。
证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。
签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名。（图一中生成server.crt）
4）返回证书：client如果请求验证服务器，服务器需返回证书文件。（图一中handshake传回server.crt）
5）client验证证书：client读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法。客户端然后验证证书相关的域名信息、有效时间是否吊销等信息。
客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。(图一中check可选，我们可以选择不验证服务器证书的有效性)
6）秘钥协商：验证通过后，Server和Client将进行秘钥协商。接下来Server和Client会采用对称秘钥加密。(对称加密时间性能优)（图一中 pre-master/change_cipher_spec/encrypted_handshake_message过程）
7）数据传输：Server和Client采用对称秘钥加密解密数据。
2.4 SSL/TLS单向认证流程

---------------------

(1)client_hello
客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下：

支持的最高TSL协议版本version，从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，当前基本不再使用低于 TLSv1 的版本;
客户端支持的加密套件 cipher suites 列表， 每个加密套件对应前面 TLS 原理中的四个功能的组合：认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验);
支持的压缩算法 compression methods 列表，用于后续的信息压缩传输;
随机数 random_C，用于后续的密钥的生成;
扩展字段 extensions，支持协议与算法的相关参数以及其它辅助信息等，常见的 SNI 就属于扩展字段，后续单独讨论该字段作用。
(2).server_hello+server_certificate+sever_hello_done
server_hello, 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 等，其中随机数用于后续的密钥协商;
server_certificates, 服务器端配置对应的证书链，用于身份验证与密钥交换;
server_hello_done，通知客户端 server_hello 信息发送结束;
(3).证书校验
[证书链]的可信性 trusted certificate path，方法如前文所述;
证书是否吊销 revocation，有两类方式离线 CRL 与在线 OCSP，不同的客户端行为会不同;
有效期 expiry date，证书是否在有效时间范围;
域名 domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析;
(4).client_key_exchange+change_cipher_spec+encrypted_handshake_message
client_key_exchange，合法性验证通过之后，客户端计算产生随机数字 Pre-master，并用证书公钥加密，发送给服务器;
此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，计算得到协商密钥;
enc_key=Fuc(random_C, random_S, Pre-Master)
change_cipher_spec，客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;
encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证;
(5).change_cipher_spec+encrypted_handshake_message
服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);
计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;
change_cipher_spec, 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;
encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端;
(6).握手结束
客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成;

(7).加密通信
开始使用协商密钥与算法进行加密通信。

2.5 实际wireshark分析

我们搭建的SSL/TLS服务器是192.168.111.100,client是192.168.111.101. client 需要认证 server的合法性。
我们只看 TLSv1.1 的数据包：
第一包(No. 25) Client Hello 包，即SSL/TLS单向认证流程的(1)
第二包(No. 27) Server Hello 包，包含服务器证书等。即SSL/TLS单向认证流程的(2)
第三包(No. 28) 服务器证书验证完成，同时发送client key exchange+change cipher spec + encrypted handshake message.即SSL/TLS单向认证流程的(4)
第四包(No. 29)秘钥协商，change cipher spec + encrypted hanshake message.即SSL/TLS单向认证流程的(5)
第五包(No. 30)握手完成。开始上层数据传输。SSL/TLS单向认证流程的(7)

2.6 SSL/TLS双向认证流程
和单向认证几乎一样，只是在client认证完服务器证书后，client会将自己的证书client.crt传给服务器。服务器验证通过后，开始秘钥协商。
实际wireshark分析：

和单向认证一样:
我们搭建的SSL/TLS服务器是192.168.111.100,client是192.168.111.101. client 需要认证 server的合法性，server也需要认证client的合法性！
我们只看 TLSv1.1 的数据包：
第一包(No. 55) Client Hello 包，即SSL/TLS单向认证流程的(1)
第二包(No. 57) Server Hello 包，包含服务器证书等。即SSL/TLS单向认证流程的(2)
第三包(No. 60) 服务器证书验证完成，同时发送客户端的证书client.crt ,同时包含client key exchange+change cipher spec + encrypted handshake message.即SSL/TLS单向认证流程的(4)
第四包(No. 61)服务器验证客户端证书的合法性。通过后进行秘钥协商，change cipher spec + encrypted hanshake message.即SSL/TLS单向认证流程的(5)
重传包(No. 62)由于网络原因，TCP重传第No. 60包。
第五包(No. 64)握手完成。开始上层数据传输。SSL/TLS单向认证流程的(7)

2.7 证书等格式说明
crt/key/req/csr/pem/der等拓展名都是什么东东？
1) .crt 表示证书, .key表示私钥, .req 表示请求文件,.csr也表示请求文件, .pem表示pem格式，.der表示der格式。
文件拓展名你可以随便命名。只是为了理解需要而命名不同的拓展名。但文件中的信息是有格式的，和exe，PE格式一样,证书有两种格式。
pem格式和der格式。所有证书，私钥等都可以是pem,也可以是der格式，取决于应用需要。
pem和der格式可以互转:

openssl x509 -in ca.crt -outform DER -out ca.der //pem -> der
openssl x509 -inform der -in ca.der -out ca.pem // der -> pem

pem格式：经过加密的文本文件，一般有下面几种开头结尾：
1
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
or:
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
or:
----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

der格式: 经过加密的二进制文件。

2) 证书中含有 申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。如查看百度证书详细信息。
a) 先下载百度证书
火狐浏览器访问https://www.baidu.com/, 点击左上角绿色小锁，点击向右箭头，点击更多信息，点击查看证书，点击详细信息，点击导出。即可导出百度的证书 baiducom.crt

b) 命令查看证书详细信息

openssl x509 -noout -text -in baiducom.crt

详细信息中，有一个字段： X509v3 Basic Constraints: CA: FALSE
该字段指出该证书是否是 CA证书，还是一般性的非 CA 证书。详细描述见 RFC5280#section-4.2.1.9，同时 RFC5280 也详细描述证书工作方式等。

3) 私钥加密，公钥解密！

2.8 SSL/TLS和 Openssl,mbedtls是什么关系？
SSL/TLS是一种工作原理，openssl和mbedtls是SSL/TLS的具体实现，很类似于 TCP/IP协议和socket之间的关系。

三: 本地生成SSL相关文件
3.1 证书生成脚本
我们自己本地使用 makefile.sh 脚本建立一个CA(ca.crt + ca.key)，用这个CA给server和client分别颁发证书。

makefile.sh

# * Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# * Neither the name of the axTLS project nor the names of its
# contributors may be used to endorse or promote products derived
# from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
# TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
# OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
# NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
# THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#

#
# Generate the certificates and keys for testing.
#

PROJECT_NAME="TLS Project"

# Generate the openssl configuration files.
cat > ca_cert.conf << EOF
[ req ]
distinguished_name = req_distinguished_name
prompt = no

[ req_distinguished_name ]
O = $PROJECT_NAME Dodgy Certificate Authority
EOF

cat > server_cert.conf << EOF
[ req ]
distinguished_name = req_distinguished_name
prompt = no

[ req_distinguished_name ]
O = $PROJECT_NAME
CN = 192.168.111.100
EOF

cat > client_cert.conf << EOF
[ req ]
distinguished_name = req_distinguished_name
prompt = no

[ req_distinguished_name ]
O = $PROJECT_NAME Device Certificate
CN = 192.168.111.101
EOF

mkdir ca
mkdir server
mkdir client
mkdir certDER

# private key generation
openssl genrsa -out ca.key 1024
openssl genrsa -out server.key 1024
openssl genrsa -out client.key 1024

# cert requests
openssl req -out ca.req -key ca.key -new \
-config ./ca_cert.conf
openssl req -out server.req -key server.key -new \
-config ./server_cert.conf
openssl req -out client.req -key client.key -new \
-config ./client_cert.conf

# generate the actual certs.
openssl x509 -req -in ca.req -out ca.crt \
-sha1 -days 5000 -signkey ca.key
openssl x509 -req -in server.req -out server.crt \
-sha1 -CAcreateserial -days 5000 \
-CA ca.crt -CAkey ca.key
openssl x509 -req -in client.req -out client.crt \
-sha1 -CAcreateserial -days 5000 \
-CA ca.crt -CAkey ca.key

openssl x509 -in ca.crt -outform DER -out ca.der
openssl x509 -in server.crt -outform DER -out server.der
openssl x509 -in client.crt -outform DER -out client.der

mv ca.crt ca.key ca/
mv server.crt server.key server/
mv client.crt client.key client/

mv ca.der server.der client.der certDER/

rm *.conf
rm *.req
rm *.srl
将上述代码保存为makefile.sh
做如下修改，终端执行。

- 修改 CN 域中 IP 地址为你主机/设备的 IP 地址
- [可选]加密位数 1024 修改为你需要的加密位数

将会看到：

ca目录：保存ca的私钥ca.key和证书ca.crt
certDER目录:将证书保存为二进制文件 ca.der client.der server.der
client目录: client.crt client.key
server目录:server.crt server.key

3.2 删除脚本
$./makefile.sh
删除脚本rmfile.sh:

rm ca/ -rf
rm certDER/ -rf
rm client/ -rf
rm server/ -rf

将上述代码保存为rmfile.sh,终端执行，将会删除产生过的目录和文件：

$./rmfile.sh
3.3 CA校验证书测试
我们可在本地使用 CA证书来分别校验由自己颁发的服务器证书 server.crt 和客户端证书 client.crt .

$openssl verify -CAfile ca/ca.crt server/server.crt
$openssl verify -CAfile ca/ca.crt client/client.crt