5 ms·

His comment system is currently broken and will just 404 and return you to a URL at https://rants.org/%5Ehttp:/your.ip.addy.here/ https://rants.org/%5Ehttp:/you

• buildbuildbuild 3y ago
  “Least worst” is right. A quick nod to Tor Browser, the Firefox fork which will always support HTTP in order to support the vast majority of Tor hidden services.
  • yjftsjthsd-h 3y ago
    Onion addresses aren't CA-based TLS, but they aren't unencrypted HTTP either.
• nimbius 3y ago
  Couldn't I just stand up a quick CA with easyrsa scripts?
  • JoshTriplett 3y ago
    Yes, absolutely. Nobody else will trust it, but you can always set up your own CA for use by computers you use. Which is fundamentally still better than insecure HTTP, because it's at least possible to take steps to trust it and make sure it's the same server you expect to talk to.
  • superkuh 3y ago
    My typical website's visitor is someone on the other side of the earth I don't know and will never know. Getting my root cert in their trust store just isn't a feasible option in this extremely common use case for a public website.
• Aerroon 3y ago
  This sounds like a great way to get lots of people to run old software. I'm sure most people wouldn't even bat an eyelid when they go on to install an out of date browser to make sure a website they want to visit works. Security people can complain as much as they want, but it's these kinds of anti-user practices that makes users hate updating.
  • version_five 3y ago
    I'd guess that ship has sailed for many people. I never update my "consumer" software because every update makes it worse. I can't be the only one. Nobody is getting any kind of positive reinforcement on updating, best case scenario it does nothing, mostly it makes stuff worse or takes away freedoms.
    • nofunsir 3y ago
      I'm currently at 399 apps that "neeeeeeed" to be updated. I manually only update banking apps and the likes. And if an app forces me to update (lazy API devs!) I usually delete it and find a new one.
  • userbinator 3y ago
    Security people can complain as much as they want, but it's these kinds of anti-user practices that makes users hate updating. Indeed, I've always thought the classic saying about those who give up freedom for security is very relevant in the current times. I'm quite certain that it's possible to respect the user and improve security (for the user), but instead they've been using security as an excuse to do worse to the users.
  • johncolanduoni 3y ago
    This would likely be a great way to get lots of people to run old software for a while, until criminals take advantage of all those juicy unpatched vulnerabilities and all their devices start showing them ads for penis pills on every webpage and their credit card number gets stolen every other week.
    • 3y ago
• jacquesm 3y ago
  That would be pretty dumb then because there is plenty of older IoT stuff that you won't be able to access anymore with FF. Sick and tired of all these companies, foundations and other silos telling people what they can and can not do with their own hardware. If I want to visit scary non encrypted websites I should be able to do so.
  • cj 3y ago
    I agree you personally should be able to as a Haacker News user with 200,000+ karma. But I would prefer my grandma be blocked from all non-encrypted sites, sorry!
    • CamperBob2 3y ago
      What does your grandma think? Did anyone bother to ask her?
      • cj 3y ago
        What question would I ask her? (Seriously tho, how would you frame the question in a way my grandma, whose only access to the internet is via an iPad, could understand)
      • jdaxe 3y ago
        My own grandma doesn't know what encryption/HTTP/TLS etc are. I think for those who are uninformed it's a sane default to not trust self-signed certs. That said, there should be a toggle in preferences or about:config to allow it for those who know what they are doing.
    • tzs 3y ago
      That can be handled by a setting that defaults to requiring HTTPS. Maybe even make it remember the setting per site.
      • cj 3y ago
        IMO HTTPS should go in the direction of 3rd party cookies. Disabled by default, but easily available if you know how to change your browser settings to allow it.
• saulrh 3y ago
  Having personally experienced what happens to my webpages when Comcast realizes that it can do whatever it wants to bare HTTP requests all the way up to and including inserting invasive advertisements loaded with arbitrary javascript, I think that "least worst" is exactly the right word for requiring HTTPS everywhere. I do agree that it would have been nice if there was a standard that required encryption without also requiring authentication, but this is the world we live in now.
  • johncolanduoni 3y ago
    If it didn't require authentication, Comcast could just MITM you.
    • saulrh 3y ago
      Right, I knew I was forgetting something about that. Yeaaaaaah. And speaking of that, let's not forget about downgrade attacks! Removing HTTP is the least worst option in much the same way that you disallow RC4 when negotiating encryption for an SSH connection.
  • superkuh 3y ago
    I also had Comcast do that. It made my Steam (games service) browser un-usable one time. So in commercial contexts HTTPS makes sense. But there is more to the web than just the commercial, institutional, and the like. Websites that are run by human people without profit motive and without any need to be constrained by the realities of CA TLS exist. The major browsers are all about money these days so they'll prioritize the safety of monetary transactions above user freedoms. But just because this is the right decision for an profit driven company or institution doesn't mean it's the right thing for everyone and should be applied to everyone. In fact doing so will ruin the web.
    • saulrh 3y ago
      With advertising eyeballs and third parties in the loop there is nothing that is not "commercial". Do you think that Comcast would have refrained from injecting ads and attack scripts if you'd been browsing Wikipedia or the Internet Archive or your own personal blog instead of Steam? Do you think that they'd have gotten less money for those impressions or extracted less of your personal data? The use case doesn't matter because the attackers in the HTTP vs HTTPS case have their own monetization scheme and their own attack chain and they _do not care_ whether something is commercial or private.
