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.

62 comments

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

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

    1. Re:recognizance ?! by Anonymous Coward · · Score: 0

      I'm assuming they meant reconnaissance, not that it makes tremendous sense even then.

    2. 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?
    3. Re:recognizance ?! by Anonymous Coward · · Score: 0

      Perhaps they meant reconnaissance?

    4. Re:recognizance ?! by Anonymous Coward · · Score: 0

      Yes, and the context of the discussion that's clearly nonsensical...

    5. Re:recognizance ?! by Anonymous Coward · · Score: 0

      Perhaps they meant recognizable?

    6. Re:recognizance ?! by Anonymous Coward · · Score: 0

      reconnaissance

    7. Re:recognizance ?! by Anonymous Coward · · Score: 0

      It kinda does - it allows you to reconnoiter the names of internal server machines without penetrating the network. So when you do breach the network, you have a map of what to hit.

  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!
    2. Re: Stupid by Anonymous Coward · · Score: 0

      Client certs. Either for http or for a VPN.

    3. Re: Stupid by Anonymous Coward · · Score: 0

      It's still information leakage, and all security comes in layers. What if the host's *name* revealed something sensitive that wasn't previously known? Like the level of redundancy, or its physical location?

  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 Anonymous Coward · · Score: 0

      Let's Encrypt allows for DNS-01 challenge in the backend, but AFAIK not yet in the official client. There are other clients available which do support DNS-01, they just need to be able to get DNS records added and removed, either dynamic DNS updates or manual DNS changes

    7. 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.

    8. Re:Hostname leaks and internal CA by Anonymous Coward · · Score: 0

      Despite the popular saying, obscurity is a great addition to good security.
      Simple things like moving SSH away from port 22 will cut down scripted attacks by 90 - 95%.
      This means that it will give you a lot of extra time when zero day vulnerabilities are found.

      Relying on obscurity is not good, but adding it on top of otherwise good security is a reasonably good idea as it will stop most scripted attacks directly.

      Take the previous example: If accessing port 22 puts your IP in a list that doesn't get a reply on important ports then even a directed attack will fail if the attacker first attempts to check port 22.
      Anyone who knows anything about your specific setup will of course not be stopped by that but obscurity will typically lead to a situation that in the event of a breach you can follow what obscurities were known about and reduce the number of possible attackers to those who have worked for your company or know someone who has worked for the company.
      Being able to track down and going after hackers legally is a pretty nice option to have.

      Same goes for encryption.
      Using a good and verified encryption will most likely stop or delay anyone who is an expert on the subject but if there is known vulnerabilities then you are exposed to any nitwit that can use an automated tool.
      Rolling your own crappy encryption will stop the automated tools but not an expert that is targeting you specifically. (It will stop big fish like NSA that relies completely on automation to be able to process large amounts of data unless they find a particular interest in you.)
      If you on the other hand use both security and obscurity you are protected by both the real security and against automated tools.
      That means that it isn't enough to break the encryption. Fishing expeditions that just tries to break everything will still fail, you have to be targeted specifically by an expert.

      There is a reason the military uses both camouflage and body armor.
      If you only can use one, go for the body armor, but there is no reason to not use both if you can.

    9. Re: Hostname leaks and internal CA by Anonymous Coward · · Score: 0

      On Android, you toss a new CA into your phone, you get to deal with a warning notification on every boot that there's a potentially malicious cert. And no way to tell it you know about the cert, and you trust it.

      Annoying, to say the least.

  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. Re:solving the wrong problem by Anonymous Coward · · Score: 0

      Your math sucks.

  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 Anonymous Coward · · Score: 0

      Stick it behind a small proxy system (physical or virtualized) that is configured to provide TLS service to LAN clients based on your internal CA. You'll need to manually establish trust once between the proxy and the backend appliance, and establishing trust between the proxy and your LAN clients simply requires installing your intermediary internal CA certificate on client devices. Once the latter is done, you can issue certificates for as many additional appliances as you like/need without having to touch the client devices again. I happen to be building a custom network security appliance that largely automates all of this. -PCP

    3. 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.

    4. Re:If the host name should not be publically known by Anonymous Coward · · Score: 0

      For many such cases, the best answer is to provide an appropriate script or other executable to perform the required steps. 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. -PCP

    5. 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...
    1. Re: Perhaps I'm missing something... by Anonymous Coward · · Score: 0

      I think it's more of a business security than computer security problem. Knowing what hostnames exist and how many of them can allow competitors to infer information they may otherwise not have. If 1000 certificates are suddenly issued for compute-ny-####.example.com, a competitor may reasonably infer that your New York office is ramping up for a recently acquired contract and not be willing to bid as much for another one they are competing with you for.

      Alternatively if they look back in the issuer history see a bunch of certificates for .dc.example.com they could determine what software license servers have andmatch any feature offerings you put it in the bid.

    2. Re: Perhaps I'm missing something... by Anonymous Coward · · Score: 0

      Damn Slashdot ate my greater-than and less-than symbols. The mobile interface needs a preview button!

      The last hostname example should have bee `product'.dc.example.com.

    3. Re:Perhaps I'm missing something... by Anonymous Coward · · Score: 0

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

      you probably also think that you dont need encryption because you have nothing to hide!

      the point is... that if you're already looking at a database of targets, it will tell you much about an organization if you see no or few or many subdomains. by knowing the naming conventions you also gain a clue to the sysop's brain and/or how 'they' think about and manage their site. combine that with dates, address-records, job-postings etc and you can make quite a profile of potential clients, including their business history.

      seeing any better now?

  9. IRRELEVANT, NOT SUPPOSED TO BE THERE by Anonymous Coward · · Score: 0

    Those points are irrelevant.

    It's not supposed to be there in the first place.

  10. "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.
  11. If you have a wildcard certificate by Kernel+Kurtz · · Score: 1

    the bad guys know all your host names.

    Oh, wait....

  12. 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.

  13. GOOGLE IS FED - ERIC SCHMIDT IS PENTAGON by Anonymous Coward · · Score: 0

    Google is all US Government spying along with other companies like Microsoft and Facebook and Markmonitor and Cloudlfare.

    There is no mystery dark to US Government spying.

    Dark certificates? Google tracks everything don't tell me about dark certificates certified by a US Spy agency.

  14. 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.

  15. buy a ca cert for your internal subdomain by Anonymous Coward · · Score: 0

    Then all devices will trust it, but there will only be a single public cert.

    1. Re:buy a ca cert for your internal subdomain by Anonymous Coward · · Score: 0

      You think people believe your stupid ass?

  16. 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.

  17. 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?

  18. 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.