16 ms·

Please consider the impacts of banning HTTP

257 points by v4n4d1s 12y ago

higherpurpose 12y ago
I think schools banning HTTPS has a lot more to do with being able to censor what the students are visiting than saving bandwidth.
- maze-le 12y ago
  Even with HTTPS enabled, institutions can censor based on IP or DNS. Blocking based on Deep-Packet-Inspection is a bit complex to set up for normal schools i think.
  - dezgeg 12y ago
    I'm pretty sure a DPI-based filtering can be purchased as an off-the-self service. And that's one of the core reasons I dislike HTTPS everywhere. It will lead to organizations like schools installing their own root certificates to MITM traffic, lessening the security of those things where encryption is the most important, like online banking.
    - dublinben 12y ago
      Many universities already require the installation of a root certificate. The primary purpose is to avoid buying commercial certificates for every last internal university site, but it also has the effect you've mentioned.
  - spacemanmatt 12y ago
    Plenty of vendors are ready to sell turnkey censorware to them. It's already a thing.
  - superuser2 12y ago
    Nope. Pretty much 100% of schools in the U.S. (with internet access) operate a transparent or explicit HTTP(s) proxy as the only way out to the internet from student-accessible vlans. Websense is probably the most popular commercial solution. My school district ran a Squid extension called Squidguard for a long time before switching to the filtering solution bundled with its new wireless controller system. Implementing web filtering is a condition of receiving federal subsidies; they take it seriously. A school with only a handful of PCs might use a host-based solution but proxy-as-the-only-way-out network design is very, very common.
- josephkern 12y ago
  They can't buy and configure an HTTPS proxy? Those things do exist after all.
  - Someone1234 12y ago
    HTTPS proxies work less well today than they did even five years ago. Certificate pinning and other security improvements have broken a lot of things (by design). So the question is: What is more important, allowing HTTPS proxies, or stopping governments with a CA from MitM-ing traffic (e.g. Iran, China, etc). A nice compromise might be to inform users that they're being MitM-ed by an installed CA, but only once and subtly so.
    - MichaelGG 12y ago
      Which browsers enforce pinning when faced with a CA proxy? Chrome explicitly overrides pinning in this case, so they don't break half of all corporate usage.
- dheera 12y ago
  Maybe schools should just stop censoring students? We should setting examples for children, and set the example of mutual trust and responsibility, not "how to spy on other people below you".
  - Someone1234 12y ago
    That would require legal changes. At the moment many schools are legally required to censor students. This is also in a country which still doesn't teach comprehensive sex ed' in many places and for which many adults don't want kids to have access to that information.
josteink 12y ago
> 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.
- growse 12y ago
  Most arguments I've seen against HTTPS everywhere seem to fail to realise that it's not just the data confidentiality that's important, it's the integrity too. If you don't care about the data you're getting back from a server being wrong, why bother requesting it in the first place? If you do care about it being wrong, HTTPS isn't a bad way to help ensure that what you're getting is what the server is giving out. It's not perfect, but nothing is.
  - josteink 12y ago
    > If you don't care about the data you're getting back from a server being wrong, why bother requesting it in the first place? If that's the argument, it reasonably applies to everything, everywhere, and we should scrap TCP alltogether. Instead we need to implement a replacement which ensures everything everywhere at every level of every stack does crypto as well. Let's call it STCP! Or does that suddenly sounds zealous? It just follows from your base argument.
    - personjerry 12y ago
      This counter-argument fails because HTTPS is much easier to implement and web servers already use it. Whereas TCP is much lower level and to make "STCP" we would have to recode servers entirely to handle both TCP and STCP requests from clients.
    - molf 12y ago
      Or Google calls it QUIC [1]. And it's exactly that, a replacement for TCP with TLS. [1] http://blog.chromium.org/2013/06/experimenting-with-quic.html http://blog.chromium.org/2013/06/experimenting-with-quic.htm...
