Hacker News new | past | comments | ask | show | jobs | submit login

You can't prevent a downgrade attack on server side, the attacker can simply roll full HTTP on top of your server. And browsers already disallow or warn against submitting passwords over HTTP, is there a problem to fix there? Browsers disabled old versions of TLS, you don't harm anyone by supporting them (except for bit rot of that old code). There are also sites with zealous TLS settings, they support only sha384 cypher suites and nothing else at all.



There are multiple layers of protection against HTTPS-to-HTTP downgrade attacks.

① An HSTS policy will protect people that have visited your site within max-age seconds, typically “within the last year”.

② An HSTS policy with preload will protect everyone.

③ HTTPS-only cookies will prevent them being sent over plain HTTP.

⑤ You could depend on various newer functionality that is only available in secure contexts <https://developer.mozilla.org/en-US/docs/Web/Security/Secure...>. For example, the Web Authentication API. (This also raises a good point about using the Web Authentication API for security: authentication is tied to the origin, so http://example.com, https://example.com and https://example.com.evil.example are all different origins and no one will be able to log in over the wrong origin.)

⑥ Any JavaScript code can check the origin and rebel if it’s not what you expect—in fact, I’d say that it’s very common to do this quite incidentally. This protects against a drive-by downgrade attack, increasing the effort required by the attacker who must now reverse-engineer a bit of your code.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: