【网络安全技术】传输层安全——SSL/TLS
一、TLS位置及架构
TLS建立在传输层TCP/UDP之上,应用层之下。
所以这可以解决一个问题,那就是为什么抓不到HTTP和SMTP包,因为这两个在TLS之上,消息封上应用层的头,下到TLS层,TLS层对上层消息整个做了加密,然后套了TLS头下到传输层,套上TCP头给IP,IP套上IP头然后路由,找到下一跳之后ARP问MAC地址,然后封上MAC头,进链路层传输。所以能看到的是TLS头、TCP头,IP头和MAC头。
下面这个图是TLS的架构,TLS内部也分了层,最上层相当于是消息的类型,这几种类型的消息都要下到Record层,套Record头,走Record结构来传输。
握手协议就是建连接的,改变Cipher spec协议就是协商用到的加密算法什么的东西的,Alert协议是返回一些警报,HTTP就是正常的加密的数据,心跳协议是用来维持连接的。
等下可以通过抓到的包来更清晰的看出来这个架构。
二、TLS握手协议
整体流程如下,从RFC 5246文档里偷过来的,
Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
1.Phase 1
一步一步看,先看绿色框起来的两个hello
client hello是第一个消息,注意区分这个握手和TCP握手之间的区别,TCP三次握手是建TCP连接用的,而TLS要走TCP连接,所以在TLS握手之前,TCP已经握完三次手了。
这是访问一个页面https协议的过程,虽然不知道为什么所有包都有两个,但还是可以清晰地看出,TCP三次握手是在TLS ClientHello之前完成的,同时,看TLS下面的这两个TCP ACK,这也说明了TCP在TLS之下,所以TLS不能加密TCP的头。
我们来看看这个hello包长什么样。首先能看出TLS所在的层级,正如刚才所说,他在TCP之上。
其次TLS的内容,这里是handshake Protocol,使用TLS Record protocol封装,所以TLS的所有内容协议,包括握手协议、改变Cipher spec协议、Alert协议、HTTP、心跳协议都是走Record Layer的,所以实际上TLS分两层,在TCP紧上面那层是Record 协议,然后在上边是剩下的协议。
然后看内容吧,对比刚才那张图,这里包括了TLS的版本,随机数,session ID,cipher suite(也就是客户端能接受的加密、认证、密钥交换算法),还有压缩方法。剩下的一堆extension列出了更加细节的客户端所支持的算法,这样服务器只能在这些列出的里面选择。
接下来是Server hello,
他会选择一系列的方法,作为响应回复给Client。这里的一些extension例如session_ticket是用来当session断开时客户端快速连接到服务器的凭证,以及下面的对于应用层协议的下协商。
2.Phase 2
这里阶段二还是抓个包看看,这wireshark不知道抽什么风,这三个Certificate,Server Key Exchange和Server Hello Done都在一层的一个包里,他给分了两个。
看这三个东西还都是封到了Record Layer里,这三个分别顾名思义,证书就是服务器把他的X.509证书给客户端,交换密钥就是服务器通过hello里跟客户端商量的协商密钥算法来交换公钥,这里是椭圆曲线DH。这之后还有可选的服务器向客户端要证书。之后就是server hello done表示他这边结束了,该客户端了。
别忘了这些包都是走的TCP,到了对方那都要回ACK的。
3.phase 3
前面二阶段server发来的证书,client首先会验一下真假,使用CA的公钥来验证证书的签名。对了之后,首先,如果先前服务器要了客户端的证书,客户端会先把他的证书回给服务器。然后他会用server的公钥来验server发来的key exchange参数的签名,之后再生成自己的公钥交换信息,
这就是下面抓到的包,第一个就是client Key exchange的record。
接下来还有一个certificate verify,这个是只有刚才客户端发送了有签名能力的证书才有的一步。
4.phase 4
然后是Change Cipher Spec,这个消息你看长度就1字节,他就是简单的告诉对方我已经将刚才咱们商量的加密什么的投入使用了,所以他发的接下来的包都是使用刚才协商好的东西加密或认证的了。在这之前,客户端和服务器交换完密钥,获得了一个比如DH公共秘密之后,这个公共秘密叫做pre-master secret,这个结合一些其他的例如随机数之类的信息,再来生成最终的session key,Change Cipher Spec代表的就是这个最终的session key投入使用。
后面跟的是client finished,这个永远紧跟在Change Cipher Spec之后,用于验证整个握手的成功。客户端会计算之前所有的握手消息的一个mac,加密之后传给服务器。所以下面抓的包显示这是加密的信息。
这之后,服务器端收到刚才客户端发来的那条消息之后,由于之前在hello里说好了要有new session ticket用来之后快速恢复session,所以这第一个record就是new session ticket,然后是服务器端的Change Cipher Spec,之后是服务器的finish,和client的同理,是计算先前的所有握手消息的mac,同样是加密之后发送。
这之后握手就结束了,这期间任何的错误都会引起alert协议报错,从而终止过程。
三、Alert Protocol
这个就是报各种错误,包括下面这些
? bad_record_mac
? handshake_failure
? decryption_failed
? bad_certificate
四、Heartbeat protocol
这个就是周期性的发送信号,比如用来同步。
他有两个目的,一个是确保双方还活着,另一个是防止有些防火墙会关闭空闲连接。
五、Record protocol
这个刚才也看了,就是封装刚才提到的所有的东西的,格式就是下面这样
content type就会是比如刚才所有握手阶段的Record都是handshake(22),实际发的包的type会是Application Data(23),也可能回事Alert(21)等等。
两个Version就是哪个版本,前面讲的例子都是TLSv1.2,长度就是后面的东西有多长。
接下来看看这个Record是怎么生成的吧,比如有加密、认证、分段、压缩等步骤。
首先拿到具体的数据之后,要分成小于等于2的14次方byte的段,然后如果之前协商了压缩,那么就会压缩。
接下来计算MAC然后接上去,对整个东西加密,然后再套上TLS Record的头,这就是完整的TLS处理完的,可以直接发给下层TCP的东西了。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!