I think a lot of the openssl specific instruction as well as the paranoia would be quite useful with the OS/2 stuff taken out. IMHO there cannot be enough of this kind of information given to users.
There is some duplication of README.sslcerts; perhaps an edit to form a README.rootcerts doc would be in order? I don't mind doing this. The openssl.exe appears to follow *nix openssl syntax; safe assumption? Any other thoughts? __Stef On Sun, 23 Nov 2003, Ilya Zakharevich wrote: > These docs contain some OS/2-specific part (please ignore it), but the > rest is not OS/2-specific. I spent a lot of time making this readable > and informative. I marked by ??? the places which I do not understand > or do not qualify to answer. > > Any comment is going to be appreciated; especially those clarifying > ??? parts. Feel free to use this as a base of Lynx docs. > > Thanks, > Ilya > > ================================================================== > > This is openssl-0.9.7c binary for OS/2. > > > I compiled it on Warp4 with emx 0.9d after applying a patch from > Ilya Zakharevich. See end of this file for the descritopn of the patch. > The DLLs and EXE are compressed with LXLite. > > Grab the full source at http://www.openssl.org/ > > > Q. How to use the openssl DLLs with third-parties applications? > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Put the DLLs to a directory in your LIBPATH. If you have applications > using the dlls with old names ssl.dll and crypto.dll install the wrapper > dlls from the backward subdirectory too. > > To use certificates or a cert bundle within a SSL enabled application > like lynx you have to place your certificate files into the diretory > /usr/local/sll. Alternatively, set the enviroenment variables to a > propper 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.) > > For more details about using the open SLL libraries from an application > read the README files of the application. > > 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 environement variable > OPENSSL_CONF by putting > > SET OPENSSL_CONF=<your-direcotry>\openssl.cnf > > into CONFIG.SYS. > > ... Should not one edit dir= line in this file??? > > > Q. Why is this document so paranoid? > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > If you want to use OpenSSL, then probably your Internet transaction have > *real* monetary value embedded in them. And as usual, the security is as good > as the weakiest link. This document unravels only the tip of the iceberg > of what can go wrong with unproperly established "secure" connections. And > given the monetary value involved, "bad guys" have a high incentive to exploit > the weakiest links. As experience shows, do not underestimate 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 which 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 a 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 the site B is what it claims, so B may > redirect to site C etc. For this process to stop, some sites claim that > "You must know my certificate, check it yourselves". These certificates are > "root certificates"; one cannot verify a site unless one has the certificate > for the "end of its certification chain". If you don't have the > relevant root certificate in the 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 yourselves certified through another site costs, > some sites would avoid this cost via presenting "end-of-chain certificates". > One should have a way to obtain these certificates via other mean than > unsecure 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 refered to as > "local certificates". (See 'What is "Snake Oil Ltd."' below.) > > If you are presented with 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 ("cert bundle", usually named > cert.pem, usually 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 claims, > there is absolutely no technological way to verify how *trustworthy* > the receiving party is. It does not make sends 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 Syndrom". 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 > trustful than the cite 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 some 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 mod_ssl site. > > Q. Should you trust this distribution? > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > It is very hard to imagine a situation when the answer is different from > "Absolutely not!". > > Indeed, obtaining the certificates are only one 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; the 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 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 trustful source via > trustful 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, ????. In each of these situations one needs the > following types of keys: ???? > > The following sites may be useful????: > > http://www.pseudonym.org/ssl/ssl_cook.html#environment > > 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. > > Below is a short descriptions 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. > > ???? Why is the file name different? > > openssl req -new -x509 -days 730 -key private/CAkey.pem -out CAcert.pem > > This certificate will expire in 2 years. Then one should do ????. The -x509 > switch is ????. > > 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: a Key and Certificate for the Apache Server > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Generate a key > > openssl genrsa -des3 -out server-key.pem 2048 > > ??? What makes openssl prompt in this case, but not in the previous one > (same command as for root key - except the output file)? > > With this variant, you will be prompted for a protecting password. If > you don't want your key to be protected by a password, remove the flag > '-des3' from the command line above. > > NOTE: if you intend to use the key together with a server > certificate, you may want to avoid protecting it with a password, > since that would mean someone would have to type in the password every > time the server needs to access the key. But then you should protect > the server key in another way. > > ??? "Someone" is who? Who connects to the server of what? > > Create a signing request > ------------------------ > > openssl req -new -key server-key.pem -out server-req.pem > > This request has no -x509 and no expiration date since ????. > > Now send this request to your CA for signing. Since you are your own CA > sign it: > -------- > > openssl ca -in server-req.pem -out server-cert.pem -outdir MyOwnCA/newcerts > > Which CA key is used by this, if any???? What is the significance of > -outdir???? Should -outdir exist???? > > Verify the certificate > > openssl verify -CAfile CAcert.pem server-cert.pem > > Now you have a key and a certificate for your Apache Webserver. (This assumes > that the CAcert.pem generated on the previous step is still in the current > directory.) Where should one place these guys???? > > > Q. Howto: send request to your CA for signing > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > http://www.modssl.org/related/cert.html???? > (Unless you are your own CA; then see above.) > > Q. Howto: Your Client Certificate/Key > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Generate a private key > ---------------------- > > openssl genrsa -des3 -out hrom-key.pem 2048 > > (still the same command with yet different file name). What with passwords > here???? > > 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 for ????. > > 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}. (Not checked...) > > 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. 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, 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 applications, such as lynx), will not know > about it until that cert is present in a file named after the hash value of > that cert, in the cert directory (default /usr/local/ssl/certs). > > So the next thing to do is to hash the cert by running c_rehash. > > > Q. What is "Snake Oil Ltd."? > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > The "Snake Oil Ltd." certificate is a testing certificate. > Specifically, it is the self-signed certificate generated by the > installation procedure of Apache-SSL. The presence of this certificate does > not make your SSL connections less secure: they will still be encrypted and > therefore difficult to intercept or corrupt. > > What the web server at "Linux Web Toast" is saying is "Our name is company > XYZ, just take our word for it." Your software (the browser) is bringing > this to your attention because it is not configured to just take anybody's > word for anything. A normal secure web server would say something like "Our > name is company XYZ according to VeriSign, Inc, and you can take their word > for it." Your web browser is probably configured to automatically trust > VeriSign, Inc. > > > > Q. How this build differs from older builds (Ilya's patch)? > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > This patch > > a) Introduces a new file os2/backwardify.pl. > > b) Introduces a new mk1mf.pl variable $preamble. As you can see, it may > be used also to move some OS-specific code to VC-CE too; > > c) The DESCRIPTION specifier of the .def file is made more informative: > now it contains the version number too. On OS/2 it is made conformant > to OS/2 conventions; in particular, when one runs the standard command > BLDLEVEL this.DLL > one can see: > > Vendor: www.openssl.org/ > Revision: 0.9.7c > Description: OpenSSL: implementation of Secure Socket Layer; DLL for library > crypto. Build for EMX -Zmtd > > [I did not make Win32 descriptions as informative as this - I'm afraid to > break something. Be welcome to fix this.] > > d) On OS/2 the generated DLL was hardly usable (it had a shared initialized > data segment). > > e) On OS/2 the generated DLLs had names like ssl.dll. However, DLL names on > OS/2 are "global data". It is hard to have several DLLs with the same > name on the system. Thus this precluded coexistence of OpenSSL with DLLs > for other SLL implementations - or other name clashes. I transparently > changed the names of the DLLs to open_ssl.dll and cryptssl.dll. > > f) The file added in (a) is used to create "forwarder" DLLs, so the > applications expecting the "old" DLL names may use the new DLLs > transparently. (A presence of these DLLs on the system nullifies (e), > but makes old applications work. This is a stopgap measure until the > old applications are relinked. Systems with no old applications do not > need these DLLs, so may enjoy all the benefits of (e).) > > The new DLLs are placed in os2/ and os2/noname subdirectories. > > > > -- > Johannes Hromadka > [EMAIL PROTECTED] > 2003-11-08 > > ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED] > ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
