1.简单概述SSL/TLS/DTLS

从 传输层安全性协议-Wiki 中:

传输层安全性协议( 英语:Transport Layer Security,缩写作 TLS ),及其前身,既安全套接层( Secure Sockets Layer,缩写作 SSL )是一种安全协议,目的是为互联网通信,提供安全及数据完整性保障。

用一句话来说就是,SSL是在HTTP不能满足安全需求下的新的协议产物(并由此逐渐衍生HTTPS并反过来推动SSL的发展),TLS是SSL发展到了一定时候的升级版本(二者不可互操,我的理解里这是一个东西的两个阶段,一个不太恰当的比方就像“腾讯的聊天工具”从“TIM”发展到了“微信”,而且TIM和微信都有人使用,TIM和微信不能相互取代;换句话说,并不是“TIM v1.0”和“TIM v1.1”且“TIM v1.1”会替代“TIM v1.0”的关系)。当然,目前所使用的大多数情况下都是TLS,但是由于习惯一般也叫SSL,其实这个不重要,只要知道这两货有时候是一个东西就好了。而DTLS(Datagram Transport Layer Security,即数据包传输层安全性协议)可以认为是UDP版本的TLS(TLS一般在TCP上层)。

在“SSL/TLS工作在哪一层”的问题上,一般认为SSL/TLS工作在OSI七层模型中的传输层,百度百科TLS 里说的是:

安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。较低的层为 TLS 记录协议,位于某个可靠的传输协议(例如 TCP)上面,与具体的应用无关,所以,一般把TLS协议归为传输层安全协议。

争论清楚安全协议工作在哪一层(七层亦或五层模型)没有什么实际意义,但在理解中我认为TSL应该是工作在传输层和应用层之间的(因为握手协议是符合会话层的定义的)。当然如果考试还是会选传输层的 ~


 

2.对称加密和非对称加密

对称加密顾名思义传输的双方均有一把相同的钥匙,也是“一般情况”下用的最多的加密算法了,比如像压缩包的解压缩其实就是一种对称解加密嘛(我压缩一部片,为了不让你的妈妈直接看到,我用密码来进行压缩,然后我口头告诉你密码,你再自己偷偷解压文件从而看片),最常见到的对称加密算法有AES、DES等。优点就是快、方便,缺点也显而易见:这个密码你一激动告诉了你哥哥,你哥哥再告诉了好基友,结果大家都知道了密码(想要分享文件意味着要分享唯一的秘钥,不安全),或者你在QQ上告诉了你哥哥解压密码,结果被你的妈妈看到了(传输秘钥的过程本身也是传输信息的过程,无法保证传输过程不被有心人监听并获取到秘钥)。

非对称加密就是在生成秘钥时,除了自己使用的(私钥,绝不外传)一把专属钥匙外,会多出一把公共的、可以散播的钥匙(公钥),需要明确的是:每一把私钥唯一对应一把公钥,也可以反过来说每一把公钥唯一对应一把私钥;用公钥加密的能且仅能使用对应的私钥解密用私钥加密的能且仅能使用对应的公钥解密知道私钥可以生成公钥但公钥绝对无法反推出私钥

除此之外还有经常听到的MD5校验,这个属于消息摘要算法,是单向、不可逆的加密,加密过程不需要秘钥,但是通过加密之后的文本同样不能反推出源文件(彩虹表?emmm),常用于校验文件完整性。

非对称加密在安全传输上,我觉得 互联网安全之数字签名、数字证书与PKI系统 中这一段说得好:

在传输机密文件中,需要保证三点:

  1. 文件内容不能被读取(加密)

  2. 文件内容不能被篡改(数字签名)

  3. 文件不能被掉包(数字证书)

