This whole attack is assuming the attacker is there from the very first packet of the particular login session. Not about inserting a MITM in the middle of an established login session.
The initial connection of an intercepted HTTPS connection would throw a security error, because the attacker would be using the wrong cert, but if you redirect the victim quickly...
You can defeat this particular hole by getting more aggressive about untrusted certificates, but it seems browsers are very reluctant to do that.
Comments
This whole attack is assuming the attacker is there from the very first packet of the particular login session. Not about inserting a MITM in the middle of an established login session.
The initial connection of an intercepted HTTPS connection would throw a security error, because the attacker would be using the wrong cert, but if you redirect the victim quickly...
You can defeat this particular hole by getting more aggressive about untrusted certificates, but it seems browsers are very reluctant to do that.
"Quickly" really isn't applicable in this case, though.
If there's no HSTS record for the domain,
- if it's HTTP, the attacker succeeds.
- if it's HTTPS with an invalid cert, the browser will display a warning and not honor any redirects.
- if it's HTTPS with a valid cert, we assume there is no attack (cert misissuance is an attack outside the scope of HSTS).
If there's an HSTS record for the domain,
- if it's HTTP, the browser will automatically rewrite to HTTPS.
- if it's HTTPS with an invalid cert, the browser produces a hard fail that the user can't override (and ignores redirects).
- if it's HTTPS with a valid cert, as above, the browser accepts the cert and we assume it's not an attack.