题 将http重定向到https是不是很糟糕?


我刚刚在我的服务器上安装了SSL证书。

然后,它会在端口80上为我的域上的所有流量设置重定向,以将其重定向到端口443。

换句话说,我所有的 http://example.com 现在,流量被重定向到适当的流量 https://example.com 页面版本。

重定向在我的Apache Virtual Hosts文件中完成,具有类似的内容......

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

我的问题是,使用SSL有什么缺点吗?

由于这不是301重定向,我将通过切换到搜索引擎中丢失链接汁/排名 https

我很感激帮助。我一直想在服务器上设置SSL,只是为了练习它,我终于决定今晚这样做。到目前为止它似乎运行良好,但我不确定在每个页面上使用它是否是个好主意。我的网站不是电子商务,不处理敏感数据;它主要是为了看起来和安装学习的快感。


更新后的问题

奇怪的是Bing现在从我的网站创建了这个截图,它在任何地方使用HTTPS ......

enter image description here 


245
2018-01-28 00:12




[WTF - 我不能添加答案(虽然我似乎有足够的代表)。]我的答案(部分)是那样的 有时候很糟糕。考虑通过HTTP在GET中传递COOKIE或API密钥。如果您的站点将HTTP请求重定向到HTTPS请求,这些调用将起作用,但COOKIE或API密钥将以明确的方式传输。有些API会关闭HTTP,这是一种更强大的方法 - 根本没有HTTP,所以除非你使用HTTPS,否则你甚至无法使用它。示例:“所有API请求必须通过HTTPS进行。通过普通HTTP进行的调用将失败” stripe.com/docs/api?lang=php#authentication - codingoutloud
@codingoutloud - 替代方案是 整件事情 通过HTTP发生,根本没有HTTPS。那怎么样更好? - Mark Henderson♦
@BenCrowell,那是因为a 俘虏门户 看起来非常像一个 sslstrip式重定向攻击(他们都是中间人请求劫持)所以 HSTS - 意识到的浏览器会阻止它们。 - Jeffrey Hantin
请注意,使用https意味着您包含的所有内容也应该是https或者可能无法加载 - 例如使用加载jquery src="://example.com/jquery.js"  - 注意缺乏 http 要么 https 所以浏览器加载适当的一个。我有一个噩梦试图让一些嵌入式亚马逊的东西正确加载,因为API(通过https加载)产生http链接 - 这意味着他们没有正常工作,直到我找到未记录的参数来切换https链接 - Basic
杰森;您的更新应该是一个新问题,可能是 网站管理员 因为它与你原来的问题无关(技术上)。但是你的样式表可能来自一个不安全的领域。 - Mark Henderson♦


答案:


[R] 旗帜本身就是一个 302 重定向(Moved Temporarily)。如果您真的希望人们使用您网站的HTTPS版本(提示:您这样做),那么您应该使用 [R=301] 永久重定向:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

一个 301 保留所有google-fu和来之不易的折扣 完整。确保 mod_rewrite 已启用:

a2enmod rewrite

要回答您的确切问题:

将http重定向到https是不是很糟糕?

一定不行。这很好。


309
2018-01-28 00:27



感谢您提供的信息,我的老板告诉我他只在他网站的某些页面上运行https的原因是,它使用了更多的服务器资源来在每个页面上运行它。你对此有所了解,或者这是真的吗? - JasonDavis
@jasondavis只有你不花几分钟时间 优化它。 - Michael Hampton♦
“它使用更多的服务器资源在每个页面上运行它。” 现代CPU具有加密加速功能,使SSL几乎免费。不要担心开销。 - Adam Davis
@AdamDavis加密算法可能是轻量级的,但握手开销仍然存在。此外,HTTPS可防止HTTP代理缓存您的内容。在 最 在这种情况下,HTTPS的开销很小而且值得,但要注意过度概括。 - 200_success
它会杀死共享缓存,这对某些网站的使用模式很有用,并且通常保护很少(人们可以知道您访问过该网站很重要,但不是您所做的详细信息吗?这是SSL有用的唯一情况)。 SSL在每个资源上的主要优点不是您需要“保护”,例如人们在看“关于我们”,但是你不能滑倒并且在你应该的情况下不能使用它。 - Jon Hanna


