ACME / OVH / DANE
sourcesACME / OVH / DANE which I would now call AOD (a meta-meta-acronym) is a utility that runs in the background, on a server (a daemon). Its job is to generate a certificate and to renew it automatically. The originality of AOD lies in the fact that it synchronizes the certificate renewal with an uploading of its hash in the DNS zone. This step will be detailed below, in the section explaining the DANE.
The AOD daemon in operation:
ACME? OVH? DANE? What is that?
AOD is unique in that, it's the only one (as far as I know) that combines the following 3 technologies:
ACME — Automatic Certificate Management Environment
ACME is a communication protocol that allows certificate authorities and server owners to manage the creation of certificates in an automated way. The ACME protocol is used by AOD for creating and renewing certificates. AOD proves to the certificate authority that the domain is indeed under the control of the server, by inserting tokens into the DNS zone.
OVH — Online Virtual Hosting
It is necessary for AOD to be able to make changes in the DNS zone. Both for adding tokens proving that the domain is under the control of the server, but also for uploading hashes (this process will be detailed in the next section). Unfortunately, there is no standardized protocol allowing this. It is therefore necessary to connect to the hosting provider API and the tool will only be compatible with this hosting provider.
Thus, AOD makes DNS the zone changes via the OVH API and is really bound to this hosting provider. This is what makes it so specific and justifies the need to develop this tool, which is too specific to already exist.
DANE — DNS based Authentication of Named Entities
DANE is a security protocol, which allows to link a certificate to a domain by adding, in the DNS zone, a field containing the hash of the certificate.
The main objective is to be able to use self-signed certificates, that is to say no longer needing a certificate authority. The authenticity of the certificate is no longer ensured by the signature of the authority, but by the presence of the fingerprint in the DNS zone.
However, this is not for this reason that AOD uses DANE (the certificate is issued by a certificate authority via ACME). AOD uses DANE to provide a proof of the existence of the certificate. Indeed, the presence of the hash in the DNS zone indicates the existence of a certificate and therefore, the existence of a secure channel. Therefore, somebody who would try to communicate with the server, would not be fooled by an attacker, located in the middle, who would try to downgrade the communications to an insecure channel by blocking communications on the secure one. Indeed, the person would understand that the secure channel does indeed exist, but that his attempts to communicate are being blocked. In this way, one can keep the insecure channel for reasons of backward compatibility and add a secure channel without risking downgrade attacks.
All of that for what?
I decided to host my own a mail server. This brings several positive points compared to a consumer email service:
- My personal data are hosted at home and not elsewhere.
- I can easily add as many domains, addresses and aliases as I want without having to pay an extra.
- The only space limit is the hard drive I plug into the server.
- I know how the server has been secured and can therefore place my trust in the infrastructure.
Being a former user of ProtonMail, the bar is quite high in terms of security and privacy. However, I want to do at least as good as them in that aspect, otherwise there is no point in hosting your own server.
After setting up an infrastructure was robust enough, something critical was missing from a security point of view: protection against downgrade attacks. Indeed, an attacker could easily alter the communications between my server and the other servers, in order to force the usage of an insecure channel and thus compromise the content of the messages.
That's why I developed this tool, very specific to my use case. The hash of the certificate that my mail server uses is synchronized to a field in the DNS zone, thus preventing downgrade attacks. At least, for communications with other mail servers that support DANE.
However, it should be remembered that email protocols are not really secure or not secure at all. The security that was set up here is better than nothing, but one must not rely on it and believe that the email communications will be private.