Https http原理及流程梳理

本文主要是介绍Https http原理及流程梳理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

HTTP请求都是明文传输的，所谓的明文指的是没有经过加密的信息，如果HTTP请求被黑客拦截，并且里面含有银行卡密码等敏感数据的话，会非常危险。为了解决这个问题，Netscape 公司制定了HTTPS协议，HTTPS可以将数据加密传输，也就是传输的是密文，即便黑客在传输过程中拦截到数据也无法破译，这就保证了网络通信的安全。

密码学基础

在正式讲解HTTPS协议之前，我们首先要知道一些密码学的知识。

明文： 明文指的是未被加密过的原始数据。

密文：明文被某种加密算法加密之后，会变成密文，从而确保原始数据的安全。密文也可以被解密，得到原始的明文。

密钥：密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥，分别应用在对称加密和非对称加密上。

1.对称加密：

对称加密又叫做私钥加密，即信息的发送方和接收方使用同一个密钥去加密和解密数据。对称加密的特点是算法公开、加密和解密速度快，适合于对大数据量进行加密，常见的对称加密算法有 AES DES、3DES、TDEA、Blowfish、RC5和IDEA。
其加密过程如下：明文 + 加密算法 + 私钥 => 密文
解密过程如下：密文 + 解密算法 + 私钥 => 明文
对称加密中用到的密钥叫做私钥，私钥表示个人私有的密钥，即该密钥不能被泄露。
其加密过程中的私钥与解密过程中用到的私钥是同一个密钥，这也是称加密之所以称之为“对称”的原因。由于对称加密的算法是公开的，所以一旦私钥被泄露，那么密文就很容易被破解，所以对称加密的缺点是密钥安全管理困难。

2.非对称加密：

非对称加密也叫做公钥加密。非对称加密与对称加密相比，其安全性更好。对称加密的通信双方使用相同的密钥，如果一方的密钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对密钥，即公钥和私钥，且二者成对出现。私钥被自己保存，不能对外泄露。公钥指的是公共的密钥，任何人都可以获得该密钥。用公钥或私钥中的任何一个进行加密，用另一个进行解密。
被公钥加密过的密文只能被私钥解密，过程如下：
明文 + 加密算法 + 公钥 => 密文， 密文 + 解密算法 + 私钥 => 明文
被私钥加密过的密文只能被公钥解密，过程如下：
明文 + 加密算法 + 私钥 => 密文， 密文 + 解密算法 + 公钥 => 明文
由于加密和解密使用了两个不同的密钥，这就是非对称加密“非对称”的原因。
非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密。
在非对称加密中使用的主要算法有：RSA、Elgamal、Rabin、D-H、ECC（椭圆曲线加密算法）等。

3、哈希算法

将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多，且算法不可逆。

例如：MD5、SHA-1、SHA-2、SHA-256 等

4、数字签名

签名就是在信息的后面再加上一段内容（信息经过hash后的值），可以证明信息没有被修改过。hash值一般都会加密后（也就是签名）再和信息一起发送，以保证这个hash值不被修改。

HTTPS通信过程

HTTPS协议 = HTTP协议 + SSL/TLS协议，在HTTPS数据传输的过程中，需要用SSL/TLS对数据进行加密和解密，需要用HTTP对加密后的数据进行传输，由此可以看出HTTPS是由HTTP和SSL/TLS一起合作完成的。

SSL的全称是Secure Sockets Layer，即安全套接层协议，是为网络通信提供安全及数据完整性的一种安全协议。SSL协议在1994年被Netscape发明，后来各个浏览器均支持SSL，其最新的版本是3.0

TLS的全称是Transport Layer Security，即安全传输层协议，最新版本的TLS（Transport Layer Security，传输层安全协议）是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。在TLS与SSL3.0之间存在着显著的差别，主要是它们所支持的加密算法不同，所以TLS与SSL3.0不能互操作。虽然TLS与SSL3.0在加密算法上不同，但是在我们理解HTTPS的过程中，我们可以把SSL和TLS看做是同一个协议。

HTTPS为了兼顾安全与效率，同时使用了对称加密和非对称加密。数据是被对称加密传输的，对称加密过程需要客户端的一个密钥，为了确保能把该密钥安全传输到服务器端，采用非对称加密对该密钥进行加密传输，总的来说，对数据进行对称加密，对称加密所要使用的密钥通过非对称加密传输。

以下图片来自于limboy的博客
这里写图片描述

HTTPS在传输的过程中会涉及到三个密钥：

    服务器端的公钥和私钥，用来进行非对称加密

    客户端生成的随机密钥，用来进行对称加密

一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。

    1. 客户端向服务器发起HTTPS请求，连接到服务器的443端口。

    2. 服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。

    3. 服务器将公开密钥证书发送给客户端，注意这个证书里面包含了公钥+各种信息+签名（私钥对各种信息加密后生成签名）。

    4. 客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么HTTPS传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性，关于客户端如何验证数字证书的合法性，下文会进行说明。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端AES 密钥,是对称加密的密钥.，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。

    5. 客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。

    6. 服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。

    7. 然后服务器将加密后的密文发送给客户端。

    8. 客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

  那么问题来了,客户端或者服务端如何确定发送过来的原文是否被修改过?

   1.在客户端发送数据时同时会有一个数字摘要,他是通过“原文 + client key ”通过哈希算法生成的"数字摘要" 然后通过公钥进行加密,生成数字签名.他会和加密后的原文一同被发送到服务端.

   2.服务端收到数据后,非对称加密的私钥解密“数字签名 ” 得到一个“数字摘要”.

   3.服务端收到数据后,同时通过AES 密钥 对原文的密文进行对称解密,得到原文,通过“原文 + client key ”通过哈希算法生成的"数字摘要" 将这个数字摘要同上一部中的数字摘要比较,如果相等,说明原文没有被修改过.