BringTheTanks 12y ago
"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.
- quonn 12y ago
  First, proxies are certainly not one of the necessary principles of REST. Even without proxies, there can be REST. More importantly, most REST APIs can't take advantage of proxies anyway, because most responses must not be cached. Second, HTTPS is MITMed using self-signed certificates (signed by custom CAs which are installed in browsers on the network) by proxies all the time. This is very common in corporate networks. Therefore, HTTPS currently works with proxies.
- maaaats 12y ago
  Because your initial premise is flawed. Equal GET requests will often have different results based on the user doing them. Either because they are requesting their "own" data or because they have different privileges and see different results. While not perfect, it's the reality. This throws out all possibilities of caching. And why intermediates should differentiate more than that I cannot see. So https is in no way limiting REST.
  - pjc50 12y ago
    Equal GET requests will often have different results based on the user doing them Well, that's very non-REST.
    - nl 12y ago
      No it's is exactly REST. Section 5.2.2 of Fielding's thesis specifically says how per-user authenticated cannot be cached in a shared cache because they may vary per request. There are other cases mentioned too.
maaaats 12y ago
> The effect on those without computers at home 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. > 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 improperly Non-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.
- josteink 12y ago
  > I think most stuff people do nowadays is things that's not cache-friendly anyway So you're OK with throwing away a perfectly fine and proven internet protocol which has survived for several decades, on a vague notion you have that "it's probably not that cache-friendly anyway". That sounds solid. > HTTPS is not a security improvement for the hosts. So what? Reduced performance. Increased latency. Increased complexity. Increased attack-vector size. But indeed: so what? > HTTPS is frequently implemented improperly. Non-argument. Yes. Who cares about the real world, anyway? I'm awfully sorry, but I honestly don't think your post counts as a very good counter-argument to those very valid points which were raised in the reported issue.
  - maaaats 12y ago
    > So you're OK with throwing away a perfectly fine and proven internet protocol which has survived for several decades, on a vague notion you have that "it's probably not that cache-friendly anyway". Don't do straw men, please. I said that it's not as big an issue as the author said it was. Nothing more, nothing less. > Reduced performance. Increased latency. Increased complexity. Increased attack-vector size. But indeed: so what? Not that much increased complexity in most cases. But the performance is a potentially good argument. The author should have used that instead.
tljr 12y ago
Occams razor says OP has a point. I know our governments are fucking our internet, but please don't help them. If we encrypt, we change the personality of the internet. It goes from a "hi let's talk" system to a "prove you are who I think you are before I say anything" system. If that sounds like a win to you, then we're going to disagree on a lot more than internet policy.
flurdy 12y ago
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.... :) https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg )
crypt1d 12y ago
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.
- spacemanmatt 12y ago
  I don't think anyone was trying to tell you how to build your core application network or your home LAN. SSL Everywhere is about critical connections subject to interception.
  - crypt1d 12y ago
    I was referring to public networks as well. I should be able to do HTTP GET to my server if I choose to do so. In the same way as I can open a socket to my server and write plain text to it.
    - spacemanmatt 12y ago
      I think you should be able, in the sense that it should not be legally or technologically prohibited nor prohibitive. I do think there is a line, beyond which a service should be obligated to encrypt everything, and that line is somewhere around carrying others' messages, certainly around getting common carrier status for the same. Edit: I must stress, social not legal consequences should apply. I'm in no hurry to invite government scrutiny of this line.
- icebraining 12y ago
  The ban is just for .gov sites. "This proposed initiative, “The HTTPS-Only Standard,” would require the use of HTTPS on all publicly accessible Federal websites and web services."
chjj 12y ago
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.
- mmphosis 12y ago
  > as long as we get rid of the SSL cert racket first. "It is really a messed up situation to have to pay to not have your website marked as dangerous"
  - IgorPartola 12y ago
    It's also messed up that we have to pay for domain names. Why can't we have them for free? I want Google.com please. You can get free certs now, and more ways to obtain them are coming this summer. In either case, let's solve our immediate problem now, then add different authentication methods to browsers after.
    - danieldk 12y ago
      This is an incorrect analogy. Domain names are a finite resource, the cost of signing a certificate approaches zero.
      - odonnellryan 12y ago
        The cost of the actual signing is pretty much zero, but there were definitely paid devs who built these commercial solutions.
        12y ago
