avast!’s virus scanner uses a self-issued trusted root certificate

tl;dr – avast’s web shield functionality appears to insert itself into SSL connections using a self signed trusted root certificate and a simple kind of man-in-the middle “attack” on SSL. I would recommend you turn off web shield’s https scanning or choose another virus scanner.

I read about this on a blog post that was linked from Hacker News where someone claimed that Avast’s virus scanner for Mac OS inserts itself into SSL-encrypted connections using a self-signed certificate. A quick check on a Windows machine in my household confirmed that this was also true for Windows:

Google Maps showing the Avast! certificate
Google Maps showing the Avast! certificate

I case you’re not that familiar with what the connection information is supposed to show you, you can be pretty sure that Google doesn’t have their identity verified by avast!.

As I was preparing the images for the blog post, I noticed the same behaviour on Outlook.com. Have a look at the “Issued by:” entry for the certificate information and also the encryption information in the URL box:


Now compare the identity information for the “clean” connection with avast! web shield disabled to the information that was showing up in my first example showing Google Maps. This is what a real certificate is supposed to look like:




Did you notice the inscription “Microsoft Corporation [US]” next to the padlock symbol that indicates you’re on an encrypted connection? That shows Microsoft is using an EV (Extended Validation) certificate for this particular site. EV certificates are backed by a much more thorough identity verification process, not to mention that they’re considerably more expensive than a normal certificate. EV certificates are intended to give the user additional confirmation that you’re indeed talking to who you think you’re talking to and not Joe’s Phishing & Hijacking service. With avast!’s inserted security certificate, you lose this additional protection. Oh, and for additional comedy value – avast! themselves use an EV certificate on their own website. Which is commendable, only that you don’t necessarily see it if you use the software you downloaded from that website.

Now, is this a big security crisis and we all need to break out our tinfoil hats? I seriously doubt that. In fact, I believe avast! is acting in good faith with their web shield – after all, if you want to protect your users from malware downloaded over an encrypted connection to a dodgy site, the only way to do this in real-time is basically to insert yourself into the connection in the first place.

However, I personally am a bit concerned that Avast! installs a Trusted Root certificate into the Windows certificate store:


Call it “echos of SuperFish” (see Lenovo’s security advisory here, Google for the tons of spilled electrons on the Internet), but that makes me uncomfortable, especially if the machine you find it on a machine that you use for online banking.

For my part, I’ve turned the web shield https scanning functionality off for now and will probably spend some more time on this sunny afternoon researching alternative virus scanners.

Improved syntax highlighting with org2blog and custom CSS

As mentioned in an earlier post, I changed my blogging workflow to org2blog for writing and editing posts in Emacs and only push them up to my WordPress blog when the posts are almost done. I still do the final editing in WordPress so I can tweak the SEO settings and all that, but the majority of the work happens in org-mode now.

One area that really needed improving was the appearance of the source code that I put in posts. Before I started using org-mode for blogging I edited the code in Emacs, ran it through htmlize and pasted it into my blog post.. That way the Emacs theme I’m using also determined what the generated HTML looked like and it allowed me to control the code’s appearance to a certain extent. Once I moved to org-mode, I just got a generic htmlize output.

In order to improve the appearance output, I switched from the inline styled export to CSS-based export. That way, I can tweak the CSS for the basic syntax highlighting, pick appropriate background colours and all that fun stuff.

First, prepare WordPress for additional custom CSS

The web is full of warnings that you shouldn’t edit your installed WordPress theme so you don’t lose all your customisations the next time the theme is updated. The usual recommendation is to create a child theme instead. This does exactly what I needed to, but felt awfully heavyweight for the comparatively simple task at hand. All I wanted was jam some additional CSS onto a page and be done with it.

I’m using Jetpack on my self-hosted WordPress install for certain additional features that you’d normally only get when hosting a blog on WordPress.com. Jetpack has a neat feature called “Custom CSS” that allows you to add additional CSS to your existing theme’s stylesheets. In other words, it allows you to provide exactly the kind of customisation I need to tweak the source code highlighting. If you haven’t activated the Custom CSS feature yet, go to your Jetpack settings and activate it.

Adding org-mode’s code export CSS

This is a relatively simple operation. First, you need to tell org-mode to export the source code formatting information using css and not the more usual inline style. This is easily done by adding the following setting to your .emacs and re-evaluate that particular piece of code:

(setq org-export-htmlize-output-type 'css)

Once that’s done, the easiest way to get the parts of the CSS that are relevant to source code formatting is to create an org file, stick a #+BEGIN_SRC/#+END_SRC block in there and export that to HTML. You can then pull the relevant parts of CSS out of the resulting HTML buffer and put it into the custom CSS settings provided by Jetpack.

In my case, the relevant CSS looks like this:

pre {
  border: 1px solid #ccc;
  box-shadow: 3px 3px 3px #eee;
  padding: 8pt;
  font-family: monospace;
  overflow: auto;
  margin: 1.2em;
  -moz-border-radius: 5px;
  border-radius: 5px;
pre.src {
  position: relative;
  overflow: visible;
  padding-top: 1.2em;
  background-color: DarkSlateGrey;
  color: WhiteSmoke;    
pre.src:before {
  display: none;
  position: absolute;
  background-color: white;
  top: -10px;
  right: 10px;
  padding: 3px;
  border: 1px solid black;
pre.src:hover:before { display: inline;}
pre.src-sh:before    { content: 'sh'; }
pre.src-bash:before  { content: 'sh'; }
pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
pre.src-R:before     { content: 'R'; }
pre.src-perl:before  { content: 'Perl'; }
pre.src-java:before  { content: 'Java'; }
pre.src-sql:before   { content: 'SQL'; }
pre.src-clojure:before { content: 'Clojure'; }

Copy your customized CSS into Jetpack’s “Custom CSS” edit control, save your changes and you’re done. The next time you publish a post from org-mode using org2blog, it’ll automatically apply the above CSS to all your code blocks that were marked as such.