(You just edited your comment, didn't you) Well, that's a good detail then.
Does it in fact reject connections to self-signed certs? Or just disallow you from accepting the broken cert? Because the real goal would just be to get the user onto http:// as quick as possible, and then the untrusted warning is gone.
(You keep editing your comments, replacing old questions with new questions, which makes it rather difficult to reply to you. I suggest making new comments instead.)
Does it in fact reject connections to self-signed certs?
Yes, you don't even need HSTS for this. HSTS just disallows the user from overriding the browser and accepting the self-signed (or otherwise bad) certificate.
But an attacker can certainly intercept HTTPS as well, and if they redirect you quick enough you'll never see the "wrong cert" errors.
No, any sort of HTTPS interception will be detected by the browser (assuming of course that the certificate authority infrastructure has not been compromised). There's no way to redirect "quick enough" to bypass certificate checking.
Of course it is detected, we are not trying to fool the PC. When I visit my personal website with a flawed certificate (for example, once I was missing the Intermediate CA) it loads the site all the same, but the lock icon shows a security verification failure.
What in HSTS protects you from that? Because it seems to me if you can get there, you can get back to http:// before the user notices the verification failure. Unless the browser simply refuses to load the site due to the verification failure, which I only see for "suspected attack sites"
Intercept 443 => Issue insecure page with new HSTS timeout => Redirect to 80 before user notices insecure page warning
But it only loads because you added an exception at some point in the past. On any normal site, it would show you a cert error and wouldn't load the page at all.
Comments
(You just edited your comment, didn't you) Well, that's a good detail then.
Does it in fact reject connections to self-signed certs? Or just disallow you from accepting the broken cert? Because the real goal would just be to get the user onto http:// as quick as possible, and then the untrusted warning is gone.
(You keep editing your comments, replacing old questions with new questions, which makes it rather difficult to reply to you. I suggest making new comments instead.)
Yes, you don't even need HSTS for this. HSTS just disallows the user from overriding the browser and accepting the self-signed (or otherwise bad) certificate.
What browser flat-out refuses to connect to a webpage with an invalid SSL cert? Is this a recent development?
Edit: Apparently all of them now, I sure didn't notice that. Not a concern, then
Test site: https://tv.eurosport.com/
No, any sort of HTTPS interception will be detected by the browser (assuming of course that the certificate authority infrastructure has not been compromised). There's no way to redirect "quick enough" to bypass certificate checking.
Of course it is detected, we are not trying to fool the PC. When I visit my personal website with a flawed certificate (for example, once I was missing the Intermediate CA) it loads the site all the same, but the lock icon shows a security verification failure.
What in HSTS protects you from that? Because it seems to me if you can get there, you can get back to http:// before the user notices the verification failure. Unless the browser simply refuses to load the site due to the verification failure, which I only see for "suspected attack sites"
But it only loads because you added an exception at some point in the past. On any normal site, it would show you a cert error and wouldn't load the page at all.