X-Git-Url: https://ruderich.org/simon/gitweb/?p=tlsproxy%2Ftlsproxy.git;a=blobdiff_plain;f=README;h=83b2442feaef4dbc2803127f947f38e6cbae3e65;hp=444bec794b59e0573ac4b69f8bc13cc26c665aa5;hb=4b64428fe11db22f70c304de1bc9f0cc95f1d189;hpb=17eaccf9d2388fa7e0131ad83868666119b6f2c9

diff --git a/README b/README
index 444bec7..83b2442 100644
--- a/README
+++ b/README
@@ -11,8 +11,9 @@ tlsproxy is licensed under GPL 3 (or later).
 REQUIREMENTS
 ------------
 
+- C89 compiler
 - GnuTLS library including development headers
-- certtool (from by GnuTLS) to create TLS certificates
+- certtool (from GnuTLS) to create TLS certificates
 
 
 USAGE
@@ -23,7 +24,7 @@ This creates the following files:
 
 - `proxy-ca.pem`:      CA which is used for all connections to the client
 - `proxy-ca-key.pem`:  private key for the CA
-- `proxy-key.pem`:     private key for the server
+- `proxy-key.pem`:     private key for the proxy
 - `proxy-invalid.pem`: special certificate used for invalid pages
 
 Then import the CA file `proxy-ca.pem` in your browser so it can validate the
@@ -50,7 +51,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 +68,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,8 +80,20 @@ 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
+possible.
+
+
+KNOWN ISSUES
+------------
+
+- Firefox (at least Iceweasel 3.5.16 on Debian) fails to load the error page
+  sent with the "invalid" certificate once the certificate has been accepted.
+  As the user shouldn't accept the invalid certificate this is a minor issue.