Agreed. I've been blocking HTTP (on port 80) accross my network and I reroute all DNS traffic to a pihole configured to use DoT. At this point in time there is really no reason to let anyone see plain text traffic.
A few things are whitelisted but the handful of things that break aren't necessary anyway.
Genuine question: Do you not have issues with browsers and other security products and OCSP? At work they blocked all internet access and tools that forced use of CRL and OCSP lost their minds. Digicert and other CAs seem to to use port 80 for this. Firefox requires OCSP option to be disabled for me for GitHub to work with pauses.
OCSP has to be port 80 because of the chicken and egg problem.
Specifically, if you use HTTPS for OCSP then now you need OCSP for the certificate for the HTTPS connection you're doing to get OCSP, so you open another HTTPS connection, and you need OCSP for that certificate, and then you open another HTTPS connection and...
But most browsers don't do OCSP by default because realistically you need fail-open behaviour and if you have fail-open behaviour there's no meaningful security benefit so why bother?
OCSP is broken by design. Should turn it off for server applications. Maybe even disable it entirely when compiling openssl if possible.
OCSP is to query random CA web servers when opening a SSL connection to verify if the certificate in use was revoked. It's broken by design because servers simply don't have internet access.
This is what happens when people do random shit in the name of security. It's security theatre, not security engineering.
Microsoft Windows, for example, allows administrators to re-publish external CRLs internally, but this only works for the built-in crypto API. Non-native applications generally won't pick this up, including most command-line tools. Blocking outbound port 80 is a mistake.
A colleague said it best: Certificate private keys are like your password. Tell no one, ever. The public key is like your passport. It's safe to hand to a border officer. CRLs are the lists of passport numbers used by known terrorists wanted by Interpol. Preventing the border officer seeing that list just lets the terrorists through the airport. This is never good.
Similarly, most firewalls ship with "drop" as the default rule, which means that a small error in the firewall rules will just end up with 20-120 second timeouts throughout the network. If instead they "rejected" flows with an explicit deny response, this failure mode would be instant and easier to diagnose.
Just yesterday I was trying to diagnose a packet loss issue on a network where some security troll blocked all ICMP between all endpoints. The last time "ping" was used as an attack vector was in the last century, but apparently it's important to prevent any hope of diagnosing entire categories of network issues. Unsurprisingly, their network has atrocious performance, random periods of high packet loss, and asymmetric routing issues. This will not get resolved until the idiot in the security team quits or retires.
PS: I suspect their issue is large UDP packets getting dropped on some paths due to MTU issues. To diagnose this without ICMP in a complex network is basically impossible. The automatic fix is to enable Path MTU Discovery... which requires ICMP!
Every large environment I've been to that has these security trolls in charge with nobody to reign them in was a shitshow of broken systems performing catastrophically badly because they spend 99% of the time waiting for timeouts.
PPS: Why firewalls don't simply have a default, auto-updating rule for "Enable CRL & OCSP outbound" for all known public CAs is beyond me. This is an extremely common requirement, to the point of being practically mandatory for any medium-large enterprise. If you firewall doesn't have this feature, and about a dozen similar ones, you're getting ripped off. You're probably paying some decent fraction of a million dollars for a bag a tools, not a complete solution.
A few things are whitelisted but the handful of things that break aren't necessary anyway.