SSL/TLS协议和证书简介

密码技术

要了解SSL协议，首先要了解：加密算法、消息摘要算法（又称为哈希算法Hash），数字签名等概念。这些技术每个都可以写出一整本的书，它们结合在一起，提供了保密性、完整性和身份验证的功能。

加密算法

设想：ALICE想发消息给她的银行要汇出一笔款。ALICE希望这些消息是保密的，因为这里面包括她的帐户资料和汇款金额。一种办法是使用加密算法，这种技术将她要传递的消息变成经过加密的密文，直接银行解密才可以被读取。 如果采用这种形式，消息只能被一个密钥所加密。没有这个密钥，消息就是无用的。一个良好的加密算法，可以使入侵者面临无法克服困难来解密原文。

有两种加密算法系列：传统加密算法（对称加密）和公钥加密算法（非对称加密）

传统加密算法

也称为对称加密，需要发送者和接收者共享一个密钥：同时用于加密和解密的信息。 只要密钥是保密的，除了收件人和发件人外没有人可以阅读该消息。如果Alice和银行知道这个密钥，那么他们可以给对方发送的经过此密钥加密的消息。这种算法的主要任务在于发送者和接收者如何共享一个密钥，同时确保没有第三方知道这个密钥，如果多人之间传递消息，如何保证这么多密钥的安全，就是一个棘手的问题。

公钥加密算法

也被称为非对称加密技术，通过使用2个密钥（其中一个可以解密另外一个加密的消息），解决了加密密钥交换的问题。 如果用其中的一个密钥用于加密信息，必须使用另外一个密钥来解密。这样就有可能获得简单地发布一个密钥（公钥），并使用未发布的密钥（私钥）来接受经过公钥加密的消息。

任何人都可以使用公共密钥加密消息，但只有私钥拥有者将能够读取它。这样，ALICE可以在发送需要保密的汇款消息给银行的时候，可以使用银行的密钥对中的公钥来对这个消息进行加密，而只有银行可以使用他们自己保管的私钥来进行解密。

消息摘要算法

虽然ALICE可以加密她的消息，但仍然有一个问题，就是有人可能会修改她发给银行的消息，并将ALICE的钱转移到自己的帐户上。为了保证ALICE消息在传递过程中没有被人篡改，可以让她创建一个消息的摘要和加密的消息一起寄到银行，银行收到消息后，将消息和消息的摘要做一个比较，如果消息内容和摘要匹配，则就可以证明消息传递过程中，没有别人篡改。

像这样的摘要被称为消息摘要， 单向函数或哈希函数 。消息摘要用于创建一个简短的固定长度，或可变长度的消息。消息摘要算法被设计成为每个消息产生一条独立的信息摘要。消息摘要算法的目的，就是让人无法为两条不同的消息找到相同的消息摘要，从而消除了使用一条摘要相同的消息替换另外一条消息的可能性。

另一个爱丽丝面临的挑战是找到一种方法，即使安全地将消息摘要发送到银行;如果消息摘要发送过程不安全，银行将无法判断消息是否就是来自ALICE。只有在消息摘要能安全地发送，才能够使消息的完整性被确定。

一个安全发送消息摘要的方式是使用数字签名。

数字签名

当Alice将消息发送给银行，银行需要确保消息真正地是从她这里发出的，以确保入侵者不能使用她的帐户进行交易。 签名就是由ALICE为实现这一目的而创建的一个专门消息。

数字签名主要使用私钥来加密消息摘要和其他信息，譬如一个序列号,虽然任何人都可以使用公钥解密数字签名，只有发送方知道私钥。这意味着，只有发件人可以签署了该消息。包含了信息摘要的签名表示这个签名只对这个消息有效，而且它确保了消息的完整性，即这个消息的发送过程中没人可以改变摘要并另外对它做签名。

为了防止入侵者拦截，并在以后再次使用这个签名，签名包含一个唯一的序列号。 这样可以保证ALICE无法否认她曾经发送过这条消息，因为只有她可以签名这条消息（不可抵赖性）。

