Currently, Dovecot does not offer any support for OCSP, leaving system administrators with a dilemma: choosing between security or compatibility.
- What is OCSP?
OCSP (Online Certificate Status Protocol) is a network protocol used to check the validity and revocation status of digital certificates in real-time.
- What is Must-Staple?
"Must-Staple" is a certificate extension that enforces the inclusion of OCSP stapling information, requiring servers to present the certificate's revocation status during the TLS handshake.
- What advantages does the use of Must-Staple offer?
The inclusion of a 'must-staple' flag in a certificate mandates the presence of an OCSP response during a TLS handshake, ensuring that a revoked certificate remains (at worst) only usable until the expiration of the latest OCSP response, rather than the expiration of the certificate itself (subject to specific client/implementation).
https://www.reddit.com/r/selfhosted/comments/aye79v/the_case_for_ocsp_mustst...
- What is the current issue with Dovecot?
Presently, any system administrator who intends to issue must-staple certificates, faces the dilemma to either chose to
a) Refrain from issuing must-staple certificates at all, resulting in the loss of a valuable security feature. b) Issue must-staple certificates without an OCSP response in Dovecot, thereby breaking the TLS RFC (and “hope for the best” on the client side…).
A "stuck between a rock and a hard place" situation.
- Any other reasons to implement OCSP?
Regulatory frameworks such as HIPAA, PCI-DSS and more require the implementation of OCSP to enhance privacy and security. Personally, this requirement does not impact me since I am neither located in the United States nor have customers there. Nonetheless, it is worth noting this requirement for individuals or entities who are subject to these regulations.
- Is there demand for OCSP in Dovecot?
https://github.com/mjhas/dovecot/issues/44 (First GitHub Google hit for “dovecot ocsp”) https://serverfault.com/questions/830434/do-postfix-and-dovecot-support-ocsp... https://dovecot.org/pipermail/dovecot/2018-October/113368.html https://www.dovecot.org/list/dovecot/2016-March/103395.html
- Summary
By implementing a simple OCSP solution, Dovecot could effectively solve this predicament without any drawbacks for its users. The focus here is on simplicity. It is unnecessary to employ a comprehensive OCSP resolver/responder like the one used in Nginx; rather, it would suffice to allow the definition of a simple file path containing the OCSP response alongside the certificate (honoring TLS SNI).
Please kindly consider my motion.
While I am always for security improvements, the utility of this unclear. I will ABSTAIN from this poll.
Presently, any system administrator who intends to issue must-staple certificates, faces the dilemma to either chose to
a) Refrain from issuing must-staple certificates at all, resulting in the loss of a valuable security feature. b) Issue must-staple certificates without an OCSP response in Dovecot, thereby breaking the TLS RFC (and “hope for the best” on the client side…).
or c) use must-staple on a host-by-host basis
Question) Do any popular email user agents validate an OCSP response if stapled? (gut feeling is MAYBE/NO)
Question) Do any query an OCSP server if the OCSP response is not stapled? (gut feeling is NO)
Observation) The industry seems poised to move back to (a reincarnation of) CRL's. https://obj.umiacs.umd.edu/papers_for_stories/crlite_oakland17.pdf
Question) Has OCSP really got a future? (gut feeling - a few years at least)
p.s. this seems like a Run-Before-You-Walk situation. I've been pushing to get Dovecot to check the client certificate presented to the LMTP server, with little apparent success. I think it's better to get the fundamentals right first. But it's certainly possible to both :)
-- This email has been checked for viruses by AVG antivirus software. www.avg.com
Hello Sean,
Thank you for your fast reply.
or c) use must-staple on a host-by-host basis
I am not exactly sure what hosts have to do with this. The must-staple extension is a (cryptographically ensured) flag that is 'ingrained' into a certificate. It tells a client to only accept the certificate if a valid and recent OCSP response was stapled along with the certificate.
Do any popular email user agents validate an OCSP response if stapled?
While I acknowledge that present MUA support for "must-staple" is underwhelming, it is also completely irrelevant for the argument I am making. The security level of one's server should not be determined by Thunderbird/Outlook (or in extension Mozilla/Microsoft).
Counter question: Why should John Doe connecting over HTTPS, doing - let's say - sensitive banking applications, be deprived of the security advantages of the 'must-staple' extension? Just because Thunderbird or Outlook does not support it? What does John Doe using Chrome have to do with Thunderbird/Outlook?
I am not trying to be obnoxious here but this point is crucial do understand: Lack of OCSP in Dovecot has security implications for the entirety of the server - not only for IMAP or Dovecot. Certificates are shared over multiple Daemons across different Protocols.
This is the entire point I am trying to make here. System Administrators currently only have the choice to either disable must-staple or break the TLS RFC for IMAP and "hope for the best" for IMAP clients. A completely unnecessary situation that could easily be resolved if Dovecot could provide basic(!) OCSP support.
Do any query an OCSP server if the OCSP response is not stapled?
I am again not sure if I understand the question correctly. The purpose of must-staple is that an "unstapled" certificate gets rejected by default. Everything else would render must-staple meaningless.
Observation) The industry seems poised to move back to (a reincarnation of) CRL's.
I'd argue that a single scientific paper (from admittedly reputable universities) is hardly an industry poised to move back. In all honesty, this looks like an attempt to clout OCSP with undeserved doubts - for reasons unknown to me. But I think it's fair to say that Dovecot users finally deserve what is common practice in Nginx/HTTP and Exim/SMTP since ~8 Years(!) already.
Has OCSP really got a future?
Reading this makes me feel like living in a parallel universe. Most certainly. In the HTTP world, this is not even up for debate but called 'best practice'.
If my response came across as confrontational I apologize in advance. It is not my intention to seek contention. I only want to find solutions. But after Years of waiting for this feature and reading arguments that mostly contradict all of my real life experiences, I feel compelled to speak as clearly and concisely as possible.
Best regards novoMedia
On 11/07/2023 5:33 pm, novoMedia via dovecot wrote:
I am not exactly sure what hosts have to do with this. The must-staple extension is a (cryptographically ensured) flag that is 'ingrained' into a certificate. It tells a client to only accept the certificate if a valid and recent OCSP response was stapled along with the certificate.
It wasn't clear that you were talking about using the same certificate across many services on a single host. That's fair but I will point out there is nothing stopping you from using several certificates for the same server. One with the extension and one without. Every application on that server can have a certificate tailored to it's own needs if need be. And with free CA's available, it's actually pretty easy. It's really an argument about manageability. It would be _nice_ to be able to use one certificate for all services on a server. And so it would be _nice_ if Dovecot supported OCSP stapling.
Counter question: Why should John Doe connecting over HTTPS, doing - let's say - sensitive banking applications, be deprived of the security advantages of the 'must-staple' extension? Just because Thunderbird or Outlook does not support it? What does John Doe using Chrome have to do with Thunderbird/Outlook? Seems like a confused argument. Why would John Doe's bank and John Doe's email provider be forced to use the same certificate for their respective servers. I'd argue that a single scientific paper (from admittedly reputable universities) is hardly an industry poised to move back. In all honesty, this looks like an attempt to clout OCSP with undeserved doubts - for reasons unknown to me. But I think it's fair to say that Dovecot users finally deserve what is common practice in Nginx/HTTP and Exim/SMTP since ~8 Years(!) already.
I've go no axe to grind here, just calling it as I see it.. FireFox and Chrome have already moved on this. Both browsers already support a CRL 2.0 type mechanism and have stated they intend to stop checking OCSP. I don't know what the other browsers are doing, but this seems to be the direction things are heading in. If the web doesn't want OCSP any more, will it stay around. I dunno.
If my response came across as confrontational I apologize in advance. It is not my intention to seek contention. I only want to find solutions. But after Years of waiting for this feature and reading arguments that mostly contradict all of my real life experiences, I feel compelled to speak as clearly and concisely as possible.
No confrontation here. I support you with your quest. It's just not something I think I would ever use or need - so I didn't vote for it. I also didn't vote against it - it would be nice to have,.
Sean.
-- This email has been checked for viruses by AVG antivirus software. www.avg.com
On 11/07/2023 6:18 pm, Sean Gallagher wrote:
No confrontation here. I support you with your quest. It's just not something I think I would ever use or need - so I didn't vote for it. I also didn't vote against it - it would be nice to have,.
I should clarify. When I say "vote" I mean figuratively. I have no say over the development of Dovecot. I'm just a user like almost everyone else on this list.
-- This email has been checked for viruses by AVG antivirus software. www.avg.com
Sean Gallagher wrote:
I am not exactly sure what hosts have to do with this. The must-staple extension is a (cryptographically ensured) flag that is 'ingrained' into a certificate. It tells a client to only accept the certificate if a valid and recent OCSP response was stapled along with the certificate. It wasn't clear that you were talking about using the same certificate across many services on a single host. That's fair but I will point out
On 11/07/2023 5:33 pm, novoMedia via dovecot wrote: there is nothing stopping you from using several certificates for the same server. One with the extension and one without. Every application on that server can have a certificate tailored to it's own needs if need be. And with free CA's available, it's actually pretty easy. It's really an argument about manageability. It would be _nice_ to be able to use one certificate for all services on a server. And so it would be _nice_ if Dovecot supported OCSP stapling.
Right that would be a possibility. But I don't see the security advantage of must-staple if there's a 'sister-certificate' without must-staple right beside it. In case of an intrusion, the attacker would just grab the non-must-staple one. Before I'd do that, I would just plainly disable must-staple and keep OCSP optional. But yes, technically you are right.
Counter question: Why should John Doe connecting over HTTPS, doing - let's say - sensitive banking applications, be deprived of the security advantages of the 'must-staple' extension? Just because Thunderbird or Outlook does not support it? What does John Doe using Chrome have to do with Thunderbird/Outlook? Seems like a confused argument. Why would John Doe's bank and John Doe's email provider be forced to use the same certificate for their respective servers.
The banking example was just made-up. It wasn't meant to be taken literally but only to get a point across.
I'd argue that a single scientific paper (from admittedly reputable universities) is hardly an industry poised to move back. In all honesty, this looks like an attempt to clout OCSP with undeserved doubts - for reasons unknown to me. But I think it's fair to say that Dovecot users finally deserve what is common practice in Nginx/HTTP and Exim/SMTP since ~8 Years(!) already. I've go no axe to grind here, just calling it as I see it.. FireFox and Chrome have already moved on this. Both browsers already support a CRL 2.0 type mechanism and have stated they intend to stop checking OCSP. I don't know what the other browsers are doing, but this seems to be the direction things are heading in. If the web doesn't want OCSP any more, will it stay around. I dunno. If my response came across as confrontational I apologize in advance. It is not my intention to seek contention. I only want to find solutions. But after Years of waiting for this feature and reading arguments that mostly contradict all of my real life experiences, I feel compelled to speak as clearly and concisely as possible. No confrontation here. I support you with your quest. It's just not something I think I would ever use or need - so I didn't vote for it. I also didn't vote against it - it would be nice to have,. Sean.
No worries Sean, thank you for your participation in this conversation. I am sure it made my standpoint to future participants more clear. Thanks for that.
Best regards, novoMedia
On 7/10/23 21:47, Sean Gallagher wrote:
While I am always for security improvements, the utility of this unclear. I will ABSTAIN from this poll.
Presently, any system administrator who intends to issue must-staple certificates, faces the dilemma to either chose to
a) Refrain from issuing must-staple certificates at all, resulting in the loss of a valuable security feature. b) Issue must-staple certificates without an OCSP response in Dovecot, thereby breaking the TLS RFC (and “hope for the best” on the client side…).
or c) use must-staple on a host-by-host basis
I am not using must-staple ... but I have haproxy stapling OCSP for any tcp/443 or udp/443 connection. I do not have any other endpoint (like submission, smtp, imap, etc) doing stapling, but I would like that to be possible.
For those who don't know about it ... OCSP stapling makes the TLS handshake faster because the client does not need to make a separate outgoing OCSP request (which may be quite slow) to verify that the server certificate hasn't been revoked. The stapled OCSP response is signed by the CA and has a very short lifetime, so forging a response is difficult.
Question) Do any popular email user agents validate an OCSP response if stapled? (gut feeling is MAYBE/NO)
Question) Do any query an OCSP server if the OCSP response is not stapled? (gut feeling is NO)
Browsers definitely do validate OCSP and make a query if the OCSP response isn't stapled. I have no idea whether that's done in the browser or the TLS library. If it's in the TLS library (openssl being the most prevalent example), then it is at least POSSIBLE for dovecot and other server software to do it.
Question) Has OCSP really got a future? (gut feeling - a few years at least)
OCSP is something I have been hearing about for quite a while. I think it's probably going to stick around.
Thanks, Shawn
participants (4)
-
help＠novo.media
-
novoMedia
-
Sean Gallagher
-
Shawn Heisey