SSL/TLS/WTLS

转载来自http://blog.csdn.net/fw0124/article/details/8470940

一 前言

首先要澄清一下名字的混淆：
1 SSL(Secure Socket Layer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上得到了普遍的应用。
2 IETF(www.ietf.org)将SSL做了标准化，即RFC2246,并将其称为TLS（Transport Layer Security），从技术上讲，TLS1.0与SSL3.0的差异很是微小。因为本文中没有涉及二者间的细小差异，本文中这两个名字等价。
3 在WAP的环境下，因为手机及手持设备的处理和存储能力有限，wap论坛（www.wapforum.org）在TLS的基础上作了简化，提出了WTLS协议（Wireless Transport Layer Security），以适应无线的特殊环境。

从SSL协议所提供的服务及其工做流程能够看出，SSL协议运行的基础是商家对消费者信息保密的承诺，这就有利于商家而不利于消费者。在电子商务初级阶段，因为运做电子商务的企业大可能是信誉较高的大公司，所以这问题尚未充分暴露出来。但随着电子商务的发展，各中小型公司也参与进来，这样在电子支付过程当中的单一认证问题就愈来愈突出。虽然在SSL3.0中经过数字签名和数字证书可实现浏览器和Web服务器双方的身份验证，可是SSL协议仍存在一些问题，好比，只能提供交易中客户与服务器间的双方认证，在涉及多方的电子交易中，SSL协议并不能协调各方间的安全传输和信任关系。在这种状况下，Visa和MasterCard两大信用卡公组织制定了SET协议，为网上信用卡支付提供了全球性的标准。

咱们从各式各样的文章中得知，SSL能够用于保密的传输，这样咱们与web server之间传输的消息即是“安全的”。而这种“安全”到底是怎么实现的，最终有能实现多大程度的保密？本文但愿能用通俗的语言阐明其实现原理。

二 总体结构概览
SSL是一个介于HTTP协议与TCP之间的一个可选层，其位置大体以下：
－－－－－－－－－
| HTTP |
－－－－－－－－－
| SSL |
－－－－－－－－－
| TCP |
－－－－－－－－－
| IP |
－－－－－－－－－

若是利用SSL协议来访问网页，其步骤以下：
用户：在浏览器的地址栏里输入https://www.sslserver.com
HTTP层：将用户需求翻译成HTTP请求，如
GET /index.htm HTTP/1.1
Host www.sslserver.com

SSL层: 借助下层协议的的信道安全的协商出一份加密密钥，并用此密钥来加密HTTP请求。
TCP层：与web server的443端口创建链接，传递SSL处理后的数据。
接收端与此过程相反。

SSL在TCP之上创建了一个加密通道，经过这一层的数据通过了加密，所以达到保密的效果。

SSL协议分为两部分：Handshake Protocol和Record Protocol,
其较低的SSL记录层协议位于传输协议TCP/IP之上,定义了传输的格式。SSL记录协议用来对其上层的协议进行封装。
握手协议就在这些被封装的上层协议之中，它容许客户端与服务器彼此认证对方；而且在应用协议发出或收到第一个数据以前协商加密算法和加密密钥。


三 须要的加密方面的基础知识
了解SSL原理须要一点点加密的概念，这里把须要的概念作一下简单阐述：

加密通常分为三类，对称加密，非对称加密及单向散列函数。
对称加密：又分分组密码和序列密码。
分组密码，也叫块加密(block cyphers)，一次加密明文中的一个块。是将明文按必定的位长分组，明文组通过加密运算获得密文组，密文组通过解密运算（加密运算的逆运算），还原成明文组。
序列密码，也叫流加密(stream cyphers)，一次加密明文中的一个位。是指利用少许的密钥（制乱元素）经过某种复杂的运算（密码算法）产生大量的伪随机位流，用于对明文位流的加密。
解密是指用一样的密钥和密码算法及与加密相同的伪随机位流，用以还原明文位流。

在块加密算法中，有ECB,CBC,CFB,OFB这几种算法模式。http://blog.csdn.net/fw0124/article/details/8472560

分组密码的典型例子为DES(64位数据，56位密钥+8位奇偶校验),AES(128位数据，128,192,256位可变密钥),IDEA(64位数据，128位密钥)，
RC5。
RC5是一个RC5-w/r/b家族系列，
w = word size in bits (16/32/64) ，1word=2bits
r = number of rounds (0..255)
b = number of bytes in key (0..255)
建议版本为RC5-32/12/16, so encrypts 64-bit data blocks using 12 rounds with 16 bytes (128-bit) secret key

序列密码的典型例子为RC4。

公钥加密：
简单的说就是加密密钥与解密密钥不一样，分私钥和公钥。这种方法大多用于密钥交换，RSA即是一个咱们熟知的例子。
还有一个经常使用的称做DH(http://blog.csdn.net/fw0124/article/details/8462373)，它只能用于密钥交换，不能用来加密。

单向散列函数：
因为信道自己的干扰和人为的破坏，接受到的信息可能与原来发出的信息不一样，一个通用的办法就是加入校验码。
单向散列函数即可用于此用途，一个典型的例子是咱们熟知的MD5,它产生128位的摘要，在现实中用的更多的是安全散列算法（SHA），SHA的早期版本存在问题，目前用的实际是SHA－1，它能够产生160位的摘要，所以比128位散列更能有效抵抗穷举攻击。
因为单向散列的算法都是公开的，因此其它人能够先改动原文，再生成另一份摘要。解决这个问题的办法能够经过HMAC（RFC 2104）,它包含了一个密钥，只有拥有相同密钥的人才能鉴别这个散列。

四 密钥协商过程
因为非对称加密的速度比较慢，因此它通常用于密钥交换，双方经过公钥算法协商出一份密钥，而后经过对称加密来通讯，固然，为了保证数据的完整性，在加密前要先通过HMAC的处理。

SSL缺省只进行server端的认证，客户端的认证是可选的。如下是其流程图（摘自TLS协议）。

Client	Server
Client Hello
	Server Hello certificate server_key_exchange certificate_request server_hello_done
certificate client_key_exchange certifiate_verify change_cypher_spec finished
	change_cypher_spec finished

① 客户端的浏览器向服务器传送客户端SSL协议的版本号、加密算法的种类、产生的随机数，以及其余服务器和客户端之间通讯所须要的各类信息。
SSL支持如下一些密钥交换方法：
+RSA，要求服务器提供一个RSA证书
+DH(Diffie-Hellman)，要求服务器的证书中包含了由CA签名的DH公开参数。客户或者在证书中提供DH公开参数，或者在密钥交换消息中提供此参数

② Server回答ServerHello。服务器向客户端传送SSL协议的版本号、加密算法的种类、随机数及其余相关信息，
同时，服务器还将向客户端传送本身的证书和密钥交换信息(可选的，有些状况下能够不须要。只有当服务器的证书没有包含必需的数据的时候才发送此消息)。

③ 客户利用服务器传过来的信息验证服务器的合法性。服务器的合法性包括：
证书是否过时，
发行服务器证书的CA是否可靠，
发行者证书的公钥可否正确解开服务器证书的“发行者的数字签名”，
服务器证书上的域名是否和服务器的实际域名相匹配。
若是合法性验证没有经过，则通讯将断开；若是合法性验证经过，则将继续进行第④步。

④ 客户端随机产生一个用于后面通讯的“对称密码”(pre_master_secret)，而后用服务器的公钥（从步骤②中服务器的证书中得到）对其加密，再将加密后的“预主密码”传给服务器。

⑤ 若是服务器要求客户的身份认证（在握手过程当中为可选），用户则能够创建一个随机数，而后对其进行数字签名，将这个含有签名的随机数和客户本身的证书，以及加密过的“预主密码”一块儿传给服务器。
若客户没有证书，则发送一个no_certificate警告，这种状况用于单向认证，即客户端不装有证书；

⑥ 若是服务器要求客户的身份认证，服务器则必须检验客户证书和签名随机数的合法性。具体的合法性验证包括：
客户的证书使用日期是否有效，
为客户提供证书的CA是否可靠，
发行CA的公钥可否正确解开客户证书的发行CA的数字签名，
检查客户的证书是否在证书撤销列表（CRL）中。
检验若是没有经过，则通讯马上中断；
若是验证经过，则服务器将用本身的私钥解开加密的“预主密码”，
而后执行一系列步骤来产生主通讯密码（客户端也将经过一样的方法产生相同的主通讯密码）。

⑦ 服务器和客户端用相同的主密码，即“通话密码”，一个对称密钥用于SSL协议的安全数据通讯的加/解密通讯。
同时，在SSL通讯过程当中还要完成数据通讯的完整性，以防止数据通讯中的任何变化。

⑧ 客户端向服务器端发出信息，指明后面的数据通讯将使用步骤⑦中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。

⑨ 服务器向客户端发出信息，指明后面的数据通讯将使用步骤⑦中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。

⑩ SSL的握手部分结束，SSL安全通道的数据通讯开始，客户和服务器开始
使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

简单的说即是：
SSL客户端（也是TCP的客户端）在TCP连接创建以后，
发出一个ClientHello来发起握手，
这个消息里面包含了本身可实现的算法列表和其它一些须要的消息，
SSL的服务器端会回应一个ServerHello，这里面肯定了此次通讯所须要的算法，
而后发过去本身的证书（里面包含了身份和本身的公钥）。
Client在收到这个消息后会生成一个秘密消息，用SSL服务器的公钥加密后传过去，
SSL服务器端用本身的私钥解密后，会话密钥协商成功，双方能够用同一份会话密钥来通讯了。


五 密钥协商的形象化比喻
若是上面的说明不够清晰，这里咱们用个形象的比喻，咱们假设A与B通讯，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动做的说明用圆括号（）括起。
A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA。
B：咱们用DES－RSA－SHA这对组合好了。
这是个人证书，里面有个人名字和公钥，你拿去验证一下个人身份（把证书发给A）。
目前没有别的可说的了。
A：（查看证书上B的名字是否无误，并经过手头早已有的CA的证书验证了B的证书的真实性，若是其中一项有误，发出警告并断开链接，这一步保证了B的公钥的真实性）
（产生一份秘密消息，这份秘密消息处理后将用做加密密钥，加密初始化向量和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密，封装成称做ClientKeyExchange的消息。因为用了B的公钥，保证了第三方没法窃听）
我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）
注意，下面我就要用加密的办法给你发消息了！
（将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥）
[我说完了]
B：（用本身的私钥将ClientKeyExchange中的秘密消息解密出来，而后将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥，这时双方已经安全的协商出一套加密办法了）
注意，我也要开始用加密的办法给你发消息了！
[我说完了]
A: [个人秘密是...]
B: [其它人不会听到的...]

六 加密的计算
上一步讲了密钥的协商，可是尚未阐明是如何利用加密密钥，加密初始化向量和hmac的密钥来加密消息的。
其实其过程不过如此：
1 借助hmac的密钥，对明文的消息作安全的摘要处理，而后和明文放到一块儿。
2 借助加密密钥，加密初始化向量加密上面的消息。

七 安全性
1）鉴别机制。
公开密钥技术和数字证书能够实现客户端和服务器端的身份鉴别。ClientHello和ServerHello发过去本身的证书(里面包含了身份和本身的公钥)。
2）加密机制。
混合密码体制的使用提供了会话和数据传输的加密性保护。双方使用非对称密码体制协商出本次将要使用的会话密钥，并选择一种对称加密算法。
3）完整性机制。
定义了共享的、能够用来造成报文鉴别码MAC的密钥。数据进行分片压缩后，使用单向散列函数产生一个MAC，加密后置于数据包的后部，而且再一次和数据一块儿被加密,而后加上SSL首部进行网络传输。
这样，若是数据被修改，其散列值就没法和原来的MAC相匹配，从而保证了数据的完整性。 
4）抗重放攻击。
SSL使用序列号来保护通讯方免受报文重放攻击。这个序列号被加密后做为数据包的负载。
在整个SSL握手中，都有一个惟一的随机数来标记这个SSL握手，这样重放便无机可乘。

SecurityPortal在2000年末有一份文章《The End of SSL and SSH?》激起了不少的讨论， 目前也有一些成熟的工具如dsniff（http://www.monkey.org/~dugsong/dsniff/）能够经过man in the middle攻击来截获https的消息。
从上面的原理可知，SSL的结构是严谨的，问题通常出如今实际不严谨的应用中。常见的攻击就是middle in the middle攻击，它是指在A和B通讯的同时，有第三方C处于信道的中间，能够彻底听到A与B通讯的消息，并可拦截，替换和添加这些消息。
1 SSL能够容许多种密钥交换算法，而有些算法，如DH，没有证书的概念，这样A便没法验证B的公钥和身份的真实性，从而C能够轻易的冒充，用本身的密钥与双方通讯，从而窃听到别人谈话的内容。
而为了防止middle in the middle攻击，应该采用有证书的密钥交换算法。
2 有了证书之后，若是C用本身的证书替换掉原有的证书以后，A的浏览器会弹出一个警告框进行警告，但又有多少人会注意这个警告呢？
3 因为美国密码出口的限制，IE，netscape等浏览器所支持的加密强度是很弱的，若是只采用浏览器自带的加密功能的话，理论上存在被破解可能。

八 代理
下面探讨一下SSL的代理是怎样工做的(可参见[6])。这可能与你开始想的不太同样：）
当在浏览器里设置了https的代理，并且在浏览器里输入了https://www.example.com以后，浏览器会与proxy创建tcp连接，而后向其发出这么一段消息：
CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443

而后proxy会向webserver端创建tcp链接,以后，这个代理便彻底成了个内容转发装置。浏览器与web server会创建一个安全通道，所以这个安全通道是端到端的，尽管全部的信息流过了proxy,但其内容proxy是没法解密和改动的（固然要由证书的支持，不然这个地方即是个man in the middle攻击的好场所，见上面的讨论）。

九 关于证书
注意，若是对于通常的应用，管理员只需生成“证书请求”（后缀大多为.csr），它包含你的名字和公钥，而后把这份请求交给诸如verisign等有CA服务公司（固然，连同几百美金），你的证书请求经验证后，CA用它的私钥签名，造成正式的证书发还给你。管理员再在web server上导入这个证书就好了。若是你不想花那笔钱，或者想了解一下原理，能够本身作CA。从ca的角度讲，你须要CA的私钥和公钥。从想要证书的服务器角度将，须要把服务器的证书请求交给CA.
若是你要本身作CA，别忘了客户端须要导入CA的证书（CA的证书是自签名的，导入它意味着你“信任”这个CA签署的证书）。而商业CA的通常不用，由于它们已经内置在你的浏览器中了。

十 wtls
在WAP的环境中，也有安全加密的需求，所以wapforum参照在WWW世界里最为流行的SSL协议设计了WTLS.从原理上说，这份协议与SSL是基本相同的，但在具体的地方做了许多改动。这些改动的大多没有什么技术上的须要，而是因为考虑到手持设备运算与存储的局限而尽可能作了简化。不过个人感受是这些改动意义实在不大，其得到的
计算和存储上节省出来的时间和空间并很少。在硬件速度日新月异的时代，这种改动能得到的好处也许并不不少（一个新的协议便须要大量新的投入，并且与原有体制并不兼容，关于这点有文章[7]作了精彩阐述，可参看）。

这里我简单举一些SSL与WTLS的差异。

1 WTLS在通常udp这类不可靠信道之上工做，所以每一个消息里要有序列号，协议里也要靠它来处理丢包，重复等状况。
此外，拒绝服务攻击也所以变得更加容易。
2 WTLS创建的安全链接是在wap网关和手持设备之间，wap网关和web server之间若是也要保密，便要采再用SSL，即在这种模型中没法实现端到端的加密。

---------- ------------- ---------
| Mobile |----------->| WAP |---------->| WEB |
| Device |<-----------| Gateway |<----------|Server |
| | WTLS | | SSL | |
---------- ------------- ---------

3 WTLS协议里加了一种成为key_refresh的机制,当传递了必定数量数据包后，双方经过一样的算法将本身的密钥作一下更新。付出了很小的代价，安全性得以加强。