Talk:Online Certificate Status Protocol

This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles ??? This article has not yet received a rating on the project's importance scale. This article is supported by WikiProject Computer Security (assessed as Mid-importance). Things you can help WikiProject Computer Security with: edit history watch purge AAlertBot. Please allow some days for processing. More information... Answer question about Same-origin_policy Review importance and quality of existing articles Identify categories related to Computer Security Tag related articles Identify articles for creation (see also: Article requests) Identify articles for improvement Create the Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc. Find editors who have shown interest in this subject and ask them to take a look here.

Article says that Safari supports OCSP but it needs to be enabled in Keychain access. However, I have this disabled in Keychain Access but Safari is still querying OCSP servers. I suspect the settings in Keychain Access are ignored by Safari, and Safari has been using OCSP for some time. -- Ch'marr (talk) 00:34, 31 August 2011 (UTC)[reply]

This piece of information would be very useful for people who are trying to gauge the merits of OCSP. Are OCSP servers more trustworthy than certificate authorities? If they are run by businesses, how do the businesses make money?

OCSP requests always go to the certificate authority that signed the certificate in question - those are the ones with the authority to revoke them

50.174.74.32 (talk) 22:54, 19 August 2014 (UTC)[reply]

Okay, so, here we have some stuff. This is it. We are ready to go and make decisions. But the OCSP protocol is down. So what do we do?

A protocol is a recipe for procedures. A consortium somewhere, out there, has a protocol that they are not satisfied with. And for this reason I am being denied internet service and provided poor, harmful internet service.

My suggestion is that you provide (I'm guessing it's Mozilla Corps?) internet service without the OCSP protocol. Delete the text document describing the OSCP protocol specifications and procedures, and do not use it anymore. Then, go to the little switch thing that provides people internet, and turn __that__ one on.

My name is mmkstarr and my e-mail address (which I can't access at the moment, b/c your OCSP protocol doesn't work at all and so just give up on it) is [email protected] I am interested in hearing how things work, even if the mail doesn't reach me until after I'm not able to receive it. Which is how all mail works.

Another way to contact me is to drop pamphlets from helicopters. You could do that. In fact, I want to be contacted--so try that.

Further, if you simply have no one to __talk__ to, I recommend social media outlets, or objects, or other people.

Signing Off In Hopes Of A Silent Continuation,

mmkstarr

Mmkstarr (talk) 00:16, 20 August 2014 (UTC)[reply]

So have you guys fixed the problem yet? Can I help in any way?

It seems like contacting an OCSP server might have privacy risks. First, it creates a record on-the-wire of every secure site a user connects to. Not only can the OCSP server maintain this log, but eavesdroppers as well. Additionally, the article mentions that it is typically an HTTP connection (not HTTPS).

Questions:

1. Q: What solution eliminates the info leak to the CA?
   A: OCSP stapling with fallback to OCSP disabled.
2. Q: Why is OCSP traffic typically HTTP and not HTTPS? -- the response is signed by the CA so, in theory, you can't really forge them -- the protocol has been partially broken see: http://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatOCSP-PAPER2.pdf
   A: Perhaps to avoid infinite loops where it's necessary to check the revocation status of a cert in order to check the invocation status of the same cert. --Noiseiron (talk) 22:48, 9 May 2016 (UTC)[reply]
3. Q: Can a user select OCSP servers that he/she trusts?
   A: The CA is the only actor that would be expected to have complete knowledge of what certificates it has issued and subsequently revoked and therefore how to respond to an OCSP request - at least until CAs implement blockchain PKI or until Certificate Transparency is ubiquitous. If the CA is not trusted with keeping private the list of sites we access, perhaps we shouldn't trust it with verifying the authenticity of the sites we are attempting to communicate with. --Noiseiron (talk) 22:48, 9 May 2016 (UTC)[reply]
4. Can browsers be configured to connect to OCSP servers only via HTTPS? — Preceding unsigned comment added by 128.112.139.195 (talk) 13:57, 18 October 2011 (UTC)[reply]

Currently refernce no. 5 ( "No, Don't Enable Revocation Checking". 19 April 2014. Retrieved 24 April 2014. https://www.imperialviolet.org/2014/04/19/revchecking.html) seems to have unreliable information. It starts off by referring to the Heartbleed bug as the "Heartbeat" bug. This error is rather more significant than a typo and makes one wonder if they are very well informed about the topic at all. I believe it should be removed as well as any information that was used from the article. 66.225.134.125 (talk) 17:58, 23 December 2015 (UTC)[reply]

Maybe mention DOS attacks using OCSP: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-6304 — Preceding unsigned comment added by FunnyDrink (talk • contribs) 13:49, 5 October 2016 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified 2 external links on Online Certificate Status Protocol. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20100210031759/http://labs.opera.com/news/2006/11/09/ to http://labs.opera.com/news/2006/11/09/
• Added archive https://web.archive.org/web/20131203092421/http://www.processor.com/editorial/article.asp?article=articles%2Fp3113%2F48p13%2F48p13.asp to http://www.processor.com/editorial/article.asp?article=articles%2Fp3113%2F48p13%2F48p13.asp

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:15, 20 January 2018 (UTC)[reply]

This article (and the corresponding Certificate_revocation_list article) could be improved by consideration of non-browser scenarios; including enterprise and Internet-of-things. I am hoping for improvements that could guide decision making, and provide pointers for common methods of solving the issues. My first contribution is dealing with enterprise servers that don't have external internet connectivity, and therefore can't directly contact OCSP responders. Next up, improving the CRL vs. OCSP comparisons, including an explanation of the impact of different common scenarios (browser vs. IoT vs. enterprise). Also want to take into account implementation context for OCSP responders and CDP (CRL distribution point) implementations. — Preceding unsigned comment added by Trsm.mckay (talk • contribs) 19:32, 10 October 2019 (UTC)[reply]