一、首先要澄清一下名字的混淆
1.SSL(Secure Socket Layer)是Netscape公司设计的主要用于WEB的安全传输协议。这种协议在WEB上获得了广泛的应用。
2.IETF将SSL作了标准化，即RFC2246，并将其称为TLS（Transport Layer Security），从技术上讲，TLS1.0与SSL3.0的差别非常微小。由于本文中没有涉及两者间的细小差别，本文中这两个名字等价。
3.在WAP的环境下，由于手机及手持设备的处理和存储能力有限，Wap论坛在TLS的基础上做了简化，提出了WTLS协议（Wireless Transport Layer Security），以适应无线的特殊环境。
我们从各式各样的文章中得知，SSL可以用于保密的传输，这样我们与Web Server之间传输的消息便是“安全的”。 而这种“安全”究竟是怎么实现的，最终有能实现多大程度的保密？本文希望能用通俗的语言阐明其实现原理。
二、整体结构概览
SSL是一个介于HTTP协议与TCP之间的一个可选层，其位置大致如下：
－－－－－－－－－ | HTTP | －－－－－－－－－ | SSL | －－－－－－－－－ | TCP | －－－－－－－－－ | IP | －－－－－－－－－ |
如果利用SSL协议来访问网页，其步骤如下：
用户：在浏览器的地址栏里输入https://www.sslserver.com
HTTP层：将用户需求翻译成HTTP请求，如
GET /index.htm HTTP/1.1 Host http://www.sslserver.com |
SSL层：借助下层协议的的信道安全的协商出一份加密密钥，并用此密钥来加密HTTP请求。
TCP层：与web server的443端口建立连接，传递SSL处理后的数据。
接收端与此过程相反。
SSL在TCP之上建立了一个加密通道，通过这一层的数据经过了加密，因此达到保密的效果。
SSL协议分为两部分：Handshake Protocol和Record Protocol,。其中Handshake Protocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。
三、需要的加密方面的基础知识
了解SSL原理需要一点点加密的概念，这里把需要的概念做一下简单阐述：
加密一般分为三类，对称加密，非对称加密及单向散列函数。
对称加密：又分分组密码和序列密码。
分组密码是将明文按一定的位长分组，明文组经过加密运算得到密文组，密文组经过解密运算（加密运算的逆运算），还原成明文组。
序列密码是指利用少量的密钥（制乱元素）通过某种复杂的运算（密码算法）产生大量的伪随机位流，用于对明文位流的加密。
解密是指用同样的密钥和密码算法及与加密相同的伪随机位流，用以还原明文位流。
CBC(Cipher Block Chaining)模式这个词在分组密码中经常会用到，它是指一个明文分组在被加密之前要与前一个的密文分组进行异或运算。当加密算法用于此模式的时候除密钥外，还需协商一个初始化向量（IV），这个IV没有实际意义，只是在第一次计算的时候需要用到而已。采用这种模式的话安全性会有所提高。
分组密码的典型例子为DES、RC5、IDEA。
序列密码的典型例子为RC4。
公钥加密：
简单的说就是加密密钥与解密密钥不同，分私钥和公钥。这种方法大多用于密钥交换，RSA便是一个我们熟知的例子。
还有一个常用的称作DH，它只能用于密钥交换，不能用来加密。
单向散列函数：
由于信道本身的干扰和人为的破坏，接受到的信息可能与原来发出的信息不同，一个通用的办法就是加入校验码。
单向散列函数便可用于此用途，一个典型的例子是我们熟知的MD5,它产生128位的摘要，在现实中用的更多的是安全散列算法（SHA），SHA的早期版本存在问题，目前用的实际是SHA－1，它可以产生160位的摘要，因此比128位散列更能有效抵抗穷举攻击。
由于单向散列的算法都是公开的，所以其它人可以先改动原文，再生成另外一份摘要。解决这个问题的办法可以通过HMAC（RFC 2104）,它包含了一个密钥，只有拥有相同密钥的人才能鉴别这个散列。
四、密钥协商过程
由于对称加密的速度比较慢，所以它一般用于密钥交换，双方通过公钥算法协商出一份密钥，然后通过对称加密来通信，当然，为了保证数据的完整性，在加密前要先经过HMAC的处理。
SSL缺省只进行server端的认证，客户端的认证是可选的。以下是其流程图（摘自TLS协议）。
Client Server Clienth*llo --------> Serverh*llo Certificate* ServerKeyExchange* CertificateRequest* <-------- Serverh*lloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data |
简单的说便是：SSL客户端（也是TCP的客户端）在TCP链接建立之后，发出一个Clienth*llo来发起握手，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL的服务器端会回应一个Serverh*llo，这里面确定了这次通信所需要的算法，然后发过去自己的证书（里面包含了身份和自己的公钥）。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 借助加密密钥，加密初始化向量加密上面的消息。
七、安全性
SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的讨论，目前也有一些成熟的工具如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的代理是怎样工作的。当在浏览器里设置了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是基本相同的，但在具体的地方作了许多改动。这些改动的大多没有什么技术上的需要，而是由于考虑到手持设备运算与存储的局限而尽量做了简化。不过我的感觉是这些改动意义实在不大，其获得的计算和存储上节省出来的时间和空间并不多。在硬件速度突飞猛进的时代，这种改动能获得的好处也许并不很多（一个新的协议便需要大量新的投入，而且与原有体制并不兼容）。
这里我简单举一些SSL与WTLS的差别。
1.WTLS在一般udp这类不可靠信道之上工作，因此每个消息里要有序列号，协议里也要靠它来处理丢包，重复等情况。此外，拒绝服务攻击也因此变得更加容易。
2.WTLS建立的安全连接是在wap网关和手持设备之间，wap网关和web server之间如果也要保密，便要采再用SSL，即在这种模型中无法实现端到端的加密。
---------- ------------- --------- | Mobile |----------->| WAP |---------->| WEB | | Device |<-----------| Gateway |<----------|Server | | | WTLS | | SSL | | ---------- ------------- --------- |
3.WTLS协议里加了一种成为key_refresh的机制，当传递了一定数量数据包后，双方通过同样的算法将自己的密钥做一下更新。付出了很小的代价，安全性得以增强。