Category Archives: Indieweb

Posted on
by

On the Indiewebcamp wiki, there’s a page discussing HTTPS, the support for which is strongly recommended. As I’ve mentioned previously, at this stage all non-encrypted communication forms (including traditional port 80 HTTP) should be considered deprecated and dangerous.

Indieweb compatible sites are encouraged to get a higher level as possible, and thanks to some prodding, I’ve finally moved both this blog and my feed over to HTTPS only, with HSTS and forward secrecy.

This got me thinking, perhaps it would be worth adding a “Level 7” (or perhaps Level 6.5) to this, and to suggest that Indieweb sites should also be made available as .onion hidden services on Tor?

Pros

  • Anonymity. Would go a large way towards protecting communication metadata (who know’s whom), which is a goal we should move towards in a world of endemic selector based surveillance.
  • Encryption. Traffic within the tor network is end to end encrypted, and there is some discussion of whether this renders HTTPS unnecessary.

Cons

  • Tor has nothing to do with HTTPS, although it is encrypted. However, the HTTPS levels page seemed a good place to put the suggestion.
  • Could be seen as endorsing one service. Tor is Free software and is pretty much the only game in town when it comes to anonymity networks, but does that constitute a silo? Probably not, but is a point for discussion.
  • No certificates for .onion. There are currently no certificate providers available for .onion domains. But, this may not be a problem.

Anyway, just mooting this as a point for discussion.

Posted on
by

In this post I’m going to discuss a potential attack, using a common method of implementing webmention comments on a site, that can allow an attacker to obtain visitor information from a third party site, and to possibly launch drive-by attacks.

This came about from a discussion related to retrieving non-TLS protected resources from a TLS protected site, and it got me thinking that the problem went a little deeper.

The Attack

A common way of handling webmentions on an Indieweb site, such as those powered by Known, is as follows:

  1. Alice writes an comment on her site, and references Bob’s post
  2. Alice sends a webmention to Bob’s site referencing the URL of her comment, and the post she’s referring to.
  3. Bob’s site retrieves Alice’s comment & parses it for Microformats markup
  4. If all things check out, Bob’s site then renders the comment using text, profile url and profile icon information obtained from Alice’s site.

It is step 4 that’s the problem here.

Typically, when the webmention is parsed and rendered by Bob, the site software will attempt to construct a nice looking comment. To do this, the site software will typically render an avatar icon, together with a user name, next to the comment. This information is obtained by parsing MF2 data from Alice’s site, and while the Webmention spec says that content should be sanitised for XSS etc, profile icons are often overlooked – a URL is fairly innocuous, so it’s generally just dropped into an img tag.

Now, if Alice was evil, she could, for example, configure her server to send “in the past” cache headers when her server served her avatar. This would mean that her server logs would then start collecting some detailed traffic information about the visitors of the page she webmentioned, since every visitor’s browser would retrieve a new copy of her profile icon.

She could, if she was very smart (or was a well funded government agency sitting on a whole bunch of zero day browser exploits) serve specially crafted content designed to trigger a buffer overflow in a specific visitor’s browser at this point.

Worse, she could do this even if the entire site was protected by TLS.

Mitigation

The simplest way to prevent this kind of exploit is not to render profile icons from webmentions. This is, however, a sub-optimal solution.

My current thinking is that Bob’s site (the site receiving and rendering the webmention) should, when receiving the webmention, fetch and cache the profile icon and serve it locally from his server.

This would prevent Alice from performing much in the way of traffic analysis since her server would only be hit for the original request. If you server re-samples the image as well (to enforce a specific size, for example) then the process would likely do much to strip any potential hidden nasties embedded in the file.

There is a DoS potential to this, but techniques for mitigating DoS for webmention/MF2 parsing have already been discussed in the Webmention spec.

Anyway… thoughts?

Posted on
by

I’ve submitted a pull request over on the Known project git repo that allows you to specify a CURL proxy connect string (which has since been merged).

If specified, this connection string will make all web service and web mention calls be sent via a proxy server.

This was a relatively small change, but is useful in many ways – for example, for communicating through a corporate firewall. It is also provides a way of routing Known to Known communication over TOR.

Why would you want to do this?

Well, this is part of an ongoing effort to harden Known against the new attack realities we face on the internet in the 21st century.

One of the things that the Snowden documents have revealed, is that the bad guys are particularly interested in harvesting everyone’s social graph – who knows who – so that they can, among other things, automate guilt by association.

Going to some lengths to hide this information from an attacker sitting on the wire, is therefore, a prudent thing to do.

Ok, how?

  • Install the TOR proxy on your server; this may just be as simple as typing apt-get install tor.
  • By default the tor package only installs the client, so you’ll need to modify the config to open up a SOCKS relay.
  • Next, tell your known site to use this relay; open your config.ini and set the proxy_string:
proxy_string = 'socks5://path.to.tor.proxy:9100'

Gotchas

Routing over TOR is only part of the solution of course. For the communication to be properly safe, you should also encrypt the communication using HTTPS.

Unfortunately, whether a connection is conducted over encrypted HTTPS or not is largely up to your friend’s webserver. But, you wouldn’t be silly enough to run unencrypted, right?

Given the numbers of nasty attacks that can be launched against an unencrypted web connection, the internet at large is now moving towards deprecating unencrypted port 80 HTTP. Google search results will now give preferential treatment to encrypted websites, so that’s another reason!

So, don’t be part of the problem. Have fun!