diff options
Diffstat (limited to '')
| -rw-r--r-- | docs/README.ssl | 69 | ||||
| -rw-r--r-- | docs/README.sslcerts | 265 |
2 files changed, 334 insertions, 0 deletions
diff --git a/docs/README.ssl b/docs/README.ssl new file mode 100644 index 0000000..c9d1c79 --- /dev/null +++ b/docs/README.ssl @@ -0,0 +1,69 @@ +SSL support for Lynx 2.8.5pre.1 +-- adapted from http://www.mentovai.com/lynx/ + +Lynx, in its unmodified form, will not allow you to make secure socket layer +(SSL) connections. SSL is used for the secure transfer of information over the +Internet. Many sites are now requiring SSL to ensure security for themselves +and their users. With a version of Lynx modified to support SSL, Lynx users +can now visit these sites with ease as well. + +The SSL configure option (--with-ssl) for Lynx provides the ability to make use +of SSL over HTTP for secure access to web sites (HTTPS) and over NNTP for +secure access to news servers (SNEWS). SSL is handled transparently, allowing +users to continue accessing web sites and news services from within Lynx +through the same interface for both secure and standard transfers. + +This is based on, and requires, the OpenSSL library. OpenSSL's distribution +and use may be restricted by licenses and laws. For information on obtaining +OpenSSL, as well as information on its distribution, see + + http://www.openssl.org/ + +The main distribution site is at + + ftp://ftp.openssl.org/source/ + +Lynx also has experimental support for GnuTLS (configure option --with-gnutls). +For information on GnuTLS, see + + http://www.gnu.org/software/gnutls/ + +To test your version of Lynx for SSL support, try it out with an SSL site. +Below are secure (https) pages which will load if your browser contains SSL +support and you accept their certificates; they give you some information about +the connection. + + https://www.gnutls.org:5555/ + https://www2.ggn.net/cgi-bin/ssl + +Lynx will complain about the certificate, since the certificate presented is +untrusted. You may accept this certificate to test your configuration, since +it is a test, but it is a bad idea to blindly accept certificates from unknown +websites if you are transmitting form data or files. + +You should review the document README.sslcerts for a detailed discussion of +correct certificate handling possibilities and procedures in lynx. + +Users are reminded to check the laws and regulations about encryption software +in their own countries. + +Here is the URL for US notification rules: + + http://www.bxa.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html + +Note that that isn't a typo; it really is "Nofify". The site contains +links to the full EAR regulations. + +Lynx is GPL'd, for our own use it falls under the regulations in EAR section +740.13(e)(1): + + (1) Encryption source code controlled under 5D002, which would be + considered publicly available under section 734.3(b)(3) and + which is not subject an express agreement for the payment a + licensing fee or royalty for commercial production or sale of + any product developed with the source code, is released from + EI controls and may be exported or reexported without review + under License Exception TSU, provided you have submitted + written notification to BXA of the Internet location (e.g., + URL or Internet address) or a copy of source code by the time + of export. diff --git a/docs/README.sslcerts b/docs/README.sslcerts new file mode 100644 index 0000000..39c3dcd --- /dev/null +++ b/docs/README.sslcerts @@ -0,0 +1,265 @@ + Lynx SSL support for certificates - README.sslcerts file + +BACKGROUND: + +The original README.ssl document for lynx stated: + + Note that the server... may not have a valid certificate. Lynx will not + complain, as it does not yet support certificates... + +Such lack of support is no longer the case. Lynx now features excellent +certificate management through the openssl project. There is almost no +online documentation available regarding how to use openssl's certificate +management with other programs, so this will accompany lynx and hopefully +encourage good practical security for unix clients. + +Lynx relies on openssl to not only encrypt connections over https, but also to +determine whether it should even accept a certificate and establish a secure +connection with a remote host. Because of this reliance upon openssl by lynx, +most of this tutorial deals with how to use openssl to "install" both +vendor-provided CA cert bundles as well as self-signed certs from trusted sources +and, most importantly, how to get them recognized by lynx. + +While lynx on many systems will transparently accept valid certificates, not +all systems enjoy such functionality. Further, as noted above, older versions +of lynx do not perform any validity checks on a certificate. + +There is also the common case of wanting to trust, use and install a +self-signed certificate from a known server source and have it be trusted by +client programs. + +Briefly, the procedure will involve confirming the default system location for +certificates, setting values for SSL_CERT_DIR and SSL_CERT_FILE in +the environment, and converting and hashing the certificates using openssl +utilities to enable recognition. + +THE CURRENT SITUATION: + +Prior to lynx2.8.5dev9, lynx did not check at all for certificate validity. + +Since lynx2.8.5.dev9, lynx has reported this openssl error: + +SSL error:unable to get local issuer certificate-Continue? (y) + +whenever an https connection was initiated and the certificate could not be +found, for whatever reason, by openssl, and therefore lynx. + +This checking for a certificate is an enhancement to security, but rather +tediously generates errors at each https browser request. + +The ability to turn off reporting of this error to the user was added to +lynx2.8.5dev16 as the FORCE_SSL_PROMPT setting in lynx.cfg as noted in the +CHANGELOG: + + This lets the user decide whether to ignore prompting for questionable + aspects of an SSL connection. + +While this is a convenient setting to employ when using lynx to script +https -dumps, it by definition ignores the issue of certificate validity +altogether. Those concerned with proper certificate management and +the maintenance of a store of updated CA certificates will be uncomfortable +with this relaxed security setting. + +The ability to accept a 'wildcard' certificate, where the first character +is a '*' was added to lynx2.8.6dev18. + +PRELIMINARY PROCEDURES: + +It is assumed that openssl has been installed correctly, that the default +cert directory is /usr/local/ssl/certs, (it's often /etc/ssl/certs, but we +need a point of departure for the discussion) and that lynx has been compiled +--with-ssl. + +The default location for certs on your system may be different, or there may not +be one. You will have to substitute that location for /usr/local/ssl/certs in +the following instructions, and/or set environment variables. + +To determine the default location for certs on your system you may run the +following command: + +strings libcrypto.a | grep -in cert | less + +Look in this output for SSL_CERT_DIR and SSL_CERT_FILE, and the lines just +above them. This is your default location, respectively, for certificates, +and the CA cert bundle, cert.pem. You will need to know where libcrypto.a is +found of course. + +Example output: + +<snip> +7490:/etc/ssl/certs +7491:/etc/ssl/cert.pem +7492:SSL_CERT_DIR +7493:SSL_CERT_FILE +<snip> + +Other possible example output: + +<snip> +31555:/usr/local/ssl/certs +31556:/usr/local/ssl/cert.pem +31557:SSL_CERT_DIR +31558:SSL_CERT_FILE +<snip> + +Note that when OpenSSL is installed, the c_rehash utility is installed in a +bin directory (default /usr/local/ssl/bin). You will need to know where it +is on your system. The command: + +whereis c_rehash + +will probably give useful results. + +Note also that there is no CA cert bundle distributed with OpenSSL. The +OpenSSL team specifically decided NOT to do that. Getting a set of trusted +certificates is left up to the installer. + +It is no longer a fairly trivial procedure to pull the bundle of trusted root certs out +of a recent version of Internet Explorer. Multiple certificates are no longer +exportable as a DER formatted file; extraction of a single certificate is the only +export for DER, and DER is what converts to PEM. + +Users with access to Apple OS X can export all certificates from Keychain Access System Roots as +a .pem file. Place this in SSL_CERT_DIR and hash it and you're done. + +The MirOS BSD project also provides them. The procedure to convert and install them +is detailed later in this document, and if you simply need to have commercially provided +certificates trusted by lynx, you can skip down a few lines to the INSTALLING OR UPDATING +THE CA BUNDLE section. + +Extracted Mozilla cert bundles are available for download from the curl project, +http://curl.haxx.se/docs/caextract.html along with a script to extract from Mozilla +source. + + +INSTALLING A SELF-SIGNED CERTIFICATE: + +When you would like to trust a self-signed (non-commercial) certificate you will +need to get hold of the actual file. If it's a cert local to your network you +can ask the sysadmin to make it available for download as a link on a webpage. + +If such file is not human-readable it's probably DER formatted and will need to +be converted to PEM format to allow openssl to use it. + +To convert DER formatted certificates into something openssl can deal with: + +Save the cert as site_name.crt in a directory. In that directory, type: + +openssl x509 -inform DER -in site_name.crt -outform PEM -out site_name.pem + +You can now copy this individual cert into the directory for that, usually +/usr/local/ssl/certs. The alternative is to concatenate the individual certs +to the cert.pem bundle in /usr/local/ssl. (Please see INSTALLING OR UPDATING +THE CA BUNDLE below). + +The cert file will now be in an acceptable format to openssl, PEM encoded. +However, openssl, and by extension lynx, will not know about it until that +cert is symbolically linked to a file named after the hash value of that cert, +in the default directory /usr/local/ssl/certs. + +So the next thing to do is to hash the cert using c_rehash. + +INSTALLING OR UPDATING THE CA BUNDLE: + +Now would be a good time to check to see if you have the bundle of CA certs +/usr/local/ssl/cert.pem, or to update them. + +CA bundles are available in various places, such as the MirOS BSD distribution, +for those who want to take that route, or you can extract the current bundle +from a current version of Internet Explorer (export them all from IE and +transfer it onto your system). + +From MirOS, a cert bundle is available at + +http://caunter.ca/ssl.certs.shar + +It includes the cacert.org certificate. Download the latest revision; read the +file to see how to get the certs out. + +No hashing is necessary with this set of certs; it is already done; ignore +the c_rehash usage below for this bundle. Simply run `sh ssl.certs.shar` +in SSL_CERT_DIR. + +From IE 5.x certs extract as a PKCS7 file and need to be converted with something +like: + +openssl pkcs7 -inform DER -in bundle.crt -outform PEM -out cert.pem \ +-print_certs -text + +The resulting cert.pem file should be copied to the default directory for +bundles (usually /usr/local/ssl) and renamed to "cert.pem", assuming that is +the SSL_CERT_FILE. + +Individual certs can also process if added and hashed in /usr/local/ssl/certs. + +We now have all of the individual certs we wish to trust in our certs +directory, and the most recent bundle of CA certs as well. + +Confirm that you have the script c_rehash (See PRELIMINARY PROCEDURES; if it is +not found, a copy is usually located in the tools directory of the openssl +source tree. If you use this copy, it needs the execute bit set or it will not +run). + +Run: + +./c_rehash + +The c_rehash utility is a perl script that runs openssl commands which creates +the files named after the hash values of the certs in the default directory +for certs. + +Its output looks like this: + +Doing /usr/local/ssl/certs +vsignss.pem => f73e89fd.0 +vsign3.pem => 7651b327.0 +...more output +<snip> + +All pem encoded certs in /usr/local/ssl/certs will now be recognized. + +SETTING AND EXPORTING ENVIRONMENT VARIABLES: + +If lynx is still not recognizing certs, environment variables need +to be set; if on a sh type shell, the variables also need to be exported. + +The environment variables SSL_CERT_DIR and SSL_CERT_FILE need to be set +if a non-default location is used for certificates, or if certs just can't be +found by lynx. They may be set as follows in /etc/profile, or a shell +initialization .profile or .*shrc, if we run a non csh type shell, according +to the results of the search for the default location for certs procedure +(See PRELIMINARY PROCEDURES): + +SSL_CERT_DIR="/usr/local/ssl/certs" +SSL_CERT_FILE="/usr/local/ssl/cert.pem" +export SSL_CERT_DIR SSL_CERT_FILE + +On csh type shells, you can use: +setenv SSL_CERT_DIR "/usr/local/ssl/certs" +setenv SSL_CERT_FILE "/usr/local/ssl/cert.pem" + +Note that the environment variable SSL_CERT_FILE applies to the cert-bundle +if used outside of the default location (/usr/local/ssl/cert.pem) compiled +into OpenSSL. There are issues with SSL_CERT_FILE in 0.9.6x versions of openssl. + +The configuration file lynx.cfg allows a system SSL_CERT_FILE variable to be set +which can simplify matters. + +SSL_CERT_FILE:/etc/ssl/certs/ca-certificates.crt + +Make sure you have FORCE_SSL_PROMPT set to PROMPT in lynx.cfg like so: + +FORCE_SSL_PROMPT:PROMPT + +You will now connect without error to https servers with trusted certs, but +will still get this error for untrusted certs: + +SSL error:self signed certificate-Continue? (y) + +A quick check confirms that these procedures have the same effect with ssl +errors in the pine program. + +2003 updated 2009 +Stefan Caunter <stefan.caunter@mohawkcollege.ca> +Mohawk College Department of Computer Science +Hamilton Ontario Canada |