The Dark Side of Certificate Transparency (sans.edu) 62
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.
recognizance ?! (Score:3, Insightful)
I don't think you know what that word means!
Re: (Score:2)
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.
Stupid (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.
Re: (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.
Hostname leaks and internal CA (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.
Re: (Score:3)
Very well said. I have no mod points, so here's my virtual +1.
Re:Hostname leaks and internal CA (Score:4, Interesting)
Exactly. We use an internal CA (there are several good ones out there like EJBCA) for all of our private internal hosts.
Re: (Score:2)
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 iss
Re:Hostname leaks and internal CA (Score:5, Insightful)
Re: (Score:2)
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?
Re: (Score:2)
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.
Internal CA on a home network? (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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 misun
Re: (Score:2)
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.
Secure Contexts (Score:2)
[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 [mozilla.org] begins: "Today we are announcing our intent to phase out non-secure HTTP." Not only Firefox but also Chrome [chromium.org] 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 [fxsitecompat.com] includes Service Worker, Geolocation, Notification, Fullscreen, Pointer Lock, and Media Stream (camera and microphone).
A secure context is available only if all documents holding referen
solving the wrong problem (Score:3)
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.
Re:solving the wrong problem (Score:4, Informative)
huh. like this. how about that - someone's already done it. https://github.com/okTurtles/d... [github.com]
Re: (Score:1)
blockchain-base SSL?
Does that make any sense at all?
Sounds to me like "lets all move to cloud-based furniture!"
DANEcoin (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
If the host name should not be publically known (Score:3)
then you should not need any certificate form any CA but yourself.
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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?
Security through obscurity of interna domain name? (Score:5, 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.
Re: (Score:2)
Certificate Transparency? (Score:2, Insightful)
Don't you think that Certificate Security [slashdot.org] 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.
Re: (Score:2)
Re: (Score:2)
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 [publicsuffix.org].
Re: (Score:2)
Re: (Score:2)
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.
Perhaps I'm missing something... (Score:5, 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.
"Dark Side"? More like admin stupidity! (Score:2)
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.
Re: (Score:2)
What if the hostname is "workmail.hillaryspersonalsite.com" ?
Or "black.sites.cia.gov" ?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Seriously, you cannot practically keep hostnames secret, in particular those where a descriptive name is an advantage (no, this is _not_ generally the case).
If you have a wildcard certificate (Score:2)
the bad guys know all your host names.
Oh, wait....
I don't understand (Score:2)