REQUIREMENTS
------------
+- C89 compiler
- GnuTLS library including development headers
- certtool (from GnuTLS) to create TLS certificates
- `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-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
Then import the CA file `proxy-ca.pem` in your browser so it can validate the
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 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.
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.
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.
+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
------------
- 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.
+
+
+AUTHORS
+-------
+
+Written by Simon Ruderich <simon@ruderich.org>.
+
+
+LICENSE
+-------
+
+tlsproxy is licensed under GPL version 3 or later.
+
+Copyright (C) 2011-2014 Simon Ruderich
+
+This program is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program. If not, see <http://www.gnu.org/licenses/>.
ruderich.org/simon / tlsproxy / tlsproxy.git / blobdiff