21 ms·

The people who are pushing back against HTTPS really bug me to be honest. They say silly things like “I don’t care if people see most of my web traffic like wh

• degenerate 9y ago
  I browse a popular gaming forum that has not implemented HTTPS. Chatting with the admin, the reason is simple: Ads. We can definitely blame the ad networks. Some have switched, but many won't work on https, and websites relying on ad revenue must stay with HTTP or make less money with HTTPS-friendly ad networks.
  • mattacular 9y ago
    Genuinely curious what kind of ads network/system you use that is not fully HTTPS compliant by now?
  • lern_too_spel 9y ago
    Those shady ad networks are going to get blocked by Chrome anyway, even without the HTTPS warning. Good riddance.
  • p49k 9y ago
    This hasn’t been true for at least a year. There is zero difference in ad revenue for HTTP vs HTTPS now. Join any major online community for publishers and ask anyone if you don’t believe me.
• Silhouette 9y ago
  If this is just a warning, that's one thing. If it becomes a solid block, it means more hassle for everyone running an intranet, and a huge liability for millions of long-lived devices with embedded web servers for browser-based configuration.
  • tjalfi 9y ago
    Chrome 64 is already a hassle for intranets. It adds "Not Secure" to the address bar whenever the user enters text on an HTTP site.
  • protomyth 9y ago
    Actually, I want a way to turn off the warning on my intranet because of all those printers, sensors, and control units on my intranet that are not going to get upgraded. I don't think I can find an HVAC or sensors with https, and I doubt anyone will authorize a 10's of thousand dollar replacement. I do not want a call anytime people have to deal with these devices and get a scary warning. Telling them to ignore it is not going to generate the right attitude when they go on the internet.
    • Silhouette 9y ago
      An inappropriate warning is still counterproductive, I agree, but it's in a different league to a solid block. Not so long ago, I was dealing with the browsers vs. Java applets war, which had a similar effect on many devices as they became progressively harder and ultimately impossible to use. The attitude demonstrated by many defending those browser changes -- as if completely and permanently breaking useful, long-developed, working software on a private network was somehow a good thing -- was somewhere between smug, dismissive and arrogant, and actually quite offensive in some cases.
      • protomyth 9y ago
        Developers often wonder why people use iSeries (AS/400) machines. Well, the software is long lived and keeps working. The whole IoT is not going to go forward when the software infrastructure is sand as opposed to stone. I get the feeling if this stuff keeps up, it would be wise for some infrastructure company (e.g. Honeywell) to sponsor an OS specifically for infrastructure with some version of a remote desktop to talk to it. Obviously, web browsers are the wrong way to control long lived devices.
• racer-v 9y ago
  My only concern is that the end user can always control which Certificate Authorities his/her browser accepts, and that anyone can set up their own CA. It seems like both of these conditions are vital for the future of decentralized web.
• userbinator 9y ago
  How is this controversial? I think it can be summed up in one old but very relevant-in-our-times quote: "Those who give up freedom for security deserve neither." At first, the idea that something is being done "for your safety and security" sounds good, but like all utopian goals, it has deeper connotations that are truly dystopian. As mentioned in another of the comments here, this is yet another instance of companies using the "more secure" argument to gain control over the masses and ostracise anything they don't like. They're harnessing fear and exploiting it to their advantage. To give an analogy in the real world, we don't lock ourselves in bulletproof cages and expend great efforts in hiding from others (for the most part), and I'm sure if your car's GPS indicated locations with high crime rates as "not safe" and prevented you from going there, there would be much outrage. We shouldn't let companies and (and try very hard, unfortunately not always succeeding for) governments dictate every detail of how we should live our lives offline, and the same should apply online. There's a very long tail of sites, many sadly disappearing from Google[1], of old yet extremely useful information, which are probably going to stay HTTP for the forseeable future. I made a comment about this in a previous "HTTP/S debate" article: https://news.ycombinator.com/item?id=14751540 https://news.ycombinator.com/item?id=14751540 Fortunately the only good thing that may come of this is that people will just start completely ignoring "not secure". And I have JS off by default and whitelisted on a very small number of sites, if you were wondering... [1] https://news.ycombinator.com/item?id=16153840 https://news.ycombinator.com/item?id=16153840
  • yzmtf2008 9y ago
    You have javascript disabled. I do not. I happen to use plenty of sites that require javascript, with HN being one of them. Most of the users out there do not have javascript disabled either. How do you account for their security? > and I'm sure if your car's GPS indicated locations with high crime rates as "not safe" and prevented you from going there, there would be much outrage. This is just a warning though, no one is preventing you from "going there", it's merely a warning that it might not be safe. Your analogy is more similar to "there's a slow down on that road, let me navigate you somewhere else, but feel free to go there if you want". You have exactly the same amount of freedom. How exactly is using HTTPS "gain control over the masses"? Google does not control the HTTPS infrastructure. It's not like those sites are gone either. There's always archive.org.
