fingerprint changed, etc.) it's logged by the proxy (stdout) and the special
`proxy-invalid.pem` certificate is used to send a 500 error message to the
client. The connection to the server is closed so there's no chance that any
-client data is sent to the (possible) evil server. The invalide certificate is
+client data is sent to the (possible) evil server. The invalid certificate is
also easy to spot in the browser because it uses an invalid hostname
("invalid") and is self-signed.
certificate. If the server certificate changes you're _not_ informed!
This option is useful if you often visit websites using HTTPS but you don't
-use critical information (e.g. no passwords, etc.) on this website.
+use critical information (e.g. no passwords, etc.) on these websites.
For hostnames with a stored server certificate everything works as usual and a
certificate change is detected.
is fine.
But if you use '-u' and an attacker redirects you to e.g.
-https://www.example.org/ (or https://whatever.org/) (for example through a
-link on a different site) then the proxy just forwards the TLS connection
-(because it doesn't know the fingerprint for https://www.example.org/, that's
-how '-u' works) and you won't be aware that a different server certificate
-might be used!
+https://www.example.org/ - leading .www - (or https://whatever.org/) (for
+example through a link on a different site) then the proxy just forwards the
+TLS connection (because it doesn't know the fingerprint for
+https://www.example.org/, that's how '-u' works) and you won't be aware that a
+different server certificate might be used!
If you always verify the authentication of the connection this isn't a
problem, but if you only check if it's a HTTPS connection then this attack is