From 4f17e2a1251d1b460c51fd37f70ea85cd59eb1fa Mon Sep 17 00:00:00 2001 From: Simon Ruderich Date: Tue, 6 Sep 2011 16:30:01 +0200 Subject: [PATCH] README: Minor documentation updates. --- README | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/README b/README index c88806b..81bb4fc 100644 --- a/README +++ b/README @@ -50,7 +50,7 @@ If an error occurs in the validation (missing `certificate-*.pem` files, 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. @@ -67,7 +67,7 @@ this case the normal CA chain in your browser lets you validate the server 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. @@ -79,11 +79,11 @@ certificate in `certificate-example.org.server.pem`. Without '-u' everything 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 -- 2.44.1