也可以这么说:

  1. A想传一份机密文件给B,A首先可以请求到B的公钥(这里假设只是单纯地向B索取公钥,并没有通过第三方机构获取B的公钥)。最初始的需求就是不想其他人能直接看到文件内容,那么就使用B的公钥对文件进行加密,然后将文件发给B,B收到后随之用自己的私钥解密出源文件即可。需求总是不断变化的,方法也会随着需求前进——这里有一个风险,那就是如果间谍C在A将已经加密好的文件发给B的中途截取这份文件,虽然C无法解密这份文件(因为C没有B的私钥),但是他可以使用B的公钥加密另外一份文件再发给B,这时候B收到的就是一份被掉包的文件了。

  2. 在另一个场景下,A想传一份文件给B,但是这份文件需不需要加密不重要,重要的是需要向B证明这份文件是A发出的保证文件到B手上时一个字母都不能少,那么这时候就需要数字签名了。A使用消息摘要算法提取源文件的摘要,然后A使用自己的私钥加密这份摘要(形成了签名)后连同源文件(也可以连同使用B的公钥加密后的文件)发给B。B收到这个文件后,先取下签名然后使用A的公钥还原出这个源文件的摘要(到此可以证明这份文件是A发出的),再将源文件(如果是加密后的,就使用B的私钥解密)使用相同的消息摘要算法提取摘要,将前后两个摘要相比如果相同则说明文件一个字母都不差(也就是校验文件完整性)。假设仍然有一个间谍C从中截取了这份文件,C从文件中取下签名并用A的公钥还原出了摘要,哪怕这份文件是明文的,因为C没有A的私钥所以无法将想要伪造的假文件求出新的签名(假设这份假的签名到了B手里,B用A的公钥解不出来就知道这份文件不对劲了,达到了防篡改的目的),当然了,如果这份文件是加密的,那C更无法通过摘要还原出源文件啦。这里仍然有一个风险,如果一开始B拿到的A的公钥是假的,实际上是C的公钥,那么可以说所有信息都会被截取且伪造了。

  3. 于是数字证书出现了,这就相当于一个第三方权威公正机构,A将自己的公钥以及A自己的信息提交给公正机构,这个机构会“颁发”给A一个数字证书,这个证书是公开的、所有人都能获取到的(这个证书一般会被这个机构的私钥所加密)。那么接着当B收到文件后,先到机构获取A的数字证书,通过机构的公钥解出证书内容附带的签名,通过签名判断收到的证书是完整的,那么就得到了一个“公正”过的A的公钥,就能放心的对机密文件进行操作了。

在实际应用中的很多情况下,A会随机生成一串对称秘钥,将文件进行对称加密,随后将这串对称秘钥计算摘要,再使用自己的私钥加密这串摘要,用B的公钥加密这串对称秘钥,随后将加密后的文件、加密后的对称秘钥和加密后的对称秘钥的摘要一起发给B,B获取到这三个东西后通过CA证书判断A的公钥的正确性,随后解出对称秘钥及其摘要,再使用这串对称秘钥解出文件,这么做兼顾了三种算法各自的优点。


 

3.DTLS协议的抓包

根据 RFC 6347 可以看到DTLS完整的握手流程如下:

在密钥交换算法选择PSK(Pre-Shared Key)时,在 RFC 7925 中可以看到 PSK 的握手流程:

我使用 DTLSv1.2 及 TLS_PSK_WITH_AES_128_CCM_8 的方式来测试并抓包,可以看到在发送 Application Data 前要进行8次交互(根据不同的实现方案,很可能过程会略有不同):

  1.  Client   ---->  Server   : Client Hello    此时Session ID Length 和 Cookie Length都是0。这里额外提一下Cookie的作用,在 RFC 6347 提到“Datagram security protocols are extremely susceptible to a variety of DoS attacks.”,所以DTLS借用了无状态Cookie来抵御DoS攻击。Cipher Suites中代表的支持的算法,在这里也就是0xc0a8,即 TLS_PSK_WITH_AES_128_CCM_8 。

  2.  Server   ---->  Client   : Hello Verify Request    服务器相应客户端的 Hello,并根据客户端IP等信息(计算式在RFC 6347中可以找到:Cookie = HMAC(Secret, Client-IP, Client-Parameters))返回 Cookie 。

  3.  Client   ---->  Server   : Client Hello    客户端拿到Cookie后再次向服务器发送 Hello 。

  4.  Server   ---->  Client   : Server Hello, Server Hello Done    服务器收到带Cookie的Hello后会校验,成功后生成 Session ID 并返回 Server Hello ,并且会跟上一个 Server Hello Done 表明Server Hello结束。

  5.  Client   ---->  Server   : Client Key Exchange    客户端发送 Client Key Exchange 并带上 PSK Client Params ,包括 PSK Identify 及其长度,用于后续计算密钥。

  6.  Client   ---->  Server   : Change Cipher Spec    客户端发送 Change Cipher Spec 表示通知服务器已经确认加密方式。

  7.  Client   ---->  Server   : Encrypted Handshake Message    这里发送了一串加密的握手信息,相当于发送了 Finished 。

  8.  Server   ---->  Client   : Change Cipher Spec, Encrypted Handshake Message    和第六、第七步相同,只是这是服务器发出来的而已。

额外提一下PSK,即 pre-shared key ,顾名思义,其实就是在通信双方在通信前已经确定好并且互相都知道的一串密钥,这串密钥依靠PSK Identify (简称 PSK ID)进行索引。说白了,在上述第5步后,服务端收到了PSK ID后会进行索引找到预设好的key(这个key在客户端本地也存放着),随后会根据一套算法结合这个key和双方各自的随机数等参数生成最终使用的对称密钥,就算有人从中截断了握手信息也无法得到这把最终使用的秘钥。

 


 

4.参考资料