• jimmaswell 9y ago
  How would wifi portals work with only https?
  • pinum 9y ago
    Captive portals have always been a hack. I'm sure there'd be some interim solution, even if it's just hardcoded captive.apple.com as an exception.
  • gboudrias 9y ago
    They don't! Isn't that amazing? The only use I know for captive portals is EULAs, and I'm not sure those ever had legal weight (though obviously IANAL). But honestly they were starting to be outdated (technologically) even before this. Since a lot of popular sites use HTTPS, I usually have to try and think of a non-HTTP site before I can get through. They're just a nuisance at this point. This is not to defend Google's actions as "altruistic" in any way. But sometimes Google's interests and the public's do align.
    • jtl999 9y ago
      I just use http://example.com http://example.com for those
    • jimmaswell 9y ago
      >The only use I know for captive portals is EULAs What? You use them to log in with some criteria more than just a username/password. For example CableWifi hotspots that let you log in with TWC, Optimum, or others.
      • chainsaw10 9y ago
        > log in with some criteria more than just a username/password The problem there is that captive portals don't add any extra link-layer security. The network is open, so literally anyone can sniff packets. It's uncommon, but a network using WPA2-Enterprise and user/pass uses different keys for each person (not sure if per device or per user), so you don't have to trust everyone in the room.
• orivej 9y ago
  If you have to use an internet provider that does not provide reasonably direct access to the internet, you should tunnel your traffic through the service that does (e.g. a VPN). The idea that all internet sites have to compensate for the low quality of the last mile of some users simply does not make sense. If a site accepts sensitive input from the users than sure, it needs an authenticated and encrypted connection; but if it serves static content, it may hold the internet infrastructure and the receivers responsible for the correct delivery.
• droopybuns 9y ago
  The existence of vulnerabilities doesn’t negate the bullshit security theatre of certificate authorities. Banning http is a great example of tossing the baby with the bathwater. Https is better, but there are still valuable use cases for unencrypted web traffic. I am sorry this bugs you, but please note that your straw man is not the argument I’d make. Sometimes you need a low hassle web server. Renewing let’s encrypt certs is not low hassle.
  • Cyphase 9y ago
    > The existence of vulnerabilities doesn’t negate the bullshit security theatre of certificate authorities. I agree that the current CA system has flaws, but there are efforts such as Certificate Transparency[1] and DANE[2] attempting to improve or bypass the CA system. That said, just having encryption defeats passive eavesdropping, and even the current CA system of authentication raises the bar for active eavesdropping. > Banning http is a great example of tossing the baby with the bathwater. I'm not sure what you mean by that. > Https is better, but there are still valuable use cases for unencrypted web traffic. Like what? [1] https://en.wikipedia.org/wiki/Certificate_Transparency https://en.wikipedia.org/wiki/Certificate_Transparency [2] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
    • dozzie 9y ago
      >> Https is better, but there are still valuable use cases for unencrypted web traffic. > Like what? Things like this: https://utcc.utoronto.ca/~cks/space/blog/tech/BIOSViaHTTPSensible https://utcc.utoronto.ca/~cks/space/blog/tech/BIOSViaHTTPSen...
      • Cyphase 9y ago
        Let's take it as given that HTTP is the right answer in that situation; I'm not saying it is or isn't, but let's assume it is. We're talking about HTTP(S) in web browsers and client-side applications; no one is actually talking about _banning_ HTTP, e.g. blocking port 80 or filtering via deep packet inspection. If you have a use case where after careful thought you decide that HTTP is better than HTTPS, then fine. But HTTPS should be the default.
