SSL OCSP allows for man in the middle attacks ?

rdan · Aug 24, 2015

I requested OCSP support for my site on Sucuri, and their support said:

Hi, OCSP allows for man in the middle attacks so we do not have it enabled for security reasons.
Click to expand...

Is this true?
Any evidence? :/

eva2000 · Aug 24, 2015

not quite sure but from Certificate revocation: Why browsers remain affected by Heartbleed | Netcraft

Is revocation checking useful for certificates potentially compromised by Heartbleed?
As explained by Adam Langley, online revocation checking can easily be blocked if the compromised certificate is being used in a man-in-the-middle attack. An attacker able to intercept traffic to the targeted website will likely also be able to block OCSP requests. If the victim is using a browser which does not hard-fail (which is the default setting of all major browsers) when an OCSP response isn't received, the attacker will be able to use a revoked certificate as normal.

However, the same logic does not apply to CRLs: if the CRL was downloaded earlier when on a trusted network, a revoked certificate used in a man-in-the-middle attack will not be trusted. This requires the certificate to have been revoked before the CRL was downloaded; however, many CRLs can be cached for a significant length of time (up to 10 days in the Baseline Requirements). Although, if a new CRL is needed, its download can be blocked just as effectively as OCSP's can be. When CRLs are used, an attacker cannot rely on the certificate passing validation: a subset of users, those with cached CRLs, will be prevented from continuing on the attacker's site. The same logic also applies to Google's CRLSets, including the ability to block updates.

As such, despite the difficulties of revocation checking in the MITM scenario, it is still critical for site owners to revoke certificates. If the certificate is revoked, an attackers job is made that much more difficult: he must chose sites with certificates issued without a CRL distribution point (which is permissible under the Baseline Requirements) or that are not covered by Google's CRLSets, and his victims must be using a browser that checks neither. Certificates that are not revoked are unlikely to ever be included in more effective revocation methods such as CRLSets.

Should I enable revocation checking in Chrome?
Whilst OCSP is easily blocked in man-in-the-middle attacks, if revocation checking is enabled, Chrome (on both Windows and Linux) will check CRLs for certificates that do not support OCSP. It is likely that you will have cached CRLs for websites you have visited recently — if you move onto an untrusted network, you will be protected by the CRLs that were downloaded earlier. Over 4% of currently valid certificates are only revocable by CRL, including login.skype.com. Unfortunately, for the majority of sites where OCSP is available CRLs will not be downloaded, any OCSP requests made can be blocked, and the attacker can continue as if the certificate is not revoked.

Perfect OCSP checks: A chicken and egg problem
By default, all browsers take the "soft-fail" approach to OCSP checks. A revoked certificate will be regarded as valid if the OCSP request fails. While this sounds like unsafe behaviour, browser vendors are reluctant to force a hard-fail approach because of the problems it can cause. For example, paid-for internet connections, such as WiFi hotspots or hotel room connections, that use captive portals are one of the major chicken-and-egg scenarios. Before a user can access the internet, he must visit a secure payment page, but this would fail because the OCSP responder used by the site's certificate cannot be reached until after he has paid. There are methods to resolve this problem, including OCSP stapling and less restrictive blocking; however, such solutions are unlikely to adopted quickly.

Firefox can be forced to use a hard-fail approach to OCSP checking, but this setting is not enabled by default.
It is critical that OCSP responders have 100% uptime, as any outage whatsoever could provide a window of opportunity to misuse compromised revoked certificates. Netcraft publishes a list of OCSP responder sites ordered by failures over the past day. Partly due to the reliability concerns, the Mozilla Foundation suggests that there is some way to go before a hard-fail approach can be enabled by default.

Despite the drawbacks of soft-fail OCSP checking, there are circumstances in which a soft-fail approach can still be useful. For example, it might be desirable to revoke a domain-validated certificate which had been issued to a deceptive domain name (e.g. paypol.com), or when a domain changes hands. In the absence of any man-in-the-middle attackers, soft-fail OCSP is likely to be effective.
Click to expand...

eva2000 · Aug 24, 2015

Maybe also ask Sucuri for more explanation ? or links to info we can read ?

eva2000 · Aug 24, 2015

oh more info OCSP Best Practices | Qualys Community

rdan · Aug 24, 2015

Hi,

You can read more about the security issues of OCSP here:

Addressing the challenges of TLS, revocation, and OCSP | Fastly

Regards,
Click to expand...

eva2000 · Aug 24, 2015

tricky situation for performance you want OCSP stapling but OCSP response isn't ideal if there's an man in the middle attack

Lastly, the OCSP protocol itself quickly falls apart in the presence of an active man-in-the-middle (MITM) attack in which the adversary is able to modify the OCSP response without breaking the CA signature to tell browsers to “Try again later.”
Click to expand...

still fastly and cloudlfare and many others enable OCSP support

eva2000 · Aug 24, 2015

Might need to look into HPKP - HTTP Public Key Pinning SecurityEngineering/Public Key Pinning - MozillaWiki

Background
Public Key Pinning is a mechanism for sites to specify which certificate authorities have issued valid certs for that site, and for user-agents to reject TLS connections to those sites if the certificate is not issued by a known-good CA. Public key pinning prevents man-in-the-middle attacks due to rogue CAs not on the site's list (see the Diginotar attack which Chrome detected and we did not: Fraudulent *.google.com Certificate | Mozilla Security Blog).

The feature binds a set of hashes public keys to a domain name such that when connecting to a site using TLS the browser ensures that there is an intersection between the public keys in the computed trust chain and the set of fingerprints associated with that domain. This check is done during the certificate verification phase of the connection, before any data is sent or processed by the browser. In particular we are pinning the sha256 digest of the der encoded subject public key info. In order to reduce rejections, Firefox computes all potential trust chains before deciding that are no valid pins.
Click to expand...

Public Key Pinning - Web security | MDN

Log in / Register

Forums

Want to subscribe to topics you're interested in?

SSL OCSP allows for man in the middle attacks ?

rdan Well-Known Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

rdan Well-Known Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

.

Log in / Register

Useful Searches

Want to subscribe to topics you're interested in?

SSL OCSP allows for man in the middle attacks ?

rdan Well-Known Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

rdan Well-Known Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

.