On 28/10/2015 21:58, Walter H. wrote: > On 28.10.2015 18:34, Jakob Bohm wrote: >> On 28/10/2015 17:36, Walter H. wrote: >>> On 28.10.2015 16:44, Jakob Bohm wrote: >>>> On 27/10/2015 21:21, Walter H. wrote: >>>>> On 26.10.2015 21:42, rosect190 at yahoo.com >>>>> <mailto:rosect190 at yahoo.com> wrote: >>>>>> Hi, I need some help on this call. >>>>>> >>>>>> I am building an OCSP client following guide in openssl and >>>>>> compile the code in Cygwin environment. My openssl version is >>>>>> 1.0.1h. >>>>>> >>>>>> With HTTP based OCSP, the code works fine. But, with HTTPs, the >>>>>> code gets stuck at the call to OCSP_sendreq_bio(). Further >>>>>> debugging shows that OCSP_sendreq_nbio() does not return. >>>>>> >>>>>> Did I need to something extra to deal with HTTPs based connection? >>>>>> >>>>> OCSP must not be https ... >>>>> the same with CRL download ... >>>> Really, I thought that was only a recent cop out rule to >>>> cater to clients with inferior SSL libraries that can't >>>> handle the recursion. >>> both OCSP and CRLs are signed, and this is enough for validation, >>> there is no need of SSL; >> How about privacy. Especially OCSP queries are very >> revealing, as they indicate the party sending the query >> is using that particular 3rd party certificate at that >> very moment. >> > what would someone really know, if he would catch the OCSP request of > the attached certificate? > privacy is not really the problem ... > She (Eve) would know that the requesting party Alice was talking to Bob at the very moment she sent Trent the OCSP *request* for Bob's certificate. And by just listening to that one address (the unencrypted requests being sent to OCSP responder Trent), Eve would essentially get the Internet equivalent of having (almost complete) real time copies of everybody's phone bill/call records. Who was calling who at what time. That's very valuable private information which Eve could otherwise get only by monitoring traffic at thousands of Internet routers. And as an added bonus, she gets to see when Alice is reading e-mails signed by Bob (because Alice's e-mail program would make an OCSP request when it checks the signature as she opens the mail that is already stored behind Alice's high strength firewall. With https-encrypted OCSP transactions, all she can see is that Alice is doing *something* that involves checking *some* *unknown* certificate issued by Trent. Only Alice and Trent would know which one. With https-encrypted CRL requests, Eve can see much less, as all she will know is the first time in each CRL-period Alice is checking some Trent-issued certificate, and perhaps even less if Trent has other popular data on that https server or Alice's computer downloads the CRLs for trusted CAs on a schedule regardless if Alice is even in the building. If Trent is a provider of Antivirus, a popular video download site or anything else that responds to millions of other https downloads unrelated to interesting activity, putting the CRLs on that same server will make even this information near impossible to observe. CRLs over http reveals the CRL access information with more accuracy as it cannot get hidden in a flux of other requests. On the authenticity side, using https provides a direct proof that non only is the validity information not stale (past its end date), but it is the most recent the server had at the time of the request, not slightly older information provided by an active attacker who wants to use a compromised certificate a little bit longer than the time it takes the CA to revoke it. For OCSP that could alternatively be achieved without the other benefits by using the nonce option in the OCSP request, but this alternative would not solve the other problems and wouldn't work for CRLs. > there is one thing that is problematic - especially if the CA is > somewhat stupid: > using one responder certificate for all OCSP responses for any end > entity certificate ... > (the specific RFC says, that it is discouraged to do so) This is not about the OCSP-response signing certificate (or the CRL signing certificate). Those are unavoidable and have already established practices for avoiding the chicken/egg problem of revocation checking. It is about the https SSL certificate of the web server that provides access to the OCSP-response service and/or the CRL download service. > > faking the OCSP response by 3rd party to pretend a good certificate > even it is bad, > is quite a little bit difficult, but easy if the CA is stupid ... > > so it is a bad idea having a OCSP Responder certificate > that was not signed by the CA that has signed the end entitiy certificate > >> Only if the SSL certificate for the OCSP or CRL server >> references itself as a way to check for revocation of >> *that* certificate (larger multi-step loops could also >> be built). >> >> However with careful choice/generation of certificates >> for the OCSP/CRL server, this can be easily avoided. >> > easily - are you sure? > > example: > > (a) you want to check cert 1 that was signed by the CAs cert A > (b) the server uses certificate 2 that was signed by the CAs cert B > > with https this would be the following: > to access the CRL or OCSP of cert 1, you need to validate cert 2, > that itself is needed to access the CRL or OCSP of cert 2, too? > As I said it involves recursion and the trick is to terminate that recursion before it gets infinitely deep. One obvious way is that at some (not too deep) level of recursion, the certificate to be checked (whose private key is that of a trusted CA-owned machine anyway) doesn't specify an OCSP responder or a https CRL URL, just like the rules that already govern the revocation checking extensions in OCSP- signing and CRL-signing certificates. And the checking of that shared deep-level CA-owned certificate is a lot less revealing of Alice's activity than the checking of a specific certificate related to Alice's current non-protocol activity. Another obvious way would be for that final https server to do OCSP-stapling, thus terminating the recursion for any relying party (Alice) whose client software knows how to parse and validate OCSP-stapled validity proofs. > do you really think is makes any sense, using https for CRLs download > or OCSP? > See my longer response above about the specific security dangers inherent in using plain http for OCSP and (to a lesser degree) CRLs. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151029/f1cdf55d/attachment.html>