虽然我支持仅SSL站点的想法,但我会说一个缺点是开销取决于您的站点设计。我的意思是,例如,如果您在img标签中提供大量单个图像,这可能会导致您的网站运行速度慢很多。我会建议任何使用SSL服务器的人确保它们能够满足以下要求。

  1. 检查整个站点的内部链接,如果您在链接中指定了自己的域名,请确保它们都使用HTTPS,因此您不会导致自己的重定向。
  2. 更新你的 <meta property="og:url" 使用域名的https版本。
  3. 如果你使用 <base href= 再次更新以使用HTTPS。
  4. 安装 SPDY协议 如果可能的话
  5. 确保尽可能使用CSS Image sprite,以减少请求数。
  6. 更新站点地图以指示https状态,以便蜘蛛随着时间的推移了解此更改。
  7. 更改Google网站站长工具等搜索引擎首选项以优先使用HTTPS
  8. 尽可能将任何策略媒体卸载到HTTPS CDN服务器。

如果上述问题得到解决,那么我怀疑你会遇到很多问题。


49
2018-01-28 02:08



SPDY是一个很好的建议;甚至似乎有一个模块 向Apache 2.x添加SPDY支持。 - Calrion
使用“//yourserver.com/some-uri”代替“yourserver.com/some-uri“解决问题(1),因为浏览器将根据加载页面的架构选择适当的架构(http或https)。 - MauganRa
@MauganRa当然,除非是从http文章页面到https登录页面的链接。 - Mołot
Google会看到有人通过该网址访问的网址 Referer 头。例如,此网站使用来自Google的CDN的jQuery,我的浏览器每次重新加载网站时都会向Google发送请求。从而a Referer 标题也会发送给Google,并设置为此网站的网址。因此,Google可以在我的IP地址未更改期间跟踪我访问的网站(如果我在此期间使用Google服务,Google也可以将此信息与我的Google帐户相关联)。 - Stephan Kulla
1)我刚刚搜索并将我的MySQL数据库http替换为https ...我正在使用WordPress,因此它可以很容易地更新数百个链接 - JasonDavis


我已经设置了https,那么你应该在网站的任何地方使用它。您将避免混合内容问题的风险,如果您拥有所需的工具,为什么不让整个网站安全?

关于从http到https的重定向,答案并不那么简单。

重定向将使您的用户更容易,他们只需键入whateversite.com并重定向到https。

但。如果用户有时在不安全的网络上(或接近 特洛伊亨特和他的菠萝)?然后用户将请求 http://whateversite.com 出于旧习惯。那是http。这可能会受到影响。重定向可能指向 https://whateversite.com.some.infrastructure.long.strange.url.hacker.org。对于普通用户来说,它看起来非常合法。但是可以截获流量。

因此,我们在这里有两个相互竞争的要求:用户友好且安全。幸运的是,有一种称为的补救措施 HSTS标题。有了它,您可以启用重定向。浏览器将移动到安全站点,但由于HSTS标头也记得它。当用户键入位于该不安全网络的whateversite.com时,浏览器将立即转到https,而不会跳过http重定向。除非您处理非常敏感的数据,否则我认为这是大多数网站的安全性和可用性之间的公平权衡。 (当我最近设置一个处理医疗记录的应用程序时,我没有重定向就去了所有https)。遗憾的是,Internet Explorer不支持HSTS(资源),所以如果您的目标受众主要使用IE并且数据是敏感的,您可能希望禁用重定向。

因此,如果您不是针对IE用户,请继续使用重定向,但也要启用HSTS标头。


38
2018-01-28 07:40



更多人也需要关注这一点。另一件事是人们认为它们是安全的,因为终点是HTTPS,忽略了在GET或POST中发送到页面的所有信息都是纯文本的事实。 - Velox
@Velox - 我不认为“人们认为它们是安全的,因为终点是HTTPS,而忽略了在GET或POST中发送到页面的所有信息都是纯文本”这一事实非常准确。虽然有一些问题,但在通过HTTPS传输期间,GET查询参数不会明确地传播。参见例如: stackoverflow.com/questions/323200/... POST有效负载也受到保护,同时也不容易受到日志记录和引用标头的影响。 - codingoutloud
@codingoutloud那是我的观点。通过HTTPS,它们是加密的,但在对HTTP页面的初始请求中,它们不是。 - Velox
@Velox - 如果整个站点重定向到HTTPS,那么在HTTPS启动之前不太可能发送任何GET参数(并且在该点之后一切都将保持HTTPS)。还有一个初始请求,其中cookie将被发送,这可以通过HSTS来解决......以及SSLStrip的小型攻击窗口,这可能会被JavaScript击败,但这是它自己的军备竞赛。 - Brilliand
@Brilliand Fair点,但安全性的弱点使整个事情变得脆弱。总是值得考虑。 - Velox


