9 ms·

I agree with this wholeheartedly. I had to maintain a lot of old custom appliances and the like for which no ready replacement existed. Niche stuff where you

• kop316 6y ago
  > has not made my life easier nor brought any benefit to my users So I'm curious, is this appliance on a private network or something? That's they only way I see that it doesn't bring any benefit. If it is going out onto the public internet, I would think encryption and integrity would be a huge concern.
  • at_a_remove 6y ago
    It goes out on the public. It's not a target because it is a library catalog. Nobody is going to man-in-the-middle looking up which shelf a book is on. I mean, I am sure you can come up with a Sneakers-style plot where it is important but no, not realistically. Could it be done? Certainly! Why would they? What's the benefit? There's just tons of stuff out there that exists where, honest-to-gosh, credit card details and HIPAA compliance do not happen. I know Hacker News leans very heavy toward the Silicon Valley side, but I swear stuff happens in the flyover states that involves computers. It might be pedestrian and unexciting, and nobody will IPO, but they do happen.
    • vbrandl 6y ago
      Any man in the middle might inject JavaScript in the request and hijack the user's browser.
      • at_a_remove 6y ago
        And if our users had ever mentioned this happening once, ever, in decades, it might be important. I've never seen it happen when I used it from home, I've never heard of it happening. It's a nobody cares situation. Now, I have had to defend university servers from quite a lot of things, in a large variety of situations. But this? This has never shown up as an issue.
        • deleted 6y ago
          [deleted]
        • cycloptic 6y ago
          Can you say, with confidence, that it will never happen in the future? And if so, how much of your own money are you willing to put down on that? Would you stake your job/career on that claim that it won't happen in the future?
          • josteink 6y ago
            I’m not OP, but I’m willing to claim that there are going to be at least an order of magnitude more reported security vulnerabilities due to overly complex crypto-stacks than there are going to be reported successful internet-scale MITM-attacks. For many things crypto itself is going to be a bigger security-risk than what it’s defending against.
            • cycloptic 6y ago
              So, you will be betting your career/job on that assertion? And your money as well? Following that, there must be a crypto-averse bank you're using to deposit your paychecks, right? And if so, can I have the URL to their public and unencrypted site?
  • vincnetas 6y ago
    What does that has to do with https? https does not fix your server side bugs. Nor https prevents anyone from connecting to your server. Only(in general) thing that it provides is content encryption which is going through internet. If you hosting public website, this content is already publicly available.
    • ubercow13 6y ago
      Lots of content is publicly available but detailed information about which people are accessing exactly which parts of the content in which patterns is something else altogether and is potentially more valuable and private. https doesn’t fully protect this information but it helps.
    • kop316 6y ago
      > Niche stuff where you had one or two vendors in the whole arena Seeing that tells me it is not just some sort of public website, and not something you just want any random person to access. Think like PLCs controlling public infrastructure (this is a real scenario in places) If it is on the public internet, I imagine the first thing you go is login to it. If it is HTTP, those credentials are going over the internet in the clear.
      • at_a_remove 6y ago
        No, the first thing you do is not log in to it. That's the one size fits all mindset that is part of the problem. It says "Everything is running on these two webservers, therefore we just have to cover those two use cases. Everything is super-critical top secret, so of course we will want to do it." The first thing you do is see if the book exists. Logins go to a different system, for something else. If you stop thinking of the Internet as a place where people put in login information and credit card details to get products shipped to them, it becomes a great deal wider and more complex. Sometimes websites are just ... present to provide information. It might be backed up by a database but that is it.
        • jasode 6y ago
