TLS/SSL 梳理

2019/04/10 10:10
阅读数 16

<p>数据加密通篇都是为了防止第三方的劫持伪造,保证连接安全,</p> <p>毫无遮掩的明文传输只有民风淳朴的时候才是安全的。</p> <p>先是一些基础的内容:</p> <!--read more--> <h3>对称加密</h3> <p>最开始为了对数据进行加密,使用的是对称加密算法,即双方协商好一个密钥,传输的时候使用这个密钥对数据进行加密和解密,但是这个密钥当然不能使用网络传输,不然同样被第三方劫持就没有意义了,所以只能私下协商交换密钥。</p> <p>最开始的DES(Data Encryption Standard)对称加密算法使用的是56bit的密钥,这个密钥稍微有点短,在后来完全可以暴力破解加密信息,对于56位的密码,只需要2的56次方就可以暴力穷举。</p> <p>然后又有了新的算法,triple—DES也交3DES,三重加密算法,最高168位密钥,还有AES,以前搭梯子的时候经常能见到,最高256bit密钥,安全性和速度都很出色。</p> <p>但是,和谁通信都私下传密钥明显不现实,于是就有了</p> <h3>非对称加密</h3> <p>各自有个私钥,使用公钥传输,全程只暴露公钥,具体过程:</p> <p>A先用自己的私钥加密数据,然后传递公钥和密文给B,B可以用自己的私钥解密</p> <p>(在一篇文章中提到,使用私钥加密的是hash值,而数据本身是明文的,因为使用密钥加密任意的数据内容存在风险,比如可以刻意的上传一些特定的数据在下载下来,从而破解得到密钥(如RSA),对数据只是payload,所以文章中的逻辑是这样的:A用自己的私钥加密hash,用B的公钥加密加入了其他信息的数据,然后给B,B用A的公钥解得数据,再用私钥解得hash,然后用hash验证完整性。但是目前还不清楚,看了很多,在原理类文章中也并未提及是对什么类型的数据加密,大体逻辑是括号前的,至少rsa是这样)</p> <p>但如果仅仅是上面这样就没有意义了,因为中间人仍然可以拦截AB的公钥,然后把自己的公钥给他们,AB还以为是对方的公钥,这样中间人就可以在中间对数据为所欲为了。</p> <p>这时候</p> <h3>CA证书</h3> <p>就出现了,我们可以向CA申请数字证书,而证书中包含我们的公钥和用户信息,有效时间,机构签字等等,而客户端择装有机构的<strong>根证书</strong>,这个根证书有机构的公钥,用于确认机构所发的证书,</p> <p>为了分CA和TLS/SSL两节,脑子有点乱,不知道怎么写了,用问题的形式自我理一理:</p> <ul> <li>中间人拦截服务器发出的证书并将自己伪造的证书发给客户端?</li> </ul> <p>不可能,因为证书无法伪造,CA所发的公钥只能对证书进行校验,而不能生产证书,私钥在CA手上,如果中间人把自己的申请到的证书发给客户端,则证书的身份和客户端所要访问的服务器的身份对不上。</p> <ul> <li>中间人拦截后向客户端发送伪造的CA证书?</li> </ul> <p>CA证书即根证书,一般安装在客户端中,并不是用网络进行传输的,除非被恶意程序改了,所以破解什么的风险之一就在这里,万一他把你的根证书改成了他伪造的,只能说完蛋。</p> <p>但是服务器的私钥泄漏了的话,就要需要吊销证书了,</p> <p>所以对于没到期但是撤销了的证书又有了CRL证书吊销列表,后来还有了OCSP在线证书状态协议,需要和第三方连接来验证证书状态,信息量较少,响应要比CRL块很多,可以减轻网络和客户端的负担,但是balabala可以看wiki:<a href="[https://zh.wikipedia.org/zh-hans/%E5%9C%A8%E7%BA%BF%E8%AF%81%E4%B9%A6%E7%8A%B6%E6%80%81%E5%8D%8F%E8%AE%AE](https://zh.wikipedia.org/zh-hans/在线证书状态协议)">传送门</a></p> <p>有关免费证书申请可以看我的<a href="https://www.seyana.life/post/15">这篇文章</a></p> <h3>TLS/SSL</h3> 终于到这了,TLS(Transport Layer Security)传输层安全性协议,SSL(Secure Sockets Layer)安全套接层 <p>SSL是TLS的前身,SSL标准化之后就是TLS,TLS处在最高层应用层也就是最接近用户的layer之下,与应用层无耦合,http,ftp,ssh生么的都能运行在TLS之上。</p> <p>用wireshark抓一下我博客的包,可以看到TLS1.2中需要两个RTT(round-trip time)来完成握手,</p> <p>(这里TCP segment of a reassembled PDU是指tcp对过大的数据分包发送,wireshark用此来标记同一个包,我把其他隐藏了方便看)</p> <p><img src="https://www.seyana.life/media/2020/03/image-20200307231619862.png" alt="image-20200307231619862" /></p> <p>过程:</p> <p>客户端向服务器发出请求,提过支持的密码算法列表,</p> <p>服务器收到后决定加密和散列函数,发送CA证书给客户端,</p> <p>客户端收到后,验证证书,不通过over,通过就随机生成一个密钥(这个密钥用作对称加密),用服务器的公钥(在证书里)加密,用相应的算法计算hash,然后再用随机的密钥对hash加密,发给服务器,</p> <p>然后服务器用自己的私钥解密获得对称密钥,通过hash验证数据的是否完整</p> <p>之后的连接都是基于对称加密的,安全且更为高效。</p> <h4>session 重用</h4> <p>在TLS1.2之后支持了sessionid重用,对连接的速度进行了优化,</p> <p>再次访问我的博客抓包,可以看到客户端把之前服务器传来的Session id发给服务器 ,而在服务器中存有对应的sessio id,服务器查到对应纪录后可以直接使用之前的加密信息,之后只需要一个RTT即可完成握手</p> <p><img src="https://www.seyana.life/media/2020/03/image-20200307223104465.png" alt="image-20200307223104465" /></p> <p>但是呢,我这用的还是TLS1.2,在1.3中又进一步对握手过程进行了优化,</p> <p>对于第一次连接,TLS1.2需要2个RTT,1.3只用1个RTT</p> <p>而对于session重用之后,1.2只用1个RTT,而1.3是0个。</p> <br> <p>而对于分布式,session ID就不起作用了,在以前似乎是通过radis来跨服务器缓存什么的,</p> <p>现在提供了session Ticket,它是用对称密钥加密过的,保留在客户端,如果服务器能解密就能加快完成握手,</p> <p>在1.2session Ticket没有时间限制,1.3中加了过期时间</p>

<br>

同时还废弃了一些算法

image-20200308005631116

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

<p>使用1.3也很简单,nginx中只需要在server块给ssl_protocols加上TLSv1.3即可,需要 OpenSSL 1.1.1库,</p> <p>我这里用的ubuntu18.04,似乎自带的1.1.1,可以openssl version -a看一下。</p>

<br>

<h3>HTTPS</h3> <p>HTTP over SSL,顾名思义了,通过TLS/SSL加密http,默认443端口,

现在浏览器都会验证是否是https,不是就给你打上警告,是就给你加小锁锁,证明你们的连接是安全的,可以开心的网上冲浪了,当然连接是安全的,网站本身不一定是安全的。</p>

来自我的博客:Opticor <br><br><br>

原文出处:https://www.cnblogs.com/mckc/p/12501558.html

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部