Government censors HTTPS traffic to our website. Workarounds?
Unfortunately, circumventing censorship is better addressed on the client side, so there aren't many server side settings that could help with that. You could advise your users to use a VPN, Tor, and/or public DNS with DNS-over-HTTPS (RFC 8484) or DNS-over-TLS (RFC 7858).
You make the assumption that the censorship method has something to do with DNS, but have you actually tested this? Did you know that the server name indication (SNI, RFC 6066, 3) in the ClientHello is unencrypted and may also be used to block the TLS connection? Luckily, TLS Encrypted Client Hello (draft-ietf-tls-esni-09) is on its way and can help with that. More reading on the subject:
- Seth Schoen: ESNI: A Privacy-Protecting Upgrade to HTTPS (EFF)
- Matthew Prince: Encrypting SNI: Fixing One of the Core Internet Bugs (Cloudflare)
(We don't usually add any greetings to our Q/A posts, but your 007 reference is golden!)
Most of Russian providers implement Inquisition requests by intercepting DNS traffic and changing it on the fly (and it's pretty easy since it's unencrypted), effectively using the man-in-the-middle scheme, for instance, all of the Ertelecom-affiliated ISPs are using this method. In this case (which can be easily determined by just comparing client-side resolved IP vs the real IP) nothing can be done from server side: even if you'll implement DNSSEC and signed answers will start to flow, all this technique will do is breaking the client-side name resolving stack entirely, when it comes to your domain (however, this is purely a theory, but you can easily prove I'm wrong; if I am).
Unffortunately, all of the available solutions to bypass DNS MitM needs to be applied to the client side, not the server one.