【下】安全HTTPS-全面详解对称加密，非对称加密，数字签名，数字证书和HTTPS

1.  HTTPS

1.1. 什么是HTTPS

HTTPS（HypertextTransfer Protocol Secure）即安全的HTTP。HTTPS的安全基础是安全套接层（Secure Sockets Layer，SSL）。HTTP工作在应用层（OSI模型的最高层），SSL协议工作在一个较低的子层，位于TCP/IP协议和HTTP协议之间。在HTTP报文传输前对其加密，并在到达时对其解密。严格地讲，HTTPS并不是一个单独的协议，而是工作在SSL协议上的HTTP协议。

TLS对SSL进行了扩充，是SSL的继任者，但两者区别不大，以下讨论中不对TLS和SSL做严格区分。

HTTPS主要作用有两种：（1）确认通讯双方的身份，（2）建立安全通道，保证数据传输安全。1.2. HTTPS的主要作用

1.2.1. 确认通讯双方的身份

HTTPS通讯中，通过签名技术通讯双方可以确认对方身份。身份认证分为单向认证和双向认证。单向认证中只有服务器端有证书，双向认证中服务器和客户端都有证书。一般的HTTPS站点只有服务器有证书，而客户端无证书。

单向认证是双向认证的简化版，本文讨论过程中如无特殊说明都认为是双向认证。

1.2.2. 建立安全通道，保证数据传输安全

基于SSL协议通讯双方可以协商一个用于对称加密的密钥，该密钥是一个难以破解的随机数，而且依赖通讯双方的证书、私钥等来协商。密钥协商好后，通讯双方用该密钥对数据进行加解密，从而保证数据安全。

1.3. HTTPS与HTTP协议的差异

(1).   HTTP 的URL是以“http://”开始，HTTPS的URL是以“https://”开始；

(2).   HTTP默认端口为80，HTTPS的默认端口为443；

(3).   采用HTTPS的Web Server需要到CA申请证书；

(4).   HTTPS由HTTP+SSL来实现，可进行加密传输、身份认证等，要比HTTP安全

(5).   HTTP的信息是明文传输，而HTTPS的信息是加密传输

  

2.  公开密钥加密

2.1. 什么是公开密钥加密？

公开密钥加密也称非对称密钥加密，该加密算法使用两个不同的密钥：加密密钥和解密密钥。前者公开，又称公开密钥，简称公钥；后者保密，又称私有密钥，简称私钥。这两个密钥是数学相关的，用某用户加密密钥加密后所得的信息只能用该用户的解密密钥才能解密。RSA算法（由发明者Rivest，Shmir和Adleman姓氏首字母缩写而来）是著名的公开密钥加密算法。

公钥加密的另一用途是身份验证：用私钥加密的信息，可以用公钥对其解密，接收者由此可知这条信息确实来自于拥有私钥的某人。私钥加密的过程即数字签名。

用公钥加密的数据只有私钥才能解密；相反的，用私钥加密的数据只有公钥才能解密，正是这种不对称性才使得公用密钥密码系统被广泛应用。

2.2. 优点

与对称密钥加密相比，优点在于无需共享的通用密钥，解密的私钥不发往任何用户。即使公钥在网上被截获，如果没有与其匹配的私钥，也无法解密，所截获的公钥是没有任何用处的。　　

2.3. 过程

假设两个用户A，B进行通信，公钥为c,私钥为d，明文为x.

Step 1. A用公钥对明文进行加密形成密文c(x)，然后传输密文；

Step 2. B收到密文，用私钥对密文进行解密d(c(x)),得到要通信的明文

2.4. 对称密钥加密

对称密钥加密又叫专用密钥加密，即发送和接收数据的双方必须使用相同的密钥对明文进行加密和解密运算。

3.    数字证书和CA

3.1. 确认主机的真实性

采用https 的server（服务器）必须从CA （CertificateAuthority）申请一个用于证明服务器用途类型的数字证书（或者叫CA证书）. 该证书只有用于对应的server 时，客户端才信任此主机.

CA（Certificate Authority）即"认证机构"，是负责签发证书、认证证书、管理已颁发证书的机构，是PKI（Public Key Infrastructure，公钥基础设施）的核心。它要制定政策和具体步骤来验证、识别用户身份，并对用户证书进行签名，以确保证书持有者的身份和公钥的拥有权。