证书

虽然ALICE给银行发出一条经过她个人私钥签名的消息，并且可以确保她发送的消息是真实可靠的，但她依然要确保她的确是和银行在通信。这意味着她必须确保她使用的公钥是银行密钥对中的公钥，而不是入侵者的。同样道理，银行业也需要核实用于签名该消息的私钥是属于ALICE的。如何使银行和ALICE能否核实对方的身份呢？

如果每个人的证书都由一个大家都信任的机构签名，那么每个人都可以验证其他有该证书的人的身份。这种被大家都信任的机构，称为认证中心（CA)，他们负责认证证书。

证书的内容

证书内容包括：公钥和真实身份识别信息，包括个人，服务器或其他实体。如表1所示，主题信息包括身份识别信息（DN）和公钥。它还包括认证和签发的CA签发这个证书的有效期，还可能有一些其他的信息（或者成为扩展信息），一般由CA自行定义使用的管理信息，譬如序列号等。

表一：证书信息

主题（证书所有人）	识别名，公钥
签发者	识别名，签名
有效期	不早于，不晚于
管理信息	版本，序列号
扩展信息	基本限制, Netscape标记等

识别名DN是用来提供对某个特定背景下的身份，例如：某个人作为公司的一个雇员而拥有一个证书。识别名DN有X.509标准定义，包括它的字段，字段名和相应的缩写表示。（如表2所示）

表二：识别名(DN)信息

DN字段	缩写	说明	举例
Common Name 通用名	CN	证书颁发对象名称	CN=Joe Average
Organization or Company 组织或公司	O	颁发对象所属单位	O=Snake Oil, Ltd.
Organizational Unit 部门	OU	所在单位部门	OU=Research Institute
City/Locality 城市	L	所在城市	L=Snake City
State/Province 省份	ST	所在省份	ST=Desert
Country 国家	C	国家代码，见ISO 3166-1 A2	C=XZ

证书颁发机构可以定义一个策略，指明哪些识别名字段名是可选的，哪些是必需的。很多证书还对某些字段的内容做出要求。例如，Netsacpe浏览器要求一个服务器证书的CN能够匹配通配符样式的域名，例如：*.snakeoil.com。

证书的二进制格式是使用了ASN.1（抽象语法标记）定义[X208] [ PKCS]。 这种表示法定义了如何指定编码规则的内容和如何将信息转换成二进制形式。证书的二进制编码使用了区分编码规则Distinguished Encoding Rules (DER)，它是基本编码规则Basic Encoding Rules (BER)的一个子集。对于那些不能采用二进制的信息传递，二进制形式可以转化为一个ASCII形式使用Base64编码[MIME]。当证书放置在Begin和End分割线中的时候，这种编码被称为增强型安全私人邮件格式(PEM -“Privacy Enhanced Mail”) 编码的证书。

PEM编码证书的样例（snakioil.crt)

Example of a PEM-encoded certificate (snakeoil.crt) —–BEGIN CERTIFICATE—– MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt 2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7 dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ== —–END CERTIFICATE—–

证书颁发机构CA

通过在批准证书之前核实证书请求中的信息，CA可以保证密钥对的私钥所有人的身份。举例，如果Alice请求一个个人证书，证书颁发机构必须首先核实ALICE在证书申请中所提交的个人信息和资料。

证书链

CA机构有时也会为另外一家CA机构颁发证书。当检查证书的时候，ALICE可能需要检查每一级证书的父亲证书，一直找到一个她所能信任的证书为止。为了降低她在检查证书链中遇到一个“坏”证书的风险，ALICE可能会设定可信证书链的深度。

创建一个根CA

如前所述，每个证书需要发行者来声明证书拥有者身份的有效性，一直到最顶层CA。 这就产生了一个问题：谁来保证最顶层CA的权威性，而这个CA是没有发行者。在这个独特的情况下，证书采用一种“自签名”的方式，所以证书的发行者就是证书拥有者自己。浏览器会将一些知名的CA配置成可信，将他们的根证书安装到自己的受信根证书列表中，但如果要自己添加信任的自签名证书，就需要特别当心。

