SSLVPN入门之SSL协议.docx
《SSLVPN入门之SSL协议.docx》由会员分享，可在线阅读，更多相关《SSLVPN入门之SSL协议.docx（18页珍藏版）》请在冰豆网上搜索。
SSLVPN入门之SSL协议
SSLVPN入门之
SSL协议
作者
胡洋5021
撰写日期
2007年
版本
V2.0
最后修订
2011年
华为赛门铁克科技有限公司
版权所有不得复制
二零一一年
第1章概述
SSLVPN设备相关知识点的总结，希望能给初接触SSLVPN领域的同事一点帮助。
1.1什么是SSLVPN？
当你异地办公需获取公司内网资源时，不用再担心公司私有数据会在公网上所泄露；当你在家进行远程办公时，不用再担心不怀好意之人的监视；当你的企业分居两地共享业务数据时，也不必再担心你的竞争对手是否会得到你的商业秘密。
SSLVPN是解决远程用户访问敏感公司数据最简单最安全的技术。
通过对数据的压缩和加密传输，在公用网络建立一个临时的、安全的、稳定的隧道，从而实现在公网上实现隔离私有数据、达到私有网络的安全级别。
基本原理图如下所示：
1.2SSLVPN的优势
✓用户使用方便，不需要配置，可以立即使用；
✓无需客户端，直接使用内嵌的SSL协议，而且几乎所有的浏览器都支持SSL协议。
✓兼容性好，支持电脑、PDA、智能手机、3G手机等一系列终端设备及大量移动用户接入的应用。
1.3何时开始学习？
当你下定决心准备在这个领域扎根的时候，本文作为一篇入门手册，可以让你快速踏入SSLVPN的门槛。
不错，因为这是一篇入门手册，所以不须任何背景知识即可开始学习。
Ø建议：
先学习TCP/IP协议再学习本文，有事半功倍的效果。
1.4约定
本文默认使用以下约定，除非特别章节有特殊说明（只在有特殊说明的章节中有效）。
{something}key表示something已经用密钥key加密。
{secret}key表示secret已经用密钥key解密。
{secret}表示未解密的secret。
【message】表示发送或接收内容为message的报文，该报文内容不一定是加密的。
『operation』表示现在计算机中正进行哪些operation。
另外，我们依据密码学的传统，使用下列的命名，使复杂的过程变的简单和易于理解。
Alice表示客户、客户端、客户机、Client、发送者、Sender等。
Bob表示服务器、服务端、ISP、服务提供商、Server、接收（受）者、Receiver等。
Sam表示监听者、窃听者、间谍、监视者、Listener、侦听者、木马等。
Trudy表示阴谋家、干扰者、挑拨者、攻击者、入侵者、骗子、Hacker、Cracker等。
第2章SSL协议
2.1什么是SSL?
安全套接层协议（SSL，Security Socket Layer）是网景（Netscape）公司提出的基于WEB应用的安全协议，它包括：
服务器认证、客户认证（可选）、SSL链路上的数据完整性和SSL链路上的数据保密性。
旨在达到在公共网络（Internet）上安全保密地传输信息的目的，这种协议在WEB上获得了广泛的应用。
之后IETF（www.ietf.org）对SSL作了标准化，即RFC2246，并将其称为TLS（TransportLayerSecurity），从技术上讲，TLS1.0与SSL3.0的差别非常微小。
2.2SSL的体系结构
SSL协议是由SSL记录协议、握手协议、密钥更改协议和告警协议组成，它们共同为应用访问连接提供认证、加密和防篡改功能。
SSLHandshakeProtocol主要是用于服务器和客户之间的相互认证，协商加密算法和MAC（MessageAuthenticationCode）算法，用于生成在SSL记录中发送的加密密钥。
SSLChangeCipherSpecProtocol存在加密信号变换策略.该协议表示开始用当前协商好的加密策略压缩并加密报文.这个消息包含一个字节,它的值为1。
SSL警告协议主要是用于为对等实体传递与SSL相关的告警信息，包括警告、严重和重大等三类不同级别的告警信息。
SSL记录协议是为各种高层协议提供基本的安全服务，其工作机制如下：
应用程序消息被分割成可管理的数据块（可以选择压缩数据），并产生一个MAC信息，加密，插入新的文件头，最后在TCP中加以传输；接收端将收到的数据解密，做身份验证、解压缩、重组数据报然后交给高层应用进行处理。
2.3SSL握手
请先观察上图，这是一张使用步骤命名的握手图，在下一部分解析SSL协议时，将说明每一步骤的组成以及它们是通过何种方法生成的。
ClientHello：
客户端发起会话请求，并发送客户端支持的密码算法列表和一个随机数。
ServerHello：
从ClientHello传过来的密码算法列表中选择一套自己也支持的算法和一个随机数。
ServerCertificate：
服务端证书（证书将在后面的文章中讲解）。
该项为可选项，因为服务端可能没有从CA申请自己的证书。
证书中包含服务端信息和特定的publickey。
ServerKeyExchange：
若服务端没有证书，将产生一个短期publickey参数（不是publickey，是publickey参数，根据算法方案的不同，处理也不尽相同）。
CertificateRequest：
要求客户端发送客户证书。
该项是可选的，工商银行在网上交易时，使用的U盾中存储的就是客户证书，以验证客户身份。
而工商银行的站点，则不需要客户端证书。
ServerHelloDone：
服务端表示自己（对客户端）发言完毕，发送该报文后服务端将等待客户端发言。
ClientCertificate：
客户端证书。
若服务端发送CertificateRequest则发送此证书，否则
不发送。
ClientKeyExchange：
客户端使用服务端的publickey来加密自己选择的
pre-mastersecret。
然后发送
【{pre-mastersecret}server-public-key，{mastersecret，handshakemessage}hmac】。
mastersecret通过以前发送的2次随机数和pre-mastersecret计算得出，handshakemessage为前一次发送的消息直到ClientHello的所有消息。
CertificateVerify：
如果客户端发送了自己的证书，即进行了ClientCertificate这一步骤，则再发送一个数字签名（数字签名将在后面的文章中详细讲解）CertificateVerify信息来对证书进行校验。
若客户端未发送自己的证书，则无此步骤。
ChangeCipherSpec：
该步骤是一个信号：
使用加密策略传输。
该步骤是由ChangeCipherSpec协议进行的，这个协议表示开始使用当前已协商好的加密策略进行加密和压缩报文，这个消息只有1个字节，这个字节的值是1。
Finished：
在ChangeCipherSpec信号发送完毕后会被立即发送，而接收端接收到这个报文后，会校验这个报文加密是否正确。
因为双方都知道它的值是1，以此确定双方加解密的密钥是正确可用的。
2.4实例
下面我们通过一个实例来彻底理解这个过程。
一天傍晚，Alice在花园中散步，看见了一个黑影手里拿着一个亮晶晶的东西。
那是一串钻石项链。
家里只有一个人能够买的起钻石项链，肯定是管家Sam偷了主人Bob的钻石项链！
Alice必须马上告诉Bob，但是她怎么才能通知Bob而不被Sam发现呢？
如果打电话给Bob，Sam可能会在另一个分机上偷听，如果用信鸽并将消息栓到它的脚上，Bob
又怎么能知道是Alice发送的信息呢？
他说不定会以为是Trudy故意陷害Sam，因为Sam拒绝了她的求爱。
那么，Alice必须能够发送只有Bob可以看懂的消息给Bob，这样即使别人能够看到她发送的消息也无所谓。
另外，当Bob接收到消息的时候，他必须能够识别出该消息确实是Alice发送的，而且没有人能够在Alice发送消息和Bob接收消息之间篡改信息。
下面我们看一下Alice和Bob之间是如何对话的。
A→BBob，我想和你安全的通话，我这里的对称加密算法有DES、RC5，密钥交换算法有RSA、DH，摘要算法有MD5、SHA。
B→A我们用DES－RSA－SHA这对组合好了。
这是我的证书，里面有我的名字和publickey，你拿去验证一下我的身份
『把证书发给Alice』
我说完了，轮到你发言了。
A→B『查看证书上Bob的名字是否无误，并通过手头早已有的CA的证书验证了Bob的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了Bob的publickey的真实性』
『产生一份预备主秘密（pre-mastersecret），这份预备主秘密处理后将称为主秘密（mastersecret），加密初始化向量（IV）和完整性保护密钥（HMACkey）。
将这份秘密消息用Bob的publickey加密，封装成称作ClientKeyExchange的消息。
由于用了Bob的publickey，保证了第三方无法窃听』
我生成了一份预备主秘密，并用你的publickey加密了，给你
『把ClientKeyExchange发给Bob』
注意，下面我就要用加密的办法给你发消息了！
『将预备主秘密进行处理，计算出主秘密，然后通过主秘密生成加密密钥（secretkey），加密初始化向量和完整性保护密钥』
{我说完了}
B→A『用自己的privatekey将ClientKeyExchange中的预备主秘密解密出来，然后将预备主秘密进行处理，计算出主秘密，然后通过主秘密生成加密密钥，加密初始化向量和完整性保护密钥，这时双方已经安全的协商出一套加密办法了』
注意，我也要开始用加密的办法给你发消息了！
{我说完了}
A→B{我的秘密是...}
B→A{放心，其它人不会听到的...}
哈哈，大家看到这里是不是感到豁然开朗呢？
呵呵，不要着急，这只是对SSL协议的一个简单理解，下一部分我们就要开始解析SSL协议，将SSL协议完整的解剖放在你面前。
2.5解析SSL
在本节，我们的主要目的是解析SSL协议，暂且先忽略掉身份验证的各种细节，重点研究一下SSL的通信。
如图：
首先，Alice发起与Bob的连接，然后Bob把自己的证书发送给Alice。
Alice校验Bob的证书之后，从中提取出Bob的publickey，然后选择一个用来计算mastersecret的随机数S，将其用Bob的publickey加密后发送给Bob。
接着，双方会使用secretkey对会话数据和完整性保护实施加密。
这样实际上需要6个秘密值（对于连接的每个方向，要计算完整性保护密钥，secretkey和IV）。
消息1：
Alice发起会话请求，并发送她所支持的密码算法的列表以及一个随机数RAlice，该随机数将用作计算masterkey的参数。
消息2：
Bob把自己的证书和一个随机数RBob发送给Alice，同时在密码算法列表中选择一种自己也支持的算法来响应Alice。
随机数同样是用来计算masterkey的参数。
消息3：
Alice选择一个随机数S（pre-mastersecret），将其用Bob的publickey加密，接着计算出K（masterkey）和握手消息（直至ClientHello的所有握手消息，但不包括本条消息）的HMAC值，一起发送给Bob。
一来可以证明她知道secretkey，二来可以防止Trudy对握手消息进行篡改。
用于数据发送的密钥称为写密钥，用于数据接收的密钥称为读密钥。
打个比方：
Bob的写secretkey是Alice的读secretkey。
在第一次消息交换中发送的秘密值S是预备主秘密（pre-mastersecret）。
由S和两个随机数R计算后得到主秘密K（mastersecret），即K=f（S,RAlice,RBob）。
对于每个连接，K与两个随机数R计算后，生成用于该连接（每个方向3个：
secretkey，完整性保护密钥和
IV）的6个密钥，即每个密钥为gi=f（K,RAlice,RBob）。
因本文重点是SSL而不是密码学，再向下深入，其复杂的算法真是让人目瞪口呆，估计得数学系研究生毕业，然后再学习编程并对程序设计十分了解，且有多年算法编写经验才能搞明白这些算法吧。
（当时看的我脸都绿了，绝对真事，室友作证）
消息4：
Bob发送先前的所有握手消息的HMAC值，再用secretkey加密，Bob的写完整性保护密钥进行保护。
Bob通过这个消息告诉对方，他知道secretkey，并确定先前的握手消息未被篡改。
因为secretkey是用S进行推导计算出来的，因此也就证明了他知道Bob的privatekey，证明了他就是真实的Bob，因为只有Bob的privatekey可以正确解密Bob的publickey。
至此，Alice完成了对Bob的认证，但是Bob并没有对Alice进行认证。
在目前的应用中很少使用双向认证。
从理论上讲，SSL/TLS可以进行双向认证，比如网上银行。
最常见的情况是，如果服务器上的应用程序想认证客户，它通常会要求用户在secretkey的保护下，把用户的用户名和口令发送过来进行认证，比如我们的SecEntry。
另外，美国政府允许在出口的客户端软件在与处理金融交易的服务器通信时使用高强度加密的密码算法。
但是，必须是在服务器证书中指明该服务器允许客户端与之进行高强度保密通信的情况下，客户端才能使用高强度加密算法。
Netscape和Microsoft的浏览器都实现了这个概念，但Netscape称它为Step-Up，Microsoft称它为SGC。
所以在使用Step-Up时，Alice开始只能提供弱密码套件，Bob选择一套，然后建立40bit的密钥g1。
但是Alice发现Bob证书中的存在Step-Up扩展，于是她继续进行另一个握手，这次握手是受g1保护的。
在新的握手中，Alice提议用强密码套件，Bob选择一套，然后握手结束，这次两者商定了高强度的密钥g2。
然后，Alice给Bob发送ChangeCipherSpec消息，指示从弱密码套件和密钥g1变为强密码套件和密钥g2。
Step-Up不需要任何特殊的代码支持。
在使用SGC的情况下，除了要求服务器拥有SGC证书外，还必须有支持SGC交换的代码。
Alice提供弱密码套件，Bob选择一套，并发送证书。
Alice发现了证书中的SGC扩展，然后Alice会发送“ClientHello”信息，该信息包含的是强密码套件。
如果服务器没有支持SGC的代码，它就会变糊涂：
“干嘛又发ClientHello”？
2.6记录的加密方式
哈哈，看完了上一节，大家终于对SSL有一个透彻的了解了吧？
“太复杂了，我没搞清楚报文的加密”。
没关系，看完下面的内容，想不清楚都难。
序列号只在进行HMAC算法时使用，不会被发送。
序列号用来防止会话重播，不需要被发送。
若发送序列号，SSL是运行在可靠的TCP协议之上的，TCP失败或者数据报丢失、数据包重新排序及重复发送数据包等情况时，通信双方会发现序列号不一致，完整性校验就会失败，从而导致后续一连串的失败。
填充字段是在使用分组算法时，需要把|记录数据|HMAC|填充为分组长度的倍数。
2.7握手消息
在一条Handshake记录中，即可以只存在一条消息，比如只包含ServerHello或Certificate或CertificateRequest或ServerHelloDone。
也可以存在多条消息，比如一条handshake中包含ServerHello、Certificate、CertificateRequest和ServerHelloDone。
下面是握手消息的报文结构。
左边一栏为字节数注释（v表示可变），右边是报文格式。
ClientHello消息：
1
类型＝1
3
长度
2
版本号
32
随机数（RAlice）
1
session_id的长度（如果不存在session_id则为0）
v
session_id
2
密钥套件列表的长度
v
密钥套件列表，每个套件两个字节
1
压缩方法列表的长度
v
压缩方法列表，每种方法一个字节
ServerHello消息：
1
类型＝2
3
长度
2
版本号
32
随机数（RBob）
1
session_id的长度（如果不存在session_id则为0）
v
session_id
2
所选择的密钥套件
1
所选择的压缩方法
ServerHelloDone消息：
1
类型＝14
3
长度＝0
ClientKeyExchange消息：
1
类型＝16
3
长度
2
长度（SSLv3中没有，TLS中有）（取决于所使用的算法，有些算法此处无用）
v
加密的pre-mastersecret
Certificate消息：
1
类型＝11
3
长度
3
长度（不必要的，冗余的）
3
证书列表的长度
v
第一个证书
v
多个<3字节证书长度，证书>对（若发送多个证书）
ServerKeyExchange消息：
1
类型＝12
3
长度
2
模数的长度
v
模数
2
指数的长度
v
指数
2
签名的长度
v
签名
CertificateRequest消息：
1
类型＝13
3
长度
1
密钥类型列表的长度
v
密钥类型列表（每种类型1个字节）
2
CA名称列表的长度
2
第一个CA的名称的长度
v
第一个CA的名称
2
第二个CA的名称的长度
v
第二个CA的名称
2
第三个CA的名称的长度
v
第三个CA的名称
2
......
v
最后一个CA的名称的长度
2
最后一个CA的名称
CertificateVerify消息：
1
类型＝15
3
长度
2
签名的长度
v
签名
ChangeCipherSpec记录：
1
类型＝20
2
版本号
2
长度（设置为1）
1
ChangeCipherSpec类型（设置为1）
HandshakeFinished消息：
1
类型＝20
3
长度（等于36或12）
36/12
摘要
Alert记录：
Alert记录用于通知通信中的另一方发生了某种状况。
多数Alert记录是Error消息，严重程度为1＝警告、2＝严重。
另外一种alert记录是终止（closure）消息，用于通知对方不再有数据发送。
2.8模拟SSL的实现
好了，现在我们来看一些必备知识，以及汉语术语的叫法：
1，公钥（publickey）和私钥（privatekey）成对出现
2，公开的密钥叫公钥，只有自己知道的叫私钥
3，用公钥加密的数据只有对应的私钥可以解密
4，用私钥加密的数据只有对应的公钥可以解密
5，如果可以用公钥解密，则必然是对应的私钥加的密
6，如果可以用私钥解密，则必然是对应的公钥加的密
7，密钥是双方共享的私钥，密钥也叫会话密钥、加密密钥
8，密钥加的密，同样可以用密钥解密
9，公钥加密用私钥解密，用私钥加密用公钥解密，叫不对称算法
10，密钥加密用同一个密钥解密，叫对称算法
现在我们来模拟实现SSL的过程：
假设Alice要认证Bob，Bob有一个密钥对，即一个公钥和一个私钥，Bob透露给Alice他的公钥。
然后Alice产生一段随机的消息，然后把它发给Bob。
A→Brandom--message
Bob用自己的私钥来加密这段消息，然后把加密后的消息返回给Alice。
B→A{random--message}bob-private-key
Alice接到了这段消息，然后用Bob以前发过来的公钥来解密。
她把解密后的消息和原始的消息做比较，如果匹配的话，她就知道自己正在和Bob通信。
Sam或是Trudy应该不知道Bob的私钥，因此就不能正确的加密那段Alice要检查的随机消息。
“不对不对，握手流程不是这样的”
的确，私钥（privatekey）是只有自己知道的，别人不知道，只有自己能够加密，加密了一些数据然后发给别人，别人怎么知道自己加密的是什么东东呢？
所以我们要告诉对方我们加密了什么，然后对方拿着我们的公钥，把加密的东东解开看看，是不是我们告诉过他的东东。
如果一致，那么就可以确认我们的身份，因为只有我们知道私钥，而想解开我们的私钥加密的东东，就必须使用我们的公钥——请看下集《数字签名》。
结语
本文历时1个多月，终于编写完成，期间参考数篇SSL领域的权威英语原版资料，深入学习钻研，充分理解后落笔，且力求表达英文原意。
望本文可以成为我司SSLVPN入门首选入门手册。
参考文献
1．RFC2246TheTLSProtocolVersion1.0
2．RFC4346TheTransportLayerSecurity（TLS）ProtocolVersion1.1
3．NetscapeSSL_2
4．NetscapeSSL_3
5．TCP/IPIllustratedVolume1:
TheProtocols
6．SSLandTLS:
DesigningandBuildingSecureSystems
7．NetworkSecurity:
PrivateCommunicationinaPublicWorldSecondEdition
8．ServerGatedCryptographyandStep-Up
9．RandomIV
10．UseHMACAlgorithm
11．SecretkeysExtension
12．UserCertificate
13．MSDN
14．IBMTechnologyLibrary
15．GOOGLE
-温馨提示：
如不慎侵犯了您的权益，可联系文库删除处理，感谢您的关注！
升级会员 