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会话是在客户与服务器之间的一个关联。会话由握手协议创建。会话定义了一组可供多个连接共享的加密安全参数。会话用以避免为每一个连接提供新的安全参数所付出昂贵的代价。 ① 会话状态由下列参数定义:
② 连接状态由下列参数定义:
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网电子商务系统技术使在网上购物的顾客能够极其方便轻松地获得商家和企业的信息,但同时也增加了对某些敏感或有价值的数据被滥用的风险。买方和卖方都必须对于在因特网上进行的一切金融交易运作都是真实可靠的,并且要使顾客、商家和企业等交易各方都具有绝对的信心,因而网络电子商务系统必须保证具有十分可靠的安全保密技术,也就是说,必须保证网络安全的四大要素,即信息传输的保密性、数据交换的完整性、发送信息的不可否认性、交易者身份的确定性。 下面就是在证书中所包含的元素的列表。
图:证书内容 有了 数字证书以后,我们可以进行发送安全的电子邮件,实现网上邮件的加密和签名电子邮件,它还可以应用于公众网络上的商务活动和行政作业活动,应用范围涉及需 要身份认证及数据安全的各个行业,如访问安全站点、网上招标投标、网上签约、网上订购、安全网上公文传送、网上办公、网上缴费、网上缴税、网上购物等网上 的安全电子事务处理和安全电子交易活动等。随着电子商务和电子政务的不断发展,数字证书的颁发机构 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.
|
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.
【SSL(Secure Sockets Layer )协议与数字证书】
推荐阅读
- 【Tomcat源码阅读分享】—(5)Tomcat中的ClassLoader
- 14.|14. Nginx Secure Link
- Centos|Centos 7 OpenSSL1.0.2K 动态库升级1.0.2U
- 说说SSL/TLS协议
- 使用DNSLOG,配置mysql的secure_file_priv参数
- Mac 上制作 SSL 证书
- 通配符SSL证书选购攻略
- SSL: CERTIFICATE_VERIFY_FAILED
- SSL证书格式及转化方法
- Tengine + BabaSSL ,让国密更易用!