一些公司，例如GeoTrust 和 Verisign已经建立了他们自己的证书颁发机构。这些公司提供以下服务：

• 验证证书请求
• 处理证书申请
• 发行和管理证书

用户也可以创建自己的证书颁发机构。虽然在互联网上存在比较大的风险，但它在企业内网中是很有用的，可以轻松地验证个人和服务器的身份。

证书管理

建立一个证书机构需要有坚实的行政，技术和管理框架。证书颁发机构不仅颁发证书，他们还要管理好证书，也就是说，他们确定证书在多久的时间内仍然有效，他们有一个列表，里面列举了过去颁发的，但已经不再有效的证书，并且不断更新这个列表（证书吊销清单，或CRL）。

例如：ALICE曾经作为公司的雇员获得一个证书，但她现在已经离开公司了，她的证书就需要被吊销。由于证书只在审核完当事人身份后被签发，并且被传递给需要和当事人沟通的同事，从证书本身告诉去告知它已经被吊销了是不可能的。因此要检查一个证书是否有效，就必须联系CA机构获取证书吊销清单CRL，而这通常是无法自动完成的。

注意：
如果你需要使用一个不是浏览器缺省信任的CA机构，就必须将这个CA的根证书装入浏览器的可信根证书列表，使浏览器可以识别这个CA颁发的服务器证书，但这样做是非常危险的，因为一旦加载了这个CA的根证书，浏览器将接受所有由这个根证书签发的服务器证书。

Secure Sockets Layer(SSL) 安全套接字层

SSL是工作在面对连接网络层（如TCP层）和应用层（HTTP层）之间的协议层。SSL层协议通过为客户端和服务器提供双向认证，对隐私数据的加密，和用数字签名来保证数据完整性，从而提供了一个安全的通信通道。

本协议被设计为支持一系列制定的算法用于加密，数据摘要和签名。这允许对特定服务器的算法选择建立在法律、出口和其他问题的基础上，并且使协议能够利用新的算法。在客户机和服务器试图建立一个对话的时候，会协商算法。

表4：SSL协议的版本

Version	Source	Description	Browser Support
SSL v2.0	Vendor Standard (from Netscape Corp.) [SSL2]	First SSL protocol for which implementations exist	– NS Navigator 1.x/2.x – MS IE 3.x – Lynx/2.8+OpenSSL
SSL v3.0	Expired Internet Draft (from Netscape Corp.) [SSL3]	Revisions to prevent specific security attacks, add non-RSA ciphers and support for certificate chains	– NS Navigator 2.x/3.x/4.x – MS IE 3.x/4.x – Lynx/2.8+OpenSSL
TLS v1.0	Proposed Internet Standard (from IETF) [TLS1]	Revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for block ciphers, message order standardization and more alert messages.	– Lynx/2.8+OpenSSL

如表4所示，有多个SSL协议的版本，其中SSL3.0的一个优势就是它增加了对证书链加载的支持。这项功能使服务器可以将自己的服务器证书和发行者的证书一起传给浏览器。证书链的加载，使得客户机即使没有安装过服务器的中间证书，也可以来验证服务器证书的有效性，因为服务器的中间证书被放在证书链中一起发送给了客户机。SSL 3.0是安全传输层TLS协议的基础，这项协议正由IETF负责制订开发。

建立会话

客户机和服务器同构一种“握手”次序来建立SSL会话，如图1.这个握手次序可能会有所不同，这取决于服务器是否配置成提供服务器证书，或者需要客户机提供客户证书。虽然在其他情况下存在因对密码管理要求不同而不同的“握手”步骤，详见各种SSL协议规范，但本文总结了一个基本的握手次序。

图1：基本握手次序

注意：
服务器为每个SSL会话分配一个唯一的会话标识符并缓存在服务器和客户端（直到会话标识符过期），使客户在下次连接的时候减少了握手的时间。

