HTTPS_请求响应会被篡改吗

什么是HTTPS（身披SSL协议这层外壳的HTTP）

HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版。HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了

HTTPS主要作用

（1）对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全;

（2）对网站服务器进行真实身份认证

为什么需要HTTPS

通信使用明文（不加密），内容可能被窃听
由于HTTP本身不具备加密的功能，所以也无法做到对通信整体（使用HTTP协议通信的请求和响应的内容）进行加密。即，HTTP报文使用明文（指未经过加密的报文）方式发送。

HTTP明文协议的缺陷是导致数据泄露、数据篡改、流量劫持、钓鱼攻击等安全问题的重要原因。HTTP协议无法加密数据，所有通信数据都在网络中明文“裸奔”。通过网络的嗅探设备及一些技术手段，就可还原HTTP报文内容。

无法证明报文的完整性，所以可能遭篡改
所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。由于HTTP协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。 换句话说，没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。

不验证通信方的身份，因此有可能遭遇伪装
HTTP协议中的请求和响应不会对通信方进行确认。在HTTP协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的IP地址和端口号没有被Web服务器设定限制访问的前提下）

HTTP协议无法验证通信方身份，任何人都可以伪造虚假服务器欺骗用户，实现“钓鱼欺诈”，用户无法察觉。

反观HTTPS协议，它比HTTP协议相比多了以下优势:

数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥
数据完整性：内容传输经过完整性校验
身份认证：第三方无法伪造服务端（客户端）身份

HTTP1.0 与HTTP1.1的区别

HTTP 1.1 引入 5 个特性

默认持久连接

HTTP/1.1 默认使用持久连接，TCP 连接默认不关闭，可以被多个请求复用。而 HTTP/1.0 默认使用短连接，要建立长连接， 可以在请求消息中声明 Connection:Keep-Alive。

** 管道机制**

客户端可以同时发送多个请求，而不用收到前一个响应之后再发出下一个请求，但服务器必须按照接收到客户端请求的先后顺序依次返回响应结果，以保证客户端能够区分出每次请求的响应内容

分块传输数据

HTTP/1.1 引入了分块传输方法。该方法使发送方能将消息实体分割为任意大小的组块，并发送它们。在每个组块前面，都加上了该组块的长度，使接收方可确保自己能够完整地接收到这个组块。最后发送方会发送长度为 0 的组块，表示消息发送完毕。

状态码 100 Continue

HTTP/1.1 加入了新的状态码 100 Continue，如果服务器因为权限拒绝了请求，就返回状态码 401；如果服务器接收此请求就返回状态码 100，客户端就可以继续发送带实体的完整请求了。

Host 域

在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址，这个 IP 地址上只有一个主机。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个 IP 地址。所以 HTTP1.1 在请求消息头中多了一个 Host 域。

HTTP2.0 相对HTTP1.1在性能上的改进

1. 头部压缩

   HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会 帮你消除重复的部分。

   这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表， 生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

2. 二进制格式

   HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是 二进制，并且统称为帧（frame）：头信息帧和数据帧。

3. 数据流

HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必 须要对数据包做标记，指出它属于哪个回应。 每个请求或回应的所有数据包，称为一个数据流（ Stream ）。每个数据流都标记着一个独一无二的编 号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数 客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。

4. 多路复用

HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟， 大幅度提高了连接的利用率。 举例来说，在一个 TCP 连接里，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程非常耗 时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。

Get 和 Post 的区别

• 使用范围：GET 一般用于获取或者查询资源信息，它是幂等的（对同一个 URL 的多个请求返回同样的结果） 和安全的（没有修改资源的状态），而 POST 一般用于更新资源信息。
• 传递数据：
  • 采用 GET 方法时，客户端把要发送的数据添加到 URL 后面，HTTP 协议没有对 URL 长度进行限制，但浏览器和服务器对 URL 的长度存在限制，所以传递的数据量有限；并且数据是明文出现在 URL 上面，所以一般只用于传输不敏感的信息。
  • 而 POST 把要传递的数据放到 HTTP 请求报文的请求体中；HTTP 协议也没有进行大小限制，起限制作用的是服务器的处理能力，传送的数据量比 GET 方法更大些； 由于传递的数据在消息体中， 安全性比 GET 高些
  • GET 请求的数据会被浏览器缓存起来，会留下历史记录；而 POST 提交的数据不会被浏览器缓存， 不会留下历史记录

POST过程中的 100 continue

HTTP/1.1 协议里设计 100 (Continue) HTTP 状态码的的目的是，在客户端发送 Request Message 之前，HTTP/1.1 协议允许客户端先判定服务器是否愿意接受客户端发来的消息主体（基于 Request Headers）。
即， 客户端 在 Post（较大）数据到服务端之前，允许双方“握手”，如果匹配上了，Client 才开始发送（较大）数据。
这么做的原因是，如果客户端直接发送请求数据，但是服务器又将该请求拒绝的话，这种行为将带来很大的资源开销。
协议对 HTTP客户端的要求是：如果 client 预期等待“100-continue”的应答，那么它发的请求必须包含一个 " Expect: 100-continue" 的头域！

