Proper SSL using letsencrypt.org

Now that letsencrypt.org entered public beta, I took the opportunity to use their fantastic service and deploy a new site certificate for madnet.ch and the other sites hosted on this platform.

The letsencrypt client was a bit confusing first but after I understood what the ACME protocol actually means, I saw the entire beauty behind this solution. So I did a quick review of the code in Github and shortly after I requested the first certificate. As I already have an Apache server running and don’t need the embedded web server stuff provided by the letsencrypt client, I only use the CSR and certificate download part of the client.

After a while I figured out how to request proper alternate subject names as well and was finally able to secure all the services running on madnet.ch with only a single certificate deployed to my Apache.

To request/renew a certificate for different hosts/domains, you basically just do:

letsencrypt-auto certonly \
--webroot \
--renew-by-default \
-w /home/to/htdocs/madnet.ch/ \
-d www.madnet.ch \
-d madnet.ch \
-d mail.madnet.ch \
-w /home/to/htdocs/anothersite/ \
-d www.anothersite.ch \
-d anothersite.ch

I also took the chance to improve the SSL configuration of my Apache web server considering recommendations from SSLLabs

After an upgrade to Apache 2.4.18, generating a proper DH parameter file and append it to the letsencrypt certificate chain, SSLLabs rates us with an A+.

SSLLabsResultMadNet

Apache 2.4 SSL configuration (ssl-global.conf) 

# Added dhparams to fullchain.pem
# If you have different certificates per vhost, 
# add these to your vhost config instead
SSLCertificateFile /etc/letsencrypt/live/xxxx/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/xxxx/privkey.pem

SSLHonorCipherOrder     on

SSLProtocol All -SSLv2 -SSLv3

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SNI enabled virtual host configuration

<VirtualHost *:443>
  SSLEngine On

  # Strict Transport Security per virtual host
  <IfModule mod_headers.c>
     Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
  </IfModule>
</VirtualHost>
 

Getting ready for IPv6

Today, I decided my server needs to get ready for the future. That means I have to configure IPv6.
Luckily my cloud provider supports IPv6 for quite some time now and I was able to pick an address from his IP address space like 1-2-3.

Configuring the OpenSuSE was a bit tricky and my first 2 attempts failed miserably.
But once I figured out what the auto config script of my provider’s Virtual Server Network Build did wrong, it was quite easy to configure the static IP and add the right default routes.

Proof:

PING www.madnet.ch(2001:8e0:40:315::1:ff) 32 data bytes
40 bytes from 2001:8e0:40:315::1:ff: icmp_seq=0 ttl=56 time=15.1 ms
40 bytes from 2001:8e0:40:315::1:ff: icmp_seq=1 ttl=56 time=15.0 ms
40 bytes from 2001:8e0:40:315::1:ff: icmp_seq=2 ttl=56 time=15.0 ms
40 bytes from 2001:8e0:40:315::1:ff: icmp_seq=3 ttl=56 time=15.0 ms

--- www.madnet.ch ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3013ms
rtt min/avg/max/mdev = 15.039/15.083/15.155/0.157 min schatz, pipe 2

Checked port 80 on Host/IP www.madnet.ch...

The checked port (80, service http) is online/reachable!

Completed portscan in 0.1194 seconds
 

Tuning Gigabit Ethernet on Mac OS X (10.5)

I recently bought a new NAS (Netgear ReadyNAS Duo) and attached it to my gigabit ethernet network. Unfortunately I only got transfer rates at around 10 MB/s which is really poor. I enabled Jumbo Frames (MTU > 1500) but this didn’t help much. So I did a bit more research and found out that the limiting factor was not only the MTU but the send and receive buffers.
This means my CPU was not able to catch up with the speed of the gigabit ethernet. What I did then was to increase the send and receive buffers for TCP/UDP traffic. É voilà! Now I get at least 35 MB/s. Still not the max a gigabit ethernet can offer, but I’m on the right way. I’d like to see something like 80-90 MB/s. Given the Samsung Disk can do at least 175 MB/s to/from buffer this should be possible.

I use the following parameters in my sysctl.conf:

kern.ipc.maxsockbuf=2500000
net.inet.tcp.sendspace=1000000
net.inet.tcp.recvspace=1000000
net.inet.tcp.mssdflt=7936
net.inet.tcp.delayed_ack=0

The buffers are probably too high, I know.