Please consider the impacts of banning HTTP

257 点作者 v4n4d1s大约 10 年前

26 条评论

xamuel大约 10 年前

Until there's a free, easy, maintainable, and actually existent solution to SSL certs, enforcing HTTPS-only is just downright extortion.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.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?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.

评论 #9407309 未加载

评论 #9407395 未加载

评论 #9407940 未加载

评论 #9407697 未加载

评论 #9407320 未加载

评论 #9407345 未加载

评论 #9408358 未加载

评论 #9407941 未加载

评论 #9408648 未加载

评论 #9407503 未加载

评论 #9407821 未加载

评论 #9408486 未加载

评论 #9408576 未加载

评论 #9408536 未加载

chjj大约 10 年前

This is interesting.I've always been okay with dropping HTTP for HTTPS-only as a long-term goal, as long as we get rid of the SSL cert racket first.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.Fingerprint caching seems insecure when you think about it, yet we're all okay with maintaining our servers with this in place.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.

评论 #9407181 未加载

评论 #9407756 未加载

评论 #9407244 未加载

评论 #9408711 未加载

评论 #9407501 未加载

hannob大约 10 年前

This seems to make two wrong assumptions: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.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.

评论 #9407305 未加载

评论 #9407412 未加载

maaaats大约 10 年前

> The effect on those without computers at homeThe 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.> Restricting the use of HTTP will require changing a number of scientific analysis tools.A non-argument. One cannot let things remain the same for ages just because of backwards compatibility.> HTTPS is not a security improvement for the hosts.So what?> HTTPS is frequently implemented improperlyNon-argument. Https not being perfect doesn't mean it's useless.I'm not necessarily saying https-everywhere is a good idea, just that these arguments adds nothing to the discussion.

评论 #9406986 未加载

评论 #9407276 未加载

评论 #9407106 未加载

评论 #9408712 未加载

评论 #9407286 未加载

评论 #9407006 未加载

PebblesHD大约 10 年前

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?

josteink大约 10 年前

> In summary: Non-sensitive web traffic does exist.A million times this. I cannot believe that the current HTTPS-nazis totally fail to see something this obvious.There's countless use-cases where plain HTTP is not only OK, but probably the simplest and best option.Trying to ban it to address some vague possibly-maybe security-related theoretical issues seems asinine.

评论 #9406993 未加载

评论 #9406982 未加载

评论 #9407131 未加载

评论 #9407153 未加载

评论 #9407633 未加载

评论 #9407047 未加载

评论 #9407844 未加载

rkuykendall-com大约 10 年前

> "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.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.Why is this a problem with Python or HTTPs and not a problem with the priorities of academic departments?[1] <a href="https://news.ycombinator.com/item?id=9397320" rel="nofollow">https://news.ycombinator.com/item?id=9397320</a>

评论 #9410767 未加载

flurdy大约 10 年前

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

ajanuary大约 10 年前

Commenting on the argument rather than the conclusion, it does an odd bait-and-switch.> 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.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.Not that "HTTPS-Only Standard" makes a particularly coherent argument in the other direction.

ubernostrum大约 10 年前

Title is misleading and the conversation reflects it: the request is for reconsideration of the US federal government's move toward HTTPS-only on its own websites. Nobody is trying to ban non-HTTPS websites in general.

评论 #9409484 未加载

deskamess大约 10 年前

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)?For example:Assume: file.data exists and is already encrypted with enckey=K, deckey=D, algo=X, etcClient -> <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><- 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.- 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.Again, I am hoping for some sort of extension to https to make it cache friendly.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.Disadvantage: Likely need to change http/s in some way to wrap and mark plain data.

评论 #9407734 未加载

评论 #9407355 未加载

moron4hire大约 10 年前

>> Due to many institutions having policies against FTP and peer-to-peer protocols,This is the problem. Your organization needs to stop cargoculting IT policy. Perhaps banning HTTP will be enough pain to make that change possible.

评论 #9407494 未加载

higherpurpose大约 10 年前

I think schools banning HTTPS has a lot more to do with being able to censor what the students are visiting than saving bandwidth.

评论 #9407896 未加载

评论 #9407199 未加载

评论 #9407093 未加载

mcguire大约 10 年前

"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." (From the comments.)That's the first time I've seen a man-in-the-middle attack described as a technique for improving security.

mike-cardwell大约 10 年前

The benefit of ubiquitous encryption outweighs this small list of minor drawbacks a million times over.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.

protomyth大约 10 年前

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.

评论 #9408691 未加载

BringTheTanks大约 10 年前

"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.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.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.Curious, I think.

评论 #9406991 未加载

评论 #9406985 未加载

评论 #9407016 未加载

评论 #9406999 未加载

natch大约 10 年前

So the author thinks that scientific data is non-sensitive data. He's an astronomer.Perhaps he's not familiar with the story of another astronomer, Galileo, and what people thought of his data.<a href="http://en.wikipedia.org/wiki/Galileo_Galilei" rel="nofollow">http://en.wikipedia.org/wiki/Galileo_Galilei</a>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.

tempodox大约 10 年前

Isn't HTTPS-only just a financial ploy of root certificate vendors? I'd welcome more security but it shouldn't cost an arm and a leg.

smsm42大约 10 年前

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

Animats大约 10 年前

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.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:<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]<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.Welcome to "EFF Backdoors Everywhere".[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>

评论 #9415362 未加载

ajani大约 10 年前

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.Yes, this is the nature of change. Not all change is good. But no good will ever be discovered without attempting change.

teekert大约 10 年前

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>I'd love to see such thing being built in straight into the Nginx/Apache packages of disto's to really make it straightforward.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.

crypt1d大约 10 年前

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.

评论 #9407777 未加载

评论 #9407147 未加载

larrysalibra大约 10 年前

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:<a href="https://github.com/WhiteHouse/https/issues/107#issuecomment-94425001" rel="nofollow">https://github.com/WhiteHouse/https/issues/107#issuecomment-...</a>

评论 #9407556 未加载

评论 #9407739 未加载

mentat大约 10 年前

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