Slashdot Mirror


Google Warns Webmasters About Insecure HTTP Web Forms (searchengineland.com)

In April Chrome began marking HTTP pages as "not secure" in its address bar if the pages had password or credit card fields. They're about to take the next step. An anonymous reader quotes SearchEngineLand: Last night, Google sent email notifications via Google Search Console to site owners that have forms on web pages over HTTP... Google said, "Beginning in October 2017, Chrome will show the 'Not secure' warning in two additional situations: when users enter data on an HTTP page, and on all HTTP pages visited in Incognito mode."
Google warned in April that "Our plan to label HTTP sites as non-secure is taking place in gradual steps, based on increasingly broad criteria. Since the change in Chrome 56, there has been a 23% reduction in the fraction of navigations to HTTP pages with password or credit card forms on desktop, and we're ready to take the next steps..."

"Any type of data that users type into websites should not be accessible to others on the network, so starting in version 62 Chrome will show the 'Not secure' warning when users type data into HTTP sites."

94 comments

  1. HTTPS is stupid by Anonymous Coward · · Score: 1

    Let's separate authentication of websites from encryption for privacy. Then there's no reason not to encrypt everything.

    1. Re:HTTPS is stupid by Anonymous Coward · · Score: 0

      It makes my proxy server far less efficient (unless I want to go to the trouble of installing certificates on all my clients).

    2. Re:HTTPS is stupid by Gaygirlie · · Score: 3, Informative

      What the hell are you babbling about? SSL-certificates aren't tied to IP-addresses, they're tied to domain-names! Hell, you can have hundreds of HTTPS-sites served by a single Apache-server with a single IP-address, all with different SSL-certificates, by using SNI!

    3. Re: HTTPS is stupid by Anonymous Coward · · Score: 1

      SNI - server name indication - fixes this problem for HTTPS. We host multiple SSL-enabled sites with different certs on single IP addresses.

    4. Re:HTTPS is stupid by bokkepoot · · Score: 0

      But then it won't support my IE on XP anymore..

    5. Re:HTTPS is stupid by Anonymous Coward · · Score: 0

      Or any App that embeds old IE.

    6. Re:HTTPS is stupid by beelsebob · · Score: 1

      And why do you give a shit about that. XP is an EOL, insecure operating system. There's litterally no reason to support it any more.

      And no - don't give my bullshit about "but my company runs critical systems on it" - THEY FUCKING SHOULDN'T BE RUNNING CRITICAL SYSTEMS ON AN OPERATING SYSTEM THAT'S KNOWN TO BE INSECURE.

    7. Re:HTTPS is stupid by i.r.id10t · · Score: 1

      And if you absolutely MUST run XP for something super critical, why the hell are you allowign that machine to browse the internet?

      --
      Don't blame me, I voted for Kodos
    8. Re:HTTPS is stupid by Anonymous Coward · · Score: 0

      We still run Windows 98 and DOS machines. Of course they are in VMs or special hardware, but it would never occur to us in a million years to connect such important machines to the Internet and most aren't even connected to a network at all. Plus, unless you know how to speak IPX/SPX, you won't do much good interfacing with those machines anyway.

    9. Re:HTTPS is stupid by thegarbz · · Score: 1

      Good. Your XP system should be forced off the internet. You're a threat to yourself and everyone else.

    10. Re:HTTPS is stupid by Anonymous Coward · · Score: 0

      If you don't authenticate the remote party, encryption won't do you much good because you could be having a private conversation with an attacker.

      Authentication and encryption go hand-in-hand. There's lots of legitimate criticism of how that authentication is currently achieved, but the system isn't secure without some authentication mechanism.

    11. Re: HTTPS is stupid by Anonymous Coward · · Score: 0

      They are tied to what ever it wants. Can be IP, can be domain.

    12. Re:HTTPS is stupid by Anonymous Coward · · Score: 0

      good, fuck anyone using any of that shitware!

  2. Nazi by Anonymous Coward · · Score: 0

    It's Nazi mania right now. Everyone you disagree with is a Nazi. Nazi's are everywhere!!

    BOO!!!

    1. Re:Nazi by Anonymous Coward · · Score: 0

      It's interesting how Trump has distracted us all from thinking he's a Russian stooge by making us think he's a Nazi sympathizer.

    2. Re: Nazi by Anonymous Coward · · Score: 0

      -1: Flamebait

  3. Chrome copies Firefox ... Again by narcc · · Score: 4, Informative

    Firefox added a warning a while ago. It's no surprise Google would follow suit.

    Chrome is really turning in to a slow, bloated, spyware-ridden Firefox clone.

    1. Re: Chrome copies Firefox ... Again by baker_tony · · Score: 0

      This isn't a story about cell phones, change your knickers and take a deep breath, lady!

    2. Re:Chrome copies Firefox ... Again by Gravis+Zero · · Score: 5, Informative

      Chrome is really turning in to a slow, bloated, spyware-ridden Firefox clone.

      Yeah, just like that time Chrome copied the Firefox layout and then dropped support for it's own extensions in favor Firefox extensions. Oh wait. ;)

      --
      Anons need not reply. Questions end with a question mark.
    3. Re:Chrome copies Firefox ... Again by williamyf · · Score: 1

      I think the parent should habve been modded +5 funny, instead of +5 Informative...

      --
      *** Suerte a todos y Feliz dia!
    4. Re:Chrome copies Firefox ... Again by Anonymous Coward · · Score: 0

      Except for the bit where Firefox is slower, and more bloated.

      Chrome is of course full of spyware.

      Which is of course why the correct choice is the fast, not bloated, and not spyware browser - Safari.

    5. Re:Chrome copies Firefox ... Again by thegarbz · · Score: 1

      Wow those people who modded you Informative are humourless or clueless.

      I laughed though :-)

    6. Re:Chrome copies Firefox ... Again by tepples · · Score: 1

      How many, realistically, are willing to carry a second computer or second phone just to run Safari?

    7. Re:Chrome copies Firefox ... Again by Z00L00K · · Score: 2

      You spelled Lynx wrong.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    8. Re:Chrome copies Firefox ... Again by Anonymous Coward · · Score: 0

      Firefox should add another warning when visiting webpages: WARNING! This page tracks and fucks your privacy by including google scripts.

    9. Re:Chrome copies Firefox ... Again by Anonymous Coward · · Score: 0

      The version 57 (nightly) is blazingly fast... and it really does use less memory. The only problem can be the extension update.

  4. There is a lot that doesn't need encryption.. by toonces33 · · Score: 3, Insightful

    This seems like overkill to me.

    1. Re:There is a lot that doesn't need encryption.. by Chai+T.+Rex · · Score: 1

      This isn't requiring encryption, so I don't see what the problem is.

    2. Re:There is a lot that doesn't need encryption.. by rklrkl · · Score: 2

      I think the problem here is that while you can easily identify a password field in a form (type=password), it's not so easy to identify other form fields that might contain personal information (you don't have to call the e-mail field "email" for example). Google is probably right at blanket-covering http forms with a warning that that they aren't https.

      The warning in Incognito Mode is on a bit less of a justifiable footing though, but it's the next logical step to warning about all http sites regardless of Incognito Mode or if they're forms or not. That latter step, though, would hit billions of pages, but might force a big adoption of https by the remaining http-only holdouts.

      A big shout-out to Let's Encrypt here, without whom I suspect this https-only tightening couldn't be been undertaken by any of the major browsers.

    3. Re:There is a lot that doesn't need encryption.. by Anonymous Coward · · Score: 2, Interesting

      This seems like overkill to me.

      Are you unaware that some ISPs and "public" wireless hotspots tamper with packets in-transit in order to inject ads?

      I want zero percent of my packets to be tampered with in-transit. We prevent that with encryption.

    4. Re:There is a lot that doesn't need encryption.. by tlhIngan · · Score: 1

      It's an annoying pain the butt.

      I mean, internal web applications don't need HTTPS, and yes, we can self-sign and force CA root to be distributed, but it's really just a pain in what is perfectly functioning software.

      The only way to hit them requires you to either be on the the local network, or VPN in.

      Firefox's warning is less than useful - the only way to disable it disables it for all sites, not just intranet ones. Chrome is probably going to be the same - disable it for all, or none, with no option to designate sites as intranet where the warning is suppressed and still have public internet sites have it.

      Yes, we can upgrade our systems, though the current web applications work well enough that justifying spending thousands to upgrade doesn't seem worth it. Especially since it works (though looks a bit dated)

    5. Re:There is a lot that doesn't need encryption.. by Anonymous Coward · · Score: 0

      I mean, internal web applications don't need HTTPS

      Because network traffic cannot be captured on an internal network ?

    6. Re:There is a lot that doesn't need encryption.. by Anonymous Coward · · Score: 0

      This seems like overkill to me.

      Quite the opposite: With all the government spying going on, this has actually become an absolute requirement in order to ensure people's privacy.

    7. Re:There is a lot that doesn't need encryption.. by Gavagai80 · · Score: 2

      The real danger here is that people are going to be so used to seeing "not secure" in their browser and being told "oh just go ahead and use it, this isn't important" that soon enough they'll start typing their credit cards into insecure forms again.

      --
      This space intentionally left blank
    8. Re:There is a lot that doesn't need encryption.. by thegarbz · · Score: 1

      Who decides if someone needs encryption or not? Do you know what all your visitors are being persecuted for? You're privileged enough to not need encryption for your specific data in your specific geo-political area. The same can not be applied universally.

    9. Re:There is a lot that doesn't need encryption.. by BradMajors · · Score: 1

      Google is supping all their data to the government. No change in privacy.

    10. Re:There is a lot that doesn't need encryption.. by swillden · · Score: 2

      This seems like overkill to me.

      I'd say it's insufficient. Everything should be encrypted and authenticated end to end, not just forms and form responses. Actually, it's really more important that data coming to your browser be authenticated than that data you send be encrypted. Why? Because unless your browser and OS are perfectly secure (they're not) then you have to trust every network hop between the server and you not to inject malware. With authentication, you only have to trust the server.

      And as long as you're authenticating all of the data, you might as well encrypt it, too, because some stuff does need to be protected and (a) it's not always obvious what does and what does not and (b) there's no reason not to just encrypt it all.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  5. Re: They should be by cunina · · Score: 0

    A week ago I would have modded this offtopic. Now I'm just mad you beat me to it.

  6. Version 62 Also Include Hate Site Warning... by Anonymous Coward · · Score: 0

    With way things are going, one can easily foresee so-called hate sites having their SSL certificates revoked; Chrome displaying a warning message / blocking access.

    As for encrypting everything, that makes sense from a security standpoint to better prevent the injection of bogus links, malware, etc in transit.

    1. Re:Version 62 Also Include Hate Site Warning... by BradMajors · · Score: 1

      By "hate", you mean non-SJW.

  7. Google that serves malware thru ads? by Anonymous Coward · · Score: 0

    How completely ironic. Google serves ads that infect users and they are lecturing on how to be secure? Please. Give us a break.

  8. Not worth the extra cost to buy a certificate by Anonymous Coward · · Score: 1

    My site has a contact page. I'm not going to spend the extra money to get a certificate just so Chrome won't kvetch about my site. I'll put verbage on the site explaining the error message in Chrome and if people don't want to contact me, I can live with that. Worst comes to worst, I can code the site to complain that Chrome isn't supported. I already do that with Internet Exploder.

    1. Re:Not worth the extra cost to buy a certificate by BlueKitties · · Score: 2

      Actually, it's free to set up HTTPS if you use letsencrypt.org. It takes roughly an hour of research to get it working, give or take depending on your current server setup. There are only a couple of gotchas: one, you have to make a certificate signing request file, .csr, which is easier on Linux than Windows. IIRC you can do it with Docker on a Windows machine. The second catch is, there are actually two files you have to put on your webserver, one is the private key, but the other is some "security key history" file that says where the security key came from. I can't for the life of me remember how that was setup, but it gave me some ugly unexplained "not secure" error in Chrome until some furious Googling surfaced the issue.

      Oh, and the third catch is, try to make the links embedded in your site use https, since an http frame embedded in an https frame isn't secure by virtue of the parent frame. Anyway, if you take the dive, expect a few headaches and unexplained "this page is not secure" experiences before you hammer out the bugs. But it's doable in a single weekend for free, and you get a nice professional looking https bar as a bonus.

      Also, some managed cloud services can turn on https for you with the push of a button, so it could be worth digging around in your settings if you're using a high level CMS / cloud host.

      --
      "Sorrow is better than laughter, for by sadness of face the heart is made glad." [Ecclesiastes 7:3]
    2. Re:Not worth the extra cost to buy a certificate by Anonymous Coward · · Score: 1

      You can get a free certificate from letsencrypt.

    3. Re:Not worth the extra cost to buy a certificate by Anonymous Coward · · Score: 0

      If you are manually creating a CSR, you're doing it wrong.

      Let's Encrypt is 100% automated; no manual steps are required unless you are on a platform that doesn't yet have a client script available.

      The big problem with Let's Encrypt is that it's not entirely straightforward to set it up in environments with load-balancers.

      For GP, if the response to this is "but I don't want to place my trust in some sketchy org." etc. then you have to remember that what you currently have is zero privacy for the data traversing the internet, and more and more browsers are going to start scanning your users.

        Using LE provides better privacy, requires minimal effort for a small site, and is 100% free.

    4. Re:Not worth the extra cost to buy a certificate by Anonymous Coward · · Score: 0

      so, cuz you're a lazy idiot, spammers can have a bot scrape your site for every email address entered?

  9. credit card forms by Anonymous Coward · · Score: 0

    If there are credit card forms, shouldn't they be reported to the cards (mc/visa/amex/jcb) so they can stop accepting transactions from unsecured (and definintely not PCI DSS compliant) pages.

    1. Re: credit card forms by Anonymous Coward · · Score: 0

      Yes, they are breaking PCI rules and should have their right to accept credit and debit cards revoked.

  10. Stop flagging self signed certs insecure by Anonymous Coward · · Score: 0

    While your at it, how bout not flagging self signed certs as insecure? You could flag it as identity not validated, but end the end a self signed cert means that the traffic between your browser and the web server has been encrypted.

    We could have had an all HTTPS web decades ago if the browser makers didn't pull this BS. Thankfully Lets Encrypt finally released free certs for all fixing this issue.

    Calling self signed cert HTTPS sessions insecure is like saying a SSH terminal session is insecure, since probably 99% of SSH terminal sessions are running on self signed certs that were generated when the OS was installed.

    1. Re:Stop flagging self signed certs insecure by Todd+Knarr · · Score: 1

      That or if Google supported CERT records in DNS properly. Then sites could publish their own issuing certs and, as long as they use DNSSEC, you could at least verify that the certificates belong to the entity that owns the domain (which is all that's needed for most purposes).

    2. Re:Stop flagging self signed certs insecure by green1 · · Score: 1

      We could also work on getting some of the registrars to actually support DNSSEC.... it's been "coming soon" to my registrar for several years now and I'm considering switching just because of it.

    3. Re:Stop flagging self signed certs insecure by tepples · · Score: 1

      end the end a self signed cert means that the traffic between your browser and the web server has been encrypted.

      And decrypted and reencrypted by a man in the middle.

    4. Re: Stop flagging self signed certs insecure by Anonymous Coward · · Score: 0

      Stop kidding yourself I'd you think the 3 letter agencies can't pull strings to get a valid cert for MITM

    5. Re: Stop flagging self signed certs insecure by Anonymous Coward · · Score: 0

      Https could have been designed to work the same way as ssh, store a fingerprint, if it changes then throw up alarms. Sites could have stored their current fingerprint as a record in their DNS entry to automate validation and to keep the spooks from planting their fingerprint on your 1st visit to a page

    6. Re:Stop flagging self signed certs insecure by ls671 · · Score: 1

      SSH doesn't use certificates as far as I know.

      --
      Everything I write is lies, read between the lines.
    7. Re:Stop flagging self signed certs insecure by Anonymous Coward · · Score: 0

      You can't be very familiar with SSH. Every time you connect to a new server you need to accept it's certificate. And every time the certificate changes you get a big warning. And more than 99% of SSH certs are self-signed, just like your parent said.

    8. Re:Stop flagging self signed certs insecure by ls671 · · Score: 1

      It isn't a certificate, it is a public key that you accept. Again, ssh doesn't use certificates.

      --
      Everything I write is lies, read between the lines.
    9. Re: Stop flagging self signed certs insecure by Anonymous Coward · · Score: 0

      Again, ssh doesn't use certificates.

      Again, you are wrong.

      Apparently you have never used ssh.

      Take a look at 'HostCertificate' in your sshd config file.

    10. Re: Stop flagging self signed certs insecure by ls671 · · Score: 1

      again, my sshd doesn't use certificates, only public/private key pairs:

        # ls
      moduli ssh_host_ecdsa_key ssh_host_rsa_key sshd_config~
      ssh_config ssh_host_ecdsa_key.pub ssh_host_rsa_key.pub
      ssh_host_dsa_key ssh_host_ed25519_key sshd_config
      ssh_host_dsa_key.pub ssh_host_ed25519_key.pub sshd_config.new
      # grep -i cer *
      #

      --
      Everything I write is lies, read between the lines.
  11. False sense of security by tepples · · Score: 1

    Self signed means false sense of security. The HTTP scheme without S means a true sense of insecurity. True sense is better than false sense.

    1. Re:False sense of security by Anonymous Coward · · Score: 0

      Self-signed is exactly as secure as CA signed. It's all the same encryption. You are confusing trust with security and confusing the CA racket for something that can provide meaningful trust.

  12. Manage your devices by tepples · · Score: 1

    Install device configuration management software on your clients, and deploy the proxy's root certificate through that.

    1. Re:Manage your devices by Z00L00K · · Score: 2

      The problem is that many sites serving over http only will be listed as insecure even if they aren't serving anything that would need encryption, and may not even have a login - or a login only for the webmaster. That covers many hobbyist sites.

      This essentially makes it more cumbersome to run a small website for hobbyist purposes.

      https only protects the data channel between server and client, it doesn't make a site more trustworthy today.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    2. Re: Manage your devices by Anonymous Coward · · Score: 1

      deploy the proxy's root certificate

      Until you're not given that option.

      "Oh, I'm sorry. Snapd won't support that because that might compromise security."

      "Chromebooks only support changing the cert store at the user level. It won't work with your federally mandated content filter because we protect our users."

      Apparently the people in charge of this crap have confused "trusted" with "authority". I.e. It's their authority that is to be trusted, NOT the system administrator's authority. Which defeats the entire purpose of TLS. (Nevermind it's a flawed system to begin with.) If the system admin wants their system to trust a specific certificate, but the system refuses to trust it, then the system itself has lost the trust of it's owner. Which means that there is no trust period over anything that passes through it. You can't establish a "secure" connection on a system that the owner doesn't trust.

      This isn't just an issue with proxies, but intranet sites too. I've had network appliances that were rendered inaccessible because a modern web browser wouldn't allow me to connect to it's management interface to upload a renewed certificate after the previous one expired. I had to actually install an older browser just to upload the renewed cert, all because the browser vendors up and decided that the user shouldn't be able to override the faulty cert and connect anyway.

      This crap is beyond broken, and for what? "Trust"? Where's the trust? It seems like, if anything, the developers don't trust the users, but demand the users trust the developers without question. Where I come from, that's not trust, it's blind faith.

    3. Re: Manage your devices by Anonymous Coward · · Score: 0

      This. Last I checked it's not even possible to get Android to trust user-installed certificates. If you install a CA that YOU trust on YOUR phone you'll need to click-through a "your device may be insecure" warning every time you start it up if.

    4. Re:Manage your devices by Anonymous Coward · · Score: 0

      The problem is that many sites serving over http only will be listed as insecure even if they aren't serving anything that would need encryption, and may not even have a login - or a login only for the webmaster. That covers many hobbyist sites.

      This essentially makes it more cumbersome to run a small website for hobbyist purposes.

      Do you think that was an accident? The biggest of the big boys doesn't want any dissenting viewpoints any more.

    5. Re: Manage your devices by tepples · · Score: 1

      That's because the person to whom you later sell on your phone doesn't trust the CA you added.

    6. Re: Manage your devices by Anonymous Coward · · Score: 0

      That's why there is a factory reset function. It's not my problem if you can't figure out how use it when you buy a used phone. That's the first thing you should do before even thinking about putting in your SIM card / telling your CDMA carrier to activate it. If you're too incompetent to be able to use the factory reset function, then you shouldn't be buying a used device of any kind in the first place.

      Further, just because you're incompetent, doesn't mean others should be forced to trust an untrustworthy device. The same function used to add the CA cert by the previous owner, can be used to remove it. If you can't use the factory reset function then you should at least remove the cert. But once again, if you can't use either you should stay away from used devices. For both your sake and the sake of the previous owner.

      Finally you've failed to address my original complaint. Whether or not someone later resells a device is irrelevent. The issue is the current owner of the device does not have the final say as to what is trusted and what isn't. It's the current owner's trust that is important, not the device manufacturer's. You may be willing to trust only what is preinstalled on your devices, but others may not be, and further, current developments are making not being able to trust a server's cert an issue. So this isn't something that can be discarded by hand-waving. This has real implications. Everyone has different levels of trust with others. The devices that they own need to reflect the levels of trust that their owners have if the notion of trust is to be preserved.

    7. Re: Manage your devices by tepples · · Score: 1

      The issue is the current owner of the device does not have the final say as to what is trusted and what isn't. It's the current owner's trust that is important, not the device manufacturer's.

      Then the current owner does have the final say. The interstitial mentioned by Anonymous Coward (#55051981) reminds the user that the current owner has exercised his final say.

  13. Feh by Anonymous Coward · · Score: 0

    I no longer care what Google has to say, considering that they believe they can censor whatever they want.

  14. Webhosts by Anonymous Coward · · Score: 0

    I often (lazily) use password fields to input text that is then used only by Javascript internal to a short page. No need for https, but firefox and chrome warn me regardless. And my webhost (1&1) wants to charge like I'm a business for anything more than a single subdomain on SSL.

    1. Re:Webhosts by Anonymous Coward · · Score: 0

      stop being so lazy and setup a vps for $4 or some shit. goddamn.

  15. I have a form on my site. by rew · · Score: 1

    They flagged my public wiki as falling under the new policy. So someone who posts something on this wiki runs the risk of having their contribution changed by a man-in-the middle. (besides running the risk of someone just going to the wiki and changing their contribution the proper way).

    1. Re: I have a form on my site. by Anonymous Coward · · Score: 0

      If your site is http only , it has been vulnerable to this the entire time, and also to some attacker seeing your users passwords and just being able to login as them.

      This change in Chrome is not that they changed some policy and NOW you are vulnerable, it's alerting your users to your EXISTING problem.

  16. Let's Encrypt issue on Playstation browser by billmarrs · · Score: 1

    I got this warning from Google about my site. A couple years ago, I got https working using Let's Encrypt. So, you'd think I could switch over 100% to https as Google is pushing me to do. But, what I've found is that there are a few odd browser/devices that don't work. A notable one is the PS3/4 web browser (my site is video-game related, so this is not entirely rare). Sony hasn't updated their root certs to include the one used by Let's Encrypt. So, my https does not work on a PS3 or PS4. Thus, I'd prefer to keep the site indexed with the http version, despite Google's pressure. I do have links up for the secure site and have tried to motivate people to switch (even use HSTS to make the switch sticky). About 28% of my signed-on users still use http. It's their choice.

  17. MITM has to intercept more connections for DV by tepples · · Score: 1

    Self-signed means the man in the middle (MITM) who intercepted the connection is decrypting what the server sends, storing it and/or altering it, and re-encrypting it to send to the client. CA-signed means the same MITM also had to intercept the CA's connection to the DNS when the server operator obtained the certificate, which is a bit harder to do for actors smaller than a nation-state. And it's even harder if the server operator regularly checks Certificate Transparency and/or Convergence.

    I don't see how Let's Encrypt, an automated domain-validated CA, is a "racket". DNS is more of a "racket", as people who operate an internally reachable server on a LAN have to buy a domain in order to qualify for a certificate.

  18. Incognito mode? by Anonymous Coward · · Score: 0

    Why would that be any less or more secure for the user? Or did they mean to say incognito mode on http site , which is insecure because it's http not because its incognito ?

  19. SSH warns that no fingerprint is stored by tepples · · Score: 1

    Https could have been designed to work the same way as ssh, store a fingerprint, if it changes then throw up alarms.

    It does work that way. The warning you see when visiting an HTTPS site whose certificate has an unknown issuer, such as a self-signed certificate, is analogous to SSH's warning that no fingerprint is stored for that hostname. A domain-validating CA is just a way to skip that warning. If you think that's a racket, then answer me this: How do you verify that no MITM is altering the fingerprint the first time you connect to an SSH server?

    Sites could have stored their current fingerprint as a record in their DNS entry to automate validation

    That's called DANE. It's not implemented in browsers because until less than a year ago, DNSSEC keys were 1024-bit RSA, and 1024-bit RSA is too short for current safety margin expectations. In addition, several registrars appear to charge extra for DNSSEC. There is a Chrome extension to run a DANE check on a certificate, but I don't know whether that or a similar Firefox legacy extension will survive the WebExtensions cutover.

    1. Re:SSH warns that no fingerprint is stored by Anonymous Coward · · Score: 0

      The problem is how scary most browser makers make that warning message. Most non technical users are just going to click the back button an go elsewhere.

    2. Re:SSH warns that no fingerprint is stored by tepples · · Score: 1

      The possibility that a man in the middle is intercepting an HTTP request whose URL specifically requested encryption should scare users. That's why OpenSSH's SSH and SFTP clients require the exact 3-character string yes when a fingerprint isn't stored instead of just letting the user press Enter. I'd prefer to go further, requiring the user to retype the first two and last two characters of the fingerprint.

      So let me repeat the question: How do you verify that no MITM is altering the fingerprint the first time you connect to an SSH server?

  20. Shut up you WUS by presidenteloco · · Score: 1

    Warrior promoting Unjust Society (or is that, Warrior for Unequal Statuses).

    --

    Where are we going and why are we in a handbasket?
  21. Playing chicken with national censors works by tepples · · Score: 1

    "Oh, I'm sorry. Snapd won't support that because that might compromise security."

    Use the --dangerous flag, or use the SNAPPY_FORCE_CPI_URL root environment variable to switch the machine to a different store. Or what am I missing?

    "Chromebooks only support changing the cert store at the user level. It won't work with your federally mandated content filter because we protect our users."

    Then perhaps Google should be playing chicken with a national government as a means of showing that said government's communications policy is harmful to its citizens' well-being by weakening security. When Wikipedia played chicken in June 2015, censorship dropped.

    It seems like, if anything, the developers don't trust the users

    Given how prevalent PEBKAC is, it saves the support department money not to have to trust the users.

    1. Re:Playing chicken with national censors works by Anonymous Coward · · Score: 0

      Nice double post.

      Use the --dangerous [snapcraft.io] flag, or use the SNAPPY_FORCE_CPI_URL root environment variable to switch the machine to a different store [github.com]. Or what am I missing?

      Because I want to recompile every snap I use just to change the trusted CA cert bundle? I don't think so. The whole point of snaps is to make deployment easier. This should be supported out of the box as a configuration option by default. Not something requiring GCC and snapcraft to be installed. At the very least they could trust the host system's root bundle. (Which is easily modified by an administrator with the appropriate permissions.) or the core snap needs the functionality (update-ca-certificates) added. Recompiling snaps everytime an update comes out just to change the CA bundle, renders snaps utterly pointless. I may as well just run a bunch of VMs, or install everything on the host manually.

      Then perhaps Google should be playing chicken with a national government as a means of showing that said government's communications policy is harmful to its citizens' well-being by weakening security [slashdot.org]. When Wikipedia played chicken in June 2015, censorship dropped [slashdot.org].

      Or maybe they should just enable the feature and let the device owner's decide. Hell they won't even enable it just for enterprise organizations. (The people who get paid to know this stuff and implement it properly.) Hell, in the case of the content filter, just enabling a local relay option for logins would eliminate most issues, as the biggest one is the filter not being able to identify a user prior to them trying to get out to the net, and blocking them as a result. (Because redirecting to a login page for the filter would require TLS interception at the system level* which Google won't allow.) Another would be to limit their oauth to just one subdomain instead of it hitting 5-6 of them and ending at their top level Google domain. (Because we all want to whitelist a search engine in a setting where content filtering is federally mandated, and any "objectionable" content is our liability. (Air quotes for "objectionable" because it's not defined in the law, so can mean literally anything.))

      * At system level because the user hasn't logged in yet, so the system only has it's own credentials to connect with. Which are useless because the ability to uniquely ID a chromebook is limited. (Can't even give it a host name.)

      Given how prevalent PEBKAC is, it saves the support department money not to have to trust the users.

      Boo, hoo. Cry me a river. PEBKAC is not an excuse. If anything the PEBKAC is not on the user's side but the developer's. And saving money? They could just as easily save money by removing the keyboard, touchscreen, and mouse, and doing everything themselves to ensure no-one will mess up. Hell, employers could just as easily save money by hiring someone who is competent enough to follow directions. The PEBKAC issue is an issue of poor user management, and an administration that doesn't care enough to enforce their own rules. Plus, most home users would never touch the CA cert list anyway. (Hence one of the biggest reasons why the current system is shame to begin with. No-one cares or even knows in many instances what or who they are trusting to begin with.) And as I already said, if you buy a used device, you need to wipe it before you start using it. That should be common sense, and for far more reasons than just the CA cert list having a potential modification. Hell, the previous owner should wipe it to protect themselves and their personal information before selling it, and that should be standard operating procedure at this point, but once again, that's a failure at multiple levels. A failure that should be addressed directly through education and legal liability (if needed), not indirectly by removing chances for screw up. As no matter how good a developer you are, a user will always find a way to screw it up, no matter how simple you make it. Teaching them what is expected of them and requiring it once taught, is a much better deterrent for screw ups and costly court cases.

    2. Re:Playing chicken with national censors works by tepples · · Score: 1

      Recompiling snaps everytime an update comes out just to change the CA bundle, renders snaps utterly pointless. I may as well just run a bunch of VMs

      If you have determined that snaps fail Debian's desert island test by making internal deployment of private applications unnecessarily difficult, then use --dangerous, or don't use snaps in your organization and write a blog post about why you chose to use something other than snaps in your organization.

      Because we all want to whitelist a search engine in a setting where content filtering is federally mandated, and any "objectionable" content is our liability.

      If you have determined that your country's laws prohibit use of a Chromebook, have you opened a support case with each Chromebook manufacturer to make them aware of this prohibition? If so, what was their reply?

      They could just as easily save money by removing the keyboard, touchscreen, and mouse, and doing everything themselves to ensure no-one will mess up.

      I can tell this is hyperbole because a product with no functionality will produce zero revenue. Let me rephrase: Taking away the user's ability to do dangerous things without explicitly acknowledging that they are dangerous strikes what a company has determined to be the appropriate balance among functionality, security, and support costs.

      Hell, employers could just as easily save money by hiring someone who is competent enough to follow directions.

      Good luck finding such an employee locally.

      Hell, the previous owner should wipe it to protect themselves and their personal information before selling it

      You sure love a certain town in Michigan, don't you?

      Anyway, the design protects the buyer who buys a used device from a seller who has wiped it to protect himself and then installed dubious software onto the freshly wiped device to spy on the buyer who is using a device that appears to have still been freshly wiped.

      A failure that should be addressed directly through education

      Who foots the bill for said "education"?

      and legal liability (if needed), not indirectly by removing chances for screw up.

      And who foots the bill for monopoly or oligopoly rents once "legal liability (if needed)" causes the market to contract as businesses go out of business on grounds that the cost of doing business has become prohibitive?

  22. Slightly misguided by presidenteloco · · Score: 1

    A page which was served by unencrypted HTTP but which posts its form data to an https url is secure.

    It just doesn't look secure to non-technical users.

    Of course if the site then sends the form data back up unencrypted (e.g. after server side value validation fails) that is then insecure, but no one with a brain sends the password value back up anyway.

    --

    Where are we going and why are we in a handbasket?
    1. Re:Slightly misguided by Anonymous Coward · · Score: 0

      If you serve the page without HTTPS then a MITM can tamper with it to make it send the data somewhere else in addition to the secure form target.

      (Yes, you could review all the source code of what your browser is running to ensure it's what you expected, but this feature seems aimed at the majority of people who can't or won't do that.)

  23. Fake news! by Anonymous Coward · · Score: 0

    They don't care about your privacy... AT ALL! Or your money or you for that matter. They care about control, and is what this move is about. Forcing those that self host their stuff come out and make themselves known by buying certificates. FU google!