• cj 3y ago
  You commented on another thread a few days ago (which I also replied to). I still don’t understand your distain for the idea of a 100% encrypted web. Rather than saying “does this remind you of anything”, can you tell us what it reminds you of? I guess the issue is, eventually, CA’s can decide not to issue certificates to certain people classified as malicious/nefarious/etc? Can you clearly articulate your position on this point?
  • Pannoniae 3y ago
    What happens when CA's say "you can't get a certificate if you supported <insert ideology here>"? Or "you can't get a certificate if you are racist"? Or "you can't get a certificate if your credit score is too low"? Or "you can't get a certificate if your website contains <pornography/warez/p2p encryption/firearms/anything we don't like>"?
  • jabbany 3y ago
    My guess is that if only encryption were the goal, then browsers should trust self-signed certs or at least upon first visit, present the cert and ask whether to trust it in the future. * Instead the current system depends on some set of built in trusted root certificate that's run by opaque monopolies (at least pre Let's Encrypt) plus a lot of hassle to add self signed certs if it's even supported at all. (IIRC some browsers like Chrome will ignore system trusted CAs in an attempt to "help the user be more secure" ref: https://serverfault.com/questions/946756/ssl-certificate-in-system-store-not-trusted-by-chrome https://serverfault.com/questions/946756/ssl-certificate-in-...) * There is precedent for this, for things like Remote Desktop or SSH where only encryption is the goal, their default behavior is exactly this: confirm upon first access, and remember the approved cert for the future. You do not need to get your server blessed by a CA to connect over ssh :)
    • throwawayadvsec 3y ago
      Yeah but SSH and RDP aren't used by grandmas that get their wallets emptied by scammers. Forced SSL everywhere is a good thing. It's bad that it's run by corporations, but it's still a good thing overall. Maybe it should be run by different people(like IDK ICANN over something like the UN)
