SSL is becoming the standard for communication on the web, that's a fact. Apple is even requiring encrypted connections within apps on iOS10. While this marks a milestone, there's also still a lot of confusion around SSL. It's not quite that hard! In this article I'll talk about different validation types, differences between security and how to up your security.
Only the ownership of the domain is checked, for example by sending an e-mail to email@example.com.
The ownership of the domain is checked, your company is checked against public registers and the WHOIS data is checked and should match your company registration.
EV-certificates are best known for the green bar in most browsers. For an EV-certificate all the checks for an OV certificate are performed. Also, you have to sign a legal agreement (Subscriber Agreement) , phone verification is performed and depending on the CA some additional checks are done.
What is important to note in the definition list above is that all of the differences are in the 'Validation'-part, technically every type of certificate is equally secure. But it's important to divide the meaning of the certificate being 'secure' in to two seperate parts, with 'secure' people might think of the assurance that the website where they are purchasing something is actually the same as they think it is and some people might think of security as the technical security, meaning that the connection between the user and the website is technically secure. Also there's a third group that has never even noticed there's a padlock showing up in their browser, no offense.
The difference between different types of certificates is mostly in the way they are validated. A simple DV-certificate does not prove the domain is owned by the company it claims to be, take Apple for example. If someone were to register theofficialapplerepairstore.com, he might be able to purchase a DV-certificate for it, with that certificate the green padlock would show up and one might believe it was an actual Apple website. But this certificate does not prove that, and neither is it meant to prove that.
What a DV-certificate can actually do is enabling a webserver to prove to it's clients that he is actually allowed to host the website for that domain name. Because only the owner can verify it is his domain name only he will be able to get a DV-certificate issued.
As the name of this certificate implies it's able to make the connection between a physical/reallife company and an online domain. The additional checks that are performed include the following.
The CA checks if the company wanting to have a certificate issued actually exists, for example by checking the Chamber of Commerce (In the Netherlands) or the D&B database.
The CA checks if the WHOIS data for the domain is the same as the details the company is officially registered with.
Some CA's also call the publicly registered phone-number for the company and ask a company official to state the certificate was intentionally ordered.
The above are additional checks performed, of course also the domain ownership is checked.
Freave's green bar EV-certificates give website users the highest form of assurance, in most browsers the adressbar turns green and displays the company name.
The checks performed for an EV-certificate are in fact not much more rigorous than those for an OV-certificate, however, CA's are more strict when issuing an EV-certificate, example below. And some CA's require the company to sign a legal agreement with the CA. Furthermore for EV-certificates it's not possible to have a wildcard issued. This is so the CA can verify each and every domain that a certificate is issued for.
So now we know exactly how SSL-certificates are validated, logically the certificate with the most thorough validation is also the most expensive (which is an EV-certificate). Does this mean that you'll need EV to secure your website? Simple answer; for the technical security of a website it does not matter which kind of certificate one purchases.
For the technical security of a website it does not matter which kind of certificate one purchases.
Let's clarify the statement above. Because the technical security is dependent on the webserver the certificate is installed on we could very well state that a website with an EV-certificate could potentially be less secure then a website which uses a DV-certificate. Like I said, it depends on the way the web server is configurated, so what could one do to make his website safer?
Use strong cipher suites
When a browser connects to a website (over HTTPS) an SSL-handshake is performed, this concists of some back-and-forth 'talking' between browser and client. At one point of this handshake the webserver presents the cipher suite of his choice, the webserver can be configured to only use secure cipher suites. The client presents which cipher suites it can handle and the webserver chooses the most secure one from the list is has. That does indeed mean that older webbrowsers which might not support newer ciphers could be locked out from a website. (Which I think is not a bad thing since it's safe to say the connection would just be insecure).
As a web server administrator it's therefore very important to configure the webserver like so that it will only setup a connection when the client supports strong cipher suites. So, maybe you're just starting out as an administrator or just host a basic blog and at this point you're like Cipher suites? What? How do I configure this?, well, not to worry! Below you'll find an example for Apache and nginx (the two most popular ones) on how to configure strong cipher suites.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5; ssl_prefer_server_ciphers on;
SSLProtocol all -SSLv2 -SSLv3 SSLHonorCipherOrder on SSLCipherSuite "EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;"
Please note that this is not the only way to go, if you have a configuration that works better on your website that's fine!
The Public Key Pinning Extension for HTTP (HPKP) is a security feature that tells a web client to associate a specific cryptographic public key with a certain web server to prevent MITM attacks with forged certificates.Mozilla (MDN)
As explained above HPKP provides a way for webbrowsers to tell if the certificate they're presented with is actually the certificate used by the website. But how?
To implement HPKP you'll need the public keys of your website's certificate, there are several tools and commands to do that, I'll tell you in a minute. At this point you might be wondering how the browser gets the Public Keys that are considered keys that belong to the website, this is done through HTTP headers. A website includes a header with every HTTPS request including the public keys used for that particular website. A header might look like the following.
pin-sha256='ZDYxOGYzOWQ2MDI0NDRhYzMyNzVkZDA2NDdmODJiODczZjExOWE5YWQ4MjQxYTIxNzUzZDEwMDc3NmM2MjgxMA=='; pin-sha256='NGIwNzc5NWZlZmRlMTY0MDI3YWQxZGUzMmI3NmJkMDdiOTgxZTY2NzQ3ODNjYmJjZGNiMzc4MjZhYjkyYzIzMg=='; max-age=86400
As you can see this string contains 2 pins, this is commonly done so that we have one backup key, this is the public key of a private key we've previously generated accompanied with a CSR. In the event that our current private key is compromised, we can revoke the current certificate and re-issue a new one with the CSR that is corresponding with our public key. If we didn't have a backup key in the event of a compromised key our website would become unreachable since our new certificate has another key than the keys presented in our HPKP header. You might also have noticed the max-age tag in our HPKP configuration, this tells the browser for how long to save the provided public keys. You want to set this to more then a few months.
How to get the public key?
There are some ways to go about this, an easy way would be to use a tool, this one being provided by report-uri.io. With the tool you can easily generate the hash of a certificate or you could simply calculate the hash of a certificate which is already on your site.
You could also use openSSL on your local machine, which makes it possible to generate the hash from a private key, useful when you need the hash of a CSR which has not yet been issued a certificate for (for example for your backup key).
From a key
openssl rsa -in my-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
From a CSR
openssl req -in my-signing-request.csr -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
raymii.org also has an interesting article writing about how to configure HPKP on your webserver.
Usage in the wild
So does Freave use HPKP? Of course we do, however, for now we have quite a short 'max-age' due to the fact we're frequently switching our configuration and certificates and we don't want anyone to be unable to connect to our website. Furthermore we have 5 pins instead of 2, meaning we have 1 active key and 4 backups. In case of a disaster we'll always have the possibilty to re-issue our main certificate. (Even if this happens in a short time, 3 times over).
One last note on HPKP. Some people don't pin the certificate they use but the Certificate Authority that issued the certificate, this is bad practice for most organizations. Most organizations will have their certificate issued by another company like Globalsign, Comodo, Symantec, etc. In that case pinning the CA means that anyone with a certificate from that CA could potentially forge your website. Of course this is far fetched, but if you want to use HPKP, use it good! By the way, I said ... for most organizations. because big corporations (Like Google, Apple, the Dutch government, etc.) have their own (intermediary) certificate. In such case the fact that the certificate was issued from that intermediary certificate already proves the authenticity of any certificate issued from that CA.
Before you read any further, open up your terminal and stand ready to implement it. So, what is HSTS? It stands for HTTP Strict Transport Security and is just like HPKP a configuration we send to the browser using HTTP headers.
HSTS however tells the browser to from the moment it receives the header only fetch the website over a secured connection. The main paramater of this configuration is the max-age and tells the browser for how long to remeber the setting. After browsers start receiving this header, there's no way back, so when you enable this make sure you'll be able to serve your website over HTTPS for the coming time.
Implement HSTS on your webserver by adding the following header to your configuration.
If you'd wanted you could also include includeSubDomains so webbrowsers will also only try to connect to your subdomains using HTTPS, I wouldn't recommend this however because you never now if the services you'll be using in the future support HTTPS (I know, they should).