mike-cardwell 12y ago
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.
PebblesHD 12y ago
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?
hannob 12y ago
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.
- dijit 12y ago
  Your second point is valid only for x86 machines (and modern ones). AES instruction sets implemented in hardware are the main factor in making HTTPS viable. But my toaster (which speaks HTTP), or my ARM based router, or even my high end server iDRAC/iLO does not have a dedicated x86 or AES hardware instruction. so the point stands, even if it's not relevant to modern laptop users.
  - icebraining 12y ago
    ARMv8 comes with the AES instruction set as well, and Linux supports it. The newer Android phones like the Nexus 9 are already using it.
  - xenophonf 12y ago
    Of all the things that should be using strong encryption by default, router and server management interfaces are at the top of that list. Those interfaces _do not_ have the kinds of high-performance transfer requirements like that of bulk data transfers or streaming video services. As for bulk data transfers for government-funded scientific research, data integrity for anything having to do with clinical trials or personally-identifiable information is among my highest concerns. And unless we're pumping that data across private fiber, the latency and bandwidth limits of the global Internet far outweigh the overhead caused by encryption/authentication algorithms. (I would add that I think bulk data transfers ought to be encrypted over private/internal networks as well, but that's an argument for when I'm not on mobile.)
  - thoughtpolice 12y ago
xamuel 12y ago
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.
- gearhart 12y ago
  I agree wholeheartedly with all of the points you're trying to make but the spoken word / snailmail comparison is broken and detracts from your message. Saying that spoken word and snail mail are unencrypted and thereby implying that we should be no more worried about unencrypted digital traffic than we are about our real-world conversations is a harmful analogy, because it's evidently superficially true, but it implies that accessing your bank account over HTTP is no more dangerous than saying your credit card number in the street. That analogy would hold if every conversation that we have (or letter we send) could be recorded, filtered and searched at scale by anyone who cared enough to do so. In reality, using encrypted web communication is more analogous to real-world conversation - if somebody is particularly interested in what you, individually, are doing or saying then barring significant efforts on your behalf, they can probably get access to it but encryption, and analogously the security afforded by the difficulty of overhearing people's conversations in real life, prevents widespread, untargeted surveillance that would make, for example, automated harvesting of bank details, or the identification of people interested in a particular political movement trivial.
- chaz72 12y ago
  > Until there's a free, easy, maintainable, and actually existent solution to SSL certs, enforcing HTTPS-only is just downright extortion. True - but the second that solution exists, I can't think of anything that should stick with unsecured HTTP, and this article didn't change my mind. I don't think we need a "ban", though. Just flip the way browsers show secured vs unsecured, instead of the green reassuring lock for https, that becomes the expected default and http gets a scary red plaintext indicator.
teekert 12y ago
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: https://letsencrypt.org/ https://letsencrypt.org/ 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.
tempodox 12y ago
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.
deskamess 12y ago
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, etc Client -> https://www.example.com/file.data https://www.example.com/file.data <-> <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.
- shawabawa3 12y ago
  The way I see it there are 2 problems with HTTP 1. Allows passive snooping (not always a problem) 2. No way of knowing whether data has been tampered with (always a problem) Would be nice if there was a way to stop 2 (e.g. checksum sent through HTTPS), but allowed the caching benefits of 1
  - icebraining 12y ago
    TLS/SSL actually supports authentication/signing only, it's just that most browsers don't accept it by default: http://www.hamwan.org/t/SSL+without+Encryption http://www.hamwan.org/t/SSL+without+Encryption
    - deskamess 12y ago
      This seems to be the feature we need if browsers would support it. I can see how this would cause issues in the "presentation", i.e., how could a browser warn a user that for this session your data is not encrypted (given expectations for pages served via https have already been defaulted to 'you are at the right site + data transfers are encrypted').