• kerkeslager 6y ago
  So, I'm definitely not against vanilla HTTP where appropriate, but here are three arguments for the "all must be encrypted, heretic!" side of things: 1. The vast majority of web developers/IT people/etc. aren't really knowledgeable enough to make the call whether something actually needs to be encrypted. Very smart developers have told me they weren't worried about security because their application didn't hold any sensitive data. Sometimes this was because they thought emails and/or passwords weren't sensitive data. I've also had very smart people tell me they weren't worried about security because nobody had any incentive to hack their server. But there is always incentive for bad people to hack a server: even if they can't ransomware you, they can host botnets or child pornography. Having seen situations like this enough, I'm no longer even convinced that even I am correct when I think security isn't necessary. Maybe you're qualified to make that call, but even then, evaluating the system may be harder than just adding security.[1] 2. Just because your system doesn't need HTTPS now, doesn't mean it never will. YAGNI conveniently doesn't specify whether "A" stands for "Are" or "Aren't". In my experience, most systems involving HTTP do eventually have a requirement that passes sensitive data over HTTP, and it would be all-too-easy to forget that channel wasn't encrypted. 3. Even if you don't need encryption for yourself, do it for everyone else who does need encryption. Before HTTPS was required in every browser, users would happily submit their passwords over completely unencrypted channels. Now, browsers will give big warnings that hopefully prevent users from doing this. Those warnings probably aren't necessary if, for example, you're submitting an anonymous comment to a Disqus conversation. But it's important not to normalize clicking past those warnings for nontechnical users, because if they click past those warnings to post an anonymoust Disqus comment, they'll click past them to submit a password. And in a more political sense, normalizing encryption for stuff where it isn't important protects encryption for stuff where it is. "If you are encrypting you must be hiding something bad" is a dangerous narrative which is pervasive in politics, and default-on encryption is one of the best tools against that. [1] As an example of this, it appears that there are a few attack vectors in your own posts, which you either didn't think of or don't care about, but which I would very much care about as a user of your library catalog.
  • at_a_remove 6y ago
    I've heard these arguments. I am not unsympathetic. For the first, I don't know what to tell you. If they aren't qualified to know when security must exist, they are not likely qualified to implement it. For the second, when it is needed, it can be added. A staff directory with no interaction does not need it now. It may never need it. As to the third, in a story, here is a great argument against that: So years ago I ran this dumb little site, by request, for the users to submit stuff, nothing too special. They suddenly wanted the HTTPS, which was at that time outside of their budget, which was zero, and we would have had to move it off of a shared IP (this was some time ago). I told them it wasn't necessary for their use case. "But the LOCK thing makes it safe!" They were so insistent ... but they still demanded the results be sent to them over SMTP. Oh, how I facepalmed. I explained that SMTP was its own channel. No, no, they insisted. The LOCK. HTTPS can result in a false sense of security. At the end of the day, I think I would rather have choices available even if mistakes could be made. Removing choice from people for their own good is fantastic if and only if it will never ever cause any kind of issue on its own. Here, in the article, we discuss some of those issues. If HTTPS were possible to just implement retroactively with nothing ever breaking, not even some ancient software on a floppy disk, fine. For anything other, it's a tradeoff, and I believe for tradeoffs we ought to have the ability to assess the tradeoffs and make a choice. Even choices others do not agree with!
• icebraining 6y ago
  I don't even disagree that HTTPS by itself is not needed for that use case; but in my experience those "old custom appliances" are riddled with unpatched security holes and shouldn't be left open to the Internet anyway, lest they become zombie members of a botnet. Are those an exception?
  • at_a_remove 6y ago
    "Niche stuff where you had one or two vendors in the whole arena." If we didn't have them open to the Internet, we would have no service. There are no choices in that arena besides strawberry and vanilla. That is it, that is all. In this case, your requirement would result in the service not existing. This is not helpful to what we're trying to do.
    • pwinnski 6y ago
      I think the counter-argument here is that by existing in their current form, these products either are now, or will in the future be, used as part of botstorms, exploited for illegal purposes, etc. I'm sympathetic to your argument, but I've also seen a little tiny "I'm just storing a list of the CDs I own in a text file" apps blow up with multiple gigs of unwanted data, which _probably_ would not have happened with HTTPS. Overall I'm on the side of "there must be some exceptions," but I have to admit that every month it's harder and harder to think of what the legitimate exceptions might actually be, given the toxic nature of the internet.
• alexhutcheson 6y ago
  That seems like a case where a reverse proxy like NGINX[1] would be useful. The configuration would basically be: User->HTTPS over public internet->NGINX->HTTP on your private network->Custom appliances The most vulnerable link (the public internet part) would still be encrypted, and browsers won't show the scary warnings. The HTTP connection would be confined to your private network, where MITM is less of a concern. You can use one NGINX instance to reverse proxy multiple different appliances, so the maintenance overhead wouldn't be that high. [1] https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/ https://docs.nginx.com/nginx/admin-guide/web-server/reverse-...
  • at_a_remove 6y ago
    It's funny you should mention that. A new guy (who has since left) who was super into the Let's Encrypt thing before running up against the org policy of only using a certain certificate vendor, got excited about the "problem," used NGINX, and then had to take it down for reasons I wasn't privy to. I didn't look into the reasons why.
    • dicknuckle 6y ago
      Probably stepped on some toes. If they're not familiar with LE, it's because they think anything free has a catch, or they're just ignorant and want to keep sending money to Norton because that's the antivirus that came with their computer all those years ago.
      • at_a_remove 6y ago
        Oh, the guy who wanted NGINX was familiar with Let's Encrypt, but the org-wide policy was set somewhere far, far away from either of us. The approved vendor changed at least twice that I can recall.
• neurostimulant 6y ago
  As someone who live in an country with no net-neutrality and government-mandated censorship, I'm glad https is everywhere now. My government requires all isp to intercept all dns requests and plain http requests to block access to banned domains. Not only that, the ISPs are doubling down by blocking domains of competing services (the ISP I use block netflix for years to promote their own streaming service, only unblocking it recently after netflix finally partner with them). They also implement the blocking by intercepting http HOST header, so even if you somehow bypass their dns filtering, they can still got you if the censored site use plain http (they'll replace the response with a redirect to their censorship portal, which fully laden with ads). They also inject ads to any non-https page at least once every day. Thanks god for pihole and vpn (when I'm using mobile connection) I can still browse whatever I want.