Hacker News new | ask | show | jobs
by raimille1 3698 days ago
Excuse the ignorance, but what's the problem if it's purely an informational read only site? There's no logins, prompts, messaging that can be exploited. What's the problem of it being unencrypted?

Don't get me wrong I'm all for https when there's user information to be protected back and forth, I just don't see the applicability for it here.

12 comments

Theoretical, but:

1. MITM to return fraudulent data ("click here to input your personal data to collect your government cheque from this new federal grant!")

2. Recording browsing activity ("gee Mr. Smith, you sure do spend a lot of time looking up laws about X. Seems like a good thing to blackmail you about")

Working those into actual problems is an exercise for the reader, but they're mostly what https is for

There is also the benefit that HTTPS is harder to mass-surveil, and harder for your ISP to play shenanigans like injecting their adverts and tracking headers into the page (https://www.eff.org/deeplinks/2014/11/verizon-x-uidh)

> Recording browsing activity

Yes, let's protect users visiting public available information from all the malicious eavesdroppers, while still posting all page requests to Google analytics...

While protecting visitors' information from malicious eavesdroppers doesn't change the fact that the site they are visiting may willingly be sending such data to a third party, it does prevent malicious eavesdroppers.

There are several levels of trust involved. HTTPS goes a great length to ensure that the link between the client and the server is not compromised. That the service may be malicious itself or unconcerned with privacy is a different problem that you have to solve in some other way. That doesn't make secure connections any less of a problem.

piwik
> Recording browsing activity ("gee Mr. Smith, you sure do spend a lot of time looking up laws about X. Seems like a good thing to blackmail you about")

Are the URLs in an HTTPS request also encrypted? I was under the impression they weren't.

They are. The only thing that could be gathered from an HTTPS connection is the IP, and therefore, possibly the domain.
For all browsers made in the last 10 years, SNI is sent as part of the SSL/TLS handshake, so the hostname of the site you are trying to connect to is included in the ClientHello and is visible to anyone that can monitor the network.
Hostname, but not path.
This is a common and dangerous mistake. The size and timing of requests is visible, as is the hostname. It is straightforward to watch a cafe and identify all the requests corresponding to Wikipedia, and within those the Tienenman Square page.

HTTPS is designed to protect secrets, not privacy. That means short random bitstrings, given that the adversary knows you're passing short random bitstrings---TLS just keeps him from figuring out the actual random content.

They are. Think about the fact that a lot of data exchange occurs via URL parameters (e.g. access tokens), so it would be a huge problem if they weren't also encrypted on HTTPS.
Here's some rationale on why it's worth using HTTPS for everything, even the less sensitive things:

https://https.cio.gov/everything/

A lot of people focus on targeted surveillance of people visiting individual sites, but there are so many other threats and issues out there. Bulk modification of unencrypted traffic is a particularly nasty one, and has been seen in the wild, at scale, multiple times.

A US .gov page recommending the use of HTTPS everywhere, in a thread complaining that another US .gov site recommends using HTTP over HTTPS. I find this hilariously ironic!
The world is a complicated place, and the US government is a highly decentralized organization. (And in the case of the executive and legislative branches, decentralized very much by design.)
If you visit any non-https site, then you leave a vector wide open for a MITM to perform numerous types of attacks. Not just against the unencrypted site you're visiting. They can launch phishing attacks or CSRF attacks or inject malware.

If every site were https, then that would provide a huge boost to peoples privacy and security.

>If you visit any non-https site, then you leave a vector wide open for a MITM to perform numerous types of attacks.

how?

I gave 3 examples. Phishing, malware injection and CSRF. If you want to know how these sorts of attacks work, there isn't enough space in a HN comment so go use a search engine.
Phishing and malware injection are obvious - but how would that give you (any more) leverage to perform CSRF? (since well, the backend validates the token).

XSS for sure (which is probably what you meant by malware injection) and that sort of can enable CSRF if the vulnerability was already there - but I don't think it can cause it.

CSRF is "cross site request forgery". It is an attack. What you are talking about when you start mentioning tokens, is presumably the various methods of mitigation that a number of websites use to defend against that particular attack.

A MITM can initiate a CSRF attack, because they can add arbitrary code to the page. Whether or not the target site has protection, and whether or not the attack is successfull, does not change the fact that a MITM can launch one. Sites still need to protect against CSRF because there are other methods of launching them, but nontheless, if all sites were HTTPS and HTTP didn't exist, then that would defend you against a MITM on an untrusted network launching one.

I didn't mean XSS when I said malware injection. I didn't mention XSS and I didn't intend to.

If you can select a handful of sensitive-information websites that use https but not frame-busting to make invisible iframes to and then just check which ones are already authenticated, you can do any number of things. Because any MITM attacker basically controls your browser. (I imagine some browsers have built-in defenses for this at this point--I haven't looked into this attack in a while. But defenses definitely aren't guaranteed by HTTPS)
it's fairly common for an ISP to inject popups into web traffic (or redirect your dns)
by the way, is it legal? how do they explain that?
In which country, in which jurisdiction, according to which lawyer?
Why is most of your mail sent in envelopes as opposed to on postcards? Why don't people default to postcards, and only use envelopes when they have something to hide?

This isn't about traffic analysis, it's about social expectations and social norms. If privacy is the default, the social norm is to be private, and to expect privacy. That's important.

True, and this has a legal implication too. If privacy while browsing the Web isn't expected, then law enforcement doesn't need a warrant to ask for this data. So let's maintain our expectation of privacy.
Commercial mass mail for informing isn't sent in envelopes. I presume that's what the parent was talking about.
It isn't? At least in Germany, commerical mass mail is always sent out in envelopes.

I guess that, in this particular case, the reason for the envelopes is to conceal the ads inside them until the recipient has taken the time to open the envelope.

In the USA, most commercial mass advertising mail is in large printed flyer form, not enclosed in any kind of external envelope.

Kinda like this:

http://thumbs.dreamstime.com/z/sale-advertising-papers-15592...

The advertisers pay bulk rates to USPS to stuff all this crap directly in our mailboxes.

There are some exceptions which arrive in envelopes, mostly to trick you into thinking it isn't just spam mail like the rest of the crap.

Yep, same here. We do have an option to place a special sticker on the mailbox, which indicates to the postal worker that he doesn't put that kind of bulk commercial material inside.
Well this ain't the norm here (a little bit south from you, still EU). Perhaps it has to do with Germany being always more vary of privacy for history reasons, but is merely a EU recommendation, not enforced by law.

Not targeted for your reply, just clarifying the previous post: I don't appreciate the down votes though, I wasn't stating that OP opinion is right, it was just my understanding of what he meant and trying to understand it.

Since it's a .gov domain, people can assume that everything on it is published by the US government. Nobody else can register a .gov domain. So a MITM injecting ads or changing the content would be worse than for a .com site.
- Nearly every "informational only" website will end up with feature creep moving it out of that

- Simply not having SSL setup is one thing. But the linked page has, not only a valid SSL certificate, but someone went through the awful process of acquiring an EV certificate. To go through that, and then choose to not use it, boggles the mind

EV isn't that difficult to acquire, only more expensive. Not a huge deal when working with other people's money. What boggles the mind is that the US Senate is using a commercial CA for their website.
Would you be OK with your browser trusting a US government managed CA in its default trust list?
Sure - why not. They already manage my water supply.
Apart from the issue with MITM attacks, they will be forever stuck on HTTP version 1 due to the fact that hardly any web-server or browser vendor plans on implementing HTTP2 without HTTPS. plain HTTP is in the spec, but it seems to be that most vendors are deliberately leaving it out (something I agree with).

From the IETF HTTP WG FAQ:

>"Does HTTP/2 require encryption? No. After extensive discussion, the Working Group did not have consensus to require the use of encryption (e.g., TLS) for the new protocol.

However, some implementations have stated that they will only support HTTP/2 when it is used over an encrypted connection, and currently no browser supports HTTP/2 unencrypted."[1]

From Wikipedia:

> "Although the standard itself does not require usage of encryption, most client implementations (Firefox, Chrome, Safari, Opera, IE, Edge) have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory."[2]

From NGINX:

> "Using HTTP/2 is likely to improve website performance if you’re using SSL/TLS (referred to as TLS from here on). But if you have not, you’ll need to add TLS support before you can use HTTP/2"[3]

From Daniel Stenberg:

>"Reasons for choosing TLS-only include respect for user's privacy and early measurements showing that new protocols have a higher success rate when done with TLS. This because of the widespread assumption that anything that goes over port 80 is HTTP 1.1 makes some middle-boxes interfere and destroy traffic when instead other protocols are communicated there."[4]

[1]: http://http2.github.io/faq/#does-http2-require-encryption

[2]: https://en.wikipedia.org/wiki/HTTP/2#Encryption

[3]: https://www.nginx.com/blog/7-tips-for-faster-http2-performan...

[4]: https://daniel.haxx.se/http2/http2-v1.10.pdf

You could do a MITM attack and change a Senator's email address to spy@russia.com. Ok it's a long shot, but not being able to serve your site over https is also a flag that your technical configuration has problems.
Not even that they're unable, there's a valid certificate & they're deliberately not using it for the site.
No reason for it not to. And certainly I could find some fun uses of changing information for visitors to a .gov site.
When sites don't use https, China MITMs the page, and inserts malicious javascript that enters the user's browser into a botnet that launches a DDOS attack on the github pages of human rights organizations, causing github downtime.

If you don't want your website viewers to be entered into a botnet, then use https.

https://citizenlab.org/2015/04/chinas-great-cannon/

Good point. Although some people might say that that isn't something they need to protect their website users against, because Quantum Insert is targeted only against very specific users such as terrorists. The Great Cannon targets all internet users indiscriminately, so website owners are more likely to sympathize with them and want to protect them.
LOL you didn't see the talk by Jacob Applebaum did you? They do this en masse to everyone they possibly can. https://www.youtube.com/watch?v=vILAlhwUgIU
That doesn't really give an example of them injecting malware into the http traffic of an innocent user.

With the Great Cannon, not only did they inject malware into the traffic of an innocent user, they injected malware into the traffic of all innocent users whose traffic went through certain Great Firewall routers.

I've used this example several times when talking to website owners who think they don't need https. My goal is to provide a specific example of how their website visitors are being attacked. With the apparently targeted attacks of Quantum Insert, the website owners could convince themselves that only terrorists are targeted, and that thus they don't need to bother protecting anyone. With the completely untargeted Great Cannon attacks, I hope to prove to them that their website visitors are actual innocent victims.

Several people have already mentioned the risks of MITM on a .gov domain. In this case, I think it goes beyond the usual risk of injecting malware / etc. on a trustworthy domain because it'd make an interesting watering hole attack because some of the visitors to senate.gov are going to be people with interesting information or access both on their computers and via their social networks.

Imagine if, say, a foreign intelligence agency managed to compromise some routers, do some DNS poisoning, etc. in the DC area and, being professionals, instead of injecting adware they inject a quiet zero-day which scrapes network info, contacts, etc. and reports home. Some of that will be political junkies, kids working on school reports, etc. but I'm sure you'd also get access to clients at a bunch of interesting agencies, NGOs, etc. which would be helpful for more targeted attacks.

I saw an answer to this type of question like: why bother requesting something (even plaintext) over the wire if you can't vouch that it's the content you wanted, from the person you expected.