US Senate website says use HTTP instead of HTTPS
senate.gov
senate.gov
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.
If every site were https, then that would provide a huge boost to peoples privacy and security.
how?
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.
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.
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)
Yes, let's protect users visiting public available information from all the malicious eavesdroppers, while still posting all page requests to Google analytics...
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.
Are the URLs in an HTTPS request also encrypted? I was under the impression they weren't.
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.
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.
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.
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.
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.
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...
- 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
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.
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.
If you don't want your website viewers to be entered into a botnet, then use https.
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.
so what would happen if a traveling american wants to access it?
edit: FYI I'm trying from Kenya. edit2: Using my phone I'm able to switch between wifi, and mobile and on mobile it is unblocked. hmmm
Also for those who don't see the Access Denied page but are curious, here is what it reads in full.
--------------------
Access Denied
You don't have permission to access "http://serve-403-www.senate.gov/" on this server. Reference #xx.xxxxxxxx.xxxxxxxxxx.xxxxxxxx
---------------------
It seems it has little to do with geography. It's an IP thing.
Clicking the provided link causes a redirect loop(i.e. the http version redirects back to https)
Disabling HTTPS-Everywhere fixed that for me.
Which country are you in? now i'm curious? China?!
and also I accessed the site from the US (tunnel ;-) and it was unblocked, and then I saw the redirect to http.
The submitted https request was not able to be completed at this time. Please retry your request using http. This may require disabling some browser based plug-ins.
This is what I am seeing: "Request unable to be completed. The submitted https request was not able to be completed at this time. Please retry your request using http. This may require disabling some browser based plug-ins."
Maybe something to do with your browser?
Edit: typo.
The above is fiction, but an easy scenario under HTTP. Any AP (wifi access point, like at a cafe) can do it...
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 that the senator's contact page does use https. This is appropriate given that personal info is shared per the contact form. I don't think any other senate pages accept input, so maybe their reasoning is that http vs. https is less critical on other parts of the site.
There is an exception process, but Akamai already supports IPv6 (though they do charge extra for it, booo!). You'd like to think something as high visibility (PR, not web traffic) as senate.gov would comply with the GSA.
I suspect they haven't caught up with the mandate.
Though the GSA's HTTPS adoption dashboard does include legislative branch domains, including senate.gov:
Would it be worth trying to update pulse.cio.gov to detect cases like this? That's non-trivial to do in a reliable automated fashion, but seems like it might be worth the effort?
In the case of the Senate, their current configuration prevents them from using HSTS or enforcing HTTPS, so the other columns will still show as lacking.
It's quite refreshing to not have that initial half-second or so lag that you get when loading an https page.
Hopefully we'll make back some of the difference once http/2 is more widespread.
HN, for example, loads in less than half a second, due to using a CDN (i.e. Cloudflare).
With CDNs, the RTTs are small enough to not matter.
What are the situations which might prompt a developer to make their users use http instead of https?
Tracking detailed referrer information from social media, etc. I don't agree with this goal, but it is something that's very important to people running sites with significant social traffic.
Mind you, I don't know if that's the case here; it certainly doesn't seem like caching should be a large priority for this sort of content.
Given the 'encryption is only used by terrorists' climate, spending the time and money to make it work for https sounds like a hard sell.
No sources, but I have done some work in UK public sector and that kind of story would match.
Isn't it a tad paranoid?
As they go through compatibility testing, someone finds a problem. Maybe that's a bunch of legacy HTML which triggers mixed-content warnings, maybe that's a problem with some creaky old legacy application which expects HTTP and doesn't follow redirects or chokes on modern cipher suites, etc.
Since they can no longer say that switching won't break anything, someone pauses the project until they can fix the problems. Maybe someone suggests using a rewriting proxy to fix it but the people who own the server it'd need to run on are worried about performance/security. Maybe the legacy app is something licensed from a vendor who wants $$$ for a major upgrade rather than just making this one change. Maybe that requires a change in next year's budget because they've already allocated all of the money they're legally allowed to spend on that class of work.
It could be as simple as budget: they're using Akamai and it's likely that the contract they originally signed didn't include HTTPS, and at least in the past adding it was a non-trivial price increase. I could easily believe that this could be as simple as either a test pending a new contract or that a section of the website (or a subdomain) uses HTTPS but they added a general redirect to avoid paying the higher HTTPS rates for traffic which doesn't require it.
;)
In my consistent experience over 5+ years, https always performs worse on poor-quality mobile connections here in the UK. In rural areas with EDGE or poor 3G, a given site will simply not load over https but it will (slowly) over http.
So the trade-off for me is between "senate.gov doesn't load, at all" and "senate.gov does load, but may leak the information to someone that I was looking at senate.gov, or may potentially be MITMed to give me misleading information about the US senate".
The balance of probabilities is such that the trade-off of enforced HTTPS everywhere, on sites like that, is _not_ worth it for me. I obviously don't object to people using HTTPS who want to. Nor do I object to sites where a MITM attack would be catastrophic (e.g. banks) requiring it. What I object to is that, where there's a balance-of-probabilities decision, I am increasingly no longer empowered to take that decision for myself, and the result is that I simply can't view many websites in particular circumstances.
Throwaway because being anything other than 100% supportive of HTTPS is the surest way to burn karma on HN.
Also intermediate nodes could compress or shrink images or do similar types of things.
And we come back a full circle. Even if the image is not sensitive, I'm glad I can force https to workaround my ISP being "helpful" and shrinking images.
You may think that it isn't a big deal because you aren't serving sensitive information, but if your users are dropping in from a random hotspot or are in one of the countries where ISPs seem to be able to do whatever the hell they want, there are tons of possible intrusions, ranging from inserting ads or replacing the entire response with a gentle reminder to pay your internet bill, to inserting outright malicious software.
It's like leaving your front door unlocked just for the convenience of being able to walk inside without unlocking it.
Nonetheless, that approach seems to be a way of the past. HTTPS is essentially expected now, so CDNs are required to achieve similar performance - Great news for CDNs ;)
https is the least of your worries in terms of overhead.
That said, if making the site very low bandwidth were the goal I would start by removing the pointless images.