5 ms·

If anyone is concerned with ocsp activity and verifications being requested all over the web, then oh boy stay away from https. OCSP is a good thing, and the w

If anyone is concerned with ocsp activity and verifications being requested all over the web, then oh boy stay away from https. OCSP is a good thing, and the web - and your signed applications - are better off with it.

feanaro 6y ago
I guess you haven't heard of OCSP stapling? https://en.wikipedia.org/wiki/OCSP_stapling https://en.wikipedia.org/wiki/OCSP_stapling Active OCSP is far from being considered a good thing universally.
brendoelfrendo 6y ago
Yeah, I feel like I'm taking crazy pills; did everyone just not know about OCSP until Apple did it? Spoiler alert, you've probably already used OCSP on the web.
- saagarjha 6y ago
  Most of the people affected by the issue have no idea what OCSP is.
- iso947 6y ago
  Most browsers are stopping ocsp because of the privacy use and the triviality to block it. Did Chrome ever do it? That’s why CT came around. Some background for those unfamiliar. https://scotthelme.co.uk/revocation-is-broken/ https://scotthelme.co.uk/revocation-is-broken/
  - judge2020 6y ago
    Chrome uses its own CRL, which pulls from OCSP https://medium.com/@alexeysamoshkin/how-ssl-certificate-revocation-is-broken-in-practice-af3b63b9cb3 https://medium.com/@alexeysamoshkin/how-ssl-certificate-revo... Although OCSP stapling is used more now IIRC.
    - iso947 6y ago
      Chrome uses CRLset, which generates a cut down CRL when the browser is updated, I don’t see any interaction with OCSP HN doesn’t set OCSP must staple so we’re still a while away from being able to trust it.
- _qulr 6y ago
  Historically speaking, OCSP was invented in a world where almost all DNS requests were also in cleartext. So if an attacker can observe DNS requests, then it's already "game over", and the cleartext of the OCSP request is almost redundant at that point. It's worth noting a couple differences between HTTPS OCSP and Developer ID OCSP. First, with Developer ID, the only DNS request is for ocsp.apple.com, so the DNS request by itself doesn't expose any information about the Mac app being launched, unlike with HTTPS. Second, the caching of Developer ID OCSP responses tends to be much much shorter than for HTTPS. Prior to Thursday's outage, the standard cache length for Developer ID OCSP responses seemed to be 5 minutes. (Apple seems to have raised it to 12 hours now.) In contrast, I just checked the latest response in my OCSP cache, which was for http://ocsp.digicert.com http://ocsp.digicert.com, and its validity is 7 days. So the rate at which Developer ID OCSP requests are made seems to be much higher than for HTTPS, and thus there's greater chance of exposure.
ctz 6y ago
OCSP which fails open combines pointlessness with terrible privacy. It's why Mozilla is moving to CRLite for privacy-friendly revocation.
cblconfederate 6y ago
Everybody knows that when they request a website their action can be logged. The opposite is true about desktop apps

feanaro 6y ago

I guess you haven't heard of OCSP stapling? https://en.wikipedia.org/wiki/OCSP_stapling https://en.wikipedia.org/wiki/OCSP_stapling Active OCSP is far from being considered a good thing universally.

brendoelfrendo 6y ago

Yeah, I feel like I'm taking crazy pills; did everyone just not know about OCSP until Apple did it? Spoiler alert, you've probably already used OCSP on the web.

saagarjha 6y ago
Most of the people affected by the issue have no idea what OCSP is.
iso947 6y ago
Most browsers are stopping ocsp because of the privacy use and the triviality to block it. Did Chrome ever do it? That’s why CT came around. Some background for those unfamiliar. https://scotthelme.co.uk/revocation-is-broken/ https://scotthelme.co.uk/revocation-is-broken/
- judge2020 6y ago
  Chrome uses its own CRL, which pulls from OCSP https://medium.com/@alexeysamoshkin/how-ssl-certificate-revocation-is-broken-in-practice-af3b63b9cb3 https://medium.com/@alexeysamoshkin/how-ssl-certificate-revo... Although OCSP stapling is used more now IIRC.
  - iso947 6y ago
    Chrome uses CRLset, which generates a cut down CRL when the browser is updated, I don’t see any interaction with OCSP HN doesn’t set OCSP must staple so we’re still a while away from being able to trust it.
_qulr 6y ago
Historically speaking, OCSP was invented in a world where almost all DNS requests were also in cleartext. So if an attacker can observe DNS requests, then it's already "game over", and the cleartext of the OCSP request is almost redundant at that point. It's worth noting a couple differences between HTTPS OCSP and Developer ID OCSP. First, with Developer ID, the only DNS request is for ocsp.apple.com, so the DNS request by itself doesn't expose any information about the Mac app being launched, unlike with HTTPS. Second, the caching of Developer ID OCSP responses tends to be much much shorter than for HTTPS. Prior to Thursday's outage, the standard cache length for Developer ID OCSP responses seemed to be 5 minutes. (Apple seems to have raised it to 12 hours now.) In contrast, I just checked the latest response in my OCSP cache, which was for http://ocsp.digicert.com http://ocsp.digicert.com, and its validity is 7 days. So the rate at which Developer ID OCSP requests are made seems to be much higher than for HTTPS, and thus there's greater chance of exposure.

ctz 6y ago

OCSP which fails open combines pointlessness with terrible privacy. It's why Mozilla is moving to CRLite for privacy-friendly revocation.

cblconfederate 6y ago

Everybody knows that when they request a website their action can be logged. The opposite is true about desktop apps