Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

US Senate website says use HTTP instead of HTTPS

senate.gov

Post reply on HN
Print view View original

101–110 of 129 posts

Re: US Senate website says use HTTP instead of HTTPS

#101

Post by Buge »

raimille1 wrote: post #24

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.

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/

Re: US Senate website says use HTTP instead of HTTPS

#102

Post by enraged_camel »

reustle wrote: post #77
ketralnis wrote: post #32

Earlier quoted context omitted.

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…

> 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. 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.

Re: US Senate website says use HTTP instead of HTTPS

#103

Post by boomlinde »

Puts wrote: post #76
ketralnis wrote: post #32

Earlier quoted context omitted.

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…

> 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.

Re: US Senate website says use HTTP instead of HTTPS

#104

Post by Buge »

boomlinde wrote: post #99
blackhaz wrote: post #39

Earlier quoted context omitted.

I can save about 30% of traffic by optimizing content via HTTP. Can't do that with HTTPS without MITM or similar questionable practices breaking the purpose of HTTPS. While you're sitting on a 100+ Mbps DSL, somebody in the middle of Africa is struggling on an ISDN-like link.

What exactly are these techniques that work in plain HTTP but not in HTTPS? It seems like the difference between the two does not pertain to the actual content at all, but I am more curious than knowledgeable in this case.

Intermediate nodes can cache http traffic, but not https.

Also intermediate nodes could compress or shrink images or do similar types of things.

Re: US Senate website says use HTTP instead of HTTPS

#105

Post by Buge »

sleepychu wrote: post #44
Ueland wrote: post #16

Earlier quoted context omitted.

Something like gzip that "all" browsers and servers support? Which i would belive more than makes up for any https overhead.

They're proposing lossy compression. That'd be a neat feature though, during the negotiation (once your comms are encrypted) you could ask the server to perform lossy compression on certain resources, would save battery life on the mobile client as well!

That's kind of what mobile sites do. They shrink the size of the site making it simpler and smaller.

Re: US Senate website says use HTTP instead of HTTPS

#106

Post by konklone »

shrikant wrote: post #88
konklone wrote: post #83

Earlier quoted context omitted.

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.)

Re: US Senate website says use HTTP instead of HTTPS

#107

Post by inglor »

mike-cardwell wrote: post #91
formula_ninguna wrote: post #84

Earlier quoted context omitted.

>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.

Re: US Senate website says use HTTP instead of HTTPS

#108

Post by ohitsdom »

mind-blight wrote: post #100

I can't load the senate.gov website with the HTTPS Everywhere browser plugin. The plugin redirects the senate HTTP URL back to the No HTTPS warning. It's easy to get around by going incognito, but this would seriously confuse the average user.

The average user doesn't have the HTTPS Everywhere plugin, and I assume most that do have it installed are used to dealing with this kind of bad configuration.

Re: US Senate website says use HTTP instead of HTTPS

#109

Post by ohitsdom »

jrapdx3 wrote: post #53

Attempted to write to one of my senators. To do so online requires using the web form on the senator's "contact" page. It says only messages from the senator's constituents will be accepted, so it's necessary for the author to share some identifying info. I don't know how much checking is done to assure the writer really is a constituent, probably there's some lookup of street addresses, zip codes, etc. Main point is…

Understood, but the contact link could be maliciously changed through a MITM attack (which would be prevented if the whole domain was accessible through HTTPS).

Re: US Senate website says use HTTP instead of HTTPS

#110

Post by codetaku »

inglor wrote: post #107
mike-cardwell wrote: post #91

Earlier quoted context omitted.

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.

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)
Post reply on HN