赞
踩
我们每天都在使用互联网,所有数据都要通过计算机网络进行传输,网络本身只具备传输数据的能力,并不能保证数据的安全性。
数据在公共网络中移动的时候,很容易被第三方截获、篡改,造成信息泄漏、中间人攻击等各种网络安全性问题。
这就是计算机网络的真实情况,也是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
年,TLS
升级到TLS 1.1
版本。
2008
年,TLS
升级到TLS 1.2
版本。
2011
年,发布了TLS 1.2
的修订版。
2014
年提出TLS 1.3
版本,直到2018
年才正式纳入标准。
综上所述,SSL
和TLS
就是同一个东西,因为历史版本原因,有了两个名字,可以认为TLS
是SSL
的升级版。
但是更为常用的名字还是SSL
,所以下文为了叙述方便,统一称为SSL
协议。
实现SSL
协议的安全性,基本思路就是数据加密。
从密码学原理来看,加解密需要密钥,具体方法可分为两种:
SSL
就是基于这两种加密方法,完成数据安全性的保障,具体怎么运用的,继续看下文。
先做一个约定:在网络通信过程中,发送数据的一方称为客户端,接收数据的一方称为服务端,从网络中窃取数据的一方称为第三者。
SSL
协议会对原始数据进行对称加密,并传输数据,整个过程可分为三个步骤:
如果有第三者从网络中截获密文:
因为他没有对应的协商密钥,所以无法对密文进行解密,因此原始数据内容就不会泄漏;
如果他擅自修改密文,再继续传输给服务端,服务端用协商密钥解密就会出错,立刻就能察觉这份数据有问题!
此时,继续思考,应该会产生一个疑问,并且发现一个漏洞:
如果能杜绝第三者获取协商密钥的办法,就不会再有这样一个漏洞。
如果搞清楚了对称密钥的协商过程,就会惊叹于它的设计逻辑,并且顿悟这样的逻辑就是杜绝第三者最好的手段。
这个协商过程就是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
协议保证数据传输可达性。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。