Go to file
Louis Vallat 43667bc6cf
Fixed wrong path for issuer cert
Signed-off-by: Louis Vallat <louis@louis-vallat.xyz>
2022-02-15 08:45:12 +01:00
src Fixed wrong path for issuer cert 2022-02-15 08:45:12 +01:00
.gitignore Initial commit: interaction with OVH API 2022-02-11 23:53:43 +01:00
.gitlab-ci.yml Added gitlab-ci.yml 2022-02-14 19:26:02 +01:00
Cargo.toml Basic logic for TLSA auto updating, should work but untested. 2022-02-14 19:16:41 +01:00
Dockerfile Added 211 record for 311+211, but flush and reset TLSA is a bit bruteforce-y 2022-02-15 08:39:39 +01:00
LICENSE Added LICENSE 2022-02-14 19:35:37 +01:00
README.md Added Security Addendum to README 2022-02-14 19:56:53 +01:00

OVH DANE Companion

Untested code ahead! This was done in a rush and isn't tested! It should work, but I wouldn't be surprised if it breaks sometimes.

Aim

I wanted to implement in a matter of a few days worth of free time a companion container for my Let's Encrypt container. My certificates are generated by a Docker container, and I wanted to deploy TLSA records automatically.

DANE and TLSA records are used to avoid TLS downgrade attacks, such as during a MITM attacks.

I also wanted to have a 100% score on internet.nl for my email server security, and I got it.

Rollover scheme

There isn't any. I could add a "2 1 1" record using Let's Encrypt's root certificates, but then I could just use permanently a "2 1 1" record and the "3 1 1" record would be useless.

As I used an external container to renew the certificates, I cannot modify the renewal procedure, so I can't use the "current + next" rollover scheme.

In compensation, I set the TLSA TLLs as the lowest my DNS provider allows: 60 seconds. In case of a key rollover, the TLSA records will be wrong for at most 2 minutes (2 TTLs just to make sure), as long as some entity on the way doesn't keep the record longer than the TTL specified (that can happen with lazy ISPs). TLSA records being borked for 2 minutes once every few months shouldn't be an issue.

Although this is not new, maybe a bit young (from 2012), this technology isn't widely spread.

Security addendum

Although it provides a bit more security, as it prevents MITM attacks from downgrading your TLS (or disable it all together), I would strongly recommend to send sensitive emails only using PGP encryption! Plain text emails are privacy nightmares!

  • Article from Abyss Project: link
  • Internet technologies tester: link
  • SMTP Protection HowTo: link
  • OVH API: link