HTTP常见请求方法

• GET：用于请求访问已经被 URI 识别的资源，可以通过 URL 传参给服务器。
• POST：用于传输信息给服务器，主要功能与 GET 方法类似，但一般推荐使用 POST 方式。
• PUT：传输文件，报文主体中包含文件内容，保存到对应 URI 位置。
• HEAD：获得报文首部，与 GET 方法类似，只是不返回报文主体。
• DELETE：删除文件，与 PUT 方法相反，删除对应 URI 位置的文件。
• OPTIONS：查询相应 URL 支持的 HTTP 方法

HTTP请求流程

浏览器与服务器之间将完成下列 7 个步骤：

• 建立 TCP 连接：在HTTP工作开始之前，浏览器首先要通过网络与服务器建立连接，该连接是通过 TCP 来完成的。
• 浏览器向服务器发送请求行：一旦建立了TCP连接，浏览器就会向服务器发送请求命令。例如：GET /sample/hello.jsp HTTP/1.1。
• 浏览器发送请求头：浏览器发送其请求命令之后，还要以头信息的形式向服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。
• 服务器应答：客户机向服务器发出请求后，服务器会客户机回送应答， HTTP/1.1 200 OK ，应答的第一部分是协议的版本号和应答状态码。
• 服务器发送应答头：正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。
• 服务器向浏览器发送数据：服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以 Content-Type 应答头信息所描述的格式发送用户所请求的实际数据。
• 发送完毕：TCP 连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

• SSL握手过程

1. ClientHello

   首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。

   SSL/TLS 协议版本, 客户端生产的随机数, 支持的密码套件列表

2. SeverHello

   服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello 。

   SSL/ TLS 协议版本, 随机数, 密码套件列表, 服务器的数字证书

3. 客户端回应

   客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的 真实性。

   随机数, 加密通信算法改变通知, 把之前所有内容的发生的数据做个摘要，用来供服务端校验

4. 服务器的最后回应

   服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的 「会话秘钥」。

   加密通信算法改变通知. 把之前所有内容的发生的数据做个摘要，用来供客户端校验。

HTTP返回码

1xx：指示信息–表示请求已接收，继续处理。

2xx：成功–表示请求已被成功接收、理解、接受。

200 OK 请求成功。一般用于GET与POST请求

3xx：重定向–要完成请求必须进行更进一步的操作。
301 Moved Permanently 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302 Found 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
304 Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
4xx：客户端错误–请求有语法错误或请求无法实现。
400 Bad Request 客户端请求的语法错误，服务器无法理解
401 Unauthorized 请求要求用户的身份认证
403 Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求
404 Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
5xx：服务器端错误–服务器未能实现合法的请求。
500 Internal Server Error 服务器内部错误，无法完成请求
501 Not Implemented 服务器不支持请求的功能，无法完成请求
502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503 Service Unavailable 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504 Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求
505 HTTP Version not supported 服务器不支持请求的HTTP协议的版本，无法完成处理

HTTP和HTTPS的区别

1. HTTPS基于传输层，HTTP基于应用层;

2. http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

3. http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全 .

4. HTTP 的端口号是 80，HTTPS 的端口号是 443。

5. HTTPS在浏览器显示绿色安全锁，HTTP没有显示;

HTTPS在TCP与HTTP中间加入了一层SSL/TLS层, 保证了信息加密, 校验机制防止被篡改, 身份证书保证访问网页的真实性.

混合加密

HTTPS在通信建立之前采用非对称加密的方式交换会话密钥, 后续就采用对称加密的方式进行加密数据

摘要算法

摘要算法用来保证数据信息的完整性, 客户端发送数据时, 会通过摘要算法算出数据的指纹信息, 并加入到数据中同时发送, 服务端采用同样的摘要算法进行计算指纹, 若两指纹信息相同, 则说明数据没有被修改

数字证书

客户端需要得到服务器的公钥, 然后用公钥进行加密, 服务端得到数据后使用自己的私钥进行解密, 得到对称加密的密钥.

• 数字证书就是保证服务器的公钥不被劫持, 篡改, 泄露.
• 能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名
• 数字签名能确定消息的完整性，证明数据是否未被篡改过

HTTPS比HTTP安全体现在？

1.HTTP协议通过SSL外壳来实现安全性：
数据加密，SSL协议通过非对称秘钥的方式来完成秘钥的协商，然后通过对称密钥的加密方式来完成数据的加密
2.验证对方的身份：服务端和客户端都会向CA机构申请证书，在SSL握手阶段，会去确认证书的可信度，从而验证对方的身份，防止第三方冒充
3. 保证数据的完整性，每次数据都会加上MAC摘要并签名，接受的数据和发送的数据，如果摘要信息是一致的，则表示该数据没有被篡改过

