HTTPS协议详解

https是http over TLS（transport security layer）的缩写。也即说明http协议是不安全的，是TLS协议保证的安全。协议层级图如下:

我们常说https协议是安全的，主要是指两点：

• 第一，通信两端可以进行身份验证。
• 第二，数据传输过程安全。

既然提到身份验证和传输安全就不得不提加密算法和数字证书机制。

加密算法主要分为对称加密算法与非对称加密算法。所谓对称加密算法，加密、解密使用相同的密钥，常用的算法有：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK等。相应的非对称加密算法用于加密、解密的密钥是一对儿，如果用其中一个来加密，只能用另外一个来解密，反之亦然，常用的算法有：RSA、DSA、ECC、DH等。

TLS还涉及到到了摘要算法MAC(message authentication code)，用以确保传输过程中的数据没有被修改替换。摘要算法也需要一个密钥，不过这个密钥不是用来做加解密的，而是用来做生成摘要时的盐。摘要算法是一个单向函数，不能通过摘要反解出原内容。常用的算法有：CRC、MD5、SHA等。

数字证书是一个认证体系。我们经常接触的银行U盾，企业登陆社保公积金网站时用到的电子证书等， 都是数字证书。数字证书由CA（certificate authority）机构颁发，有有效期， 到期需要更换，且是付费的。证书的生成就是依赖上文所述的非对称加密算法。颁发一个证书就是生成一对密钥，然后用CA机构的数字证书（私钥）进行签名认证，以此来保证数字证书的合法性。私钥保留在申请者手里，要保证私钥绝对安全，不能被别人获取，所以我们会采用很多的方式来保护私钥。公钥则是对外公布使用的。

数字证书还有根证书、证书链两个概念。终端证书是由CA机构的证书进行签发的，那么CA机构的证书又是谁签发的？怎么验证CA机构证书的合法性？结构如下：

final certificate <--> CA certificate <--> CA certificate <--> CA.... <-->root certificate

终端证书由CA证书签发，这个CA证书由另外一个CA证书签发，循环往上，直至根证书。那么根证书由谁签发的呢？根证书是一个自签名证书。那么根证书怎么认证呢？这就靠相关实现自己维护了（比如以约定的方式：我说它是合法的根证书，它就是合法的根证书）。以chrome浏览器为例，chrome浏览器维护有一个根证书库：https://chromium.googlesource.com/chromium/src/+/main/net/data/ssl/chrome_root_store/root_store.md

然后chrome浏览器将根证书缓存在本地

数字证书验证过程如下（以浏览器为例），注意不是身份验证：

1. 浏览器访问某个服务器，要求服务器下发自己的数字证书（终端证书），实际上是下发证书链，但不包含根证书。
2. 浏览器从服务器证书开始，依次用后一个CA证书对前一个证书进行验证，直至最后一个CA证书，这时浏览器就从本地根证书池去查找这个CA证书的签发证书，进行验证。如果通过，则表明服务器证书合法。

数字签发过程是用私钥加密，验证过程是用公钥解密，如果能解析，则表明证书合法。

TLS本身分为两层，下层为record protocol，负责数据的传输，handshake protocol主要负责两端进行握手。

 Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

             Figure 1.  Message flow for a full handshake

client可以被理解为浏览器，server被理解为我们要访问的服务网站

• client向server发送一个ClientHello消息，信息主要包含：1.client支持的TLS版版，2.client支持的密码套件（cipher suite），就是我支持的对称加密算法有哪些、摘要算法有哪些等，3.一个随机数，4.支持的压缩算法。client会将自己最喜欢用的密码套件放在最前边儿。消息结构如下：

      struct {
          ProtocolVersion client_version;
          Random random;
          SessionID session_id;
          CipherSuite cipher_suites<2..2^16-2>;
          CompressionMethod compression_methods<1..2^8-1>;
          select (extensions_present) {
              case false:
                  struct {};
              case true:
                  Extension extensions<0..2^16-1>;
          };
      } ClientHello;

• server在接收到client的ClientHello消息后，会用自己支持的密码套件来匹配client发过来的密码套件，如果没有匹配上，则会给client返回一个握手失败的消息。作为对clientHello消息的回应，server回返回一个serverHello消息，信息主要包含：1.服务端选择的密码套件，2.一个服务端随机数，3.服务端选择的压缩算法。结构如下：

      struct {
          ProtocolVersion server_version;
          Random random;
          SessionID session_id;
          CipherSuite cipher_suite;
          CompressionMethod compression_method;
          select (extensions_present) {
              case false:
                  struct {};
              case true:
                  Extension extensions<0..2^16-1>;
          };
      } ServerHello;

• 紧接着，server向client发送一个certificate消息，内容主要为：server的数字证书链，结构如下：

      opaque ASN.1Cert<1..2^24-1>;

      struct {
          ASN.1Cert certificate_list<0..2^24-1>;
      } Certificate;

• 接着certificate消息，server向client发送serverKeyExchange消息，但是这个消息不是必须的，只有在certificate消息不包含交换“预主密码”（premaster secret）算法时，才会发送此消息。
• 紧接着server向client发送certificate request消息，这个消息也不是必须的。只有server端需要验证client身份时发送此消息，让client也将自己数字证书发送过来。
• 紧接着server向client发送serverHello done消息，告诉client我的serverHello相关信息都发送完了。
• client在接收到上述消息后，会根据上述数字证书认证流程对server进行身份验证。
• client如果收到了certificate request消息，这时候会向server发送client certifcate消息，将自己的数字证书发送给server。server端在收到数字证书后，对client的身份进行验证。
• client接着发送client key exchange消息，消息内容主要为“预主密钥”（premaster secret），client在生成premaster secret以后，会用server的数字证书（公钥）进行加密，然后发送给server端。
• client向server发送finished消息。
• server向client发送finished消息。
• client端和server端会根据达成的算法、随机数、premaster seceret分别生成master密钥（注意是分别生成的，但是是相同的）。master密钥就是我们需要的对称加密密钥。
• 握手结束。
• 后续的数据交互过程中，会对传输内容用master密钥进行加密，然后再用MAC算法进行签名。这样即做到了传输安全，又不至于消耗太多的计算力。

https://datatracker.ietf.org/doc/html/rfc2817

https://datatracker.ietf.org/doc/html/rfc2818

https://datatracker.ietf.org/doc/html/rfc3749https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.8

https://www.cloudflare.com/zh-cn/learning/ssl/what-happens-in-a-tls-handshake/

https://blog.csdn.net/Dancen/article/details/120979520