SSL Introduction
Normal web traffic is sent unencrypted over the Internet. That is,
anyone with access to the right tools can snoop all of that traffic.
Obviously, this can lead to problems, especially where security and privacy
is necessary, such as in credit card data and bank transactions. The Secure
Socket Layer is used to encrypt the data stream between the web server
and the web client (the browser).
SSL makes use of what is known as asymmetric cryptography,
commonly referred to as public key cryptography (PKI). With public key
cryptography, two keys are created, one public, one private. Anything
encrypted with either key can only be decrypted with its corresponding
key. Thus if a message or data stream were encrypted with the server's
private key, it can be decrypted only using its corresponding public key,
ensuring that the data only could have come from the server.
A common question is if SSL utilizes public key cryptography to
encrypt the data stream traveling over the Internet, then why is a certificate
necessary? The technical answer to that question is that a certificate is not
really necessary, because the data is secure and cannot easily be decrypted
by a third party. However, certificates do serve a crucial role in the
communication process. The certificate, signed by a trusted Certificate
Authority (CA), ensures that the certificate holder is really who he claims
to be. Without a trusted signed certificate, your data may be encrypted,
however, the party you are communicating with may not be whom you
think. Without certificates, impersonation attacks would be much more
common.
Session Establishment
The SSL session is established by following a handshake sequence
between client and server. Once an SSL session has been established it may
be reused, thus avoiding the performance penalty of repeating the many
steps needed to start a session. For this the server assigns each SSL session a
unique session identifier, which is cached in the server and which the client
can use on forthcoming connections to reduce the handshake. The elements
of the handshake sequence, as used by the client and server, are listed below:
1.
2.
3.
4.
Negotiate the Cipher Suite to be used during data transfer
Establish and share a session key between client and server
Optionally authenticate the server to the client
Optionally authenticate the client to the server
Handshake Sequence Protocol
The handshake sequence uses three protocols:
 The SSL Handshake Protocol for performing the client and server
SSL session establishment.
 The SSL Change Cipher Spec Protocol for actually establishing
agreement on the Cipher Suite for the session.
 The SSL Alert Protocol for conveying SSL error messages between
