SSL/TLS学习-RSA

1、传输层安全协议

  安全套接字层SSL（secure socket layer）。
  传输层安全TLS（transport layer security）。
  SSL协议是Netscape公司在1994年开发的安全协议，广泛应用于基于万维网的各种网络应用（不限于万维网）。SSL作用在端系统应用层的HTTP和传输层之间，在TCP之上建立起一个安全通道，为通过TCP传输的应用层数据提供安全保障。
  SSL协议工推出3个版本：SSL1.0、SSL2.0、SSL3.0。于是IETF在SSL3.0基础上设计了TLS协议，为所有基于TCP的网络应用提供安全数据传输服务。不过由于SSL3.0和TLS之间存在加密算法上的差异，因此不能相互操作。他们是两个不同协议。
  TLS协议经历的版本：TLS1.0、TLS1.1、TLS1.2、TLS1.3；其中TLS1.2和TLS1.3应用更为广泛。严格来说SSL/TLS协议属于OSI-7层模型的会话层，在传输层TCP/UDP协议之上。

在Windows的网络设置里面可以看到本地网络传输层安全使用的那种方式。

  应用层协议中使用SSL/TLS最多的就是HTTP超文本传输协议，但并非仅用于HTTP，而是可用于任何应用层的协议。例如可以用于IMAP邮件存取的鉴别和数据加密。HTTP端口号为80，当http使用SSL安全服务时，端口是443、同时网址栏显示变为HTTPS。

2、SSL/TLS提供的安全服务

  SSL/TLS安全服务可归纳为一下三种

服务器鉴别，允许用户证实服务器的身份。支持SSL客户端通过验证服务器的证书，来鉴定服务器的真实身份并获得服务器的公钥。
客户鉴别，SSL的可选安全服务，允许服务器证实客户的身份。
会话加密，对客户端和服务器间发送的所有报文进行加密，并检测报文是否被篡改。

3、SSL工作过程

  以客户端A和服务器B举例。当A点击网站建立TCP连接后，先进行浏览器和服务器之间的握手协议，完成加密算法的协商和会话秘钥的传递，然后进行安全数据传输。过程如下（实际步骤要更加复杂）。

1、协商加密算法。①浏览器A向服务器B发送浏览器的SSL版本号和一些可选的加密算法。②B从中选定自己所支持的算法如（RSA），并告诉A。
2、服务器鉴别。③服务器B向浏览器A发送包含其RSA公钥的数字证书。④A使用该证书的认证机构CA公开发布的RSA公钥对该证书进行验证。
3、会话秘钥计算。由浏览器A随机产生一个秘密数。⑤用服务器B的RSA公钥进行加密发送给B。⑥双方根据协商的算法产生共享的对称会话秘钥。
4、安全数据传输。⑦双方用会话秘钥加密和解密他们之间传送的数据并验证其完整性。

4、SSL/TLS 握手协议

  TLS握手包括一下几个步骤：

  上图简要概述TLS握手过程，其中每一个方块都是一个记录（record），记录是TLS收发数据的基本单位，类似TCP里面的数据段。多个记录可以组成一个TCP包发送，所以通常经过四个消息就可以完成TLS握手，也就是需要2个RTT的延时，然后就可以安全的通信环境里发送HTTP报文。

  不同的秘钥交换算法，TLS的握手过程可能会有一些却别。考虑到性能，双方通信信息使用的是对称加密秘钥，为了对称秘钥的安全性，所以使用非对称加密的方式来保护对称加密密钥的协商，这个工作就是秘钥加密算法负责的。TLS用到的秘钥交换算法通常有RSA、ECDHE…。

4.1、RSA握手过程

  传统的TLS握手基本都是使用RSA算法来实现密钥交换的，在将TLS证书部署服务端时，证书文件中包含一对公私钥，其中公钥会在TLS握手阶段传递给客户端，私钥则一直留在服务端，一定要确保私钥不能被窃取。
  在 RSA 密钥协商算法中，客户端会⽣成随机密钥，并使⽤服务端的公钥加密后再传给服务端。根据⾮对称加密算
法，公钥加密的消息仅能通过私钥解密，这样服务端解密后，双⽅就得到了相同的密钥，再⽤它加密应⽤消息。
  wireshark工具抓包实例

TLS第一次握手

  客户端首先发一个client hello消息，消息里面有客户端使用的TLS版本号、支持密码的套件列表，以及生成的随机数client random，这个随机数会被客户端保留，他是生成对称加密秘钥的材料之一。

