Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Dark Side of Certificate Transparency (sans.edu)

Posted by EditorDavid on from the extra-credentials dept.

Slashdot reader UnderAttack writes: Certificate Transparency is a system promoted by companies like Google that requires certificate authorities to publish a log of all certificates issued. With certificate transparency, you can search these logs for any of the domains you own, to find unauthorized certificates. However, certificates are not only used for public sites. And with all certificates being published, some include host names that are not meant to be publicly known. An update of the standard is in the works to allow entities to obfuscate the host name, but until then, certificate transparency logs are a good recognizance source.

41 of 62 comments (clear)

  1. recognizance ?! by Anonymous Coward · · Score: 3, Insightful

    I don't think you know what that word means!

    1. Re:recognizance ?! by pahles · · Score: 1

      recognizance |rk()nz()ns| (also recognisance)
      noun Law
      a bond by which a person undertakes before a court or magistrate to observe some condition, especially to appear when summoned. the Lord Chancellor asked them to enter into recognizances to appear in court. he was released on his own recognizance of £30,000.

      --
      Sig?
  2. Stupid by Anonymous Coward · · Score: 2, Informative

    This is stupid. Transparency is good. Don't rely on security through obscurity. If that's your method to keep secrets, you deserve what you get. There's no legitimate reason why you should have a secret hostname that's not otherwise secured, if you don't want people accessing it.

    1. Re:Stupid by davester666 · · Score: 1

      just great. Now I, the fucking CFO, have to enter a password before I can gain access to the accounting system. How the fuck am I supposed to do that on this fucking tiny cell phone screen, in broad daylight, on the 7th hole. I have to fucking walk all the way back to the cart, just so I can see the fucking tiny little fucking letters.

      --
      Sleep your way to a whiter smile...date a dentist!
  3. Hostname leaks and internal CA by plsuh · · Score: 5, Insightful

    1) Hostnames leak all the time. A client will make a DNS request and the name becomes known even if it is not resolvable on the public Internet.

    2) If you really care that much, run an internal CA. Lots of ways to do it, most server OS's have built-in or easily available internal CA software.

    Keeping a hostname out of the certificate log is pretty much pointless security by obscurity.

    1. Re:Hostname leaks and internal CA by dmbasso · · Score: 2

      Very well said. I have no mod points, so here's my virtual +1.

      --
      `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
    2. Re:Hostname leaks and internal CA by ErikTheRed · · Score: 3, Interesting

      Exactly. We use an internal CA (there are several good ones out there like EJBCA) for all of our private internal hosts.

      --

      Help save the critically endangered Blue Iguana
    3. Re:Hostname leaks and internal CA by CanadianMacFan · · Score: 1

      I created certificates for our development servers and QA machines at one job. Previously we just put the certificate from the production server on and everyone was tired of having the warning pop up but nobody was going to pay to get real certificates. We had a lot of different host names because it was a government department that had been created from a group of smaller departments who wanted to keep their domain names plus any names for campaigns. The developers and testers just had to trust the new issuer in the browser once and then they wouldn't get a warning about the certificates again. Saved them a lot of frustration and the department a lot of money (approximately 100 certificates when they were expensive to get).

    4. Re:Hostname leaks and internal CA by TheRaven64 · · Score: 4, Insightful

      The second point doesn't make a difference. If your clients support certificate transparency, then they will publish any server certs that they come across. It doesn't matter what the cert is. The real point, however, is that if the machine should not be routable from outside of your network, then you should not make it routable from off your network. Assuming that the hostname (or IP) is secret is silly.

      --
      I am TheRaven on Soylent News
    5. Re:Hostname leaks and internal CA by tepples · · Score: 1

      The real point, however, is that if the machine should not be routable from outside of your network, then you should not make it routable from off your network.

      If a machine is not routable, how will Let's Encrypt or any other DV CA know that you have enough control over a machine to be entitled to a certificate for its hostname?

    6. Re:Hostname leaks and internal CA by wvmarle · · Score: 1

      Why bother with those external CAs?

      That's what point 2) of OP is for. Private hosts, private network, private CA. By the time you're running your own private hosts on your own private network, it's for sure a no-brainer for your IT staff to run their own CA and register it as trusted CA in all internal computer systems.

  4. solving the wrong problem by lkcl · · Score: 2

    y'know... it occurs to me that seeing CENTRALISED trust mechanisms break down really is no surpise, at all. it's a simple mathematical equation which can be explored by doing e^(1/N) * N where you increase N, then make a tiny *tiny* change in the 1/N value. so E^(1/100,010) * 100,000 for example is drastically divergent from E^(1/100,000) / 100,000. point being: the more you CENTRALISE trust, the greater the chance of it being violated (exponentialy greater)

        solving this will take moving away from CENTRALISED trust to DECENTRALISED trust. does anyone remember keynote (an IETF RFC), or advogato, or even the moderation system behind slashdot, and how effective those are? we really really need to start moving to things like blockchain. as in, don't arse about expecting the incumbents to move to blockchain (because they have financial incentives not to do so) - just move to blockchain-based SSL Certificates.

    1. Re:solving the wrong problem by lkcl · · Score: 3, Informative

      huh. like this. how about that - someone's already done it. https://github.com/okTurtles/d...

    2. Re:solving the wrong problem by Anonymous Coward · · Score: 1

      blockchain-base SSL?

      Does that make any sense at all?

      Sounds to me like "lets all move to cloud-based furniture!"

    3. Re:solving the wrong problem by cryptizard · · Score: 1

      I take it you are the one that posted a reply on the SANS site about okTurtles? You should probably know how it actually works before you endorse it because it is broken, according to Namecoin developers who make the technology that it uses.

      Second, you are effectively posting off-topic because a blockchain solution will not address the problem from the article AT ALL. Namecoin, on purpose, makes all of the certificates public. Certificate transparency is a key feature of any blockchain-based solution. People will still see all the domains for which certificates have been issued.

    4. Re:solving the wrong problem by Lehk228 · · Score: 1

      blockchain is automatically retarded, if you take over 50%+1 you control everything.

      --
      Snowden and Manning are heroes.
  5. If the host name should not be publically known by drolli · · Score: 2

    then you should not need any certificate form any CA but yourself.

    1. Re:If the host name should not be publically known by tepples · · Score: 1

      then you should not need any certificate form any CA but yourself.

      Let's assume that an appliance on a home LAN needs an X.509 certificate for HTTPS on its web-based administration interface. Let's further assume that the device acts as its own CA to issue this certificate. What would be the easiest way to get this device's CA trusted by the Windows, macOS, Android, and iOS devices on the LAN?

    2. Re:If the host name should not be publically known by tepples · · Score: 1

      establishing trust between the proxy and your LAN clients simply requires installing your intermediary internal CA certificate on client devices.

      Are instructions to install an internal CA's root certificate easy for a home user to find and follow on Windows (home, not Pro therefore not on a domain, and definitely not Enterprise), macOS, Android, and iOS? I thought certain operating systems intentionally made root certificate installation hard to do in order to deter social engineering attacks on the PKI underlying TLS.

    3. Re:If the host name should not be publically known by tepples · · Score: 1

      The working plan is to provide such resources through the proxy's admin panel, along with step-by-step instructions for platforms where multiple manual user actions are required.

      Where "the proxy" was previously defined as "a small proxy system (physical or virtualized) that is configured to provide TLS service to LAN clients based on your internal CA". But in this case, the first access to "the proxy's admin panel" would itself produce a certificate error. How does the user access the device for the first time?

  6. Security through obscurity of interna domain name? by Wrath0fb0b · · Score: 4, Informative

    Seriously, does this bozo think that there is any security benefit if an attacker doesn't know your internal domain names? What in the world does that buy?

    PS. Editors: reconnaissance != recognizance. Holy hell what a train wreck.

  7. Certificate Transparency? by fustakrakich · · Score: 2, Insightful

    Don't you think that Certificate Security would be the priority?

    An update of the standard is in the works to allow entities to obfuscate the host name..

    So now the whole idea becomes entirely useless, aside from the public relations.

    Certificates are cookies, just another word with more syllables and some different letters.

    --
    “He’s not deformed, he’s just drunk!”
    1. Re:Certificate Transparency? by cryptizard · · Score: 1

      The proposal is to redact subdomains in the certificate log. That won't impact security at all, but will solve this problem. You can still see if a CA issued a certificate for a domain that they shouldn't. The only time this could lead to confusion would be if you own a domain for which you have multiple subdomains with certificates signed by different authorities, which probably doesn't (or shouldn't) happen.

    2. Re:Certificate Transparency? by tepples · · Score: 1

      The only time this could lead to confusion would be if you own a domain for which you have multiple subdomains with certificates signed by different authorities, which probably doesn't (or shouldn't) happen.

      And if it does happen, your domain probably is a public suffix.

    3. Re:Certificate Transparency? by cryptizard · · Score: 1

      I imagine the standard will account for this by only subdomains lower than whatever the level of an "owned" domain is, but thanks for pointing it out!

    4. Re:Certificate Transparency? by tepples · · Score: 1

      For example, Amazon owns the amazonaws.com, but it allows Simple Storage Service (S3) subscribers to register subdomains (called "buckets"). This makes the buckets' root domain (s3.amazonaws.com) a public suffix, though Amazon uses its own wildcard certificate for *.s3.amazonaws.com to serve files in S3 buckets to HTTPS clients.

  8. Perhaps I'm missing something... by SvnLyrBrto · · Score: 4, Insightful

    ... in my pre-coffee state. But:

    > vpn.miltonsandfordwines.com
    > upstest2.managehr.com
    > mail.backup-technology.co.uk

    How exactly is the knowledge of the existence of any of these domains a problem? Just about any given domain can be assumed to have a mail.whatever.com subdomain. Internal testing domains are internal and, if they're ever publicly routable at all, are only opened up for the duration of the test and then closed down again. And just the knowledge of a VPN address should never be enough. At the very least you also need a valid username/password. You probably need a 2-factor token. And you possibly need a client certificate of your own to access it.

    I'm failing to see any "dark side" here.

    --
    Imagine all the people...
  9. "Dark Side"? More like admin stupidity! by gweihir · · Score: 1

    If your security relies on host-names remaining secret, then you have already messed up to a stellar degree. The host-name in a certificate is decidedly not the problem in that case.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:"Dark Side"? More like admin stupidity! by sexconker · · Score: 1

      What if the hostname is "workmail.hillaryspersonalsite.com" ?
      Or "black.sites.cia.gov" ?

    2. Re:"Dark Side"? More like admin stupidity! by gweihir · · Score: 1

      Nice examples for what I said: These hostnames should never have been selected.

      Face it: Host-names can leak in other ways, for example DNS helpfully telling you about them in the "extra" section or from a reverse-lookup of the IP. ALso if you do a resolution call to a resolving DNS, that DNS (which can be an arbitrary resolving one) afterwards knows about the hostname. Hostnames are not secret in any practical sense.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    3. Re:"Dark Side"? More like admin stupidity! by sexconker · · Score: 1

      Hostnames are supposed to be descriptive. Host names are descriptive, natural language mappings to IP addresses. That's their primary purpose. Those host names are fine as long as they're kept secret. There is no benefit to "transparency" nor is that the goal of the DNS system.

      Hostnames that map to IPs not publicly routable should not be disseminated publicly, regardless of what they are.

    4. Re:"Dark Side"? More like admin stupidity! by gweihir · · Score: 1

      Seriously, you cannot practically keep hostnames secret, in particular those where a descriptive name is an advantage (no, this is _not_ generally the case).

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  10. If you have a wildcard certificate by Kernel+Kurtz · · Score: 1

    the bad guys know all your host names.

    Oh, wait....

  11. DANEcoin by tepples · · Score: 1

    blockchain-base SSL?

    Does that make any sense at all?

    It makes about as much sense as layering DANE (RFCs 6698 and 7671-7673) on top of Namecoin.

  12. Re:Security through obscurity of interna domain na by bloodhawk · · Score: 1

    when it comes to phishing attacks knowing internal host and site names has huge value in generating bait that IS FAR MORE LIKELY TO HOOK A VICTIM.

  13. Internal CA on a home network? by tepples · · Score: 1

    By the time you're running your own private hosts on your own private network, it's for sure a no-brainer for your IT staff to run their own CA and register it as trusted CA in all internal computer systems.

    Say someone goes to Best Buy and buys a home server for use on a home LAN, and its web-based administration interface uses a private CA for HTTPS. Is the owner of that home server likely to know how to make the server's internal CA trusted on all Windows, macOS, Android, and iOS devices on the home network?

    1. Re:Internal CA on a home network? by wvmarle · · Score: 1

      By the time someone feels the need for a private server at home (and even knows what to do with it and how to use it - including things like setting up a domain and getting fixed IP or DynDNS to actually be able to access it remotely), they should be able to handle that part as well. If they can't figure out such a task, no hopes for the security of the rest of the server so whether it's https or not doesn't matter any more.

    2. Re:Internal CA on a home network? by tepples · · Score: 1

      By the time someone feels the need for a private server at home (and even knows what to do with it and how to use it - including things like setting up a domain and getting fixed IP or DynDNS to actually be able to access it remotely)

      I wasn't referring to remote access. I was referring to access only within the private home LAN.
      they should be able to handle that part as well. If they can't figure out such a task, no hopes for the security of the rest of the server so whether it's https or not doesn't matter any more.

      Let me repeat it in my own words to make sure I understand what you wrote:

      Nobody should buy a networked printer or networked backup appliance until he or she has already learned how to trust a CA.

      What if anything did I misunderstand?

    3. Re:Internal CA on a home network? by wvmarle · · Score: 1

      Those are not servers and don't need to serve https as you'll connect on a trusted network - your own, and your own only. Wired or encrypted WiFi.

      My own networked printer required me to connect by cable first for initial setup, after which the built in software would connect the printer to my network (I had to tell which and so). Secure without CA.

  14. I don't understand by jon3k · · Score: 1

    If it's not public, then it's on a private network where you should run your own CA. So what's the issue?

  15. Secure Contexts by tepples · · Score: 1

    [Appliances on a home network with a web-based administration interface] are not servers and don't need to serve https

    The article "Deprecating Non-Secure HTTP" by Richard Barnes begins: "Today we are announcing our intent to phase out non-secure HTTP." Not only Firefox but also Chrome has announced plans to deprecate HTTP. This includes making new web APIs, such as Service Worker, available only to a "secure context". The list of such APIs includes Service Worker, Geolocation, Notification, Fullscreen, Pointer Lock, and Media Stream (camera and microphone).

    A secure context is available only if all documents holding references to objects in that context come from a "potentially trustworthy origin", as defined in the W3C's "Secure Contexts" spec. As of right now, web browsers are treating only the 127/8 netblock (that is, localhost) and origins using the https or wss scheme as potentially trustworthy origins. The spec allows a web browser to allow the user to mark other origins as potentially trustworthy, but the present draft doesn't suggest how the web browser might expose this functionality to the user.

    as you'll connect on a trusted network - your own, and your own only. Wired or encrypted WiFi.

    A web browser cannot tell the difference between my encrypted Wi-Fi network at home and the encrypted Wi-Fi network of the coin laundry near me. For this reason, the RFC 1918 private netblocks 10/8, 172.16/12, and 192.168/16 are by default not treated as potentially trustworthy without the https scheme, unlike 127/8.