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.
At a guess, it was built years ago by an agency selected on the basis of anything other than technical competence. As a result it probably has thousands of hard coded HTTP links and an oddly configured out of date web server.
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.
Just a wild guess, but if there are non secure assets in the page, this would result in a browser warning, arguably more suspicious looking than this for average users.
As a quick and dirty workaround they may have done this?
Interestingly, some of the subdomains like https://www.budget.senate.gov/ use the same certificate and do allow you to load their pages with mixed sources. If this was the idea, it was done fairly shoddy.. more than a few sites in the 'Alternative Name' field will still load.
Think of the government as a particular large, stratified enterprise IT shop with some weighty policy/legal requirements driving some of the internal barriers. I'm imagining that it went something like this: the group which owns the public web servers decides to start using HTTPS and slogs through renegotiating their CDN contract, purchasing and installing an EV certificate, etc.
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.
Well, briefly - the General Service Administration declared "By September 30, 2014, agencies needed to update their public networks to Internet Protocol Version 6 (IPv6)"
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.
The US Senate is not an agency. They are a branch of Congress, and therefore definitely not required to do anything a executive agency tells them to do -- especially if it's reasonable like implementing HTTPS.
Yes, the IPv6 is a White House (not GSA) mandate, like https://https.cio.gov. It doesn't apply to the legislative or judicial branches, and in that blog post, GSA is advertising the services it can offer other agencies to help them achieve IPv6 compliance.
And it's OK. This "HTTPS everywhere" concept is damaging. I think it should be revised. The amount of overhead and the lack of ability to optimize encrypted content for transferring over, say, satellite or other radio links, is bad. Lots of people still use very expensive (>$2,000 per Mbps) long-RTT connections that would benefit immensely from content optimization techniques. And most of them are cost-sensitive because they live in developing countries.
Wouldn't that be a whole new level of "premature optimization"? Serve https by default and also http for those still needs it for the reasons you outline.
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!
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.
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.
Optimise for the most common case. I imagine there are far more people in the US with broadband connections being put at risk of MITM attacks than people in Kenya with very slow internet trying to look at the US governments website.
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.
> 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.
As far as I'm concerned, that third parties can change the content of a response mid-air is exactly the reason that you should use HTTPS. If you rely on handing unencrypted data over the internet to a third party provider, you have to accept that other parties may also modify the requests and their responses.
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.
Supporting caching doesn't necessarily mean intermediates can modify the requests/responses mid-air. You can still hash and sign content, and servers can cache these responses.
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 ;)
> benefit immensely from content optimization techniques. And most of them are cost-sensitive because they live in developing countries
You can't optimise the size of encrypted content until you've downloaded it. It could go through a third party on your behalf but then they argue, what's the point in the encryption at all.
Not blocked in the Netherlands, but it opens the https version , which displays the following error:
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.
Clicking the provided link causes a redirect loop(i.e. the http version redirects back to https)
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.
Just tried from Kenya and did not see any "ACCESS DENIED".
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."
That looks like an Akamai error message (yup, www.senate.gov is a CNAME for e483.g.akamaiedge.net). Akamai has a bunch of (frankly ridiculous) heuristics for developing IP blacklists. So likely whatever network you're on got blacklisted for some inscrutable reason.
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.
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.
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)
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.
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.
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...
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.
> 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.
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.
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.
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.
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.
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.
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.
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]
- 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.
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.
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.)
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.
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.
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.
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.
I wondered if there were any senator contact forms etc but I couldn't find any. However, you can use the 'find your senator' drop-down top-right to find a senator's private website contact form. Those I looked at were all unencrypted too.
How strange, I changed it to http as asked. For me it then asked for my social security number to login and then I needed to confirm some of my banking information for the IRS. I'd expect that to be information you'd want to protect!! I actually double checked to make sure I wasn't on a phising site but I was safe: "senate.gov" why did they need my banking information? Oh well.
The above is fiction, but an easy scenario under HTTP. Any AP (wifi access point, like at a cafe) can do it...
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 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.
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).
Somewhat confusingly, pulse.cio.gov lists senate.gov as supporting HTTPS with an 'A' from SSL Labs. While that is of course technically correct, it doesn't tell the full story, since no actual content is served over HTTPS.
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?
Yeah, I'm torn on it. It's clearly not the right information. But one of the benefits of an automated approach is that everyone's being treated equally, and people can't complain about unfair treatment.
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.
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.
128 comments
[ 0.25 ms ] story [ 143 ms ] threadWhat 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.
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.
http://gsablogs.gsa.gov/technology/2014/01/02/1128/
;)
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.
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.
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...
[4]: https://daniel.haxx.se/http2/http2-v1.10.pdf
- 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.
https://citizenlab.org/2015/04/chinas-great-cannon/
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.
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.
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.
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:
https://pulse.cio.gov/https/domains/#q=legislative
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.