这没有什么不妥,事实上这是最好的做法(对于网站而言 应该 通过安全连接提供服务)。事实上,你所做的与我正在使用的配置非常相似:

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

301 状态代码表示a 常驻 重定向,指示有能力的客户端使用安全URL进行未来连接(例如更新书签)。

如果您只通过TLS / SSL服务该站点,我建议使用另一个指令来启用HTTP 严格的运输安全 (HSTS)在你的 安全 虚拟主机:

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

这个标题指示有能力的客户(我相信他们中的大多数人)应该这样做 仅使用HTTPS 提供的域名(secure.example.com,在这种情况下)为下一个 1234 秒。该 ; includeSubdomains 部分是 可选的 并表示该指令不仅适用于当前域,还适用于其下的任何域(例如 alpha.secure.example.com)。请注意,HSTS标头是 只要 浏览器在通过SSL / TLS连接提供时接受!

要根据当前的最佳实践测试服务器配置,需要一个好的免费资源 Qualys的SSL服务器测试 服务;我的目标是至少得分A-(由于缺乏对椭圆曲线加密的支持,你无法获得比Apache 2.2更多的分数)。


22
2018-01-28 02:20



我应该添加,发送标题 Strict-Transport-Security: max-age=0 否定任何先前的指令;一如既往,这个 必须 通过HTTPS发送以接受,但如果您决定还需要在域上使用HTTP,则它是取消事物的便捷方式。 - Calrion


哇 !将HTTP重定向到HTTPS是一件非常好的事情,我看不出任何缺点。

只需确保您的客户拥有正确的CA,以避免在浏览器中出现有关证书的非用户友好警告。

此外,您设置Apache重定向到HTTPS的方式似乎还可以。


5
2018-01-28 00:35





将http重定向到https是不是很糟糕?

一点都不。实际上,这是一件好事!

在重定向上:

它可能更有效率 彻底消除了重写。这是我在类似情况下的配置......

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

5
2018-01-28 13:45





HTTPS并非完全万无一失。 当然,通常强制HTTPS是一件好事。 它可以防止正常的犯罪分子对您的用户做任何不好的事情。

但请记得检查SSL设置,如SSLCiphers设置。 禁用RC4加密,SSLv2和SSLv3协议等功能。 另外,你应该知道你的系统的加密系统libarys是否支持TLS1.2(这是你想拥有的东西;))

启用S​​SL,这是一件好事。


4
2018-01-28 07:43



熵没有用完(至少如果你是在抵御地球上的攻击者 而不是 做伏都教)。要么你从熵不足开始,你不能做任何需要随机性的事情,或者你从足够的熵开始,并且无论你产生多少随机性,你都会保持足够的熵。 - Gilles
抱歉, 什么?在Linux上有许多操作坚持硬件派生的强熵而不是基于PRNG的可能足够好的熵,如果池深度很低,那些操作确实会阻塞。当然可以在Linux系统上以足够的熵开始,但过度使用会耗尽池,导致某些操作被阻塞。 - MadHatter


就个人而言,我全都使用SSL来保护网络上的连接,但我觉得这里所有其他答案都遗漏的一点是,并非所有能够进行HTTP连接的设备和软件都能够使用SSL,因此,如果不支持它,我会考虑为用户提供一些避免它的方法。某些加密技术非法的国家/地区的人也可能无法访问您的网站。我会考虑添加一个未加密的登录页面,其中包含强制网站不安全版本的链接,但除非用户明确选择这样做,否则只需将其转发到HTTPS版本。


3
2018-01-28 10:13



像普通的HTTP登陆页面这样的解决方案存在的问题是,即使正确分离,该页面仍然可以进行操作。即,没有实际保证网站的HTTPS版本的链接完整地传递给访问者。 - Håkan Lindqvist


