CA Comodo used broken OCR and issued certificates to the wrong people
bugzilla.mozilla.org
bugzilla.mozilla.org
In this email, Comodo discloses the security issue to Mozilla. The email was sent 26 days after researchers Florian Heinz and Martin Kluge of Vautron Rechenzentrum AG informed them of the bug.
Comodo clearly states that they used OCR for .eu and .be domains because the TLD registrars redacted their port 43 WHOIS data, and only provided an image of an email address on their web WHOIS pages. There was apparently no other way to obtain the email address.
Rather than flag humans to fix OCR in ambiguous situations, they had automated heuristics to correct the OCR, as determined by the security researchers. However, the heuristics chose the wrong output for the domain @a1telekom.at, producing @altelekom.at (an L instead of a one). The researchers registered altelekom.at and obtained a cert for a domain owned by A1 Telekom, a major ISP.
> steffen 2016-10-20 08:35:58 PDT
> In fact, the linked incident report refers to the heise article I also linked. So Comodo chose to "publish" this immediately after it was made public by others. That would be quite a coincidence. This raises the question of whether Comodo would've informed Mozilla at all if the media hadn't picked up on it.
Corp has to write, test, verify, share internally, review and approve before it can be released. Bureaucracy. They also needed to patch their systems too.
Ryan Sleevi (Google) asked the question, and Robin Alden (Comodo) stated a reasonable timeline. There is no conspiracy here.
So what they're saying is y0u can fo0l their servers with 1eetspeak?
Quite often you try to eliminate uncertainty by being clever: Sure, OCR engine: Go ahead and recognize O and l and B if you want. If I know that the context of this text is an amount, I'll still replace those chars with 0 and 1 and 8 afterwards.
(Engines usually allow you to configure the allowed character set, but in practice it seems to be easier/more reliable to work like a parser: Lenient in what you accept and strict in what you pass on)
The CEO seemed really self absorbed and saw himself as an innovator with letsencrypt stealing business processes from him (which makes filing for trademark infringement make less sense). He took it as a personal insult, and did not even appear to understand that letsencrypt was a public service rather than a for-profit product.
There was a fan who claimed to be a paralegal cheering on the CEO's rant yet appeared to confuse trademarks with patents with copyrights.
At least with the forums alone, that thread read like teenage high school soap opera, not a business. It was like an echo chamber of the CEO's fixation.
And now this. Sounds like there was a deliberate business decision to use faulty tech, and forgetting the wider social impact of operating a CA.
https://forums.comodo.com/general-discussion-off-topic-anyth...
Here's the HN discussion
Otherwise, I applaud the initiative.
If you would like to use it without root/sudo, you can pass flags changing the directory it uses. For example:
certbot --logs-dir ~/SSL --work-dir ~/SSL --config-dir ~/SSLIt's good to encrypt things, but I wouldn't be too surprised if it were possible for folks to issue bad certs via them, as well.
This OCR issue with Comodo in TFA concerns WHOIS data, which may or may not be more reliable than unsigned DNS data. Regardless your point remains valid.
Public key pinning seems like it would prevent this attack though.
1etsencrypt.orgISRG is a Secion 501(c)(3) corporation.
Bugs happen. Stupid bugs happen. Stupid systems with stupid bugs even sometimes happen.
What I don't see is Comodo learning anything from their serial screwups.
Like paying for a SSL certificate you never received?
Not sure why people are down voting my answer. The other person posted "Chargeback?" - note the question mark. So I took that as if they were asking what a chargeback is, and was trying to explain it as simplified as possible.
To be fair to Keverw, it's easy to think that I meant to reply to dman's post and was asking what the term meant.
There's `.well-known` HTTP resources: https://tools.ietf.org/html/rfc5785
I work for CertSimple and we automatically use `(site)/.well-known/pki-validation` if we see whois privacy, because in practice customers using whois privacy are inevitably uncontactible. We may use `.well-known` by default in future. Our friends at LE/Certbot (ie, ACME) use `(site)/.well-known/acme-challenge`.
Also there is various efforts to replace/standardize whois, eg WEIRD and RDAP https://tools.ietf.org/html/rfc7483. However .well-known resources work well enough for the purposes and in practice is more widely used.
If I apply for an ev cert for ACME Inc to use on acme.com and have "ACME Inc" as the registered owner in Whois, does that satisfy the domain control check?
Which is all I want, anyway. If I'm typing my Bank of America login info, I care that it's being encrypted to a private key in Bank of America's control, and it doesn't really matter if that happens through a DNS name registered to Bank of America or not. It would be weird if it didn't, but it wouldn't inherently impact my security if the key was still BoA's.
https://www.iana.org/assignments/well-known-uris/well-known-...
It is possible that the people drafting that ballot didn't feel they ought to approach IANA until after it was voted through, and then they simply forgot.
It is also possible that the subsequent IP fuss (a bunch of CA/B members turn out to have patented some methods listed in Ballot 169) distracted everybody
Finally it's possible IANA just didn't get around to updating the list yet.
It is already supported for IP address lookups by all 5 regional Internet registries.
Every time I hear about these Comodo breaches, I'm not surprised. Supposedly, Iran was able to get them to issue fake certs for some major sites:
the only problem is... who's going to pay for it? the CA model and the DNS model tend to be a very low-cost one which means there's unlikely to be the kind of money available to pay for expensive red-teaming on a regular basis, let alone running infrastructure that would resist their attacks..
http://www.pcworld.com/article/2887632/secure-advertising-to...
Disclaimer: not associated with Comodo in any way.
All of this, plus the querying of the organization's legal registration, business address and contact is all done by trained people and due to internal efficiencies and workflows we can complete that in a matter of minutes from the time a customer places an order.
In the end, even an organizational vetted certificate is still completed just as fast as it takes customers usually to click on the approval email to authorize issuance and submit the CSR for the certificate creation.
Using images as anti-spam measure really gives you a lot more problems than benefits (except you'd use random single-usage addresses).
Don't obfuscate, but fix your spam filters or switch your email provider. What helps a lot is server-side moving of detected spam emails to your junk folder and looking through this folder from time to time.
The tragedy is, that most of the internet access is now happening from mobile devices and majority of that is coming from native apps. The apps need neither the same trust model nor have any "green locks". But PKI/TLS based orthodoxy has such a death grip on the industry that people continue to use this broken model for native apps where it makes even less sense than it does for browsers.
I think defaulting to the Web PKI and strongly encouraging use of key pinning (with good tooling, etc.) is the right approach here.
It just seems odd for them to use an image of a web page to transcribe information from a web lookup when they could just scrape the text off the web page directly without using the intermediate image and OCR.
However, I could see them using a human in the chain to look up the whois information, it just seems strange to come up with a complicated OCR solution (and if they did, that they couldn't find a font that makes 1's and l's look more distinct, like http://forum.high-logic.com/viewtopic.php?t=4004)
Try looking up whois info on google.eu. Most tools will simply output `NOT DISCLOSED! Visit www.eurid.eu for webbased whois.`. Now you can search https://whois.eurid.eu for the whois information of google.eu. You will find that the email address is only available as an image.
That's exactly the situation Comodo tried to solve.
Given that it's a simple font with no obfuscation, a small pattern-matching python programm should give you near 100% accuracy. Apparently Comodo used some off-the-shelf software instead, and that software seems to make assumptions it shouldn't make.
So it seems like there's little point in deliberately obscuring the email address in an image, and certainly no reason to do it with a font that doesn't more clearly distinguish between letters and numbers.
Visit whois.ausregistry.com.au for Web based WhoIs
Doesn't surprise me.
Nothing exists like this for linux (however https://github.com/subgraph/fw-daemon is getting close).
The quality of the software both good and bad doesnt' apply here.
Also whats wrong with ufw? Github is down so I can't view that link.
> The quality of the software both good and bad doesnt' apply here.
Well I clearly does, because this post is about how their software did some crazy roundabout stuff to validate domains that didn't work.
1. https://bugs.chromium.org/p/project-zero/issues/detail?id=76...
When you check out the link, see that nothing like this exists on linux. The closest thing on OSX would be little snitch.
github isnt down, flush your dns, its left over cached NXDOMAINS from this mornings outage.
you can also clear your browser dns cache with chrome://net-internals/#dns
I think my original meaning is there is lots of teams and not all of them are bad :-)
iptables --pid-owner[1]
> I think my original meaning is there is lots of teams and not all of them are bad :-)
Sure, you find diamonds in the rough, but when their AV and their certificate teams are trash does that inspire confidence? When their antivirus software bundles a 'secure browser' that disables CORS (!!!) and infects you only by scanning a file then why is it safe to assume that they know what the fuck they are doing as a company?
That's like assuming it's safe for a doctor to operate on your kidney, despite killing all their patients when operating on other organs, because you know, it's different.
The firewall might work and have the slickest interface but if it's full of buffer overflows and written by an idiot then it's not the best, is it.
Thats broken (only matches the exact PID, no child processes and according to the documentation does not work on SMP systems). It also got removed at some point. There is a cgroup match which may be usable instead, also network namespaces may be a good solution in some cases.
From a practical standpoint, I find it hard to imagine that the cost of added complexity for configuring application rules per user would outweigh the benefits of simply configuring them system wide. I remember the days of terminal clients logging into mainframes but all I see are single user desktops. Things like location on the network matter more in an application firewall than which user is accessing the desktop.
If you have never used something like Little Snitch on MacOS it is very surpassing to see all the outgoing connections from processes. It returns some control to the user to block cloud services, application dial home, etc.
Being able to interactively allow/deny access to resources (say via hostname or via IP) per connection per process (image?) is very valuable.
This is hard to do in linux. Several good solutions to do this in MacOS and Windows.
fw-daemon/rules.go references "/var/lib/sgfw/sgfw_rules" yet nowhere to be found.
There's IIRC no mechanism for that, but for the single-domain CA key it'd make sense to sign the new one with the old one.
There will be some jurisdictions where MiTM is always and unavoidable. TOFU can't work here.
These things must be universal, and TOFU can never be universal.
I think it would be cool to have a standard URL (/.well-known/certificate or something) that explains why you should trust their self-signed certificate, and have the browser show that as part of the view when you encounter a self-signed cert.
The current PKI system allows you to make an unsolicited encrypted connections to an internet origin over an untrusted connection with strong server authentication.
Self signed can not provide this. We do not want the web to be like SSH.
Also, PGP is a very different security model - in order to effectively use PGP, you need to go disclose your government identity to a handful of other people who are already in the strong set. That's not a great fit for the web.
Now, if you have a CA who gives out certificates to parties who should not have them, and that CA can sign certificates for any domain, how do you know if any connection is a MiTM or benign? Do you actually check the issuer every time you connect to a secure site?
CAs give a false sense of security. We need to move off this model.
How?
CAs give a false sense of security. We need to move off this model.
Maybe, but not by adopting the politician's syllogism. We should only move to a better model. As easy as it may be, it's still slightly harder to get a CA to sign a cert for a domain you don't control than it is to sign them yourself, and that shouldn't be dismissed.
If I go to a bank or business, and as part of setting up a relationship they hand me a pamphlet printed with their Public Key Fingerprint, AND the browser shows me that fingerprint image at first use, ..... then that's pretty reliable verification, isn't it?
Obviously we've never had face-to-face relationships with the likes of Paypal, Stripe, etc, and would still rely on our browser and operating system vendors to validate the chain of authority.
(In fact, I would argue that free certificates from Let's Encrypt are more trustworthy since the ACME protocol drastically reduces the surface area for attacks on the verification process. See slides[1].)
[1]: http://www.thedotpost.com/2016/10/matthew-holt-go-with-acme
[1] https://blog.chromium.org/2016/09/moving-towards-more-secure... [2] https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-...
Plaintext HTTP gives no illusion that your connection has confidentially, authentication nor integrity.
HTTPS is meant to provide all of these things. With a validated, trusted certificate, you get these things. With a self-signed cert, you have none of these things.
Knowing that I don't have things is better than thinking i have these things and not.
So no, untrusted self-signed can't ever be better.
Note cant reply to reply, but all i can say is
"With a self-signed cert, I know I am talking to exactly one party and that no third party can surveil or monitor that communication. "
(This is not true, as this could easily be my MiTM Proxy that is substituting your self signed public key). Once you introduce 'trusts' you are back to CA land.
HTTPS is meant to provide all of these things.
No. This is absolutely false. HTTPS is a transport protocol (that's the second T) and provides point to point security, only. The fact that we have grafted onto this protocol the notion of authenticity as verified by a warden is an historical accident (and frankly the cause of many problems).
With a self-signed cert, you have none of these things.
With a self-signed cert, I know I am talking to exactly one party and that no third party can surveil or monitor that communication. This is a channel over which the second party and I can then negotiate authenticity, which is a much better way to do it than the two-headed monster we've built for ourselves.
Furthermore, for the vast majority of websites I visit, an assurance from a third party that they are who they say they are is of absolutely no value to me. Take HN: I do not particularly trust ycombinator.com more than I would trust a phisher trying to convince me he is ycombinator.com, so a third party's assurance that this is in fact ycombinator.com doesn't give me any useful information.
"With a self-signed cert, I know I am talking to exactly one party and that no third party can surveil or monitor that communication."
You can't state this. The self-signed cert you are seeing could be the one that my MiTM proxy has substituted on your connection! The only thing that saves you is your Trust Store. I feel like you don't quite understand public key substitution and MiTM attacks. This isnt a Phishing problem, its a 'breaking the encryption between client and server' problem.
"Furthermore, for the vast majority of websites I visit, an assurance from a third party that they are who they say they are is of absolutely no value to me. Take HN: I do not particularly trust ycombinator.com more than I would trust a phisher trying to convince me he is ycombinator.com, so a third party's assurance that this is in fact ycombinator.com doesn't give me any useful information."
This is HIGHLY ALARMING! If this is the case then please use my proxy server and do your banking. Im sure its cool, you don't need to check with a third party that i'm not messing with your encrypted connections.
Which makes that MiTM the one and only one party with whom I am communicating. And I know no other party is surveiling or altering this phishing attempt.
Over this secure channel, my phisher and I can negotiate authenticity, which hopefully he will fail.
If this is the case then please use my proxy server and do your banking.
Sigh. My bank is not ycombinator.com. I don't think YC is even a bank. My bank is one of the few sites I mentioned where I do care about their authenticity because I do trust them more than I trust a potential phisher.
You are not simply substituting the origin with a phish, you are reading/modifying traffic by a third party without any possible detection from the server.
There are three parties. You, Me (the mitm) and your bank. (assuming your bank uses self signed, which it doesnt). Ive substituted my self-signed cert with the banks in your TLS handshake. I then reencrypt everything you send me to the bank. Bank can't distinguish you and I.
We solve this with PKI and trusts.
In this scenario, you're communicating with Z, while M listens in. Anything you send down the pipe can be transparently proxied by M and relayed to Z.
What mechanism can you use to verify the authenticity of the other end that can't be spoofed by M, now that they're inserted into the communication path?
No such mechanism exists, as this bug demonstrates.
Think about it. If you connected to my blog, would it actually give you any useful information if Thawte assured you I am who I say I am? You don't have any reason to trust me more than you would trust someone pretending to be me, because I'm some rando with a blog you got linked to.
I mean, obviously my dream solution where my bank hands me a USB stick with their public key on it when I open an account isn't really feasible, but this bug report makes me wonder what value PKI is really adding.
Without an explicit warning, it's not going to be at all obvious to the average user - or anyone who forgets to check the address bar/isn't enforcing HTTPS - that the connection lacks those properties.
Yeah, but with the current model it could also be subsituted with a cert for which comodo has fucked up the verification again.
Regardless, look at the vast majority of technical users relying on SSH without using a CA for secure communications, had browsers done a better job at self-signed certs we could be doing the same on the web.
How many technical users actually check the fingerprint matches the expected one of the server, out-of-band? Almost everyone I know just accepts the unknown fingerprint, so almost nobody knows who the endpoint they're actually connected to is.
In the mid-90's, CA certs were put into Netscape Navigator (IE joined later) in order to facilitate the new wild wacky concept that someone might buy something online. They called it "e-commerce".
Trust was centralized because it was far easier to add the then ~half-dozen CA's rather then somehow vetting every joe that wanted to self-sign their certs. PGP's web-of-trust existed but it was deemed less viable.
Besides, the whole SSL certs thing was a major business premise behind creating Netscape - profits. Without that there might not have been a dot-com and the huge amount of money that followed since then.
One of the methods that Comodo uses to validate that a certificate applicant owns or controls a domain to be included in the subjectAlternativeName of a server authentication certificate is set out in the CA/B Forum's Baseline Requirements document [2] at section 3.2.2.4.2.
That method may be summarized as the sending of an email to an email address (and obtaining a confirming response) where the email is identified as belonging to the Domain Name Registrant, technical contact, or administrative contract as listed in the WHOIS record of the domain.
So the Browser (Google Mozilla Microsoft) and the CA (Comodo Symantec LE) industry working group agreed that was acceptable.
We have zero idea how many bad certs like this may be out there (the nefarious people won't publish their results, after all), and yet a browser will still treat a Comodo cert as better than a self-signed one (it's identical to a self-signed cert, since Comodo is a known bad actor now). It's better than plaintext, of course, but that's not saying much.
It provides meaningful security. CA signed clearly not the same as self-signed; Maybe you misunderstand what this means?
How is a certificate from Comodo any different from an self-signed certificate? There is actual evidence that they gave a certificate to a third party. That means you should treat any certificate from them as self-signed, because you cannot trust Comodo to do their jobs.
You cannot determine provenance of a self-signed certificate. The sig matches the subject. With a CA signed, the hold of the CA private key is the only source (with high probability), so it is attributable.
If you trust the company or not -- play with you trust store. Otherwise this is apples and oranges.
The only time when this comparison would be apt would be the compromise of the Comodo Private Key. This would allow anyone to issue Comodo certificates, thus removing their provenance. Of course then their cert would be revoked and we wouldn't have this conversation.
Exactly, though I think you meant "provenance". It's exactly like how we now know we can't determine the provenance of a Comodo certificate, agreed?
I think I understand why you are not following what I am saying.
You prove that the certificate came from comodo, and only comodo. It can't have come from anyone else. This isnt trust -- its public key crypto. Only the issuer could sign it. If you trust it or not, its irrelevant, only that it could only have possibly originated from there.
If you believe that the public key is truly owned by the subject because the issuer said so -- this is trust.
> How people still think the PKI system is actually delivering security is beyond me.
It has its problems, but it's what we've got to work with right now, and it's not as bad as you make it seem.
> it's identical to a self-signed cert, since Comodo is a known bad actor now
That's not technically true. I dislike Comodo as much as the next person, but this statement is a bit disingenuous, since you're implying that you can trust anyone who generates their own certificate for google.com or yourbank.com more than a CA-signed certificate. There's a reason PKI exists; it's because self-signed certificates by themselves aren't trustworthy in the wild.
They may have, for that matter. Do you check the issuer every time you go to a secure site? Do you trust them to do a better job securing either of those domains than they did with a large telecom in Austria?
Your browser does (for high-value sites). That's what certificate pinning and HPKP are for.
For that matter, since HPKP requires sideband key management, it's A) an admission that PKI doesn't actually work, and B) a pretty clear example of why the CAs are unnecessary
If you have pinned certificates you are essentially operating exactly the way 99% of us do with SSH (only rather better because there are several million eyes on high-value certificates), which means you don't need CAs anymore.
Pins are either built into the browser by the vendor, or assigned on first access AFTER a successful server authentication (via the cert). Pins are trusted/verified through another channel.
SSH Tofu trust occurs pre server authentication. It has no defense against an ALWAYS mitm. Of course there are far less ALWAYS MITM for SSH than TLS. You have no way of validating the pubkey you have written to known_hosts against anything else.
Right, sideband, and browsers do it manually for domains they consider "high value".
It has no defense against an ALWAYS mitm
For that matter nothing does, since at some point I downloaded my OS or browser (wherever my CA store is) to begin with.
Most of the sites I connect to I don't actually "trust" in any real sense, so a third party assuring me they are who they say they are isn't useful information for me. (Am I being phished right now? It doesn't matter, because I don't trust news.ycombinator.com with any information I wouldn't also give to a phisher.)