tests: Log output of gnutls-serv during the tests.

[tlsproxy/tlsproxy.git] / README

diff --git a/README b/README
index 4347b9b813924ad6d72bd3c073ed8a4db038f3ea..1e1efa7f76e8c90808fc5f1a6d419da3f806d88d 100644 (file)
--- a/README
+++ b/README
@@ -24,6 +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-dh.pem`:      Diffie-Hellman parameters for the proxy
 - `proxy-key.pem`:     private key for the proxy
 - `proxy-invalid.pem`: special certificate used for invalid pages
 
@@ -48,7 +49,7 @@ If the validation is successful the proxy uses the `certificate-*-proxy.pem`
 certificate to secure the connection to the client (signed by `proxy-ca.pem`).
 
 If an error occurs in the validation (missing `certificate-*.pem` files,
-fingerprint changed, etc.) it's logged by the proxy (stdout) and the special
+fingerprint changed, etc.) it's logged by the proxy (stderr) 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 invalid certificate is
@@ -90,6 +91,11 @@ 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.
 
+Another issue is embedded active content, like JavaScript. If the website
+includes data from a different host (e.g. a different sub-domain), for which
+tlsproxy has no certificate, then an attacker can MITM that connection and
+inject JavaScript with unknown consequences into the browser.
+
 
 KNOWN ISSUES
 ------------