As Shadow Wizard notes, a good workaround for all sorts issues caused by clumsy meddling proxies, firewalls or broken antivirus software is to use Stack Exchange over HTTPS. This is pretty easy to do: just click your browser's URL bar and replace the
http:// prefix with
https:// (or just add the
https:// prefix, if your browser hides it for plain HTTP sites).
Alas, HTTPS support on Stack Exchange is still not perfect. While it mostly works, there are a couple of remaining issues that can be a bit annoying.
One problem is that Stack Exchange is full of
http:// links that will drop you back out of HTTPS mode when clicked. While most (but alas, still not all!) links in the navigation interface actually are properly HTTPS-preserving, almost all links in posts and comments will still use plain old HTTP.
One way to solve this problem is to install the HTTPS Everywhere browser extension, which will make your browser automatically use HTTPS on any sites that are known to support it, even if you follow a plain
http:// URL. By default, HTTPS Everywhere will also apply to lots of other sites besides Stack Exchange; most people would consider this a good thing, but if you don't like it, it's possible to configure HTTPS Everywhere to only apply to certain specific sites.
A more limited solution is provided by the SOUP user script (which — disclaimer — I am the main author of), which simply rewrites any internal links on Stack Exchange sites to not drop you out of HTTPS mode. SOUP won't force you into using HTTPS, but it does try to keep you from dropping accidentally back into plain insecure HTTP. One limitation of SOUP is that it cannot rewrite links coming from outside the Stack Exchange network (e.g. from Google search results). To get such links also rewritten to use HTTPS, something like HTTPS Everywhere is needed.
Another problem with Stack Exchange's HTTPS support is that per-site meta sites are broken over HTTPS, giving a scary "invalid certificate" warning. This is caused by an unfortunate incompatibility between SE's site naming scheme (in which per-site metas have host names of the form
meta.*.stackexchange.com) and the current standard for SSL wildcard certificates (which effectively disallows wildcards of that form). Nick Craver's blog post from 2013 explains this issue in more detail.
Nonetheless, it is in fact possible to use per-site metas over HTTPS, simply by clicking through the error message and setting up a manual security exception. On Firefox, for example, you need to click "Advanced", then "Add Exception...", and finally "Confirm Security Exception". On Chrome, you also need to first click "Advanced" (which is written in small gray letters, making it deliberately hard to notice) and then "Proceed to meta.site.stackexchange.com (unsafe)".
Of course, before doing this, you should verify that the security error is indeed just a technicality, and not someone trying to subvert your Internet security. If your browser shows the certificate as being valid for
*.stackexchange.com, you can be reasonably confident that it indeed belongs to Stack Exchange, Inc.; if it doesn't, you should probably not accept it.
Ps. One unfortunate side effect of this is that, because of the certificate mismatch warnings, HTTPS Everywhere does not currently force HTTPS for per-site metas (and, in fact, will automatically downgrade any HTTPS links to them back to plain HTTP!). If you like, it is possible to manually edit the HTTPS Everywhere ruleset to remove the exclusion and downgrade rules, but this can be somewhat tricky in practice.