https服务的原理和实现

https详解

目前大部分大型网站已经全部切换到了https服务，所以很有必要了解整个https的原理，https是如何保证信息安全的。这里希望大家对以下部分名词有一定的了解：

• 数字证书
  是互联网通信中的身份标识(主要是用户身份信息和公钥)，一般由CA中心颁发，既CA认证中心，或第三方权威机构。数字证书上通常包括：CA的签名，证书所有人的公钥，CA中心的签名算法，指纹以及指纹算法，证书的唯一编号，版本，有效期等。
• 数字签名、签名算法
  对信息的摘要【通过hash算法/摘要算法/指纹算法计算的信息摘要/hash值】使用签名算法进行加密，得到的密文就叫做数字签名
• 指纹、指纹算法/摘要算法【hash值计算】
  对消息使用hash算法/摘要算法进行单向处理，获取一个固定长度的信息的摘要/hash值。
• 非对称加密
  可以使用公钥、私钥分解进行对应的加密、解密的算法，即加解密使用的是不同的一堆秘钥。
• 对称加密
  使用相同秘钥进行加解密的算法
• 公钥、私钥
  非对称加解密的一对秘钥。

https服务部署过程和原理

了解https的原理，最好的方法就是走一遍流程，理论上的流程和原理通过以下几点来解释：

1. 证书申请
2. 证书信任
3. 密文通信

证书的获取

https的关键之一就是ssl证书，为了保证证书的安全有效性，在各类委员会/厂商之间合作，通过类似圆桌会议来形成若干权威的认证机构【顶级认证机构可以有若干附属的二级、三级...认证机构】，想要得到受信任的证书，就需要向CA机构提交证书签名请求 (CSR, Certificate Signing Request)。过程如下：

1. 证书申请者【一般是公司、个人开发者等】需要使用加密算法【大部分是RSA算法】来生成公钥、私钥，其中私钥保存在服务器上，不提供给任何人。
2. 生成证书签名请求 (CSR, Certificate Signing Request)，需要提供一些申请者相关的信息【域名、公钥等信息】，发送给CA机构请求他们的签名，经过他们签名才能成为被信任的证书。
3. CA机构对申请者进行验证【这里不同类型收费不同，验证方式也会不同】，验证通过后，将会在证书中添加部分信息【证书颁发机构、有效期、指纹/hash算法、签名算法】，形成新的证书。
4. 对新的证书进行签名，步骤如下：
   • 对新证书按照指纹/hash算法进行hash值计算
   • 使用CA机构的私钥对计算出来的hash值按照签名算法进行加密，得出的密文就是数字签名；
   • 将数字签名放在证书的最后面【签名完成】，得到完整的证书，并返回给申请者；
   • 申请者获取签名证书，保证自己的HTTPS服务被信任。

所以最后的证书包括的内容如下：

• 证书的有效期
• 公钥
• 证书所有者（Subject）
• 签名所使用的算法
• 指纹以及指纹算法【hash算法】
• Version Number，版本号。
• Serial Number，序列号。
• 颁发机构
• 数字签名

客户端识别证书

在申请到受信任的证书后，客户端是怎么知道这些证书是值得信任的呢，不同浏览器和系统的具体实现不太一样，但是基本的方式差不多，都是在系统或者浏览器中事先准备好权威的CA机构的相关信息[公钥、常使用的各类hash、签名、加密算法等]。具体过程如下：

1. 浏览器访问某https服务，带上浏览器自身支持的一系列Cipher Suite（密钥算法套件，后文简称Cipher）[C1,C2,C3, …]发给服务器【算法套件包括非对称算法、对称算法、hash算法】；
2. 服务器接收到浏览器的所有Cipher后，与自己支持的套件作对比，如果找到双方都支持的Cipher【双方套件中都能支持的最优先算法】，则告知浏览器，并返回自己的证书；
3. 浏览器确认和服务端后续的密文通信的加密算法，同时对证书进行认证；
4. 使用证书中的认证机构【可能是二级、三级机构】的公钥【系统、浏览器事先准备好的】按照证书中的签名算法进行解密【认证机构使用私钥加密的密文只能通过该认证机构的公钥进行解密】，解密获取hash值；
5. 使用证书中的hash/摘要算法对证书信息【证书签名除外的信息[服务器公钥、有效期等]】hash值计算，和4中解密的hash值进行对比，如果相等，表示证书值得信任；【通过数字签名来保证证书内容没有被篡改】。

https的加密通信过程

在上文的流程之后【证书信任，客户端和服务端握手中需要的非对称算法、握手信息验证的hash算法、正文传输的对称加密】，就是具体的通信过程：

1. 客户端信任了服务端的证书，并和服务端确认了双方的加密算法【握手中需要的非对称算法、握手信息验证的hash算法、正文传输的对称加密】；
2. 客户端生成随机数，通过证书中的公钥按照约定的非对称加密算法进行加密，得到加密的随机数秘钥，同时将之前所有的通信信息【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，并使用随机数和协商好的对称加密算法进行签名加密，将随机数秘钥和加密签名发送到服务端。
3. 服务端收到随机数秘钥和加密签名，先使用私钥将随机数按照约定的非对称解密算法进行解密，获取随机数，同时使用随机数按照约定的对称解密算法进行解密，获取待验证的hash值，将之前的通信消息体【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，与刚才解密获取的待验证的hash值对比，验证加密成功与否。
4. 成功以后，服务器再次将之前所有的通信信息【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，并使用随机数和协商好的对称加密算法进行签名加密，将随机数秘钥发送到客户端，
5. 客户端使用随机数按照约定的对称解密算法进行解密，获取待验证的hash值，将之前的通信消息体【秘钥算法套件、证书等所有的通信内容】按照约定的hash/摘要算法获取hash值，与刚才解密获取的待验证的hash值对比，验证加密成功与否，
6. 成功的话整个链接过程完成，之后将使用随机数和约定的对称加密算法进行密文通信，【如果上面的任何步骤出现问题，都将会结束整个握手过程，导致建立安全连接失败】。