我们每天都在使用互联网,所有数据都要通过计算机网络进行传输,网络本身只具备传输数据的能力,并不能保证数据的安全性。
数据在公共网络中移动的时候,很容易被第三方截获、篡改,造成信息泄漏、中间人攻击等各种网络安全性问题。
这就是计算机网络的真实情况,也是SSL/TLS
协议诞生的背景!
要解决的问题:能够在不安全的网络环境中,安全的传输数据。
安全性体现在两个方面:
1994
年,NetScape
公司设计出SSL(Secure Sockets Layer)
协议1.0
版,但是未发布。
1995
年,NetScape
公司发布SSL 2.0
版,很快发现有严重漏洞。
1996
年,SSL 3.0
版问世,得到大规模应用。
1999
年,互联网标准化组织ISOC
接替NetScape
公司,发布了SSL
的升级版TLS 1.0
版。
2006
年和2008
年,TLS
进行了两次升级,分别为TLS 1.1
版和TLS 1.2
版。
2011
年发布了TLS 1.2
的修订版。
2014
年提出TLS 1.3
版本,直到2018
年才正式纳入标准。
综上所述,SSL
和TLS
就是同一个东西,因为历史版本原因,有了两个名字,可以认为TLS
是SSL
的升级版。
但是更为常用的名字还是SSL
,所以下文为了叙述方便,统一称为SSL
协议。
实现SSL
协议的安全性,基本思路就是数据加密。
从密码学原理来看,加解密需要密钥,具体方法可分为两种:
SSL
就是基于这两种加密方法,完成数据安全性的保障,具体怎么运用的,继续看下文。
先来做一个约定:在网络通信过程中,发送数据的一方称为客户端,接收数据的一方称为服务端,从网络中窃取数据的一方称为第三方。
SSL
协议采用对称加密来保护数据,客户端和服务端在发送数据之前,协商出一个密钥,发送者用这个密钥对数据加密,之后再扔到网络中传输,服务端拿到数据后用相同的密钥解密,还原数据内容。
在网络传输过程中,如果数据被第三方截获,他没有对称密钥,是解不出来数据内容的。因此,数据内容可以得到保护,不会泄漏。
如果第三方截获密文数据以后,尝试替换或者修改密文数据,客户端或服务端拿到数据以后,用对称密钥解不出来正确内容,立刻就能知道数据出现了问题!
此时,就会出现两个问题:
不论客户端还是服务端,解密结果无非就是两种情况:
此时,就需要网络应用层协议发挥作用了,比如客户端发送的是http
协议内容,如果服务端能够解析成功,那内容就是对的,如果解析失败,内容肯定是有问题的!客户端同理。
至于错误内容,到底是双方发的就有问题,还是被第三方篡改的,已经不重要了。
SSL
协议只是保证双方都能够正确接收到彼此传输的内容,在解密成功的情况下,判断内容对不对是应用层协议的事情。
通常来讲,如果数据被第三方篡改了,即使解密成功了,得到的内容也是一堆乱码,除非第三方真的神通广大,拿到了对称密钥,给出了正确的密文数据!
这个过程就是SSL
协议最核心也是最关键的部分,理解了对称密钥协商过程,也就真正理解了SSL
协议。
客户端和服务端所有通信都是基于网络的,因此,对称密钥协商过程也是通过网络进行的,不仅如此,协商过程发送的数据内容几乎还都是明文传输的!
密钥协商过程中的所有元数据都能被第三方截获!
客户端和服务端在第三方监视下协商出对称密钥,还能不被第三方获取到,这就是SSL
协议的巧妙之处!
具体实现要用非对称加密方法,服务端提前在本地环境中生成非对称密钥,私钥自己保管好,公钥可以给任何人。
协商过程如下(先这样理解,实际有出入,后面进阶部分纠正):
因为公钥加密只有私钥能解,而私钥只有服务端有,所以,第三方即使截获到密钥协商数据,因为没有私钥,也无法解密获取对称密钥。
至此,SSL
协议工作原理机制就算是讲完了,稍微总结一下:
SSL
协议实现包含两种加密方法:对称加密,非对称加密。SSL
协议在保障安全的前提下尽可能提高效率的办法。SSL
协议完全可以有另外一种实现方案:通信过程全部采用非对称加密方式,客户端和服务端各自保管私钥,互换公钥,之后的过程使用非对称加密传递数据。文章上半部分是对SSL
协议最基本的原理分析,下半部分详细讲述一下对称密钥的协商过程,属于原理进阶吧。
前面为了好理解些,将对称密钥协商过程归纳如下:
其实,这样说是不对的,真实原理过程比这复杂些~~~
真实环境中,协商对称密钥相对比较复杂的,实现方案从理论上讲不唯一,有多种理论参考模型,虽然手段可能有差异,但是目的都是为了保障数据的安全性。
对称密钥协商过程又叫“握手阶段”,可类比传输层TCP
协议的握手阶段,只不过TCP
是三次握手,标准的SSL
协议模型是四次握手。
第一次握手
客户端发出加密通信请求,称为ClientHello
,提供以下一些信息:
TLS 1.0
版。RSA
公钥加密。第二次握手
服务端收到请求后回应数据,称为SeverHello
,回应信息:
TLS 1.0
版本。如果没有匹配版本,服务端关闭加密通信。RSA
公钥加密。数字证书可以通过各种途径自己生成,但是这样的证书没有社会公信力,还是容易被第三方冒名顶替。
正确的做法是,拿着自己的基本信息和公钥去找权威证书颁发结构,也就是常说的CA
机构,从他们哪里获取具有公信力的证书。
CA
机构会用自己的私钥对证书进行签名,所以这样的证书是无法被篡改的,也能得到所有客户端的认可和校验。
第三次握手
客户端收到响应信息后,首先要验证服务端数字证书,如果证书颁布机构不可信、或者证书中包含的基本信息与服务端不一致、又或者证书已经失效,就会告知当前用户,询问用户是否还要继续通信。
如果数字证书验证通过,或者用户人为选择继续通信,客户端就从证书中提取服务端公钥,并向服务端再次发送信息:
hash
值,用来供服务端校验。第四次握手
注意前面握手阶段提到的随机数,到目前为止,双方都掌握了三个随机数。
两个由客户端生成,一个明文传输给服务端,一个用服务端公钥加密后传输给服务端。
一个由服务端生成,明文传输给客户端。
确定好这三个随机数,客户端和服务端就可以在各自的本地环境中,根据密钥生成器生成对称密钥。数学原理可以保证客户端和服务端生成的密钥是一样的,并且,该密钥无需再次经过网络传输,可以有效避免对称密钥的泄漏问题!
因为第三个随机数是用公钥加密传输的,第三方无法解开,所以,即使第三方截取到另外两个随机数,也不可能根据密钥生成器生成协商出来的对称密钥!
因此,对称密钥就在不安全的网络环境中,安全的产生了。
服务端验证客户端的hash
值,并生成对称密钥以后,返回客户端响应信息:
hash
值,用来供客户端校验。客户端收到响应以后,校验服务端hash
正确以后,就表示四次握手阶段全部完成。
再往后就是用对称密钥加密传输应用层协议数据了。
SSL
协议保障数据安全分两个阶段:
需要明白的是,整个通信过程都能被第三方监听到,但是只要服务端保护好自己的私钥,就能保护好对称密钥不被第三方获取,进而保证关键的通信数据不能被第三方解密。
这就是SSL
协议精彩的地方!能够在不安全的环境中建立起安全的通信机制。
不要把SSL
协议和TCP
协议混为一谈,他们的地位职能不一样:
TCP
是传输层协议,保证数据的可达性,也就是保证数据在网络中不会丢失。SSL
协议功能介于TCP
协议和应用层协议之间,是保证数据安全性的,有人认为应该归属于传输层,有人认为应该归属于会话层。最常见的HTTPS
应用浏览器就是支持SSL
协议功能的实现者。利用HTTP
协议表示数据内容,利用SSL
协议保护数据安全,利用TCP
协议保证数据传输可达性。