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.

ALPR and Digital Civil Rights

Once again my fight for digital civil rights has landed on the front page of the Times Colonist, this time in relation to the ALPR (Automatic License Plate Recognition) surveillance system. I highly recommend reading the commissioner's report, which you can find at

The report goes into great detail about the ALPR program and is derived from a lot of information that our research group has not been able to obtain under the freedom of information access processes -- this despite repeated requests for all documents of all types relating to the ALPR program. (Rob Wipond reports that he currently has 6 complaints before the federal information commissioner)

The report has learned that non-hit data (data including the movement patterns of innocent Canadians) is being acquired and shared outside of the BC jurisdiction. It also makes crystal clear that where local police collect the information, they are in custody of the information and are subject to FIPPA regulations on their handling of that data. This includes not storing and not sharing any data that is, after-scanning and comparison to an on-board hotlist, no longer useful for policing purposes.

The Commissioner's report also reveals a new data point which we were unable to access. Obsolete Hits. These are hits that are valid at some point in the database, but that are no longer valid when the vehicle is scanned. The commissioner's report suggests that these false-hits cannot be shared with the RCMP either. This requirement alone is a huge win for accountability of this program, as it will mandate the review of each and every hit produced by the ALPR system before it is shared with the RCMP or used for secondary purposes. This should return the ALPR system to being a useful convenience tool for police plate scanning, but will remove the dragnet surveillance capability of the system as it will likely necessitate manual review of the data produced.

That said, I was disappointed that the commissioner did not engage in an analysis of the confidence rating of the system as a whole. With accuracy rates claimed in the 70-95% range for ALPR systems more generally, they have the potential to generate tremendous amounts of false, incorrect, information that will be used against people. The commissioner's report gives us two data points that are hugely valuable in this regard however. For every 100 scans, only 1 is a hit. In a 95% accurate scanning system, 5 scans in 100 will be inaccurate. The report also states that 4% of hits are obsolete hits, further reducing the confidence rating of the resulting data produced. A Bayes Theorem Analysis of the overall system's data confidence rating is definitely needed, but will require significant resources and access to do properly. The initial data however, suggests that the system may produce significant volumes of incorrect data, and confidence ratings may be low enough to call into question the entire program, even when only discussing the hit-data context. Certainly ALPR's use as an evidence-generating tool for court-purposes will be easily challenged and investigations that start from ALPR data may be subject to the poisonous tree doctrine in certain jurisdictions.

Overall, I'm thrilled with the report. It validates what I and my colleagues have been saying about police use of surveillance tools and is an incredible study into what these programs actually look like in practice. The data in the other-pointer-vehicle category, as just one example, shows just how broadly these programs are being applied. It also draws into question many previous statements by the authorities on the scope of the ALPR program.

I look forward to Victoria Police and the province fulfilling the report's recommendations on disclosure and access to information. Sunlight is always the best disinfectant.

Responsible Disclosure and the Academy.

They say publish or perish, but what happens when publishing puts people's personal information at risk?

Last year I discovered that SSL as it is implemented for server-to-server data transfers in popular software has common, and extremely serious problems. Merchant API's from PayPal, Moneris, Google and others left people's credit card details at risk for interception. I discovered that oauth libraries listed by Twitter were vulnerable -- and found a bunch of other problems that I'm still in disclosure with. It was a big deal, I'd found what computer security folks call a 'class break'.

So I begun a responsible disclosure process. Initiallly I had discovered a vulnerability in a single merchant provider's api and as a good security researcher does, I contacted the vendor -- this quickly went sideways. As a result, I enlisted the help of a local academic and trusted resource of mine, Christopher Parsons. Parsons recommended I get in contact with Tamir Israel, staff lawyer for CIPPIC, and thus begun what was to be (and still is) a nightmarish saga of responsible disclosure and broken cyber security programs.

I've not written this openly about peerjacking before today because this issue is still very much in play, but I feel that because Dan Boneh and his colleagues have published the research that I must respond and set the record straight.

Tamir offered to help me free-of-charge and really went to bat for me, offering legal advice and offering to help with the predicament I was quickly getting myself into. Thanks to Chris and Tamir, we got in contact with the Office of the Privacy Commissioner of Canada to disclose the vulnerability and see if it was within their area of responsibility. After a couple phone meetings, it was determined that because there was no evidence of actual data being stolen via this vulnerability, and with me being unable to provide such evidence without engaging in illegal computer hacking, it was determined it was outside their jurisdiction. The privacy commissioner's process, it seems, is about cleaning up data spills, not preventing them. The file was referred to the CCIRC... The Canadian Cyber Incident Response Centre.

