转: https 单向双向认证说明_数字证书, 数字签名, SSL(TLS) , SASL

转自： http://www.cnblogs.com/mailingfeng/archive/2012/07/18/2597392.html

 

由于项目中要用到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. 数字证书   

 

     2.1 数字证书和CA的简介

    数字证书是一种权威性的电子文档。它提供了一种在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 数字证书组成信息

 

　　1.Certificate(证书)：

　　 (1).Common Name(证书全部人姓名，简称CN，其实就是证书的名字，如第一幅图看到的：ABA.ECOMRoot....)

　　 (2).Version(版本，如今通常是V3了)

　　 (3).Issuer(发证机关)

　　 (4).Validity(有效日期)

　　 (5).Subject(证书信息，你会发现它和Issuer里面的内容是同样的)

　　 (6).Subject's Public Key Info(证书全部人公钥，刚才所说的公钥就是这个!)

　　 (7).Extension(扩展信息)

　　 (8).Certificate Signature Algorithm(公钥加密算法)、

 　　 以上这几项就是上面所说的证书内容(F)。　

　　2.Certificate Signature Algorithm:

　　  这是描述证书的加密算法，就是上所说的加密算法(A)，看它的Fireld Value，通常会写：PKCS #1 SHA-1 With RSA Encryption

　　3.Certificate Signature Value:

　　　这记录的是证书被加密后的结果，至关于上面说讲的F'。

 

 

 

 

---

 

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握手，单方服务器认证 
                   

 

                             图3.2.2  SSL握手，双方认证

 

    

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

 

    这么作有几个好处： 
       1.    防止消息的篡改 
        所谓消息篡改就是有第三者插在通讯双方之间，篡改往来的消息。因为消息是加密的，第三者不能得到消息的内容，可是他能够闭着眼睛瞎改。若是没有MAC的话，接受者就没法判断此  消息是否被篡改过。 
       2.    防止消息重放 
       消息的重放是只第三者记录下通讯双方的每一次发送的消息，虽然他不能得到消息的内容。可是它能够经过从新发送客户端或者服务端的信息来把本身装成是客户端或者服务端。若是在MAC里面加上了时间戳，消息接收方验证时间戳就能够阻止消息的重放攻击。 
SSL的基本思想是用非对称加密来创建连接（握手阶段），用对称加密来传输数据（传输阶段）。这样既保证了密钥分发的安全，也保证了通讯的效率。

 

 

---

 

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所派发的证书里面所包含的公钥(用户或者机构的). 并经过该公钥来验证证书持有人的真实性. (由于持有人并不必定是证书全部人)

 

       经过上面对SSL的分析，咱们能够看到，SSL并不能阻止别人得到你传输的数据，可是因为你传输的数据都是加密过的，别人拿到了毫无用处，同样能够保护信 息的安全。还有一点须要强调一下，SSL并不依赖于TCP，它能够创建在任何可靠的传输层协议（好比TCP）之上。也就是说SSL是不能创建在UDP之上 的。这是显然的，若是传输都不可靠，偶尔丢两个包或者包的顺序换一换的话，怎么保证安全呢？

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