在握手序列中的被客户端和服务器使用的各项要素，如下列所示：

1. 协商数据传输中使用的加密套接字。
2. 在客户机和服务器中建立并共享一个会话密钥。
3. 可选的服务器端身份认证
4. 可选的客户端身份认证

首先，加密套接字协商，允许客户端和服务器选择一个他们都是支持的加密套接字方式。SSL3.0协议定义了31中加密套接字方式，每一种安全套接字由下列部分组成：

• 密钥交换方法
• 数据加密传输
• 创建消息认证码（MAC）的消息摘要

这3个要素将在下面的几节中详细描述。

密钥交换方法

密钥交换方法定义在客户端和服务器之间共享双方都同意的，被用于应用数据传输的对称加密的密钥。SSL2.0协议只适用RSA密钥交换方式，而SSL3.0不仅支持RSA密钥交换（在使用证书的情况下），还支持Diffie-Hellman密钥交换（在没有使用证书或者没有客户端和服务器之间通信密钥之前的情况下。）

在决定密钥交换方式中的变量是选择是否需要数字签名和使用什么样的签名。使用私钥签名可以防止在交换共享密钥的时候，遭受中间人攻击。

数据加密传输

SSL在加密会话中的消息时采用传统的对称加密方法，有9种加密方式可以选择，包括也可以选择不加密。

• No encryption
• Stream Ciphers

• RC4 with 40-bit keys
• RC4 with 128-bit keys

• CBC Block Ciphers

• RC2 with 40 bit key
• DES with 40 bit key
• DES with 56 bit key
• Triple-DES with 168 bit key
• Idea (128 bit key)
• Fortezza (96 bit key)

“CBC”

“DES” 是指Data Encryption Standard，有一系列不同的变量。包括DES40和3DES_EDE

“Idea”

“RC2”

摘要函数

对信息摘要函数的选择决定了如何从一个记录单元创建一个摘要。SSL支持以下模式：

• 无摘要
• 128位哈希的MD5
• 160位的安全哈希算法（SHA – 1）

消息摘要是用来创建一个消息认证码（MAC），MAC是与消息加密，来核实消息的完整性和保护消息不受回放式攻击。

握手次序协议

握手次序使用三个协议：

• SSL Handshake Protocol. SSL握手协议执行客户端和服务器SSL会话的建立过程。
• SSL Change Cipher Spec Protocol .SSL更改密码协议负责协商会话用的密码套接字。
• SSL Alert Protocol.SSL告警协议负责在客户端和服务器间传递SSL错误信息。

这些协议以及应用协议数据，都被SSL记录协议封装，如图2所示。封装好的数据被不检查数据的低一层的协议传递。下一层的协议对封装协议来说是未知的。

图2：SSL协议栈

SSL控制协议对记录协议的封装，使一个正在进行的会话在需要重新协商时，控制协议能够被安全地传输。如果没有前一个会话，则使用空的密码套接字，也就是说，在会话建立以前，不会使用密码也没有验证完整性的消息摘要。

数据传输

SSL记录协议,如图3所示 , 用于在客户端和服务器之间传递SSL控制协议和应用层数据，必需将这些数据分割成较小的单元，或者将多个较高层协议数据合并为一个单元。它可能会在将这些数据传递到下一层可靠的传递协议前将这些数据压缩、加密和附加一个摘要签名。（注：目前主流的SSL都没有对压缩的支持）。

图3：SSL记录协议

安全HTTP通信

SSL最常见的一想用途就是在浏览器和WEB服务器之间加密安全的WEB HTTP通信。使用加密的HTTP（称为HTTPS），即在SSL协议上使用HTTP协议，并没有排除HTTP协议，不过在URL地址中使用HTTPS来替换原来的HTTP，并使用另外一个服务器端口（HTTPS缺省使用443，HTTP使用80）。

原文链接：https://blog.51cto.com/u_9420214/6333275