I had already emailed CCIRC, but had received no reply. This is a small agency and while they tell me they that they had received my disclosure, its not clear what they had done prior to the privacy commissioner's office becoming involved. The group seems to work silently behind the scenes -- if there was action, I didn't know about it.... But once the privacy commissioner had referred the file, things changed. Tamir and I began what turned into a weekly discussion with CCIRC about the vulnerability -- it culminated in the Cyber Security Information Notice IN11-003. It was new ground for CCIRC (disclosing new zero-day's is not something they had much, if any, experience with) ... I wanted the agency to name names, but they decided against it. The notice contains only a technical description of the vulnerability, but no context for who is at risk. Mom and Pop shops using PayPal, Moneris or Google would likely never see this notice, nor, if they did, would they understand that their business and customers were at risk. Throughout the back n forth, I was rather miffed about the process, but Tamir rightly pointed out that the disclosure was helpful in that it provided a third party look at the vulnerability and would help confirm what I was saying.

I couldn't live with not disclosing the affected software though, and throughout the process I had found a number of other vendors that were affected -- I'd even found Google Code Search and GitHub Search terms that pointed to a -much larger issue- and found other non-php software that was affected... I had disclosed the affected software that I knew about and the code searches to the CCIRC during the development of the information notice, but they hadn't named names. I'm sure they had their reasons, but I had the public to think about. How were mom and pop merchants going to know to patch? What about their customers credit card details and order information?

I decided to take the list of companies I knew had been notified, and who had had time to resolve the issue, and to disclose about the vulnerability in their software. That resulted in ... but that isn't even close to a complete list, and CCIRC is to my knowledge still working on the issue of the GitHub and Google Code Searches. For my part, after the disclosure I continued to work with PayPal and others to get them patched up. PayPal is still working on this issue in their API's and towards merchant disclosure -- which makes the Boneh et al paper so troubling. I never spelled out how the other PayPal API's were affected because the issue is still being resolved... responsibly.

So that brings me to today. Dan Boneh (a well known academic cryptographer) and a number of colleagues have published "The most dangerous code in the world: validating SSL certificates in non-browser software" ... I had been given a headsup in August about the paper coming out and I reached out to Dan....

[Normally I wouldn't share publicly an email I sent, but since I never got a reply, well, its just my own writing....]


Sent on 08/15/2012

Hi Dan,

I was linked this morning to by
<redacted> this morning. Just wanted to let you know that this appears to
be exactly like my prior published work on peerjacking,
( and that informs Government of Canada, CCIRC
cybersecurity notice IN11-003.

I am still in responsible disclosure with a number of vendors on this,
including undisclosed vulnerabilities in other PayPal sdks, and non-php
related vulnerabilities, to which I believe you may be making reference.
I have been withholding a full whitepaper on this research while the
industry addresses and resolves these problems. This issue affects a
wide swath of the credit card processing industry and represents a
threat to critical infrastructure. I would appreciate your team not
disclosing the vulnerabilities in specific software before all
responsible disclosure avenues have been properly exhausted.

I am working with CCIRC and others to responsibly disclose this


Kevin McArthur

I never got a reply, and I even blogged about it before it was released, but today I've noticed that the paper has been made available in PDF to the public. I've read it, and I'm cited in it, but I've made it clear previously that peerjacking affects more than PHP applications and that I've purposefully not disclosed the details of the research due to the ongoing responsible disclosure process. To see this research published within the academy and in the face of my plea to respect the responsible disclosure process troubles me.  However, please know that I tried to make sure this vulnerability was resolved before it was widely disclosed.

Welcome to the world of peerjacking. SSL is dead.

Understanding the Lawful Access Decryption Requirement

Christopher Parsons (@caparsons) and I have just published "Understanding the Lawful Access Decryption Requirement" via SSRN

In it we discuss the implications of bill C-30 on encrypted communications, especially those communications featuring systems that feature perfect forward secrecy or client software involved in key generation.

Certificate Pinning in PHP

UPDATED: The previous version of this script is affected by a security vulnerability in some PHP versions. Details are located at: I have updated the script below to include a version check, and if you are using this technique/code I strongly suggest you add similar version checks.

I spent a few hours today working on a piece of open source technology that should help address some of the peerjacking concerns with PHP developers. This tool will help me secure our ecommerce clients, as well as help improve the SSL ecosystem within PHP itself.

So without further introduction, certificate pinning in PHP. A reference design called sslurp (written by Evan Coury (@evandotpro)) and a pin.php pinning script. This builds on the work by Adam Langley and Moxie Marlinspike who did the heavy lifting in developing the pinning algorithm and have also published pinning scripts (written in GO and Python respectively). My PHP contribution to the pinning ecosystem makes it possible to set and verify pinned certs within PHP projects.


Copyright (c) 2012, StormTide Digital Studios Inc.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

    * Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

    * Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in
      the documentation and/or other materials provided with the

   *  Neither the name of StormTide Digital Studios Inc, nor the names 
      of its contributors may be used to endorse or promote products 
      derived from this software without specific prior written permission.


//Version 0.2 Alpha

//Check for vulnerable openssl_x509_parse call.

if(version_compare(PHP_VERSION'5.3.0''<')) {
//PHP Less than 5.3
die("PHP Version Insufficient. See" PHP_EOL);
version_compare(PHP_VERSION,'5.3.0','>=') && version_compare(PHP_VERSION,'5.3.28','<')) {
//If less than 5.3.28 in the 5.3 series.
die("PHP Version Insufficient. See"PHP_EOL);
version_compare(PHP_VERSION,'5.4.0','>=') && version_compare(PHP_VERSION,'5.4.23','<')) {
//If less than 5.4.23 in the 5.4 series.
die("PHP Version Insufficient. See"PHP_EOL);
version_compare(PHP_VERSION,'5.5.0','>=') && version_compare(PHP_VERSION,'5.5.7','<')) {
//If less than 5.5.7 in the 5.5 series.
die("PHP Version Insufficient. See"PHP_EOL);

if(isset($_SERVER['argv']) && is_array($_SERVER['argv']) && !empty($_SERVER['argv'][1])) {
$cert $_SERVER['argv'][1];
} else {
"Error no cert provided. Usage ./pin.php cert.crt"PHP_EOL);

if(is_file($cert) && is_readable($cert)) {
  try {
$contents file_get_contents($cert);
$parsed openssl_x509_parse($contents);
$pubkey openssl_get_publickey($contents);
$pubkeydetails openssl_pkey_get_details($pubkey);
$pubkeypem $pubkeydetails['key'];
//Convert PEM to DER before SHA1'ing
$start '-----BEGIN PUBLIC KEY-----';
$end '-----END PUBLIC KEY-----';
$pemtrim substr($pubkeypem, (strpos($pubkeypem$start)+strlen($start)), (strlen($pubkeypem) - strpos($pubkeypem$end))*(-1));
$der base64_decode($pemtrim);
//Calculate the SHA1 pin of the Public Key in DER format.
$pin sha1($der);
$base64 base64_encode(sha1($der,true));
'Pin for: '$parsed['name']. PHP_EOL;
'Pin Hex (SHA1-long): '$pinPHP_EOL;
'Pin Base64 (SHA1-short): '$base64PHP_EOL;
'Pin Chrome format: sha1/'$base64PHP_EOL;
 } catch (
Exception $e) {
'Could not get public key pin');
} else {
'Could not read cert');

This cli script will generate pins for SSL certificates and the reference design by Evan Coury for validating a pinned connection can be viewed at

Additionally the sslurp package will, in the future, likely form the basis for bootstrapping a CA bundle into PHP projects requiring secure operation.


#PeerJacking - SSL Ecosystem Attacks Against Online Commerce (update)

I just wanted to put up a short update about my PeerJacking research today. The vulnerability I discovered with SSL certificate validation in online commerce applications in July of last year is still in responsible disclosure with a number of software vendors, and I am awaiting the successful mitigation of the vulnerability before releasing the whitepaper describing the scope and impact of these certificate validation failures.

I've been informed by one of these vendors that there is strikingly similar research to be presented at the ACM CCS 2012 conference. I am confused by this as I have not been contacted by these researchers. The researchers published an abstract that revealed a number of the companies affected by PeerJacking, including several that I am currently working with on mitigation of this critical vulnerability. I've attempted to contact the academics involved, but have not seen any reply yet, though, the abstract in question appears to have been removed from the web for the time being. 

PeerJacking (programming failure to verify peer certificates) affects nearly all major programming languages and is depressingly common. It is deployed widely throughout commercial server-to-server API's from hundreds of distinct vendors. It is the breadth of the vulnerability and the sheer number of affected vendors that makes responsible disclosure of this vulnerability so complicated and why 13 months later I am still largely limited in what I can say publicly about this issue.

As before, please contact the Canadian Cyber Incident Response Centre for advice. They are the agency handling the responsible disclosure, notification and mitigation of this vulnerability affecting critical infrastructure.

See also (previous posts on this topic):
PeerJacking - SSL Ecosystem Attacks Against Online Commerce
Credit Card System Update (IN11-003)
Credit Card System Vulnerability
Update on Credit Card System Vulnerability.

Is there a safe way to upgrade users to https?

Update: Ryan's Responded with Whats your organizations policy on SSL? which covers these items in detail.

This morning GlobalSign CTO Ryan Hurst put up a simple post: "Rewriting HTTP URLS to HTTPs URLs in Apache"

It's the advice I hear all the time from security-minded developers, but I think its wrong, and its wrong because of a flaw in the way the web works. That said, I've used the technique from time to time, and it works, a bit.

So what does it do. If you ask for you get http, a 302 redirect and a reference to the https version of the url. Your client then begins a HTTPS request. Sounds good right? Sorta.

The initial request is sent over http and the client is not expecting a SSL result. They're not checking for a cert, or a lock icon because they didnt ask for a secure connection. The developer thinks its secure because he sees his users interacting over SSL, but theres a problem. That initial redirect is the weak link.

Lets talk the typical Mallory between Alice and Bob problem. Bob wants to talk to Alice. Bob sends Alice a message and waits for a reply. Alice not wanting to talk insecurely tells Bob to go to a secure site at a specific url. Bob dutiffully follows the advice and goes to the secure site. The only problem is that Bob cant tell the difference between Alice and Mallory at this referral stage. Did Alice really tell Bob to go to the secure site, or did Mallory? In this case Mallory can redirect Bob to an insecure site of Mallory's chosing. Its up to Bob to check that the referred site's identity validates and is secure, but Bob as you'll recall wasnt expecting secure messaging, and is used to Alice telling him to goto the secure site when she wants to talk securely, so isnt being paranoid about the authenticity of the referral. Bob has done this 100 times without issue. But on time 101, Mallory hijacks the referal, and now Bob is talking to Mallory who is relaying messages to Alice and pretending to be Bob talking securely to Alice. The protection SSL was supposed to bring never happened and no one was the wiser. Alice sees a secure connection to who she thinks is Bob and Bob sees no security to Alice as he expected. Everyone is happy, but Mallory is listening in.

Moxie Marlinspike demonstrated this attack with a talk and tool called SSLStrip. Yes, thats right, its now off the shelf software.

So is it safe to upgrade users this way? Is there any value in the activity? Not really. In one sense, it changes the threat model from passive listening to active attacking, and so offers -some- security, but it also has a downside, it trains the users not to ask for the https page. The sum of the security change, about zero.

So what can make it better? HSTS. Http Strict Transport Security. This technology works such that after the first time you see a https site, if you type http in or visit a http link, it will automatically upgrade you. Its a good technology, with privacy problems (see, but it also has some odd side-effects when combined with Ryan's suggestion of a site-wide redirect, in that, it will actually hide mixed content errors on your pages for some clients. For a demonstration of this, see this page.

So as a person or company interested in real https security, what do you do.

Three things.

1) Implement HSTS

2) Get listed in HTTPSeverywhere.

3) Pin your certs in browsers that allow this (See Google Chrome)

#PeerJacking - SSL Ecosystem Attacks Against Online Commerce

Responsibly Disclosed to Canadian Cyber Incident Response Centre [CCIRC], Office of the Privacy Commissioner of Canada and Canadian Bankers Association, July 15, 2011. Informs government Public Safety Notice IN11-003 released December 20, 2011. Due to the scope of the issue, vendor notification was performed by CCIRC.

Users of the following libraries should evaluate their software for exposure to IN11-003 (#PeerJacking). Many of these libraries are now patched by the vendors but affected versions will need to be deployed on end-user web servers.

Moneris eSelectPlus 2.03 PHP API
PayPal SDK Soap (MD5: ae8b2b7775e57f305ded00cae27aea10)
PayPal SDK NVP (MD5: 5a5d6696434536e8891ee70d33b551bd)
PayPal WPS ToolKit (MD5: a9e7c4b8055ac07bb3e048eecc3edb14) Library (* Defaults to secure, but affected by configuration instructions. anet_php_sdk-1.1.6)
Google Checkout Sample Code (V 1.3.1 for PHP) (Article Updated April 2, Patched in V.1.3.2 Download Here)
OSCommerce 2.3.1
CiviCRM 4.0.5 (Update Apr 2: Still vulnerable as of V 4.1.1)
Magento 1.5 (Update Apr 2: Vulnerabilities still exist as of version 1.6.2)
UberCart for Drupal (uberdrupal-6.x-1.0-alpha8-core)
Pear Services Twitter. (0.6.3)
Themattharris Oauth (< 0.61) (*Twitter indexed library )
TwitterOAuth (File date: May 18, 2011, *Twitter indexed library

Additionally the following GitHub Search may help identify affected libraries. Here. Instances of CURLOPT_SSL_VERIFYPEER set to false or 0, and instances of CURLOPT_SSL_VERIFYHOST set to 0, 1, or true rather than the value 2, may indicate exposure. PHP ships with secure defaults for these values and thus this is not a vulnerability in PHP or CURL, but entirely contained within library code.

Libraries where these default values are overridden and not correctly set will be vulnerable to man-in-the-middle interception and modification of data in transit by an attacker using a self-signed SSL certificate and off-the-shelf software. Fixes to these libraries usually cannot be deployed centrally by the vendors, and typically must be upgraded individually on all deployed client systems.

Please contact the Canadian Cyber Incident Response Centre for further mitigation information and advice. Thanks to Tamir Israel (CIPPIC) and Christopher Parsons for their assistance in responsibly disclosing this vulnerability.

"Privacy Commissioner slams provincial surveillance program"

Rob Wipond has published another article on ALPR surveilance coming out of his, Chris Parsons and my own research into the subject. New documents obtained under freedom-to-information show considerable reason for concern with the ALPR surveilance program.

Read It Here: or in the March 2012 edition of Focus Magazine

Read our source documents, obtained under FOI, here:

ALPR - Amazing research, terrible transparency and dangerous agenda.

For the last 6 months I've been spending my off-hours working with a research collective consiting of Rob Wipond, Chris Parsons and Myself investigating the technology known as Automatic License Plate Recognition (ALPR) and how it is being deployed by the RCMP and local police in Canada.

I'm happy to report that Focus Magazine has now published the story as written by Rob Wipond and you can read it here Hidden Surveilance" you can also read the source documents uncovered via freedom to information request on Rob's website RCMP & VicPD ALPR Documents Released

Rob covers the saga of obtaining these documents and doing the research far better than I ever could, so I'll dedicate this post a little bit to the inside baseball, how it came about and how citizens around the country can reclaim investigative journalism and their civil liberies themselves.

It all started in 2006, when the BC government released a press release about the deployment of a new policing tool. The press release really tries to sell this program, but it also revealed to the public for the first time that non-hit license plates (that is, license plates of completely innocent Canadians) would be tracked alongside the criminals and stored for 90 days.

To set the scene and add some personal context - in 2006, I was 23, and my job hadn't been e-commerce, it was VoIP. For a while I was employed as senior VoIP architect at a publicly traded telco and I designed research systems in SIP, RTP, ENUM, etc... as well as designing lawful intercept systems and figuring out ways to punch through carrier Net Neutrality violations. Around this time I founded Canada's first digital policy campaign for Net Neutrality... and, at least in my mind, helped to define the space which groups like OpenMedia now dominate. I was an activist. They wrote about me in The Tyee. People threatened to sue me for public comments.

But I'm not an anarchist and the activist scene never felt right to me -- I might have a soft-spot for #occupy, but chances of finding me tenting by city hall are pretty slim. My parents were life-time civil servants, my dad a senior geologist, helped invent what we now call opendata by running skunkworks projects within the various deriviations of Energy, Mines and Petroleum, while my mother won a premiers award for work breaking down barriers to provincial trade. You learn a lot about the system growing up with civil servants, and I learned. I learned about waste and progress, about situations that evoke memories of 'ours is not to wonder why' and about situations where a moral stance was absolutely required, and of the very real, personal,  consequences for whistleblowers within in our government. I ended up with both a respect for the inviduals working within, and a strong distrust for the institution itself.

So at 23 with the knowledge of how lawful intercepts were conducted and how dangerous this government can be, I read their press release with horror. I absolutely knew it would be abused, and that it was just the beachhead into a generalized surveilance society. I picked a fight. I wrote articles, public letters to privacy commissioners and even launched a site called to collect my work. It got attention, but if it had any effect, I couldn't see it. I wasn't plugged in to the academics and civil liberties groups I am today. It took the Ideas Victoria group in 2011 to really make those linkages. So I let it drop, filed the articles away on my blog, and moved on to other pursuits -- I moved to Edmonton and refocused on building my business.

But it gnawed at me. I can't believe our government is doing this, that our media didnt care and that this is the society we are living in. It sucked, but it was hopeless. I bitched about it from time to time on my blog, and to the civil liberties types I met, but it wasn't until a meeting in 2011 with a critical thinkers group, that it all came together. I was explaining the issue to the group of folks there that night and Rob Wipond (an ideas regular) says, "I'm a journalist, so lets cover it", Chris Parsons (also an ideas regular, and surveilance researcher) said he was interested in helping too -- and so we began. Rob did what I couldn't, he knew how to pry information out of a system that explicitly claimed they had no information. So most other journalists might have dropped it, but when Rob reported 'they say they have nothing' or 'they say they store nothing', and we told him that couldn't possibly be true or we explained how, if it were true, it only raised more questions, he persisted. And it turns out we were right.

Over the next 6 months documents slowly came in as Rob fought with the FOI process. When we got back the privacy impact assessment document (PIA) from the RCMP, our worst fears were realized, they were collecting non-hit data. They were surveiling the public. We proved it... sorta. In followup interviews Rob was told that they dont actually do what they say they do in the PIA -- its only in the PIA but it doesnt actually happen.

So Rob kept digging and Info slowly came in. You can read the documents we got on Rob's blog. Nearly every wednesday night before the ideas meeting, we'd have dinner and pour over the latest twist and turn in the case. It was frustrating as all hell, but as Chris Parsons pointed out (paraphrased) ... "Every time they do this, its just another page for the report. "

So we pressed on and Rob kept getting the run around, but somehow with each conversation he learned some new little piece of information that linked to another piece, he caught folks in contradictions others being less than forthcoming with the truth. We studied the marketing material for PIPS and other ALPR manufacturers and got a really good idea of what was going on, and what the capabilities of this system are. But they denied it, its in the PIA, but it doesnt happen. That was the line and what at one second was personal information wasn't personal the next. In my head I they were Schrödinger's License Plates. If they weren't personal information, then we were entitled to it under FOI, and could happily publish the data for all to see. Have you seen my site? We all got a good laugh, but it was true, if its not PII then its publishable, it it is, then there's rules about how it must be handled. The RCMP either didn't know whether it was PII, or they were up to something. We pressed on.

I truly thought I was going crazy, each discovery was quickly shot down, were they or werent they, personal information or not, approved by privacy commissioners or not? Michael Vonn from BCCLA got it right. The Jell-O met the wall and the team took turns using our heads as hammers.

We eventually got there, and, well, you can just read Robs article and make up your own mind on the evidence and where the program is going in the future, but I don't like where we're headed.

So what do we do. I tried writing letters. Doesn't work. What it took was getting a room of people with diverse backgrounds together to talk about random ideas, bitch about things and get involved. In Victoria BC, we have one every wednesday night and you're welcome to come. We get everyone from the crazy <redacted> lady to local police officers, civil servants and aspiring politicians coming out. There's academics and civil liberatians, inventors and hackers, folks interested in opendata and in journalism. I've never seen anything like it, and I think we can all credit this unique meet-up, held weekly in the old Canada Pacific Lawn Bowling Club as a powerful social innovation tool. Kris Constable has to get the credit for organizing and keeping the ideas meeting alive. If you're not from Victoria, or another community with a meeting already, set up an meeting in your community -- yes, some meetings will suck as you listen to someone eschew the dangers of wireless radition, but there's that chance for a diamond to be found, a new idea, a new set of resources, and it can end in real, positive, change.

Lets hope it has for ALPR

Chris Parsons will be speaking on a panel about ALPR at the Reboot Privacy and Security conference in Victoria BC which happening on February 16 and 17th.


Subscribe to RSS