• derefr 3y ago
  > a browser that can only visit websites that third party TLS CA corporations periodically approve Er... no. It means that Firefox will only connect to websites that the domain administrator of the system approves of. You, as the administrator of a computer, can install whatever X.509 roots of trust you want. Including a root of trust you own, which can issue certificates for whatever websites you approve of. Today, where there are residential users who can't get the attention of big companies, you'd probably then run a local forward-proxy that re-wraps connections to sites you trust, with certificates rooted in your root-of-trust. But this is just a sociological evolution of the original design intent of X.509: where each corporate/institutional/etc domain would directly manage its own trust, acting as its own CA and making its own trust declarations about each site on the internet, granting each site it trusts a cert for that site to use when computers from that domain connect to it. Just like how client certs work — in reverse. (How would that work? You'd configure your web server with a mapping from IP range to cert+privkey files. Made sense back when there was a 1:1 relationship between one class-A or class-B IP range, one Autonomous System, and one company/institution large enough to think of itself as its own ISP with its own "Internet safety" department.)
  • apostacy 3y ago
    > You, as the administrator of a computer, can install whatever X.509 roots of trust you want. Including a root of trust you own, which can issue certificates for whatever websites you approve of. That is a completely unreasonable assumption. The barriers of entry have been greatly increased. How many users have devices that they are really administrators of? Fewer and fewer. What is the technical challenge of setting up your own HTTP server that can be browsed with an off the shelf browser on your local computer?
    • derefr 3y ago
      > How many users have devices that they are really administrators of? Fewer and fewer. As long as nobody has forced you to join your computer to a domain and accept the installation of group-policy overrides, you're still fundamentally an administrator of that machine. You might not ever feel the need to administrate it, because the OS vendor is often co-administering the machine (see: Windows or macOS when you use a local account rooted in their cloud SSO) but the OS vendor hasn't restricted you from doing your own administration in the way that a corporation or institution administering the domain your device belongs to would restrict you. You still have the ambient authority to administer your machine, whether you ever bother to elevate yourself or not. You can still install your own X.509 roots of trust. Even on, say, iOS! (You must administer the iOS device using tools — e.g. https://github.com/ProfileCreator/ProfileCreator https://github.com/ProfileCreator/ProfileCreator — that run outside of the device on a "real computer"; but that's just a fact of history, to do with how system administrators generally prefer to interact with computers, not a property of the target device's security. A config profile is just a file format; if someone ever wanted to make a profile editor that ran on iOS itself, they could.) (And if we're talking about a machine that is corporate or institutionally controlled? Well, then it's the responsibility of the people who manage your device — your IT department — to decide whether a given cert should be given trust. Like it always was under X.509.) > What is the technical challenge of setting up your own HTTP server that can be browsed with an off the shelf browser on your local computer? The approach where you run a proxy that wraps untrusted connections into trusted ones is fully general, but yes, only really applicable to the most advanced users. But then, only the most advanced users really need and/or should want the full power of this approach. Only someone with a lot of experience in network security should consider themselves capable of vouchsafing a non-TLS HTTP connection as worth being trusted. You have to basically come up with a [continuously falsifiable!] "attestation heuristic" for the remote yourself — that it stays on the same IP, that its DNS records haven't changed owner, that the server is still sending the same Server response header, etc. (In fact, if the point is just to look at old websites that were never updated to use TLS, it's probably better to let someone else solve this specific problem for you, through a full application-layer compatibility forward-proxy service like https://theoldnet.com/ https://theoldnet.com/ .) If your needs are slightly weaker — if you can assume that every remote is at least using self-signed TLS certs rather than not using TLS at all — then the problem is vastly simplified: you can directly trust any cert by putting that cert directly into your X.509 trust store (in effect making it a root-of-trust — though it doesn't have the X.509 property that enables other certs signed by the cert to be trusted transitively, so it's a leaf-node root-of-trust. A "stump of trust", if you will.) You don't need to run any local servers to do this. And, at least in some cases (e.g. macOS Safari) it's just a few clicks to get from "this cert is invalid" over to "add this cert as a root-of-trust" (i.e. https://i.imgur.com/IXpF4ld.png https://i.imgur.com/IXpF4ld.png). The only problem with this approach, is that there will be no continuity of identity if the X.509 cert of the remote gets to the end of its lifetime and must be renewed. You must act in the capacity of the CA, figuring out again, from scratch, whether the new remote cert should be trusted. If your goal is to get together with a bunch of your buddies to escape the "X.509 CA cabal" by doing your own cert signing, you'd therefore be better off not using self-signed certs, but rather creating your own CA (probably an automated one using ACME!); importing that CA cert onto all your devices as a root-of-trust; and then having that CA sign certs for all your group members' sites. Then you'll get all the advantages of regular X.509, just in a sort of "overlay world" where your group's browsers can trust both regular sites and your private-world sites, while regular people who aren't part of your group will see a certificate error when visiting your group's sites (unless they also decide to import your CA as a root-of-trust.) (TBH, this would be kind of a cool "member's only club" to join. In theory, with sufficiently-advanced ACME probes, you could also enforce whatever properties of each site you liked, at least at time of issuance. You could create an "overlay web" that acts like Gopher/Gemini or whatever else you like, just by doing this.)
• TheBrokenRail 3y ago
  On the topic of user freedom, Firefox also doesn't allow installing extensions not signed by Mozilla unless you use a fork, Nightly, or Developer Edition (which is just a badly named beta)[0]. The hilarious thing is that Safari, the web browser from the company infamous for walled gardens and not letting you control your device, does let you install unsigned extensions on desktop[1]. [0]: https://wiki.mozilla.org/Add-ons/Extension_Signing https://wiki.mozilla.org/Add-ons/Extension_Signing [1]: https://developer.apple.com/documentation/safariservices/safari_web_extensions/running_your_safari_web_extension#3744467 https://developer.apple.com/documentation/safariservices/saf...
  • lapcat 3y ago
    This is actually no different from Firefox: "The Allow Unsigned Extensions setting resets when you quit Safari; set it again the next time you launch Safari." You can run an unsigned add-on in regular Firefox by opening about:debugging#/runtime/this-firefox and clicking Load Temporary Add-on... In both cases, it only lasts until you quit the app.
    • TheBrokenRail 3y ago
      And that's what I deserve for not reading the entire page. Thanks for the correction.