Consider an election web site that will be used for voting over the Internet. What steps should the administrator of such a web site take to provide adequate security against man-in-the-middle attacks and spoofed web sites? Can anyone suggest a checklist of top-priority items that should not be overlooked? Assuming that the answer involves SSL, how should the site be using SSL and how should SSL be configured?

Motivation: Recently, some technical details about Halifax's use of web-based voting in the 2012 elections surfaced. Based upon the publicly available information, it appears that they fell short of accepted practices for SSL configuration. But what should they have done? What should folks deploying web-based Internet voting make sure not to overlook, to defend against man-in-the-middle attacks and spoofing attacks? How should they have configured SSL?

I'd prefer this to be a narrowly-scoped question that's limited to SSL configuration, MITM attacks, and spoofing attacks: other issues related to e-voting security (such as client-side malware, insider threats, voter authentication, etc.) are out of scope.

  • D.W. are there not some issues the security community should avoid backing to include putting government elections on the internet? Peter G. Neumann of SRI and friends have done outstanding work for more that a decade to present the risks of such changes to our voting system (csl.sri.com/users/neumann/treasures-pgn.pdf). It appears to be provable that no technical solution exists to overcome the forces motivated to defeat such a system.
    – zedman9991
    Jun 28, 2013 at 12:11

2 Answers 2

  • Use SSL sitewide. Enable SSL (https). Make sure that any attempt to connect via http immediately redirects to the SSL site.

  • Follow accepted best practices. Refer to SSL/TLS Deployment Best Practices from SSL Labs. Follow all of the advice there, including use of using SSL for all site traffic, marking all cookies as secure, avoiding mixed content, enabling HSTS, and other recommendations.

  • Avoid third-party scripts. Avoid third-party script (i.e., any Javascript downloaded from any other domain). Avoid trusting any other sites or domains. For instance, don't use third-party widgets or analytics; don't use ads; host all Javascript locally, on your own server. They present an element of risk, and an elections context that sort of risk is probably unnecessary and undesirable.

  • Buy an EV cert. Spend the extra amount to get an extended validation (EV) certificate. This will provide users with an extra level of assurance.

  • Use pre-loaded HSTS and public key pinning. Register your domain with Google Chrome and Firefox, to request to add your domain to Google's and Mozilla's pre-loaded HSTS list. This helps defend against SSL stripping and man-in-the-middle attacks, even for users who have never visited your domain before (and thus haven't had a chance to receive the initial HSTS information from your domain). Enable pre-loaded public key pinning with them, as well, if you can.

  • Use forward-secure ciphersuites. Configure SSL on your web server to enable forward secrecy for all clients that support the corresponding ciphersuites. See Deploying forward secrecy from SSL Labs for details on how to do this. Generally speaking, you'll set the order of preferred ciphersuites on the server so that ECDHE is your first choice of ciphersuite; DHE is your second choice; and standard (non-forward-secure) ciphersuites are lower priorities. Forward secrecy helps protect the confidentiality of all earlier communications (including voters' votes) if the server's private key is compromised after the election, which seems helpful in an elections context.

  • Support TLS 1.2. Make sure you support the latest versions of TLS, for voters with browsers that support those versions. The latest versions of TLS are not yet supported by all browsers, but they add defenses against some recent attacks on SSL.

  • Check your site. After deployment, check your SSL configuration using the SSL checker at SSL Pulse (provided by SSL Labs). Make sure you have a grade of A. Fix any issues that the SSL checker spots.

  • Advertise the https URL. When you communicate with voters to tell them what web page to visit to vote, list the full https: URL. For instance, tell voters to enter https://www.elections.us into their browser, not http://www.elections.us or www.elections.us (the last two are treated identically by browsers, and may be vulnerable to MITM attacks).


The root of a MITM attack against a voting system is that an adversary my submit fraudulent votes or observe the votes of a victim. Implementing HTTPS properly helps with some of these concerns, but HTTPS is not the biggest concern. Common vulnerabilities CSRF, Clickjacking, and XSS could all be used to influence a vote regardless of the use of HTTPS. One way of thinking about clickjacking is that it is a MITM attack of the user interface. Further more, HTTPS does not verify that the election wasn't manipulated by a government or another insider threat.

Homomophic Encryption can be used to construct verifiable elections. Helios Voting is a good example of cryptographically secure election system. In this case, even if an attacker had exploited a vulnerability in the implementation of the election system, such manipulation could be detected.

  • 1
    Excellent points to remember. Thank you for reminding us of the broader context as well.
    – D.W.
    Jun 27, 2013 at 23:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .