I have heard about some content blockers decrypting SSL/HTTPS connections at the gateway and selectively blocking based on the content.
What are the privacy concerns about this? Is there a way for websites to prevent this from happening to their users? (Does HSTS prevent it?)
What are the privacy concerns about this?
Content analysis by intercepting SSL as an active man in the middle can only be done if the client trusts the CA of the man in the middle because this CA issues a new certificate. Thus it will usually only work transparently in company networks where the systems are managed in a central way and such CA's can get installed. It will also work if the user overrides the warnings or if the software does not properly validate certificates.
If the interception is done by a trusted party (i.e. employer or similar) which has control to the system anyway then the additional privacy implications due to SSL interception are probably less a problem because this trusted party has access to the system already and thus could in theory also grab the plain data outside the encrypted connection.
Privacy implications are more severe if the user is not aware of the inspection and thus transfers sensitive data in the believe that they can not be intercepted. This is especially problematic if these are private data. But, use of company controlled systems for handling sensitive private data is a problem anyway and is not restricted to SSL interception.
Apart from these legal interception there are illegal ways by using trusted certificates known to the attacker. From my understanding of the question this is not what you ask about, but see the story about Superfish adware for an example.
Is there a way for websites to prevent this from happening to their users?
It is hard for websites to detect SSL interception but it would be possible in many cases. Since the SSL interception essentially terminates the SSL connection from the client at the MITM proxy and creates another SSL connection from the proxy to the server the TLS handshake hitting the server will be from the MITM proxy and not the original client. By fingerprinting the handshakes and comparing to typical browsers and MITM solutions it is possible to determine if SSL interception is probably done. For more details see the chapter TLS Implementation Heuristics in The Security Impact of HTTPS Interception.
But, in reality the necessary information to fingerprint the TLS stack are not exposed to the application but are kept inside the TLS engine of the web server. Thus a web application itself can usually not determine if TLS inspection is done or not.
Another way to deter SSL interception from the server side is to require client certificates. Most SSL interception solutions cannot deal with these and even if they could they would need to re-issue the client certificate the same way as they do with the server certificate which can be detected by the server because the issuer CA is not trusted. Unfortunately, this would mean that you would first need to issue certificates to all your clients which they need to install. While useful if you want to use these certificates for authentication of the client anyway it would be a logistic and usability nightmare in most cases.
Does HSTS prevent it?
HSTS just says that the site should be accessed by HTTPS only. Since the site still gets accessed by HTTPS even though the traffic gets intercepted this header will not help. More useful in theory might be certificate pinning, either by using the HPKP header or using built-in pinsets. But while key pinning would detect if the certificate got changed due to SSL interception it is explicitly disabled if the new certificate was issued by a CA which got explicitly added as trusted. This is done to support legal SSL interception like done in companies but also within many antivirus products.
