转载来自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 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的机制,当传递了一定数量数据包后，双方通过同样的算法将自己的密钥做一下更新。付出了很小的代价，安全性得以增强。