是否有任何理由不在网站上实施HTTPS？

我经常访问的网站最终决定对服务器启用TLS，但并没有像许多其他网站那样强制要求使用TLS。维护者声称TLS 必须是可选的。为什么？

在我自己的网站上，我长期设置了强制性的TLS和HSTS，并且较弱的密码套件已禁用。保证使用HTTP 301将纯文本访问隔离到受TLS保护的版本。这会对我的网站产生负面影响吗？

有几个使用TLS的充分理由

（只有少数的边际原因不这样做）。

• 如果该站点具有任何身份验证，则使用HTTP暴露来窃取会话和密码。

• 即使在静态的信息站点上，使用TLS也可以确保没有人篡改数据。

• 自Google I / O 2014以来，Google采取了一些措施来鼓励所有站点使用HTTPS：

  • Google一直在帮助网站管理员配置更安全的服务器，但也使用HTTPS作为排名信号。
  • 最近，谷歌Chrome已经开始标志着HTTP网站的非安全，作为一个长期计划，以纪念所有的HTTP网站的非安全的一部分。
  • Google Chrome开发人员小组在 Mythbusting HTTPS讲座中明确说明了他们的态度。

• Mozilla安全博客还宣布弃用不安全的HTTP，将所有新功能仅提供给安全网站使用，并逐步淘汰对非安全网站的浏览器功能的访问，尤其是那些对用户的安全和隐私构成风险的功能。

强制执行TLS的理由也很多

如果您已经拥有广受信任的证书，为什么不总是使用它呢？实际上，当前所有的浏览器都支持TLS并安装了根证书。我多年来实际看到的唯一兼容性问题是Android设备，并且缺少中间证书颁发机构，因为Android仅直接信任根CA。通过将服务器配置为将证书链发送回根CA，可以很容易地避免这种情况。

如果您的维护者仍希望允许HTTP连接不进行直接连接301 Moved Permanently，例如说要确保从某些真正的旧浏览器或移动设备进行访问，那么浏览器将无法得知您甚至已经配置了HTTPS。此外，你不应该部署HTTP严格传输安全（HSTS）无301 Moved Permanently：

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

为Tor计划和Electronic Frontier Foundation识别了同时为这两种协议配置的各种站点的问题，并通过多浏览器HTTPS Everywhere扩展解决了该问题：

Web上的许多站点都对HTTPS加密提供了有限的支持，但使它难以使用。例如，它们可能默认为未加密的HTTP，或使用返回到未加密站点的链接来填充加密页面。

由于可能通过修改通过非安全HTTP连接加载的JavaScript或CSS对HTTPS站点进行XSS攻击，因此混合内容也是一个巨大的问题。因此，如今所有主流浏览器都会警告用户有关内容混合的页面，并拒绝自动加载。这使得在没有301HTTP重定向的情况下很难维护站点：您必须确保每个HTTP页面仅加载HTTP连接（CSS，JS，图像等），并且每个HTTPS页面仅加载HTTPS内容。两者上的内容相同时，要做到这一点非常困难。

在当今时代，TLS + HSTS是您的网站由专业人士管理的标记，这些人士可以信赖他们知道自己在做什么。正如Google所证明的那样，这是一种新兴的可信赖性最低标准，这表明它们将为这样做的网站提供积极的排名。

另一方面是最大的兼容性。那里仍然有较老的客户，尤其是在世界上不是美国，欧洲或中国的部分地区。普通HTTP永远是可行的（虽然并不总是工作良好，这是另一回事）。

TLS + HSTS：针对搜索引擎排名进行优化
普通HTTP：针对兼容性进行优化

取决于对您而言更重要的事情。

简单的只读网站不使用HTTPS的一个很好的理由。

• Web缓存无法缓存通过HTTPS传输的图像。
• 世界上某些地区的国际连接速度很慢，因此取决于缓存。
• 从另一个域托管图像需要一些技巧，这些是小型只读网站的运营商所无法拥有的。

维护者声称TLS必须是可选的。为什么？

要真正知道该问题的答案，您必须问他们。但是，我们可以做出一些猜测。

在公司环境中，IT部门通常会安装防火墙，以检查传入和传出的流量中是否存在恶意软件，可疑的CnC类活动，被认为不适合工作的内容（例如色情内容）等。在对流量进行加密时，这变得更加困难。本质上有三种可能的响应：

1. 放弃监视此流量。
2. 在用户计算机上安装根CA，以便您可以执行MitM解密和检查。
3. 批发阻止加密流量。

对于相关的系统管理员，这些选项都不是特别有吸引力。有很多威胁可以攻击公司网络，保护公司免受这些威胁是他们的工作。但是，完全阻止许多站点会激起用户的厌恶，并且安装根CA可能会让人感到有些草草，因为它引入了用户的隐私和安全注意事项。我记得当他们第一次打开HSTS时看到（很抱歉，找不到线程）sysadmin请愿reddit，因为他正处于这种情况下，并且不想仅仅因为他被企业强迫而阻止所有reddit阻止以色情为重点的subreddits。

技术的车轮不断向前发展，您会发现许多人认为这种保护是过时的，应该逐步淘汰。但是仍然有很多人在实践它，也许是您神秘的维护者所关心的人。

