Public Key Pinning is a security feature that tells a web browser to associate a public cryptographic key with a server or servers. When a web browser visits a website for the first time, it will read the HPKP header and store the hashes for the certificates that are provided. Each time the browser then revisits that website, the hash from the provided public key is compared against the stored keys, if the hashes do not match, the web browser should display a warning.
The HPKP header adds protection against man-in-the-middle (MITM) attacks but, if incorrectly configured can make your website display a TLS error for a long period of time.
Here’s a look at what this website publishes as it’s HKPK header.
To explain it, the first pin-sha265 key is the hash of the public key that … kura
With haproxy 1.5 finally being released we are lucky enough to get a basic interface around OCSP stapling.
Sadly this interface really is quite basic and it’s not the simplest thing to figure out without some trial and error.
According to the official documentation, you should be able to pipe your OCSP response to haproxy via it’s stats socket. Sadly I could not get this to work properly at all, so I decided to swap the piping for a file and reload solution.
You’ll need to get a copy of your certification authorities root certificate to proceed with this.
Looking for your OCSP URI
If you don’t know the URI you need to do an OCSP lookup against, you can find it in your certificate data.
openssl x509 -in /path/to/your/certificate -text
Inside the output, look for the following section.
Authority Information Access …
I am a firm believer in using SSL as much as possible, for me that is pretty much everywhere and, thanks to the wonderful guys at GlobalSign, most of my SSL certificates are free becauses my projects are all open source.
I used a blog post by Hynek Schlawack as a base for my SSL setup, he is keeping this article up-to-date as much as possible so it should be a great source for any security conscious people that would like to know more and get good explanations about each part.
Let’s take a brief look at how this website achieves it’s A* rating.
I do not support SSLv2 or SSLv3 but I do support much stronger protocols;
- TLS 1.2,
- TLS 1.1 and,
- TLS 1.0.
Blackhole has always been able to handle unencrypted SMTP and for a long time it’s been able to handle encrypted SMTP via TLSv1.
One thing Blackhole hasn’t been able to do until the 1.7.0 release is handle STARTTLS.
In the past the STARTTLS command would cause Blackhole to return the standard 250 OK response but would continue to operate on unencrypted SMTP.
I wanted to fix this and do it properly, but this meant learning how to do so with Tornado, which itself proved to be tricky. I ended up deciding to go to my local coding spot - the pub and hash it out.
The first thing I had to do was refactor the code that created the instance of tornado.iostream.IOStream and tornado.iostream.SSLIOStream so that it didn’t actually do the ssl wrapping.
Detect which socket the connection …
As part of my effort to make Blackhole as useful and usable as possible, I needed to be able to support SSL/TLS enabled connections.
Tornado itself has two built-in IOStreams that help us do the job; the first is the standard IOStream and the second is the SSLIOStream.
With this in mind we simply need to spawn two sockets, by default these listen on port 25 for standard SMTP and port 465 for SSL/TLS encrypted SMTP. With these two sockets bound we’re then very simply able to listen for incoming connections on either socket and use socket.socket.getsockname() to figure out if the connection is to the encrypted or unencrypted socket.
Detect which socket the connection is being made on,
create and iostream for the connection, wrapping it
in SSL if connected over the SSL socket.
The parameter 'connection' is an instance …
I wrote an article last week explaining that I had changed my blog and built my own nginx packages with SPDY built in.
I decided I would take things a little further and poke around with haproxy some more. The initial plan was to compile the latest dev source of haproxy with SSL termination enabled.
In doing so I realised I would lose SPDY support, which upset me a little. After some digging I found that the 1.5-dev branch of haproxy supports npn and thus can handle SPDY.
I tweaked my builds a little more and managed to get haproxy running as an SSL terminating load balancer, with SPDY connections being sent off to my nginx servers with SPDY enabled and all other non-SPDY connections were passed on to an nginx virtual host with SPDY disabled.
I have released my haproxy build as a debian file below …
Sometimes keeping multiple copies of keys, certificates and root certificates can be a real annoyance, thankfully it’s quite simple to convert them in to a single PKCS#12 file with the following command.
openssl pkcs12 -export -out certificate.pkcs -in certificate.crt -inkey private.key -certfile rootcert.crt -name "PKCS#12 Certificate Bundle"
This will create a file called certificate.pkcs which will contain the contents of the certificate.crt, private.key and your root certificate rootcert.crt, it will also have an internal reference to it’s name PKCS#12 Certificate Bundle to make it easier to inspect the certificate to find what it should contain, usually you’d set this to something more useful. kura
Figured I’d write this one up quickly as it proved to annoy the hell out of me at 4:30am this morning getting it working on a live server.
Apache 2 can serve SSL content to multiple vhosts on your setup, provided they use different IP addresses, this post will give you a quick run down on how to do it.
First up we need to actually add the new IP to the machine in /etc/network/interfaces.
iface eth0 inet static
iface eth0:1 inet static
Replace my IPs with your own.
sudo /etc/init.d/networking restart
Next task is Apache 2 to configure it to listen on both IPs.