HSTS VS 301 redirect

本文深入探讨HTTPS的工作原理,包括SSL通信过程、中间人攻击及其防御措施。同时,详细解析了HSTS(HTTP Strict Transport Security)的概念,以及如何在Nginx中配置301重定向和HSTS,对比HSTS与301重定向的区别与联系。

之前基于nginx为网站配置了HTTPS服务,配置过程中涉及到两个知识点:

  • 301 永久重定向
  • HTST(HTTP Transport Security Protocol)

本文主要是通过梳理一下相关概念,理清这两种配置的目的。

HTTPS

HTTPS,也称作HTTP over TLS,TLS的前身是SSL。HTTPS 相比 HTTP 提供了数据完整性、 数据隐私性和身份认证的功能。

SSL通信过程

  • 客户端发起一个HTTPS请求,提供客户端支持的加密算法和一个客户端随机数 client_random 给服务器
  • 服务器返回给客户端配置好公钥的证书和服务器随机数 server_random
  • 客户端验证公钥证书、比如是否在有效期内、域名是否匹配等;如果证书有效,客户端使用服务器提供的公钥加密加密随机数 premaster secret,发送给服务器
  • 服务器使用自己的私钥解密 premaster secret
  • 客户端和服务器将前面阶段的三个随机数,使用协商好的算法进行加密生成 master secret,后面双方通信使用这个对称密钥进行加密;

