It is Really Easy to Do Dumb SSL Things

‹prev | My Chain | next›

In an ongoing attempt to figure out why my SSL negotiation is suddenly taking ~700ms instead of 250ms, tonight I try SSL in nginx. It is conceivable that the node.js SSL implementation is somehow causing problems (connections to other HTTPS sites work). So trying the same key + certificate with a reference SSL implementation seems like a good next step.

To enable SSL, I edit /etc/nginx/sites-enabled/default, uncommenting the HTTP server configuration:

# HTTPS server
#
server {
listen   443;
server_name  localhost;

ssl  on;
ssl_certificate  cert.pem;
ssl_certificate_key  cert.key;

ssl_session_timeout  5m;

ssl_protocols  SSLv3 TLSv1;
#ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
ssl_ciphers DES-CBC3-SHA;
ssl_prefer_server_ciphers   on;

location / {
#root   html;
root   /var/www;
index  index.html index.htm;
}
}

I change the root setting to re-use the root directory that already contains static HTML (/var/www). I also stick with a cipher that I know Wireshark can decode.

When I load the site, I find a normal SSL client hello from the browser:



And then another client hello from the browser:



Followed by several connection closures (FINs):



Until finally, I see a new connection open that successfully complete the handshake:



Since I am seeing the same behavior with nginx and my express-spdy implementation, it is time to admit that either there is something wrong with my certificate or my methodology.

Either way it's my mistake. But how to track it down?

Aha! Chrome's about:net-internals page has more than just a SPDY tab. The Events tab keeps track of all sorts of events. Maybe it logs SSL events?

It does!

Filtering events on my VM's www.local hostname, I see:



Hrm... there are three different groups of CONNECT_JOB events. Taking a closer look, I find a common name error:



In fact, that common name error happens twice:

t=1311649121151 [st=17]    -SOCKET_POOL_CONNECT_JOB_CONNECT  
                            --> net_error = -200 (CERT_COMMON_NAME_INVALID)

Arrgh! Now that I think about it, these SSL woes started right about the time that I started messing about with VMs and differently named hosts.

Chrome remembers that I OK'd the invalid certificate (even after I clear the cache). It seems as though Chrome is still trying to verify the SSL certificate like normal, but eventually giving up and falling back to the session exemption that I have already made for this invalid certificate.

The SSL certificate is for localhost. When I am testing against localhost (as I did for most of my book), I am not incurring this obscene negotiation penalty. When I am trying to use the localhost SSL certificate against a differently named server all sorts of badness arises.

Sigh.

Up tomorrow, I think I go back to generating and signing certificates.


Day #83