Finally, I managed to enable HTTPS on my own blog!
I opted for a quick-and-dirty solution based on a self-compiled version of HAProxy in front of WordPress, statically linked to OpenSSL 1.0.2, in order to serve Certificate Transparency information during the TLS setup.
The recent OpenSSL 1.0.2 version added support for Certificate Transparency (CT) RFC6962 by implementing one of the methods that allow TLS clients to receive and verify Signed Certificate Timestamp during the TLS handshake, that is the OCSP response extension. My goal here is to show how to use another method, the signed_certificate_timestamp TLS extension, to gain the same result.
While dealing with the SHA-1 sunsetting process I encountered a problem with some certificates from StartSSL/StartCom that may lead Chrome to raise warnings or even errors on websites with updated SHA-2-only chains (at least on Microsoft Windows clients).
I’m happy to see that more and more tools are developed to increase the security level and trustworthiness of Internet applications. I already talked about DNSSEC and tools to check the validity of domain names, many others blogged about DANE and TLSA validation support in browsers; this time I would like to focus on DKIM and on a Thunderbird add-on to verify its signatures taking advantage of DNSSEC end-to-end validation.
After reading the interesting post by Stéphane Bortzmeyer on RIPE Labs (How Many RIPE Atlas Probes Can Resolve IPv6-only Domain Names?) I wondered how many RIPE Atlas probes used DNSSEC aware resolvers, so I tried to setup some measures and some comparisons.
As also expressed in the aforementioned post, it should be noted that RIPE Atlas probes can’t be used to represent general behaviors of Internet users; they are excellent “toys” in the hands of network engineers but nobody can ensure that their configuration reflects the one used in production environments by users or by servers or by applications.