back to article Google publishes list of Certificate Authorities it doesn't trust

Google's announced another expansion to the security information offered in its transparency projects: it's now going to track certificates you might not want to trust. Certificate Authorities (CAs) that your browser (or smartphone) trusts have a suitable entry in “settings”, but if a site presents a certificate from an …

  1. Aniya
    Meh

    Re: Since users too often click through those warnings.

    As an admin is there actually ever a good reason to even allow such a behaviour on client PC's? IE & Chrome both have a GPO setting to forbid users from browsing past certificate errors and the like.

    The only time I received a legitimate complaint about this setting was when an insurance company we deal with felt that it was more productive to provide their customers a six-page PDF on how to add their self-signed certificate to our PC's trusted cert store because as we all know insurance companies are really too short on cash to spend a couple bucks a year on an entry-level SSL certificate.

    1. jtaylor

      Re: Since users too often click through those warnings.

      My home router uses a self-signed SSL certificate. I think Dell DRAC (lights-out module) does too.

      1. John Robson Silver badge

        Re: Since users too often click through those warnings.

        Surely no need for it to do so though.

        There is of course the question of what you are trying to do with said cert:

        - Authenticate

        - Encrypt

        Why not have a "public" root CA which anyone can sign their "self signed" cert with - but that is only trusted on RFC1918 devices

        After all - I suspect we're looking for data encryption, not authentication for these devices. You could even use the MAC address as part of the cert, and validate the connection against that as well (no routing allowed)

        1. Anonymous Coward
          Anonymous Coward

          Re: Since users too often click through those warnings.

          No, you should look for authentication also. If an admins connects to a remove device with admins credential (or any user using any kind of "privileged" credentials), authentication ensures nobody is playing anygender-in-the-middle. Without authentication, encryption could be quite useless, if you end up talking to Eve pretending to be Bob.

          If there were such CA, and I can generate a valid certificate for you network, and I'm inside it, I can MITM you and you'll never know.

          You don't need a public CA for internal use only. You can setup your own PKI, and get the full benefits of it, including authentication.

      2. A Non e-mouse Silver badge

        Re: Since users too often click through those warnings.

        My home router uses a self-signed SSL certificate. I think Dell DRAC (lights-out module) does too.

        And these can be replaced with CA signed certs.

        1. Anonymous Coward
          Anonymous Coward

          Re: Since users too often click through those warnings.

          One of the worst software to replace certificates for is VSphere. It does uses a damned command line tool written using a ugly combination of shell scripts and Java which is sound as a soap bubble. You need to follow a long list of manual steps and be very careful about the order of them. Also, beware of setting passwords with some special characters - or even spaces - within them, because they can break the scripts or Java code. If something goes wrong, there's the risk its services become unable to talk to each other, and cleaning up may be complex.

          The result is I've seen admins very wary of attempting it.

          Never understood why they can't write a tool which generates the certificate requests, then once the certificate and keys are available, performs the whole process without asking you to select each steps, and rolls back fully if anything doesn't work.

          1. Anonymous Coward
            Anonymous Coward

            @LDS Re: Since users too often click through those warnings.

            One of the worst software to replace certificates for is VSphere

            Amen to that! I once had a problem with vCenter 5. In the end I had to re-build it as VMWare Tech Support couldn't fix the certificate issue.

    2. Grahame 2

      Re: Since users too often click through those warnings.

      I would tend to agree, although in corporate environments the only root CA the clients need to trust is the in-house root, or better still, an intermediate signed by the house root CA. Everything passing through the proxy to the Internet will be getting resigned with this for IPS/DLP and general BOFH activities anyway.

      That way you only need to worry about external trusted CAs policy on the proxy.

      Many appliance's have self signed certs (Network Hardware, LOMs etc), by implication you suggest that admin/trusted client machines are not restricted, the Do-It-Right approach would be to replace the appliance public key with one signed by the house cert/intermediary. OK, someone will need to login initially to configure that, and I admit without the proper automation it would be a serious P.I.T.A. to admin, the reason it is the exception rather than the rule in most estates.

      But that is just for corporate environments, and the published trust log will be useful to both corporate admins (the proxy still needs to know who to (not) trust) and diligent home users.

      1. John Robson Silver badge

        Re: Since users too often click through those warnings.

        "I would tend to agree, although in corporate environments the only root CA the clients need to trust is the in-house root"

        Yes - although most companies don't MITM certain traffic (like banks etc) - they recognise that that would be seriously unethical.

        Hence my "public" CA for these devices, which would be well known and only valid within an RFC1918 domain, and potentially not even across routers. The idea is a limited mechanism for those connections to be trusted - which will satisfy home users, and will allow corporate users to get a proper cert on there easily.

        1. Grahame 2

          Re: Since users too often click through those warnings.

          Yes - although most companies don't MITM certain traffic (like banks etc) - they recognise that that would be seriously unethical.

          That does present an ethical issue, however maintaining a whitelist of 'good banks/sites' creates it's own problems.

          Sure you can setup a whitelist for current UK high-street banks, not that hard, but what if they change URLs/CAs (often banks use 3rd parties etc..) and what about discrimination against employees using overseas or boutique / sharia banking.

          You are also trusting the 'good/private' sites to never be hacked, never have their DNS/CA hijacked, never spread malware, not provide a vector for data exfiltration etc..

          The MITM policy should be clearly defined and can be made ethical by limiting functions to base URL logging, IPS/threat scanning & DLP scanning without logging non-flagged content (who wants to wade through that lot anyway?)

      2. Anonymous Coward
        Anonymous Coward

        "it would be a serious P.I.T.A. to admin"

        What are they paid for? Configure and manage properly devices, I guess? Configuring devices certificates (and update them when they expire) should be routine. There are ways to automatically deploy certificates (i.e Active Directory can do that, if the client supports it), but installing a cert is in most cases not that difficult (VSphere aside...). Or do you mean that also changing the default password could be a serious P.I.T.A for many admins?

        1. Grahame 2

          Re: "it would be a serious P.I.T.A. to admin"

          Yes, as I said without automation such tasks are a P.I.T.A. and generally therefore won't get done unless they are 'must do' tasks or linked to some KPI.

          Also installing the cert is not really the issue, it's getting it signed securely without automation, as has already been mentioned is not that hard to set up an in-house PKI and automate signing host certs.

          Did I mention, I am a big fan of automation.

          1. Anonymous Coward
            Anonymous Coward

            Re: "it would be a serious P.I.T.A. to admin"

            While some deploy can be automated, not everything can. To get a certificate, you need first to be authenticated in some other way - otherwise you're delivering certificates to world+dog and making thereby certificates useless. Also you need the right programmable APIs, sometimes they are there, sometimes not (and if admins find installing a certificate a PITA, there are good chances they find automating it a PITA too - unless already done by someone else, right?)

            You also need to design a PKI carefully. If you go the easy way with a single omnipotent CA, and certificates needs to be approved by a bearded hermit living in cave far away, getting a cert becomes a pain. If you have intermediate CAs dedicated to a single type of certificate (i.e. certificates for network equipment), you can delegate someone down the chain (still with enough privileges and accountability) to issue them, maybe even automatically if your deployment needs requires it, and your security policies allows for it.

            But as long as people believe basic security practices are a PITA, well, security will be what we've seen till now.

    3. Adam 52 Silver badge

      Re: Since users too often click through those warnings.

      I generate self-signed certs all the time.

      If you don't allow self-signed certs then you need to let develpers and Ops have access to create CA-signed certs, which opens up a whole world of leaked certificates and damaged reputation risk.

      1. John Robson Silver badge

        Re: Since users too often click through those warnings.

        I'm sure you can turn it off - or just run your own CA - and install the root...

      2. Anonymous Coward
        Anonymous Coward

        Re: Since users too often click through those warnings.

        We have our internal CAs (including intermediate ones) for development and management. Of course these are not valid outside our networks.

        For development, we have to ensure everything works properly in the real situation too (certificate chains, validations, etc. etc.). For system management, we have to spot any invalid or unconfigured systems, especially when administrative credentials are in use.

        Setting up a PKI is not that difficult - sure, it requires some work, and someone has to manage it, but it pays off.

        1. This post has been deleted by its author

        2. Grahame 2
          Thumb Up

          Re: @LDS Since users too often click through those warnings.

          Sounds like you have set up what I had in mind with the phrase 'Do-It-Right'.

    4. Vic

      Re: Since users too often click through those warnings.

      As an admin is there actually ever a good reason to even allow such a behaviour on client PC's?

      I have an invalid certificate on my webmail server. It is deliberate.

      From time to time, I will find myself on customer site where all the machines trust a local CA, and there is a MitM machine to intercept HTTPS traffic. I don't want my data to be intercepted. Thus, if I *don't* get a certificate warning when I try to connect, I know I cannot use my webmail from that location...

      Vic.

  2. Anonymous Coward
    Anonymous Coward

    And who put *GOOGLE* in charge?

    I'd start with not trusting Google, to be honest..

    1. RyokuMas
      Thumb Up

      Re: And who put *GOOGLE* in charge?

      Yup, these days Google definitely head up my "do not trust" list...

      ... shortly followed by Microsoft and Apple.

  3. Alan J. Wylie

    Error 404

    All of the google certificate transparency pages are currently (09:45) returning 404

    https://ct.googleapis.com/submariner/ is the correct URL according to both the official announcement and the list of known logs

    1. Anonymous Coward
      Anonymous Coward

      Re: Error 404

      What, you can't even Google it?

      Oh, wait ..

      :)

    2. Anonymous Coward
      Anonymous Coward

      Re: Error 404

      That's the base URL for the Certificate Transparency API - you have to add "/ct/v1/<ACTION>" after it, e.g. "/ct/v1/get-roots". If you're looking for something human-readable, check out https://www.google.com/transparencyreport/https/ct.

  4. Mr Dogshit

    Here's my list of companies I don't trust

    1. Google

  5. msknight

    Excuse me but....

    in an increasing number of cases, the user is not asked for what to do... but told that they ain't having it and that's that.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like