超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。
为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS。为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。
一、HTTP和HTTPS的基本概念
HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。
HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。
HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。
二、HTTP与HTTPS有什么区别？
HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。
简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
HTTPS和HTTP的区别主要如下：
1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
HTTP、HTTPS在我们日常开发中是经常会接触到的。我们也都知道，一般 Android 应用开发，在请求 API 网络接口的时候，很多使用的都是 HTTP 协议；使用浏览器打开网页，也是利用 HTTP 协议。看来 HTTP 真是使用广泛啊，但是，HTTP 是不安全的。利用网络抓包工具就可以知道传输中的内容，一览无余。比如我经常会使用 Fiddler 来抓包，搜集一些有趣的 API 接口。
那么问题来了，如何保证 HTTP 的安全性呢？基本上所有的人都会脱口而出：使用 HTTPS 协议。99.9% 的人都知道 HTTPS 会将传输的内容进行加密，但是接着问具体加密的过程和步骤，很多人就哑口无言了。
为了防止出现这种尴尬的局面，所以今天你就要好好看看这篇的内容了。以后就可以装个逼，哈哈！
加密类型
先科普一下，加密算法的类型基本上分为了两种：
对称加密，比较有代表性的就是 AES 加密算法；非对称加密，经常使用到的 RSA 加密算法就是非对称加密的；
对称加密的意思就是说双方都有一个共同的密钥，然后通过这个密钥完成加密和解密，这种加密方式速度快，但是安全性不如非对称加密好。
举个例子，现在学霸小明这里有一道数学题的答案：123 。他想把答案传给自己一直暗恋的小红。所以他们双方在考试开考前，约定了一把密钥：456 。那么小明就把答案内容经过密钥加密，即 123 + 456 = 579 ，将 579 写在小纸条上扔给小红。如果此时别人捡到了小纸条，不知道他们是加密传输的，看到上面的 579 ，会误以为答案就是 579 ；如果是小红捡到了，她拿出密钥解密，579 - 456 = 123 ，得到了正确的答案。
这就是所谓的对称加密，加解密效率高，速度快，但是双方任何一方不小心泄露了密钥，那么任何人都可以知道传输内容了。
讲完了对称加密，我们看看啥是非对称加密。
非对称加密就是有两把密钥，公钥和私钥。私钥自己藏着，不告诉任何人；而公钥可以公开给别人。
经过了上次作弊后，小红发现了对称加密如果密钥泄露是一件可怕的事情。所以她和小明决定使用非对称加密。小红生成了一对公钥和私钥，然后把公钥公开，小明就得到了公钥。小明拿到公钥后，把答案经过公钥加密，然后传输给小红，小红再利用自己的私钥进行解密，得到答案结果。如果在这个过程中，其他人得到传输的内容，而他们只有公钥，是没有办法进行解密的，所以也就得不到答案，只有小红一个人可以解密。
因此，相比较对称加密而言，非对称加密安全性更高，但是加解密耗费的时间更长，速度慢。
对称加密和非对称加密的具体应用我还是深有体会的，因为所在的公司是做金融支付方面的，所以加解密基本上算是天天见了。
说完加密类型后，我们再来看看 HTTPS 。我们先来看一个公式： HTTPS = HTTP + SSL 从这个公式中可以看出，HTTPS 和 HTTP 就差在了 SSL 上。所以我们可以猜到，HTTPS 的加密就是在 SSL 中完成的。所以我们的目的就是要搞懂在 SSL 中究竟干了什么见不得人的事了？
这就要从 CA 证书讲起了。CA 证书其实就是数字证书，是由 CA 机构颁发的。至于 CA 机构的权威性，那么是毋庸置疑的，所有人都是信任它的。CA 证书内一般会包含以下内容：证书的颁发机构、版本证书的使用者、证书的公钥、证书的有效时间、证书的数字签名 Hash 值和签名 Hash 算法…
正好我们把客户端如何校验 CA 证书的步骤说下吧。 1). CA 证书中的 Hash 值，其实是用证书的私钥进行加密后的值（证书的私钥不在 CA 证书中） 2). 然后客户端得到证书后，利用证书中的公钥去解密该 Hash 值，得到 Hash-a ； 3). 然后再利用证书内的签名 Hash 算法去生成一个 Hash-b; 4). 最后比较 Hash-a 和 Hash-b 这两个的值，如果相等，那么证明该证书是对的，服务端是可以被信任的；如果不相等，那么就说明该证书是错误的，可能被篡改了，浏览器会给出相关提示，无法建立起 HTTPS 连接。除此之外，还会校验 CA 证书的有效时间和域名匹配等。
接下来我们就来详细讲一下 HTTPS 中的 SSL 握手建立过程，假设现在有客户端 A 和服务器 B ：
1. 首先，客户端 A 访问服务器 B ，比如我们用浏览器打开一个网页 https://www.baidu.com ，这时，浏览器就是客户端 A ，百度的服务器就是服务器 B 了。这时候客户端 A 会生成一个随机数1，把随机数1 、自己支持的 SSL 版本号以及加密算法等这些信息告诉服务器 B 。
2. 服务器 B 知道这些信息后，确认一下双方的加密算法，然后服务端也生成一个随机数 B ，并将随机数 B 和 CA 颁发给自己的证书一同返回给客户端 A 。
3. 客户端 A 得到 CA 证书后，会去校验该 CA 证书的有效性，校验方法在上面已经说过了。校验通过后，客户端生成一个随机数3 ，然后用证书中的公钥加密随机数3 并传输给服务端 B 。服务端 B 得到加密后的随机数3，然后利用私钥进行解密，得到真正的随机数3。
4. 最后，客户端 A 和服务端 B 都有随机数1、随机数2、随机数3，然后双方利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密，一般用的都是 AES 算法。
5. 客户端 A 通知服务端 B ，指明后面的通讯用对话密钥来完成，同时通知服务器 B 客户端 A 的握手过程结束。
6. 服务端 B 通知客户端 A，指明后面的通讯用对话密钥来完成，同时通知客户端 A 服务器 B 的握手过程结束。
SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户端 A 和服务器 B 开始使用相同的对话密钥进行数据通讯。
到此，SSL 握手过程就讲完了。可能上面的流程太过于复杂，我们简单地来讲：
客户端和服务端建立 SSL 握手：客户端通过 CA 证书来确认服务端的身份；互相传递三个随机数，之后通过这随机数来生成一个密钥；互相确认密钥，然后握手结束；数据通讯开始，都使用同一个对话密钥来加解密；
我们可以发现，在 HTTPS 加密原理的过程中把对称加密和非对称加密都利用了起来。即利用了非对称加密安全性高的特点，又利用了对称加密速度快，效率高的好处。
转载自https://baijiahao.baidu.com/s?id=1595441779997706095&wfr=spider&for=pc
https://blog.csdn.net/xionghuixionghui/article/details/68569282
