Show HN: CertStream – See SSL certs as they're issued in real time
certstream.calidog.io
certstream.calidog.io
I will probably never know, because BSI is a trusted CA in all browsers and other http clients so they don't complain (and I am not looking at what certificate the server sent me every time I open my nc page), and nobody else will ever know that that certificate was released. Am I right? So what does CT buy me?
The Coinbase Engineering blog actually just put out an article on this very topic today - https://engineering.coinbase.com/moving-to-expect-ct-d0d26a0....
Makes sense. So to be sure nobody issued a cert for one of my properties I would have to check regularly on CT logs to be sure that only certs requested by me are issued. But in that case, if someone requests a cert for one of my properties, and that cert was not requested by me, what do I do?
Do I tell mozilla and google that "someone issued cert id 4d8effdd25 for my nextcloud installation (or my forum where some rebellious users meet up sometimes) to mitm me, but it was not me". Will they belive me? And it will be probably to late anyway, because propagation to a CT log can take up to one day, so they got data on all the traffic for a whole day.
Couple that with most providers requiring you to prove your domain via DNS or organizational status and you narrow the attack window.
Also I'd assume that as the owner of a domain, you'd be able to revoke any certificate for your domain that you didn't create.
This is where a TLSA record would help to prevent malicious certificates. At least, if the client (browser) validates TLSA records.
If a government was coercing a CA, they'd just tell them to disable this check. If this can be proven it's grounds to start the distrust process. At the very least, they should fail their next WebTrust audit.
You would indeed, which is part of the reason I released this service + libraries, so some enterprising developer can build a nice alerting service with it for folks just like you!
> Do I tell the mozilla that "someone issued cert id 4d8effdd25 for my nextcloud installation
Not exactly, I believe you'd probably contact the certificate issuer who issued the original certificate to have them issue a revocation, but my sincere hope is that folks running CAs will eventually come up with some better method for flagging certificates as bad/malicious than "just email Symantec support", since I wouldn't wish that on anyone.
I launched https://ctadvisor.lolware.net/ some time ago.
Basically. You'd send a report to the CA telling them there was a misissuance, and if their answer isn't to your satisfaction, you can report it to Mozilla and the other browsers on the public mailing list, claiming a misissuance by the CA. The browsers would then force the CA to follow up.
They're almost exclusively used for digital ID servives (and, according to some sources, MitM), and are in browsers anyway. CT won't help with that.
Do you have any source for that certificate being used for MitM?
There are a few stories about this in the 2013 Snowden data actually, the SPIEGEL published stories about that back then, too.
I'm far more enraged by the decision of the Bundesdruckerei to not offer on-card signing features for the ePerso anymore.
Instead, you have to use their web service to sign, and it costs you even more money. And is obviously ridiculously insecure.
Yes, this is exactly what you should do. There's a very active list by mozilla ("dev-security-policy") where CA missteps are discussed on a regular basis, that's a good place to bring up all issues with CAs (however most of them are much more minor than a mitm attack with a fake cert - the day to day business is more "this cert violates RFC something").
> Will they belive me?
Well, the malicious issuance of a certificate is high profile enough that they will at least investigate and the CA will have to show some evidence how the cert has been issued.
> And it will be probably to late anyway, because propagation to a CT log can take up to one day, so they got data on all the traffic for a whole day.
That is in principle true. CT does not directly prevent attacks. But the general idea is this: CT makes it very likely that attacks get detected. A malicious attack by a CA is almost certainly the end of their cert business. So while an attack is still possible, it becomes very expensive, you basically have to sacrifice a working business.
CertSpotter does this for you automatically: https://sslmate.com/certspotter/
In most countries, law enforcement are disinclined to use tools that will only work once - because what if they need that tool tomorrow for something more important? So this provides you with a bit of herd immunity, there is probably someone doing something naughtier than you who would be a better target.
It is also legally easier to get away with demanding that somebody do something they already _can_ do than to demand they come up with a way to do something they can't already do. British courts for example asked Internet Service Providers "Do you have a way to block web sites, e.g. for having child pornography on them?" and all the big ISPs said "Oh yes, we have that" and then the courts said "Aha. OK, then you must use that to also block copyright infringements, Hollywood will tell you what to block". But for the tiny ISPs like mine that said "No, we just move bits - nazis, child porn, bomb making, if it's illegal then you should convict the people doing it, not our problem" the courts said "Then it would be outrageous for us to demand you do as Hollywood asks, carry on as you were".
Because CT logging is mandated by Google, most CAs are building systems that automatically log everything. So then "Issue this but don't log it" becomes a huge ask, the front line guy the secret police get to says "I don't have a way to do that, it always logs everything" and that increases the chance the spooks get forwarded to an executive who says "Woah, this suicides my whole company, you better get yourselves a warrant, and I am calling my lawyer right now".
Chrome is scheduled to do start doing this in April 2018
I see two issues with that:
1) the browser vendors know each site and subdomain I visit. This seems to be a privacy issue.
2) every new visits adds a lot of latency because they need to check the certificate every time I request a site (now it becomes: dns, ssl handshake, cert check, http transfer).
3) when the cert check server is down, what is supposed to happen? Fail every ssl request? This adds a new point of failure. Just allow it? An attacked could black-hole the dns or block the IP address.
The web server sends a Signed Certificate Timestamp in the TLS Handshake¹. The browser will check that.
Apache support is coming², and other web server vendors are probably working on it as well.
But the obvious answer for truly secure connections is your own CA root or a self-signed cert you manually install/enforce.
You don't want to pass through another CA if your service is private. You actually don't need to. In fact, you'd want to manually enforce a single root or distrust system certificates entirely when doing so to avoid the problem you describe.
Most decently-written software that supports SSL/TLS allows you do that.
The CA system is for services that you intend to make public.
> Most decently-written software that supports SSL/TLS allows you do that.
Unfortunately maintaining your own CA and installing it on all your devices is no easy feat. On android it's not even possible without root, and most IoT devices are not "decently-written". So what you say is true on paper, but delegating your CA to an external service like letsencrypt is unfortunately the only doable way as things are now.
Let's assume an attacker finds a RCE in JIRA, Confluence or Gitlab... now everything the attacker has to do to find a list of candidates is to run a simple grep -i gitlab|jira|confluence|whatever on the CT logs, while he'd have to go the brute-force route before CT.
Don't name hosts after products!
But more generally, you should never expose Confluence etc to the greater internet. That's just asking for trouble. It will find you, greppable hostname or not.
If your last defense is that nobody knows the domainname, then you've lost. Not knowing the domainname shouldn't be any defense at all.
Of course not, but CT dramatically lowers the bar for attackers. That's what I mean.
CT raises the bar for attackers since they will be logged into the CT if they try to MitM.
Any other attack is not made easier than without CT.
I think that it would be somewhat difficult to pull off a correlation attack/leakage as the CTLs tend to dump in batches vs every poll returning new results, but I think once you remove a lot of the noise (cloudflare SNI certs, testing domains, etc) it'd potentially show some interesting patterns.
https://github.com/CaliDog/certstream-python/blob/master/exa...
This demo would be a decent starting point to that analysis if you'd be interested in toying with it!
How are you dealing with googles 60min-ish flushes of their log?
Seems like Hanno Bõck could at least use a shout out if it was related to his work.
Either way, the talk is worth a watch.
[0] https://www.youtube.com/watch?v=TMNeSnjZfCI&list=PL9fPq3eQfa...
Thanks for the video!
Anyone who reads the certificate transparency log rfc can quickly realize whats possible.
I've also been following calidog since his first medium post, ive got my own similar cert scanner/tracker.
In the meanwhile, crt.sh also offers a Atom feed of issued certificates. Definitely not realtime but also works.
https://media1.giphy.com/media/R54jhpzpARmVy/giphy.gif TL;DR - Curse you Webpack! ::shakes fist::