moron4hire 12y ago
>> 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.
- lultimouomo 12y ago
  > This paperwork has restricted our ability to openly share scientific data with international partners, and has impacted our sharing with an NSF partner that had a foreign-born system administrator. I'd say their IT policy is not the only broken one...
larrysalibra 12y ago
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: https://github.com/WhiteHouse/https/issues/107#issuecomment-94425001 https://github.com/WhiteHouse/https/issues/107#issuecomment-...
- biftek 12y ago
  Maybe because your tone was rude?
- danielsamuels 12y ago
  Are you trying to garner sympathy from the Hacker News crowd? Because you're not going to get it.
  - icebraining 12y ago
    Sorry, downvoted you by mistake :|
  - larrysalibra 12y ago
    Not at all. Apologies for leaving that impression! Want more people to call bullshit when people in government use lazy arguments as an excuse to compromise privacy of citizens. "But if there's encryption, my job is more work" arguments from NSA, CIA, FBI, military, etc, exactly like this are a huge threat to civil liberties & freedom.
ubernostrum 12y ago
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.
- deleted 12y ago
  [deleted]
ajanuary 12y ago
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.
protomyth 12y ago
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.
- MichaelGG 12y ago
  I'd have a lot of fun and probably make a lot of money, if I could control Yahoo News for a week.
  - protomyth 12y ago
    That is the single most unlikely thing that could happen. It is also just a dumb argument to require people to do a lot of book keeping for every printer or other device on a network. I am starting to think this is some weird plot to make entry into any web software harder and protect those already here because the arguments for this don't make sense. I assume that caching is going to end.
    - MichaelGG 12y ago
      Really? 4chan got Apple stock to plummet 5% just by announcing stuff about Steve Jobs. Yahoo News publishing news like "Elon Musk dies" or "3 killed in Tesla car battery explosions" or just other simple "X misses Q3 by 80%" or "X to acquire Y" would do a pretty good job at changing prices, I'd guess. (Though if you went overboard they could roll trades back, maybe.) As far as the fun part. Just change people's quotes, slightly. Twist words around. Make it seem like Obama really regrets the healthcare act. Or something funnier. Done well, it'd be a fantastic piece of trolling. Done really well, you could send people into a panic.
      - protomyth 12y ago
        Has this actually happened or is this just a fever dream? We are talking actual dollars and pain-in-the-butt work versus some weird hijack looks like it would get caught in very short order. I am unwilling to trade caching and bandwidth for this.
smsm42 12y ago
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).
mentat 12y ago
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
rkuykendall-com 12y ago
> "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] https://news.ycombinator.com/item?id=9397320 https://news.ycombinator.com/item?id=9397320
- alphapapa 12y ago
  Read the GitHub bug. We're talking about missions started decades ago. There is no budget and no staff to maintain the existing code, much less rewrite parts of it. But because some wonk thousands of miles away in Washington made a "HTTPS only from now on!" proclamation, all these existing projects which are working fine should be canceled? Or the staff should put in hours of unpaid overtime to learn and rewrite and test decades-old codebases? How about you volunteer to do some of that work, and then you can criticize "priorities" and "people trying to do technical things and doing them poorly."
mcguire 12y ago
"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.
Animats 12y ago
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: <rule from="^http://([\w-]+\.)?dezeen\.com/" to="https://$1dezeen.com/" /> 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] <rule from="^http://(?:g-images\.|(?:ec[5x]|g-ecx)\.images-)amazon\.com/" to="https://d1ge0kk1l5kms0.cloudfront.net/"/> 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] https://www.eff.org/https-everywhere/atlas/domains/amazonaws.com.html https://www.eff.org/https-everywhere/atlas/domains/amazonaws...
- serve_yay 12y ago
  Ahh, you're nuts. If it's HTTPS, it must be secure -- that's what the "S" stands for!
