X-Git-Url: https://ruderich.org/simon/gitweb/?a=blobdiff_plain;f=README;h=c88806b1f2f82724fc0aaaaf77d85ae5d5fc5613;hb=378de4c6745edcf83cd997ed6dff27b63e675aec;hp=ebcb53fb201f0c111e20a2dc249d272e441f1f76;hpb=d3ee0e4a91df6a73d93db8f1b0e70d2c528fc7b8;p=tlsproxy%2Ftlsproxy.git

diff --git a/README b/README
index ebcb53f..c88806b 100644
--- a/README
+++ b/README
@@ -12,7 +12,7 @@ REQUIREMENTS
 ------------
 
 - GnuTLS library including development headers
-- certtool (from by GnuTLS) to create TLS certificates
+- certtool (from GnuTLS) to create TLS certificates
 
 
 USAGE
@@ -56,3 +56,43 @@ also easy to spot in the browser because it uses an invalid hostname
 
 If an internal error occurs before the TLS connection can be established a 503
 Forwarding failure is sent to the client (unencrypted).
+
+
+-u option
+~~~~~~~~~
+
+The '-u' option passes through connections for hostnames with no stored
+certificate (i.e. `certificate-*-server.pem` is missing or unreadable). In
+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.
+
+For hostnames with a stored server certificate everything works as usual and a
+certificate change is detected.
+
+WARNING: The option might cause security problems if you're not careful:
+
+For example you normally visit https://example.org/ and store the server
+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!
+
+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.