SSL/TLS简介
SSL/TLS是一种密码通信框架,他是世界上使用最广泛的密码通信方法。SSL/TLS综合运用了密码学中的对称密码,消息认证码,公钥密码,数字签名,伪随机数生成器等,可以说是密码学中的集大成者。
TLS协议的架构
TLS主要分为两层,底层的是TLS记录协议,主要负责使用对称密码对消息进行加密。
上层的是TLS握手协议,主要分为握手协议,密码规格变更协议和应用数据协议4个部分。
- 握手协议负责在客户端和服务器端商定密码算法和共享密钥,包括证书认证,是4个协议中最最复杂的部分。
- 密码规格变更协议负责向通信对象传达变更密码方式的信号
- 警告协议负责在发生错误的时候将错误传达给对方
- 应用数据协议负责将TLS承载的应用数据传达给通信对象的协议。
TLS记录协议
消息首先将会被分段,然后压缩,再计算其消息验证码,然后使用对称密码进行加密,加密使用的是CBC模式,CBC模式的初始向量是通过主密码来生成的。
得到密文之后会附加类型,版本和长度等其他信息,最终组成最后的报文数据。
握手协议
注:
1、这里可用版本号,可用的密码套件清单,可用的压缩方式清单就是向服务器询问对方支持哪些服务。
2、客户端随机数和服务器随机数是用来生成对称密钥的随机数。
3、可选步骤:certificate服务器端发送自己的证书清单,因为证书可能是层级结构的,所以处理服务器自己的证书之外,还需要发送为服务器签名的证书。客户端将会对服务器端的证书进行验证。如果是以匿名的方式通信则不需要证书。
4、可选步骤:ServerKeyExchange,如果第三步的证书信息不足,则可以发送ServerKeyExchange用来构建加密通道。
ServerKeyExchange的内容可能包含两种形式:
- 如果选择的是RSA协议,那么传递的就是RSA构建公钥密码的参数(E,N)。我们回想一下RSA中构建公钥的公式:密文=明文^E\ mod\ N密文=明文EmodN, 只要知道了E和N,那么就知道了RSA的公钥,这里传递的就是E,N两个数字。
- 如果选择的是Diff-Hellman密钥交换协议,那么传递的就是密钥交换的参数。
5、可选步骤:CertificateRequest如果是在一个受限访问的环境,比如fabric中,服务器端也需要向客户端索要证书。如果并不需要客户端认证,则不需要此步骤。
6、server hello done,服务器端发送server hello done的消息告诉客户端自己的消息结束了。
7、可选步骤:Certificate,客户端发送客户端证书给服务器
8、ClientKeyExchange分两种情况:
- 如果是公钥或者RSA模式情况下,客户端将根据客户端生成的随机数和服务器端生成的随机数,生成预备主密码,通过该公钥进行加密,返送给服务器端。
- 如果使用的是Diff-Hellman密钥交换协议,则客户端会发送自己这一方要生成Diff-Hellman密钥而需要公开的值。具体内容可以参考更加安全的密钥生成方法Diffie-Hellman,这样服务器端可以根据这个公开值计算出预备主密码。
9、可选步骤:CertificateVerify客户端向服务器端证明自己是客户端证书的持有者。
10、ChangeCipherSpec(准备切换密码),ChangeCipherSpec是密码规格变更协议的消息,表示后面的消息将会以前面协商过的密钥进行加密。
11、finished(握手协议结束),客户端告诉服务器端握手协议结束了。
12、ChangeCipherSpec(准备切换密码),服务器端告诉客户端自己要切换密码了。
13、finished(握手协议结束),服务器端告诉客户端,握手协议结束了。
14、切换到应用数据协议,这之后服务器和客户端就是以加密的方式进行沟通了。
什么是主密码?
- 主密码是根据密码套件中定义的单向散列函数实现的伪随机数生成器+预备主密码+客户端随机数+服务器端随机数生成的。
- 主密码主要用来生成对称密码的密钥,消息认证码的密钥和对称密码的CBC模式所使用的初始化向量。
什么是预备主密码?
- 如果是公钥或者RSA模式情况下,客户端将根据客户端生成的随机数和服务器端生成的随机数,生成预备主密码,通过该公钥进行加密,返送给服务器端。
- 如果使用的是Diff-Hellman密钥交换协议,则客户端会发送自己这一方要生成Diff-Hellman密钥而需要公开的值。
SSL/TLS优势
- 强认证。 用 TLS 建立连接的时候,通讯双方可以互相检查对方的身份。在实践中,很常见的一种身份检查方式是检查对方持有的 X.509 数字证书。这样的数字证书通常是由一个受信机构颁发的,不可伪造。
- 保证机密性。TLS 通讯的每次会话都会由会话密钥加密,会话密钥由通讯双方协商产生。任何第三方都无法知晓通讯内容。即使一次会话的密钥泄露,并不影响其他会话的安全完整性。 加密通讯中的数据很难被篡改而不被发现。
SSL/TLS协议
SSL/TLS 单向验证
在单向认证中,EMQX或其他MQTT 服务器使用 SSL 证书进行身份验证,客户端不需要提供证书。
客户端可以验证服务器的身份,确保连接的安全性和可信度。这种方式适用于客户端只需验证服务器身份,而无需验证客户端身份的场景。
SSL/TLS 证书准备
通常来说,我们会需要数字证书来保证 TLS 通讯的强认证。数字证书的使用本身是一个三方协议,除了通讯双方,还有一个颁发证书的受信第三方,有时候这个受信第三方就是一个 CA。和 CA 的通讯,一般是以预先发行证书的方式进行的。也就是在开始 TLS 通讯的时候,我们需要至少有 2 个证书,一个 CA 的,一个 EMQX/其他MQTT 服务 的,EMQX/其他MQTT 服务的证书由 CA 颁发,并用 CA 的证书验证。
获得一个真正受外界信任的证书需要到证书服务提供商进行购买。在实验室环境,我们也可以用自己生成的证书来模拟这个过程。下面我们分别以这两种方式来说明 EMQX/其他MQTT服务 服务器的 SSL/TLS 启用过程。
注意: 购买证书与自签名证书的配置,读者根据自身情况只需选择其中一种进行测试。
购买证书
如果有购买证书的话,就不需要自签名证书。可以前往国内阿里云或者腾讯云购买证书。
由于我是本地测试所以采用自签名证书。
自签名证书
下载并安装 OpenSSL ,具体可参考《OpenSSL下载安装教程》,很详细
我们需要一个自签名的 CA 证书。生成这个证书需要有一个私钥为它签名,可以执行以下命令来生成私钥:
openssl genrsa -out ca.key 2048
这个命令将生成一个密钥长度为 2048 的密钥并保存在 ca.key 中。有了这个密钥,就可以用它来生成根证书了:
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.pem
查看 CA 证书信息(可选):
openssl x509 -in ca.pem -noout -text
根证书是整个信任链的起点,如果一个证书的每一级签发者向上一直到根证书都是可信的,那个我们就可以认为这个证书也是可信的。有了这个根证书,我们就可以用它来给其他实体签发实体证书了。
实体(在这里指的是 EMQX / 其他MQTT服务)也需要一个自己的私钥对来保证它对自己证书的控制权。生成这个密钥的过程和上面类似:
openssl genrsa -out emqx.key 2048
然后新建 openssl.cnf 文件,并填入:
[req]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
countryName = CN
stateOrProvinceName = GuangDong
localityName = ZhuHai
organizationName = EMQX
commonName = Server certificate
[req_ext]
subjectAltName = @alt_names
[v3_req]
subjectAltName = @alt_names
[alt_names]
IP.1 = BROKER_ADDRESS
DNS.1 = BROKER_ADDRESS
其中:
req_distinguished_name :根据情况进行修改
alt_names: BROKER_ADDRESS 修改为 EMQX / 其他MQTT 服务器实际的 IP 或 DNS 地址,例如:IP.1 = 127.0.0.1,或 DNS.1 = broker.xxx.com
然后以这个密钥和配置签发一个证书请求:
openssl req -new -key ./emqx.key -config openssl.cnf -out emqx.csr
然后以根证书来签发实体证书:
openssl x509 -req -in ./emqx.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out emqx.pem -days 3650 -sha256 -extensions v3_req -extfile openssl.cnf
查看实体证书(可选):
openssl x509 -in emqx.pem -noout -text
验证实体证书,确定证书是否正确:
openssl verify -CAfile ca.pem emqx.pem
SSL/TLS 启用及验证
在 EMQX / 其他MQTT服务 中 mqtt:ssl 的默认监听端口为 8883。
将前文中通过 OpenSSL 工具生成的 emqx.pem、emqx.key 及 ca.pem 文件拷贝到 EMQX 的 etc/certs/ 目录下,并参考如下配置修改 emqx.conf:
listeners.ssl.default {
bind = "0.0.0.0:8883"
max_connections = 512000
ssl_options {
#keyfile = "etc/certs/key.pem"
#certfile = "etc/certs/cert.pem"
#cacertfile = "etc/certs/cacert.pem"
keyfile = "etc/certs/emqx.key"
certfile = "etc/certs/emqx.pem"
cacertfile = "etc/certs/ca.pem"
}
}
MQTT 连接测试
此时 Certificate 一栏需要选择 Self signed ,并携带自签名证书中生成的 ca.pem 文件。
打开 EMQX 的 Dashboard 在 Listeners 页面可以看到在 8883 端口上有一个 mqtt:ssl 连接,或在其他MQTT服务器控制台查看连接信息
通过抓包看数据已经加密
参考: http://support.emqx.cn/hc/kb/article/1553131/