Francisco Partners Acquires Comodo's Certificate Authority Business | Hacker News Reader

Francisco Partners Acquires Comodo's Certificate Authority Business

eweek.com

49 pointspfg24 comments

Should we worry that a Deep-Packet-Inspection vendor has the same owner as an SSL certificate vendor?

I worry about it too, my company use Fortinet with DPI enabled that it strips down target server's SSL cert and replaces by its self-signed cert. So, maybe with Comodo's CA, SonicWall DPI would be transparent to end users. Yes they assure in the press release but who knows.

This would be a violation of root policies and would certainly cause the CA to be distrusted nowadays. It would also be detected with a high likelihood due to HPKP (and CT in the future). The economics of buying a CA for this purpose don't make sense.

You might have missed yesterday's news from Chrome announcing that the HPKP feature is being considered for removal.

The deprecation timeline is being synced with the rollout of CT and CT enforcement headers (Expect-CT). This provides roughly the same detection (if not prevention) capabilities.

Would it be a violation if a company or person were only using it to crack open traffic into or out of their network? On my network, shouldn't I be able to do just about anything I want?

It would be a violation to do it with Comodo's publicly-trusted PKI, yes. You can do whatever you want with a private root that's manually deployed to the clients within your network.

An important thing about the way Public Key cryptography works is that if you try shenanigans like this you're obliged to supply the client with the smoking gun as part of your scheme. The signed certificates prove beyond doubt what happened, and they are automatically delivered to the client as a necessary part of the initial SSL/TLS connection.

Imagine if you had a fool-proof way to murder people, but it requires you leave their corpse in a public square with a copy of your photo driving license and a signed confession. Now, perhaps for some reason you are politically untouchable so you will never see justice. Still though, by this method absolutely everybody will know you did it, so it doesn't seem like a good idea anyway.

Next year Google Chrome will require people to publish all the certificates in Certificate Transparency, which will be a significantly better source of proof because then people who are in a better position to know that the attack is an attack will also have a straightforward way to see them.

Is each cert chained to the previous somehow? Like a field from one hashed into the next, so that you can detect gaps in the issuance? That way they can't even issue a secret cert for a one time national security op without breaking the chain.

Yes.

Kind of. The way CT works is that everything submitted to a CT log is chained, so you can validate that the CT log's record of issuance is complete—that is, everything it has received has been digitally signed into its record, and you can verify that nothing has been removed from the record. So if you're presented a cert with a CT timestamp, you can validate that a CT log server saw and accepted that certificate (making it part of the public record). The signed timestamp (or timestamps--you're supposed to present stamps from a minimum of three different CT logs to make Chrome happy) has to be embedded in the cert or presented as part of the TLS handshake. (See https://www.certificate-transparency.org/how-ct-works for more info.)

All of that doesn't prevent someone from issuing a certificate from a public CA and /not/ submitting it to a CT server: there's no easy way to detect that. If someone did that, though, they would have to present the certificate to your browser without a CT stamp attached. Both Firefox and Chrome are working on implementing mandatory CT validation, at which point your browser will yell and scream if it is presented a cert from a public CA that doesn't have an associated CT stamp. (Right now, if you want to check CT timestamps on certs, you need a plugin (there's one for Firefox, e.g., at https://www.elevenpaths.com/labstools/certificate-transparen... although I can't vouch as to its completeness).) At that point, sneakily grabbing certs from a public CA won't do you any good because it will be obvious they're not legitimately issued.

> At that point, sneakily grabbing certs from a public CA won't do you any good because it will be obvious they're not legitimately issued.

An interesting problem in this design is how to persuade users that they've encountered something genuinely important that it would be helpful for them to tell someone else about. (Maybe browsers can store such questionable certificates offline and gossip about them to other TLS servers later.) It's not very common for people to be persuaded that errors on their computer matter and that other people will care about them... but this one does! :-)

I know HPKP has a report method which one could imagine generalizing somehow to CT inclusion failures, but, in many attack scenarios involving use of misissued certs, the victim's network connection is controlled by the attacker. In that case, the attacker will probably not want to allow the victim to report the attack to another server in real time.

Interesting idea! I know the CT spec recommends that clients archive CT data received for later review, and it defines the concept of a CT 'auditor' that constantly reviews the logs from CT log servers looking for malfeasance. It would be interesting and very useful to amalgamate anonymized data from browsers into one of those auditors and crunch through it to compare to CT records.

We have at least another such example of a merger - BlueCoat + Symantec, with BlueCoat's CEO becoming Symantec's CEO. And now Symantec's certificate business is gone because it couldn't be trusted.

The article also seems to imply that Comodo is selling its CA business "because of what happened between Google and Symantec." They seem to try to spin it as an opportunity for Francisco Partners, but I wonder why Comodo was suddenly interested in selling its CA business - is it because their infrastructure was just as shake and insecure as Symantec's? Certainly something to think about.

All the more reason to build over top Google, Dropbox, AWS... treat them as vanilla endpoints for encrypted traffic

Do nothing in AWS that isn’t hidden, encrypt local and store on Dropbox...

Keybase and similar should be used as new examples of the kind of apps and features to be offering

End-to-end encrypted messaging, git, and file sharing

Am done with Google and the like for personal and soon at work where we’re migrating from AWS and Google G suite

It’s market evolution. Out with Kodak and in with digital cameras.

Only now it’s social media and services 1.0

Since it’s just software it can happen much faster and more frequently

Serious question: Was Francisco Partners unaware that the paid CA business model is going down the crapper thanks to LetsEncrypt?

Props to Comodo though for having the foresight to exit while there was still value.

Is it really [going down the drain] though? I'd imagine there will be infinite ways to create costly enterpris-y offerings, be that via additional important-looking seals, SLAs, EV, or something else. Or Postgres+friends would've destroyed Oracle ages ago.

Furthermore, I don't believe there is a LetsEncrypt equivalent for code signing.

Also harder to implement. With letsencrypt you prove you control the domain and the DNS. How do you prove you control software?

It's the same process as EV - verify the public key is controlled by a real world legal entity. Validation process depends on the entity type, but usually a combination of government and private business registrars, and verification phone calls. Sometimes ID inspection for sole traders (since in their case the legal entity is a person).

Yes, but this does not lend itself to automation, hence free as letsencrypt does.

Not entirely, but reducing EV verification times is my job at https://certsimple.com. There's a lot that can be done and most CAs tech to handle the problem is at least a decade old.

Also: ACME for EV is coming.

Cool. I’ll send you an email.

Reply on news.ycombinator.com