Funny that - I thought the advantage of unencrypted HTTP was so that middleboxes could do things like caching (squid, etc) and outbound deep packet inspection to prevent information leaks in corporate environments.
†The correct way to proxy HTTPS is wire a client and server with your meddling code in between, your client negotiates a TLS connection to say https://news.ycombinator.com/ and it decides exactly what is sent and can see in plaintext exactly what's received. Users make TLS connections to your server and it presents them with a certificate it made, maybe claiming to be news.ycombinator.com and signed by My Corp Monkey Proxy then passes through some requests to the client we described.
But it's much cheaper not to do this, and all of the other things you might do to achieve the same goal are insecure or break the protocol or both. So there's a big financial incentive to destroy security, while often ironically claiming to be improving security e.g. anti-phishing. For example choosing random number is hard yet at the same time essential for security - so several major vendors sold products that just didn't. When they turned A->B into A->M->B with their product as M, they'd just re-use the random numbers from the other conversation in the pair. This had been destroying security for all their customers for years, but we only found out they were doing it because it broke with TLS 1.3 final.
Specifically when a TLS 1.3 server (but not draft versions for important compatibility reasons) talks to a client that doesn't agree to TLS 1.3 it scribbles the letters "DOWNGRD" over part of the random number field. Since the client supposedly doesn't know TLS 1.3 it shouldn't care, DOWNGRD is a ludicrously unlikely "random" choice but so is "FCKTRMP" or "KICKASS" and those don't mean anything in older TLS versions either. But if the client really does speak TLS 1.3 and has somehow been tricked into negotiating an old version, this weird choice of "random" number signals it's a trick and it will disconnect.
The affected "proxies" would tell a nice shiny new Chrome or Firefox (which can speak TLS 1.3 and thus are looking out for DOWNGRD) that they only knew TLS 1.2, fair enough. And they'd tell servers, say www.google.com, the same thing. But the TLS 1.3 capable servers would scribble DOWNGRD into their random number field, and then because these "proxies" weren't actually assembled from a separate client and server but just re-used all the numbers, the DOWNGRD gets copied into data received in Chrome, and it disconnects because it has seemingly detected an active attack.