CA 也拥有一个证书（内含公钥）和私钥。网上的公众用户通过验证 CA 的签字从而信任CA ，任何人都可以得到 CA 的证书（含公钥），用以验证它所签发的证书。

 

3.2. 什么是数字证书

数字证书（CA证书是经过认证的数字证书）是一个用于互联网通讯中认证身份的工具，由权威机构——CA机构（Certificate Authority）发行。其作用类似于司机的驾驶执照和公民身份证。CA作为公正的第三方来确保证书的有效性[6]。全国存在多个CA机构（只要你有公信力你也可以成立一家CA机构）。

数字证书包含一个公钥以及该密钥所有者的信息。证书还标明有有效期，并通过另一密钥（CA私钥）进行签名，该密钥能保证这些属性的真实性，最重要的是，保证公钥本身的真实性[14]。最简单的证书包含一个公钥、名称以及证书授权中心的数字签名（公开密钥只是证书的一部分内容）。目前，证书的格式和验证方法普遍遵循X.509 国际标准。

CA机构自身也拥有一个证书（内含公钥）和一个私钥。

用户如果想得到一个数字证书，他应先向 CA申请，CA审查申请者的身份后，给他分配一个公钥，并将公钥与申请者的身份信息绑在一起，同时用自己的私钥签字，最终生成一个证书，发给申请者；同时还将一个与公钥关联的私钥也发给申请者。证书的内容主要有：CA信息、CA签字、证书拥有者信息、证书公钥和证书有效期等。

某人需要验证一个证书时，用签发该证书的CA的公钥来解密其签名信息，以验证证书是否可信。CA证书也需要验证，验证CA证书是一个递归上溯的过程，验证过程终止于根证书。根证书是一份特殊的证书，它的签发者是它本身，下载根证书就表明用户对该根证书，以及其所签发的证书都信任。

 

3.3. 数字证书基本原理

数字证书采用公开密钥加密体制，利用一个强关联的密钥对进行加、解密。证书拥有者保存好自己的私钥，用它进行解密和签名；并把公钥公开，供一组用户所共享，用于加密和验证签名。

1、加密：发送数据时，发送方使用接收方的公钥对数据加密，接收方用私钥解密，还原消息。算法保证公钥加密的数据只有对应的私钥才能解密。

2、数字签名：证书拥有者用私钥对信息进行加密，由于私钥仅为本人所有，这样就生成了别人无法伪造的数据，该数据即数字签名。采用数字签名，能够确认以下两点：

（1）保证信息是由签名者所发送，签名者不能否认或者难以否认；

（2）保证信息自签发后到收到为止，未曾做过任何修改，签发的文件是真实的文件。

算法保证只有公钥才能解开私钥加密的信息。

3.4. 如何生成数字证书

略

 

4.  SSL

4.1. 什么是SSL

SSL 是一个安全协议，它提供使用TCP/IP 的通信应用程序间的隐私与完整性。传输层安全（Transport Layer Security，TLS）对SSL进行了升级改造，将成为SSL的继任者。

4.2. 加密过程

SSL 协议既用到了公钥加密技术(非对称加密)，又用到了对称加密技术。

Step 1：用公开密钥加密技术（通常为RSA）验证彼此身份（有时服务器不需要验证客户端身份），并协商Step2中通讯时所用的对称加密密钥；

Step 2：用对称密钥加密技术（如DES，或者RC4）加密服务器端和客户端通讯时的数据。

这样做的好处是：公开密钥加密相对复杂，速度慢，可用来完成安全性要求较高的身份认证、密钥协商等事务；对称密钥加密技术相对简单，速度快，可用来加密数据量大的传输内容。

4.3. 构成

SSL协议的优势在于它与应用层协议是独立无关的。高层的应用层协议 (例如：Http、FTP、Telnet等等 ) 能透明的建立于SSL协议之上。SSL协议在应用层协议通信之前就已完成数据加密、通信密钥的协商和服务器的认证等工作。在此之后应用层协议所传送的数据都会被加密，从而保证通信的私密性。

SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层：记录协议（SSL Record Protocol）和握手协议（SSL Handshake Protocol）。记录协议建立在可靠的传输协议（如TCP）之上，为高层协议，如握手协议，提供数据封装、压缩、加解密等支持。握手协议建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。握手协议协商好加密算法、压缩算法和对称加密密钥等后，开始应用层数据传输（如HTTP协议的数据传输）。应用层的数据传输也是工作在记录协议之上，由记录层用协商好的密钥对其数据进行加解密，确保数据安全。

