什么是Http？

Http是超文本传输协议的缩写（Hyper Text Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。在1990年，HTTP就成为WWW的支撑协议。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。

并且，HTTP 是一个无状态（stateless）协议，也就是说服务器不维护任何有关客户端过去所发请求的消息。这其实是一种懒政，有状态协议会更加复杂，需要维护状态（历史信息），而且如果客户或服务器失效，会产生状态的不一致，解决这种不一致的代价更高。

HTTP 协议通信过程

HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认端口为 80. 通信过程主要如下：

  1. 服务器在 80 端口等待客户的请求。
  2. 浏览器发起到服务器的 TCP 连接（创建套接字 Socket）。
  3. 服务器接收来自浏览器的 TCP 连接。
  4. 浏览器（HTTP 客户端）与 Web 服务器（HTTP 服务器）交换 HTTP 消息。
  5. 关闭 TCP 连接

HTTPS

背景–HTTP的缺点

作者：苏莉安
链接：https://www.zhihu.com/question/68302462/answer/269474847
来源：知乎

HTTP的明文传输带来的问题是无法防止中间人截获、盗取和篡改信息，从你的[路由器]、运营商到对方服务器，中间每一步都是明文。这里面可下手的地方太多了。

比如很多地方电信运营商就擅自给用户的网页插入浮动窗口广告，甚至影响正常浏览，不知情的用户还骂网站。其实这就是HTTP的明文特性导致的天然漏洞，对HTTPS网站则束手无策。因为后者只有用户和服务器能看到真实请求数据，对所有中间环节都加了密，自然也就无从篡改。

是不是好多人有微博账号莫名关注或点赞某些垃圾僵尸粉、营销号或者取关好友？在微博没有全站HTTPS化之前这种现象普遍存在。有人说是官方恶意给大号涨粉（官方肯定不承认，底下的人会不会收钱办事很难说），但各种证据表明绝大多数都是中间有人动了手脚，比如前面说的与运营商合作的营销公司。他们可以通过截获请求盗取并伪造你的身份信息来关注一票僵尸号或给某些营销微博点赞。方法也简单，把你本次成功访问微博的cookie存下来，直接用这个cookie发送关注别人的请求就行。

这种情况根本无需窃取你密码，也就无所谓密码大量泄露了。

对黑客和黑产从业者来说，除非你是个有影响力的大V或高价值账户才值得完全盗走。否则对千千万万普通用户而言，在无感知的情况下借用你的身份做一些事才是最有用的。

而那个「很厉害的黑客，黑了很多计算机」，其实根本用不到HTTP的明文特性就能窃取你的大量信息，因为人家黑的不是传输阶段，而是从起始阶段就下手了。无论你在中间怎么加密，在自己电脑总要有明文吧。

另外，那些著名的「某某网站几百几千万用户数据泄露」其实只是冰山一角，绝大部分泄露都不会被外界得知。有的跟网站私下交易，有的窃取完数据堵上漏洞就不管了，有的说不定站方从头到尾都没察觉到这件事。更何况网上流传的很多用户账号密码包根本就是在黑产圈内流传了几年连剩余价值都榨干了才出于炫耀或引导舆论的目的被扔出来的……

Tips：比如这篇参考的这篇文章所在的网站就没有使用HTTP加密，跳了好几个垃圾弹窗。可能或是嫌弃办理证书缴费太贵，或是嫌弃拖累网站速度。程序猿

HTTPS 的核心—SSL/TLS协议

HTTPS 之所以能达到较高的安全性要求，就是结合了 SSL/TLS 和 TCP 协议，对通信数据进行加密，解决了 HTTP 数据透明的问题。接下来重点介绍一下 SSL/TLS 的工作原理。

SSL 和 TLS 的区别？

SSL 和 TLS 没有太大的区别。摘自 [javaguide](HTTP vs HTTPS（应用层） | JavaGuide)

SSL 指安全套接字协议（Secure Sockets Layer），首次发布与 1996 年。SSL 的首次发布其实已经是他的 3.0 版本，SSL 1.0 从未面世，SSL 2.0 则具有较大的缺陷（DROWN 缺陷——Decrypting RSA with Obsolete and Weakened eNcryption）。很快，在 1999 年，SSL 3.0 进一步升级，新版本被命名为 TLS 1.0。因此，TLS 是基于 SSL 之上的，但由于习惯叫法，通常把 HTTPS 中的核心加密协议混成为 SSL/TLS。

SSL/TLS 的工作原理

首先科普知识点：

散列算法

散列算法，又称哈希函数，是一种单向算法。在信息安全技术中，经常需要验证消息的完整性，散列(Hash)函数提供了这一服务，它对不同长度的输入消息，产生固定长度的输出。这个固定长度的输出称为原输入消息的”散列”或”消息摘要”(Message digest)。散列算法不算加密算法，因为其结果是不可逆的，既然是不可逆的，那么当然不是用来加密的。

