(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

September 5, 2017 Comments closed

Should the Browser Community Distrust PROCERT?

in Industry Lowdown

The Venezuelan CA is facing myriad issues, and its response isn’t promising.

Ever heard of PROCERT? If not, I don’t blame you. Until last month, I had not heard of it either.

It is a tiny, government-affiliated Certificate Authority operating in Venezuela. It has issued only a few hundred publicly-known certificates, primarily for .ve domains (the ccTLD for Venezuela) and other Venezuelan websites and organizations.

PROCERT is one of the dozens of regional and government CAs that are almost completely unknown out of its native markets. Many of these CAs handle certificate issuance for its countries’ governments and cater to local laws for digital certificate.

These CAs typically fly under the radar until something goes wrong. The French government CA “ANSSI” was technically constrained to French territories in 2013 after its certificates were found to be used for network interception; and In 2015, China’s Internet Network Information Center CA (CNNIC) was dis-trusted by Google and Mozilla after mis-issuing certificates.

Now, it is PROCERT’s turn.

PROCERT’s root certificate is currently trusted by Mozilla, Microsoft, and Apple. But issues discovered by three independent researchers suggest that the CA is not deserving of that trust.

The earliest issue was reported on August 6th. Alex Gaynor and Jonathan Rudenberg reported the initial problems, and Andrew Ayer discovered additional issues later in the month. PROCERT themselves helped out by inadvertently sharing a certificate issued in 2016 with a 1024-bit key during a failed attempt to show a different violation was incorrect.

In total, seven different violations were found. The issues were formally raised by Mozilla on August 16th and PROCERT has yet to resolve a single one. For many of the issues, the most its representatives have said is “steps are being taken to avoid these drawbacks,” despite being asked to provide a complete incident report by Mozilla.

Here is a complete run-down of the different violations:

1. Issuing a certificate for a “.local” domainIssuing certificates for internal names (IPs and domain names which cannot be registered – such as .local or “localhost”)  has been forbidden by the CA/B Forum since 2016. Because internal names do not have a canonical owner they can be ‘owned’ by anyone and everyone, which represents a security risk for man-in-the-middle attacks.Procert issued a certificate containing multiple internal names earlier this year – a major violation. Because it is impossible to confirm ownership of a .local domain, this suggests Procert’s CA software does not require validation of domain ownership, or that the requirement can be manually overridden. Similar errors have been the cause of high-profile mis-issuances in the past.
2. Issuing a certificate for a URL, instead of a domain.Procert issued a certificate for “http://ripac.insopesca.gob.ve.” The error here was including the scheme “http://” – which is a formatting error forbidden by multiple standards including RFC 5280 and the CA/B Forum Baseline Requirements.
3. Issuing a certificate for a reserved IP Address.Reserved IP addresses are set aside by the IANA (Internet Assigned Numbers Authority) for special purposes. A well known example is “192.168.1.1” – the default address used by most Linksys routers. The entire “192.168.x.x” block is reserved by the IANA for private network use.But, Procert said nuts to that and issued a certificate for 192.168.244.100 earlier this year. This is similar to the first issue above where the IP is an internal name which can not be registered.
4. Not including Common Name as a SANThere are two fields in a certificate where domain(s) can be encoded: the Common Name (CN) and Subject Alternate Name (SAN) fields. The Common Name is a deprecated field that no longer serves a purpose in most client software, but it still hangs around for legacy purposes.The CA/B Forum Baseline Requirements state that the domain name contained in the CN field must also be listed as a SAN. Procert issued a single certificate in violation of this requirement in May of this year.
5. Non-random serial numbers.SSL certificates contain a serial number which is to be unique and random for each CA. This provides both a unique identifier, and protection against collision attacks.Researcher Andrew Ayer reported that since September 30th, 2016,  every publicly-known certificate issued by Procert (24 certificates in total) have been issued in violation of this requirement.
6. “Good” OCSP Responses for Non-existent CertificatesOCSP (Online Certificate Status Protocol) is a revocation mechanism that allows the revocation status of individual certificates to be checked.PROCERT’s OCSP responder incorrectly responds with “Good,” indicating a valid certificate, when given a serial number that does not exist.
7. Issued certificate with 1024-bit key.1024-bit keys have been known to be weak for quite some time – and the CA/B Forum Baseline Requirements forbid the issuance of new certificates using 1024-bit keys since 2010.In an attempt to show that its OCSP responder was working properly, PROCERT provided examples of OCSP responses using a certificate issued in 2016 with a 1024-bit key. After this was pointed out, PROCERT’s representative said the certificate had expired in 2012 – which was patently untrue.
    

In total, PROCERT has mis-issued (at least) 29 certificates. While that number pales in comparison to some other CAs, the root causes behind these problems are deeply concerning.

A certificate profile is a template that dictates the formatting and fields of a particular certificate. CAs should use strictly defined profiles in order to ensure all the certificates they are issuing meet industry requirements – and that they do so consistently.

The range of PROCERT’s violation suggests that it either does not use well-defined profiles, or that it’s a common practice to manually circumvent such profiles. For example, issuing a certificate for an internal name suggests that it is possible for a PROCERT employee to override the technical controls – or that those controls do not exist at all. The same goes for the 1024-bit certificate.

While issuing a certificate to “autodiscover.fospuca.local” may seem like no big deal, the root cause behind that could just as easily result in the unauthorized issuance of a certificate for “Google.com.” This is a major security risk to the entire internet – the kind of risk that undermines the entire Web PKI platform. PROCERT may be intended to serve its local market, but it has a responsibility to the entire internet.

On top of that, PROCERT’s responses demonstrate that it is unfamiliar with industry standards. Its first response incorrectly disputed that “http://” was allowable. It then followed up another incorrect comment by asking the community to provide an OpenSSL command to test its OCSP responder.

Do we really need a CA (which is trusted by millions of devices) that is not competent enough to know how to test its own OCSP responder, nor clever enough to look it up on its own?

It has been three weeks since Mozilla requested incident responses from PROCERT, who have completely failed to provide a report – or anything that could loosely be considered a report – for any of its seven violations.

This incident comes during a flurry of reports by researchers, who have found mis-issued certificates from more than 30 Certificate Authorities, many of which have been able to resolve (or at least begin) proper incident reports. PROCERT is amongst the worst – in terms of issue severity, total number of issues, and flagrant lack of awareness of industry standards.

Two weeks ago, Google’s Ryan Sleevi said “Absent a significantly compelling response, my advice would be that the community consider removing this root from distribution and/or moving to block it.”

The only significant thing PROCERT have provided is a list of reasons to dis-trust its CA. There’s been more than an ample opportunity to respond, and it is clear PROCERT is unable or uninterested in doing so.

It is time to say goodbye to this CA.

• #CA/B Forum
• #Certificate Authorities
• #Distrust