|
|
4.3. OpenSSLOpenSSL is the open source implementation (toolkit) of many cryptographic protocols. Almost all open source and many commercial packages rely on it for their cryptographic needs. OpenSSL is licensed under a BSD-like license, which allows commercial exploitation of the source code. You probably have OpenSSL installed on your computer if you are running a Unix system. If you are not running a Unix system or you are but you do not have OpenSSL installed, download the latest version from the web site (http://www.openssl.org). The installation is easy: $ ./config $ make # make install Do not download and install a new copy of OpenSSL if one is already installed on your system. You will find that other applications rely on the pre-installed version of OpenSSL. Adding another version on top will only lead to confusion and possible incompatibilities. OpenSSL is a set of libraries, but it also includes a tool, openssl, which makes most of the functionality available from the command line. To avoid clutter, only one binary is used as a façade for many commands supported by OpenSSL. The first parameter to the binary is the name of the command to be executed. The standard port for HTTP communication over SSL is port 443. To connect to a remote web server using SSL, type something like the following, where this example shows connecting to Thawte's web site: $ openssl s_client -host www.thawte.com -port 443 As soon as the connection with the server is established, the command window is filled with a lot of information about the connection. Some of the information displayed on the screen is quite useful. Near the top is information about the certificate chain, as shown below. A certificate chain is a collection of certificates that make a path from the first point of contact (the web site www.thawte.com, in the example above) to a trusted root certificate. In this case, the chain references two certificates, as shown in the following output. For each certificate, the first line shows the information about the certificate itself, and the second line shows information about the certificate it was signed with. Certificate information is displayed in condensed format: the forward slash is a separator, and the uppercase letters stand for certificate fields (e.g., C for country, ST for state). You will get familiar with these fields later when you start creating your own certificates. Here is the certificate chain: Certificate chain 0 s:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting (Pty) Ltd/OU=Security/CN=www.thawte.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority You may be wondering what VeriSign is doing signing a Thawte certificate; Thawte is a CA, after all. VeriSign recently bought Thawte; though they remain as two different business entities, they are sharing a common root certificate. The details of the negotiated connection with the remote server are near the end of the output: New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : EDH-RSA-DES-CBC3-SHA
Session-ID: 6E9DBBBA986C501A88F0B7ADAFEC6529291C739EB4CC2114EE62036D9B
F04C6E
Session-ID-ctx:
Master-Key: 0D90A33260738C7B8CBCC1F2A5DC3BE79D9D4E2FC7C649E5A541594F37
61CE7046E7F5034933A6F09D7176E2B0E11605
Key-Arg : None
Krb5 Principal: None
Start Time: 1090586684
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)To understand these values, you would have to have a deep understanding of the SSL protocol. For our level of involvement, it is enough to recognize the protocol being used, which can be seen on the fourth line above. In our case, the TLSv1 protocol is used. However, it is worrisome that the last line reports an error in certificate verification. The problem arises because openssl does not have enough information to verify the authenticity of the last certificate in the chain. The last certificate in the chain is a root certificate that belongs to VeriSign. In most cases, you would have to download the root certificate from a trusted location. Since VeriSign is a well-known CA, however, its root certificate is distributed with OpenSSL. You just need to tell the tool where to look for it. The certificate is a part of the OpenSSL supported files. The exact location depends on the operating system. On Red Hat systems, it is in /usr/share/ssl. On Debian, it is in /usr/local/ssl. To find the location of the OpenSSL configuration and shared files, type: $ openssl ca Using configuration from /usr/share/ssl/openssl.cnf ... The first line of the command output will tell you where the certificates are. Bundled certificates are provided in a single file that resides in the /certs subfolder of the folder that contains openssl.cnf in a file called ca-bundle.crt. Armed with the path to the certificate bundle, you can attempt to talk SSL to the web server again, supplying the path to the openssl binary in the CAfile parameter: $ openssl s_client -host www.thawte.com -port 443 \
> -CAfile /usr/share/ssl/certs/ca-bundle.crt
...
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : EDH-RSA-DES-CBC3-SHA
Session-ID: F2C04CD240C5CA0DF03C8D15555DB1891B71DA6688FA78A920C808362C
822E1E
Session-ID-ctx:
Master-Key: 5F662B2E538E628BDE2E9E0F324CE88D57CCB93FCFCCFB52761AA0728B
487B80DE582DC44A712EFA23370A8FDD9BF6AD
Key-Arg : None
Krb5 Principal: None
Start Time: 1090588540
Timeout : 300 (sec)
Verify return code: 0 (ok)This time, no verification errors occur. You have established a cryptographically secure communication channel with a web server whose identity has been confirmed. At this point, you can type an HTTP request just as you would if connecting via a Telnet command: HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Fri, 23 Jul 2004 11:36:49 GMT Server: Apache Connection: close Content-Type: text/html closed |
|
|