natch 12y ago
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. http://en.wikipedia.org/wiki/Galileo_Galilei http://en.wikipedia.org/wiki/Galileo_Galilei 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.
ajani 12y ago
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.

257 points by v4n4d1s 12y ago

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

maze-le 12y ago
Even with HTTPS enabled, institutions can censor based on IP or DNS. Blocking based on Deep-Packet-Inspection is a bit complex to set up for normal schools i think.
- dezgeg 12y ago
  I'm pretty sure a DPI-based filtering can be purchased as an off-the-self service. And that's one of the core reasons I dislike HTTPS everywhere. It will lead to organizations like schools installing their own root certificates to MITM traffic, lessening the security of those things where encryption is the most important, like online banking.
  - dublinben 12y ago
    Many universities already require the installation of a root certificate. The primary purpose is to avoid buying commercial certificates for every last internal university site, but it also has the effect you've mentioned.
- spacemanmatt 12y ago
  Plenty of vendors are ready to sell turnkey censorware to them. It's already a thing.
- superuser2 12y ago
  Nope. Pretty much 100% of schools in the U.S. (with internet access) operate a transparent or explicit HTTP(s) proxy as the only way out to the internet from student-accessible vlans. Websense is probably the most popular commercial solution. My school district ran a Squid extension called Squidguard for a long time before switching to the filtering solution bundled with its new wireless controller system. Implementing web filtering is a condition of receiving federal subsidies; they take it seriously. A school with only a handful of PCs might use a host-based solution but proxy-as-the-only-way-out network design is very, very common.
josephkern 12y ago
They can't buy and configure an HTTPS proxy? Those things do exist after all.
- Someone1234 12y ago
  HTTPS proxies work less well today than they did even five years ago. Certificate pinning and other security improvements have broken a lot of things (by design). So the question is: What is more important, allowing HTTPS proxies, or stopping governments with a CA from MitM-ing traffic (e.g. Iran, China, etc). A nice compromise might be to inform users that they're being MitM-ed by an installed CA, but only once and subtly so.
  - MichaelGG 12y ago
    Which browsers enforce pinning when faced with a CA proxy? Chrome explicitly overrides pinning in this case, so they don't break half of all corporate usage.
dheera 12y ago
Maybe schools should just stop censoring students? We should setting examples for children, and set the example of mutual trust and responsibility, not "how to spy on other people below you".
- Someone1234 12y ago
  That would require legal changes. At the moment many schools are legally required to censor students. This is also in a country which still doesn't teach comprehensive sex ed' in many places and for which many adults don't want kids to have access to that information.

josteink 12y ago

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

growse 12y ago
Most arguments I've seen against HTTPS everywhere seem to fail to realise that it's not just the data confidentiality that's important, it's the integrity too. If you don't care about the data you're getting back from a server being wrong, why bother requesting it in the first place? If you do care about it being wrong, HTTPS isn't a bad way to help ensure that what you're getting is what the server is giving out. It's not perfect, but nothing is.
- josteink 12y ago
  > If you don't care about the data you're getting back from a server being wrong, why bother requesting it in the first place? If that's the argument, it reasonably applies to everything, everywhere, and we should scrap TCP alltogether. Instead we need to implement a replacement which ensures everything everywhere at every level of every stack does crypto as well. Let's call it STCP! Or does that suddenly sounds zealous? It just follows from your base argument.
  - personjerry 12y ago
    This counter-argument fails because HTTPS is much easier to implement and web servers already use it. Whereas TCP is much lower level and to make "STCP" we would have to recode servers entirely to handle both TCP and STCP requests from clients.
  - molf 12y ago
    Or Google calls it QUIC [1]. And it's exactly that, a replacement for TCP with TLS. [1] http://blog.chromium.org/2013/06/experimenting-with-quic.html http://blog.chromium.org/2013/06/experimenting-with-quic.htm...

BringTheTanks 12y ago

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

