SSL（Secure Sockets Layer ）协议与数字证书

 

1 SSL的概述 由于 Web上有时要传输重要或敏感的数据， Netscape公司在推出 Web浏览器首版的同时，提出了安全通信协议 SSL（ Secure Socket Layer）。 目的是在 Internet基础上提供一种基于会话加密和认证的安全协议。 SSL协议已成为 Internet上保密通讯的工业标准。现行 Web浏览器普遍将 HTTP和 SSL相结合，从而实现安全通信。   SSL协议有以下三个特性 : 保密性 。因为在握手协议定义了会话密钥后，所有的消息都被加密。 确认性 。因为尽管会话的客户端认证是可选的 ，但是服务器端始终是被认证的 。 可靠性 。因为传送的消息包括消息完整性检查 （使用 MAC）。 SSL或 TSL工作在 TCP层与 HTTP,FTP,SMTP之间 .   2 SSL的体系结构 SSL协议分为两层协议。       一层是 SSL记录协议（ SSL Record Protocol ），它建立在可靠的传输协议（如 TCP）之上，为更高层提供基本的安全服务，如提供数据封装、压缩、加密 等基本功能的支持。       另一层是建立在 SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。 它由三个协议组成： • SSL握手协议（ SSL Handshake Protocol ） • SSL修改密文规约协议（ SSL Change Cipher Spec Protocol ） • SSL告警协议（ SSL Alert Protocol ）     图：SSL 协议栈     SSL中协议中两个重要概念 ：       SSL连接（ connection ） ：在 OSI分层模型的定义中，连接是提供一种合适类型服务的传输。而 SSL的连接是点对点的关系。连接是暂时的，每一个连接和一个会话关联。       SSL会话（ session ） ：一个 SSL会话是在客户与服务器之间的一个关联。会话由握手协议创建。会话定义了一组可供多个连接共享的加密安全参数。会话用以避免为每一个连接提供新的安全参数所付出昂贵的代价。   ① 会话状态 由下列参数定义： 会话标识符 ：服务器选择的一个任意字节序列，用以标识一个活动的或可激活的会话状态。 对方证书 ：一个 X.509.v3证书。可为空。 压缩方法 ：加密前进行数据压缩的算法。 密文规约 ：指明数据体加密的算法 （无，或 DES等），以及用以计算 MAC散列算法 （如 MD5或 SHA-1）。还包括其它参数，如散列长度 ，主密码 （ 48位 C与 S之间共享的密钥）， 重新开始标志 （指明该会话是否能用于产生一个新连接）。   ② 连接状态 由下列参数定义：    服务器和客户的随机数：服务器和客户为每一个连接所选择的字节序列。 服务器写 MAC密码：一个密钥，用来对服务器发送的数据进行 MAC操作。 客户写 MAC密码：一个密钥，用来对客户发送的数据进行 MAC操作。 服务器写密钥：用于服务器进行数据加密，客户进行数据解密的对称加密密钥； 客户写密钥：用于客户进行数据加密，服务器 r进行数据解密的对称加密密钥； 初始化向量：当数据加密采用 CBC方式时，每一个密钥保持一个 IV。该字段首先由 SSL握手协议初始化，以后保留每次最后的密文数据块作为下一个记录的 IV。 序号：每一方为每一个连接的数据发送与接收维护单独的顺序号。当一方发送或接收一个修改的密文规约的报文时，序号置为 0，最大 264-1。   3 SSL记录协议 在 SSL协议中，所有的传输数据都被封装在记录中。记录是由记录头和长度不为 0的记录数据组成的。所有的 SSL通信包括握手消息、安全空白记录和应用数据都使用 SSL记录层。 SSL记录协议（ SSL Record Protocol）包括了记录头和记录数据格式的规定。 1.SSL记录头格式       SSL的记录头可以是两个或三个字节长的编码。 SSL记录头的包含的信息包括：记录头的长度、记录数据的长度、记录数据中是否有粘贴数据。 2.SSL记录数据的格式      SSL的记录数据包含三个部分： MAC(Message Authentication Code ) 数据、实际数据和粘贴数据 。 3.SSL记录协议操作      在 SSL的记录层完成对数据加密、解密和认证。操作过程如图所示：   SSL Record Protocol All SSL protocol messages move in records of up to 32,767 bytes. Each message has a header of either 2 or 3 bytes. The headers include a security escape function, a flag to indicate the existence of padding, and the length of the message (and possibly the padding.) A two byte header has no padding, a three byte header includes some padding.         The meaning of bits is as follows:    1 2 3 4 5 6 7 8                    +----------------+-----------------+----------------+ |# S Length      |  Length         | Padding length | +----------------+-----------------+----------------+   # is the number of bytes in the header         0 indicates a 3 byte header, max length 32,767 bytes.         1 indicates a 2 byte header, max length 16,383 bytes S indicates the presence of a security escape, although none are currently implemented. (Several suggestions for security escapes are in the weaknesses section.)   There is no version information within the SSL record header, although it is available in the handshake. Within a record, there are three components: MAC-DATA, Actual-data, and Padding-data. MAC is the Message Authentication Code , Actual-data is the actual data being sent, and Padding-data is padding. The MAC-DATA is a hash of a key, the data, padding, and a sequence number. The hash is chosen based on the cipher-choice. The key used is the (sender)-write-key, which is the same key as the (receiver)-read-key. When cipher-choice is not defined, there is no mac-data or padding-data. Padding is used to ensure that the data is a multiple of the block size when a block cipher is used . Padding data is always discarded after the MAC has been calculated. Sequence numbers are unsigned 32 bit integers incremented with each message sent. Sequence numbers wrap to zero after 0xFFFFFFFF. Each dialog direction has its own sequence number. Failure to authenticate, decrypt, or otherwise get correct answers in a crytpographic operation result in I/O errors, and a close of connection.   附： 主 密码的计算 主秘密 (master secret)的生成，它是从预主秘密衍生出来的。       当生成了一个预主秘密并且双方都知道它之后，就可以计算主秘密，用作共享秘密的主秘密是通过对许多先前的消息交接中的数据的杂凑计算构成的。 生成主密钥这些计算格式如下： Master_secret=       MD5（ pre-master-secret+SHA（ A+pre-master-secre+ClientHello.random+ServerHello.random））   + MD5（ pre-master-secret+SHA（ BB+pre-master-secre+ClientHello.random+ ServerHello.random））   + MD5（ pre-master-secret+SHA（ BB+pre-master-secre+ClientHello.random+    ServerHello.random））     4 修改密文规约协议 修改密文规约协议（ SSL Change Cipher Spec Protocol）是简单的特定 SSL的协议。       目的：为表示密码策略的变化 。该协议包括一个单一的消息，它由记录层按照密码规约中所指定的方式进行加密和压缩。在完成握手协议之前，客户端和服务器都要 发送这一消息，以便通知对方其后的记录将用刚刚协商的密码规范以及相关联的密钥来保护。所有意外的更改密码规范消息都将生成一个 “意外消息 （ unexpected_message） ”警告。   5 告警协议 警告协议将警告消息以及它们的严重程度传递给 SSL会话中的主体。就像由记录层处理的应用层数据一样，警告消息也用当前连接状态所指定的方式来压缩和加密。      当任何一方检测到一个错误时，检测的一方就向另一方发送一个消息。如果警告消息有一个致命的后果，则通信的双方应立即关闭连接。双方都需要忘记任何与该失败的连接相关联的会话标识符、密钥和秘密 。对于所有的非致命错误，双方可以缓存信息以恢复该连接。   6 握手协议 SSL握手协议负责建立当前会话状态的参数。双方协商一个协议版本，选择密码算法，互相认证（不是必需的），并且使用公钥加密技术通过一系列交换的消息在客户端和服务器之间生成共享密钥。       SSL握手协议动作包含四个阶段。握手协议的动作如图所示。 第一阶段 建立安全能力 （ 1） Client Hello消息 （ 2） Server Hello消息 第二阶段 服务器认证和密钥交换 （ 1） Server Certificate消息 （ 2） Server Key Exchange消息 （ 3） Certificate Request消息 （ 4） Server Hello Done消息 第三阶段 客户认证和密钥交换 （ 1） Client Certificate消息 （ 2） Client Key Exchange消息 （ 3） Certificate Verify消息 第四阶段 结束握手 （ 1） Change Cipher Spec 消息 （ 2） Finished消息 （ 3） Change Cipher Spec 消息 （ 4） Finished消息 握手交互流程： C->S: 请求一个受保护的页面 S->C：返回附带公钥的证书 C：检查证书是否授信，不授信则提示客户端 C：产生一临时的对称密钥，并用服务端的公钥加密 C：用服务端的公钥加密需要请求的地址和附加的参数 C->S:将加密过的密钥和请求内容发送给服务端 S：首先用私钥解密获得两者交互的临时对称密钥 S->C：将请求的内容通过临时对称密钥加密返回给客户端 C->S：通过临时对称密钥开始交互 S->C：通过临时对称密钥加密并返回内容         数字证书         数字证书称为数字标识 （ Digital Certificate ， Digital ID）。它提供了一种在 Internet 上身份验证的方式，是用来标志和证明网络通信双方身份的数字信息文件，与司机驾照或日常生活中的身份证相似。数字证书它是由一个由权威机构即 CA机构，又 称为证书授权（ Certificate Authority）中心发行的，人们可以在交往中用它来识别对方的身份。在网上进行电子商务活动时，交易双方需要使用数字证书来表明自己的身份，并使用 数字证书来进行有关交易操作。通俗地讲，数字证书就是个人或单位在 Internet上的身份证。 　　 　　比较专业的数字证书定义是，数 字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。一般 情况下证书中还包括密钥的有效时间，发证机关（证书授权中心）的名称，该证书的序列号等信息，证书的格式遵循相关国际标准。有了数字证书，我们在网络上就 可以畅通无阻。如图( 数字证书授权中心) 是一个数字证书在网络应用中的原理图。     图：数字证书授权中心   为什么需要数字证书呢？Internet网电子商务系统技术使在网上购物的顾客能够极其方便轻松地获得商家和企业的信息，但同时也增加了对某些敏感或有价值的数据被滥用的风险。买方和卖方都必须对于在因特网上进行的一切金融交易运作都是真实可靠的，并且要使顾客、商家和企业等交易各方都具有绝对的信心，因而网络电子商务系统必须保证具有十分可靠的安全保密技术，也就是说，必须保证网络安全的四大要素，即信息传输的保密性、数据交换的完整性、发送信息的不可否认性、交易者身份的确定性。   下面就是在证书中所包含的元素的列表。 　　 版 本 ：它用来区别 X.509的各种连续的版本。默认值是 1988版本。 序列号 ：序列号是一个整数值，在发行的证书颁发机构中是唯一的。序列号与证书有明确联系，就像身份证号码和公民日常登记有明确联系一样。 算法识别符 ：算法识别符识别证书颁发机构用来签署证书的算法。证书颁发机构使用它的私钥对每个证书进行签名。 发行者或证书颁发机构 ：证书颁发机构是创建这个证书的机构。 有效期 ：提供证书有效的起止日期，类似于信用卡的期限。 主体 ：证书对他的身份进行验证。 公钥信息 ：为证书识别的主体提供公钥和算法识别符。 签 名 ：证书签名覆盖了证书的所有其他字段。签名是其他字段的哈希代码，使用证书颁发机构的私钥进行加 密，保证整个证书中信息的完整性。如果有人使用了证 书颁发机构的公钥来解密这个哈希代码，同时计算了证书的哈希代码，而两者并不相同，那么证书的某一部分就肯定被非法更改了。       图：证书内容   有了 数字证书以后，我们可以进行发送安全的电子邮件，实现网上邮件的加密和签名电子邮件，它还可以应用于公众网络上的商务活动和行政作业活动，应用范围涉及需 要身份认证及数据安全的各个行业，如访问安全站点、网上招标投标、网上签约、网上订购、安全网上公文传送、网上办公、网上缴费、网上缴税、网上购物等网上 的安全电子事务处理和安全电子交易活动等。随着电子商务和电子政务的不断发展，数字证书的颁发机构 CA中心将作为一种基础设施为电子商务的发展提供可靠的保障。     Appendix - 1   Details of Handshake Protocol     A HTTP-based SSL connection is always initiated by the client using a URL starting with https:// instead of with http:// . At the beginning of an SSL session, an SSL handshake is performed. This handshake produces the cryptographic parameters of the session. A simplified overview of how the SSL handshake is processed is shown in the diagram below.       The client sends a client "hello" message that lists the cryptographic capabilities of the client (sorted in client preference order), such as the version of SSL, the cipher suites supported by the client, and the data compression methods supported by the client. The message also contains a 28-byte random number. The server responds with a server "hello" message that contains the cryptographic method (cipher suite) and the data compression method selected by the server, the session ID, and another random number. Note: The client and the server must support at least one common cipher suite, or else the handshake fails. The server generally chooses the strongest common cipher suite. The server sends its digital certificate. (In this example, the server uses X.509 V3 digital certificates with SSL.) If the server uses SSL V3, and if the server application (for example, the Web server) requires a digital certificate for client authentication, the server sends a "digital certificate request" message. In the "digital certificate request" message, the server sends a list of the types of digital certificates supported and the distinguished names of acceptable certificate authorities. The server sends a server "hello done" message and waits for a client response. Upon receipt of the server "hello done" message, the client (the Web browser) verifies the validity of the server's digital certificate and checks that the server's "hello" parameters are acceptable. If the server requested a client digital certificate, the client sends a digital certificate, or if no suitable digital certificate is available, the client sends a "no digital certificate" alert. This alert is only a warning, but the server application can fail the session if client authentication is mandatory. The client sends a "client key exchange" message. This message contains the pre-master secret, a 46-byte random number used in the generation of the symmetric encryption keys and the message authentication code (MAC) keys, encrypted with the public key of the server. If the client sent a digital certificate to the server, the client sends a "digital certificate verify" message signed with the client's private key. By verifying the signature of this message, the server can explicitly verify the ownership of the client digital certificate. Note: An additional process to verify the server digital certificate is not necessary. If the server does not have the private key that belongs to the digital certificate, it cannot decrypt the pre-master secret and create the correct keys for the symmetric encryption algorithm, and the handshake fails. The client uses a series of cryptographic operations to convert the pre-master secret into a master secret, from which all key material required for encryption and message authentication is derived. Then the client sends a "change cipher spec" message to make the server switch to the newly negotiated cipher suite. The next message sent by the client (the "finished" message) is the first message encrypted with this cipher method and keys. The server responds with a "change cipher spec" and a "finished" message of its own. The SSL handshake ends, and encrypted application data can be sent.

 

