可以将https回退到https的https和安全级别 [英] Can https fallback to http and security level of https
问题描述
我正在考虑为我的域安装SSL / TLS。有两个问题困扰着我：
I am considering installing SSL/TLS for my domain. There are two questions that have been bothering me:
-
有没有任何情况下，https连接可以回退到http？所以，如果我的ajax看起来像这样
Is there any scenario where a https connection can fallback to http? So, for e.g. if my ajax looks something like this
$.post("https://foo.com", function(){
});
有可能改变为
$.post("http://foo.com", function(){
});
即使我的域名仍然可以访问 http://foo.com ？
and even if it does would my domain be still accesible at http://foo.com ?
接下来我已经广泛阅读了关于使用SSL / TLS并且从我所看到的，似乎相当准确的假设，如果我启用了这一功能，即使我以纯文本的形式发送用户凭据，它仍然是安全的（当然会有盐加密和服务器上的一切） 。在多大程度上这是真的，并会在客户端上创建一个哈希，然后通过https发送它更安全？
Next I have read extensively about using SSL/TLS and from what I have read it seems to be fairly accurate to assume that if I have this enabled and even if I send the user credentials in plain text, it's still secure (There would be encryption with salt and everything on the server of course). To what extent is this true and would creating a hash on the client and then sending it over https be any more secure?
更新：如果通过SSL发送明文是足够安全的，那么使用像cnonce这样的东西究竟是什么呢？不是客户端上不必要的开销吗？
Update: If sending plaintext over SSL is secure enough, then what really is the point of using things like cnonce ? Isn't it just unnecessary overhead on the client?
推荐答案
-
不，HTTPS从不自动回到HTTP。用户会采取慎重的行动。如果您只是通过将网址放入地址栏中来访问网页，这很简单;对于表单提交更难。
No, HTTPS never falls back to HTTP automatically. It would take deliberate action by the user. If you're just going to a web page by putting its URL into the address bar, this is easy; for form submission it's harder.
是的，通过SSL发送纯文本是正确的。事实上，发送散列密码并没有真正提高安全性 - 如果有人设法嗅探连接并获取散列密码，那就是他们需要登录的网站。它有一个很小的优势：如果用户在多个站点使用相同的密码，那么为一个站点学习散列密码并不能帮助他们进入另一个使用不同（或不）散列的站点。由于客户不知道盐，所以发送盐渍哈希是不可行的。
Yes, sending plain text over SSL is fine. In fact, sending a hashed password doesn't really increase security much at all -- if someone manages to sniff the connection and gets the hashed password, that's all they need to be able to login to the site. It has one small advantage: if the user uses the same password at multiple sites, learning the hashed password for one site doesn't help them get into another site that uses a different (or no) hash. And it's not likely to be feasible to send salted hashes, since the client doesn't know the salt.
cnonce增加了一个额外的保护。如果某种方式有人设法破解SSL加密，那么cnonce会阻止他们从中获取可用的密码。这基本上解决了我上面提到的为什么发送散列密码不能帮助的原因：你需要的是从会话到会话的变化，cnonce提供这个。
A cnonce adds an extra level of protection. If, somehow, someone manages to crack the SSL encryption, the cnonce prevents them from getting a usable password from it. This basically addresses the point I made above about why sending a hashed password doesn't help: what you need is something that changes from session to session, and a cnonce provides this.
请参阅 https://security.stackexchange.com/questions / 3001 / what-is-the-use-of-a-client-nonce
这篇关于可以将https回退到https的https和安全级别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
