https的一些原理知识

看了许多的文章，自己写了一点作为整理。

https = http + ssl/tls  + tcp

其中ssl 协议 叫做 安全套接字层（secret scoket layer ）

 

Ssl 建立连接（握手）： 需要用到    对称加密，非对称加密，hash 加密

对称加密的意思是  同一个密钥可以同时用作信息的加密和解密

非对称加密的意思   是 非对称加密算法需要两个密钥来进行加密和解密，这两个秘钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）

这两个的意思是

       1. 两边的算法规则一直 我用这个加密 你用这个解密 叫对称加密        

       2. 非对称是 两边的加密不一致 我用这个加密 你用另一个解密 但两个加解密的钥匙有联系

结论是 在建立ssl 协议连接中 使用的是非对称加密 ，而在连接完成后 使用的是对称加密 

  SSL握手过程

    A: 客户端 向服务器端发送一个 hello ，这个过程总会附带一个 客户端 使用RSA算法 生成的一个随机数 ，同时给出 我客户端有的ssl 协议版本号，支持的加密算法。（这些过程都是明文传递的，也就是外界可以获取到这个给出的ssl协议版本和算法还有客户端给出的随机数）

   B: 服务器端 接收到这个hello， 也返回一个由RSA 生成的一个随机数 给客户端，但同时会返回一个数字证书….（中包含服务器有的公钥）（在下面解释数字证书），这个过程服务器会选择最优的加密算法 确定ssl 版本。

   C: 客户端接受到 服务器发过来的 数字证书后 ，再生成一个随机数，把证书中的公钥取出来 给这个随机数做加密。

   D: 服务器 接受到这个加密后的数据，再用只存在服务器中的私钥器解密这个数据 得到客户端发过来的随机数 ，这个数据一般外部是拿不到的 （因为外部没有私钥，无法解开传输的数据），会话就是通过这三个随机数 生成最后的随机数 用于保证数据安全

    （为什么要三个随机数？ 为什么不要最后的那个随机数？ 由于ssl 设计 客户端不一定都能完全提供随机数，如果不随机的话解密的分险就变大了，所以会采用三个随机数去生成最后的随机数）

1. ssl 握手后 整个会话会采用三个随机数生成的来进行加解密，因为RSA 算法比较耗时，服务器会保留整个ssl 连接存到一个sessionID 或者 session ticket  ，如果断开的话 ，下次只要客户端给出这个sessionid而且服务器也有这个记录，双方就会使用现有的一对密钥 不会去重新生成新的。

3.数字证书 这个东西：

     Ssl 建立连接的时候 ，服务器会返回一个数字证书给客户端去使用 

    其中数字证书 包含了以下的信息:参考地址

    X.509 是较流行的ssl 数字证书标准 ，这中证书一般包含了下面这些信息：

  

字段	值说明
对象名称（Subject Name）	用于识别该数字证书的信息
共有名称（Common Name）	对于客户证书，通常是相应的域名
证书颁发者（Issuer Name）	发布并签署该证书的实体的信息
签名算法（Signature Algorithm）	签名所使用的算法
序列号（Serial Number）	数字证书机构（Certificate Authority， CA）给证书的唯一整数，一个数字证书一个序列号
生效期（Not Valid Before）	(｀·ω·´)
失效期（Not Valid After）	(╯°口°)╯(┴—┴
公钥（Public Key）	可公开的密钥
签名（Signature）	通过签名算法计算证书内容后得到的数据，用于验证证书是否被篡改

等等....

     证书中包含持有者信息等其他内容和公钥（由申请者提供）

      CA 制作证书一般会将内容（持有者信息等和公钥）先进行 hash加密后 再用CA 的私钥进行加密 得到数字签名 （Signature）放到证书中 ，和证书内容一起 制作成一个文件 就是数字证书。

       

      这时候 客户端接受到这样一份证书后，先对证书的内容 做hash 得到一个 H1  ,再用CA 的私钥去解密 证书中的数字签名 得到一个H2

  if (H1 == H2){

   证书是正确的没有被改过

}else{

   证书被修改过

}

回到 ssl 握手过程 服务器返回证书给 客户端 验证：

 

验证证书一般分两种 ：单项验证和双向验证 

    1. 单项验证：是客户端认证服务器端的提供的证书，一般的HTTPS网站都采用这种方式

    2.双向验证：客户端和服务器端都要认证对方的证书，一般是APP应用和它的服务器可能会采用这样的方式

客户端验证 服务端证书：

    证书是否过期

    发行服务器证书的CA是否可靠

    发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”

     服务器证书上的域名是否和服务器的实际域名相匹配

服务端验证客户端发来的证书：

      客户的证书使用日期是否有效

      为客户提供证书的CA是否可靠

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

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

这两步 在是否是单向还是双向的时候 插入ssl 协议握手过程中间

参考：

https://blog.csdn.net/duanbokan/article/details/50847612

https://www.jianshu.com/p/25efb6d8ec8c

https://www.jianshu.com/p/25efb6d8ec8c

https://www.cnblogs.com/oc-bowen/p/5896041.html

//ssl tls 部分

http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

http://oncenote.com/2014/10/21/Security-1-HTTPS/

http://oncenote.com/2015/09/16/Security-2-HTTPS2/#verify_safely