以下是一些广泛的笔触问题:

  • MITM / SSLSTRIP:这是一个巨大的警告。如果您要通过HTTPS为您的网站提供服务, 然后在网站上禁用HTTP。否则,您会让您的用户对包括SSLSTRIP在内的各种中间人攻击开放,这些攻击将拦截请求并通过HTTP安静地为其提供服务,并将自己的恶意软件脚本插入流中。如果用户没有注意到,那么他们就会注意到 认为 实际上它们的会话是安全的。

    • 但问题是,如果您的站点是公共站点而您只是毫不客气地禁用HTTP,则可能会丢失大量访问者。它可能不会 发生 如果站点不加载HTTP,则向他们尝试HTTPS。
  • 如果您的站点需要安全登录,则应保护整个用户会话。不要通过HTTPS进行身份验证,然后将用户重定向回HTTP。如果再次这样做,那么您的用户容易受到MITM攻击。这些天认证的标准方法是进行一次身份验证,然后来回传递身份验证令牌(在cookie中)。但是,如果您通过HTTPS进行身份验证,然后重定向到HTTP,那么中间人可以拦截该cookie并使用该站点,就好像他们是经过身份验证的用户一样,绕过了您的安全性。

  • HTTPS的“性能”问题仅限于创建新连接所涉及的握手。尽你所能最大限度地减少来自URL的多个HTTPS连接的需求,并且您将领先一步。即使您通过HTTP提供内容,坦率地说也是如此。如果您阅读了SPDY,您会发现它所做的一切都是为了尝试通过单个连接提供来自单个URL的所有内容。是的,使用HTTPS会影响缓存。但是现在有多少网站只是静态的,可缓存的内容呢?您可能会在Web服务器上使用缓存来获得更多收益,以最大限度地减少冗余数据库查询一次又一次地检索未更改的数据,并防止昂贵的代码路径执行超出必要的频率。


3
2018-04-19 10:43



你可以做的事情来实际解决 sslstrip 是使用HSTS(最好是 预先加载您的HSTS设置)。无论您是否通过普通HTTP接受请求在这方面实际上并不重要,即使您只接受HTTPS请求,MITM也可以通过普通HTTP(可能代理您的HTTPS站点)进行回答。 - Håkan Lindqvist
@HåkanLindqvist我真的赢了你的誓言?关于不通过HTTPS进行身份验证然后在剩余的会话中切换到HTTP,我是否提供了错误的建议或好的建议?我是否就HTTPS性能神话提供了不好的建议?此外,如果客户端最初尝试使用HTTPS进行连接,则MITM无法在不触发浏览器中的警报的情况下进行拦截和响应,因为除非他们的证书被盗或成功伪造,否则他们的证书将不匹配。另一方面,如果站点接受HTTP连接,则拦截更容易。无论哪种方式,HTTPS都会提高标准。 - Craig
..当然,我完全同意使用HSTS。 - Craig
答案的问题是列表中的第一项声称要解决sslstrip,而实际上并没有(说到神话)。我在初次评论中试图得到的是,如果你有一个活跃的MITM(这是你首先需要的sslstrip),攻击者从客户的角度来看基本上可以是“网站”;是攻击者决定是否要接受来自客户端的普通HTTP连接,您的实际Web服务器在这方面的行为方式不会影响攻击者可以或将要做的事情。 - Håkan Lindqvist
@HåkanLindqvist除非访问者有意尝试连接HTTPS,否则攻击者无法在浏览器中抛出标记而无法满足该请求,除非他们设法窃取服务器证书或以某种方式成功伪造服务器证书,他们将不得不为了将连接切换到HTTP。 HTTPS 仍然 提高了标准。当然,如果访问者通过HTTP进行初始连接尝试,则所有投注都将完全关闭。 - Craig


这在技术上不是您原始问题的答案,但如果您使用Google Chrome扩展程序HTTPSEverywhere(我确定其他浏览器上有类似的扩展程序),该扩展程序会自动将使用HTTP的网站重定向到使用HTTPS的同一网站。我已经使用了一段时间了,我没有遇到任何问题(除了可能减速,但我没有测试过)。 HTTPSEverywhere可以通过服务器端的某些规则进行更改,但由于我在该区域没有做太多,我不确定具体细节。

回到你的实际问题,如果你使用像HTTPSEverywhere这样的东西,那么使用HTTP的动机就更少,尽管我认为很难在你需要的时候设置正确的规则。


1
2018-01-28 04:27





通过HTTP获得HTTPS的唯一技术回归是,处理HTTPS请求比普通HTTP计算成本更高

然而,鉴于大多数现代服务器具有高功率CPU,这种影响通常可以忽略不计,除非您处于极高的流量水平,此时您很可能无论如何都要使用负载平衡器

随着像SPDY这样需要SSL / TLS工作的协议的出现,这实际上抵消了上述计算开销,通过在多个请求方面提供显着的性能改进并且整体上更快地将资产提供给客户端。


1
2018-01-29 11:55



HTTPS性能的问题在于建立新连接更加昂贵,因为涉及更多的往返,并且因为非对称加密/解密比对称加密/解密昂贵得多。一旦连接握手建立共享的对称加密密钥,持续的开销实际上是无关紧要的(非常小)。如果您阅读了SPDY,您会发现它所做的所有花哨内容的目标主要是通过单个连接提供来自URL的所有内容,从而减轻连接握手开销。 - Craig