]> ruderich.org/simon Gitweb - tlsproxy/tlsproxy.git/blobdiff - README
Rename server_certificate_path() to server_certificate_file().
[tlsproxy/tlsproxy.git] / README
diff --git a/README b/README
index ebcb53fb201f0c111e20a2dc249d272e441f1f76..81bb4fcdd761dda8f120093c5ca8a22de66c15a9 100644 (file)
--- a/README
+++ b/README
@@ -12,7 +12,7 @@ REQUIREMENTS
 ------------
 
 - GnuTLS library including development headers
 ------------
 
 - GnuTLS library including development headers
-- certtool (from by GnuTLS) to create TLS certificates
+- certtool (from GnuTLS) to create TLS certificates
 
 
 USAGE
 
 
 USAGE
@@ -50,9 +50,49 @@ 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
 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.
 
 If an internal error occurs before the TLS connection can be established a 503
 Forwarding failure is sent to the client (unencrypted).
 also easy to spot in the browser because it uses an invalid hostname
 ("invalid") and is self-signed.
 
 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 these websites.
+
+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/ - 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.