TLS第二次握手

  服务器收到客户端的client hello消息后，会确认TLS版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成随机数server random。
  接着服务器返回 server hello消息，消息里面有服务器确认的tls版本号，也给出了随机数server random，然后从客户端的密码套件列表选择了一个适合的密码套件。
  TLS第二次握手报文包含的内容比较多。有时候一个报文包含所有载荷，有时各个载荷单独发送。如果看到单独发送的载荷，莫要奇怪。

密码套件字段解读：规范形式是[密钥交换算法+签名算法+对称加密算法+摘要算法]，一般WITH单词前面有两个单词，第一个单词是约定秘钥交换算法，第二个单词是约定证书的验证算法。
Cipher Suite:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
解读为秘钥交换算法为ECDHE；
签名算法为RSA；
握手后通信加密使用的对称加密算法AES、秘钥长度128位
分组模式GCM
摘要算法SHA256

  客户端和服务器互相打招呼的过程都会各自产生一个随机数，并把随机数传给对方。随机数作用是后续生成会话秘钥（传输数据时使用的对称加密密钥）的条件。

  然后服务器证明自己的身份，发送server certificate给客户端，这个消息里含有数字证书。

  随后服务端发了server hello done消息，目的告诉客户端，我已经把该给你的东西给你了，本次招呼完毕。

TLS第三次握手

  客户端收到服务器的消息之后需要校验数字证书的有效性。

一个数字证书通常包含了

公钥；
持有者信息；
CA对这份文件的数字签名及使用的算法；
证书的有效期；
其他额外信息

  数字证书的的作用，是用来认证公钥持有者的身份，以防止第三方进行冒充。为了让服务器的公钥被大家信任，服务端的证书都是由CA（Certificate Authority ，证书认证机构）签名的，CA就是网络世界里的公安局、公正中心，具有极高的可信度，所以由它来给个公钥签名，信任的一方发的证书，那必然证书也是被信任。

数字证书签发和验证流程

如下图所示，为数字证书签发和验证流程

CA签发证书的过程，如上图左边部分：

⾸先 CA 会把持有者的公钥、⽤途、颁发者、有效时间等信息打成⼀个包，然后对这些信息进⾏ Hash 计算，得到⼀个 Hash 值；
然后 CA 会使⽤⾃⼰的私钥将该 Hash 值加密，⽣成 Certificate Signature，也就是 CA 对证书做了签名；
最后将 Certificate Signature 添加在⽂件证书上，形成数字证书；

客户端校验服务端的数字证书过程，如上图右边部分：

⾸先客户端会使⽤同样的 Hash 算法获取该证书的 Hash 值 H1；
通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使⽤ CA 的公钥解密 Certificate Signature 内容，得到⼀个 Hash 值 H2 ；
最后⽐较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

证书链

  实际中，证书的验证过程中存在一个证书信任链。我们想CA申请的证书一般不是根证书签发的，是由中间证书签发的。证书有三级：根证书，中间证书，百度证书。

客户端收到第3级证书后，发现这个证书的签发这不是根证书，无法根据的本地已有的根证书中的公钥去验证3及证书是否可信。
通过3及证书找到中间证书，最后找到根证书。
根据根证书的公钥验证中间证书，在根据中间证书的公钥验证3级证书。

  客户端验证完证书以后，认为可信则继续往下走。接着，客户端生成一个新的随机数pre-master用服务器的RSA公钥加密该随机数，通过change cipher key exchange消息传给服务端。

  服务端收到后，用RSA私钥解密，得到客户端发来的随机数pre-master。
  至此，客户端可服务端双方共享了三个随机数client random、server random、pre-master，双方根据三个随机数生成会话秘钥master sectet，它是对称秘钥，用于对后续的HTTP请求/响应的数据加密。
  生成会话秘钥后，客户端发一个change cipher spec告诉服务端开始用加密方式发送消息。

  然后，客户端在发一个**encrypted handshake message（finishd）**消息把之前数据做摘要，再用会话秘钥加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否有被中途篡改过。

  change cipher spec之前传输的TLS握手数据都是明文 之后的传输都是对称秘钥加密过的密文。

TLS第四次握手

  服务器也是同样的操作，发change cipher spec和encrypted handshake message消息，如果双方都验证加密和解密没有问题，那么握手正式完成。最后就用会话秘钥加解密HTTP请求和响应了。