对某个数据包进行散列算法计算得到一个数字，称这个数值为摘要。

  • 常用散列算法MD5、SHA1、HMAC

  • 一个粗略的应用实例：我有一篇文章，用散列算法加密后为【4f2016c6b934d55bd7120e5d0e62cce3】。因为散列算法是单向的，所以不可能被逆向破解。我把这篇文章连带密文发给你，你拿到这篇文章后用散列算法计算，与密文比对。如果相等，说明文章内容没有被篡改。

加密算法

1. 对称加密算法

  • 特征是收信方和发信方使用相同的密钥，即加密密钥和解密密钥是相同或等价的。

  • 常用对称加密算法：DES, 3DES, AES。

  • 特点：运算开销小，但是bob给alice传递唯一密钥时会被中间人攻击造成数据泄露！

2. 非对称加密算法

公钥加密算法。其特征是收信方和发信方使用的密钥互不相同，而且几乎不可能从加密密钥推导解密密钥。

用公钥加密的过程叫加密

用私钥解密的过程叫解密

用私钥加密的消息称为签名，只有拥有私钥的用户可以生成签名

用公钥解密签名这一步称为验证签名（验签），所有用户都可以验证签名(因为公钥是公开的)

一旦签名验证成功，根据公私钥数学上的对应关系，就可以知道该消息是唯一拥有私钥的用户发送的，而不是随便一个用户发送的。

由于私钥是唯一的，因此数字签名可以保证发送者事后不能抵赖对报文的签名。由此，消息的接收者可以通过数字签名，使第三方确信签名人的身份及发出消息的事实。当双方就消息发出与否及其内容出现争论时，数字签名就可成为一个有力的证据。

常用非对称加密算法：RSA, ECC

  •  RSA非对称加密算法RSA是基于「大整数分解」这一数学困难问题的公钥密码体制，也就是说，对两个质数相乘容易，而将其合数分解很难。

  • 运算开销大，网络传播公钥不怕泄露。但是有漏洞。

客户端 C 和服务器 S 想要使用 SSL/TLS 通信，由上述 SSL/TLS 通信原理，C 需要先知道 S 的公钥，而 S 公钥的唯一获取途径，就是把 S 公钥在网络信道中传输。要注意网络信道通信中有几个前提：

  1. 任何人都可以捕获通信包
  2. 通信包的保密性由发送者设计
  3. 保密算法设计方案默认为公开，而（解密）密钥默认是安全的

因此，假设 S 公钥不做加密，在信道中传输，那么很有可能存在一个攻击者 A，发送给 C 一个诈包，假装是 S 公钥，其实是诱饵服务器 AS 的公钥。当 C 收获了 AS 的公钥（却以为是 S 的公钥），C 后续就会使用 AS 公钥对数据进行加密，并在公开信道传输，那么 A 将捕获这些加密包，用 AS 的私钥解密，就截获了 C 本要给 S 发送的内容，而 C 和 S 二人全然不知。

同样的，S 公钥即使做加密，也难以避免这种信任性问题，C 被 AS 拐跑了！

数字签名

我们先思考一下，现实中的签名有什么作用？

上图是一个现实中的签名，小明签下了姓名，我们从这份签名中可以知道两件事情：

  1. 签名者的身份为小明（通过笔迹鉴定可以确保其他人不能模仿）

  2. 签名者认可文件内容（小明认可了签名文件所在的这张”纸“数据内容没有被篡改）

这就是数字签名算法需要解决的两个问题。

  • 常用数字加密算法：RSA签名算法(包含RSA加密算法+哈希算法（散列）)，DSA, ECDSA。

  • 接下来主要介绍RSA签名算法。

刚才说非对称加密，把公钥公开用于他人对数据加密然后发给你，只有用你手上对应的私钥才能将密文解密。其实，私钥也可用用来加密数据的，对于 RSA 算法，私钥加密的数据只有公钥才能解开。

数字签名也是利用了非对称性密钥的特性，但是和公钥加密完全颠倒过来：仍然公布公钥，但是用你的私钥加密数据，然后把加密的数据公布出去，这就是数字签名。

你可能问，这有什么用，公钥可以解开私钥加密，我还加密发出去，不是多此一举吗？

是的，但是数字签名的作用本来就不是保证数据的机密性，而是证明你的身份，证明这些数据确实是由你本人发出的。

你的私钥加密的数据，只有你的公钥才能解开，那么如果一份加密数据能够被你的公钥解开，不就说明这份数据是你（私钥持有者）本人发布的吗？

当然，加密数据仅仅是一个签名，签名应该和数据一同发出，至于文件的完整性，我们用散列算法来保证。

具体流程应该是：

1、Bob 生成公钥和私钥，然后把公钥公布出去，私钥自己保留。

2、先将数据用哈希算法生成摘要，再用私钥加密摘要作为签名，然后将原始数据附带着签名一同发布出去。

3、Alice 收到数据和签名，需要检查此份数据是否是 Bob 所发出，于是用 Bob 之前发出的公钥尝试解密签名，将收到的签名解密后的数据哈希值和文件运算后的哈希值结果作对比，如果完全相同，说明数据没被篡改，且确实由 Bob 发出。

