SSL/TLS/WTLS原理 (2)

（产生一份秘密消息，这份秘密消息处理后将用作加密密钥，加密初始化向量和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的代理是怎样工作的(可参见[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

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有