Fix compile with current GnuTLS versions.

[tlsproxy/tlsproxy.git] / README

diff --git a/README b/README
index 0178e5c8f97a7caff3f3041cb50e4751ac10bc52..83b2442feaef4dbc2803127f947f38e6cbae3e65 100644 (file)
--- a/README
+++ b/README
@@ -11,8 +11,9 @@ tlsproxy is licensed under GPL 3 (or later).
 REQUIREMENTS
 ------------
 
 REQUIREMENTS
 ------------
 

+- C89 compiler

 - 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


@@ -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-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
 - `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
 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.
 
 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
 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.
 
 For hostnames with a stored server certificate everything works as usual and a
 certificate change is detected.


@@ -79,12 +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.
 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.
 
 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.