• gear54rus 9y ago
  People who cheer for tons of stupid fucking HTTP warnings all over the place really bug me to be honest. Anyone who uses the web needs to be taught the difference between a secure and insecure connection and told where to look for signs (this assumes we burn stupid shit browsers that look to mangle URL bar by removing data from it). The grandma will not make better decision if you put in another dumb warning like this one https://i.imgur.com/rxmyWtF.png https://i.imgur.com/rxmyWtF.png to waste more and more of my time when I enter my password on the same website over and over. I KNOW IT'S INSECURE, JUST STFU already. I'm at the point where I will look to build my browsers from source after removing that shit (along with removing inability to add certificate exceptions for certain situations). Good thing they're open source.
  • JoshMnem 9y ago
    > this assumes we burn stupid shit browsers that look to mangle URL bar by removing data from it That's just about every browser now. I think that full URLs are only available in Firefox, and only if you set `browser.urlbar.trimURLs` to `false` in about:config. Hiding URL information is a very bad trend.
    • briandear 9y ago
      You can show full urls in Safari if you want.
      • Miredly 9y ago
        also Opera.
      • JoshMnem 9y ago
        Safari is the worst by default. I don't have any Apple devices, but when I look at screenshots of Safari's URLs, they are not full URLs. Also, it looks like you can't show the full URLs on iPads or iPhones. (You can on Firefox for Android.) Not a full URL: example.com Not the full URL: http://example.com http://example.com (the page will load after completing the URL with a trailing slash) This is the full URL for the homepage of example.com: http://example.com/ http://example.com/
• hartator 9y ago
  I would have trouble following security advice from a company that was serving mining ads directly from its websites last week. Main argument in favor of http would be it's making browser fingerprinting harder from a privacy standpoint. Https by itself let the server identifies its clients individualy without cookies.
• aurelian15 9y ago
  My primary concern are local servers ‒ which of course, are irrelevant if you are a centralised service provider such as Google. To provide some context, I'm currently working on a web application where the server is intended to be running inside a home network (where the server requires zero configuration by the user). As of now, some of the JS APIs I'm using are only available if the site is running in a secure context, so the server has to serve the application using HTTPS, otherwise some functionality won't be available. However, it is impossible to obtain a valid TLS certificate for this local connection -- I don't even know the hostname of my server, and IP based certificates aren't a thing. So basically, to get a "green lock symbol" in the browser, the server would have to generate a random CA and get the user to install it, which comes with its own severe security risks and is not an option. So my current plan is to have a dual-stack HTTP/HTTPS server, which on first startup generates a random, self-issued certificate. When the server is first accessed using HTTP, the client automatically tries to obtain some resources via HTTPS. If this succeeds, the user is redirected to the HTTPS variant. If it fails due to a certificate error, the user is presented with a friendly screen telling her that upon clicking "next" an ugly error message will appear, and that this is totally fine. Oh, and here's how to permanently store an exception in your browser. Still, the app will forever be marked as insecure. Although it isn't. It is trivial for the user to verify that the connection is secure by comparing the certificate fingerprint with that displayed by the server program she just started. This sucks. It just seems that Google and co don't care about people running their own decentralised infrastructure; and marking your own local servers as "insecure" does definitively not help.
  • deleted 9y ago
    [deleted]
  • fulafel 9y ago
    You are deluding your users if you convey the idea that home networks are separated the internet. Or that traffic on a home network is safe and doesn't need TLS. Can't you just put up a domain can give your users subdomains on that?
    • aurelian15 9y ago
• legulere 9y ago
  The attack surface of browsers is relatively small if you keep them up to date. Browsers were early in including meltdown and spectre. Running JavaScript is pretty harmless. On the other hand https makes the web performance horrible
• ori_b 9y ago
  > Now consider that things like Meltdown and Spectre have JavaScript PoCs. How is this controversial? Please explain to me how Javascript delivered from a malicious ad delivered over HTTPS is somehow safer. Most malicious code is delivered with the help of the website. This post was written with no javascript enabled.
