OCSP: URI: http://ocsp.comodoca.com - why not https?


#1

This way, a 3rd party observer near the LE site can see which site using an LE certificate I am visiting.

Unfortunately, it appears that 178.255.83.1 doesn’t listen on port 443 :frowning:

Same (albeit less revealing what I am doing) with the cdp http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.crl

<< openssl s_client -connect crl.comodoca.com:443 -starttls smtp
CONNECTED(00000003)
didn’t found starttls in server response, try anyway…
140629943912104:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:

no peer certificate available

No client certificate CA names sent

SSL handshake has read 0 bytes and written 333 bytes

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE>>
~$


#2

Note that one of the disadvantages of OCSP (i.e., without stapling) is that even with https at least LE can see which sites using LE certificates you are visitng …


What is the business model?
#3

Sure, but at least it is only one institution and not any-one along the route my packets are taking.

Furthermore, I guess I have to have minor trust in LE anyway (e.g. at least to record the certificates it issued in a way with “integrity”)?


#4

it’s partially a chicken and egg issue, if you use https to check ocsp how do you then check the ocsp for the ssl on the ocsp responder itself. It’s the same reason why crl’s are served over http to my understanding.

the real answer in my personal opinion is either long lived certs like a traditional ca with ocsp stapling or even shorter lived than current LE certs (on the 3-7 day scale) without ocsp as the cert would effectively become the ocsp, instead of having an extra signed validation attached that’s short lived and making new standards to mark certs as requiring ocsp to avoid soft fails, just make the cert itself short lived, if you are going the “ocsp must staple” route then a failure to get a new signed document every few days is already a hard fail just the same as not having the certificate itself and that doesn’t need new standards other than automated renewals which is what acme is, why not just have one signed document (the certificate) instead of two, it also mostly fixes revocation, as the crl’s would shrink with the quick fall off of certs that would be expired anyway and even if you don’t use crl’s or ocsp, the window to use a stolen cert shrinks to only a few days, for security you might require more detailed checks if the private/public key will change and only allow super easy renewals of the exact cert other than a newer set of dates, in which case you don’t really need security on the renewal, a new cert is useless to an attacker if it’s tied to a key they don’t have, and so it could be easily set up (like download the url from this field in the cert or with replacing this piece of a url with a standard part of a cert, like the spki hash) and handle re authorizations and revocations out of band from that simplistic new cert fetch system.

sorry about the rant but I’ve heard a lot of talk of ocsp must staple elsewhere and it keeps bugging me why do we need this new system when we could do it with what we have now and then almost all client systems would already support it where many don’t support good revocation checking now.


#5

Hi,

OCSP send you an signed response.
That mean the integrity can be checked without relying on the https protocol.
Also it can be verified that it come from the correct ca.
Only it is possible for MitM to see what site’s you are surfing. => OCSP-Stappling helps here.
On the other hand OCSP Server can use an certificate without OCSP information.
Even if i like to see https here i see no security problem in case of manipulated data:


#6

I believe that some kind of industry norms or policies require the availability of an OCSP responder that does not require HTTPS.

This is a privacy problem, a disadvantage in OCSP itself, and it is definitely preferable for privacy purposes for sites to use stapling. The way the unencrypted query leaks the identity of the visited site is a privacy harm to the user, and there may be entities that would otherwise not have been on-path that are logging those queries, but I don’t believe there’s anything Let’s Encrypt could have done to avoid advertising an unencrypted OCSP responder – I think it’s a requirement imposed on us.

Once the service and client are more mature, we will definitely be looking into ways to encourage more widespread use of stapling. As has been mentioned in another thread, it can be done now if you have the right expertise. :smile:


#7

I’ve posted the Nginx OCSP Stapling config that is functioning for helloworld.letsencrypt.org on this thread:

I hope that’s helpful!


#8

Stapling sounds good, but I guess there is unfortunately no way, we’ll see a majority of sites doing that anytime soon (see e.g. tomcat https://issues.apache.org/bugzilla/show_bug.cgi?id=56148) .

So @mcgurrin 's idea of short-lived certs without ocsp uri is probably worth a thought.

Alternatively, how about

  1. offer both, a http and a https URI ? (at least the chicken & egg only needs to be solved once and then subsequent requests are not exposed to third party observers - an the first request exposing the cert of the ocsp https is not really an “exposure” either IMHO)

  2. as per the recent safe-harbour discussions - would it make sense to offer multiple ocsp URIs to choose from - each one physically residing in a major “jurisdiction region” like NorthAmerica, Europe, Asia, … ?