800-pound Comodo tries to trademark upstart rival’s “Let’s Encrypt” name

(credit: wbeem)

Comodo, the world's biggest issuer of browser-trusted digital certificates for websites, has come under fire for registering trademarks containing the words "let's encrypt," a phrase that just happens to be the name of a nonprofit project that provides certificates for free.

In a blog post, a Let's Encrypt senior official said Comodo has filed applications with the US Patent and Trademark Office for at least three such trademarks, including "Let's Encrypt," "Let's Encrypt with Comodo," and "Comodo Let's Encrypt." Over the past few months, the nonprofit has repeatedly asked Comodo to abandon the applications, and Comodo has declined. Let's Encrypt, which is the public face of the Internet Security Research Group, said it has been using the name since November 2014.

"We’ve forged relationships with millions of websites and users under the name Let’s Encrypt, furthering our mission to make encryption free, easy, and accessible to everyone," Josh Aas, ISRG executive director, wrote. "We’ve also worked hard to build our unique identity within the community and to make that identity a reliable indicator of quality. We take it very seriously when we see the potential for our users to be confused, or worse, the potential for a third party to damage the trust our users have placed in us by intentionally creating such confusion."

Read 5 remaining paragraphs | Comments

HTTPS certificates with forbidden domains issued by “quite a few” CAs

(credit: Ed Yourdon)

Browser-trusted certificate authority (CA) Comodo said it mistakenly issued transport layer security credentials for "mailarchive," "help," and at least five other forbidden names and warned that "quite a number" of unnamed competitors have committed similar violations.

The non-compliant certificates are forbidden under the baseline requirements enforced by the CA Browser Forum, an industry group of CAs and browser makers that establish rules CAs must follow for their digital certificates to be trusted in Chrome, Internet Explorer, and other major browsers. The rules forbid the issuance of certificates for internal names that aren't part of a valid Internet domain name or for a reserved IP address such as 192.168.1.1.

The rules are designed to prevent the issuance of certificates for names such as “exchange,” “mailserver,” “domain," or "localhost," which many operating systems and organizations use to designate internal servers or other resources. The regulations similarly bar certificates for public IP addresses reserved for routers or other internal resources inside a home or organization network. A CA-issued certificate for something as generic as "mailserver" or "192.168.1.1," for instance, could be used to spy on or impersonate any resource that used that name or IP address. The baseline requirements bar all CAs from issuing certificates with such internal names or IP addresses and expire after November 1, 2015.

Read 5 remaining paragraphs | Comments

Operation Black Tulip: Fox-IT’s report on the DigiNotar breach

Creative Commons photo of black tulip courtesy of Photography_Gal's Flickr photostreamFox-IT, the security auditors hired to investigate the compromise of DigiNotar, the digital certificate authority that signed fraudulent certificates for Google, the CIA and others, released their preliminary findings this afternoon.

It’s at least as bad as many of us thought. DigiNotar appears to have been totally owned for over a month without taking action, and they waited another month to take necessary steps to notify the public.

Fox-IT’s report shows that the initial compromise appears to have occurred on June 17th, 2011. On the 19th DigiNotar noticed the incident, but doesn’t appear to have done anything about it.

July 2011 calendarThe first rogue certificate (as far as we know), *.google.com, was issued on July 10th, 2011. All of the other 530 rogue certificates were issued between July 10th and 20th.

There are several very disturbing conclusions about security at DigiNotar and the investigation isn’t even complete yet:

  1. All of the certificate servers belonged to one Windows domain, allowing the compromise of one administrator account to control everything.

  2. The administrator password was simple and could be easily brute forced.
  3. Much of the malware and tools used in the attack would have been easily detected by anti-virus, had it been present.
  4. The software on public-facing servers was out of date and unpatched.
  5. They had no centralized nor secure logging.
  6. There was no effective separation of critical components.

The attacker left behind a message in one of the scripts used to generate the rogue certificates, arguably tying this attack to the earlier attack against Comodo back in March of this year.

The message reads in part:

“THERE IS NO ANY HARDWARE OR SOFTWARE IN THIS WORLD EXISTS WHICH COULD STOP MY HEAVY ATTACKS
MY BRAIN OR MY SKILLS OR MY WILL OR MY EXPERTISE”