• coldtea 9y ago
  >Now consider that things like Meltdown and Spectre have JavaScript PoCs. How is this controversial? Seems totally irrelevant, since any "legit" site with a $10 certificate will still be able to inject malicious code, either by its operators putting it there directly, or by it being hacked -- whether there's a man in the middle or not. And with something like Spectre out there, https wont do anything.
  • jefozabuss 9y ago
    There is a quite big difference between the site injecting it or having it injected via ISP.
    • coldtea 9y ago
      Yes. That you can trust ISPs (few, large companies) more than random websites.
      • Avamander 9y ago
        How can you trust someone with a known track-record of violations more than a small website admin?
        • coldtea 9y ago
          It's easier to trust someone with a "known track-record of violations" than millions of random websites.
• rrcaptain 9y ago
  There is a non-zero impact of HTTPS on the size of a webpage. This can be bad for users on bad connections.
• zimbatm 9y ago
  My only issue is HTTP/2 client and servers only implementing TLS. This makes it unnecessarily hard to reverse-proxy HTTP/2 on a loopback connection where it's reasonable to assume being safe from MITM.
• soname 9y ago
  I would have nothing against it, if browsers just disabled Javascript on plain-HTTP web sites. I do it anyway by default, enabling it on domains where it serves some useful purpose. Treating non-HTTP content as untrusted makes absolutely sense (though I don't think that HTTPS really makes a https://random.l33t.site/ https://random.l33t.site/ a trusted source of anything). The old simple plain-HTTP plain-HTML web is still useful and practical for showing text (don't care much even about CSS - HTML 3.2 is perfectly suitable for showing readable information). It seems to become a victim of collateral damage in the pursuit of "better web", which is sad.
• xg15 9y ago
  > However, you have to recognize the fact that you run JITed code from these sites. I guess browsers could then make an effort to help sites use scripts only when absolutely necessary and give users easy to use tools to disable scripting. But, oh wait, they do the exact opposite.
  • nileshtrivedi 9y ago
    Or the users could switch to browsers that disable Javascript, third-party cookies by default instead of the ones controlled by advertising and DRM monopolies. But, oh wait, they do the exact opposite.
• tonetheman 9y ago
  To be clear the ONLY reason this is happening is to make sure that any ad served from Google is not tampered with. This is protection for their money making machine. Plain and simple.
  • vntok 9y ago
    Of course it is not the ONLY reason.
    • tonetheman 9y ago
      There are some drive-by benefits but I would imagine money/ad delivery is the ultimate purpose.
• dec0dedab0de 9y ago
  Maybe just disable js on port 80, let 443 be for web apps and 80 be for web pages.
  • corey_moncure 9y ago
    What a great idea this is!
• peterwwillis 9y ago
  You don't need HTTPS to verify integrity. HTTPS actually adds attack vectors, complexity, and removes useful functionality like proxies. And like another commenter mentioned, most malware is delivered from an authentic site anyway. HTTPS evangelists are basically playing a game of political ideology shrouded as concern for safety. I think they care more about their own privacy than they do the functionality, security, and maintenance required for HTTPS sites. It's also not coincidental that Google has a vested interest in keeping all traffic surrounding their services hidden or obfuscated: traffic content and metadata is money. Google is basically eating the lunch money of ISPs' passive ad revenue. (This is also part of why they want to serve DNS over HTTPS)
  • floatboth 9y ago
    How else would you practically verify integrity for web browsing? What's wrong about caring about your privacy?! Why the hell do ISPs deserve ad revenue? I don't like Google either, but ISPs that want to tamper with connections to inject their ads can fuck off and die in a fire. That is more unethical than anything Google has ever done.
    • peterwwillis 9y ago
      > How else would you practically verify integrity for web browsing? Download a signature once, verify any file before rendering it. You could even control this behavior using an HTTP header if you wanted granular control. It would be a trivial extension. Today, nobody verifies that content was created by the author. That content can be subverted on the web server, and this is how malware is distributed today. Verifying content with a signature would actually be more secure than just TLS. > What's wrong about caring about your privacy?! Ignoring all the other concerns for the sake of it, is what's wrong. > ISPs that want to tamper with connections to inject their ads can fuck off and die in a fire. That is more unethical than anything Google has ever done. Google reads your e-mails and search history and tracks where you go on the internet, and sells the information to advertisers, who then display the ads no matter where you are or what you're looking at - including over HTTPS pages.
