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

Posted 2020-10-04

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

因为项目中要用到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, 该种机制下, 密码可以不用在网络上传输, 也就不用怕密码被窃听.