宋思明与小三的游戏规则（理解WS-SECURITY）

Webservice 在业界用得很多，很多企业部门内部系统，甚至企业与企业之间的应用都是靠Webservice集成的。 许多的跨部门或跨企业的消息交互都是在公网进行，大家都知道公网上的黑客，木马程序，拦截工具一堆。 如果忽视安全这一块，后果可想而知。

我们假定基本上使用或恶意使用webservice的人包括：
服务提供者 (宋思明)
第三方 (郭海藻)
第三方 (另一个小三， 假设叫芙蓉姐)
黑客 (黄脸婆,即宋思明老婆)


为了和小三们沟通顺畅， 宋思明和小三们都交换了QQ号。 很无耐， 宋思明老婆永远都知道宋思明的号码。这时候他们的关联关系是：


[img]http://dl.iteye.com/upload/attachment/200123/87a07f88-30e2-3ad7-b017-8ab4d8ebb475.png[/img]


这样， 宋思明就可以跟小三们聊天了， 有时候还不得不应付一下自己老婆发过来的消息。 但问题是如果要跟小三们没正经的瞎聊，宋思明会觉得很不安全。 没准黄脸婆用个拦截工具一拦， 不就什么都曝光啦。

[b]一、[/b]密文传输：上面提到的场景， 便是Webservice 的安全问题之一， 明文传输业务数据非常危险， 总有恶意的黑客们在盯着你的一举一动， 你不得不防。

所以宋思明与小三们商量，设一把密钥， 大家都将QQ消息加密起来， 这样， 黄脸婆就无招了。宋思明与小三们终于可以在网上大聊特聊， 有正经没正经的都聊。 感觉很安全。

加密后， 关联关系变成：


[img]http://dl.iteye.com/upload/attachment/200125/df5ea5af-00f9-3800-a8c0-40de21d65920.png[/img]


有意无意之中， 宋思明发现芙蓉姐在吃海藻的醋， 芙蓉姐质问他为什么给海藻买了房子而芙蓉姐还租在老旧待拆迁的农民房里面。虽然是密文， 但如果芙蓉姐可以解密海藻的消息的话， 宋思明又没啥安全感啦。

[b]二、[/b]非对称加密：以上所提到的场景是Webservice的第二个安全问题， 虽然是密文， 但第三方A不应当可以用密钥解密第三方B的消息。

这一次， 宋思明在家里下载了个密钥工具，给自己分配了一把公钥， 给小三们一人发了一把私钥过去。 这样其实已经有些安全， 老婆是看不到消息了， 小三们之间的问题也解决的七七八八啦。于是宋思明在网上问海藻， 对话如下：

宋思明：!@#$%^&*
海藻：_)*)_)**)

呵呵， 傻了吧， 被加密了。 但是这段对话被芙蓉姐拦截到了， 海藻的话还没有发到宋思明电脑上， 芙蓉姐夫是程序员出身， 他帮芙蓉用芙蓉的私钥解密了宋思明的对话。被解密后的文字：(用私钥可以解密经公钥加密的内容，但用私钥A是解不了私钥B的内容的。)

宋思明：我把你买房的150W打你卡上去。你卡号多少。
海藻：_)*)_)**)


芙蓉姐转发了一下海藻的消息，

海藻：1243-5268-56863 （注：芙蓉姐用了自己的卡号， 并把消息用自己的密钥加密了一下）


宋思明没有将钱打到芙蓉姐卡里， 因为海藻的回答通常会带上很多表情符号：

"谢谢 :) , \p， 我的卡号是1243-5268-56863 (*-*)"

[b]三、[/b]身份验证：以上这种情况便是Webservice所面临的第三个问题， 要确保访问信息的客户或用户是用户本人。要确保消息的完整性， 确保客户或用户日后无法否认对信息的使用。 也就是预防抵赖


上次差点将钱打给芙蓉姐， 也给老宋提了个醒， 他整了个签名机制， 也就是说， 发过来的消息必须经过了消息签名。 并经过私钥加密， 这样的消息才是可信的。


也许你会问， 芙蓉姐也可以伪造签名呀。 但问题是， 签名被海藻用私钥加密过了， 芙蓉姐是拿不到海藻的签名的。