一: SSL/TLS 介绍
什么是 SSL, 什么是 TLS 呢?
官话说 SSL 是安全套接层 (secure sockets layer),TLS 是 SSL 的继任者,叫传输层安全 (transport layer security)。
说白点,就是在明文的上层和 TCP 层之间加上一层加密,这样就保证上层信息传输的安全。如 HTTP 协议是明文传输,加上 SSL 层之后,就有了雅称 HTTPS。它存在的唯一目的就是保证上层通讯安全的一套机制。
它的发展依次经历了下面几个时期,像手机软件升级一样,每次更新都添加或去除功能,比如引进新的加密算法,修改握手方式等。
- SSL1.0: 已废除 SSL2.0: RFC6176, 已废除
- SSL3.0: RFC6101, 基本废除
- TLS1.0: RFC2246, 目前大都采用此种方式
- TLS1.1: RFC4346 TLS1.2: RFC5246, 没有广泛使用
- TLS1.3: IETF 正在酝酿中
下面我们将介绍 TLS1.x 如何保证通讯安全。
二: CA & SSL Server & SSL Client 介绍
如何保证安全呢?你说安全就安全吗,究竟是怎么实现的呢?绝对安全吗? 哈,有人的地方就有江湖,有江湖的地方就没有绝对的安全。但 SSL/TLS 确实可以极大程度保证信息安全。下面根据图一 SSL/TLS 工作流来一览实现过程。
2.1 SSL/TLS 工作流
image图一 SSL/TLS 工作流
CA: 证书授权中心 (certificate authority)。 它呢,类似于国家出入境管理处一样,给别人颁发护照;也类似于国家工商管理局一样,给公司企业颁发营业执照。
它有两大主要性质:
- CA 本身是受信任的 // 国际认可的
- 给他受信任的申请对象颁发证书 // 和办理护照一样,要确定你的合法身份,你不能是犯罪分子或造反派。
当然,你需要被收保护费,同时,CA 可以随时吊销你的证书。 证书长啥样?其实你的电脑中有一堆 CA 证书。你可以看一看嘛:
- 360 浏览器: 选项 / 设置 -> 高级设置 -> 隐私于安全 -> 管理 HTTPS/SSL * 证书 -> 证书颁发机构
- 火狐浏览器: 首选项 -> 高级 -> 证书 -> 查看证书 -> 证书机构
- chrome 浏览器: 设置 -> 高级 -> 管理证书 -> 授权中心
- ubuntu: /etc/ssl/certs
这些都是 CA 的证书!
CA 的证书 ca.crt 和 SSL Server 的证书 server.crt 是什么关系呢?
- SSL Server 自己生成一个 私钥 / 公钥对。server.key/server.pub // 私钥加密,公钥解密!
- server.pub 生成一个请求文件 server.req. 请求文件中包含有 server 的一些信息,如域名 / 申请者 / 公钥等。
- server 将请求文件 server.req 递交给 CA,CA 验明正身后,将用 ca.key 和请求文件加密生成 server.crt
- 由于 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 证书详细工作流
image图二 证书详细工作流
1)申请认证:服务器需自己生成公钥私钥对 pub_svr & pri_svr,同时根据 pub_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 单向认证流程
image(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 分析
image 我们搭建的 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 分析:
image和单向认证一样: 我们搭建的 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 等拓展名都是什么东东?
- 带有私钥的证书 PKCS12(P12)
包含了公钥和私钥的二进制格式的证书形式,以 pfx 作为证书文件后缀名。 - 二进制编码的证书(DER)
证书中没有私钥,DER 编码二进制格式的证书文件,以 .cer 作为证书文件后缀名。 - Base64 编码的证书(PEM)
证书中没有私钥,Base64 编码格式的证书文件,也是以 .cer 作为证书文件后缀名。
- .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格式:经过加密的文本文件,一般有下面几种开头结尾:
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
or:
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
or:
----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
der 格式: 经过加密的二进制文件。
- 证书中含有 申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文,同时包含一个签名。如查看百度证书详细信息。
a) 先下载百度证书
火狐浏览器访问 https://www.baidu.com/, 点击左上角绿色小锁,点击向右箭头,点击更多信息,点击查看证书,点击详细信息,点击导出。即可导出百度的证书 baiducom.crt
b) 命令查看证书详细信息
openssl x509 -noout -text -in baiducom.crt
image
详细信息中,有一个字段: X509v3 Basic Constraints: CA: FALSE
该字段指出该证书是否是 CA 证书,还是一般性的非 CA 证书。详细描述见 RFC5280#section-4.2.1.9,同时 RFC5280 也详细描述证书工作方式等。
- 私钥加密,公钥解密!
2.8 SSL/TLS 和 Openssl,mbedtls 是什么关系?
SSL/TLS 是一种工作原理,openssl 和 mbedtls 是 SSL/TLS 的具体实现,很类似于 TCP/IP 协议和 socket 之间的关系。
三: 为Tomcat生成和配置HTTPS证书
单向:
-- 为服务器生成证书
keytool -genkey -dname "cn=programmer, ou=JavaSoft, o=Sun, c=US" -keyalg RSA -keysize 1024 -alias tomcat -keypass changeit -keystore server.keystore -storepass changeit -validity 3600
配置Tomcat根目录下的/conf/server.xml
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="${catalina.base}\keystore\server.jks" keystorePass="changeit" />
双向:
-- 为服务器生成证书
keytool -genkey -dname "cn=programmer, ou=JavaSoft, o=Sun, c=US" -keyalg RSA -keysize 1024 -alias tomcat -keypass changeit -keystore server.jks -storepass changeit -validity 3600
-- 为客户端生成证书
-- 双击.p12文件,按照提示安装证书,将证书填入到“受信任的根证书颁发机构”
keytool -genkey -v -alias client -keyalg RSA -storetype PKCS12 -keystore client.p12 -dname "cn=programmer, ou=JavaSoft, o=Sun, c=US"
-- 必须把客户端证书添加为服务器的信任认证。由于不能直接将PKCS12格式的证书库导入,必须先把客户端证书导出为一个单独的CER文件
keytool -export -alias client -keystore client.p12 -storetype PKCS12 -storepass changeit -rfc -file client.cer
-- 将该文件导入到服务器的证书库,添加为一个信任证书
keytool -import -v -file client.cer -keystore server.jks
-- 把服务器证书导出为一个单独的CER文件,使用如下命令
-- 双击.cer文件,按照提示安装证书,将证书填入到“受信任的根证书颁发机构”
keytool -keystore server.jks -export -alias tomcat -file server.cer
配置Tomcat根目录下的/conf/server.xml
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="true" sslProtocol="TLS"
keystoreFile="${catalina.base}\keystore\server.jks" keystorePass="changeit"
truststoreFile="${catalina.base}\keystore\server.jks" truststorePass="changeit" />
参考资料
keytool+tomcat 单向/双向认证的配置
关于Certificate的一切-概念及工具
SSL/TLS 双向认证 (一) -- SSL/TLS 工作原理
SSL 双向认证和 SSL 单向认证的区别
各种安全证书间的关系及相关操作
网友评论