diff options
Diffstat (limited to 'docs/README.rootcerts')
| -rw-r--r-- | docs/README.rootcerts | 308 |
1 files changed, 0 insertions, 308 deletions
diff --git a/docs/README.rootcerts b/docs/README.rootcerts deleted file mode 100644 index fb294d11..00000000 --- a/docs/README.rootcerts +++ /dev/null @@ -1,308 +0,0 @@ - DOS/Windows-oriented notes on Root Certificates - -To use certificates or a cert bundle within an SSL enabled -application such as lynx you must place your certificate -files into a known directory, and set the environment -variables to a proper value (e.g. in CONFIG.SYS file). - - set SSL_CERT_DIR=x:/usr/local/ssl/certs - set SSL_CERT_FILE=x:/usr/local/ssl/cert.pem - -(See "What are root certificates" below.) - - -Q. Why would I want to install openssl.exe? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -openssl.exe is used to manage certificates. (See "What are root certificates" -below.) - -Q. How to install openssl.exe? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Put openssl.exe in a directory in your PATH and the DLLs to a directory -in your LIBPATH. - -Copy conf\openssl.cnf.demoCA to a directory of your -choice, rename it to openssl.conf and set the environment variable -OPENSSL_CONF by putting - -SET OPENSSL_CONF=<your-directory>\openssl.cnf - -into CONFIG.SYS. - - -Q. Why is this document so paranoid? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If you want to use OpenSSL, then probably your Internet transactions have -*real* monetary value embedded in them. And as usual, the security is as good -as the weakest link. This document unravels only the tip of the iceberg -of what can go wrong with improperly established "secure" connections. And -given the monetary value involved, "bad guys" have a high incentive to exploit -the weakest links. As experience shows, do not underestimate the intelligence -of bad guys... - -Really, with security, a little knowledge is a dangerous thing; one can -suspect that many people, if they really understood the trust structures -associated with SSL, would be rather careful about checking the details -of certificates. - -Q. What are root certificates? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Making a secure connection is like sending your valuables (for storage or -consumption) to somebody who agreed to be at a prearranged place. To -guard the valuables on the way there, you can ask for a police escort; this is -what https:// connections are about. However, it does not make any sense to -have an escort if the goods are transfered to a random person who happens to be -at this place; one needs to certify the identity of the receiver as well. - -The certification process is a chain; when site A wants to certify that it is -actually what it claims, it actually says "Check this certificate with site B"; -to proceed, one needs to certify that site B is what it claims, so B may -redirect to site C etc. For this process to stop, some sites claim -"You must know my certificate, check it yourself". These certificates are -"root certificates"; one cannot verify such a site unless one has the -certificate for the "end of its certification chain". If you don't have the -relevant root certificate in your local certificates file, it means that -you don't trust anyone to vouch for the authenticity of the site. - -So one should have a collection of known certificates from several well-known -sites known as "Root Certification Authorities". Most sites for large-scale -businesses have certificates which will eventually resolve to these places. -Such certicates represent people like Verisign that are in the business of -confirming the identity of servers, etc. - -Additionally, since having yourself certified through another site costs, -some sites avoid this cost via presenting "end-of-chain certificates". -One should have a way to obtain these certificates via other means than -insecure Internet connection (e.g., one can walk into the office and copy -the certificate file to a floppy). These are so-called "Self-signed -certificates"; they are "root certificates" as well. The locally-installed -securely obtained copies of such certificates are referred to as -"local certificates". (See 'What is "Snake Oil Ltd."' below.) - -If you are presented with a locally-unresolvable root certificate, and you -*believe* that you are really talking to the site, and not someone -in between (who is either completely simulating the site or relaying -your requests onto the real site - called a "man in the middle" attack), -you will still have an encrypted connection. Otherwise, you should act -as though the site was an impostor, unless and until you manage to get -a root certificate from a trustworthy source, and that root certificate -represents someone that you would trust to have vetted the site you -want to connect to. - -Local certificates are stored in SSL_CERT_FILE (this "cert bundle", usually -named cert.pem, contains several signatures for "Root Certification -Authorities") and SSL_CERT_DIR (which has a signature per file, and usually -contain local copies of self-signed certificates). - -There are three crucial considerations to be added to this picture: - - a) While there are ways to ensure that the receivers are who they claim, - there is absolutely no technological way to verify how *trustworthy* - the receiving party is. It does not make sense to secure-send your - valuables to a certified receiver if this receiver is a crook (or will - just keep them later in a publicly accessible place). - - b) "VeriSign Syndrome". For the above scheme of "a chain of trust" to work, - the "Root Certification Authorities" should be *very* trustworthy - high-integrity entities. Unfortunately, there are certain doubts that - this is so. E.g., fall 2003, VeriSign started an attack on DNS scheme - which could disrupt the whole architecture of Internet (hijacking *all* - unclaimed Internet addresses and redirecting them to a promotional site; - google for VeriSign DNS hijack). - - One major company even issued a Microsoft certificate to a company - other than Microsoft, and there had to be a Windows critical update - to block that certificate. - - c) Keep in mind that the "big 2 browsers" are adding an increasing - number of root certificates, and most users fail to realise that they - are putting a trust in the supply chain for the browser to give them - the certificates of reliable organisations (the browser suppliers could - make bad choices, or the browser could have been hacked before you got - it). - - Incidentally, standard browsers come with certificates representing - very different levels of identity verification, but most people accept - all of those supplied with the big 2 as equally valid. - -Q. How to obtain root certificates? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Certificate files, such as cert.pem, are security critical; you have to -trust whoever supplies it to you; all your certification process is no more -trustworthy than the site you downloaded cert.pem from. So you shouldn't just -accept any offer. - -One way is to copy them from a machine which already obtained them in a secure -way. Another one is to extract them from a web browser which was itself -obtained in a secure way (see "How to extract certificates from Internet -Explorer" below). If anything else fails, obtaining a privately-generated -bundle from third-parties, such as - - http://www.kfu.com/~nsayer/encryption/ca-bundle.crt.text - -is *not* much better than no certificates at all, but may avoid some warnings -from applications. One of the places which has a bundle is the mod_ssl site. - -Q. Should you trust this distribution system? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -It is very hard to imagine a situation when the answer is different from -"Absolutely not!". - -Indeed, obtaining the certificates is only half of the problem. -The certificates are going to be checked by the SSL library. Can you trust -these executables (DLLs)? Did you obtain the library via a secure connection? -Are you sure that the place you obtained it from has reasonable security -practice, so that the archive could not be tampered with? The latter place -most probably did not build the DLLs themselves; chances are they just -store what a fourth-party supplied them. Was *that* file transfer done via -secure channels? Can you trust this fourth-party so that it did not insert -Trojans? - -Chances are that all of these questions are answered "No". There are still -major problems with bootstrapping security via the Internet... - -What about the application which uses these DLLs? Do you have any reason to -trust it? What about the OS itself? Did it come from a trustworthy source -via trustworthy channels? Are you sure it was not tampered with? - -Q. How to compile and link with OpenSSL libraries? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Put the files from include and lib to your emx directory, -or directories on C_INCLUDE_PATH and LIBRARY_PATH. -Note that openssl should become a subdirectory of your include directory. -If you need .lib files you can create them using emxomf. - -The supplied library files link against the new renamed dlls open_ssl and -cryptsll. - -See the doc directory for some information and visit -http://www.columbia.edu/~ariel/ssleay/ for more infos. - - -Q. Why do you need your own keys and certificates? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -There are several situations: having a server which accepts secure connections; -authenticating yourself to a server by means other than login/password, -sending S-Mime crypto-mail, authenticating from a client browser to a server. -In each of these situations one needs keys. - -The following sites may be useful: - - http://www.pseudonym.org/ssl/ssl_cook.html#environment - http://the.earth.li/~sgtatham/putty/0.53b/htmldoc/Chapter8.html#8.2 - -Q. How to generate your own keys and certificates? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -There are many ways. A good solution is to use sslRexx. It provides everything -you need. PuTTYgen is a key generator that will work. - -Below is a short description of how I made my own Certification Authority, -a Server Key for Apache and a client Key/Certificate for me, signed by my -own CA. - - -Q. Howto: Root CA (needed to self-sign all certificates) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Generate a CA-Key and store it in sub-directory private: - - openssl genrsa -des3 -out private/MyOwnCA.pem 2048 - -Make a selfsigned certificate based on above key. - - openssl req -new -x509 -days 730 -key private/CAkey.pem -out CAcert.pem - -This certificate will expire in 2 years. - -Optional: generate text output of this certificate: - - openssl x509 -in ./CAcert.pem -text > CAcert.txt - -Now you have a key and certificate for your own CA which can be used -to sign user and server keys. The CAcert is also needed to configure -Apache and Netscape. You can/should give away the CA certificate but -never give the CA key to anybody. - - -Q. Howto: Your Client Certificate/Key -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Generate a private key ----------------------- - - openssl genrsa -des3 -out hrom-key.pem 2048 - - -Create a signing request (same command again) ------------------------- - - openssl req -new -key hrom-key.pem -out hrom-req.pem - -Let the CA sign it (same command again) ------------------- - - openssl ca -in hrom-req.pem -out hrom-cert.pem -outdir MyOwnCA/newcerts - -After you get back the certificate from the CA, combine it with -your private key and store the result as p12 file. This file can -be imported into your browser. The browser will use this file to present -to a server requiring it for access. - - openssl pkcs12 -export -name Hromadka -in hrom-cert.pem -inkey hrom-key.pem -out hrom.p12 - - -Security Notes: Never give your private key to a CA, they only need the -signing request. Never give away your p12 file. Always secure your private -keys with a passphrase. - - -Q. How to use c_rehash? -~~~~~~~~~~~~~~~~~~~~~~ - -One needs a working port of Perl and cp.exe to run this. Set OPENSSL to the -full name of openssl executable. One may also need to change some ':' to -$Config{path_sep}. c_rehash finds certs from enviroment variables and allows -them to be recognized by openssl. - -Q. How to extract certificates from Internet Explorer? -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To make your own file of certificates, go to the -"Tools/Internet Options/Content/Certificates/Trusted Root Certificates" -section of IE. Select all the certificates, then "export" to a file. -It will be saved as a PKCS#7 file, with suffix ".p7b". You can call -it "ca_bundle.p7b". Then use openssl to convert it with the command: -"openssl pkcs7 -inform DER -in ca_bundle.p7b -print_certs -text -out cert.pem". -Ask your system administrator to put the file "cert.pem" in the openssl -directory and c_rehash it. Then lynx can check the certificates against the -set of certificates that you (or Microsoft) trusts, and you won't get the -warning message any more. - -Q. How to install 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 and hash the -cert by running c_rehash. A complete discussion of this procedure for unix is -in the document README.sslcerts. |