所有这些都取决于您的安全要求，用户选择以及隐式降级的风险。在很大程度上必须禁用服务器端的旧密码，因为浏览器会以用户体验/便利的名义高兴地掉入绝对可怕的密码客户端。当然，确保使用不安全的方法无法到达依赖于用户安全通道的任何信息，这也是非常合理的。

当我认为您的博客文章中关于您为什么比Ruby更喜欢Python的消息（不是说您这样做，只是一个通用示例）时，我不容许我明确降级到不安全的HTTP，我不认为这是鬼怪或公众知道的假设HTTPS对我来说是微不足道的，我访问的原因就没有充分的理由。

如今，有些嵌入式系统无法立即使用TLS，或者有些系统滞留在旧的实现中（我认为这样做是非常糟糕的，但是作为[insert Embedded设备]，有时我无法更改此设置）。

这是一个有趣的实验：尝试使用足够旧的TLS / SSL实现通过HTTPS从上游OpenBSD站点下载LibreSSL的最新版本。您将无法。前几天，我在具有2012年左右或更早版本的OpenSSL版本的设备上进行了尝试，因为我想将此嵌入式系统升级到更安全的，来自源代码的新内容-我没有预装的豪华包。我尝试时的错误消息不是很直观，但是我认为这是因为我的旧版OpenSSL不支持正确的东西。

这是唯一的HTTPS举动实际上会对人们造成不利影响的一个示例：如果您没有最近使用的预构建软件包的奢侈，并且想通过从源代码构建自己解决问题，那么您将被锁定在外。幸运的是，在LibreSSL的情况下，您可以回退到显式请求HTTP的位置。当然，这不会使您免遭已经重写流量的攻击者的攻击，该攻击者能够用受感染的版本替换源程序包并重写HTTP正文中的所有校验和，以描述可在您浏览的网页上下载的程序包，但是在许多情况下它仍然非常有用更常见的情况。

我们大多数人都不是APT（高级持久线程：国家情报机构的安全术语和其他资源极为丰富的网络威胁）所拥有的不安全下载。有时我只想要wget一些纯文本文档或一个小程序，我可以将其源代码快速审核（例如，我在GitHub上的我自己的小实用程序/脚本）到不支持最新密码套件的机器上。

就个人而言，我会问：您的内容是否可以使一个人合理地决定“我可以接受我成为公众知识”？对于非技术人员而言，是否意外地将您的内容降级为HTTP，是否有可能带来真正的风险？权衡您的安全要求，对用户的强制性隐私要求和隐式降级的风险，以了解了解风险的用户的能力，这些能力应根据具体情况做出明智的选择，以使其不受担保。完全有理由说，对于您的站点，没有充分的理由不执行HTTPS-但我认为可以公平地说，仍然存在纯HTTP的良好用例。

关于tls的优点，这里有很多讨论-但这从未像原始帖子中所要求的那样。

傲游提出了2个问题：

1）为什么有一个随机的，未命名的网站决定同时保持http和https的存在

2）对Maxthon的负面影响是否仅对301请求提供301个响应

关于第一个问题，我们不知道提供商为什么选择保留http和https网站。可能有很多原因。除了关于兼容性，分布式缓存以及有关地缘政治可访问性的一些提示之外，还考虑了内容集成，并避免了关于内容不安全的丑陋浏览器消息。正如Alvaro指出的那样，TLS只是安全方面的冰山一角。

但是，第二个问题是可以回答的。当实际上需要使用https进行安全操作时，通过http公开网站站点的任何部分都可以提供可利用的攻击媒介。但是，为了确定流量被错误地定向到站点上的端口80并解决原因，维护该设置确实有意义。也就是说，既有负面影响，也有带来正面影响的机会，最终结果取决于您是否以管理员身份工作。

Sysadmin1138说，https影响seo排名。尽管Google表示确实会对排名产生影响，但据我所见，仅有的可靠研究表明差异很小。那些应该更了解这一点的人对此无济于事，因为排名靠前的网站更有可能具有https状态，因此 https状态可以提高排名。

过去，我不得不使用HTTP而不是HTTPS，因为我想<embed>从其他地方访问自己通过HTTP服务的页面，否则它们将无法正常工作。

这不是一个很好的理由，因为这意味着您的客户端不正确/损坏/不安全，但是如果有自动化进程通过现有的http://url 访问资源，则其中的某些进程甚至可能不支持https（例如busybox wget， '内部没有TLS支持，并且仅通过openssl子进程在最近才添加了TLS），如果将它们重定向到了他们无法遵循的https网址，则会中断。

我很想通过编写重定向规则以排除未知（或已知旧版）User-Agent字符串不被重定向，并允许他们通过http访问内容（如果需要的话）来处理这种可能性，以便实际的浏览器都可以从中受益强制https / hsts。

很少有很好的理由使用HTTP，而不是HTTPS的网站上。如果您的网站处理任何类型的交易或存储任何类型的敏感或个人数据，如果您希望上述数据是安全的，则必须绝对使用HTTPS。我不执行HTTPS的唯一体面原因是您的网站是否依赖于缓存，因为HTTPS无法与缓存一起使用。但是，为了确保网站的安全性，通常值得牺牲一些性能。您的客户端也可能不支持HTTPS，但实际上，在2017年应该支持。