4.4. RSA算法

1977年美国麻省理工学院的Ron Rivest、Adi Shamirh和LenAdleman共同发明了RSA加密算法。。该算法基于一个十分简单的数论事实：将两个大素数相乘十分容易，但要对其乘积进行因式分解却极其困难。

4.5. SSL协议的身份认证和对称加密密钥的协商

4.5.1. TSL协议交互过程

TSL的身份认证和密钥协商大致过程如下（下面只考虑新建会话的情况，而不考虑重启存在会话的情况）：

Step1：客户端往服务器端发ClientHello消息

消息特点：该消息是客户端连接服务器端时发送的第一个消息。

消息构成：

(1).   使用的TLS协议版本。

(2).    随机数；用于计算对称加密时的“主密码”。

(3).   会话ID；重连时有用，可为空。

(4).   加密算法列表；客户端支持的加密算法列表，并按照客户端的偏好从前往后排。

(5).   压缩算法列表；客户端支持的压缩算法列表，并按照客户端的偏好从前往后排。

(6).   扩展信息。

消息作用：用于发起会话、交换随机数、协商加密算法、压缩算法等。

 

Step2：服务器端验证ClientHello消息，主要验证：

(1)   消息格式是否合法；

(2)   能否至少支持客户端所列举的一个加密算法和一个压缩算法等。

验证不通过则发送消息断开会话，验证通过则执行下一步。

 

Step3：服务器往客户端发送ServerHello消息。

消息特点：该消息是服务器收到ClientHello后返回给客户端的第一个消息。

消息构成：

(1).   使用的TLS协议版本。

(2).    随机数；用于计算对称加密时的“主密码”(这个随机数是服务器发送给客户端的,跟第一步骤的随机数不同,第一个是客户端发送给服务的)

(3).   一个加密算法；服务器从客户端的加密算法列表中选中的一个加密算法。

(4).   一个压缩算法；服务器从客户端的压缩算法列表中选中的一个压缩算法。

(5).    会话ID；新建的唯一的会话ID。

(6).   扩展信息。

消息作用：用于交换随机数、确定加密算法、压缩算法等。

 

Step4：服务器往客户端发送Certificate消息。

消息特点：该消息必须在ServerHello发送完后立即发送。如果是匿名协商，则无须发该消息。

消息构成：

(1).   证书列表；服务器的证书必须为证书列表的第一个，其后为签发服务器证书的证书，依次类推，最后一个证书为根证书签署的证书。根证书不在证书列表中，它是通过其他途径给到客户端的。(好多时候是浏览器预装好的)

消息作用：发送服务器证书，或者证书链。

 

Step5：服务器往客户端发送ServerKeyExchange消息。

消息特点：

(1).   该消息必须在Certificate发送完后立即发送（如果是匿名协商，则该消息紧跟在ServerHello后）。

(2).    该消息只有当Certificate消息无法提供足够信息让客户端完成“预主密码”交换时才需要。

 

消息构成：

(1).   密钥交换算法

消息作用：该消息用于发送密钥交换算法给客户端。客户端可利用这些算法和服务器端完成“预主密码”的交换。

 

Step6：服务器往客户端发送CertificateRequest消息。

消息特点：

(1).    非匿名的服务器可通过该消息来要求客户端发送证书验证其身份。

(2).   如果发送该消息则该消息在ServerKeyExchange发送完后立即发送(如果该次交互不发送ServerKeyExchange，则该消息紧跟Certificate消息)

消息构成：

(1).   证书类型列表；客户端的证书类型必须是证书类型列表中一种。

(2).   签名和哈希算法列表；列举服务器所支持的签名算法和哈希算法。

(3).   CA名字列表；服务器只接受的列表中所列出的CA所发行的证书，其他证书无法验证。

消息作用：请求客户端发送证书验证其身份。(只有双向认证才需要,即服务器也需要认证客户端)

 

Step7：服务器往客户端发送ServerHelloDone消息。

消息特点：

消息构成：

(1).   无消息内容。

消息作用：该消息用来告诉客户端ServerHello以及附属消息都已发送完毕。发完该消息后服务器等待客户端消息。

 

