计算机基础 HTTPS

原文地址: https请求过程

1. HTTPS请求过程

我们都知道HTTPS能够加密信息，以免敏感信息被第三方获取。所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。

HTTPS简介

HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，且看下图。

1. 客户端发起HTTPS请求

这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

2. 服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3. 传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4. 客户端解析证书

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5. 传送加密信息

这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6. 服务段解密信息

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息

这部分信息是服务段用私钥加密后的信息，可以在客户端被还原

8. 客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

2. HTTPS

原文来自《码出高效：Java 开发手册》

总结

HTTPS: HTTP over SSL，简单的理解就是在之前的 HTTP 传输上增加了 SSL 协议的加密能力。

其实就是建立公钥加密数据，私钥解密数据的过程

服务端的公钥加密数据，客户端的私钥解密数据

访问一个 HTTPS 的网站的大致流程如下：

（1）浏览器向服务端发送请求，请求中包括浏览器支持的协议，并附带一个随机数。

（2）服务器收到请求后，选择某种非对称加密算法，把数字证书签名公钥、身份信息发送给浏览器，同时也附带一个随机数。

（3）浏览器收到后，验证证书的真实性，用服务器的公钥发送握手信息给服务器。

（4）服务器解密后，使用之前的随机数计算出一个对称加密的秘钥，以此作为加密信息并发送。

（5）后续所有的信息发送都是以对称加密方式进行的。

1. Client Hello: Client支持的SSL版本，加密算法，秘钥交换算法，MAC算法等
2. Server Hello: Server确定采用的加密规则，分配会话ID
3. Certificate：Server发送证书信息
4. Server Key Exchange、Certificate Request 、Server Hello Done
5. 1. Certificate 2. Client Key Exchange 3. Certificate verify 4. Change Cipher Spec 5. Encryptcd Handshakc Message

• 第一，客户端发送了一个Client Hello协议的请求：在 Client Hello 中最重要的信息是 Clipher Suites 字段，这里客户端会告诉服务端自己支持哪些加密的套件。比如在这次 SSL 连接中，客户端支持的加密套件协议如图 1-29 所示。

• 第二，服务端在收到客户端发来的 Clien Hello 的请求后，会返回一系列的协议数据，并以一个没有数据内容的 Server Hello Done 作为结束。这些协议数据有的是单独发送，有的则是合并发送，这里分别解释几个比较重要的协议，如图 1-30 所示。

  （1） Server Hello 协议。主要告知客户端后续协议中要使用的 TLS 协议版本， 这个版本主要和客户端与服务端支持的最高版本有关。比如本次确认后续的 TLS 协议版本是 TLSvl.2 ，并为本次连接分配个会话 ID ( Session ID ）。此外，还会确认后续采用的加密套件（ Cipher Suite ）， 这里确认使用的加密套件为 TLS_ECDHE RSA WITH AES 128 GCM SHA256。该加密套件的基本含义为 ， 使用非对称协加密 （ RSA ） 进行对称协议加密 （ AES ）密钥的加密，并使用对称加密协议 （ AES ) 进行信息的加密。

  （2）Certificate (证书) 协议。主要传输服务端的证书内容。

  （3）Service Key Exchange (服务端秘钥交换)。如果在 Certificate 协议中未给出客户端足够的信息，则会在 Server Key Exchange 进行补充，如图 1-31 所示。比如在本次连接中 Certificate 未给出证书的公钥（Public Key），这个公钥的信息将会通过 Server Key Exchange 发送给客户端

  （4 ）Certificate Request (证书请求)。 这个协议是一个可选项 ，当服务端需要对客户端进行证书验证的时候 ，才会向客户端发送一个证书请求 （ Certificate Request ） 。

  （5 ）最后以 Server Hello Done 作为结束信息 ， 告知客户端整个 Server Hello 过程结束。

• 第三 ，客户端在收到服务端的握手信息后 ，根据服务端的请求 ，也会发送一系列的协议。

  （1）Certificate (证书)。它是可选项。因为上文中服务端发送了 Certificate Request 需要对客户端进行证书验证，所以客户端要发送自己的证书信息。

  （2）Client Key Exchange (客户端秘钥加密)。它与上文中 Server Key Exchange 类似，是对客户端 Certificate 信息的补充，在本次请求中同样是补充了客户端证书的公钥信息，如图 1-32 所示。

  （3）Certification Verity (认证证明)。对服务端发送的证书信息进行确认。

  （4）Change Cipher Spec (更改加密规范)。该协议不同于其他握手协议（Handshake Protocol），而是作为一个独立协议告知服务器，客户端已经接收之前服务端确认的加密套件，并会在后续通信中使用该加密套件进行加密。

  （5）Encrypted handshake Message。用于客户端给服务端加密套件加密一段Finish的数据，用以验证这条建立起来的加密通道的正确性。

• 第四，服务端在接收客户端的确认信息及验证信息后，会对客户端发送的数据进行确认，这里也分为几个协议进行回复。

  （1）Change Cipher Spec (更改加密规范)。通过使用私钥对客户端发送的数据解密，并告知后续将使用协商好的加密套件进行加密传输。

  （2）Encrypted handshake Message。与客户端的操作相同，发送一段 Finish 的加密数据验证加密通道的正确性。

最后，如果客户端和服务端都确认加密解密无误后，各自按照之前约定的 Session Secret 对 Application Data 进行加密传输。