我有一个在NGINX中设置的http–httpsredirectconfiguration：
server { listen 80; server_name localhost; return 301 https://$server_name$request_uri; } 我的问题是：有没有在最初访问我的应用程序的login页面的用户发布他的用户名+密码的任何时候，在HTTPredirect到HTTPS之前凭证清除的时间？
这取决于你的登录表单（它应该总是只发布到https网址），但是根据这个信息，我认为不是，密码总是在https 使用时按照预期使用 。
但是，您可能需要注意一些事情并添加更多的保护措施（深度防御），因为攻击的目的就是让事情不会如预期的那样进行。 🙂
攻击者可能会从用户的角度降低与http的连接，而攻击者本人与服务器保持安全的连接。 请注意，即使服务器甚至没有响应普通的http，这将工作。 看到这个视频或这个链接 （等等）。 解决方案是HSTS（见下文）。
如果攻击者可以以任何方式将简单的http请求注入到通过普通http发送证书的客户端浏览器中，那么这些证书将不受保护。 这适用于发布的用户名/密码，也适用于会话cookie，相当于会话持续时间内的用户凭证。 所以这意味着如果攻击者可以插入一个带有src="http://yoursite.com" ，会话cookie将被发送成明文。 响应将按照您的nginx设置重定向，但是太迟了。 始终将会话cookie设置为secure可解决此问题（但不能发布另一个有关发布凭证的问题，这可以通过HSTS进行缓解）。
您的网站应该有一个Strict-Transport-Security响应标题，这样一旦浏览器有机会与服务器通话而没有中间人攻击者删除标题，它将会记住使用https，即使用户没有明确指定它在网址栏。
Strict-Transport-Security: max-age=31536000; includeSubDomains
更多关于HSTS的信息在这里 。