Hacker News Reader

Comment by olivierlacan | Hacker News Reader

The very fact that an organization like the Nieman Foundation can publish something like this article without first having the good sense of enabling required TLS on their website is frighteningly careless.

Anyone from governmental agencies who read this article at home or work can now fairly easily be targeted by the relevant surveillance agencies.

View on HN

They're also leaving themselves open to MITM attacks, where an attacker could change all of the tor addresses.

Even SSL sites are not immune. On corporate networks, the clients trust the company cert, which is used to proxy all traffic (including HSTS and HPKP/pinned sites) for filtering/logging.

If you don't trust the machine you're currently on then it's already game over from a security perspective.

Isn't the actual content of the page signed by the the site's certificate though? And they can't just serve a different certificate because your browser can tell whether or not it was issued by a trusted CA. How does the attack work in this case?

Edit: Nevermind — I assume you're referring to this scenario[1], in which the company installs a root certificate onto your actual computer that allows them to sign certificates for other sites.

[1] http://security.stackexchange.com/a/63306

A lot of corporate computers have at least an additional CA authority on each computer that they use... if you're using a corporate computer, it's really easy for them to MITM any request, just relaying requests to the public resource, then proxying and using their CA signed cert in the proxy.

From there, everything can be tracked.

If you have a corporate computer, you shouldn't rely on any expectation of privacy. There's nothing stopping them from installing other monitoring software—screen grabbers, keyloggers, etc.—whenever they please.

That's where something like Tails comes in handy. :)

I don't think Tails would work because a corporate proxy would likely block any outgoing connections. Also most corporate IT policies would probably disallow running something like Tails.

That's working. If it fails secure it's keeping you alive.

Monitoring hardware, then.