quonn 12y ago
First, proxies are certainly not one of the necessary principles of REST. Even without proxies, there can be REST. More importantly, most REST APIs can't take advantage of proxies anyway, because most responses must not be cached. Second, HTTPS is MITMed using self-signed certificates (signed by custom CAs which are installed in browsers on the network) by proxies all the time. This is very common in corporate networks. Therefore, HTTPS currently works with proxies.
maaaats 12y ago
Because your initial premise is flawed. Equal GET requests will often have different results based on the user doing them. Either because they are requesting their "own" data or because they have different privileges and see different results. While not perfect, it's the reality. This throws out all possibilities of caching. And why intermediates should differentiate more than that I cannot see. So https is in no way limiting REST.
- pjc50 12y ago
  Equal GET requests will often have different results based on the user doing them Well, that's very non-REST.
  - nl 12y ago
    No it's is exactly REST. Section 5.2.2 of Fielding's thesis specifically says how per-user authenticated cannot be cached in a shared cache because they may vary per request. There are other cases mentioned too.

maaaats 12y ago

> The effect on those without computers at home 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. > 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 improperly Non-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.

josteink 12y ago
> I think most stuff people do nowadays is things that's not cache-friendly anyway So you're OK with throwing away a perfectly fine and proven internet protocol which has survived for several decades, on a vague notion you have that "it's probably not that cache-friendly anyway". That sounds solid. > HTTPS is not a security improvement for the hosts. So what? Reduced performance. Increased latency. Increased complexity. Increased attack-vector size. But indeed: so what? > HTTPS is frequently implemented improperly. Non-argument. Yes. Who cares about the real world, anyway? I'm awfully sorry, but I honestly don't think your post counts as a very good counter-argument to those very valid points which were raised in the reported issue.
- maaaats 12y ago
  > So you're OK with throwing away a perfectly fine and proven internet protocol which has survived for several decades, on a vague notion you have that "it's probably not that cache-friendly anyway". Don't do straw men, please. I said that it's not as big an issue as the author said it was. Nothing more, nothing less. > Reduced performance. Increased latency. Increased complexity. Increased attack-vector size. But indeed: so what? Not that much increased complexity in most cases. But the performance is a potentially good argument. The author should have used that instead.

tljr 12y ago

Occams razor says OP has a point. I know our governments are fucking our internet, but please don't help them. If we encrypt, we change the personality of the internet. It goes from a "hi let's talk" system to a "prove you are who I think you are before I say anything" system. If that sounds like a win to you, then we're going to disagree on a lot more than internet policy.

flurdy 12y ago

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.... :) https://www.youtube.com/watch?v=BKorP55Aqvg https://www.youtube.com/watch?v=BKorP55Aqvg )

crypt1d 12y ago

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.

spacemanmatt 12y ago
I don't think anyone was trying to tell you how to build your core application network or your home LAN. SSL Everywhere is about critical connections subject to interception.
- crypt1d 12y ago
  I was referring to public networks as well. I should be able to do HTTP GET to my server if I choose to do so. In the same way as I can open a socket to my server and write plain text to it.
  - spacemanmatt 12y ago
    I think you should be able, in the sense that it should not be legally or technologically prohibited nor prohibitive. I do think there is a line, beyond which a service should be obligated to encrypt everything, and that line is somewhere around carrying others' messages, certainly around getting common carrier status for the same. Edit: I must stress, social not legal consequences should apply. I'm in no hurry to invite government scrutiny of this line.
icebraining 12y ago
The ban is just for .gov sites. "This proposed initiative, “The HTTPS-Only Standard,” would require the use of HTTPS on all publicly accessible Federal websites and web services."

chjj 12y ago

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.

mmphosis 12y ago
> as long as we get rid of the SSL cert racket first. "It is really a messed up situation to have to pay to not have your website marked as dangerous"
- IgorPartola 12y ago
  It's also messed up that we have to pay for domain names. Why can't we have them for free? I want Google.com please. You can get free certs now, and more ways to obtain them are coming this summer. In either case, let's solve our immediate problem now, then add different authentication methods to browsers after.
  - danieldk 12y ago
    This is an incorrect analogy. Domain names are a finite resource, the cost of signing a certificate approaches zero.
    - odonnellryan 12y ago
      The cost of the actual signing is pretty much zero, but there were definitely paid devs who built these commercial solutions.
      - 12y ago

