Here's a summary of the themes from the Hacker News discussion:
The Downfall of OCSP and the Rise of Shorter Certificate Lifetimes
A central theme is the consensus that OCSP (Online Certificate Status Protocol) is being deprecated or is effectively dead. This is largely attributed to its inherent design flaws, primarily its susceptibility to Man-in-the-Middle attacks if not properly implemented, its potential to overload Certificate Authorities (CAs), and its privacy implications.
"GauntletWizard: Ocsp has always represented a terrible design. If clients require it, then it becomes just a override on the not after date included in the certificate, that requires online access to the cert server. If it is not required, then it is useless, because blocking the ocsp responses is well within the capabilities of any man in the middle attack, and makes the servers themselves DDOS attack targets."
The move towards significantly shorter certificate lifetimes (e.g., 90 days, with a future reduction to 47 days) is seen as a direct consequence of OCSP's shortcomings, effectively making its constant need for real-time status checks less critical.
"tptacek: Well, OCSP is dead, so the real argument is over how low certificate lifetimes will be, not whether or not we might make a go of OCSP."
OCSP Stapling as a Compromise and its Limitations
OCSP stapling was discussed as a significant improvement over standard OCSP, aiming to mitigate privacy concerns and reduce the reliance on direct OCSP queries. In this model, the CA's OCSP response is "stapled" to the certificate by the web server itself.
"GauntletWizard: The alternative to the privacy nightmare is ocsp stapling, which has the first problem once again - it adds complexity to the protocol just to add an override of the not after attribute, when the not after attribute could be updated just as easily with the original protocol, reissuing the certificate."
However, even stapling was not universally lauded, with some viewing it as an added complexity. Moreover, its widespread adoption was lacking, making it difficult for browsers to enforce.
"ekr____: The problem with requiring OCSP stapling is that it's not practically enforceable without breakage. The underlying dynamics of any change to the Web ecosystem is that it has to be incrementally deployable, in the sense that when element A changes it doesn't experience breakage with the existing ecosystem. At present, approximately no Web servers do OCSP stapling, so any browser which requires it will just not work."
The Role of Certificate Lifetimes in Security
The discussion highlights a significant shift towards shorter certificate lifetimes as a primary mechanism for revocation and security. This approach aims to reduce the window of opportunity for compromised certificates to remain valid.
"jerohd: OCSP stapling was a good solution in the age of certificates that were valid for 10 years (which was the case for basic HTTPS certificates back in 2011 when OCSP stapling was introduced). In the age of 90 day certificates (to be reduced to a maximum of 47 days in a few years), it's not quite as necessary any more, but I don't think OCSP stapling is that problematic a solution."
"gerdesj: SSL certs (and I refuse to call them TLS) will soon have a required lifetime of forty something days. OCSP and the rest becomes moot."
The feasibility and implications of these shorter lifetimes were debated, particularly concerning the increased load on Certificate Transparency (CT) logs.
"tgsovlerkhgsel: Certificate volume in Certificate Transparency would increase a lot, adding load to the logs and making it even harder to follow CT."
Certificate Transparency (CT) and Scalability Concerns
The increasing issuance of certificates, especially with shorter lifetimes, raises concerns about the scalability of Certificate Transparency logs. Processing these logs locally becomes a significant challenge.
"tgsovlerkhgsel: Following CT (without relying on a third party service) right now is a scale problem, and increasing scale by at least another order of magnitude will make it worse. I was trying to process CT logs locally. I gave up when I realized that I'd be looking at over a week even if I optimized my software to the point that it could process the data at 1 Gbps (and the logs were providing the data at that rate), and that was a while ago."
There's a sentiment that the current architecture might need to evolve to handle this increased volume.
"charcircuit: You can delete old logs or come up with a way to download the same thing with less disk space. Even if the current architecture does not scale we can always change it."
Browser-Centric Revocation Mechanisms (CRLite and CRLSets)
Browsers are increasingly adopting their own centralized revocation checking mechanisms, such as Firefox's CRLite and Chrome's CRLSets. These systems aim to provide a more efficient and scalable approach to certificate revocation compared to OCSP and traditional CRLs.
"sugarpimpdorsey: This will not impact Chrome in any meaningful way because - in typical Google fashion - they invented their own bullshit called CRLSets that does not perform OCSP or CRL checks in any way, rather periodically downloads a preened blacklist from Google which it then uses to screen certificates."
"ekr____: By contrast, with Firefox's introduction of CRLite, all the major browsers now have some central revocation system, which works today as opposed to years from now and doesn't require any change to the servers."
There's a perceived difference in how these systems operate, with Chrome's CRLets being described as a pre-cleaned blacklist rather than a direct revocation check.
"ekr____: Sort of. Firefox doesn't filter the list of revoked certificates the way Chrome does."
The Evolving Trust Model and CA Centralization Concerns
The discussion touches upon the broader implications of how trust is managed on the web. Some argue that the current system, heavily reliant on CAs and browser vendors, is overly centralized and offers diminishing returns in security, especially as domain validation becomes more prevalent.
"ocdtrekkie: The entire existence of CAs is a pointless and mystical venture to ensure centralized control of the Internet that, since now entirely domain-validated, provides absolutely no security benefits over DNS. If your domain register/name server provider is compromised, CAs are already a lost cause."
There's a concern that browser vendors exert undue influence over web standards and security practices.
"ocdtrekkie: Three browser companies on the west coast of the US effectively control all decisionmaking for WebPKI. The entire membership of the CA/B is what, a few dozen? Mostly companies which have no reason to exist except serving math equations for rent."
Counterarguments are made that the DNS infrastructure itself is also centralized, and browser vendors' control is a natural consequence of their role in providing the browsing experience.
"tptacek: Browser vendors exert control by dint of controlling the browsers themselves, and are in the picture regardless of the trust system used for TLS. The question is, which is more centralized: the current WebPKI, which you say is also completely dependent on the DNS but involves more companies, or the DNS itself, which is axiomatically fewer companies?"
Privacy Trade-offs in Web Browsing
A recurring point of debate is the privacy implications of various web security mechanisms. While OCSP was criticized for privacy concerns, the practice of querying DNS servers was also brought up as a similar, albeit accepted, privacy leak.
"lol768: The privacy concerns could have been solved through adoption of Must-Staple, and you could then operate the OCSP responders purely for web-servers and folks doing research. And let's not pretend users aren't already sending all the hostnames they are visiting to their selected DNS server. Why is that somehow okay, but OCSP not?"
"woodruffw: I think the argument isn’t that it’s okay, but that one bad thing doesn’t mean we should do two bad things. Just because my DNS provider can see my domain requests doesn’t mean I also want arbitrary CAs on the Internet to also see them."