Appendix - 2

SSL uses a scheme of https to reference documents available under HTTP with SSL. The https has a IANA reserved number of 443. SSL supports the RC2 & RC4 with either 128 bits or 40 bits of secret key information, as well as DES, 3 key 3DES, and IDEA. Details of all are covered in Schneier.

A. The threats

As long as they confine themselves to playing by the rules established by Netscape, lookers can do little harm. There's little a looker with minimal resources can do against the deployed crypto systems used in SSL. Hacking one or more of the hosts or key certification authorities would seem to be a better option.

Insiders, especially those around the top of the key certification hierarchy, have the potential to do quite a bit of harm by creating false signatures on keys. Few of these attacks will occur in a vengeful manner; they require time and foresight to enact, and are probably the domain of the malicious employee. (This assumes that employees who become vengeful do so at about the time they leave a firm.)

A criminal organization could, depending on its resources, possibly target an employee at a key certification organization. However, a more useful option might be to buy a cheap PC, and have it attempt brute force RC4 keys. It is estimated that a pentium based PC should be able to crack a 40 bit RC4 key in a month or several months using brute force. The manipulations used on the master key may increase the cost of tha attack, but probably not by orders of magnitude. If a PC costs $1500, then breaking 12 keys a year leads to a cost that could be as low as $125 per stolen card number. While this seems like a high price, the credit card numbers are acquired in a nearly risk free manner of sniffing an ethernet. In addition, that time will drop with the introduction of faster hardware.

