2020 felt more like a maintenance year in the SSL/TLS ecosystem. Other than the certificate validity period changing from 825-days to 398-days, there didn’t appear to be any other significant changes. However, there has been a lot of activity. In this blog, we’ll take a look at some events that occurred in 2020 and look ahead to what’s to come.
Deprecate TLS 1.0 and 1.1
The plan to deprecate TLS 1.0 and 1.1 finally happened. In November 2018, the browsers jointly announced deprecation would happen sometime in 2020. Certification Authorities (CAs) monitored customers to see who were not supporting TLS 1.2 or 1.3 and there were reports that as many as 850,000 sites could be blocked. The deprecation did proceed and most sites continue to provide security using the later versions of the TLS protocol. From a Netcraft survey provided at end of November 2020, we see that 99.85 percent of the more than 89 million servers reviewed support TLS 1.2 or 1.3:
| SSL/TLS Protocol Version | Percentage |
| SSL 3.0 | 0.000065 |
| TLS 1.0 | 0.154781 |
| TLS 1.1 | 0.001369 |
| TLS 1.2 | 34.25 |
| TLS 1.3 | 65.60 |
Certificate Revocation Lists: Mozilla and CRLite
In January 2020, Mozilla introduced CRLite, a new certificate status method. The benefits of CRLite include that it:
- does not require large Certificate Revocation List (CRL) downloads
- removes the privacy concern of the Online Certificate Status Protocol (OCSP)
- maintains performance with online checks, eliminates the CA being the single point or failure
- prevents the browser suffering from soft failure
Mozilla announced that CRLite is currently enabled in Firefox Nightly and Beta for gathering telemetry, but is not in use to enforce revocation checks.
398-day Certificate Expiry Period
After the failed CA/Browser Forum ballot SC22 to reduce SSL/TLS certificate validity in September 2019, Apple changed their policy to minimize certificate validity period to 398-days effective from September 1, 2020. The 398-day rule was moved into the CA/Browser Forum Baseline Requirements through ballot SC31, which was a browser (policy) alignment ballot.
Multi-perspective Validation
In 2018, Princeton provided a paper called ‘Bamboozling Certificate Authorities with BGP’ stirring much discussion at the time. Although BGP attacks are not common with CAs, Let’s Encrypt has implemented multi-perspective validation to improve domain validation security. With the billion certificates that Let’s Encrypt has issued (and more to come), this could mitigate future risk.
Expiring CA Certificates
The trust of the TLS ecosystem starts with root CA certificates, which are embedded and trusted by operating systems and browsers. A root certificate has a long life, typically 20 years; however the certificate eventually expires. Hopefully the CA has migrated to a new root prior to expiration, but that may create a problem with old operating systems and browsers that do not have the new root certificate.
Backwards compatibility is a problem and affected browsers with a Sectigo root in 2020 and will also impact Let’s Encrypt sites which used a IdenTrust root in 2021. The problem can be mitigated with a cross-certificate to another old root or the end users may need to upgrade or change their browser or operating system. Let’s Encrypt has come up with a unique solution where the root signed a cross-certificate which expires after the root certificate expires. This solution will work with Android as it does not check the expiry date of the root.
.Gov Domains to have HSTS Preloading
In June 2020, the DotGov Program announced their intent to preload all .gov domains using the HTTP Strict Transport Security (HSTS) policy. This means HTTPS will be forced for all .gov sites for browsers which support HSTS (i.e., Chrome, Firefox, Opera, Safari, IE 11 and Edge). HSTS is a great tool to provide security to all of the browser users of your site. Reviewing he HSTS list indicates that over 1,000 sites ending with .gov have been preloaded into the HSTS list.
Apple CT Policy Update
Certificate Transparency (CT) was pushed out by Chrome to all TLS certificate types in April 2018. Apple also started requiring publication to CT logs for certificates issued after 15 October 2018. CT has been found to be a great Internet tool to gather information about most TLS certificates issued publicly. The use of CT to find mis-issued certificates has also helped to clean up the quality of the TLS/SSL ecosystem.
Apple updated their CT policy effective from 1 April 2021. The update means that all CAs must support the most restrictive CT policy in order to be compliant with all CT policies and maintain trust with most browsers. Apple’s new policy includes:
- more requirements on log operator diversity
- additional SCT for certificates issued for validity periods greater than six months
- allowance for CT operators to reject non-TLS certificates
- more precise units in representing the policy’s technical enforcement.
Raccoon Attack
I would have thought with all of the specialists working from home and not travelling that more attack research would have occurred, but 2020 was not a year for many reported TLS attacks.
We did get an announcement of the Raccoon Attack. Raccoon exploits a timing vulnerability with the processing of the Diffie-Helman (DH) secret in the cipher suite. A success would allow the attacker to break encryption and read sensitive communications (e.g., passwords, credit card numbers, etc.) transmitted between a browser and a server. To mitigate this attack, server operators should drop support for DH and DHE cipher suites. This attack is also mitigated by communicating with TLS 1.3, which is already supported by more than 65-percent of servers.
Chrome Root Program and Root Store
Google announced the Chrome Root Program and the Proposed Chrome Root Store at the CA/Browser Forum meeting in October 2020. The Chrome root program takes advantage of the Mozilla root program for verifying CAs before allowing new root certificates to be embedded. The proposed Chrome root store appears to have fewer roots than Mozilla. New roots will be accepted if the CA:
- is widely used and is updating key material
- only issues TLS server certificates
- has been reviewed through a widely-recognized public discussion program (e.g., Mozilla)
- maintains sole control over all CA key material
- has been audited to WebTrust for CA/BR criteria.
Firefox HTTPS-only mode
Mozilla has launched HTTPS-only mode in Firefox release 83. HTTPS-only mode will ensure Firefox users are protected by HTTPS for all sites. If a browser goes to an HTTP site, Firefox will display an error page indicating the security risks. The user may still opt to continue to advance to the unsecure HTTP site.
Kazakhstan and another MITM Certificate
The country of Kazakhstan has issued another root certificate, which it is trying to get their citizens to install. When the root is installed, it allows citizens to trust server certificates that can be used in man-in-the-middle (MITM) attacks on a few websites. A similar attack was attempted in 2019. Mozilla and other browsers have blacklisted this root certificate to help protect their users in Kazakhstan.
To 2021 and Beyond
Will 2021 also be a maintenance year? There is no forecast for a change to crypto technology. We should continue to be safe with SHA-256 signatures, 2048-bit RSA keys, 398-day certificate validity and the TLS 1.3 protocol. That said, we may see some simple security improvements.
OU Field Changes
The organization unit (OU) field in the certificate subject name of certificates is under some scrutiny because it does not really help browser users. It does help certificate subscribers. The server owner may be used OU for some type of tracking information. The OU may provide information on the company department name or a department number. Poor validation of the OU could be confusing to a browser as it may imply that the certificate was issued to a different entity.
DigiCert decided to deprecate the OU and stated: “The OU field allows optional metadata to be stored in a certificate, however, it’s intended purpose is extremely limited and is subject to validation requirements. To reduce confusion around this optional field and to help improve validation times, we are removing it from future ordering processes.” I agree. Since it is difficult to provide automation, the OU field must be validated manually, which slows down validation.
The CA/Browser forum has also discussed removal of the OU or keeping the OU with improved validation requirements. As such, we can expect some changes to the OU in 2021.
Delegated Credentials for TLS
Over the past couple of years, delegated credentials for TLS has been developed by Cloudflare, Facebook, and Mozilla. This is also being documented as a proposed delegated credential IETF RFC.
The delegated credential mechanism allows a server operator to use the private key from their server to issue a delegated credential. The delegated credential will have a different private key and a validity period of no greater than seven days. Since the delegated credential is only valid for a short period of time, there is no status protocol required to be checked, that is, no CRL or OCSP response.
The mechanism will increase security by allowing new private keys to be created in a short period of time. Since the delegated credential is near the server, it is not hindered by having to reach out to the CA for a delegated credential or a short period certificate.
Regarding deployment, we might be waiting for RFC finalization and support from other browsers. We will see if this will be deployed in 2021.
And, there you have it – a brief look at a very active year in the TLS/SSL ecosystem. Find out more about how Entrust can help you manage your TLS/SSL environment here.
The post Looking Back at 2020 appeared first on Entrust Blog.
*** This is a Security Bloggers Network syndicated blog from Entrust Blog authored by Adam Gothmann. Read the original post at: https://blog.entrust.com/2021/01/looking-back-at-2020/