Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| ssl_proxy [2010/06/20 09:57] – created szilu | ssl_proxy [2010/06/20 10:06] (current) – szilu | ||
|---|---|---|---|
| Line 69: | Line 69: | ||
| === Defaults: === | === Defaults: === | ||
| - | < | + | < |
| # ssl_proxy -s 443 -c localhost: | # ssl_proxy -s 443 -c localhost: | ||
| -K / | -K / | ||
| </ | </ | ||
| + | |||
| + | ==== Notes ==== | ||
| + | SSL Proxy 1.0.0 introduced the ability to connect to UNIX domain sockets, not just TCP sockets. Please note that if you use UNIX domain sockets and you also use the -r (chroot) feature to make your system more secure, than the socket file must reside under the chrooted directory. The path specified in the -c option must be relative to the chrooted directory. Also note that if you use UNIX domain sockets with the -u (setuid) feature, then the user must have read and write permission to the socket file. The TCP sockets has no similar limitations, | ||
| + | with filesystem objects. | ||
| + | |||
| + | The file provided with the -v option can contain several CA certificates in PEM format. If you use the -V (certificate directory) option, then each file have to contain exactly ONE certificate. The files are looked up by the CA subject name hash value, which must be available. You can create symlinks with | ||
| + | the c_rehash utility, contained in the openssl package. | ||
| + | |||
| + | ==== Client info feature ==== | ||
| + | SSL Proxy can provide client information to the server in a special format. | ||
| + | |||
| + | This is a new feature in version 1.0.7, so I do not know of any server software that can use this information except my own special purpose software. If I receive information about any software available that uses this information, | ||
| + | |||
| + | The usage is very simple. You provide the -i option to SSL Proxy. When a client connects, SSL Proxy connects to the server the usual way. But before the data sent by the client is forwarded to the server, SSL Proxy sends an information line to the server. This is an example of a HTTPS connection with the -i option: | ||
| + | |||
| + | < | ||
| + | szilu@maia: | ||
| + | # | ||
| + | GET / HTTP/1.1 | ||
| + | Host: localhost: | ||
| + | User-Agent: Links (2.1pre37; Linux 2.6.27-11-eeepc i686; 80x24) | ||
| + | Accept: */* | ||
| + | Accept-Encoding: | ||
| + | ... | ||
| + | </ | ||
| + | |||
| + | As you can see, an extra line beginning with '# | ||
| + | |||
| + | This information can be used for example for logging or access control purposes. | ||
| + | |||
| + | ==== Examples ==== | ||
| + | If you are running a HTTP server at port 80 which does not has SSL support, and you want it to work on SSL too, than defaults are good for you: | ||
| + | <code bash> | ||
| + | ssl_proxy | ||
| + | </ | ||
| + | |||
| + | If you would like to use maximal security level, you can use: | ||
| + | <code bash> | ||
| + | mkdir / | ||
| + | ssl_proxy -u nobody -r / | ||
| + | </ | ||
| + | |||
| + | ==== How to report bugs ==== | ||
| + | To report a bug, send mail to // | ||
| + | In the mail include: | ||
| + | |||
| + | * The version | ||
| + | * Information about your system. For instance: | ||
| + | * What operating system and version | ||
| + | * What version of OpenSSL | ||
| + | * What version of the C library | ||
| + | * Anything else you think is relevant. | ||
| + | * How to reproduce the bug. | ||
| + | * The text that was printed out (Debug information). | ||
| + | |||
| + | You can also use tha SourceForge bugtracking system at | ||
| + | http:// | ||
| + | |||
| + | ==== Patches ==== | ||
| + | Patches can be sent to tha // | ||
| + | |||
| + | If the patch fixes a bug, it is usually a good idea to include all the information described in "How to Report Bugs". | ||