• JohnTHaller 9y ago
  As for reasons, there are tons of folks with personal websites on providers that only offer expensive yearly certificate options. Most CDN providers don't support LetsEncrypt. Most shared hosts don't. The Cloud Sites platform for multi-site shared hosting (formerly RackSpace, now at Liquid Web) that I use for a dozen of my friend's sites I host for free doesn't. So, essentially, this means that personal hosted websites either stay 'not secure', get ditched, or increase in price quite a lot. Yes, it's just 5 to 10 bucks a month to spin up another instance on Digital Ocean, but it's yet another 'server' to manage when I'd rather decrease the number than increase it.
  • deleted 9y ago
    [deleted]
• ksk 9y ago
  The fact that people want to force HTTPS really bugs me. HTTPS centralizes the publication rights to browser vendors and cert vendors. Why should you require permission before publishing content on the web? IMHO, They should rename the S in HTTPS to $. I believe that Google's intentions here are to block other pass-through internet entities from collecting advertising data. Obviously, Google would never encrypt user data so that they couldn't mine it. Personally, I am more worried about Google mining our data than some rinky dink ISP. Also, could you link to the PoCs? I have not seen a reliable PoC but maybe I haven't look that hard. The ones I've seen only work on specific CPUs, and only if certain preconditions are met. But anyway, that is a separate discussion.
  • wishinghand 9y ago
    > IMHO, They should rename the S in HTTPS to $. This is an absurd thing to say when Let's Encrypt exists.
    • ksk 9y ago
      Why is it absurd? So I either have to pay a CA vendor, or I have to ask Lets Encrypt permission to renew my cert every 90 days. In any case, why should I be forced to support a model where I have to beg for permission to host anything. I believe in stating my opinions and let others make up their own mind. The opposition believes in forcing everyone to adopt their position by fiat. Why not put the information out there, and let people switch to HTTPS if they feel like the benfits make sense to them.
      • dragonwriter 9y ago
        You aren't forced to do anything. If you choose to use HTTP, you can, and no one will stop you. The Chrome omnibox will accurately report to users that your site is insecure, if you do, but that's just making them aware of a basic fact.
        • ksk 9y ago
          >The Chrome omnibox will accurately report to users that your site is insecure What evidence does Chrome have that my site is insecure or poses a threat to users? 'What could happen' logic would mean disabling all browsers since you could get pwned by using any of them. That is not a rational way to approach anything.
• aplorbust 9y ago
  The simpler solution is to not run that code. The imaginary user cited does not need that code in order to "browse memes". The code is there for advertising, e.g., to attract advertisers as customers by gathering data about users. Hence the push to HTTPS is for companies that aim to generate revenue from selling access to or information about users to advertisers. I have no problem with HTTPS on the public web, to the extent that it is the concept of encrypted html pages, and perhaps these are authenticated pages (PGP-signed was an early suggestion). Encrypt a page of information (file), sign it with a public key and then send it over the wire . The wire (network) does not necessarily need to be secure. However I do have a problem with SSL/TLS. I would like to leave open the option to not use it in favor of alternative encryption schemes that may exist now or in the future. It seems one allegedly "user-focused" company wants to remove this option. Comply with their choice or be penalized. The issue I have with TLS is only to the extent TLS is the idea of setting up a "secure channel" to some "authenticated" endpoint (cf. page), with this authentication process firmly under the control of commercial third parties, using an overly complex protocol suite and partial implementation that is continually evolving (moving target) while people scramble to try to fix every flaw that arises out of this complexity. To the extent it is not what I describe, I have no issue. (That is, I'm pro-TLS.) We have one company aiming to replace HTTP with their own HTTP/2 protocol, which to no surprise has features that benefit web app developers and the advertisers they seek to attract far more than they benefit users. Could we design a scheme to encrypt users web usage that would not benefit advertisers? I think yes. But this is not what is being developed. Encryption today is closely coupled with the "ad-supported web". If we are not careful, this sort of policy pushing by Google could cripple the non-ad-supported web that existed before the company was incorporated. Encrypted "channels" are not the only way to protect information transferred via the web. TLS is not the only game in town.
• deleted 9y ago
  [deleted]