Secure socket layer(SSL)协议最初由Netscape企业发展，现已成为网络用来鉴别网站和网页浏览者身份，以及在浏览器使用者及网页服务器之间进行加密通讯的全球化标准。由于SSL技术已建立到所有主要的浏览器和WEB服务器程序中，因此，仅需安装数字证书，或服务器证书就可以激活服务器功能了。这次专题我们先从SSl原理讲起。
SSL原理解密
RSA公钥加密在计算机产业中被广泛使用在认证和加密。可以从RSA Data Security Inc.获得的RSA公钥加密许可证。公钥加密是使用一对非对称的密码加密或解密的方法。每一对密码由公钥和私钥组成。公钥被广泛发布。私钥是隐密的，不公开。用公钥加密的数据只能够被私钥解密。反过来，使用私钥加密的数据只能用公钥解密。这个非对称的特性使得公钥密很有用。
使用公钥加密法认证
认证是一个身份认证的过程。在下列例子中包括甲和乙，公钥加密会非常轻松地校验身份。符号{数据} key意味着"数据"已经使用密码加密或解密。假如甲想校验乙的身份。乙有一对密码，一个是公开的，另一个是私有的。乙透露给甲他的公钥。甲产生一个随机信息发送给乙。 甲——〉乙：random-message
乙使用他的私钥加密消息，返回甲加密后的消息。 乙——〉甲：{random-message}乙的私钥
甲收到这个消息然后使用乙的以前公开过的公钥解密。他比较解密后的消息与他原先发给乙的消息。如果它们完全一致，就会知道在与乙说话。任意一个中间人不会知道乙的私钥，也不能正确加密甲检查的随机消息。
除非你清楚知道你加密的消息。用私钥加密消息，然后发送给其他人不是一个好主意。因为加密值可能被用来对付你，需要注意的是：因为只有你才有私钥，所以只有你才能加密消息。所以，代替加密甲发来的原始消息，乙创建了一个信息段并且加密。信息段取自随机消息（random-message）并具有以下有用的特性：
1. 这个信息段难以还原。任何人即使伪装成乙，也不能从信息段中得到原始消息；
2. 假冒者将发现不同的消息计算出相同的信息段值；
3. 使用信息段，乙能够保护自己。他计算甲发出的随机信息段，并且加密结果，并发送加密信息段返回甲。甲能够计算出相同的信息段并且解密乙的消息认证乙。
这个技术仅仅描绘了数字签名。通过加密甲产生的随机消息，乙已经在甲产生的消息签名。因此我们的认证协议还需要一次加密。一些消息由乙产生：
甲——〉乙：你好，你是乙么?
乙——〉甲：甲，我是乙
{信息段[甲，我是乙] } 乙的私钥
当你使用这个协议，乙知道他发送给乙的消息，他不介意在上面签名。他先发送不加密的信息，"甲，我是乙。"，然后发送信息段加密的消息版本。甲可以非常方便地校验乙就是乙，同时，乙还没有在他不想要的信息上签名。
提交公钥
那么，乙怎样以可信的方式提交他的公钥呢？看看认证协议如下所示：
甲——〉乙：你好
乙——〉甲：嗨，我是乙，乙的公钥
甲——〉乙：prove it
乙——〉甲：甲，我是乙 {信息段[甲，我是乙] } 乙的私钥
在这个协议下，任何人都能够成为"乙"。所有你所要的只是公钥和私钥。你发送给甲说你就是乙，这样你的公钥就代替了乙的密码。然后，你发送用你的私钥加密的消息，证明你的身份。甲却不能发觉你并不是乙。 为了解决这个问题，标准组织已经发明了证书。一个证书有以下的内容：
* 证书的发行者姓名
* 发行证书的组织
* 标题的公钥
* 邮戳
证书使用发行者的私钥加密。每一个人都知道证书发行者的公钥（这样，每个证书的发行者拥有一个证书）。证书是一个把公钥与姓名绑定的协议。通过使用证书技术，每一个人都可以检查乙的证书，判断是否被假冒。假设乙控制好他的私钥，并且他确实是得到证书的乙，就万事大吉了。
这些是修订后的协议：
甲——〉乙：你好
乙——〉甲：嗨，我是乙，乙的校验
甲——〉乙：prove it
乙——〉甲：甲，我是乙 {信息段[甲， 我是乙] } 乙的私钥
现在当甲收到乙的第一个消息，他能检查证书，签名（如上所述，使用信息段和公钥解密），然后检查标题（乙的姓名），确定是乙。他就能相信公钥就是乙的公钥和要求乙证明自己的身份。乙通过上面的过程，制作一个信息段，用一个签名版本答复甲。可以校验乙的信息段通过使用从证书上得到的公钥并检查结果。
如果一个黑客，叫H
甲——〉H：你好
H——〉不能建立一个令甲相信的从乙的消息。
交换密码（secret）
一旦甲已经验证乙后，他可以发送给乙一个只有乙可以解密、阅读的消息：
甲——〉乙：{secret}乙的公钥
唯一找到密码的方法只有使用乙的私钥解码上述的信息。交换密码是另一个有效使用密码加密的方法。即使在甲和乙之间的通讯被侦听，只有乙才能得到密码。
使用密码作为另一个secret-key增强了网络的安全性，但是这次这是一个对称的加密算法（例如DES、RC4、IDE甲）。因为甲在发送给乙之前产生了密码，所以甲知道密码。乙知道密码因为乙有私钥，能够解密甲的信息。但他们都知道密码，他们都能够初始化一个对称密码算法，而且开始发送加密后的信息。这儿是修定后的协议：
甲——〉乙：你好
乙——〉甲：嗨，我是乙，乙的校验
甲——〉乙：prove it
乙——〉甲：甲，我是乙 {信息段[甲，我是乙] }乙的私钥
甲——〉乙：ok 乙，here is a secret {secret}乙的公钥
乙——〉甲：{some message}secret-key
黑客窃听
那么如果有一个恶意的黑客H在甲和乙中间，虽然不能发现甲和乙已经交换的密码，但能干扰他们的交谈。他可以放过大部分信息，选择破坏一定的信息（这是非常简单的，因为他知道甲和乙通话采用的协议）。
甲——〉H：你好
H——〉乙：你好
乙——〉H：嗨，我是乙，乙的校验
H——〉甲：嗨，我是乙，乙的校验
甲——〉H：prove it
H——〉乙：prove it
乙——〉H：甲，我是乙 {信息段[甲，我是乙] }乙的私钥
H——〉甲：甲，我是乙 {信息段[甲，我是乙] }乙的私钥
甲——〉H：ok 乙，here is a secret {secret} 乙的公钥
H——〉乙：ok 乙，here is a secret {secret} 乙的公钥
乙——〉H：{some message}secret-key
H——〉甲：Garble[{some message}secret-key ]
H忽略一些数据不修改，直到甲和乙交换密码。然后H干扰乙给甲的信息。在这一点上，甲相信乙，所以他可能相信已经被干扰的消息并且尽力解密。
需要注意的是，H不知道密码，他所能做的就是毁坏使用秘钥加密后的数据。基于协议，H可能不能产生一个有效的消息。但下一次呢？
为了阻止这种破坏，甲和乙在他们的协议中产生一个校验码消息（messageauthentication code）。一个校验码消息（MAC）是一部分由密码和一些传输消息产生的数据。信息段算法描述的上述特性正是它们抵御H的功能：
MAC= Digest[some message，secret ]
因为H不知道密码，他不能得出正确的值。即使H随机干扰消息，只要数据量大，他成功的机会微乎其微。例如，使用HD5（一个RSA发明的好的加密算法），甲和乙能够发送128位MAC值和他们的消息。H猜测正确的MAC的几率将近1/18，446，744，073，709，551，616约等于零。
这是又一次修改后的协议：
甲——〉乙：你好
乙——〉甲：嗨，我是乙，乙的校验
甲——〉乙：prove it
乙——〉甲：嗨，我是乙，乙的校验
甲，我是乙
{信息段[甲，我是乙] } 乙的私钥
ok 乙，here is a secret {secret} 乙的公钥
{some message，MAC}secret-key
现在H已经无技可施了。他干扰了得到的所有消息，但MAC计算机能够发现他。甲和乙能够发现伪造的MAC值并且停止交谈。H不再能与乙通讯。
SSL/TLS/WTLS原理通
在CIW课程中虽然没有对SSL做深入的讨论，但是SSL已成为应用最广泛的互连网安全协议了，有必要对其深刻理解
一 前言
首先要澄清一下名字的混淆：
1 SSL(Secure SocketLayer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。
2 IETF(www.ietf.org)将SSL作了标准化，即RFC2246,并将其称为TLS（TransportLayer Security），从技术上讲，TLS1.0与SSL3.0的差别非常微小。由于本文中没有涉及两者间的细小差别，本文中这两个名字等价。
3 在WAP的环境下，由于手机及手持设备的处理和存储能力有限，wap论坛（www.wapforum.org）在TLS的基础上做了...S协议（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,。其中HandshakeProtocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。
在CIW课程中虽然没有对SSL做深入的讨论，但是SSL已成为应用最广泛的互连网安全协议了，有必要对其深刻理解
一 前言
首先要澄清一下名字的混淆：
1 SSL(Secure SocketLayer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。
2 IETF(www.ietf.org)将SSL作了标准化，即RFC2246,并将其称为TLS（TransportLayer Security），从技术上讲，TLS1.0与SSL3.0的差别非常微小。由于本文中没有涉及两者间的细小差别，本文中这两个名字等价。
3 在WAP的环境下，由于手机及手持设备的处理和存储能力有限，wap论坛（www.wapforum.org）在TLS的基础上做了...S协议（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,。其中HandshakeProtocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。
在CIW课程中虽然没有对SSL做深入的讨论，但是SSL已成为应用最广泛的互连网安全协议了，有必要对其深刻理解
一 前言
首先要澄清一下名字的混淆：
1 SSL(Secure SocketLayer)是netscape公司设计的主要用于web的安全传输协议。这种协议在WEB上获得了广泛的应用。
2 IETF(www.ietf.org)将SSL作了标准化，即RFC2246,并将其称为TLS（TransportLayer Security），从技术上讲，TLS1.0与SSL3.0的差别非常微小。由于本文中没有涉及两者间的细小差别，本文中这两个名字等价。
3 在WAP的环境下，由于手机及手持设备的处理和存储能力有限，wap论坛（www.wapforum.org）在TLS的基础上做了...S协议（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,。其中HandshakeProtocol用来协商密钥，协议的大部分内容就是通信双方如何利用它来安全的协商出一份密钥。 Record Protocol则定义了传输的格式。
七 安全性
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 inthe 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是无法解密和改动的（当然要由证书的支持，否则这个地方便是个manin the middle攻击的好场所，见上面的讨论）。
九 关于证书
注意，如果对于一般的应用，管理员只需生成“证书请求”（后缀大多为.csr），它包含你的名字和公钥，然后把这份请求交给诸如verisign等有CA服务公司（当然，连同几百美金），
你的证书请求经验证后，CA用它的私钥签名，形成正式的证书发还给你。管理员再在webserver上导入这个证书就行了。如果你不想花那笔钱，或者想了解一下原理，可以自己做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的机制,当传递了一定数量数据包后，双方通过同样的算法将自己的密钥做一下更新。付出了很小的代价，安全性得以增强。
SSL是如何工作的?
声明：由于最近对安全加密相关技术比较感兴趣，所以翻译了这篇SSL的工作原理。这是一篇比较好的文章，深入浅出的介绍了SSL -- 安全套接层的工作原理，但是由于本人的加密知识及英语水平所限，感觉很多地方翻译的不好，但是我相信大家还是能够看懂的。：-）还是那句老话，本文欢迎非商业性转载，但请保持文章完整性并注明出处！
密钥密码系统介绍
这篇文章向大家阐述了Netscape公司是如何使用RSA的公用密钥密码系统来实现因特网安全的。Netscape的安全套接层的实现就利用了这篇文章中所讨论的技术。
RSA的公用密钥密码系统广泛地应用于计算机工业的认证和加密方面。Netscape得到RSA数据安全公司的许可可以使用公用密钥密码系统以及其它产品，尤其是认证方面的产品。
公用密钥加密技术使用不对称的密钥来加密和解密，每对密钥包含一个公钥和一个私钥，公钥是公开，而且广泛分布的，而私钥从来不公开，只有自己知道。
用公钥加密的数据只有私钥才能解密，相反的，用私钥加密的数据只有公钥才能解密，正是这种不对称性才使得公用密钥密码系统那么有用。
使用公用密钥密码系统进行认证
认证是一个验证身份的过程，目的是使一个实体能够确信对方是他所声称的实体。下面的例子包括Alice和Bob，并且向我们演示了如何使用公用密钥密码系统来轻易的验证身份。下面的 {something}key 表示something 已经用密钥 key 加密或解密。
假设Alice要认证Bob，Bob有一个密钥对，即一个公钥和一个私钥，Bob透露给Alice他的公钥（至于他是怎么做的将在以后讨论）。然后Alice产生一段随机的消息，然后把它发给Bob。
A-->B random--message
Bob用自己的私钥来加密这段消息，然后把加密后的消息返回给Alice。????????
B-->A {random--message}bobs--private--key
Alice接到了这段消息，然后用Bob以前发过来的公钥来解密。她把解密后的消息和原始的消息做比较，如果匹配的话，她就知道自己正在和Bob通信。一个入侵者应该不知道Bob的私钥，因此就不能正确的加密那段Alice要检查的随机消息。
但是，等一下，还有......
除非你确切的知道你在加密什么，否则用你的私钥加密一些东西，然后发给别人永远不是一件好事。这是因为加密后的数据可能会背叛你（记住，只有你能加密，因为只有你才有密钥）。
所以，我们不加密Alice发送的原始消息，取而代之的是，由Bob构造一个消息摘要，然后加密它。消息摘要是从随机消息中以某种方式提取出来的，并且具有以下特点：
摘要很难逆转，任何假冒Bob的人不能从摘要得到原始消息
假冒者无法找到具有相同摘要的不同消息
通过使用摘要，Bob能够保护自己。他首先计算出Alice发给他的随机消息的摘要并加密，然后把加密后的摘要返回给Alice，Alice可以计算出相同的摘要，通过解密Bob的消息然后对比一下就可以认证Bob的身份。
近一点......
刚才描述的技术称为数字签名。Bob为Alice产生的消息签名，这样做其实和加密Alice产生的随机消息一样危险。因此我们的认证协议需要一次以上的变形。部分（或者全部）的数据需要由Bob产生。
A-->B hello,are you bob?
B-->A Alice,This Is bob{digest[Alice,This Is Bob]}bobs-private-key
当Bob使用这个协议的时候，他知道自己发给Alice的是什么消息，并且不介意签名。他首先发送没有加密的消息“Alice,This Is Bob。”然后发送加密的摘要。Alice能够轻易的判断Bob是Bob，并且Bob没有签任何他不愿意签的东西。
分发公钥
Bob如何以一种可信赖的方式分发他的公钥呢？我们假设认证协议是这个样子的：
A-->B hello
B-->A Hi, I'm Bob, bobs-public-key
A-->B prove it
B-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key
如果使用这个协议的话，任何人都可以是Bob。你需要的只是一个公钥和私钥，你跟Alice慌称你是Bob，接着你用自己的公钥代替Bob的公钥，然后你通过用你的私钥加密的东西来证明，这样Alice就不能分辨出你不是Bob。
为了解决这个问题，标准化组织发明了一个叫做证书的东西，一个证书包括下面的一些内容：
证书发行者的名字
证书发送给的团体
主题的公钥
一些时间戳
证书是由证书发行者的私钥签名的，每个人都知道证书发行者的公钥（即证书发行者有一个证书，等等）。证书是一种把公钥绑定到名字的标准方式。
通过使用证书这种技术，每个人都可以通过检查Bob的证书来判断Bob是不是伪造的。假设Bob严格的控制着他的私钥，并且的确是Bob得到了他的证书，那么一切都好。下面是补偿协议：
A-->B hello
B-->A Hi, I'm Bob, bobs-certificate
A-->B prove it
B-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key
当Alice收到Bob的第一条消息，她可以检查证书，核实签名（如上，使用摘要和公钥加密），然后，核实主题（Bob的名字）来判断那是不是真的Bob。这样她就相信公钥是Bob的公钥，然后要求Bob证明他的身份。Bob则重新进行一次上面的相同过程，计算消息的摘要，签名之后发给Alice，Alice可以用从证书得到的公钥检查Bob的消息摘要，从而判断Bob的身份。
一个坏家伙 - 我们不妨叫他Mallet - 可以做下面的事情：
A-->M hello
M-->A Hi, I'm Bob, bobs-certificate
A-->M prove it
M-->A ????
但是Mallet在最后的消息中不能满足Alice。Mallet没有Bob的私钥，所以他无法构造一条使Alice相信来自Bob的消息。
交换秘密
一旦Alice认证了Bob，她就可以做另外一件事-她能发给一条只有Bob才能解码的消息：
A-->B {secret}bobs-public-key
发现这个秘密的唯一方法就是用Bob的私钥来解密上面的消息，交换秘密是公用密钥密码系统的另一种强大的用法。即使Alice和Bob之间的通信被监视，除了Bob，也没有人能够得到秘密。
这项技术加强了因特网的安全性，它把这个密码当作另一个密钥，但是这时它是对称性密码系统算法的密钥（如DES，RC4，IDEA）。Alice知道这个秘密，因为这是自己在发送给Bob之前产生的。Bob知道这个秘密，因为Bob有私钥，能够解密Alice的消息。因为他们都知道这个秘密，所以他们就可以初始化一个对称的密码算法然后开始传输用它加密的消息。下面是订正的协议：
A-->B hello
B-->A Hi, I'm Bob, bobs-certificate
A-->B prove it
B-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key
A-->B ok bob, here is a secret {secret} bobs-public-key
B-->A {some message}secret-key
secret-key 的计算取决于协议的定义，但是它可以简化成一个 secret 的副本。
你说什么？
Mallet的袋子里有很多诡计。虽然Mallet不能发现Alice和Bob交换的秘密，但是他可以干预并且破坏他们的对话。举例来说，如果Mallet位于Alice和Bob，他可以选择让大多数的消息返回以及向前继续传输没有改变，但是破坏了特定位的消息（这对他来说很容易，因为他知道Alice和Bob之间通信的协议）。
A-->M hello
M-->B hello
B-->M Hi, I'm Bob, bobs-certificate
M-->A Hi, I'm Bob, bobs-certificate
A-->M prove it
M-->B prove it
B-->M Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key
M-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key
A-->M ok bob, here is a secret {secret} bobs-public-key
M-->B ok bob, here is a secret {secret} bobs-public-key
B-->M {some message}secret-key
M-->A Garble[ {some message}secret-key ]
Mallet一直让数据没有改变的通过，直到Alice和Bob分享一个秘密。然后Mallet通过改变Bob发送给Alice的消息来进入这个方式中。这时候Alice是相信Bob的，因此她就可能相信这个改变的消息，然后按照它来做。注意Mallet并不知道这个秘密-他能做的所有事就是破坏用这个秘密的密钥加密的数据。他可能不能利用这个协议制造出一条有效的消息，但是下一次，他可能幸运一点。
为了防止这种破坏，Alice和Bob在他们的协议中引入了一种消息认证码（MAC）。MAC是根据秘密的密钥和传输的数据计算出来的，上面描述的摘要算法的属性正好可以用于构造抵抗Mallet的MAC功能。
MAC := Digest[ some message, secret ]????
因为Mallet不知道这个秘密的密钥，所以他无法计算出这个摘要的正确数值。即使Mallet随机的改变消息，如果摘要数据很大的话，他成功的可能性也很小。举例来说，通过使用MD5（RSA公司发明的一种很好的密码摘要算法），Alice和Bob能和他们的消息一起发送128位的MAC值。Mallet猜中这个正确的MAC值的几率是18,446,744,073,709,551,616 分之1-也就是从来也不会猜出来。
下面是样本协议，又订正了一次：
A-->B hello
B-->A Hi, I'm Bob, bobs-certificate
A-->B prove it
B-->A {digest[Alice, This Is Bob] } bobs-private-key
ok bob, here is a secret {secret} bobs-public-key
{some message,MAC}secret-key
Mallet现在有麻烦了，Mallet可以改变任何的消息，但是MAC的计算将揭露他的欺诈行为。Alice和Bob能发现伪造的MAC值并停止会话，Mallet就不能伪造Bob的消息了。
这是什么时候的事？
最后的，但是同样重要的是要防范Mallet鹦鹉学舌。如果Mallet记录了会话的过程，他虽然可能不知道会话的内容，但是他可以重放这些会话。实际上，Mallet能在Alice和Bob之间做一些真正龌龊的事。解决的办法就是从会话的双方因如随机因素。
SSL基本结构的集中管理
在企业环境中,采用SSL协议的Web服务器的需求正在逐步增加, 需要更加强大和有效的SSL基本结构. 这篇文章分析了通过对SSL基本结构的集中管理来减少结构的复杂性和整体成本的方法.
当公司有强烈的要求将基于Web的应用程序整合到他们的商业系统的时候, 他们可以使用SSL协议来保护应用程序和用户之间的信息的交换..这篇文章分析了当前基于SSLWeb站点的可测量性问题和整合的细节,例如 DellTM PowerEdgeTM Load Balancing Server-BIG-IP? Powered(formerly Dell PowerApp.BIG-IP), 能与SSL管理进行整合.
评价普通SSL的实施?
一部分SSL的实施是基于软件的解决方案.在这种实施中, 服务器通过SSL连接与客户端连接然后在软件级别上执行加密和解密. SSL握手, 实际上是客户端和服务器端协商使用哪种运算法则和密钥, 是一个处理器的操作. 因为执行握手过程和运行应用程序需要消耗大量的资源因此连接到这台服务器上的客户端的数量受到限制. 如果想连接更多的客户端需要更多的能力更强的服务器.
第二种SSL的实施是通过添加额外独立的SSL加速卡实现的, 例如roadcom CryptoNetXM卡, 对于每个Web 服务器. SSL 通信量并不会对整个网络流量带来影响, 但是它加重了处理网络流量的服务器的负担. 使用加密方式通信的Web站点和Web应用程序可能会因为Web站点流量的增加而出现响应时间的延迟.为每个Web服务器增加SSL加速卡可以避免Web站点和Web应用程序出现这种延迟. 当SSL协商过程被SSL加速卡来进行处理后可以将服务器的处理器解脱出来用来处理其他的内容和应用程序.
为了管理更高级别的流量, 管理员能够将多个Web服务器组织成一个Web组(看 图1). 这个组中的每个Web服务器必须安装有内置的加速卡以便能够提供SSL握手的处理. 这种SSL基本结构比基于软件方式的SSL或使用加速卡的单个Web服务器的性能要好的多, 但是它也有以下的几个局限性.
图1：一个标准的SSL实施: Web服务器组
测量Web服务器组的局限性
因为许多服务器使用不同的加密技术来加密数据因此管理这样一个Web服务器组会花费比较大并比较复杂. 在一个传统的采用负载均衡的Web服务器阵列中, 每个处理加密数据的服务器要求有一个SSL加速卡和一个数字证书. 一个数字证书是被CA签署的一个电子认证标识. 在加密通信方面提供了身份一致性的验证.
为了从CA获得一个数字证书, 管理员必须创建一个公钥对和CSR, 然后提交这些项目给CA. 这个过程被Web组中的每个服务器重复进行. 数字证书仅仅是在有限的时间内是正确的,当证书过期后管理员还必须重新获得证书.
不但管理这些支持 SSL特性的服务器是耗时的、而且成本很高。技术的进步可以降低SSL 加速卡的成本，但是仍然很昂贵。并且每次认证到期后，都必须从CA 重新购买。这种花费成本极大的增加采购与管理支持SSL 特性的服务器成本。
将 SSL基础结构和BIG-IP整合在一起
一种集中和简单的管理SSL Web组的方式是通过Dell PowerEdge Load BalancingServer-BIG-IP Powered 实现负载均衡, 一般称之为BIG-IP. BIG-IP 是一个运行有BIG-IP 负载均衡软件的Dell PowerEdge服务器. 它通过SSL加速卡实现SSL的 off-loading 同时还可以实现应用层和IP层的负载均衡. 一般作为冗余对, 这个工具还提供了对关键Web结构的高可用性的保证.
通过允许SSL的终结,BIG-IP工具可以减少Web服务器组的管理性和成本. 使用SSL的终结,前端的BIG-IP加密从客户端接受的数据然后将它们发送到后端服务器. 后端服务器响应这个请求后将完成的请求发送给BIG-IP, BIG-IP再重新解密数据然后发送会客户端. 因为后台服务器并不是直接参与SSL的处理,它们不要求SSL硬件或数字证书;BIG-IP在只有考虑冗余性时才要求SSL硬件和数字证书. 在可测量性方面, BIG-IP工具每秒钟最多能够管理到800个加密处理事务. SSL证书的集中管理减少了Web服务器组的复杂性和整体拥有成本.
在Web服务器环境中实现BIG-IP
大多数的BIG-IP把前端配置成一个应用服务器阵列. 这些服务器可能组成了一个数据库,cache池, 防火墙, 邮件交换组, 虚拟专用网络, 或Web服务器组. 这一部分详细解释一下管理员如何实现BIG-IP冗余的,一个处于活动状态另一个则处于备用状态, 前端的Web服务器组包括了两类服务器, 一类满足SSL的处理,另一类进行内容的解密. 图 2 显示了BIG-IP实现的例子.
图2：使用BIG-IP实现SSL的集中管理
BIG-IP的网络设置
管理员必须首先配置BIG-IP对.使用Dell的快速部署工具, 管理员能配置基本的主机和网络信息, 例如VLAN, 主机名称,Web管理员的名称以及密码.
在这里例子中使用三个VLAN: 一个为外部的网络服务(自身的IP 153.142.10.111-112/255.255.255.0, 第二个 IP 153.142.10.115)另外两个为内部网络服务自身的IP 192.168.10.101-102/255.255.255.0, 第二个 IP 192.168.10.100; 自身的IP10.10.10.101-102/255.255.255.0, 第二个 IP 10.10.10.100). 自身的 IP是每个BIG-IP与VLAN通信的IP地址. 第二个IP是由冗余对中的活动的BIG-IP使用的与其他的服务器中的BIG-IP连接. 在两个内部的网络中, 一个 (192.168.10.X) 是与提供安全处理的电子商务服务器连接,另一个与提供解密内容的Web服务器连接.
网络管理员是在配置初始时定义的, 能通过任何网络访问BIG-IP配置工具. 这个基于Web的工具允许管理员创建缓冲池和虚拟服务器以及管理节点.管理员也可以通过在一个内部网络中的主机的浏览器中输入https://192.168.10.100/ 或https://10.10.10.100/来访问这个活动的BIG-IP的配置工具.
一旦连接到配置工具, 管理员能够将后台的服务器组织到两个分别称为SECURE 和WEB 的不同的缓冲池中. SECURE 缓冲池包括IP地址为192.168.10.X 的服务器, 这种服务器能够运行应用程序和处理器从客户端收到的请求. WEB缓冲池由IP地址为10.10.10.X 的Web服务器组成, 这种服务器进行有规则的数据操作.在BIG-IP上创建两个虚拟的服务器: VS1(153.142.10.101) 驻留在前端的SECURE缓冲池中,而VS2 (153.142.10.102) 驻留在前端的WEB缓冲池中. VS1和VS2的DNS名称分别为https://buy.compxyz.com 和http://www.compxyz.com. 管理员现在可以通过将冗余的BIG-IP与活动的BIG-IP进行同步以便它们能够保持相同的状态.
当完成了BIG-IP系统的配置后, 管理员改变了后台Web服务器的默认网关以便使它指向BIG-IP的内部接口. 为了完成这个任务, 管理员将电子商务服务器的默认网关改为192.168.10.100 ,将Web服务器的默认网关改为10.10.10.10
配置SSL终结
为了配置SSL 终结,管理员必须获得由CA认证的证书并架设一个SSL代理. 管理员使用配置工具产生一个CSR并将它提交给CA. 当接收到一个正确的证书后, 管理员将它安装到一个BIG-IP上.
当在BIG-IP对上安装完了证书后, 管理员改变VS1的地址（就是驻留在前端的SECURE 池中的）为127.0.0.1. 管理员然后创建一个SSL代理给它分配一个IP地址为153.142.10.100; 它的目标虚拟服务器是VS1. 客户端也能够通过https://153.142.10.100/访问这个安全站点.当加密数据到达IP地址为153.142.10.100的SSL代理后,它首先解密,然后发送到VS1, 并最终转到SECURE 缓冲池.
提供持续性工作
配置的最后的步骤是提供这个Web服务器组的持续运行.因为BIG-IP解密所有的数据,更多的持续性选项变得可用. BIG-IP能够持续的检测信息的 HTTP报头例如SSL 任务IDs 或 HTTPcookies. 更新的MicrosoftIE浏览器 包括了一个安全功能,能够重新判断Web 服务器上的SSL任务的.
由于 BIG-IP 可以解密所有数据，因此就可以应用更多可用选项。BIG-IP 可以检查HTTP 头并根据SSL 会话ID 或HHTP Cookies的信息完成连续执行操作。新版本的Microsoft? Internet Explorer 浏览器包含安全特性可以与Web服务器的SSL 会话 ID完成重新数据协商操作。该特性根据会话ID 持续运行因此不适合应用于电子商务Web站点，但是非常适用于负载均衡其它加密应用程序。
BIG-IP 工具提供了四种类型的基于HTTP cookie 的persistence:插入模式, 重写模式,被动模式, 和 细分模式 mode. 在插入模式中, BIG-IP创建和写cookie到服务器响应的HTTP报头中. 在重写模式中, 服务器创建cookie 但是被会被BIG-IP覆盖. 在被动模式中, 后台服务器创建cookie, 这中间包括了足够的供BIG-IP负载均衡流量的使用的信息.在细分模式中,BIG-IP 创建一个cookie的细分以便返回的通信能够被传送到负载均衡组中的正确的服务器中.
为了避免对后台服务器的任何重新配置, 管理员选择插入模式cookie. 当一个客户返回到一个Web 站点时, 他通过cookie 就已经驻留在BIG-IP中了.该站点的信息就已经存储在cookie 中, 当客户下次再访问这个站点时会很快的显示出来了. 管理员通过persistence 功能可以提供一个完整的电子商务站点了.
发现BIG-IP另外的好处
BIG-IP工具提供了几个SSL实施之外的功能.它能负载均衡各种不同类型的应用程序,,或后台数据库. 在一个单一的Web组中, 一个BIG-IP也能检测进入的通信的HTTP的报头然后将它们直接发送给不同类的服务器.
使用BIG-IP进行集中的SSL管理
Dell PowerEdge LoadBalancing Server-BIG-IP Powered 提供了一种性价比很高的方法来管理当今复杂的Web服务器结构中的Web站点的加密性.通过结合SSL证书管理, BIG-IP 帮助我们减少了复杂性和整体拥有成本; 通过对SSL流量的负载均衡, BIG-IP增加了Web站点的性能.
SSL通讯安全代理简介
一、SSL通讯安全代理简介
SSL（Secure SocketsLayer，安全套接层）是由Netscape公司开发的网络安全传输协议，是目前INTERNET上点到点之间尤其是Web浏览器与服务器之间进行安全数据通讯所采用的最主要的协议。由于SSL具有应用面广、实施成本低、安全高效、操作简单等优点，它已成为电子商务系统中应用得最广泛的协议，例如目前美国的大多数电子商务应用系统都是基于SSL协议的。 由于美国政府禁止40位以上的加密算法出口，多数流行软件（如Web浏览器和服务器）的国际版本只支持40位以下的弱加密算法，为此杭州核新软件技术有限公司独立开发了具有自主知识产权的SSL安全代理系统，该系统全面实现SSL3.0规范，支持128位以上的高强度加密算法。该系统于1999年12月通过了中国国家信息安全测评认证中心的测试、检验，获得国家信息安全产品型号证书认证。（注册号：CNISTEC1999TYP024）
核新SSL安全代理的基本工作原理是：核新SSL安全代理软件与Web浏览器安装在客户电脑上（如图一），当浏览器要与远端Web服务器建立安全连接时，它向安全代理发出请求，由安全代理负责与远端Web服务器建立连接。连接建立后，浏览器与服务器之间的数据传输是经过安全代理转发完成的。浏览器与安全代理之间的数据传输是用浏览器本身支持的40位以下的弱加密算法加密的，而安全代理与远端Web服务器之间的数据传输则是用高强度的数据加密算法加密的。
核新SSL安全代理实现了用户电脑与券商服务器之间信息传输的高强度加密，解除了重要资料被黑客破译纂改的顾虑。
二、 SSL安全代理用户端系统配置?
一般用户在SSL安全代理安装时，可选择缺省的系统配置，即可获得较好的安全保障。如果用户有特殊要求，请按下列说明进行配置。您也可以在以后的使用过程中通过用户界面改变某些系统配置。
打开系统配置界面的方法有两种：一是单击主窗口的"系统"菜单，然后单击"选项"菜单项；二是单击快捷菜单的"系统选项"菜单项。
系统配置可分为两类：通讯方面的设置和加密算法方面的设置，分别对应窗口中的两个属性页。
1、通讯设置
通讯设置的画面（如下图）所示
|
1．1 SSL安全代理监听端口
Web浏览器在访问安全信息时，连接到该端口。缺省设为9999。如果您改变了该端口，应同时改变Web浏览器的安全代理设置。假设您将该端口设为9000，则浏览器的安全代理应设为127.0.0.1:9000。下面以IE 4.0中文版和Netscape 4.03中文版为例介绍浏览器的安全代理设置方法。
IE浏览器：单击"查看"菜单，然后单击"Internet选项"菜单项，打开"Internet选项"窗口。在窗口中选择"连接"属性页，在代理服务器一栏中选取"通过代理服务器访问Internet"，然后单击"高级"按钮打开"代理服务器设置"窗口。在Secure一栏中填入安全代理的IP地址和端口号(如下图)。
Netscape浏览器：单击"编辑"菜单，然后单击"首选项"菜单项，打开"首选项"窗口。在分类目录中双击"高级"，然后单击"代理服务器"；在窗口的右边选取"手动配置代理服务器"，然后单击"查看"按钮，打开"手动代理服务器配置"窗口。在"安全"一栏中填入安全代理的IP地址和端口号。（如下图）所示。
|
|
1．2最大并发连接数：为了提高效率，安全代理支持并发访问多个网页。最大并发连接数限定了并发访问的最大页面数。
1．3通过代理网关访问外部网络：有些电脑通过统一的出口访问外部网络，例如用一条DDN专线连接外部网络，在出口处安装代理网关（防火墙）。如果您的电脑属于这种情况，应选取此选项，并输入代理网关的IP地址和端口号。
1．4内置web server监听端口：安全代理有一内置Web服务器，通过此Web服务器您可以浏览联机文档和安装安全代理的证书。内置Web服务器监听端口的缺省设置为9998。
2．加密算法设置
加密算法的设置界面（如下图）所示。
加密算法列表中列出了安全代理支持的各种加密算法。本系统支持128位以上加密算法，如未收到券商的正式通知，请统一设为"使用全部加密算法"。
|
SSL和数字证书服务慨述
http://chinait.com.cn/blogs/chinait/default.aspx