Flag of IranFox-IT analyzed the lookups against DigiNotar’s OCSP servers (which browsers check to see if a certificate has been revoked) and determined that during the active attack period more than 99% of queries originated in Iran.


Video showing origin of OCSP queries against DigiNotar’s servers courtesy of Fox-IT.

This is the most solid evidence yet that these certificates may have been used by the Iranian government or ISPs to spy on private communications of Iranian internet users.

Many of the other requests not originating from Iran appear to have originated via Tor exit nodes or other proxies used by Iranians to avoid censorship.

This indicates that the method used to perform the man-in-the-middle attacks with these certificates likely depended on DNS poisoning at the ISPs.

While some folks are complaining that too much fuss is being made over this attack, it is far more important than many other stories that the security press have been obsessed with over the last two years.

This incident demonstrates in a real way the fragility of the SSL/TLS certificate trust model in use on the net today.

ConvergenceI hope adoption of replacement technologies like Moxie Marlinspike’s Convergence take off in a meaningful way to provide us with more confidence in the security of our communications.

We now know not to trust certificates issued by DigiNotar, but how many of the 600+ other certificate authorities have similar security holes and may already be compromised?

Creative Commons photograph of a black tulip courtesy of Photography_Gal’s Flickr photostream.



Fraudulent Comodo Digital Certificates Affect Multiple Services

Earlier today news was made public regarding nine fraudulent digital certificates which were issued by a company named Comodo. The certificates were issued through a breached registration authority (RA), causing the applicant to be improperly verified. Mozilla, Google, and Microsoft (major browser vendors) have updated their applications, or put out patches, in order to block the certificates from being used. The certificates have already been revoked as of last week.

To provide a little background, browsers include a list of certificates which are 'blacklisted'. These certificates are ones which have been compromised through some method and no longer validate the authenticity of the person using it. Since they were reported as 'compromised', the browser vendors ship a patch, or updated version of the browser itself, which recognizes these certificates and blocks them from being used.

Users who don't use updated browsers or patched machines may be lead to malicious Web sites which are able to prove their fake identity. For example, someone with a stolen certificate for 'Company X' will be able to host a site wherever he wanted to telling people that he was indeed 'Company X'.

Why does it matter?

If we look at the list of certificates which are involved in this incident, we see a lot of legitimate and popular services being targeted, including but not limited to Google, Google Mail, Yahoo!, Microsoft Hotmail/Live Mail, and Mozilla add-ons.

The first theory which comes to mind is that the person behind the compromise wanted to somehow get credentials, and subsequent access, to mail and other communication accounts. According to this report from Comodo, the attack originated in Iran. The same article goes on to speculate that the perpetrators of this attack may have been state sponsored. While we don't have any information which could either support or dismiss this information, the incident reminds us of the issue which took place earlier this year in Tunisia where, allegedly, some entity was stealing its users' credentials. The Mozilla add-ons could have been targeted here to prevent usage of add-ons which circumvent censorship filters at the country's network perimeter. Anyway, I digress.

For end users, the key here is to somehow get alerted if they visit a Web site which isn't who it claims to be, using these stolen certificates. There are two ways by which certificates are revoked - Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP).

If this incident is indeed state sponsored, then the revocation process has a few gaps to overcome. For CRL and OCSP to work effectively, there is a dependency on the network itself. OCSP requires a query to be sent to an authority, to check on the status of a certificate being used on a Web site. A similar process goes for the CRL method. A CRL is most effective when a computer has checked for the latest published CRL. Both techniques rely on the machine having accessibility to the revoking authority. If a state, any state, is behind such an attack, they can easily make changes to the network such that access to the revocation lists are blocked. Once that is done, the users wouldn't know that they are dealing with a impersonated Web site. Users affected by such a state-sponsored attack wouldn't even know about it.

Thus, to help mitigate scenarios where a system may not be able to reach revocation lists when presented with a fraudulent certificate, Mozilla, Google, and Microsoft have shipped updates that will locally recognize the fraudulent certificates without needing to query the CRL or OCSP.

At this point, we urge all users to update their browsers to the latest version, and make certain that they have this patch installed on Windows machines. The issue affects all operating systems and all browsers.