OCSP Stapling for TLS/SSL

[whiskerpickles]

It's not mission critical but it would be nice to see support for this NIST/HIPAA recommended protocol.

[d19dotca]

@whiskerpickles Good idea. Looks like it's possible already too for Cloudron to support (i.e. supported by Let's Encrypt): https://letsencrypt.org/docs/integration-guide/#implement-ocsp-stapling

By turning on OCSP Stapling, you can improve the performance of your website, provide better privacy protections for your users, and help Let’s Encrypt efficiently serve as many people as possible.

[girish]

Reading up on this... One thing led to another and I ended up implementing it Should be in next release. Currently, it's enabled for all new certs. I will let it sit for a while to check if causes any issues with various browsers.

Firefox now shows that the cert has OCSP must-staple:

The connection also has the staple information:

Also, verified with openssl s_client -connect hostname:443 -status:

======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = US, O = Let's Encrypt, CN = R3
    Produced At: Apr 16 19:26:00 2021 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 48DAC9A0FB2BD32D4FF0DE68D2F567B735F9B3C4
      Issuer Key Hash: 142EB317B75856CBAE500940E61FAF9D8B14C2C6
      Serial Number: 035EAD5077C8953B8AC544660B927A2A37B5
    Cert Status: good
    This Update: Apr 16 19:00:00 2021 GMT
    Next Update: Apr 23 19:00:00 2021 GMT

    Signature Algorithm: sha256WithRSAEncryption
         5f:2f:9d:67:41:26:c8:9c:53:fd:01:ab:ce:47:83:87:fe:06:
         97:7c:4e:16:90:4d:1d:32:6b:8d:9d:19:c8:40:7f:27:5a:d6:
         82:8d:a2:af:f2:19:60:7c:d0:d8:90:39:bc:60:cd:9b:b2:64:
         fb:e2:1c:b1:e5:1c:22:91:a4:75:23:09:cd:85:b4:b4:52:d2:
         46:cf:55:d8:f2:a8:57:d3:27:61:a2:99:61:76:d1:a3:05:ae:
         4a:d5:3d:c8:97:fe:14:e2:b7:cd:1c:98:2c:c1:dd:1b:78:02:
         87:8f:de:da:8d:d5:6b:33:d4:d3:75:a5:ba:6f:1d:54:ee:42:
         81:b7:ed:e4:d8:bf:23:c6:b7:30:06:ea:11:c2:88:66:f4:28:
         a7:43:f2:b8:9c:9f:9e:13:82:07:fb:b4:8e:7f:e7:19:84:8d:
         13:2f:f9:9f:9b:f8:1a:7f:04:f2:5c:17:1c:fa:c4:96:28:33:
         43:de:ee:c6:68:de:60:49:ea:b2:ad:57:30:fe:df:87:4c:83:
         c2:a2:07:e4:8b:b9:16:9f:79:61:4e:8f:5c:91:a7:6e:2f:17:
         ec:93:29:f5:57:96:e3:be:e5:90:80:db:64:dd:2a:22:7a:b0:
         9d:3e:95:87:51:96:de:4f:6e:ac:63:ed:55:a4:f2:e0:45:ca:
         90:51:50:d1
======================================

[girish]

The change is pretty small, if anyone is interested - https://git.cloudron.io/cloudron/box/-/commit/4d919127a73717d43f14e0d90ba2dc46785c16c8 .

[girish]

Grr, I knew it was too good to be such a simple change. I found that the first visit on firefox (unlike chrome which ignores must-staple) always fails. Investigating, it turns out, nginx does not fetch OCSP responses on reload or restart - https://trac.nginx.org/nginx/ticket/812 . So, one has to prime the OCSP cache using curl requests. Alternately, one can use openssl ocsp -noverify -no_nonce and then ssl_stapling_file. Both approaches won't work if the OCSP servers are down and then we have to have some retry logic. Also, the cache is per nginx worker, so I have no clue how many times one has to call curl. The ssl_stapling_file approach requires some refresh logic as well

So, I have changed the code to not enable must-staple in the certificate request. It minimizes the security benefits but we have to wait on nginx to make this properly work.

[whiskerpickles]

That's great work @girish - it's not often you step out for the day and return to see your post "solved". I was going to include that it should be a simple nginx config thing but I know better. And it's unfortunate the request caching is a nightmare to enforce "must-staple".

Regardless, the win here is that you have it enabled. That should now be reflected in test reults from Mozilla Observatory (extended to Qualys SSL Labs & ImmuniWeb). Thanks for putting in the grunts on this one.

[girish]

I got some mails about this last week and some people wondered what the situation with Cloudron is. I thought I will update it here.

Let's Encrypt is discontinuing support for OCSP altogether in the coming weeks - https://letsencrypt.org/2024/12/05/ending-ocsp/ . A brief summary is that OCSP and CRL are two methods a browser can use to check the validity of an already issued certificate. OCSP involves querying a URL and CRL involves downloading a database of revoked certificate serial numbers. OCSP has a big privacy issue - when you visit example.com , the OCSP check can make the CA log the domain + IP (willing or forced by law). The "OCSP Must Staple" was a way to circumvent this but this hasn't gained much traction .

As to what this means to Cloudron... nothing really. We did not enable OCSP Must Staple in the first place because nginx required some manual priming and downtime to make it work reliably (a point noted in the above URL).