3 ms·
>... if https doesn't work, people [or browsers] will just try http... And how does your proposal solve that? Nothing will stop people from trying 'http://myba
by tetrep 12y ago
>... if https doesn't work, people [or browsers] will just try http...
And how does your proposal solve that? Nothing will stop people from trying 'http://mybank.com' http://mybank.com' if 'rfsp://mybank.com' fails. You could try to have the browser stop the user, e.g. "You tried to visit 'mybank.com' over a secure connection, but failed. Are you sure you wish to visit 'mybank.com' over an insecure connection?" But that could also just be displayed after a user attempts an HTTPS connection to 'mybank.com'.
I don't see any advantage of RFSP that we couldn't just roll into HTTPS to avoid creating an entirely new protocol and to not undo the great effort that's been put forth into attempting to get people to use HTTPS.
- peterwwillis 12y agoSeveral reasons: 1. The https protocol allows self-signed certs, which defeats the purpose of a guaranteed secure connection. 2. The https protocol doesn't have any way of differentiating between a normal connection and one which mandates multiple certificates all verify the same identity if the host has been mitm'd. You'd go back to the chicken-and-egg that is HSTS and your initial connection is hijacked again. 3. Because https is inherently broken (for the edge cases discussed here), the users will not be able to rely on it. Yes, it would require re-training everyone in the world to always use this other protocol for their secure communications. But it would guarantee a secure connection every time without having to think about it. I'll bet that's a tradeoff most people are willing to make. The idea is to never allow the user to make an insecure connection. Give a user enough rope and they'll hang themselves.