数字签名的制作过程：

• CA机构拥有非对称加密的私钥和公钥。
• CA机构对证书明文数据T进行hash。
• 对hash后的值用私钥加密，得到数字签名S。
• 明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。

浏览器验证过程：

• 拿到证书，得到明文T，签名S。
• 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S’。
• 用证书里指明的hash算法对明文T进行hash得到T’。
• 显然通过以上步骤，T’应当等于S‘，除非明文或签名被篡改。所以此时比较S’是否等于T’，等于则表明证书可信。

为什么制作数字签名时需要hash一次？

性能问题：非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加解密就快很多。

中间人有可能篡改该证书吗？

假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

既然不可能篡改，那整个证书被掉包呢？

假设有另一个网站B也拿到了CA机构认证的证书，它想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，这确实会导致上文“中间人攻击”那里提到的漏洞？

其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。

怎么证明CA机构的公钥是可信的？

数字证书是为了证明某公钥是可信的，即“该公钥是否对应该网站”，那CA机构的公钥是否也可以用数字证书来证明？没错，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中会有CA机构的根证书，这样就可以拿到它对应的可信公钥了。

实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链。也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。

另外，不知你们是否遇到过网站访问不了、提示需安装证书的情况？这里安装的就是根证书。说明浏览器不认给这个网站颁发证书的机构，那么你就得手动下载安装该机构的根证书（风险自己承担XD）。安装后，你就有了它的公钥，就可以用它验证服务器发来的证书是否可信了。

每次进行HTTPS请求时都必须在SSL/TLS层进行握手传输密钥吗？

服务器会为每个浏览器（或客户端软件）维护一个session ID，在TLS握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了

HTTPS如何保证信息可靠

• 保证消息不被篡改

  为了保证消息的内容不被篡改, HTTPS采用哈希算法将消息计算出一个指纹, 并与内容一同传输, 接收端接受到信息采用相同的哈希算法计算指纹, 对比成功即可保证消息内容没有被篡改.

• 保证消息来源可靠

  为保证消息没有被中间人替换, 采用非对称加密算法,也就是数字签名算法, 发送端使用私钥加密指纹信息, 若接收端可以通过公钥正常的解析出内容, 则证明消息来自拥有私钥的一端, 也就保证了来源可靠.

• 保证对方身份, 也就是保证公私钥没有被伪造.

  采用CA证书确认, CA将 [发送端信息+非对称加密的公钥+数字签名]使用自己的私钥加密, 打包成一个数字证书发送到接收端, 若证书可信, 则说明公钥可信, 于是可以使用公钥来解密消息.

HTTPS的加密方式

对称加密：加密和解密使用相同的密钥，如 DES，AES，3DES

非对称加密：使用两个密钥：公钥和私钥，用公钥加密，只有对应的私钥才能解密；而用私钥加密，只有用对应的公钥才能解密。如 RSA 算法等。

1. 混合加密

   HTTPS 采用的是对称加密和非对称加密结合的 「混合加密」 方式：

   在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。

   在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

   采用「混合加密」的方式的原因： 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但 速度慢。

2. 摘要算法

   摘要算法用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决了篡改 的风险。

   服务端通过摘要算法将数据重新生成指纹，两指纹匹配则说明数据没有被篡改

3. 数字证书

   客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

   这就存在些问题，如何保证公钥不被篡改和信任度？

   所以这里就需要借助第三方权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数 字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。

RSA算法

首先取两个不相等的质数p与q，并计算pq乘积n，n的二进制长度就是密钥的长度，计算n的欧拉函数值f，然后选出一个与f互质，且大小在1到f之间的数e，计算e模为f的逆元d，此时ed = 1 (mod f)

将n与e封装成公钥，n与d封装为私钥即可。

cookie 和 session的区别

cookie和session都是用来跟踪浏览器用户身份的会话方式。

cookie是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上 ， 它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。 cookie的作用就是为了解决HTTP协议无状态的缺陷所作的努力

Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。

Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。

• 存储位置不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
• 存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
• 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
• 存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。

ping得通，但是浏览器访问不成功。

ping得通，说明IP层没问题，服务器ip正常，问题可能在应用层或者传输层。

请求报文格式

请求报文主要由 4 部分组成：

• 请求行：由 3 部分组成：请求方法、URL 以及协议版本
• 请求头
• 空行：表示请求头部结束
• 请求正文，get 请求没有

响应报文格式

响应报文主要由 4 部分组成：

• 状态行：由 3 部分组成：协议版本，状态码以及状态码描述
• 响应头
• 空行
• 响应正文

为何不所有的网站都使用HTTPS

• 节约购买证书的开销
• 与HTTP的纯文本通信相比，HTTPS的加密通信会消耗更多的CPU及内存资源