client and server.
These protocols, as well as application protocol data, are encapsulated in
the SSL Record Protocol. An encapsulated protocol is transferred as data by
the lower layer protocol, which does not examine the data. The encapsulated
protocol has no knowledge of the underlying protocol. The encapsulation of
SSL control protocols by the record protocol means that if an active session
is renegotiated the control protocols will be transmitted securely.
Certificate Generation
RSA Private Key Creation With Triple-DES
The first step in certificate generation is to create a RSA Private Key.
This key is a 1024 bit RSA key, which is encrypted using Triple-DES and
stored in a PEM format so that it is readable as ASCII text. Several files will
be used as random seed enhancers, which will help make the key more
secure. The key is generated using the following command, where
file1:file2:etc represents the random files.
root@jackel:/var/tmp/CERT $ /usr/local/ssl/bin/openssl genrsa -des3 -rand
/var/adm/messages:/var/adm/messages.0:/var/adm/messages.1 -out
www.muhannasweets.com.key 1024
570 semi-random bytes loaded
Generating RSA private key, 1024 bit long modulus
...................++++++
..........................................++++++
e is 65537 (0x10001)
Enter pass phrase for www.muhannasweets.com.key:
Verifying - Enter pass phrase for www.muhannasweets.com.key:
RSA Private Key Creation Without Triple-DES
One unfortunate side-effect of the pass-phrased private key is that
Apache will ask for the pass-phrase each time the web server is started.
Obviously this is not convenient because someone will have to be around to
type in the pass-phrase if a server reboots or crashes. mod_ssl includes the
ability to use an external program in place of the built-in pass-phrase dialog,
however, this is not necessarily the most secure option. It is possible to
remove the Triple-DES encryption from the key, thereby no longer needing
to type in a pass-phrase. If the private key is no longer encrypted, it is
critical that this file only be readable by the root user! I am using this
method, because I would like apache to start without somebody physically
typing a pass-phrase if the server reboots or accidentally crashes.
root@jackel:/var/tmp/CERT $ /usr/local/ssl/bin/openssl rsa -in
www.muhannasweets.com.key -out www.muhannasweets.com.key
Enter pass phrase for www.muhannasweets.com.key:
writing RSA key
Certificate Signing Request Generation
Once the private key is generated a Certificate Signing Request is
generated. The CSR is then used in one of two ways. Ideally, the CSR will
be sent to a Certificate Authority, such as Verisign who will verify the
identity of the requestor and issue a signed certificate. The second option is
to self-sign the CSR. Below is an example of a CSR that would be signed
by a CA; however, I generated a self-signed certificate which is documented
in the next section.
root@jackel:/var/tmp/CERT $ /usr/local/ssl/bin/openssl req -new -key
www.muhannasweets.com.key -out www.muhannasweets.com.csr
Enter pass phrase for www.muhannasweets.com.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
----Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Oklahoma
Locality Name (eg, city) []:Jenks
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Muhanna Sweets
Organizational Unit Name (eg, section) []:Sweet Shop
Common Name (eg, YOUR name) []:www.muhannasweets.com
Email Address []:info@muhannasweets.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:muhanna33
An optional company name []:
Generating a Self-Signed Certificate
At this point you will need to generate a self-signed certificate
because you either don't plan on having your certificate signed by a CA, or
you wish to test your new SSL implementation while the CA is signing your
certificate. In my experience dealing with Verisign, it can take up to a week
or more before receiving your signed certificate. The time it takes to receive
the certificate will vary based on how quickly they receive your required
documentation. This temporary certificate will generate an error in the
client browser to the effect that the signing certificate authority is unknown
and not trusted. To generate a temporary certificate, which is good for 365
days, issue the following command:
/usr/local/ssl/bin/openssl x509 -req -days 365 -in www.muhannasweets.com.csr -signkey
www.muhannasweets.com.key -out www.muhannasweets.com.crt
Signature ok
subject=/C=US/ST=Oklahoma/L=Jenks/O=Muhanna Sweets/OU=Sweet
Shop/CN=www.muhannasweets.com/emailAddress=info@muhannasweets.com
Getting Private key
Enter pass phrase for www.muhannasweets.com.key:
Installing the Private Key and Certificate
When Apache with mod_ssl is installed, it creates several directories
in the Apache config directory. The location of this directory will differ
depending on how Apache was compiled. Usually the apache-mod_ssl
config directory is located in /usr/local/apache/etc. The directories mod_ssl
creates include ssl.crt, ssl.csr, and ssl.key.
root@jackel:/usr/local/apache/etc $ ls -l
total 6
drwxr-xr-x 2 root other
512 Apr 27 15:36 ssl.crt
drwxr-xr-x 2 root other
512 Apr 27 15:36 ssl.csr
drwxr-xr-x 2 root other
512 Apr 27 15:36 ssl.key
Copying the files to the appropriate directories
root@jackel:/usr/local/apache/etc $ cp /var/tmp/CERT/www.muhannasweets.com.crt ssl.crt/
root@jackel:/usr/local/apache/etc $ cp /var/tmp/CERT/www.muhannasweets.com.csr ssl.csr/
root@jackel:/usr/local/apache/etc $ cp /var/tmp/CERT/www.muhannasweets.com.key* ssl.key/
These directories are good locations to store server certificates,
certificate signing requests, and private keys. The apache “virtualhosts”
directive refers to www.muhannasweets.com. When adding SSL enabled
“virtualhosts” to the web server, it is a good practice to keep all of the SSL
“virtualhosts” in a separate file. This insures that all SSL hosts can be easily
found in one location and helps to keep the httpd.conf file from growing too
large. The SSL “virtualhosts” will be kept in a file called ssl.conf. In order
for Apache to recognize and parse this file, it must be included in the
httpd.conf file with the following directive:
Include /usr/local/apache/etc/ssl.conf
ssl.conf Contents Example
This will create an SSL “virtualhost” named
www.muhannasweets.com, which is accessed via port 443 (the standard port
for https) on the default IP address of the web server.
# SSL Virtual Hosts
<IfDefine SSL>
#Specifies the port of https which is 443
<VirtualHost _default_:443>
#Specifies the webmaster address for muhannasweets.com
ServerAdmin info@muhannasweets.com
#Specifies the website home directory for muhannasweets.com
DocumentRoot /usr/local/apache/htdocs/Muhanna
#Specifies the website’s name
ServerName www.muhannasweets.com
#Specifies where the cgi-bin is located
ScriptAlias /cgi-bin/ /usr/local/apache/htdocs/cgi-bin/
SSLEngine on
#Location of certificate
SSLCertificateFile
/usr/local/apache/etc/ssl.crt/www.muhannasweets.com.crt
#Location of key
SSLCertificateKeyFile /usr/local/apache/etc/ssl.key/ www.muhannasweets.com.key
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
CustomLog /usr/local/apache/var/log/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
</IfDefine>
Stopping and Starting Apache
In order for the changes to take affect, Apache must be stopped and
restarted with the “startssl” option.
Stopping Apache
root@jackel:/usr/local/apache2/bin $ ./apachectl stop
Starting Apache with “startssl”
root@jackel:/usr/local/apache2/bin $ ./apachectl startssl
Below is a process list of the httpd Apache process running with “secure socket layers”.
root@jackel:/usr/local/apache2/bin $ ps -eaf | grep http
nobody 2771 2767
0 16:32:44 ?
0:00 /usr/local/apache2/bin/httpd -k start -DSSL
root 2774 28622 0 16:32:51 pts/2 0:00 grep http
nobody 2769 2767
0 16:32:44 ?
0:00 /usr/local/apache2/bin/httpd -k start -DSSL
nobody 2770 2767
0 16:32:44 ?
0:00 /usr/local/apache2/bin/httpd -k start -DSSL
root 2767 1
1 16:32:44 ?
0:00 /usr/local/apache2/bin/httpd -k start -DSSL
nobody 2768 2767
0 16:32:44 ?
0:00 /usr/local/apache2/bin/httpd -k start -DSSL
nobody 2772 2767
0 16:32:44 ?
0:00 /usr/local/apache2/bin/httpd -k start –DSSL
Currently, I have https turned off, because it significantly slows down
accessing pages on my Solaris Sparc 5. The below picture illustrates how
https would function if it were engaged. Not the blue rectangle surrounding
the “https”. Also notice the red rectangle surrounding the lock, which
signifies that a secure web page.
When you click on the yellow lock, you are presented with the below certificate. Notice
that this certificate is not trusted, because it is self-signed. After I move this sight to a
higher end server, I will request a CA signed certificate.
Installing A Certificate