SSL.TLS.WTLS原理（上）
一 前言
首先要澄清一下名字的混淆：
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可以用于保密的传输，这样我们与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（
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.TLS.WTLS原理（下）
八 代理
下面探讨一下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的机制,当传递了一定数量数据包后，双
方通过同样的算法将自己的密钥做一下更新。付出了很小的代价，安全性得以增
强。
参考文献
[1] SSL 3.0 SPECIFICATION
http://home.netscape.com/eng/ssl3/ [2] TLS
http://www.ietf.org/rfc/rfc2246.txt [3] 《应用密码学》
机械工业出版社
[4] The End of SSL and SSH?
http://securityportal.com/cover/coverstory20001218.html [5] HTTP Over TLS
http://www.ietf.org/rfc/rfc2818.txt [6] HTTP Upgrade to TLS
http://www.ietf.org/rfc/rfc2817.txt [7] W* Effect Considered Harmful
http://www.4k-associates.com/IEEE-L7-WAP-BIG.html [8] 智能卡数字加密技术
http://www.yicard.com/cardtech/smartcard/jiami/index.htm [9] HMAC: Keyed-Hashing for Message Authentication
http://www.ietf.org/rfc/rfc2104.txt关于MAC地址和IP地址的知识
在校园网络中，最方便的捣乱方法就是盗用别人的IP地址，被盗用IP地址的计算
机不仅不能正常使用校园网络，而且还会频繁出现IP地址被占用的提示对话框，
给校园网络安全和用户应用带来极大的隐患。捆绑IP地址和MAC地址就能有效地避
免这种现象。
何为MAC地址
网卡在使用中有两类地址，一类是大家都熟悉的IP地址，另一类就是MAC地址
，即网卡的物理地址，也称硬件地址或链路地址，这是网卡自身的惟一标识，就
仿佛是我们的身份证一样，一般不能随意改变。它与网络无关，无论把这个网卡
接入到网络的什么地方，MAC地址都是不变的。其长度为48位二进制数，由12个00
~0FFH的16进制数组成，每个16进制数之间用“-”隔开，如“00-10-5C-AD-72-E3
”。
如何查找MAC地址
1、在Windows 9x/2000/XP下单击“开始/程序”，找到“MS-DOS方式”或“
命令提示符”。
2、在命令提示符下输入：“Ipconfig/all”，回车后出现如附图所示的对话
框，其中的“Physical Address”即是所查的MAC地址。
如何捆绑MAC地址和IP地址
进入“MS-DOS方式”或“命令提示符”，在命令提示符下输入命令：ARP - s
10.88.56.72 00-10-5C-AD-72-E3，即可把MAC地址和IP地址捆绑在一起。
这样，就不会出现IP地址被盗用而不能正常使用校园网络的情况（当然也就
不会出现错误提示对话框），可以有效保证校园网络的安全和用户的应用。
注意：ARP命令仅对局域网的上网代理服务器有用，而且是针对静态IP地址，
如果采用Modem拨号上网或是动态IP地址就不起作用。ARP命令的各参数的功能如
下：
ARP -s -d -a
-s：将相应的IP地址与物理地址的捆绑，如本文中的例子。
-d：删除相应的IP地址与物理地址的捆绑。
-a：通过查询ARP协议表显示IP地址和对应物理地址情况。
3.IP地址和物理地址成对被盗用是怎么回事?
比如，在局域网中，由主机自动分配IP地址，或自己指定IP地址，
自动分配时，先开主机，然后下面的再开的机子自动分配IP为168.192.0.2，
168.192.0.3。。。依此推下去，或自己指定IP，如，主机（1号机）为
168.192.0.1，2号机为168.192.0.2，依此推下去，
在局域网络里，IP地址分配好的情况下，比如，我现在做的是5号机，本来IP应该
是168.192.0.5，但我在设置指定IP时，改为168.192.0.2，这样，就等于说，占
用了2号机的IP，当2号机再启动时，就会出现提示说IP被占用，无法连接网络，
造成上不了网或网络共享访问，简单来讲就是这样了
解决的方法，就是把，那个IP和本机的网卡MAC地址捆绑，让别的占用不成