在nginx中的配置方法

  • 申请证书
  • 在nginx.conf中配置
    server {
        listen 443;
        server_name www.example.com; #填写绑定证书的域名
        ssl on;
        ssl_certificate /etc/nginx/sslconfig/1_www.example.com_bundle.crt;
        ssl_certificate_key /etc/nginx/sslconfig/2_www.example.com.key;
        ssl_session_timeout 5m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
        ssl_prefer_server_ciphers on;
        location / {
            root   html; #站点目录
            index  index.html index.htm;
            # proxy_pass http://$server_name:8920;
    }
    复制代码

中间人攻击(MitM)

中间人攻击(Man-in-the-middle attack,缩写:MITM)是指攻击者与通讯的两端分别建立独立的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方直接对话,但事实上整个会话都被攻击者完全控制并进行数据篡改和嗅探。

  • 代理服务器(mitmproxy):代理服务器 在HTTP和HTTPS通信中担任中间人的角色,在和客户端通信时它伪装成服务器,在和服务器通信时伪装成客户端,对两边的通信内容进行解码。代理服务器会生成伪造证书欺骗客户端,要使客户端信任伪造证书而不发出警告,需要在客户端手动将代理服务器注册为受信任的 CA。
  • SSL剥离(SSLsplit):SSL剥离中,攻击者 SSLStrip 也是担任中间人的角色,中间人和服务器之间维持HTTPS连接,而和客户端维持HTTP连接,也就是将 HTTPS 降级为 HTTP。由于 HTTP 是明文传输的,因此攻击者可以窃取通信内容。
  • 会话劫持(Session Hijacking):攻击者通过窃取或预测有效的会话令牌来破坏会话令牌,以获得对Web服务器的未授权访问。常用的窃取Cookie/会话令牌的方法有会话嗅探和跨站点脚本攻击等。
  • 防御:对于实际生活中的信件沟通和线上的信息交流来说,中间人攻击都是很难防范的,一些小建议:
    • 不要忽视浏览器弹出的证书警告!你可能访问的是钓鱼网站或者假冒的服务器
    • 公共网络环境下(例如公共WiFi),没有HTTPS加密的敏感网站不要随便登录,一般不可信
    • 在任何网站上登录自己的账号前确保网址是走的HTTPS加密协议

HSTS

HSTS,即HTTP Strict-Transport-Security。 当站点通过 HTTPS 运行的时候,服务器通过返回一个响应头部 Strict-Transport-Security ,强制浏览器以后使用 HTTPS 进行通信。

Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload
复制代码

一个网站接受一个 HTTP 的请求,然后跳转到 HTTPS ,用户可能在开始跳转前,通过没有加密的方式和服务器对话,这样存在中间人攻击潜在威胁,跳转过程可能被恶意网站利用来直接接触用户信息,而不是原来的加密信息。
HTST 是在初次通过访问 HTTPS 连接并返回安全头之后,浏览器记录下这些信息。有效期内,当浏览器再次试图通过 HTTP 与服务器建立连接只会返回307 Temporary Redirect ,浏览器禁止加载 HTTP 信息,并将连接重定向到 HTTPS 。一个测试的结果如下:

在nginx中配置响应信息

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
复制代码

浏览器返回结果

注意 HTST 是通过 HTTPS 响应头设置的,如果使用 HTTP 则会被忽略。一种解决的策略是 preload HTST。HSTS预加载是把你的网站和或域名放在一个被认可的hsts列表上,这个列表实际上是内置在浏览器中的。Google提供了这个列表服务,并由Chrome、Firefox、Opera、Safari、IE11和Edge使用,可以将你的站点提交到官方的HSTS预加载列表。

301 redirect

HTTP 301 永久重定向说明请求的资源已经被移动到了由 Location 头部指定的url上,是固定的不会再改变,搜索引擎会根据该响应修正,在 SEO 中301跳转对网站的权重会产生影响。
我们注意到,我们已经在nginx中已经配置了return 301 https://$server_name$request_uri,将HTTP请求重定向到HTTPS。但是,在前面的浏览器测试结果中,通过HTTP访问并没有显示301永久重定向,而是307临时重定向。实际上,301 仍然是发生的,301是服务器层面上的重定向,而307是浏览器层面上的重定向。我们通过 httpstatus 进行测试,可以看到直观的结果:

我们已经说明了HSTS和301的作用,但是我们可能仍然有些困惑:

  • 为什么已经使用 301重定向,还要使用 HSTS ?
  • 为什么大多数网站使用301重定向,而不用预加载HSTS替代?
区别与联系
  • HSTS覆盖域名,而301 redirect针对特定的URL Path;
  • HSTS设计的意义是为了解决安全问题,而301更多是为了解决重定向问题,后来被广泛用在从 HTTP 升级到 HTTPS 的过程中,并对网站搜索权重造成影响;
  • HSTS起作用是在至少访问过一次HTTPS且证书验证成功的情况下,在安全性要求较高的情况下我们强制使用 HTTPS,这需要进行预加载或者强制重定向;如果攻击者一直阻止网站建立HTTPS连接,HTST将不起作用;
  • 目前大多数网站使用HSTS时是结合301 redirect使用的而不是预加载,这可能是出于兼容考虑;
  • HSTS相比301 redirect,在性能和安全上可能有一些优势。301缓存和其他请求一样都是保存在浏览器缓存中,重定向会消耗性能;而HSTS保留在另一个单独的缓存列表中,可以保留更长时间而不被浏览器清除;
  • 中间人攻击可能利用重定向的时机进行介入,而HSTS 可以有效应对SSL剥离(HTTPS降级)导致的安全问题,但是对于其他类型的中间人攻击可能不起作用。
  • HSTS 常和 HPKP(HTTP Public Key Pinning) 结合使用, HPKP 允许 HTTPS 网站指定其信任的证书,并指示浏览器不允许任何连接到由任何其他证书保护的站点。

总之,中间人攻击不可能简单地通过某一种策略来完全阻止,但是聊胜于无,HSTS 仍然是个可行的安全策略。


参考了一些博客和讨论,如有错误欢迎指正。

参考资料

转载于:https://juejin.im/post/5d010fb0f265da1bb80c275a

<think>好的,用户现在想了解HTTP 301状态码的处理方法及影响。根据之前的对话,用户可能是在处理HTTPS重定向或API请求时遇到了问题。先看看用户提供的引用内容。 引用1提到使用301重定向到HTTPS时需要注意POST请求的问题,因为301可能导致方法从POST变为GET。用户可能是在配置全站HTTPS时遇到了这个问题,需要处理POST请求的正确重定向。 引用2详细说明了不同重定向状态码的历史和区别,尤其是302在HTTP/1.0中的问题。用户可能关心不同状态码的适用场景,特别是POST请求的处理。 引用3解释了301和302的区别,特别是搜索引擎优化方面的影响。用户可能想知道如何选择正确的状态码来维护SEO效果。 接下来,用户的问题明确询问301的处理方法和影响。需要从定义、处理步骤、注意事项、影响等方面展开,并结合用户之前的调试问题,比如Nginx配置或前端处理重定向的情况。 要确保回答结构清晰,分点说明。同时需要指出何时使用301,何时使用其他状态码,比如307或308来处理POST请求的重定向,避免方法改变。还要提到配置时的注意事项,如Nginx设置、HSTS,以及测试方法。 可能用户的实际场景是配置服务器重定向时遇到了POST请求被错误处理的问题,或者前端接收到301后出现意外行为。需要针对这些情况给出解决方案,比如使用308状态码,检查服务器配置,测试工具的使用等。 最后,相关问题部分需要涵盖常见问题,如POST请求处理、SEO影响、测试方法、与308的区别,以及HSTS的作用,帮助用户全面理解。</think>### HTTP 301 Moved Permanently 详解及处理方法 --- #### **一、301 状态码定义** HTTP 301 **永久重定向**表示请求的资源已永久移动到新位置,客户端(如浏览器、爬虫)应更新所有旧地址引用至新URL。主要特点: - **搜索引擎优化(SEO)**:旧页面权重转移至新URL[^3] - **客户端缓存**:浏览器会缓存重定向规则,后续请求直接跳转新地址 - **方法转换**:部分客户端可能将POST请求转为GET(需特别注意)[^1][^2] --- #### **二、常见触发场景** 1. 网站启用HTTPS强制跳转(HTTP→HTTPS) 2. 网站目录结构调整(如 `/old-path` → `/new-path`) 3. 域名更换(如 `example.com` → `newexample.com`) --- #### **三、处理方法与配置示例** ##### **1. Nginx 配置 301 重定向** ```nginx # HTTP → HTTPS 全局重定向 server { listen 80; server_name example.com; return 301 https://$host$request_uri; # 保留完整路径 } # 路径级重定向 location /old-page { return 301 /new-page; } ``` ##### **2. Apache 配置(.htaccess)** ```apache RewriteEngine On RewriteRule ^old-path/(.*)$ /new-path/$1 [R=301,L] ``` ##### **3. 编程语言实现(Java示例)** ```java response.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY); response.setHeader("Location", "https://new-url.com"); ``` --- #### **四、关键注意事项** 1. **POST 请求处理** 301可能导致POST自动转为GET(数据丢失)[^2],此时应改用: - **307 Temporary Redirect**:临时重定向且保留原始方法 - **308 Permanent Redirect**:永久重定向且保留原始方法(HTTP/1.1+) ```nginx # 安全保留POST方法的重定向 return 308 https://$host$request_uri; ``` 2. **HSTS 增强安全** 配合HTTP Strict-Transport-Security头强制HTTPS,减少中间人攻击风险: ```nginx add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; ``` 3. **测试与验证** - 使用`curl -vI http://example.com`检查响应头和状态码 - 浏览器开发者工具(Network标签)验证实际跳转逻辑[^3] --- #### **五、301 的影响** | 维度 | 说明 | |------|------| | **用户体验** | 自动跳转无感知,但首次加载增加1次往返延迟 | | **SEO** | 搜索引擎更新索引至新URL,旧链接权重转移(约需数周)[^3] | | **缓存** | 客户端长期缓存规则,需谨慎操作避免循环重定向 | | **API兼容性** | 部分客户端(如旧版SDK)可能不支持方法保留,需测试验证[^2] | --- ### **相关问题** 1. **POST请求被301重定向后数据丢失怎么办?** 改用307/308状态码保留请求方法,或在前端手动处理重定向逻辑[^2]。 2. **301与302状态码对SEO有何区别?** 301永久转移权重,302临时重定向不传递权重[^3]。 3. **如何测试重定向链是否合理?** 使用`curl -L -v http://example.com`跟踪最多50次跳转。 4. **308状态码与301有何区别?** 308强制保留原始请求方法(如POST),适用于API场景[^2]。 5. **HSTS如何避免SSL剥离攻击?** 通过响应头强制浏览器仅使用HTTPS,跳过HTTP请求阶段[^1]。 --- ### **关键引用** - 301重定向可能导致POST方法转换的兼容性问题[^1][^2] - 永久重定向对搜索引擎优化的长期影响[^3] - 308状态码在保留请求方法中的优势[^2]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值