mike-cardwell 12y ago

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.

PebblesHD 12y ago

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?

hannob 12y ago

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.

dijit 12y ago
Your second point is valid only for x86 machines (and modern ones). AES instruction sets implemented in hardware are the main factor in making HTTPS viable. But my toaster (which speaks HTTP), or my ARM based router, or even my high end server iDRAC/iLO does not have a dedicated x86 or AES hardware instruction. so the point stands, even if it's not relevant to modern laptop users.
- icebraining 12y ago
  ARMv8 comes with the AES instruction set as well, and Linux supports it. The newer Android phones like the Nexus 9 are already using it.
- xenophonf 12y ago
  Of all the things that should be using strong encryption by default, router and server management interfaces are at the top of that list. Those interfaces _do not_ have the kinds of high-performance transfer requirements like that of bulk data transfers or streaming video services. As for bulk data transfers for government-funded scientific research, data integrity for anything having to do with clinical trials or personally-identifiable information is among my highest concerns. And unless we're pumping that data across private fiber, the latency and bandwidth limits of the global Internet far outweigh the overhead caused by encryption/authentication algorithms. (I would add that I think bulk data transfers ought to be encrypted over private/internal networks as well, but that's an argument for when I'm not on mobile.)
- thoughtpolice 12y ago

xamuel 12y ago

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.

gearhart 12y ago
I agree wholeheartedly with all of the points you're trying to make but the spoken word / snailmail comparison is broken and detracts from your message. Saying that spoken word and snail mail are unencrypted and thereby implying that we should be no more worried about unencrypted digital traffic than we are about our real-world conversations is a harmful analogy, because it's evidently superficially true, but it implies that accessing your bank account over HTTP is no more dangerous than saying your credit card number in the street. That analogy would hold if every conversation that we have (or letter we send) could be recorded, filtered and searched at scale by anyone who cared enough to do so. In reality, using encrypted web communication is more analogous to real-world conversation - if somebody is particularly interested in what you, individually, are doing or saying then barring significant efforts on your behalf, they can probably get access to it but encryption, and analogously the security afforded by the difficulty of overhearing people's conversations in real life, prevents widespread, untargeted surveillance that would make, for example, automated harvesting of bank details, or the identification of people interested in a particular political movement trivial.
chaz72 12y ago
> Until there's a free, easy, maintainable, and actually existent solution to SSL certs, enforcing HTTPS-only is just downright extortion. True - but the second that solution exists, I can't think of anything that should stick with unsecured HTTP, and this article didn't change my mind. I don't think we need a "ban", though. Just flip the way browsers show secured vs unsecured, instead of the green reassuring lock for https, that becomes the expected default and http gets a scary red plaintext indicator.

teekert 12y ago

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: https://letsencrypt.org/ https://letsencrypt.org/ 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.

tempodox 12y ago

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.

deskamess 12y ago

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, etc Client -> https://www.example.com/file.data https://www.example.com/file.data <-> <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.

shawabawa3 12y ago
The way I see it there are 2 problems with HTTP 1. Allows passive snooping (not always a problem) 2. No way of knowing whether data has been tampered with (always a problem) Would be nice if there was a way to stop 2 (e.g. checksum sent through HTTPS), but allowed the caching benefits of 1
- icebraining 12y ago
  TLS/SSL actually supports authentication/signing only, it's just that most browsers don't accept it by default: http://www.hamwan.org/t/SSL+without+Encryption http://www.hamwan.org/t/SSL+without+Encryption
  - deskamess 12y ago
    This seems to be the feature we need if browsers would support it. I can see how this would cause issues in the "presentation", i.e., how could a browser warn a user that for this session your data is not encrypted (given expectations for pages served via https have already been defaulted to 'you are at the right site + data transfers are encrypted').

