Until there's a free, easy, maintainable, and actually existent solution to SSL certs, enforcing HTTPS-only is just downright extortion.<p>Referring to solutions that are under construction doesn't cut it. If you're that passionate about it, contribute to the SSL cert solution yourself instead of to the endless calls for HTTPS-only.<p>The 'Semantic Web' movement promises that if everyone would just publish their websites in XHTML with RDF annotations, we'd magically achieve world peace and end hunger. (I exaggerate slightly.) Should we ban non-semantic websites?<p>Physical snailmail and the spoken word are unencrypted. Both are frequently used to transfer data more sensitive than cat pics. If I'm surfing a website in a coffee shop, yes, there's a danger someone could intercept the data to spy on me. But they could just as well look over my shoulder, and HTTPS-everywhere isn't gonna do anything about that.
This is interesting.<p>I've always been okay with dropping HTTP for HTTPS-only as a long-term goal, <i>as long as we get rid of the SSL cert racket first</i>.<p>As far as MITM and identity go, could we at least modify the protocol to allow fingerprint caching, as opposed to certs, as a fallback? ...SSH does this and it is arguably more important to secure than HTTPS.<p>Fingerprint caching seems insecure when you think about it, yet we're all okay with maintaining our servers with this in place.<p>Furthermore, X.509/ASN.1 is the worst thing to happen, ever. I know this because I damn near tore my hair out trying to implement an x.509 certificate validation.
This seems to make two wrong assumptions:<p>1. HTTPS does not only guarantee that data is secret, it also guarantees that data is not manipulated. And in this sense scientific data is very sensitive - it matters that you know your data is the correct data.<p>2. As so many do, it vastly exaggerates the performance costs of HTTPS. They are really minimal. If you really care I suggest you benchmark before you make any claims regarding your servers can't handle it.
> <i>The effect on those without computers at home</i><p>The additional bandwidth is not really that big. Yes, you cannot cache the big news-papers etc. when everything is https, but I think most stuff people do nowadays is things that's not cache-friendly anyway (like your private e-mail, facebook etc.). If they are afraid of some people using all the bandwidth because they cannot block youtube, netflix etc., they can can divide the traffic in better ways, limiting each client.<p>> <i>Restricting the use of HTTP will require changing a number of scientific analysis tools.</i><p>A non-argument. One cannot let things remain the same for ages just because of backwards compatibility.<p>> <i>HTTPS is not a security improvement for the hosts.</i><p>So what?<p>> <i>HTTPS is frequently implemented improperly</i><p>Non-argument. Https not being perfect doesn't mean it's useless.<p>I'm not necessarily saying https-everywhere is a good idea, just that these arguments adds nothing to the discussion.
I'm aware that there is a proposed service to simplify the acquisition of SSL certificates for websites but at this point getting SSL and HTTPS ready is both a costly and complex exercise for many webmasters. Managing several websites for generally small audiences (1000-5000 people) and with limited revenue to pay the costs associated with getting a cert makes me reluctant to support an outright ban on the use of plain HTTP especially when the content is not of a personal or indeed personally identifiable nature. How does the proposal address the ease of access to certificates and the current state of affairs in certifying authorities?
> In summary: Non-sensitive web traffic does exist.<p>A million times this. I cannot believe that the current HTTPS-nazis totally fail to see something this obvious.<p>There's countless use-cases where plain HTTP is not only OK, but probably the simplest and best option.<p>Trying to ban it to address some vague possibly-maybe security-related theoretical issues seems asinine.
> "HTTP has become the de facto standard in sharing scientific data. [...] HTTPS would cause an undue strain on limited resources that have become even more constrained over the past few years.<p>Interesting that this keeps coming up. I saw the same thing at the top of the comments on the Python 2/3 article here yesterday [1] That academia is full of people trying to do technical things and doing them poorly, so everyone else should hold back progress because they're barely managing as-is, with no engineering training or staffing, if you change anything it's all coming down.<p>Why is this a problem with Python or HTTPs and not a problem with the priorities of academic departments?<p>[1] <a href="https://news.ycombinator.com/item?id=9397320" rel="nofollow">https://news.ycombinator.com/item?id=9397320</a>
Conventions, not rules, better every time. Though a rule that public services should at least state that the data is not sensitive and not needing https is probably a good idea to force people to at least think about it.<p>But we should encourage more public data not less, not add another potential step that might delay/discourage people from making data available. Making https/ssl/tls easier and easier will make this a non issue eventually.<p>(I had to stop myself from spamming the github issue with a link to the seven red lines video.... :)
<a href="https://www.youtube.com/watch?v=BKorP55Aqvg" rel="nofollow">https://www.youtube.com/watch?v=BKorP55Aqvg</a> )
Commenting on the argument rather than the conclusion, it does an odd bait-and-switch.<p>> there is a statement that 'there is no such thing as insensitive web traffic' -- yet there is. [...] Forcing these transfers to go to HTTPS would cause an undue strain on limited resources that have become even more constrained over the past few years.<p>That HTTPS adds additional strain on resources says nothing on whether the data is sensitive or not. The entire post leaves "Non-sensitive web traffic does exist" as an assertion while going on to provide arguments around resources.<p>Not that "HTTPS-Only Standard" makes a particularly coherent argument in the other direction.
Title is misleading and the conversation reflects it: the request is for reconsideration of the US federal government's move toward HTTPS-only <i>on its own websites</i>. Nobody is trying to ban non-HTTPS websites in general.
HTTPS certainly is not cache friendly. Is there an easy way to extend https to handle heavy cache use cases (to improve caching behavior across clients)?<p>For example:<p>Assume: file.data exists and is already encrypted with enckey=K, deckey=D, algo=X, etc<p>Client -> <a href="https://www.example.com/file.data" rel="nofollow">https://www.example.com/file.data</a>
<-> <protocol between server/client to get deckey, algo, etc needed to decrypt><p><- transfer of file.data (from cache) without further encryption but still in the scope of the outer https. The response would carry appropriate headers to indicate where the "plain" data starts and how long it is. At this point, you can use a packet filter and see the encrypted body of the file but not the https headers or anything else.<p>- Client recognizes this valid https session response but takes the inner sections without further decryption. The inner section would need to be marked (as in a multi-part section), and https response headers would need to indicate which byte range of the body should be read as-is and decoded with key deckey.<p>Again, I am hoping for some sort of extension to https to make it cache friendly.<p>Advantages: File is encrypted once (or as needed if policy requires it) and caching proxies can serve the file without re-encryption per user session response.<p>Disadvantage: Likely need to change http/s in some way to wrap and mark plain data.
>> Due to many institutions having policies against FTP and peer-to-peer protocols,<p>This is the problem. Your organization needs to stop cargoculting IT policy. Perhaps banning HTTP will be enough pain to make that change possible.
"<i>If the schools, libraries, and other filtered access points own the client machines they can install their own CA into those machines and have the proxy software intercept and generate certificates.</i>" (From the comments.)<p>That's the first time I've seen a man-in-the-middle attack described as a technique for improving security.
The benefit of ubiquitous encryption outweighs this small list of minor drawbacks a million times over.<p>Even if you could convince me that it's ok to send some traffic in the clear, that wouldn't make any difference. You're just going to have to suck it up, for the benefit of the web and humanity in general.
Why does the news of Yahoo need to be sent over an encrypted channel? Since bandwidth is still expensive, why take away basic caching? I don't want to setup reverse proxies because I don't want a massive headache to separate Yahoo from people banks or medical records.
"HTTPS-only" goes directly against the architectural principles laid out in "REST", where intermediaries should be able to understand (in a limited sense) the request and responses that pass through, do caching, differentiate idempotent from non-idempotent actions etc.<p>The ability for intermediaries to see what goes through is in large part why "REST" is said to aid scalability, the same point this article seems to address.<p>Now, both movements, "HTTPS-only" and "REST" are widely popular in dev communities. Yet I never see one acknowledge the existence of the other, which threatens it. In fact, I'd see people religiously support both, unaware of their cognitive dissonance.<p>Curious, I think.
So the author thinks that scientific data is non-sensitive data. He's an astronomer.<p>Perhaps he's not familiar with the story of another astronomer, Galileo, and what people thought of his data.<p><a href="http://en.wikipedia.org/wiki/Galileo_Galilei" rel="nofollow">http://en.wikipedia.org/wiki/Galileo_Galilei</a><p>It's not always about what you think about your own data. It's also about what others think of your data... which is something beyond your control and sometimes beyond imagining.
It looks like mix of very good arguments (some traffic is not sensitive, and ensuring data integrity may be done much cheaper than HTTPS) with iffy arguments (we must have bad security because some governments ban some people from having a good one) with outright bad ones (since HTTPS can be implemented incorrectly or have bugs, it is not useful).
Trying to secure everything weakly leads to weaker security on important data. If you're using HTTPS for everything, it's so tempting to run everything through a CDN such as Cloudflare, which lets them look at your most critical data. This over-centralization creates a convenient point for central wiretapping. If you run the important stuff like credit card data through your own secured server, and serve the cat videos through the CDN unencrypted, you're be more secure than if you run everything through the CDN. HTTPS Everywere discourages this, which is why it's a form of security theater.<p>Then there's the EFF's own backdoor, the HTTPS Everywhere plug-in. Compromise the EFF's "rules" servers, and you can redirect user traffic anywhere. Their "rules" are regular expressions which can rewrite domain names. Here's an HTTPS Everywhere rule, from their examples:<p><pre><code> <rule from="^http://([\w-]+\.)?dezeen\.com/"
to="https://$1dezeen.com/" />
</code></pre>
That's a third party using a regular expression to rewrite a second level domain. This rule always rewrites it to the same second level domain. But do all of the thousands of rules in the EFF's database? Here's an dangerous looking one that doesn't:[1]<p><pre><code> <rule from="^http://(?:g-images\.|(?:ec[5x]|g-ecx)\.images-)amazon\.com/"
to="https://d1ge0kk1l5kms0.cloudfront.net/"/>
</code></pre>
That redirects some Amazon subdomains to the domain "d1ge0kk1l5kms0.cloudfront.net". Seems legit. The EFF wouldn't let someone redirect Amazon traffic to a hostile site hosted on Cloudfront, would they? If someone set up an instance on Cloudfront which faked the Amazon site, and got a rule like that into the EFF's database, they have a working MITM attack. That site is "secured" by a "*.cloudfront.net" wildcard SSL cert, so all we know is that it's hosted on Cloudfront. Does the EFF must have some way to check that "d1ge0kk1l5kms0.cloudfront.net" string? Nothing in their documentation indicates they do.<p>Welcome to "EFF Backdoors Everywhere".<p>[1] <a href="https://www.eff.org/https-everywhere/atlas/domains/amazonaws.com.html" rel="nofollow">https://www.eff.org/https-everywhere/atlas/domains/amazonaws...</a>
Cert racket and other attendant problems aside, there is little in the argument itself against banning HTTP. It is the same old argument - If we change things, things will break.<p>Yes, this is the nature of change. Not all change is good. But no good will ever be discovered without attempting change.
It comes up everytime but let's at the very least wait until we see if this is a viable way to easily implement HTTPS: <a href="https://letsencrypt.org/" rel="nofollow">https://letsencrypt.org/</a><p>I'd love to see such thing being built in straight into the Nginx/Apache packages of disto's to really make it straightforward.<p>Personally I have a mail.mydomain.nl, a mydomain.nl and an owncloud instance at cloud.mydomain.nl, it is such a pain to update every year, it requires at least 2, if you do it well 3 long sessions at startssl. If you by any chance don't have postmaster@mydomain.nl set up, you get to do that first too. This problem really, really needs solving.
Simply banning any kind of legacy protocol is not exactly in good spirit. People should have freedom of choice when it comes to running THEIR OWN infrastructure.
Poster could set up a reverse proxy to support apps that couldn't be updated to HTTPS in less time than it took to write his github issue post:<p><a href="https://github.com/WhiteHouse/https/issues/107#issuecomment-94425001" rel="nofollow">https://github.com/WhiteHouse/https/issues/107#issuecomment-...</a>
The number of crypto negative posts here makes me feel like HN SSL posts are being gamed. It's the same sorts of comments from multiple "people" across different threads. Anyone want to do the NLP to verify