Step8：客户端往服务器端发送ClientCertificate消息。

消息特点：

(1).    该消息仅当收到服务器CertificateRequest时才发送，即服务器要求验证客户端。

(2).   如果发送该消息，则该消息必须是客户端收到ServerHelloDone消息后发往服务器的第一个消息。

消息构成：

(1).   证书列表。

消息作用：发送客户端证书让服务器认证。(只有双向认证才需要,即服务器也需要认证客户端)

 

 

Step9：客户端往服务器端发送ClientKeyExchange消息。

消息特点：

(1).   如果有ClientCertificate消息，则该消息必须紧跟其后发送；如果无ClientCertificate消息，则该消息是收到ServerHelloDone消息后发往服务器的第一个消息。

(2).   消息用RSA算法或者 Diffie-Hellman参数来协商预主密码。

(3).    采用RAS加密的协商预主密码时，先生成一个长的随机数，由该随机数和客户端的TSL版本号构成一个结构体，用服务器证书的公钥（从服务器证书获得）对结构体进行加密，并把加密后的数据发给服务器。

(4).   Diffie-Hellman参数协商比较复杂，暂不讨论。

消息构成：因加密算法而异。

消息作用：协商预主密码

 

Step10：客户端往服务器端发送CertificateVerify消息。

消息特点：

(1).   该消息只有当客户端证书有签名能力时(Tenfy:即有客户端证书，且证书是公钥和私钥都有的)发送，其它情况不发送（不含固定Diffie-Hellman参数的证书都有签名能力）。

(2).   该消息必须在ClientKeyExchange发送完后立即发送。

(3).   该消息采用客户端证书中的私钥信息进行加密。

消息构成：

(1).   把该消息之前的所有消息作为参数，用私钥对其进行签名得出一份数据，该数据即为消息体。

消息作用：通过签名方式，验证客户端身份。

 

Step 11：服务器用服务器私钥解密ClientKeyExchange消息得 “预主密码”。服务器和客户端用相同的算法计算“主密码”。主密码计算是根据预主密码、ClientHello中的随机数、ServerHello中的随机数得到的。计算好主密码后双方各向对方发送一个ChangeCipherSpec消息：

消息特点：

(1).   该消息必须在所有握手消息发送完之后，在Finished消息发送之前发送。

(2).   该消息必须在接收完所有握手消息之后，在接收Finished消息之前收到。

消息构成：

(1).   确认消息。

消息作用：确认采用刚才协商好的压缩算法、加密算法、主密码等来传输后继数据。

 

Step12：任意一方收到ChangeCipherSpec消息后告诉自己的Record Layer由读等待状态转为读状态，并采用新方式来传递数据。并往另外一端往发送Finished消息。

消息特点：

(1).   该消息是收到ChangeCipherSpec后立即发送的。

(2).    该消息是首次采用刚才协商好的压缩算法、加密算法、主密码等来传输的数据。

消息构成：

(1).   把前面大部分的握手消息作为参数，用相同的算法计算得到的一个值。

消息作用：完成压缩算法、加密算法等的协商，开始转入应用层数据传输。   

 

Step13：双方验证收到的消息，验证通过则开始应用层数据传输，否则断开。

 

TSL通讯时分为单向认证和双向认证。单向认证时只需要服务器端拥有证书（公钥是证书的一部分）和私钥，其中证书公开，私钥自己保管；双向加密时需要服务器和客户端都提供证书和私钥，证书都公开，私钥都自己保管。这两个对证书、私钥对无必然联系，实际编程时把它们作为两对独立的证书、私钥对来处理。

单向认证时，服务器端不会验证客户证书。故服务器无须发送CertificateRequest消息请求客户端证书，客户端无须发与证书相关的ClientCertificate和CertificateVerify消息。

 

4.5.2. TSL协议中的消息验证

通讯过程中必须严格按上述说明来发送和接收消息。接收方接收消息后一旦发现：(1)消息遗漏，(2) 消息次序不对，(3) 消息格式（如加密格式）有误，(4) 消息内容有误，(5) 自身致命错误等，接收方立即通过Alert Protocol往发送方发送ErrorAlert消息，告诉对方终止此次会话。如果是能容忍的错误，则不发任何消息，以免对方主动断开会话。

若干重要验证说明：

