我联系了他们，问他们为什么丢弃HTTPS，他们告诉我“因为现在通过Google进行的身份验证是安全的，所以不再需要”。
我不是安全专家，但是在回复他们之前，我想知道：什么？
所以，据我所知，我会说（如果我错了，请纠正我）：
客户端之间通信中的隐私损失和服务器（攻击者可以读取交换的任何信息，其中包括客户端可能会发布到服务器的个人信息）。
攻击者可能出于恶意目的修改了客户端的请求。
可以读取Cookie并使用它来访问服务，就好像它们是最初使用Google服务进行身份验证的客户端一样。
我是不是？还有什么可能出问题？
#1 楼
没错，对HTTP的回归是毫无意义的。请注意，您的所有观点都适用于一种特殊的攻击，在这种攻击中，对手可以访问客户端和服务器之间的数据传输。这可能是WiFi热点的所有者，也可能是您的ISP充当中间人，坐在您与服务器之间。对于远程攻击者而言，这可能很难实现，但在公共WiFi上尤为容易。
HTTPS为HTTP添加的内容是安全的数据传输。 Web应用程序本身可以完全正常-如果您通过未加密的通道进行通信，则攻击者将能够读取，修改任意数据并将其注入到您的请求和服务器响应中。使用捕获的会话cookie，只要cookie有效，就可以冒充您。
攻击者无法做的是接管您的Google帐户，或在以后重新向Google进行身份验证。这是因为通过Google进行的身份验证始终通过SSL进行，并且授予的令牌会在给定的时间后过期。
因此，这种情况比立即捕获您的凭据要好一些。但是，正如您所说，攻击者仍然可以接管会话并代表您执行任何操作。
评论
肯定是劫机-毫无疑问！尝试通过Tor和/或I2P进行验证-尝试通过theese隧道进行连接。如果将照常使用HTTPS，请先进行调查，但首先要加强连接，然后尝试设置Tor路由器
–阿列克谢·韦斯宁（Alexey Vesnin）
16年4月20日在14:20
#2 楼
我会提出以下问题：在应用程序中进行身份验证有什么意义？
如果所有页面包含的都是公开内容并且可以通过外部方式进行验证（例如一个debian镜像，其中的软件包带有PGP），并且您的用户不介意第三方检查他们访问的内容，该页面可能不需要https。但也没有登录。
要求进行身份验证的常见原因包括：
有些数据用户只能在登录时读取
注册用户可以将消息发送给其他人
，该用户可以通过维护仅由他使用的身份来获得声誉
该帐户可以从外部获得一些好处（例如访问付费内容）
在通讯中使用http而不是https以及插入登录名的几乎所有其他原因都击败了他们。不管密码没有被公开的事实（这会更糟）。
前一段时间，有人争辩说购买证书的价格，但是如今有一些免费提供证书的CA。 。
†Nitpicker的一角，在极少数情况下，安全性不会因此受到损害。一个例子是Mega，它通过http加载了一些常见的javascript，但是在执行它们之前，通过https加载的脚本验证了它们的哈希值。比在任何地方设置https都脆弱且复杂。孩子们，不要在家尝试这个。
评论
如果您出于某种原因想要支付（即使只是在出现问题时让某人大喊大叫），即使是已支付的证书也几乎可以达到名义金额。在$ 10 / year / fqdn范围内找到基本的DV证书并不难，如果您想要通配符证书之类的东西，甚至对于考虑使用HTTP，DV HTTPS的任何东西，也可以将额外的零附加到零完全足够。
–用户
16-4-19在12:15
使用http：//而不是https：//可以使强制门户背后的用户更加方便。公共WiFi网关可以将第一个http：//请求从给定的MAC地址重定向到服务条款页面，但是https：//请求将仅转到错误屏幕，而无需告知用户需要同意使用之前，请遵守服务条款。
–超级猫
16年4月19日在16:53
MEGA“哈希验证”毫无意义：它会通过HTTPS加载所有内容，因为阻止从HTTPS加载HTTP资源，或者至少会发出警告。只是台式机客户端和扩展程序会发出HTTP请求，而只是下载加密文件，因为那些客户端和扩展程序不需要下载JavaScript文件。
–古斯塔沃·罗德里格斯（Gustavo Rodrigues）
16年4月19日在18:48
我可以做出有根据的猜测，是哪个网站启发了您进入第三项（声誉收集）-但是它们至少仍然允许使用HTTP，不是吗？
–哈根·冯·埃森（Hagen von Eitzen）
16年4月19日在21:20
@HagenvonEitzen我实际上是在一个经典论坛中思考，但是该页面确实受到了影响。实际上，用户在其中进行注册和通信的任何页面都是。
–Ángel
16年4月19日在22:59
#3 楼
您的凭据是安全的，但是可能会发生会话劫持一种可能是攻击者可能在充当中间人时进行了SSL Strip攻击，如果发生这种情况，HTTPS网站将作为HTTP到受害者。但是，正如您在网站上确认的那样，他们是有意这样做的。因此，这种可能性就开始了。
现在，Google使用oAuth2，因此与Google的握手将通过HTTPS进行，并且您将被重定向之后，通过HTTP到您的网站（使用Google帐户时，它与https://security.stackexchange.com/的发生方式非常相似）。您的网站在oAuth之后会生成一个会话令牌。在这种情况下，HTTP带来的风险是附件可以很容易地劫持您的会话并假装是您浏览网站
评论
Stack Exchange为所有非元站点提供HTTPS。 （由于域名结构，Meta更为复杂；应该将它与security.meta.stackexchange.com而不是meta.security.stackexchange.com一起使用，因为那样的话，它可能主要由* .stackexchange.com和* .meta处理.stackexchange.com。）我认为EFF的HTTPS Everywhere默认为所有Stack Exchange主站点提供HTTPS。
–用户
16-4-19在12:18
#4 楼
你完全正确。除Google登录凭据外，攻击者可以执行MITM攻击并拦截所有受害者的请求。我建议您向他们传达重新实施SSL协议的风险。#5 楼
“怎么了？”：如果使用API进行操作，则所有为该iOS 9设计并使用该API在iOS 9上运行的iOS应用程序都将停止运行。它被称为“应用程序传输安全性”，并且除非开发人员为您的域创建例外，否则不接受http，并且不接受连接不够安全的https。由于您的API曾经使用https，因此现有应用程序不会在您的域中出现异常，因此它们将停止运行。
评论
好吧，我在安全方面要求“可能出什么问题”。如果此Web服务停止工作，那实际上不是安全问题。但是，是的，当然客户和第三方应用程序可能会停止运行（尽管xD不知道iOS与之相关）。
– Peque
16年4月21日在10:00
评论
运行该站点的人非常无能。“我联系了他们，问他们为什么要丢弃HTTPS，他们告诉我：“因为现在Google进行的身份验证是安全的，所以不再需要了。” -符合流行语的安全性示例？
很高兴他们没有使用HSTS。.
@RubberDuck如果这样做，可能会迫使他们保留HTTPS支持。 ;-P
顺便说一句，这些天，确实没有太多理由仍然将纯http用作任何内容。