Securing whistleblowers

Kategorier: Dev,English-articles,Journalistikk,Media,Open Source,Sikkerhet,Utvikling & Webutvikling

Thanks to the Tor network, sources wary of surveillance may get in touch with NRK anonymously. By using our SecureDrop whistleblower service, people can contact us without being easily traced by a third party.

The service allows a source to submit encrypted files and messages to the news room without disclosing her real IP address. Identifying Tor users is considered intractable from a technical stance. Still, there are caveats that whistleblowers can fall into if one fails to pay attention to security measures at either end of the line.

No breadcrumbs to follow

A recent saying states that if you kill someone, don’t google how to do it first. Regardless of how safe you feel using the Tor network: If the server logs show that you sought information about NRK’s SecureDrop portal prior to a major leak, it will certainly put you on your adversary’s short list.

Since SecureDrop is a so-called hidden service, it can only be reached over the Tor network. We cannot take for granted that people know how to do that. Therefore, we obviously need to publish some information on a regular web page as well to describe how to go about it.

Our landing page is where people find instructions on how to use the SecureDrop portal. Securing this page is just as crucial as securing the SecureDrop service itself. That’s why Freedom of the Press Foundation, who maintains the SecureDrop project, have published comprehensive guidelines on how to arm and protect the landing page.

The most important step is to use encryption. The landing page must be served over an HTTPS (TLS encrypted) connection only.

Furthermore, the landing page is served directly from our load balancer, thus bypassing most of’s internal infrastructure. Additionally, server logging is disabled for this page in particular, so anyone wanting statistics and traffic graphs for the landing page is out of luck. Such data isn’t retained. We simply don’t know who, when or how many.

One among the few is easily spotted

We’re still not safe. If the landing page happened to be one of a few selected TLS encrypted sub pages under the domain, our landing page visitors could be given away by the mere fact that their service provider registers established HTTPS connections. To suspicious minds, the presence of a log entry for an HTTPS request to could alone be enough to assume a landing page visit.

Fortunately, most of moved to TLS during this summer. Besides being the single most important change we could make in order to secure our users in general, this change also helps us protect SecureDrop users. In effect, NRK’s overall transition to HTTPS cloaks arbitrary visits to the landing page and makes them indistinguishable from millions of unrelated server requests. Landing page visitors are literally hiding in the crowd, giving log file snoopers a hard time trying to tell whistleblowers apart from the lot.

This is also the reason why we didn’t put our landing page on a separate subdomain. While it certainly would have made some things easier technically; using «» would be a very, very bad idea. DNS lookups are unencrypted. Anyone with access to your network or the server logs would then have seen what you’re up to.

The next thing to worry about is security headers. The HTTP/HTTPS protocol allows for special directives detailing how browsers should behave. These directives are crucial in order to enforce a given level of security for the landing page. The web server may, for example, tell the client never to accept content from other domains when processing the landing page. Another example is instructing the browser always to use HTTPS on future connections to that domain.

Some of these rules are memorized by the browser between sessions. If a conflict arises on the next visit to the same page, i.e. something changed and the content becomes at variance with a previously declared policy, the user will see a very explicit notification that something went awry, and that the page can no longer be trusted.

Almost, but not entirely

Security headers severely limit the attack vector for so-called «man-in-the-middle» exploits. For example, a maliciously designed javascript block injected somewhere on the page could give whistleblowers away by «phoning home» to the man-in-the-middle whenever a user visits the landing page.

Even though a well-configured TLS connection provides fair protection against these kinds of attacks, a correctly configured set of server headers makes this even harder to accomplish. Effectively, if an attacker finds a way to alter the page contents somewhere between the end points, security headers enforce an additional check point on the client side that ultimately blocks such attempts.

We have tightened the rules as much as possible when it comes to security headers for the landing page. Unfortunately, there are still problematic areas that gives us no other choice than to leave some nuts and bolts looser than they frankly ought to be, at least in order to give top score on validation services like

