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