Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lavabit.com should be fixed #47

Closed
ladar opened this issue Jan 22, 2019 · 7 comments

Comments

Projects
None yet
3 participants
@ladar
Copy link

commented Jan 22, 2019

We updated the TLS cert earlier this month, and looks like the new TLSA records didn't propagate from the master NS to the slaves. It should be fixed now. If not, let me know.

@desh-se

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

From what I can see, it's resolved. All four (ns1-4) now return FA1B412A4BB93C... and https://dane.sys4.de is happy.

$ dig +short _25._tcp.lavabit.com. tlsa @ns3.lavabit.com
3 0 1 FA1B412A4BB93C4A9F7A24991ED990583EF5283C837C15BB8AE80316 4CB1CD26

@desh-se desh-se closed this in d7ac564 Jan 22, 2019

@vdukhovni

This comment has been minimized.

Copy link
Collaborator

commented Jan 23, 2019

Yes, all fixed, and issue closed, but for the record I would like to recommend working published email contacts for the domain, "3 1 1" instead of "3 0 1" records, and actually always two TLSA records for the domain, at least one of which is valid on post key/cert rollover and another pre key/cert rollover, so that there's never a time when the cert is out of sync with cached TLSA RRs. And of course monitoring, including monitoring. A useful resource is: https://github.com/baknu/DANE-for-SMTP/wiki/1.-Implementation-resources

@ladar

This comment has been minimized.

Copy link
Author

commented Jan 23, 2019

The contacts are valid, but our support address gets 300 messages per day, so a lot gets lost in the noise. The engineer tasked with responding only replies to 10 - 20 messages per day..

@vdukhovni why do you suggest 3 1 1 records? Sounds like that makes sense if your rolling the cert, but keeping the same public key. We recently switched to a 2 year EV cert, which (hopefully) won't need to be changed for awhile. So I prefer the added security of a full cert signature.

As for updating, I have scripts to create/manage the TLSA records, but this was the first time I've had to update the records since I wrote those scripts... and I had to relearn how to do it. Which I did. But of course, I forgot to force a slave update. I thought my recently rebuilt name servers would were sync'ing, but apparently they aren't, so I'll need to investigate that...

@vdukhovni

This comment has been minimized.

Copy link
Collaborator

commented Jan 23, 2019

I recommend "3 1 1" records, because with "3 1 1" not only can you keep the TLSA record stable when not changing the key, but when you do roll the key regularly, you can generate the key and publish the TLSA associated record well in advance of obtaining the new certificate. Indeed with the recommended "3 1 1 + 3 1 1" scheme, you'd generate the next key and TLSA RR as soon as you deploy the current key/cert pair.

So you can use "Let's Encrypt" (EV certs are a waste of money for SMTP, nobody cares and the sending MTAs don't see a "green" bar in the non-existent address bar), and rotate keys every 60-90 days, and automate everything, so there's no manual process that happens only every couple of years and never quite fresh enough in the operator's mind to make it reliable.

So I'd say that your 2-year EV cert is not only needlessly expensive and pointless, but its long lifetime harms the reliability (and thus security) of your site. When certificate rotation breaks TLSA records, senders learn to add exceptions for you site, that might never be removed. Go with a key rotation approach that is frequent and automated.

Don't forget to bump the SOA serial number when changing zone records, and monitor the SOA RRs on the secondary servers, as well as any looming expiration of DNSKEY/SOA/MX and TLSA RRSIGs.

Matching the certificate exactly gives no security advantage, if they have your key, they can just "borrow" your certificate, but it does make TLSA records more fragile, so don't bother with "3 0 1". There's a better case for "2 0 1" vs. "2 1 1", but only for a CA you manage yourself. With 3rd-party CAs, again "2 1 1" is better, since CAs get reissued from time to time with the same key.

@ladar

This comment has been minimized.

Copy link
Author

commented Feb 5, 2019

So I'd say that your 2-year EV cert is not only needlessly expensive and pointless, but its long lifetime is actually counter-productive to the reliablity (and thus security) of your site. When certificate rotation breaks TLSA records, senders learn to add exceptions for you site, that might never be removed. Go with a key rotation approach that is frequent and automated.

I had to purchase our cert, so I could get a wildcard common name. We need the wildcard cert, so smtp.lavabit.com, mail.lavabit.com, etc, all validate properly, regardless of what the user enters, without the need for SNI, etc.

@vdukhovni

This comment has been minimized.

Copy link
Collaborator

commented Feb 5, 2019

@ladar FWIW, IIRC Let's Encrypt now supports wildcard certs.

@ladar

This comment has been minimized.

Copy link
Author

commented Feb 5, 2019

@vdukhovni I did not know that. Once upon a time, they did not. Thank you. I'll keep it in mind when our cert expires, provided I can get our HSM to play nicely with the certbot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.