B. Protections

SSL explicitly examines a number of attacks that can be made against it, including brute force, clear text cryptanalysis, replay, and man in the middle. It does seem to protect well against those forms of attack.

SSL is designed to protect at the network layer. This means it is not designed to, and does not, protect you from host breakins. To protect against host breakins, a Tripwire-like package should be integrated with the HTTPd. Tripwire uses cryptographically strong hashes to ensure documents have not been changed from some reference version. The database is usually stored on a physically write protected media like a floppy (Kim).

C. Weaknesses

SSL, being a low level protocol, does little to protect you once your host is compromised. Also, once a key in a certificate is compromised, it can remain compromised, as there is no mechanism in place for consulting the root of a CA to confirm the key you are using has not been revoked. The keys however do include expiration dates. Climbing to the root CA is not a commonplace step, but a mechanism should be available to do so, for high value transactions. Out of band key repudiation is also desirable. Today, trusted key certifiers are compiled into the Netscape binary.

The use of RC4 is troublesome, albeit understandable. RC4 is a newly published cipher, and although it was designed by the very competent Ron Rivest, it has not been subjected to the same kind of intense professional scrutiny that DES and IDEA have undergone. The decision to use RC4-40 is driven by the fact that it gets automatic export approval from the State Department.

There are also a number of areas in the design of SSL as it stands that could become exploitable problems. None suggest an immediate means of attack, but are things which could be modified for possible added surety.

Handshaking protocol: The challenge data, sent in the CLIENT-HELLO message, could in some types of handshakes, be sent later, encrypted. The data used in generating the session keys could include more data not sent in the clear. The means of generating the master key should be better specified, probably with reference to RFC-1750.

Record protocol: Bad MAC-data should not terminate a connection, it should cause a repeat-request message. There are few attacks that will get anything from having the same data resent, and closing the connection on a bad message opens avenues for denial of service attacks. Sequence numbers should be randomly initialized. There are quite a few non-obvious attacks on sequence numbers (in IP, and NFS); it can't hurt to start with a non-predictable number.

There should be a way for one or both sides to demand renegotiation of keys. Perhaps this could be implemented as a security escape. This is not needed for HTTP connection security, since the connections are very short lived, but if SSL is used, as the authors suggest, for telnet or FTP, the sessions could last substantially longer.