3 ms·
It's insecure because whoever intercepts the unencrypted HTTP request could redirect it anywhere, i.e. to their evil site instead of your secure site. But if y
by ptx 8y ago
It's insecure because whoever intercepts the unencrypted HTTP request could redirect it anywhere, i.e. to their evil site instead of your secure site.
But if you set the Strict-Transport-Security header[1] that will tell the client to go directly to HTTPS in the future, without needing to be redirected, so future requests will be secure as long as the initial redirect request is not intercepted.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/St...
- icebraining 8y agoAllowing HTTP is not insecure; if someone can intercept the connection, they can do so even if you don't have HTTP enabled.
- ptx 8y agoHmm? What could they intercept if you only have HTTPS (with properly checked valid certificates) other than the (useless to the attacker) encrypted data? Preventing that kind of thing is the whole point of SSL. If you enable communication without SSL it's not prevented, so it's less secure.
- icebraining 8y agoI'm saying that if the client tries to connect to HTTP/80 and the attacker has interception abilities, it doesn't matter if the legitimate server has that port closed, because the request will never get there.
- ptx 8y agoAh. Sure. But if the server doesn't listen on port 80 and you document this fact, clients won't regularly attempt to connect on port 80 (since they know it can't work). I guess this applies more to non-browser client software than to people typing URLs in their browser address field, though.
- michaelt 8y agoIf it's an API, disabling HTTP reduces the risk someone will mistakenly code a client that uses HTTP, not notice their mistake, and later users of that client will get MITMed.