diff options
Diffstat (limited to '')
| -rw-r--r-- | docs/README.rootcerts | 308 |
1 files changed, 308 insertions, 0 deletions
diff --git a/docs/README.rootcerts b/docs/README.rootcerts new file mode 100644 index 0000000..67fb641 --- /dev/null +++ b/docs/README.rootcerts @@ -0,0 +1,308 @@ + 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 transferred 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 certificates 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 environment 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. |