1.        客户端验证服务器的Certificate消息。主要验证内容为：

(1).    服务器证书使用日期是否有效。

(2).    发行服务器证书的CA是否可靠。

(3).    发行者的公钥能否解开服务器证书上的“发行者数字签名”。

(4).    服务器证书上的名称（如域名）是否和服务器实际名称匹配等（PHP中可以选择是否验证该选项）。

(Tenfy: 这里可以看出,客户端验证服务的时候,只需要验证对应服务器证书的有效性即可,无需验证对应服务器是否拥有跟该证书一致的私钥)

 

 

2.        服务器验证客户端的CertificateVerify消息。主要验证内容为：

(1).    用客户端公钥能否解开客户端私钥加密的消息。

(Tenfy:服务器验证客户端时候，还需要验证是否拥有跟证书对应的私钥)

 

3.        服务器验证客户端的ClientCertificate消息。主要验证内容为：

(1).    客户的证书使用日期是否有效。

(2).    为客户提供证书的CA 是否可靠。

(3).    发行CA 的公钥能否正确解开客户证书的发行CA的数字签名。

(4).    检查客户的证书是否在证书废止列表（CRL）中。

附：常见的证书格式

1.1. PEM 

Openssl使用PEM(RFC 1421－1424)文档格式。PEM全称是PrivacyEnhanced Mail，该标准定义了加密一个准备要发送邮件的标准。它的基本流程是这样的：

1、信息转换为ASCII码或其它编码方式；

2、使用对称算法加密转换了的邮件信息；

3、使用BASE64对加密后的邮件信息进行编码；

4、使用一些头定义对信息进行封装，这些头信息格式如下（不一定都需要，可选的）：

Proc-Type,4:ENCRYPTED

DEK-Info:cipher-name, ivec

其中，第一个头信息标注了该文件是否进行了加密，该头信息可能的值包括ENCRYPTED(信息已经加密和签名)、MIC-ONLY(信息经过数字签名但没有加密)、MIC-CLEAR(信息经过数字签名但是没有加密、也没有进行编码，可使用非PEM格式阅读)以及CLEAR(信息没有签名和加密并且没有进行编码，该项好象是openssl自身的扩展，但是并没有真正实现)；；第二个头信息标注了加密的算法以及使用的ivec参量，ivec其实在这儿提供的应该是一个随机产生的数据序列，与块加密算法中要使用到的初始化变量（IV）不一样。

5、在这些信息的前面加上如下形式头标注信息：

-----BEGINPRIVACY-ENHANCED MESSAGE-----

在这些信息的后面加上如下形式尾标注信息：

-----ENDPRIVACY-ENHANCED MESSAGE-----

上面是openssl的PEM文件的基本结构，需要注意的是，Openssl并没有实现PEM的全部标准，它只是对openssl中需要使用的一些选项做了实现，详细的PEM格式，请参考RFC1421－1424。

The Public-KeyCryptography Standards (PKCS)是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。

1.2. PFX 

PFX（Personal Information Exchange）证书文件是采用PKCS(The Public-KeyCryptography Standards)标准生成的证书。PKCS是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。

PFX文件通常包含一个证书和与之对应的私钥，现阶段证书采用PKCS #12 标准[14]。这类文件是高度敏感的，在导出密钥对时，Windows 提供用密码加密 .pfx 文件；而在导入密钥对时，您必须再次提供此密码方可导入。

1.3. CER 

扩展名为 .cer 的文件采用 X.509v3 格式ASN.1 ，并由CA签名。这些文件中包含着一个公钥和额外的信息。这些文件一般用来提供给业务合作伙伴，以便他们能够使用公钥加密数据。

1.4. Java Key Store

Java Key Store（JKS）是Java语言中给出的一种密码保护的文件，可存储密钥和证书。JKS文件好比一个仓库，为防范别人随便乱拿，仓库可以设置一把锁，即JKS文件的密码（storepass）。仓库里可存放多种密钥，如公钥、私钥和密钥对（由配对公钥和私钥组成）。每个密钥都有一个名字，称为别名（alias）。仓库里的公钥只要你能进入仓库你就可以随便查看拿走，私钥则是有密码的（keypass），只允许有权限的人查看拿走。所以从JKS文件中读取公钥只需要知道JKS文件（仓库）的密码即可，但读取私钥时则还必须有私钥的密码[1]。