Check SSL encryption of web pages

Authors: Michael Gisbers and Christian Hesse

After we have completed the subject OpenSSH with the Linux tip in September we turn now to SSL encryption. Everyone has seen the following dialogue his browser:

This warning appears whenever the administrator of a site did not put a certificate authenticated by a Trustcenter on the server secured via SSL or if the certificate is not valid for any other reason.

With the 'Certificate' (or 'Cert') the browser checks if the key of the server is unchanged and the server name is correct.

A certificate is issued for a key file (key). This key file allows the server to encrypt or decrypt data.

Information such as the server name (' CommonName' , or 'cn') are stored in the certificate. In addition, further information on the validity period, the intended use and the exhibitor ( 'Issuer') of the certificate are included.

At the exhibitor TrustCenter come into play. These are certificate authorities to ensure by specific security policies that their stored certificate authority (or 'CA') is trustworthy. The certificates are signed by this CA and attested hat the certificates are valid. In order to follow this path, the certificates of the CA are stored in the web browser and the operating systems.

After all this theory we look to establish a connection to an SSL server:

user@linux ~ $ curl -Iv https://google.com
* About to connect() to google.com port 443 (#0)
*   Trying 173.194.70.139...
* Connected to google.com (173.194.70.139) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-ECDSA-AES128-GCM-SHA256
* Server certificate:
* 	 subject: C=US; ST=California; L=Mountain View;
* 	 O=Google Inc; CN=*.google.com
* 	 start date: 2013-09-11 11:10:44 GMT
* 	 expire date: 2014-09-11 11:10:44 GMT
* 	 subjectAltName: google.com matched
* 	 issuer: C=US; O=Google Inc; CN=Google Internet
* 	 Authority G2
* 	 SSL certificate verify ok.
> HEAD / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: google.com
> Accept: */*
[...]

The `curl` command as used herein provides with the parameter `-v '(verbose) and`-I` (only header data) a detailed insight into the connection.

First the connection to the server is established and then the SSL protocol activated. Server and `curl` then exchange the certificate and agree on an encryption for the connection.

In the block `server certificate` the actual information of the certificate is seen then. The main message here is `SSL certificate verify ok.` So the certificate matches the server and the path to a certificate authority can be checked.

Even a simple modification changes the statement:

user@linux ~ $ curl -vI https://173.194.70.139
[...]
* Server certificate:
* 	 subject: C=US; ST=California; L=Mountain View;
* 	 O=Google Inc; CN=*.google.com
* 	 start date: 2013-09-11 10:50:21 GMT
* 	 expire date: 2014-09-11 10:50:21 GMT
* SSL: certificate subject name '*.google.com' does not
* match target host name '173.194.70.139'
* Closing connection 0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name '*.google.com' does
not match target host name '173.194.70.139

In this example, the address which has been previously used to connect to the server, instead of using the server name in the URL.

Immediately `curl` puts out an error message and informes of the reason for the rejection of the certificate. To still be able to fully perform the connection, `curl` would have to use the parameter `-k` (or `--insecure`). By this certificate problems are ignored.

Another way to obtain information about connecting to a server is the allrounder `openssl`. This is not only used for generating of keys, certificates, or certificate requests, but also for the testing of SSL servers:

user@linux ~ $ echo "QUIT" | openssl s_client -connect google.com:443 -CApath /etc/ssl/certs
CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate
Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet
Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O =
Google Inc, CN = *.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google
Inc/CN=*.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google
Inc/CN=*.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 4410 bytes and written 448 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID:
68CE9DF986DDA1A70673B153EB0CDF3330AD443A943BDE94217AC67C4AF4CB8B
    Session-ID-ctx: 
    Master-Key:
3A68C9BE21DAB36E8D1CFAD12462A2CC460C5E7B05C828B8B79E96FA5BFCBD8B7533AF33C1EC66B66B86E9C9DBF57AFA
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 100800 (seconds)
    TLS session ticket:
    [...]
    Start Time: 1380707062
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE
----

The call here is a little more complicated , but provides much more information . First the program the text `QUIT` is added to the standard input to close the connection cleanly . Without this `QUIT` the connection would remain in place and the program would have to be canceled by an interruption (`Ctrl + C`).

The parameter `
-connect` specifies the server and port for the test. Usually, the port for SSL is `443`.

Because `openssl` has no own database for certificates it relies on the database stored in the operating system. `-CApath` therefore requires the path to it.

With these two tools (`curl` and `openssl`) there is the possibility
to test the certificates of the SSL encrypted server connections offside from the messages in the web browser.

The next article
s in this series deal with further options of the command `openssl` for key generation, certificate requests and certification. We will also explain the different types of certificates.