SSL协议基础知识(转载)
原文：http://210.40.7.188/NEW/SSL-SET/0_02.htm
第二章 SSL协议基础知识
2.1 SSL协议历史
1994年，网景公司设计了安全套接层（SSL）协议，最初，仅仅是为了在web浏览器和web服务器之间安全地传输私人数据如信用卡卡号，密码等。在1994年底，网景推出了SSL版本2，并第一次载入了一个商业浏览器——Netscape Navigator。1995推出了版本3，在1996年，一个国际标准组织（IETF）接管了SSL的工作，并将SSL协议重命名为安全传输层（TLS），它是建立在SSLV3基础之上的。在1999年，IETF推出TLS的版本1.0 (The TLS Protocol, Version 1.0, RFC 2246)。
2.2 SSL协议简介
安全套接层协议（SSL，Security Socket Layer）是网景（Netscape）公司提出的基于WEB应用的安全协议，它是一种在两台机器之间提供安全通道的协议。它具有保护传输数据以及识别通信机器的功能。安全通道是透明的，意思是说它对传输的数据不加变更。客户与服务器之间的数据是经过加密的，一端写入数据完全是另一端读取的内容。透明性使得几乎所有基于TCP的协议稍加改动就可以在SSL上运行，非常方便。
SSL安全协议主要提供三方面的服务：
（1） 认证用户和服务器, 使得它们能够确信数据将被发送到正确的客户机和服务器上；
（2） 加密数据以隐藏被传送的数据；
（3） 维护数据的完整性, 确保数据在传输过程中不被改变。
在数据传播之前，加密技术通过将数据转变成看起来毫无意义的内容来保护数据不被非法使用。其过程是：数据在一端 (客户端或者服务器端) 被加密，传输，再在另一端解密。
安全套接字层协议是美国Netscape公司于1996年推出的一种著名安全协议。此协议是一个建立在TCP／IP协议之上提供客户和服务器双方网络应用安全通讯的开放式协议。
SSL协议建立在传送层和应用层之间，由记录协议和握手协议组成，其中记录协议在握手协议下端。
SL记录协议主要完成分组和组合，压缩和解压缩，以及消息认证和加密等功能。
SSL握手协议描述安全连接建立的过程，在客户和服务器传送应用层数据之前，完成加密算法，密钥加密密钥算法的确定，以及交换预主密钥，并最后产生相应的客户和服务器MAC秘密、会话加密密钥等功能，协议由下面不同的连续过程组成：
其中，*表示由情况而定，不一定要传送的项：[]表示可以自由选择的项。通过这几个图，基本上清楚了SSL协议，下面我们就看一看托管加密标准（EES），它是由防窜扰的Clipper芯片来实现的，一个Clipper芯片安装了一个固定的操作程序和SKIPJACK算法，还有一个唯一的设备密钥UKA，一个族密钥FK。
EES的加密和解密过程是这样的：假设你刚刚得到一个Clipper芯片，想牛刀小试，于是你打算给你表姐传送一条加密消息w，你首先用密钥分配协议和你表姐交换会话密钥，然后把会话密钥k 和消息w输入Chipper芯片A。芯片A就产生两部分信息E（k,M）和LEAF（A，k），其中E（k,M）是用SKIPJACK算法和密钥k对消息w加密所得的密文，LEAF（A，k）是用族密钥FK对一个128比特串加密的密文，其形式如下：
LEAF（A，k）=E（FK，D（A，k））
D（A，k）=<IDA，E（UKA，k），f（A，k，IV）>
其中 D（A，k）含有一个32bit的身份号IDA（是你的），一个80bit长的会话密钥加密拷贝，一个16bit长的校验和f（A，k，IV），当你表姐收到这个一团乱码的消息后，虽然知道会话密钥A，但不知道SKIPJACK算法，还是无法解密，所以她只有利用Chipper芯片才能解密。每个Chipper芯片的解密过程被按照如下程序固化：
1、clipper芯片首先使用族密钥FK解密 LEAF（A，k）得到D（A，k）=<IDA，E（UKA，k），f（A，k，IV）>
2、clipper芯片计算f（A，k，IV），并把结果与收到的校验和相比较，如果相等，则转到下一步，否则停止计算。
3、clipper芯片使用SKIPJACK算法和密钥汾对E（k，M）解密，恢复出明文w。
2.3 需要的加密方面的基础知识
了解SSL原理需要一点点加密的概念，这里把需要的概念做一下简单阐述：
加密一般分为三类，对称加密，非对称加密及单向散列函数。
对称加密：又分分组密码和序列密码。
分组密码是将明文按一定的位长分组，明文组经过加密运算得到密文组，密文组经过解密运算 （加密运算的逆运算），还原成明文组。
序列密码是指利用少量的密钥（制乱元素）通过某种复杂的运算（密码算法）产生大量的伪随机位流，用于对明文位流的加密。
解密是指用同样的密钥和密码算法及与加密相同的伪随机位流，用以还原明文位流。
CBC(Cipher Block Chaining)模式这个词在分组密码中经常会用到，它是指一个明文分组在被加密之前要与前一个的密文分组进行异或运算。当加密算法用于此模式的时候除密钥外，还需协商一个初始化向量（IV），这个IV没有实际意义，只是在第一次计算的时候需要用到而已。采用这种模式的话安全性会有所提高。
分组密码的典型例子为DES,RC5,IDEA。
序列密码的典型例子为RC4。
公钥加密： 简单的说就是加密密钥与解密密钥不同，分私钥和公钥。这种方法大多用于密钥交换，RSA便是一个我们熟知的例子。
还有一个常用的称作DH，它只能用于密钥交换，不能用来加密。
单向散列函数：由于信道本身的干扰和人为的破坏，接受到的信息可能与原来发出的信息不同，一个通用的办法就是加入校验码。 单向散列函数便可用于此用途，一个典型的例子是我们熟知的MD5,它产生128位的摘要，在现实中用的更多的是安全散列算法（SHA），SHA的早期版本存在问题，目前用的实际是SHA－1，它可以产生160位的摘要，因此比128位散列更能有效抵抗穷举攻击。
由于单向散列的算法都是公开的，所以其它人可以先改动原文，再生成另外一份摘要。解决这个问题的办法可以通过HMAC（RFC 2104）,它包含了一个密钥，只有拥有相同密钥的人才能鉴别这个散列。
2.4 密钥协商过程
由于对称加密的速度比较慢，所以它一般用于密钥交换，双方通过公钥算法协商出一份密钥，然后通过对称加密来通信，当然，为了保证数据的完整性，在加密前要先经过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服务器端用自己的私钥解密后，会话密钥协商成功，双方可以用同一份会话密钥来通信了。
2.5 加密的计算
上一步讲了密钥的协商，但是还没有阐明是如何利用加密密钥，加密初始化向量和hmac的密钥来加密消息的。 其实其过程不过如此：
1 借助hmac的密钥，对明文的消息做安全的摘要处理，然后和明文放到一起。
2 借助加密密钥，加密初始化向量加密上面的消息。
2.6 SSL与TCP/IP族
所有版本的SSL与TLS都采用了相同的策略：它们在两个通信程序之间提供一条在其间传递任意应用数据的安全通道。从理论上讲，SSL连接非常类似于“保密的”TCP连接。从安全套接层这个名字就可以看出，目的就是为了让SSL连接像以TCP连接起来的套接字那样。
让SSL语义模仿TCP语义的首要目的是易于应用程序员的使用。依照这个目标，大多数SSL实现都提供了有意模仿最为流行的网络API，Berkeley,sockets 的应用编程接口（application program interface ,API）。下面是sockets API 与 SSL API 的比较：
sockets API openssl
int socket(int,int,int) SSL *SSL_new(SSL_CTX)
int connect(int,const struct sockaddr *,int) int SSL_connect(SSL *)
ssize_t write(int, const void *,size_t) int SSL_write(SSL *,char *,int)
ssize_t read (int ,void *,size_t) int SSL_read(SSL *,char *,int)
在理想状况下，从一个应用程序员的角度来看，可以将所有的socket 调用替换成SSL 调用而大体上获得所需的安全特性。甚至有可能与提供普通socket调用库的安全版本（初此之外与普通库没什么差别）进行链接来使应用获得安全特性。不幸的是，尽管这在某种程度上是可能的，但是SSL的语义与TCP的语义并不严格匹配，这就导致一些问题或混淆。图2.1描述了协议栈中SSL的位置，它正好位于应用层的下面，TCP的上面.
| 应用层 |
| TCP |
| IP |
| 应用层 |
| SSL |
| TCP |
| IP |
一般应用 使用SSL
SSL假定其下层的数据包发送机制是可靠的。写入网络的数据将依顺序发送给另一端的程序，不会出现丢包或重复发送的情况。从理论上讲，有许多传输协议都能提供此种服务，但在实际应用中，SSL几乎只是在TCP上运行，它不能在UDP或直接在IP上运行。
SSL依赖于可靠传输协议发送数据的特点一直是过去争论的焦点，而且已经存在有去除这种依赖性的尝试。总的来说，这总特点需要处理确认和重发超时问题，以便重发丢失的消息。微软的STLP和无线应用论坛的WTLS[WAP1999a]均为意图在数据报传输层如UDP上正确工作的SSL变种。
2.7 SSL握手
SSL握手有三个目的。第一，客户端与服务器需要就一组用于保护数据的算法达成一致。第二，它们需要确立一组由那些算法所使用的加密密钥。第三，握手还可以选择对客户端进行认证。我们先不讨论具体的协议消息，从整体上讨论握手过程。然后讲述如何将这一过程分解为具体的消息。
整个握手过程工作如下：
(1) 客户端将它所支持的算法列表连同一个密钥产生过程用作输入的随机数发送给服务器。
(2) 服务器根据从列表的内容中选择一种加密算法，并将其连同一份包含服务器公用密钥的证书发回给客户端。该证书还包含了用于认证目的的服务器标识，服务器同时还提供了一个作为密钥产生过程部分输入的随机数。
(3) 客户端对服务器的证书进行验证，并抽取服务器的公用密钥。然后，再产生一个称做pre_master_secret的随机密码串，并使服务器的公用密钥对其进行加密。最后，客户端将加密后的信息发送给服务器。
(4) 客户端与服务器端根据pre_master_secret以及客户端与服务器的随机数值独立计算出加密和MAC密钥。
(5) 客户端将所有握手消息的MAC值发送给服务器。
(6) 服务器将所有握手消息的MAC值发送给客户端。
那么，该过程达到了怎样的效果呢？还记得我们的两个目标是什么吗？第一，就一组算法达成一致。第二，确立一组加密密钥。第一和第二步实现了第一个目标。客户端告诉服务器它所支持的算法，而服务器选择其中一种算法。当客户端收到了服务器在第二步所发的消息时，它也会知道这种算法，所以双方现在就知道要使用什么算法了。
第二个目标，确立一组加密密钥是通过第二和第三步来实现的。在第2步服务器向客户端提供其证书，这样就可以允许客户端给服务器传送密码。经过第3步后，客户端与服务器都知道了pre_master_secret。客户端知道pre_master_secret是因为这是它产生的，而服务器则是通过解密而得到pre_master_secret的。
注意，第3步是握手过程中的关键一步。所有要被保护的数据都依赖于pre_master_secret的安全。原理非常简单：客户端使用服务器的公用密钥（从证书中抽取出来的）来加密共享密钥，而服务器使用私用密钥对共享密钥进行解密。握手的剩余步骤主要用于确保这种交换过程的安全进行。然后在第4步，客户端与服务器使用相同的密钥导出函数(key function,KDF)来产生master_secret,最后再次通过KDF使用master_secret来产生加密密钥。
第5与第6步用以防止握手本身遭受篡改。设想一个攻击者想要控制客户端和服务器所使用的算法。客户端提供多种算法的情况相当常见，某些强度弱而某些强度强，以便能够与仅支持弱强度算法的服务器进行通信。攻击者可以删除客户端在第1步所有高强度的算法，于是就迫使服务器选择一种弱强度算法。第5步和第6步的MAC交换就能阻止这种攻击，因为客户端的MAC是根据原始消息计算得出的，而服务器的MAC是根据攻击者修改过的消息计算得出的，这样经过检查就会发现不匹配。由于客户端与服务器所提供的随机数为密钥产生过程的输入，所以握手不会受到重放攻击的影响。这些消息是首个在新的加密算法与密钥下加密的消息。
因此，在此过程结束时，客户端与服务器已就使用的加密算法达成一致，并拥有了一组与那些算法一起使用的密钥。更重要的是，它们可以确信攻击者没有干扰握手过程，所以磋商过程反映了双方的真实意图。
握手消息
刚才所描述的每一步都需要通过一条或多条握手消息来实现。在此先简要地描述哪些消息与哪几步相对应，然后再在后面详细每条消息的内容。下图描述了各条消息：
图 ：SSL “握手”协议
这些消息的意思如下：
1. ClientHello：发送信息到服务器的客户端，这些信息如 SSL 协议版本、会话 ID 和密码组信息，如加密算法和能支持的密匙的大小。
2. ServerHello：选择最好密码组的服务器并发送这个消息给客户端。密码组包括客户端和服务器支持。
3. Certificate：服务器将包含其公钥的证书发送给客户端。这个消息是可选的，在服务器请求验证的时候会需要它。换句话说，证书用于向客户端确认服务器的身分。
4. Certificate Request: 这个消息仅在服务器请求客户端验证它自身的时候发送。多数电子商务应用不需要客户端对自身进行。
5. Server Key Exchange：如果证书包含了服务器的公钥不足以进行密匙交换，则发送该消息。
6. ServerHelloDone：这个消息通知客户端，服务器已经完成了交流过程的初始化。
7. Certificate：仅当服务器请求客户端对自己进行验证的时候发送。
8. Client Key Exchage：客户端产生一个密匙与服务器共享。如果使用 Rivest-Shamir-Adelman (RSA) 加密算法，客户端将使用服务器的公钥将密匙加密之后再发送给服务器。服务器使用自己的私钥或者密钥对消息进行解密以得到共享的密匙。现在，客户端和服务器共享着一个已经安全分发的密匙。
9. Certificate Verify：如果服务器请求验证客户端，这个消息允许服务器完成验证过程。
10. Change Cipher Spec：客户端要求服务器使用加密模式。
11. Finished：客户端告诉服务器它已经准备好安全通信了。
12. Change Cipher Spec：服务器要求客户端使用加密模式。
13. Finished：服务器告诉客户端它已经准备好安全通信了。这是 SSL “握手”结果的标志。
14. Encrypted Data：客户端和服务器现在可以开发在安全通信通道上进行加密信息的交流了。
2.8 SSL记录协议
到目前为止我们设法做到的就是对服务器进行认证并共享一些密钥资料。记住，将SSL放在首位的原因就是能够交换经过加密和认证的数据。握手的目的就是建立起使发送和接收受保护数据成为可能所需要的共享状态。在SSL中，实际的传输是使用SSL记录协议来实现的。
SSL记录协议是通过将数据流分割成一系列的片段并加以传输来工作的，其中对每个片段单独进行保护和传输。在接受方，对每条记录单独进行解密和验证。这种方案使得数据一经准备好就可以从连接的一端传送到另一端，并在接收到的即刻加以处理。
在传送片段之前，必须防止遭到攻击。可以通过计算数据的MAC来提供完整性保护。MAC与片段一起进行传输，并由接收实现加以验证。将MAC附加到片段的尾部，并对数据与MAC整合在一起的内容进行加密，以形成经过加密的负载（payload）。最后给负载装上头信息。头信息与经过加密的负载的连结称作记录（record），记录就是实际传输的内容。下图描述了传输过程。
记录头信息
记录头信息的工作就是为接收实现（receiving implementation）提供对记录进行解释所必需的信息。在实际应用中，它是指三种信息：内容类型、长度和SSL版本。长度字段可以让接收方知道他要从线路上读取多少字节才能对消息进行处理，版本号只是一项确保每一方使用所磋商的版本的冗余性检查。
内容类型字段标识消息类型。正如我们在前面所讨论的，若能在同一条受保护的通道上传输各种类型的信息则是非常方便的。尤其是在我们想要发送受保护的、表示错误与连接关闭的消息时。内容类型字段使得实现能够将这种管理信息与传送给高层应用的数据区分开来。
内容类型
SSL支持四种内容类型：applcation_data、alert、handshake和change_cipher_spec。使用SSL的软件发送和接收的所有数据都是以application_data类型来发送的。其他三种内容类型用于对通信进行管理，如完成握手和报告错误等。
内容类型alert主要用于报告各种类型的错误。大多数alert（警示）用于报告握手中出现的问题，但是也有一些指示在对记录试图进行解密或认证时发生的错误。Alert消息的其他用途时指示连接将要关闭，这对于阻止截断攻击时必需的。
内容类型handshake（不足为奇）用于承载握手消息。
Categorized in: Java · Tagged with: JSSE, SSL, TLS
(No Ratings Yet)
Loading ...
(
