Posted on
by

Over on my Idno development fork, I’ve pushed some functionality that I think is rather neat (and I hope will be adopted by upstream Update: it was.).

In a nutshell, I’ve started fleshing out the ability to Friend/Follow other users (based on some stuff I’ve previously kicked about).

The ability to add friends (and create posts only visible to them) is what puts the social in social network, and was functionality previously missing to idno core. An added complexity is that, since Idno is designed to be a distributed network, this needs to work across multiple installations.

Idno references users by URL, so this much was fairly straightforward, however I absolutely didn’t want people to be typing URLs into boxes to add a friend…

MF2 to the rescue!

Since everything in Idno is marked up and parse-able by it’s built in Microformats parser, Idno can easily harvest the required information when parsed a page, so all I really needed to do was pass an endpoint a URL.

So, I created a simple bookmarklet:

following

Once dragged into your toolbar, you can click on any page and your Idno installation will find any users present and allow you to add them in a couple of button clicks.

addfriend

Monocultures are considered harmful

What makes this approach especially cool is, so long as the page is marked up using simple Microformats, your friend does not need to be running Idno in order for you to add them.

Your friends could be running Elgg, WordPress, Fizzbuzz, whatever, and you can still follow them, and allow them to see private posts (using some form of authentication – more on that to come).

Have fun!

Posted on
by

Elgg, like Idno supports a number of different views on data – standard HTML, JSON etc. However, unlike Idno, Elgg does not natively support JSONP.

JSONP allows you to make cross domain calls using JSON data, and is very handy for querying data from other sources using your fancy-pants javascript/jquery ajax code. It’s how, among other things, the idno feed widget running in the sidebar works.

Anyway, a commenter on another post asked about Elgg support, and because I had a few minutes spare, I put together a quick plugin!

» Visit the project on Github...

Posted on
by

GCHQoogle: so much for "Don't be evil" So, unless you’ve been living under a rock for the past few months, you will be aware of the disclosure, by one Edward Snowden, of a massive multinational criminal conspiracy to subvert the security of internet communications and place us all under surveillance.

Even if you believe the security services won’t misuse this, what GCHQ can figure out, other criminal organisations can as well, so like many others, I’ve decided this’d be a good time to tighten the security of some of the sites I am responsible for.

Enabling HTTP Strict Transport Security

So, lets start off by making sure that once you end up on the secure version of a site, you always get sent there. For most sites I had already had a redirect in place, but this wouldn’t help with a number of threats. Thankfully, modern browsers support a header, that when received, will cause the browser to rewrite all connections to that site to the secure endpoint before they are sent.

A quick and easy win, so in my apache conf I placed:

Header add Strict-Transport-Security "max-age=15768000; includeSubDomains"

Auditing my SSL configuration, enabling forward secrecy

The next step was to examine the actual SSL/TLS configuration used by the various servers.

During the initialisation of a secure connection, there is handshake that takes place which establishes the protocol used (SSL / TLS), the version, and what algorithms are available to be used. The choices presented have an effect on exactly how secure the connection will be, and obviously, older and insecure protocols and weaker algorithms present security risks.

I have been, I admit, somewhat remiss in the past, and have largely used Apache’s defaults, which was ok for the most part, but as SSL Lab’s handy audit tool revealed left a number of weak algorithms available as well as not taking advantage of some newer security techniques.

I quickly disabled the weaker algorithms and SSL protocols, and also took the opportunity to specify that the server prefers algorithms which support Forward Secrecy.

Forward secrecy is a property of newer algorithms (supported, sadly, only by newer browsers), that means that even if the key for a given session has been compromised, that key could not be used to decrypt any future sessions. This means that even if the attacker compromised one connection, they would not be able to compromise any past or future connections.

Here is a handy guide for implementing this on your own server.

The downside of these changes of course is that older browsers (IE6, I’m looking at you) are left out in the cold, but these browsers (IE6, I’m still looking at you) are using such old implementations with weak algorithms, they would likely be in trouble anyway.

Security is a moving target, so it’s important to keep up to date!

Update: If you’re running Debian (as I am), you will have some issues with ECDHE suites until stable updates to Apache 2.4. Until then I’ve tacked on AES support at the end, to support IE with something reasonable, but giving forward secrecy to more modern browsers.

Update 27/6/14: Debian recently backported a few 2.4 cipher suites into the 2.2 branch in debian stable. This means that Perfect Forward Secrecy is now supported for Internet Explorer!