celenityy / BadBlock

Cleaning up the internet, one domain at a time.
https://codeberg.org/celenity/BadBlock
GNU General Public License v3.0
17 stars 1 forks source link

[OTHER] Alternative whitelist that doesn't contain OCSP responders to fix blocklist to block them #11

Closed Metrokoto closed 1 month ago

Metrokoto commented 1 month ago

I usually block OCSP responders as they are a security and privacy nightmare, however I recently noticed the Badblock Whitelist is whitelisting all of the endpoints Scott Helme's blacklist is supposed to be blocking.

CRL is less of a privacy nightmare, and between blocking both and having no revocation, I'd take CRL over it any day.

Can you therefore please provide an alternative whitelist file that only whitelists CRL endpoints, and does not whitelist OCSP endpoints?

AdGuard home overrides any block rule with whitelist ones, therefore this is the only way to achieve OCSP blocking.

celenityy commented 1 month ago

I usually block OCSP responders as they are a security and privacy nightmare

Do you mind elaborating on this? What are your concerns here? - I guess a lot of it depends on your browser & use case, and whether they have a proper implementation of OCSP.

For instance - if you use a hardened Firefox user.js like Arkenfox or a config like my Phoenix - CRL is prioritized & always used where possible, OCSP is only used in rare cases as a fallback when CRL is unavailable, and even then - it's set to hard-fail if unavailable, & staple where possible. I would argue this fairly significantly improves security with little to no downside.

The only privacy concern I can think of in that case is exposing your IP address to the OCSP server in rare cases where CRL & OCSP Stapling aren't supported - but realistically, you should be using a VPN or proxy anyways...

I'll have to think of the best way to handle this

Curious to hear your thoughts.

Metrokoto commented 1 month ago

I usually block OCSP responders as they are a security and privacy nightmare

Do you mind elaborating on this? What are your concerns here? - I guess a lot of it depends on your browser & use case, and whether they have a proper implementation of OCSP.

For instance - if you use a hardened Firefox user.js like Arkenfox or my Phoenix - CRL is prioritized & always used where possible, OCSP is only used in rare cases as a fallback when CRL is unavailable, and even then - it's set to hard-fail if unavailable, & staple where possible. I would argue this fairly significantly improves security with little to no downside.

The only privacy concern I can think of in that case is exposing your IP address to the OCSP server in rare cases where CRL & OCSP Stapling aren't supported - but realistically, you should be using a VPN or proxy anyways...

I'll have to think of the best way to handle this

Curious to hear your thoughts.

I use Cromite. Nothing I use can disable OCSP, but additionally, something to note is, a lot of embedded web apps use OCSP, as well as Windows programs too, so my threat model involves just removing that potential entirely, plus a lot of applications I use break using a VPN, so I tend to use a VM where possible with one installed on it, making that untenable too.

If I may add, the simplest way to do it would be to create a separate file and just strip any OCSP entries and allow people to directly download it.

You could call it whitelist-minus-ocsp.txt or something.

celenityy commented 1 month ago

I use Cromite.

Ah. Yeah, AFAIK Chromium browsers don't support OCSP at all out of the box, has to be enabled via policies. I believe Cromite is the same.

Nothing I use can disable OCSP, but additionally, something to note is, a lot of embedded web apps use OCSP, as well as Windows programs too, so my threat model involves just removing that potential entirely, plus a lot of applications I use break using a VPN, so I tend to use a VM where possible with one installed on it, making that untenable too.

This is reasonable & fair enough - I hadn't thought of that. We can't guarantee every embedded web app is using a proper OCSP implementation like I described above (Tbh most probably don't if I had to guess...), and since there's not really a mechanism to disable OCSP in cases like that, sounds fair enough for users to be able to block them if they desire.

If I may add, the simplest way to do it would be to create a separate file and just strip any OCSP entries and allow people to directly download it.

You could call it whitelist-minus-ocsp.txt or something.

Sounds like the best approach here, I'll look into it & see what I can do. Appreciate the feedback!

celenityy commented 1 month ago

I'm currently working on completely reworking the way I build the lists (almost done actually...), so while I've been doing that, I've been trying to consider the best way to handle this.

The biggest problem I'm running into is that some domains appear to be used for both OCSP & CRL. Some also serve other legitimate purposes (ex. Apple's OCSP domain(s) are also used for app notarization, very important for security).

I think what I might do is break down the Whitelist into different individual categories, similar to how BadBlock's blocklists work. I would still build the combined whitelist & recommend users stick to it, but for specific use cases like yours, that would allow you to only add the categories you want to, while not unblocking ex. OCSP/CRL domains. I would still have to figure out though what to do about cases like the Apple example I gave above. Biggest drawback to this is that I feel like I would still have to combine OCSP & CRL domains, so still need to think & probably do more research into this.