Pomerium: internal/httputil: support OCSP stapling

[yegle]

Is your feature request related to a problem? Please describe.

I'm using Pomerium as a reverse proxy to my DNS over HTTPS server. Depending on the client implementation, the client trying to check certificate status over OCSP may result in deadlock (this is mentioned in the RFC https://tools.ietf.org/html/rfc8484#section-10).

OCSP stapling is considered the solution here.

Describe the solution you'd like

Pomerium should add OCSP stapling response by default.

Describe alternatives you've considered

Use Nginx between user and Pomerium as reverse proxy.

Explain any additional use-cases

I believe this is also good for user privacy. OCSP must respond in plaintext HTTP and thus ISP can learn what website you are accessing. This is mentioned in Chromium's Security FAQ: https://dev.chromium.org/Home/chromium-security/security-faq#TOC-What-s-the-story-with-certificate-revocation-

Additional context

https://github.com/mholt/certmagic/blob/master/ocsp.go is an existing implementation of OCSP stapling which relies on golang.org/x/crypto/ocsp.

[desimone]

This is very much still on my mind and recently came up in the recent Kubernetes Security Review.pdf.

@yegle is this something you would be interesting in adding?

[yegle]

Oh sorry, didn't notice there's a question to me.

Yes I'm interested in implementing this feature. Let me take this bug.

[desimone]

Awesome, thanks @yegle !

[yegle]

I have an implementation in https://github.com/yegle/pomerium/tree/ocsp that actually works, feedback welcome.

Note the approach is very naive and I need to read the RFC to:

1. Understand the best timing of requesting a new staple
2. Understand the ResponseStatus and how to handle each properly (https://godoc.org/golang.org/x/crypto/ocsp#ResponseStatus)

Open questions:

1. Should we persist the staple on disk? Caddy does it, but Pomerium doesn't persist anything to disk AFAIKT.
2. Best way to unit test it? I'm thinking about running a fake OCSP server in-memory, serve some random bytes, and expect an SSL connection to get those random bytes. But I think the real logic that requires unit testing is: 1) gracefully handle OCSP server downtime. 2) exponential retry on some ResponseStatus. I'm out of my depth here, my testing experience in Go is limited :-(
3. Should OCSP stapling be enabled by default? I think the answer is yes. The alternative is to have a configurable option so that user can disable it when the OCSP server of their cert is down.

[desimone]

@yegle this is a great start, thank you!

I need to be better informed on the subject before weighing in but I have a few hot-takes that hopefully help.

1. Persistence / state is a tricky subject in general for Pomerium but I think saving to disk is a reasonable path forward.
2. I think spinning up a test TLS server makes sense. Do you have a sense for what other implementors do to gracefully handle downtime?
3. Not sure yet. I need to better understand the tradeoffs but I'm open to it.

Additional context (and reading for me!)

• Ryan Sleevi's unofficial Guide to OCSP Stapling
• OCSP Stapling: How CloudFlare Just Made SSL 30% Faster
• High-reliability OCSP stapling and why it matters
• No, don't enable revocation checking
• Revocation still doesn't work
• OCSP Stapling Robustness in Apache and nginx

[desimone]

Hi @yegle just wanted to check in on this to make sure I'm holding you up in anyway. Cheers!

[yegle]

Hi sorry for the delay, I'm still on this and has being keeping my patch in sync with master.