这是通过https 发送数据的过程,可以看到,既有对称加密,又有非对称加密.这里的私密密钥,就是客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性后,随机生成的.

 

数字证书

通过观察HTTPS的传输过程，我们知道，当服务器接收到客户端发来的请求时，会向客户端发送服务器自己的公钥，但是黑客有可能中途篡改公钥，将其改成黑客自己的，所以有个问题，客户端怎么信赖这个公钥是自己想要访问的服务器的公钥而不是黑客的呢？ 这时候就需要用到数字证书。

在讲数字证书之前，先说一个小例子。假设一个镇里面有两个人A和B，A是个富豪，B想向A借钱，但是A和B不熟，怕B借了钱之后不还。这时候B找到了镇长，镇长给B作担保，告诉A说：“B人品不错，不会欠钱不还的，你就放心借给他吧。" A听了这话后，心里想：“镇长是全镇最德高望重的了，他说B没问题的话那就没事了，我就放心了”。 于是A相信B的为人，把钱借给了B。

与此相似的，要想让客户端信赖公钥，公钥也要找一个担保人，而且这个担保人的身份必须德高望重，否则没有说服力。这个担保人的就是证书认证中心（Certificate Authority），简称CA。 也就是说CA是专门对公钥进行认证，进行担保的，也就是专门给公钥做担保的担保公司。 全球知名的CA也就100多个，这些CA都是全球都认可的，比如VeriSign、GlobalSign等，国内知名的CA有WoSign。

那CA怎么对公钥做担保认证呢？CA本身也有一对公钥和私钥，CA会用CA自己的私钥对要进行认证的公钥进行非对称加密，此处待认证的公钥就相当于是明文，加密完之后，得到的密文再加上证书的过期时间、颁发给、颁发者等信息，就组成了数字证书。

不论什么平台，设备的操作系统中都会内置100多个全球公认的CA，说具体点就是设备中存储了这些知名CA的公钥。当客户端接收到服务器的数字证书的时候，会进行如下验证：

    首先客户端会用设备中内置的CA的公钥尝试解密数字证书，如果所有内置的CA的公钥都无法解密该数字证书，说明该数字证书不是由一个全球知名的CA签发的，这样客户端就无法信任该服务器的数字证书。

    如果有一个CA的公钥能够成功解密该数字证书，说明该数字证书就是由该CA的私钥签发的，因为被私钥加密的密文只能被与其成对的公钥解密。

    除此之外，还需要检查客户端当前访问的服务器的域名是与数字证书中提供的“颁发给”这一项吻合，还要检查数字证书是否过期等。

验证公钥合法行

公钥证书是什么

https在建立通信时首先会采用非对称加密的方式传输数据
(这里的传输数据一般是随机生成的key 这个key用于后续的对称加密)
服务端会生成一对秘钥, 公钥和私钥
公钥交给客户端 私钥留给服务端自己
客户端在拿到公钥后 如何确保拿到的公钥就是想要访问的服务端的公钥呢?
这时就需要有一个公认的权威机构来证明, 公钥是来自指定的服务端的公钥

认证机构的工作

认证机构会生成一对秘钥, 公钥和私钥
公钥证书的生成包括了两部分内容

1. 数字签名
2. 服务器公钥

其中数字签名的生成过程是:

1. 服务器公钥 经过数字摘要算法 生成数字指纹
2. 把生成的数字指纹 在用认证机构的私钥加密 生成数字签名

https中客户端验证公钥证书的过程

服务器将公钥证书发送给客户端 客户端验证公钥证书 从而确保公钥的合法性

1. 客户端取出提前内置在手机内部的认证机构的公钥
2. 用认证机构的公钥去解密公钥证书里的数字签名 从而得到数字指纹
3. 客户端对公钥证书的服务器公钥进行 数字摘要算法 从而生成数字指纹
4. 对比客户端自己生成的数字指纹(第3步)和解密得到的数字指纹(第2步)是否一致 如果一致则公钥证书验证通过 就可以进行接下来的握手步骤了

 

HTTP 和 HTTPS 协议对比

1、HTTP 协议（HyperText Transfer Protocol，超文本传输协议）：是客户端浏览器或其他程序与Web服务器之间的应用层通信协议 。

2、HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：可以理解为HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL，用于安全的 HTTP 数据传输。

如上图所示 HTTPS 相比 HTTP 多了一层 SSL/TLS

SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。

TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。

参考: https://blog.csdn.net/xiaoming100001/article/details/81109617

         https://www.jianshu.com/p/14cd2c9d2cd2

         https://blog.csdn.net/iispring/article/details/51615631

         https://www.cnblogs.com/rinack/p/10743355.html

         https://www.jianshu.com/p/c5c178ddcf1c

这篇关于Https http原理及流程梳理的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---