从http到https--https请求过程

文章参考：
http://www.360doc.com/content/19/0228/16/59494473_818161915.shtml
http://jiaxf.github.io/2019/10/11/https%E8%AF%B7%E6%B1%82%E8%BF%87%E7%A8%8B/
(文中图片也来自于上述文章，但是360doc的链接是来源于51cto的，回头找51cto的文章也没找到，在此感谢360doc文章的原作者，应该是51cto的一位技术老哥了。)

从http到https

在http协议中，存在两台主机，其中A主机为客户机，B主机为服务器。当客户机发送给服务器hello的时候，如果使用的是http，那么hello是会在网上明文传输的，这样是非常不安全的。

虽然http中的明文传输问题很不好，但这并不是http协议最大的安全隐患，http协议最大的安全隐患是信息篡改和信息劫持。
我们通过下图可以看到具体的过程。

通过上图可以很清楚的看到，http在信息传输的过程中，信息很容易被中间人给劫持。更严重的情况是，中间人可以伪装成服务器，将篡改的信息返回给用户。
(1)信息篡改：修改通信的内容
(2)信息劫持：拦截到信息通信的内容。

http存在上述问题，那么如何解决这个问题呢？一个想得到的答案就是对信息进行加密。我加密了，我看你怎么偷看我的信息。这便有了https的诞生。
https=http+ssl，https就是http再套一层ssl保护壳，ssl的功能就是对信息进行加密。

https

我们知道，加密一般分为对称加密和非对称加密。所谓的对称加密就是AB进行通信，加解密使用的是相同的密钥。如下图所示。

当A发送给B字符hello的时候，在进行信息传输前，先使用密钥S对hello进行加密，加密成了JDuEW8&*21!@#进行传输。假如现在传输信道中间有坏人，他拿到的也只是加密的字符串，啥信息也得不到。
在现实生活中，上述的过程可能是这样的。

server和所有的client采用相同的密钥进行加密，但是这样还是不安全的，因为只要一个密钥泄露了，那就全完蛋了。所以真实的通信过程是每一台客户机与服务器进行通信所采用的密钥是不一样的。

如上图所示，A和server进行信息传输之前，先协商一下对称加密算法，但是问题来了！这条信息没被加密啊！因此还是存在安全风险的，那么怎么办呢？我们再对协商信息进行加密？不行！这样就是套娃，并不能解决问题，因为必然存在一次未加密的过程。

那么如何对协商进行加密而且还不会泄露信息呢？此时非对称加密上场了，xdm。

如何对协商进行加密？

密码学中除了对称加密以外，还有非对称加密。非对称加密的特点是使用私钥加密后的密文，使用公钥都可以解密。使用公钥加密的密文，只有私钥可以解密。私钥只有一个人有，但是公钥可以发给所有人。如下图所示：

基于上述过程，我们能得到：
(1)公钥是任何人都能获取的，私钥是需要保密的，而且存储在服务器端
(2)服务器向客户机传输信息是不安全的，因为所有人都能获取到公钥，虽然服务器使用私钥加密了信息，但是公钥谁都有，都能解密。
(3)但是client向sever传输信息是安全的，因为我用私钥不是人人都有的。
因此，上述的过程客户机向服务器发送信息进行协商就能解决协商的信息没能加密的问题。具体过程如下：

上述图片中的关键一步是③，对后续信息传输所采用的对称加密算法进行了加密然后传输，服务器知道这些信息后，所有的通信的障碍都扫除了。

对前面的内容做一个总结：
信息通信采用http是不安全的，存在信息劫持、篡改的风险。https是加密传输，是安全的通信，对于https加密的过程，我们首先介绍的对称加密，采用对称加密进行通信存在秘钥协商过程的不安全性，因此我们采用了非对称加密算法解决了对协商过程的加密，因此https是集对称加密和非对称加密为一体的加密过程

安全的获取公钥

