Setting the record straight on Halifax E-voting.

There is currently a story making the media circuit on electronic voting in the Halifax municipal elections. This is the story of that election and how this information became known, and what remains hidden behind responsible disclosure today.

In September 2012 I learned that Halfiax was going to be using e-voting and that they had been making claims about the security and viability of online voting – and so I reached out to colleagues in the security community to see if anyone had done any security evaluation of this evoting solution. 

The response I got back was that no one had done the research because there were concerns about the climate for this type of research. For example, just watching a voter cast their vote, could be considered an election offence in some jurisdictions. So I decided to do some basic 'right to knock' type research before the election was open rather than investigate during the voting period. I simply checked out the publicly facing voting instructions on the municipal website and visited the website to see what security they were presenting to would-be voters. For example, was it presenting an identity validated EV SSL certificate? I did some other basic security checks that didn’t require anything more than loading the webpage and looking up details in public registries. To my surprise, the voting portal had been setup by the middle of September (presumably for testing), and there were a number of items I found concerning with the implementation I was seeing.

So I wrote it up, and sent it over to CCIRC (The Canadian Cyber Incident Response Centre)... these are the guys responsible for managing cyber threats against critical infrastructure in Canada – and I've worked with them before on similar disclosures (like IN11-003) ... the process is known as “Responsible Disclosure” and gives the government and the vendors the opportunity to address the problem and make the information public once they have done so. Its generally considered impolite to talk about security vulnerabilities before they have been addressed because they can be used by malicious persons before the systems are corrected.

I never heard back from CCIRC, except for a single 'ack'[nowledged] email confirming receipt. I assumed they were still working on the problem – and perhaps they still are today. Fast forward a few months and I'm discussing online security with a local group of individuals and I bring up the Halifax Election as an example of a system I have concerns with. I don't tell anyone what the specific security issues are, and so after that, a local journalist Rob Wipond comes up and asks me for more detail, essentially, for proof – to which I say “I cant tell you that, ask the government and pointed him towards CCIRC” ... little did I know he would, and did.

May arrives and the CCIRC has apparently filled an ATIP request made by Rob Wipond and he sends the result to me for comment. It's mostly redacted, but it does show that they took the issues seriously and contacted the municipality and vendor to get the issues addressed. It says they mitigated some concerns, but not specifically which ones or what the fixes were. The redactions were unsurprising as the information had not otherwise been made public at this time and many of the concerns would have been hard to resolve. We're not talking about a quick software fix, but rather, altering voting instructions and redesigning how the system is implemented.

Rob apparently put together a video and asked the vendor and the municipality for comment. I didn't think much of it, Rob hadn't discovered the details of the security vulnerabilities and was reporting about redacted documents and questionable audits. I'd never shared the vulnerability data with Rob, so he had very little to work with.

Nevertheless the story gets picked up by CBC radio and I hear Rob talking about the issue. You can listen to that here. ... but he's still not got the details, and so I decide to let the story continue along without my input – what can I add if I cant talk about the vulnerabilities. 

Then, everything changes.  The next day CBC has the HRM clerk and the vendor on air to respond to the concerns. ... I was shocked. During the interview the lady from HRM discloses that we're talking about a “Strip Attack”. She reassures the public in no uncertain terms that when asked “Was the election spoofed” she says “Absolutely not.”... I was floored. Not only can they not know this, but they disclosed the type of security vulnerability in play. Then the vendor goes on about things that have nothing to do with these types of attacks like immutable logs and receipts. They call the whole thing hypothetical, never pointing out that its illegal to hack into a live voting system, so no one could give them proof even if they wanted to.

So now that the cat is out of the bag on the “Strip Attack” portion, I can talk about that part of the disclosure. Those in the know call this ex-post discussion. There remains 2 of the 3 areas of concern that are still secret though, and so I wont be talking about those items. 

I've re-scanned the CCIRC disclosure document to remove the redactions around the now-publicly known stripping attack. You can download that document here [PDF].

My final conclusion in the disclosure was:

“The election process in use may present a number of security and privacy challenges that electors may not be sufficiently aware of when deciding to cast their votes online. These vulnerabilities and lack of auditability may affect the perceived validity of the election result for those that did not use the online mechanisms to vote. The online election may need to be suspended in order to address these and other issues not here disclosed.”

I also make clear that “This can be achieved at scale sufficient to draw into question the election result and is difficult, if not impossible to detect as there are limitless network perspectives that could be attacked.”

I was also concerned to hear that they think these types of attacks are hard, and require considerable cost and effort. The reality of course, is that like any computer vulnerability, there are those who discover and publish these techniques (hard) and those who simply use them. (easy) We call the latter “script kiddies” and yes, you can think of them as they are brilliantly portrayed in this Rick Mercer skit.

In this case a SSL stripping attack could have been achievable with a piece of off-the-shelf software called SSLstrip. Its not hard to use, and doesn't require any considerable effort to install. It can be setup at practically any point between the voter and the voting server and could compromise the confidentiality of the voting information. The problem lies in the voting instructions – when users type in “” their browser translates that into and not ... since theres no SSL at the start, the attacker simply makes sure it stays that way. Everything else looks identical to the user, save for a missing s in the url bar and a lock icon that never shows up. But there was also a third party domain in use at the time I did the research – the voter got redirected to a site called whom was previously unknown to the voter. The attacker could simply redirect that user to, a site with SSL setup, https in the url bar and the lock icon lit -- they clone the website and drop the votes on the floor, collect credentials, etc. You'd have to be really on your game to know that is not the same as in your url bar, given you'd never heard of either of them before you visited the website. These type of plain stripping and hybrid stripping/phishing attacks are ridiculously common on the internet today, and are not difficult to achieve and are particularly difficult, if not impossible to detect as no altered traffic ever hits the official servers.

To actively modify the information in transit – like to flip votes, an attacker would use this tool along with a simple shell script to modify parts of the communication between the voter and the voting servers. Contrary to assertions that you'd have to recreate an entirely new voting app, you rather only have to change a few lines in the in-transit data. At most its a few hundred lines of script -- its the kind of thing the smart kid in your high-school computer lab can do. If its done aptly, the voting servers see the users original IP address and a legitimate SSL connection – SSL is only stripped from the voters perspective, and not the servers. In general (and I've not researched this particular solution) ... receipts and voter codes wont save the process as the attacker can see the codes, hide the receipt entirely, hand out receipts for other legit votes (receipt multiplication), or simply include more form fields on the webpage that ask the voter for more information, like their name and address.

To the incredulous question of 'why' anyone would go to that minimal effort, well, all I can say is – we are still talking about a public election? Right? A recount is impossible, and a city council is the prize.

To the other concerns, well, ask CCIRC or HRM if they're willing to make those public too.