2 ms·

Regarding OCSP, off-topic for Apple: Firefox enables OCSP by default. This means that for every TLS connection an OCSP plaintext HTTP request will be made to th

Regarding OCSP, off-topic for Apple: Firefox enables OCSP by default. This means that for every TLS connection an OCSP plaintext HTTP request will be made to the certificate authority that signed the certificate of the website the browser is connecting to. This means that the certificate authority receives very well timestamped information about the exact domains you are visiting if you are using Firefox and don't disable OCSP and the website you're connecting to does not use OCSP stapling (most don't). Note that disabling OCSP will make Firefox unable to get certificate revocation information (maybe it still uses system's revocation store, I'm not sure about that, but it certainly does not use more privacy preserving CRLs).

mananaysiempre 2y ago
For intermediates, Firefox distributes OneCRL[1] based on CCADB[2] data and the Mozilla Root Program’s own trust decisions. For leaf certificates, they announced the CRLite[3,4] experiment a while ago but it’s not clear how far along it is. [1] https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ https://blog.mozilla.org/security/2015/03/03/revoking-interm... [2] https://www.ccadb.org/ https://www.ccadb.org/ [3] https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/ https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a... [4] https://bugzilla.mozilla.org/show_bug.cgi?id=crlite https://bugzilla.mozilla.org/show_bug.cgi?id=crlite
lol768 2y ago
It's a trade-off though, isn't it? Everyone seems upset about OCSP as of late, but the domains being sent in plaintext is not exactly limited to just OCSP - we've had this with SNI and DNS. The advantages of OCSP are that you get a real-time understanding of the status of a certificate and you're not needing to download large CRLs which are stale very quickly. If you set security.OCSP.require appropriately, you don't have any risk of the browser failing open, either. It seems to me like the people who most dislike OCSP are CAs who have to maintain the infrastructure capable of responding to queries. I have really limited sympathy, that should be part of running a CA. The privacy concerns could be solved by mandating OCSP stapling, and you could then operate the OCSP responders purely for web-servers and folks doing research. Unfortunately the ship has sailed with ballot SC63 now, and we are where we are. I don't necessarily agree that OCSP as a concept was unfixable, though.
- jesprenj 2y ago
  > Everyone seems upset about OCSP as of late, but the domains being sent in plaintext is not exactly limited to just OCSP - we've had this with SNI and DNS. My main privacy related concern isn't about domains being sent in plaintext but that they are sent to the CA and they can then theoretically do analytics on this data and profile web users. But maybe this concern doesn't really make sense as we have strict personal-data regulations now.

mananaysiempre 2y ago

For intermediates, Firefox distributes OneCRL[1] based on CCADB[2] data and the Mozilla Root Program’s own trust decisions. For leaf certificates, they announced the CRLite[3,4] experiment a while ago but it’s not clear how far along it is. [1] https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ https://blog.mozilla.org/security/2015/03/03/revoking-interm... [2] https://www.ccadb.org/ https://www.ccadb.org/ [3] https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/ https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a... [4] https://bugzilla.mozilla.org/show_bug.cgi?id=crlite https://bugzilla.mozilla.org/show_bug.cgi?id=crlite

lol768 2y ago

It's a trade-off though, isn't it? Everyone seems upset about OCSP as of late, but the domains being sent in plaintext is not exactly limited to just OCSP - we've had this with SNI and DNS. The advantages of OCSP are that you get a real-time understanding of the status of a certificate and you're not needing to download large CRLs which are stale very quickly. If you set security.OCSP.require appropriately, you don't have any risk of the browser failing open, either. It seems to me like the people who most dislike OCSP are CAs who have to maintain the infrastructure capable of responding to queries. I have really limited sympathy, that should be part of running a CA. The privacy concerns could be solved by mandating OCSP stapling, and you could then operate the OCSP responders purely for web-servers and folks doing research. Unfortunately the ship has sailed with ballot SC63 now, and we are where we are. I don't necessarily agree that OCSP as a concept was unfixable, though.

jesprenj 2y ago
> Everyone seems upset about OCSP as of late, but the domains being sent in plaintext is not exactly limited to just OCSP - we've had this with SNI and DNS. My main privacy related concern isn't about domains being sent in plaintext but that they are sent to the CA and they can then theoretically do analytics on this data and profile web users. But maybe this concern doesn't really make sense as we have strict personal-data regulations now.