(SecureDrop developer here) That's why we created https://securedrop.org/directory (HTTPS, HSTS, preloaded, .onion available, etc.). Use that instead! Also, we have strong recommendations for the news organization's "landing pages" (e.g. https://theintercept.com/securedrop/), including requiring HTTPS, to prevent this and other obvious security issues.

This a shameless plug?

At least he was upfront about it by putting a disclosure in parenthesis.

But why would they bother. The point of collecting data for surveillance is to provide signals that help sort the real threats from the noise. But the Nieman Foundation is such a well-known and widely-read blog that just reading an article there is not at all noteworthy, regardless of the subject.

Most government employees are not even in a position to access leakable data even they wanted to. Targeting them based on reading an article would be a waste of effort.

If you're at work at a place where reporters would give a hoot about what you have to say, most likely your TLS sessions are intercepted at the proxy.

It's less common for companies to have content inspection.

All the SSL MitM products I've seen can do content inspection. Not yet for freeform text though who knows...

I'm confused, what would TLS do? The surveillance agencies can log an HTTPS URL as easily as an HTTP URL, they don't need to see the contents to see that you requested it.

They can log the domain you connected to, not the URL you visited

Although with most TLS implementations they will see the size of your transfers, thus still giving away which URL you visited....

Idea: HTTP server module that appends a minimal amount of hidden random garbage data (as a comment or similar) to each response so no two responses have the same fingerprint.

user btown answered that elsewhere here in this thread: "https://github.com/technion/mod_randpad (an Nginx module that injects padding as a comment into returned HTML documents) is likely the correct layer to add random padding; the performance hit would be negligible."

If this is the first (and only) time someone visited the domain around the time of a leak, it may be a little suspicious.

Then use public WiFi.

If they can't see the contents, they also can't see the URL -- both are encrypted.

No, HTTPS URLs are not logged in plain text as they are in HTTP. So it does make an important difference.

See: http://security.stackexchange.com/a/2916/50175

If you mean "logging" as in web server logs, then it completely depends on the configuration of the server and there is nothing the client can do about it..

If you mean "transferring over the network", then yes, HTTPS only shows the server you are connecting to, but not the specific URL.

Then again, that can be deduced from the transfer sizes that are still shown.

Not true.

HTTPS encrypts the URL as well as the content of the communication. Someone surveilling the conversation with the ability to observe all network traffic but without the ability to decrypt SSL traffic would be able to tell that the end user had viewed something at a particular website (technically, at a particular server), but would NOT be able to tell WHICH article was viewed.

I wonder how much that actually gains for this specific case ("which article did IP $x view?"). With more effort, it should be fairly easy to match the traffic pattern to the article, e.g. by matching the size of subsequent requests for the images. But more complicated than a simple filter that just grabs all URLs from HTTP.

> With more effort

That's the new key point for 2017 pro-privacy architectures.

Proof of work surveillance doesn't scale because requiring it leverages the disparity between the total level of Internet traffic and intelligence agency resources.

Kill the dragnets as step 1, then worry about step 2.

It would be helpful to have a website to display a random image of differing sizes for every page load. This would prevent fingerprinting https.

Um, I don't believe that would help. You either inline the images as data, or better, get rid of all images and have random length non-printing text to hide the real data. This kills caching and performance though.

https://github.com/technion/mod_randpad (an Nginx module that injects padding as a comment into returned HTML documents) is likely the correct layer to add random padding; the performance hit would be negligible.

SD dev here. You might be interested to check out https://github.com/freedomofpress/fingerprint-securedrop (note: still in experimental stages). We're going to be using the framework/ ML pipeline to evaluate server-side defenses (e.g., https://petsymposium.org/2017/papers/issue2/paper54-2017-2-s...), and are also working w/ Tor dev Mike Perry who is working on a solution or set of solutions to the problems of website & circuit fingerprinting with regards to Tor at the protocol level.

Edit: What Mike is trying to implement is based on https://arxiv.org/pdf/1512.00524.pdf.

Could you as the host send out random extra bytes that make it hard to match up?

> but would NOT be able to tell WHICH article was viewed.

What about inspecting traffic pattern? I suspect that each article has different size.

I noticed some sites use a subdomain for securedrop. Does that reveal that they're visiting the securedrop page, or not?

> Does that reveal that they're visiting the securedrop page, or not?

Potentially, if they're using TLS/SSL with SNI.

Just as true if they're using the real domain with a dedicated IP, right?

Nope, if they're not using SNI, you'd just see the IP address. Fire up Wireshark some time when you're browsing and watch what comes through.

> Nope, if they're not using SNI, you'd just see the IP address.

but that's my point... if you're not using SNI, there's only one SSL server on that IP address, and if reverse-DNS fails you, you can connect on port 443 and ask it for its certificate and it will give it to you...

Yes, both through DNS requests (although one maybe could somewhat mitigate that by having each visit to the main domain trigger requests to the subdomain, a) creating traffic and b) putting it in peoples' DNS caches) and HTTPS (All modern browsers include the domain via SNI).

It still might be a better choice, given that the main domain for many sites goes through CDNs and more complex systems in general, increasing the risk of compromise there (which also would expose network details about the submitter, and possibly even more)? A dedicated securedrop site hopefully has dedicated infrastructure and better security.

> at a particular website (technically, at a particular server)

You got it right the first time around, the parenthetical correction is wrong. The SNI is transmitted in plain text during the TLS handshake.

I have a palo alto networks firewall with URL filtering.I can observe destination URL's on https sites without performing SSL decryption. please see eff website showing certain information that can be observed by onlookers[0] when you are using Tor or HTTPS or both

https encrypts the contents... not things like source/destination often only a destination IP address is required to get URL categories for many Proxy/URL filtering technologies.

[0] https://www.eff.org/pages/tor-and-https

If you go to https://example.com/some/directory?param=something, the firewall will only see a request to https://example.com. Everything else is encrypted. In this case, with SSL, a government agency not doing a MITM will only see https://www.niemanlab.org, and http://www.niemanlab.org/2017/01/how-easy-is-it-to-securely-... if they were doing a MITM.

You are confusing URLs with Domains. The only plaintext part of an SSL connection is the SNI, which is the domain.

Ok, so they'd only know that you visited a domain like this at a given time?

securedrop.ap.org

That still gives away a lot, many of these secure drop sites are on a subdomain.

It's worse than just knowing the URL. HTTP pages can be altered without your knowledge by a malicious third party: http://security.stackexchange.com/a/72661

So a surveillance agency could e.g. replace the URLs for the various organizations' leaks landing pages and Tor addresses with phishing pages, and anyone who used them would upload documents directly to the agency.

Reply on news.ycombinator.com