因为项目中要用到TLS + SASL 来做安全认证层. 所以看了一些网上的资料, 这里做一个总结.

1. 首先推荐几个文章:

数字证书: http://www.cnblogs.com/hyddd/archive/2009/01/07/1371292.html

数字证书和SSL: http://www.2cto.com/Article/201203/121534.html

数字签名: http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html

2. 数字证书

数字证书是一种权威性的电子文档。它提供了一种在Internet上验证您身份的方式，其作用类似于司机的驾驶执照或日常生活中的身份证。它是由一个由权威机构----CA证书授权(Certificate Authority)中心发行的，人们可以在互联网交往中用它来识别对方的身份。当然在数字证书认证的过程中，证书认证中心（CA）作为权威的、公正的、 可信赖的第三方，其作用是至关重要的。

CA认证中心是负责
签发，
管理，
认证
数字证书的机构，是基于国际互联网平台建立的一个公正，权威，可信赖的第三方组织机构。

全球有很多个CA认证中心, 根CA认证中心代表权威, 它可以分派数字证书(包括下级CA数字证书 , 用户数字证书).

CA认证中心的关系图:

2.2 数字证书的组成

数字证书由CA派发, 包含F证书内容(明文写明证书的一些信息,包括派发单位,证书所有人等),  A加密算法 , F'数字签名(派发该证书的CA的数字签名) , 所有者的公钥

这里要说一下数字签名的产生过程:

例如这里由派发证书的CA生成的数字签名, 首先, 对证书内容(F)进行hash算法生成摘要, 使用CA自己的私钥进行RSA加密(或者其他一种非对称加密算法A) , 就生成出了数字签名(F').

2.3 数字证书的验证原理

数字证书通过F , A , F' 三项来验证证书的真实性和有效性.

首先我们要知道下面几个特点:

1.数字证书机制默认, 所有者的私钥是安全的

2.根CA的公钥默认认为是合法的, 且是为大多数浏览器所知的, 甚至内嵌的. 例如firefox的证书管理器中就内嵌了已知的根CA的公钥.

验证数字证书(包含验证'证书'和'持有人'的真实有效性)的过程: (*******)

1. 使用派发证书的CA的公钥(可以向CA请求)来对F'解密得到h1 (hash值)

2. 对证书内容F进行hash算法得到h2

3. 如果h1 == h2 , 那么证书是真实有效的.

4. 当证书被证明是真实有效的, 那么我们就可以认为数字证书中包含的公钥, 是证书所有人(申请该证书的用户或者机构)的真实公钥.

(从这一点我们可以知道, 其实数字证书, 就是为了保证公钥的正确性而产生的)

5. 用此公钥加密一段信息发送给证书的持有者，如果持有者能发送回（可以是被私钥加密，也可以是明文，没有关系）被加密的这段信息的话就证明该持有者拥有该证书对应的私钥，也就是说，该持有者就是该证书的所有者。

以上过程(前3步)可以用下图说明:

     

2.4 数字证书组成信息

3. ssl(tls)  - 传输层安全协议

通过第二节的数字证书说明, 相信大家都可以大致知道数字证书的作用(保证公钥确实属于证书所有人)以及验证的过程.

那么下面就可以来看SSL如何结合数字证书进行工作:

3.1 为何引入SSL

我们知道, 传统的加密技术有2个类型, 一个是对称加密(例如DES) , 另一个是非对称加密(例如RSA).

其中非对称加密中有私钥和公钥的概念, 十分适合验证特定对象的真实性和唯一性. 但非对称加密算法比较复杂, 速度缓慢 , 也很消耗资源, 因此就不适合大数据量的加密.

而对称加密由于两端同用一组密码,加密和解密算法比较简单, 适合大数据量加密.

SSL全称是 Secure Sockets Layer，它是一种间于传输层（比如TCP/IP）和应用层（比如HTTP）的协议. 它通过"握手协议"和"传输协议"来解决传输安全的问题.

握手协议是基于非对称加密的，而传输协议是基于对称加密的。根据不同的应用，SSL对证书的要求也是不一样的，可以是单方认证（比如HTTP, FTP），也可以是双方认证（比如网上银行）。通常情况下，服务器端的证书是一定要具备的，客户端的证书不是必须的。

3.2 SSL的握手和传输

下面两张图片显示了SSL握手的过程。

图3.2.1  SSL握手，单方服务器认证
                  

传输过程: 在通信双方协商出一个对称密钥以后，他们用这个密钥来加密传输的数据。同时为每个消息生成时间戳，用此密钥为消息和相应的时间戳生成消息认证码（MAC）。也就是说，每次发送的内容包括
             Encrypt(message) + MAC(message + timestamp)

4. SASL - 简单认证和安全层

SASL是一种用来扩充C/S模式验证能力的机制认证机制,  全称Simple Authentication and Security Layer.

当你设定sasl时，你必须决定两件事；一是用于交换“标识信 息”（或称身份证书）的验证机制；一是决定标识信息存储方法的验证架构。

sasl验证机制规范client与server之间的应答过程以及传输内容的编码方法，sasl验证架构决定服务器本身如何存储客户端的身份证书以及如何核验客户端提供的密码。

如果客户端能成功通过验证，服务器端就能确定用户的身份， 并借此决定用户具有怎样的权限。

比较常见的机制；

4.1 plain(较常用)

plain是最简单的机制，但同时也是最危险的机制，因为身份证书（登录名称与密码）是以base64字符串格式通过网络，没有任何加密保护措施。因此，使用plain机制时，你可能会想要结合tls。

4.2 login

login不是其正式支持的机制，但某些旧版的mua使用这种机制，所以cyrus sasl让你可选择其是否支持login机制。如果你的用户仍在使用这类老掉牙的mua，你必须在编译sasl函数库时，指定要包含login的支持。 login的证书交换过程类似plain。

4.3 otp

otp是一种使用“单次密码”的验证机制。此机制不提供任何加密保护，因为没必要－－每个密码都只能使用一次，每次联机都要改用新密码。smto client必须能够产生otp证书。

4.4 digest-md5(较常用)

使用这种机制时，client与server共享同一个隐性密码，而且此密码不通过网络传输。验证过程是从服务器先提出challenge（质询）开始， 客户端使用此challenge与隐性密码计算出一个response（应答）。不同的challenge，不可能计算出相同的response；任何拥 有secret password的一方，都可以用相同的challenge算出相同的response。因此，服务器只要比较客户端返回的response是否与自己算 出的response相同，就可以知道客户端所拥有的密码是否正确。由于真正的密码并没有通过网络，所以不怕网络监测。

4.5 kerberos

kerberos是一种网络型验证协议。除非你的网络已经使用kerberos，否则你应该用不到kerberos机制；相对的，如果你的网络已经架设了kerberos验证中心，sasl就能完美的将smtp验证整合进现有的体系。

4.6 anonymous

anonymous机制对smtp没有意义，因为smtp验证的用意在于限制转发服务的使用对象，而不是为了形成open relay，sasl之所以提供这种机制，主要是为了支持其他协议。
当 客户端链接到一个支持sasl的邮件服务器时，服务器会以优先级列出可用的机制供客户端选择。如果客户端也支持多钟机制，则当第一种机制验证失败时，客户 端可能会继续尝试第二种机制，直到通过验证或是所有机制都失败为止。如果双方在一开始就无法协调出共同的机制，验证过程就算失败。
一旦双方在使用哪种机制上达成共识，就开始进行验证过程。实际的交互过程随机制而定，但通常包含一次或多次应答过程。验证协议本身也规定了应答内容的编码格式。

5. 总结

数字证书, 是级联认证派发的, 最上层是根CA认证中心. 数字证书的根本作用, 是为了保证所有人公钥的安全性和真实性. 大致认证过程是: 通过CA的公钥来解出该CA所派发的证书里面所包含的公钥(用户或者机构的). 并通过该公钥来验证证书持有人的真实性. (因为持有人并不一定是证书所有人)

SASL是提供一种用户身份认证机制, 你可以简单认为是用来认证用户的账号/密码是否运行进入系统或者使用系统的服务. 一般较长使用digest-md5, 该种机制下, 密码可以不用在网络上传输, 也就不用怕密码被窃听.