Fox-IT hit by cyber attack

I was using a simple form of 2FA with my retail bank in Switzerland back in the early 2000s.

To clarify, the problem here wasn't with their DNS servers, but rather the registrar being compromised. You could run your own DNS servers and still get compromised like this unless you also happen to run your own registrar.

18 years ago was 1999.

Yes, it more highlights that the simple presence of a valid certificate does NOT guarantee that you are connecting to the service that you think you are.

EV certs would be harder to compromise, but likely not too difficult for a sophisticated attacker. And who really notices if a site that had an EV cert suddenly doesn't? I might for my bank, but likely would not for a software product website.

> he could pass a CA's domain validation

What! That's impossible! /s

Specifically Comodo reports that they sent their normal validation email to hostmaster@fox-it.com (which unknown to Comodo or Fox-IT at the time was being directed to the attackers). I've never used Comodo's implementation of 3.2.2.4.4 but typically there's an email with a code in it, telling you to go to a web page and paste the code in if you want to authorise the issuance of the requested certificate, or something along those lines.

The security of this validation method (3.2.2.4.4) depends upon

1. You control DNS for your domain including the MX records used to deliver email (this is where Fox-It came undone here)

2. You control the MX servers, or if you have a third party providing backup MX, you trust them not to abuse that

3. The Certificate Authority does a good job of getting accurate DNS records and connecting to the right IP address

4. All email addresses in your WHOIS records plus a handful of famous ones like hostmaster@ postmaster@ are delivered to people you trust in your organisation.

Ah yes, the Dutch government, which is so good at digital security choices cough Diginotar cough.

https://radicallyopensecurity.com/ are pretty great. Don't know if they're actually better than fox-it. The latter I only know by reputation.

That is a very hard question. The simple answer is _that one_ security company that manages to compromise you and point out all issues within your company and or code for you to fix/address, that's the best one (for you). (if we can leave the financial part out of it, because security advice or audits aren't cheap either.)

But it is not that simple. I don't consider that very likely, that you actually find that 'right' company. (and putting faith in a third party to audit your code/company, brings other risks too). And chances are that some issues will be overlooked but not by that 'weird' guy/girl in the attic that has all the time of the world to security probe you 'for free'.

And there will always be a part you can't audit properly, your employees, which often is the origin of a hack, disgruntled employees. Or even worse, a disgruntled employee of the security company that just audited you.

And keep in mind, with enough power, you can get anything offline or in a non acceptable state (half working, data compromise etc). So security companies can only help you a certain length, nonetheless it can be very helpful to have a person from outside look at things with 'fresh eyes' and see things you have overlooked for so long because you are right in the middle of it all.

> The name of the country is the Netherlands, not Netherland.

I disagree. I'm Dutch[0], and I find it stupid that English speakers always pluralise our country. We've been a unified country for quite some time now. Netherland is fine.

[0] Yeah, "Dutch" is another one of those weird things that English inflicts on us. Why?

[I'm sure you know this but for other HN readers]

Once a certificate is submitted to the logs (which as mentioned elsewhere, Google wants to make mandatory, but today they only enforce for EV and only by treating as non-EV if it isn't logged) the log won't necessarily immediately tell monitors about that certificate. Accepting new items for the logs can be (and usually would be) parallelised, but the log structure is a single Merkle Tree and so cannot be calculated entirely in parallel, usually updating this structure is a serial operation that happens asynchronously, with the result available some time later.

A policy value called the Maximum Merge Delay decides how long a log has to get this done and produce a new head value for the log, Google has currently chosen 24 hours for logs to be accepted in Chrome. Once a log presents somebody with an SCT proving it logged a particular certificate, it has 24 hours to make a Merkle Tree with that cert in it available to the monitors. That sounds like a long time, but it's not "business hours" or "best effort" it's an absolute limit. Data Centre flooded by a tsunami? Too bad. OS upgrade is incompatible with your CPU model? Don't care. Some lunatic threw a billion dollars in bills out of an aeroplane and your employees are out collecting as much as they can carry? Not our problem. Usually you can expect the actual turnaround to be much less than 24 hours, if it's ever greater the log should be distrusted and shut down.

There have already been logs that had "problems" and went away for this reason. Because the logs are only useful if they obey the MMD Google is being pretty strict about this.

However, just because something is in one or more logs doesn't mean any monitor, including famous ones like crt.sh, or Google's own transparency site, has actually obtained and processed the log item right away. There can definitely be slowdowns in this part, but they're only a matter of throwing enough resources at the problem.

Do you have statistics about how fast different CAs are/how it is distributed? Are some CAs always "lagging", or do many of them have occasional late outliers, ...?