细心的人(我不是)也许注意到了，如果使用非对称加密算法，公钥需要一开始就有，不然没法开展加密行为。
那么新的问题来了，如何让客户机安全的获取到公钥呢？一个直接的方法就是通过服务器将公钥发送给每一个主机，但是这地方又有不安全的点了。如下图所示：

如上图，客户机请求公钥，在请求返回的过程中被中间人劫持，那么我们将使用假的密钥进行通信，中间人获取后解密再使用从服务器获取的公钥进行通信，这就坏了。

那么如何解决这个问题呢？如何安全的获取公钥，并且保证公钥的获取是安全的呢？
噔噔蹬蹬，终极武器，SSL证书和CA机构。

如上图所示，在第②步的时候，服务器发送了一个SSL证书给客户端，SSL证书中包含具体的办法机构，有效期，公钥，证书持有者，签名。通过第三方的校验保证了身份的合法，解决了公钥获取的安全性。（第三方如何校验保证安全性，参考：https://www.cnblogs.com/xdyixia/p/11610102.html）
以浏览器为例说明如下整个校验过程：
(1) 首先浏览器读取证书中的证书所有者、有效期等信息进行——校验
(2) 浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
(3) 如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
(4) 如果找到，那么浏览器就会从操作系统中取出颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密
(5) 浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
(6) 对比结果—致，则证明服务器发来的证书合法，没有被冒充
(7) 此时浏览器就可以读取证书中的公钥，用于后续加密了

http与https的不同点

HTTP与HTTPS的不同点
1、HTTPS需要用到CA申请证书。
2、HTTP是超文本传输协议，信息是明文的；HTTPS则是具有安全性的SSL加密传输协议。
3、HTTPS和HTTP使用的是完全不同的连接方式，用的端口也不一样，HTTP是80,HTTPS是443。
4、HTTP的连接很简单，是无状态的，HTTPS是HTTP+SSL协议构建的，可进行加密传输、身份认证的网络协议，比HTTP协议安全。

HTTPS的优势
1、内容加密，建立一个信息的安全通道，来保证数据传输过程的安全性。
2、身份认证，确认网站的真是性。
3、数据完整性，防止内容被第三方冒充或者篡改。

另一个版本HTTPS的请求过程

1、浏览器发起往服务器的 443 端口发起请求，请求携带了浏览器支持的加密算法和哈希算法。
2、服务器收到请求，选择浏览器支持的加密算法和哈希算法。
3、服务器下将数字证书返回给浏览器，这里的数字证书可以是向某个可靠机构申请的，也可以是自制的。
（注释：证书包括以下这些内容：1. 证书序列号。2. 证书过期时间。3. 站点组织名。4. 站点DNS主机名。5. 站点公钥。6. 证书颁发者名。7. 证书签名。因为证书是要给大家用的，所以不需要加密传输）
4、浏览器进入数字证书认证环节，这一部分是浏览器内置的 TSL 完成的：
4.1 首先浏览器会从内置的证书列表中索引，找到服务器下发证书对应的机构，如果没有找到，此时就会提示用户该证书是不是由权威机构颁发，是不可信任的。如果查到了对应的机构，则取出该机构颁发的公钥。
4.2 用机构的证书公钥解密得到证书的内容和证书签名，内容包括网站的网址、网站的公钥、证书的有效期等。浏览器会先验证证书签名的合法性。
签名通过后，浏览器验证证书记录的网址是否和当前网址是一致的，不一致会提示用户。如果网址一致会检查证书有效期，证书过期了也会提示用户。这些都通过认证时，浏览器就可以安全使用证书中的网站公钥了。
4.3 浏览器生成一个随机数 R，并使用网站公钥对 R 进行加密。
5、浏览器将加密的 R 传送给服务器。
6、服务器用自己的私钥解密得到 R。
7、服务器以 R 为密钥使用了对称加密算法加密网页内容并传输给浏览器。
8、浏览器以 R 为密钥使用之前约定好的解密算法获取网页内容。