We’ve omitted the Strict Transport Security header. If in place, this header instructs your browser never to accept anything but secure connections to Since we haven’t moved every bit of to HTTPS quite yet, this header would block some of the old but legitimate services on that still relies on plain HTTP. That would be unacceptable, so we’ll just have to wait a bit for that part. Hopefully, this situation will change in near future.

Tamper protection

To top it all off, we implemented a solution to sign the HTML content of the landing page with a PGP key, hence adding an additional layer of security. This precaution makes it even harder for someone trying change the landing page content. Should the web server ever be compromised, its intruders will still be out of luck trying to serve an alternate landing page. The GPG signature will break, and we will get alerted. Scripts are in place on external servers that frequently check the landing page signature.

We created a custom script for preparing and signing the page. The idea is to compile all resources into one HTML file, including web fonts and imagery. Binary files are base64 encoded into the source file. This way, everything gets signed – even the pixels in the images.

The script is called pagesign, and it is published as an open-source project on GitHub.

The members of NRK’s SecureDrop team are immediately notified if a bad signature is encountered. Furthermore, advanced users are encouraged to check the signature themselves by following the guidelines given on the landing page. People running OS X or Linux can first import the public part of our SecureDrop landing page signing key:

gpg --recv-key "D200 5ADD B4CA A347 D2F3 C8D9 E62B D775 8C5A 23AA"

and then execute the following command in the terminal window to verify the page:

curl -L | gpg > /dev/null

Which will look something like this when executed:


Still, no cigar

There’s one big gotcha here. Even if everything between the opening and closing <HTML> tags are signed, malicious javascript code can still find its way into the DOM and alter everything without breaking the signature(!).

Due to some crazy decision made by browser vendors, <SCRIPT> blocks that are prepended or appended outside the document (i.e. outside the signed block in our case) will still get executed just as if it was part of the DOM document! For example, if someone manages to add a javascript block right after the closing </HTML> element, that code will be inserted into the DOM and happily executed by your beloved browser.

Therefore, besides verifying the signature of the page, it is paramount for anyone wanting to check the validity of the page to also inspect the source code and make absolutely sure that nothing has been added outside the root element.

If you take a closer look at the landing page’s source code, you will find a comment block on top that among other things contains a couple of parameters:

File length: 904196
Prologue: 3a12123953975bb2447c7ca25b2f6cb5aba4f760a9159e6cc3b2943403fd866d
Epilogue: 5d5b9de6d9b95f3e0c950afe742a5bb39cb25f6e6e886c10603310b7bf3cba35

These three parameters hint about what to be expected outside the signed block. The values themselves reside within the signed block and cannot be altered without breaking the signature. While File length is the exact size of the entire file, the Prologue and Epilogue values are SHA256 hashes of the content to be found before and after the signed block, respectively. The aforementioned validation script makes use of these values to determine that nothing has been altered outside the PGP signed block.

4 kommentarer

  1. Another pattern that may tie an IP address to a drop, is a download of tor software shortly after visiting nrk.

    As stated in the article, DNS is plaintext. Also destination IP address is visible as well as the hostname in the TLS connection (SNI).

    In addition, malicious CA-signed certs are routinely issued with intent or by accident or generated after intrusion.

    Lastly, there is stille lots of user training to be done. In my opinion, users will eventually need to learn security of they are going to be doing risky stuff. E.g. people need to learn the implications of bypassing TLS-warnings. Hopefully browsers will not allow this in the future.

    Svar på denne kommentaren

  2. Bruker Linux og curl commandoen virker ikke:
    ~/ curl -L | gpg > /dev/null
    % Total % Received % Xferd Average Speed Time
    Dload Upload Total
    0 0 0 0 0 0 0 0 –:–:–
    100 883k 100 883k 0 0 988k 0 –:–:–
    gpg: Signatur opprettet sø. 17. juli 2016 kl. 23.40 +02
    gpg: bruker RSA nøkkel E62BD7758C5A23AA
    gpg: Klarte ikke å kontrollere signatur: No public key

    Svar på denne kommentaren

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *. Les vår personvernserklæring for informasjon om hvilke data vi lagrer om deg som kommenterer.