This website requires JavaScript.

TLS/SSL 梳理

数据加密通篇都是为了防止第三方的劫持伪造,保证连接安全,

毫无遮掩的明文传输只有民风淳朴的时候才是安全的。

先是一些基础的内容:

对称加密

最开始为了对数据进行加密,使用的是对称加密算法,即双方协商好一个密钥,传输的时候使用这个密钥对数据进行加密和解密,但是这个密钥当然不能使用网络传输,不然同样被第三方劫持就没有意义了,所以只能私下协商交换密钥。

最开始的DES(Data Encryption Standard)对称加密算法使用的是56bit的密钥,这个密钥稍微有点短,在后来完全可以暴力破解加密信息,对于56位的密码,只需要2的56次方就可以暴力穷举。

然后又有了新的算法,triple—DES也交3DES,三重加密算法,最高168位密钥,还有AES,以前搭梯子的时候经常能见到,最高256bit密钥,安全性和速度都很出色。

但是,和谁通信都私下传密钥明显不现实,于是就有了

非对称加密

非对称加密有两种应用,加密和签名:

加密:

不希望别人知道我的消息,所以只有我才能解密

公钥负责加密,私钥负责解密;

签名:

不希望有人冒充我发消息,只有我才能发布这个签名

私钥负责签名,公钥负责验证。

(在一篇文章中提到,使用私钥加密的是hash值,而数据本身是明文的,因为使用密钥加密任意的数据内容存在风险,比如可以刻意的上传一些特定的数据在下载下来,从而破解得到密钥(如RSA),对数据只是payload,所以文章中的逻辑是这样的:A用自己的私钥加密hash,用B的公钥加密加入了其他信息的数据,然后给B,B用A的公钥解得数据,再用私钥解得hash,然后用hash验证完整性。但是目前还不清楚,看了很多,在原理类文章中也并未提及是对什么类型的数据加密,大体逻辑是括号前的,至少rsa是这样)

但如果仅仅是上面这样就没有意义了,因为中间人仍然可以拦截AB的公钥,然后把自己的公钥给他们,AB还以为是对方的公钥,这样中间人就可以在中间对数据为所欲为了。

这时候

CA证书

就出现了,我们可以向CA申请数字证书,而证书中包含我们的公钥和用户信息,有效时间,机构签字等等,而客户端择装有机构的根证书,这个根证书有机构的公钥,用于确认机构所发的证书,

为了分CA和TLS/SSL两节,脑子有点乱,不知道怎么写了,用问题的形式自我理一理:

  • 中间人拦截服务器发出的证书并将自己伪造的证书发给客户端?

不可能,因为证书无法伪造,CA所发的公钥只能对证书进行校验,而不能生产证书,私钥在CA手上,如果中间人把自己的申请到的证书发给客户端,则证书的身份和客户端所要访问的服务器的身份对不上。

  • 中间人拦截后向客户端发送伪造的CA证书?

CA证书即根证书,一般安装在客户端中,并不是用网络进行传输的,除非被恶意程序改了,所以破解什么的风险之一就在这里,万一他把你的根证书改成了他伪造的,只能说完蛋。

但是服务器的私钥泄漏了的话,就要需要吊销证书了,

所以对于没到期但是撤销了的证书又有了CRL证书吊销列表,后来还有了OCSP在线证书状态协议,需要和第三方连接来验证证书状态,信息量较少,响应要比CRL块很多,可以减轻网络和客户端的负担,但是balabala可以看wiki:传送门

有关免费证书申请可以看我的这篇文章

TLS/SSL

终于到这了,TLS(Transport Layer Security)传输层安全性协议,SSL(Secure Sockets Layer)安全套接层

SSL是TLS的前身,SSL标准化之后就是TLS,TLS处在最高层应用层也就是最接近用户的layer之下,与应用层无耦合,http,ftp,ssh生么的都能运行在TLS之上。

用wireshark抓一下我博客的包,可以看到TLS1.2中需要两个RTT(round-trip time)来完成握手,

(这里TCP segment of a reassembled PDU是指tcp对过大的数据分包发送,wireshark用此来标记同一个包,我把其他隐藏了方便看)

image-20200307231619862

过程:

客户端向服务器发出请求,提过支持的密码算法列表,

服务器收到后决定加密和散列函数,发送CA证书给客户端,

客户端收到后,验证证书,不通过over,通过就随机生成一个密钥(这个密钥用作对称加密),用服务器的公钥(在证书里)加密,用相应的算法计算hash,然后再用随机的密钥对hash加密,发给服务器,

然后服务器用自己的私钥解密获得对称密钥,通过hash验证数据的是否完整

之后的连接都是基于对称加密的,安全且更为高效。

session 重用

在TLS1.2之后支持了sessionid重用,对连接的速度进行了优化,

再次访问我的博客抓包,可以看到客户端把之前服务器传来的Session id发给服务器 ,而在服务器中存有对应的sessio id,服务器查到对应纪录后可以直接使用之前的加密信息,之后只需要一个RTT即可完成握手

image-20200307223104465

但是呢,我这用的还是TLS1.2,在1.3中又进一步对握手过程进行了优化,

对于第一次连接,TLS1.2需要2个RTT,1.3只用1个RTT

而对于session重用之后,1.2只用1个RTT,而1.3是0个。


而对于分布式,session ID就不起作用了,在以前似乎是通过radis来跨服务器缓存什么的,

现在提供了session Ticket,它是用对称密钥加密过的,保留在客户端,如果服务器能解密就能加快完成握手,

在1.2session Ticket没有时间限制,1.3中加了过期时间


同时还废弃了一些算法

image-20200308005631116

更多详细的内容可以看 wiki wiki wiki

使用1.3也很简单,nginx中只需要在server块给ssl_protocols加上TLSv1.3即可,需要 OpenSSL 1.1.1库,

我这里用的ubuntu18.04,似乎自带的1.1.1,可以openssl version -a看一下。


HTTPS

HTTP over SSL,顾名思义了,通过TLS/SSL加密http,默认443端口, 现在浏览器都会验证是否是https,不是就给你打上警告,是就给你加小锁锁,证明你们的连接是安全的,可以开心的网上冲浪了,当然连接是安全的,网站本身不一定是安全的。

0条评论
avatar