为什么 Alice 这么肯定呢，毕竟数据和签名是两部分，都可以被掉包呀？原因如下：

1、如果有人修改了数据，那么 Alice 解密签名之后，对比发现二者哈希值不一致，察觉出异常。

2、如果有人替换了签名，那么 Alice 用 Bob 的公钥只能解出一串乱码，显然和数据不一致。

3、极端情况：有人篡改了数据，然后将用山寨的公-私钥生成按上述流程和篡改数据制成签名，使得 Alice 的对比无法发现不一致；也就是说，Alice无法知道，互联网上哪个公钥是真的，谁才是真正私钥的拥有者。

一旦涉及公钥的发布，接收方就可能收到中间人的假公钥，进行错误的认证，这个问题始终避免不了。

说来可笑，数字签名就是验证对方身份的一种方式，但是前提是对方的身份必须是真的… 这似乎陷入一个先有鸡还是先有蛋的死循环，要想确定对方的身份，必须有一个信任的源头，否则的话，再多的流程也只是在转移问题，而不是真正解决问题。

公钥数字证书

为了解决非对称加密公钥传输的信赖性问题，第三方机构应运而生——证书颁发机构（CA，Certificate Authority）。CA 默认是受信任的第三方。CA 会给各个服务器颁发证书，证书存储在服务器上，并附有 CA 的电子签名。

证书其实就是公钥 + 签名，由第三方认证机构颁发。引入可信任的第三方，是终结信任循环的一种可行方案。

证书认证的流程大致如下：

1、Bob 去可信任的认证机构证实本人真实身份，并提供自己的公钥。

2、CA机构在核实Bob身份后，CA自己也声称一套公钥和私钥，使用私钥将【Bob身份信息及其公钥数据】这一文件内容进行数字签名（哈希运算，私钥加密），并放到数字证书中，该证书就相当于文件数据（Bob身份和公钥）和数字签名的组合体。

3、Alice 想跟 Bob 通信，首先向认证机构请求 Bob 的公钥，认证机构会把证书发送给Alice（或直接由小明给alice）。ps：每个人的电脑和手机系统里，默认安装了根证书，里面记载了可以信赖的CA机构信息及其公钥，预装在系统中可以杜绝CA机构公钥被伪造的可能。

4、Alice 检查签名，将公钥与签名运算，得到哈希值，与文件运算得来的哈希值进行对比。确定该公钥确实由这家认证机构发送，中途未被篡改。

5、Alice 通过这个公钥加密数据，开始和 Bob 通信。

PS：以上只是为了说明，证书只需要安装一次，并不需要每次都向认证机构请求；一般是服务器直接给客户端发送证书，而不是认证机构。

也许有人问，Alice 要想通过数字签名确定证书的有效性，前提是要有该机构的（认证）公钥，这不是又回到刚才的死循环了吗？

我们安装的正规浏览器中都预存了正规认证机构的证书（包含其公钥），用于确认机构身份，所以说证书的认证是可信的。

Bob 向机构提供公钥的过程中，需要提供很多个人信息进行身份验证，比较严格，所以说也算是可靠的。

获得了 Bob 的可信公钥，Alice 和 Bob 之间的通信基于加密算法的保护，是完全无懈可击的。

再回到最开始的工作原理

一句话总结：SSL/TLS实现—–>（数字证书+RSA密钥交换+对称加密）

RSA无论是加密还是解密，一般都要比同长度的AES（一种非对称加密算法）慢很多，因此，两端传输一般优先用RSA来加密对称算法的密钥，然后通信双方再通过对称算法密钥来进行大量的信息传输工作。

  1. 首先，由接收方创建RSA密钥对，接收方通过网络发送RSA公钥到发送方，同时保存RSA私钥。

  2. 而对方则用发送方公开的公钥来解密，检验其身份的唯一性。确认发送方身份为该公开公钥的私钥持有者以后，则用双方约定的AES来进行加密。

  3. 即，先用RSA来加密对称算法的密钥，然后通信双方再通过对称算法密钥来进行大量的信息传输工作。

这里就可以看到私钥加密的作用：认证对方的合法性，任何拥有CA公钥的个体，都可以解开数字签名，来验证信息是否安全可信。**

这样一来，传统的中间人攻击就几乎没有了生存空间，攻击手段只能由技术缺陷转变为坑蒙拐骗。事实上，这种手段的效果反而更高效，比如我就发现网上不少下载网站发布的浏览器，不仅包含乱七八糟的导航和收藏网址，还包含一些不正规的认证机构证书。任何人都可以申请证书，这些不正规证书很可能造成安全隐患。

HTTP vs HTTPS区别

  • 端口号 ：HTTP 默认是 80，HTTPS 默认是 443。
  • URL 前缀 ：HTTP 的 URL 前缀是 http://，HTTPS 的 URL 前缀是 https://。
  • 安全性和资源消耗 ： HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。