moron4hire 12y ago

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

lultimouomo 12y ago
> This paperwork has restricted our ability to openly share scientific data with international partners, and has impacted our sharing with an NSF partner that had a foreign-born system administrator. I'd say their IT policy is not the only broken one...

larrysalibra 12y ago

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: https://github.com/WhiteHouse/https/issues/107#issuecomment-94425001 https://github.com/WhiteHouse/https/issues/107#issuecomment-...

biftek 12y ago
Maybe because your tone was rude?
danielsamuels 12y ago
Are you trying to garner sympathy from the Hacker News crowd? Because you're not going to get it.
- icebraining 12y ago
  Sorry, downvoted you by mistake :|
- larrysalibra 12y ago
  Not at all. Apologies for leaving that impression! Want more people to call bullshit when people in government use lazy arguments as an excuse to compromise privacy of citizens. "But if there's encryption, my job is more work" arguments from NSA, CIA, FBI, military, etc, exactly like this are a huge threat to civil liberties & freedom.

ubernostrum 12y ago

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.

deleted 12y ago
[deleted]

ajanuary 12y ago

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.

protomyth 12y ago

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.

MichaelGG 12y ago
I'd have a lot of fun and probably make a lot of money, if I could control Yahoo News for a week.
- protomyth 12y ago
  That is the single most unlikely thing that could happen. It is also just a dumb argument to require people to do a lot of book keeping for every printer or other device on a network. I am starting to think this is some weird plot to make entry into any web software harder and protect those already here because the arguments for this don't make sense. I assume that caching is going to end.
  - MichaelGG 12y ago
    Really? 4chan got Apple stock to plummet 5% just by announcing stuff about Steve Jobs. Yahoo News publishing news like "Elon Musk dies" or "3 killed in Tesla car battery explosions" or just other simple "X misses Q3 by 80%" or "X to acquire Y" would do a pretty good job at changing prices, I'd guess. (Though if you went overboard they could roll trades back, maybe.) As far as the fun part. Just change people's quotes, slightly. Twist words around. Make it seem like Obama really regrets the healthcare act. Or something funnier. Done well, it'd be a fantastic piece of trolling. Done really well, you could send people into a panic.
    - protomyth 12y ago
      Has this actually happened or is this just a fever dream? We are talking actual dollars and pain-in-the-butt work versus some weird hijack looks like it would get caught in very short order. I am unwilling to trade caching and bandwidth for this.

smsm42 12y ago

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

mentat 12y ago

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

rkuykendall-com 12y ago

> "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] https://news.ycombinator.com/item?id=9397320 https://news.ycombinator.com/item?id=9397320

alphapapa 12y ago
Read the GitHub bug. We're talking about missions started decades ago. There is no budget and no staff to maintain the existing code, much less rewrite parts of it. But because some wonk thousands of miles away in Washington made a "HTTPS only from now on!" proclamation, all these existing projects which are working fine should be canceled? Or the staff should put in hours of unpaid overtime to learn and rewrite and test decades-old codebases? How about you volunteer to do some of that work, and then you can criticize "priorities" and "people trying to do technical things and doing them poorly."

mcguire 12y ago

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

Animats 12y ago

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: <rule from="^http://([\w-]+\.)?dezeen\.com/" to="https://$1dezeen.com/" /> 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] <rule from="^http://(?:g-images\.|(?:ec[5x]|g-ecx)\.images-)amazon\.com/" to="https://d1ge0kk1l5kms0.cloudfront.net/"/> 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] https://www.eff.org/https-everywhere/atlas/domains/amazonaws.com.html https://www.eff.org/https-everywhere/atlas/domains/amazonaws...

serve_yay 12y ago
Ahh, you're nuts. If it's HTTPS, it must be secure -- that's what the "S" stands for!

natch 12y ago

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. http://en.wikipedia.org/wiki/Galileo_Galilei http://en.wikipedia.org/wiki/Galileo_Galilei 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.

ajani 12y ago

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.