Author: Christophe Gérard

CPO - Nameshield Group

SSL/TLS certificate duration reduced to 45 days by 2027:Apple takes the first step

On October 9, Apple revealed to the CA/Browser Forum that it had posted a draft ballot for comment on GitHub regarding two important SSL/TLS certificate lifetime events:

  • Gradually reduce the maximum duration of public SSL/TLS certificates to 45 days by 2027;
     
  • Gradually reduce the reuse period for DCV challenges to 10 days by 2027.

In March 2023, in its “Moving Forward, Together” roadmap, Google announced its intention to offer the CA/B Forum a reduction on the maximum possible validity period for public TLS certificates going  from 398 days to 90 days. Since this announcement, the market has been feverishly awaiting for Google’s confirmation but most of all, for the implementation’s timetable… without success. For its part, Mozilla announced, a few weeks ago, its intention to follow Google’s lead on its Firefox browser, without adding any further detail.

Apple ultimately took the first step last week, announcing on October 9th its intention to both reduce the lifetime of certificates to 45 days (when the entire market was expecting 90 days) and to limit the duration of the DCV challenge to 10 days, according to the schedule below. A true bombshell:

Sep-15-2025 => certificates and DCV validation times reduced to 200 days

Sep-15-2026 => certificates and DCV validation times reduced to 100 days

Apr-15-2027 => certificates and DCV validation times reduced to 45 days

Sep-15-2027 => DCV Validation time: 10 days

Information on the background and analysis of this announcement, the expected outcomes and how to prepare for them will undoubtedly be useful:

Context and Analysis:

At this stage, the publication is likely to be commented by market players prior to the formal drafting of the ballot within the CA/B Forum, which itself will be voted on by its members: the Internet browser publishers on the one hand (Google, Mozilla, Apple and Microsoft…) and the Certification Authorities on the other. Amendments are bound to be made, but the general idea remains and the machine is up and running.

Indeed, software publishers are all aligned on the need to reduce the lifetime of certificates, and among Certification Authorities, Sectigo, one of the major players in the certificate industry, is already supporting the initiative. It is likely that things will move rapidly from now on, with few comments and a ballot drafted in the coming weeks or months. We will then know more about the confirmation of the durations and timetable, and will of course make sure to keep you informed.

Expected Outcomes:

  • Certificate lifetime: whether 90 days, 45 days or even less, this reduction is no longer a surprise, and will have a major impact on public certificate portfolio. The certificates can no longer be managed manually. The market has begun its transition to automation, notably through CLMs (Certificate Lifecycle Managers). The issue at stake for companies and organizations will be to rely on partners who can offer as many interconnections as possible between Organizations, Certification Authorities and CLMs.
     
  • DCV challenge duration: Reducing the duration of the DCV challenge to 10 days, if validated, would have a considerable impact, perhaps even more so than reducing the lifetime of certificates. Up until now, the industry has pre-validated domain names for 398 days, using the DCV challenge only once. Apple’s announcement would thus force the use of a DCV challenge for virtually all orders, which would be a major paradigm shift and would involve interconnections with an additional brick in the ecosystem: the DNS. The DCV (Domain Control Validation) challenge involves intervening in the zone of the domain name(s) listed in the certificate, ideally instantaneously, to validate it.
     
  • Organization authentication duration: Apple has not announced anything on the subject of the validity period of organization authentication for OV certificates, which is currently 825 days. However, rumors are circulating that this may be reduced to 398 days or even 365 days.

How to be ready:

The key to successful certificates management lies in automation. A 45 days certificate lifetime represents 9 interventions per year per certificate. Manual management thus becomes utopian. We therefore need to rely on:

  1. Certificate Provider/Certification Authority (CA): a trusted partner who will support through your organizational and domain authentication issues. Service level is key to good management. A multi-CA partner is thus recommended to limit dependence on a single CA, as in the case of Entrust’s recent setbacks. 
     
  2. Registrar / Primary DNS: mastering the primary DNS of domain names listed in certificates will become the key to delivery. Each time a certificate is issued, a TXT or CNAME will be installed on the zone(s) in question. An interconnection between the CA and the DNS is vital.
     
  3. CLM editor: the CLM’s role is to inventory the certificate portfolio, to define certificate portfolio management rules and automate the entire process of orders, from the generation of CSRs to the deployment of certificates on servers. To function properly, the CLM relies on connectors with CAs or certificate suppliers.

Getting ready thus means identifying the most suitable solution, based on these three dimensions, and undertaking this analysis to understand the impacts in terms of process, technology, and budget – in an ideal world – before the end of the first half of 2025.

Nameshield’s approach:

Nameshield holds a unique position in the market as a registrar and supplier of multi-AC certificates. For over 10 years, we have been managing the day-to-day issues associated with authenticating organizations and domains using certificates. On the one hand, we have a privileged relationship with the biggest CAs on the market (Digicert, Sectigo, GlobalSign), and on the other, we master the DNS brick for DCV validation. As a result, we can issue public certificates almost instantaneously. Last but not least, Nameshield has connectors with the major players in the CLM market, allowing you to ensure a comprehensive connection between the various components involved in certificate management. This way, we can support you in anticipating all the issues mentioned above.

SSL/TLS certificate duration reduced to 45 days by 2027:Apple takes the first step

For more information, please contact our Sales team or our Certificates team.

Crédit image : Nameshield with storyset.com

BIMI and VMC: display your logo with emails

BIMI and VMC: display your logo with emails

BIMI (Brand Indicators for Message Identification) allows you to authenticate your emails and reinforce the trust of your customers by displaying your logo in their inbox. VMC (Verified Mark Certificate) is a certificate associated with BIMI, which ensures the authenticity of the logo displayed.

BIMI - Nameshield

What is BIMI?

BIMI is an industry initiative aimed at standardizing the use and display of brand logos in email clients. By placing a brand or company logo next to an email, it is more easily identifiable by customers and users, builds a sense of legitimacy and trust, significantly impacts open rates, and increases consumer protection against fraudulent emails.

Technically speaking, BIMI is an emerging security technology that works alongside DKIM, SPF and DMARC protocols to protect your domain name from being used by malicious actors to send fraudulent emails.

Before BIMI, the steps to get your logo next to an email were specific to each email service your message was sent to. Sometimes the process was entirely manual or relied on other applications to aggregate your brand information and share it across participating platforms.

The AuthIndicators group, which includes email service providers such as Google, Verizon Media, IONOS by 1&1 and Fastmail, is working to implement BIMI in the most common email clients. Many players have already adopted BIMI, others are in the process, Microsoft’s and Apple’s positions are expected to drive final adoption of the standard.

Why is BIMI important?

To complete the arsenal of a brand’s protection on the Internet, more specifically against hijacking attempts through fraudulent spoofing emails whose goal is to deceive the user and lead them to phishing sites.

306 billion emails circulated worldwide in 2020, with an ever-increasing proportion of fraudulent emails hijacking brands.

To increase the desirability of emails, particularly in marketing campaigns. The implementation of BIMI and more widely of security protocols and certificates on the domain name associated with a brand is essential today and has a major impact on online reputation.

Because it is becoming a market standard, easy to implement unlike the number of existing anti-fraud email solutions that are often difficult to test and implement.

How does BIMI work?

BIMI uses a process of several steps to validate emails by ensuring that they are actually associated with the sender’s domain name. Senders must add a TXT DNS record dedicated to BIMI.

For BIMI to work, domain names must also have several other fraud protections, including:

  • SPF (Sender Policy Framework): authenticates emails by identifying mail servers authorized to send from specific domain names ;
  • DKIM (DomainKeys Identified Mail): adds a digital signature to each email to verify that it was sent from an authorized domain name;
  • DMARC (Domain-Based Message Authentication, Reporting, and Conformance): confirms SPF and DKIM records and specifies how non-compliant emails should be handled.

When emails are sent using BIMI, the receiving mail server will first do the standard DMARC/DKIM authentication and SPF validation. If the email passes these checks, the mail server will verify that it has a valid BIMI record and display the brand logo.

How does BIMI interact with DMARC, DKIM and SPF?

The first step towards using BIMI to display a logo is to implement DMARC. This is stored as a DNS record of TXT type on the domain name. For DMARC to work with BIMI, the reject policy in this record must be p=quarantine or p=reject for all emails sent from your domain.

BIMI requires DMARC… and DMARC requires your domain name to have DKIM records to work. While DMARC only requires SPF or DKIM to work, it is best to include SPF records for more security when using BIMI. These 2 security tools are also stored as TXT DNS records in the domain name zone.

VMC, the final link in the chain

A Verified Mark Certificate is a digital certificate that authenticates the ownership of a logo, and completes the use of BIMI in email clients such as Gmail.

The VMC certificate guarantees the authenticity of the logo displayed, which is necessarily owned by the domain name holder sending the email. It is the last link in the chain to guarantee the authenticity of the email received.

When you send an email to a contact, the receiving mail server that manages their inbox will take the URL of the tag that indicates where the logo should be displayed. It will then check the VMC certificate to ensure that the correct logo is used. Once the logo is verified by the VMC, BIMI will display it next to the email in the inbox.

To obtain a VMC certificate, the implementation of DMARC on the domain name is a prerequisite. Then follows a reinforced authentication process with a Certification Authority that will validate the identity of the Organization, the registration of the logo with a certified body and will issue the certificate after a one to one meeting with a notary.

Depending on the country, the intellectual property offices for logos registrations may vary as well as the rules of acceptance to issue the certificate. The notions to keep in mind, the authorized trademarks can be:

  • Design trademarks: consist exclusively of a design;
  • Verbal trademarks: contain words, letters and/or numbers, without any particular font, size, color or style;
  • Combination trademarks: include a combination of words with a design, stylized letters or numbers.

While this is not a requirement for implementing BIMI on your domain name at this time, VMC should be part of the standard in the future.

Entrust Datacard and DigiCert are the first 2 companies to issue VMC certificates for the BIMI standard. Nameshield is a partner of both companies and will assist you in obtaining VMC certificates. You can contact directly our certificates department for any question on the subject.

BIMI + VMC = Guarantee of authenticity

BIMI, VMC… and Nameshield

Nameshield now assists its customers in all aspects of the implementation of DMARC, SPF, DKIM, but also BIMI protocols and the obtaining of associated VMC certificates. The domain name is at the core of the implementation of these different protocols. Our historical business as a registrar and DNS zones manager allows us today to assist our customers on these major subjects of the fight against online fraud and the increase of emails desirability.

Firefox 83 launches HTTPS-Only mode

On November 17, Mozilla released the version 83 of the Firefox browser, promising improved performance in terms of page loading and browsing responsiveness, as well as a significant reduction in the memory used.

But above all, Mozilla introduces a brand-new security feature to the small world of browsers, an “HTTPS-Only Mode” option to limit browsing to secure HTTPS* connections only.

Firefox 83 launches HTTPS-Only mode
Image source: Mozilla Security Blog

Mozilla is pushing it further regarding the desire of major browsers to pass HTTPS as the default browsing protocol instead of the unencrypted and therefore fully visible HTTP.

Which display during browsing?

When the option is activated, any web page that does not have an SSL/TLS certificate (allowing the HTTPS and the security padlock icon to be displayed in the browser address bar) will be preceded by the warning message below, which is restrictive for web users.

Firefox 83 launches HTTPS-Only mode
Image source: Mozilla Security Blog

What to expect in the coming years?

If the option is not yet activated by default, Mozilla’s management indicates that it expects HTTPS to become the standard for browsing the Web. Driven by the successive evolutions of browsers and their increasingly obvious displays of a lack of security, more and more websites are migrating to HTTPS by default. It is likely that browsers makers will decide to completely depreciate HTTP connections in the near future, making HTTPS the default protocol for Web browsing.

How can companies be prepared?

Most companies have already begun the migration of their website(s) to the HTTPS by default. It is important to maintain an exhaustive inventory of the company’s websites and pages and to control the associated SSL-TLS certificates, of which the main risks are renewal errors and poor implementation. It is essential to set up clear procedures and to associate to them a good communication towards the interlocutors in charge of the websites. Actors such as Nameshield are there to accompany you in this process. They have the expertise and tools necessary to simplify these tasks and reduce the risk of error.

The dangers of Wildcard certificates

wildcard certificate - TLS/SSL certificates
Image source: skylarvision via Pixabay

TLS/SSL certificates are used to authenticate servers (mostly Web) and encrypt traffic between websites and users. Thus, they ensure the integrity of the data exchanged and prevent data spying. The digitalization of the company and the world in general, as well as the browsers’ desire to impose HTTPS:// by default, have multiplied exponentially the need for certificates.

To meet these growing needs, the wildcard certificate (*.domainname.com) is increasingly being considered by companies. While it has some advantages, particularly in terms of costs reduction and flexibility, it is important to be aware of the disadvantages in order to choose the right certificate wisely. A brief overview of the wildcard certificate.

What is a wildcard certificate?

A standard TLS certificate secures an explicit host name (CN for Common Name or FQDN for Fully Qualified Domain Name) defined in its metadata. For example, Google holds a certificate for mail.google.com.

  • This certificate is only valid for: https://mail.google.com/
  • It cannot be used for: https://google.com/ – https://images.google.com/ – https://my.mail.google.com/

In other words, the host name must be an exact match. If you try to use this certificate on https://my.mail.google.com/ you will get a certificate error from your browser.

A TLS wildcard certificate is different. As its name implies, it uses a generic match rather than an exact match. This generic match is represented by “*” in the CN and covers all subdomains of the same level. Example with the *.google.com certificate.

  • This certificate is valid for: https://mail.google.com/ AND https://images.google.com/ as well as all possible subdomains of google.com.
  • It cannot be used for: https://google.com/ (without subdomain) or https://my.mail.google.com/ (the subdomain level is not the same).

The practical side of the wildcard certificate?

In some situations, the wildcard certificate is very useful. A host that proposes websites for different clients, hosted on a shared server, and accessible through different subdomains… client1.mysite.com, client2.mysite.com, client3… It is less practical, technically more complicated and de facto more expensive to ask for a new certificate for each client that registers; the simplest option is a wildcard certificate for *.mysite.com, a unique certificate that will cover all clients. The case is identical for a company that wishes to access its websites through FQDN derived from the same domain and hosted on the same web server, *.mycompany.com. So far, everything is okay.

But then, what is the risk?

In the cases above, all sites are hosted on a single server. In large companies, or for major websites, hosting is often more complex and on different servers. Let’s take again our example of Google with images.google.com and mail.google.com, these two applications are linked to different services of the company, hosted on different servers and managed by different technical teams. This kind of organization is extremely frequent in the company. And this is where the security of wildcard certificates stops.

The problem with wildcard certificates, and to a lesser extent with certificates containing multiple entries (the famous SAN, Subject Alternative Names), comes from the fact that they are deployed on several servers. Indeed, to ensure the security of a TLS/SSL certificate, it is absolutely necessary to protect the private key associated with the certificate. Ideally, it should be stored in a vault or in a HSM. When a certificate is installed on several servers, the associated private keys circulate, increasing the exposure to the risk of compromise.

Case of a compromised certificate

In case of a compromised certificate, or an error on the certificate (renewal problem), it is recommended to intervene quickly to limit the damage caused. Application for a new certificate (or renewal), installation of the new certificate and, if necessary, revocation of the compromised certificate.

In our example of creating websites on a single server, this is not a problem. We have only one server, it has been compromised, the stolen/expired/compromised certificate only works for this one server; we have limited the damage as much as possible.

In a “several servers” scenario, if the certificate of only one of the servers is affected, it becomes compromised on all of the servers, which will have consequences on all of them and require a much wider intervention to repair the damage, most often in an emergency, and assuming that all of the affected servers are identified. Indeed, it is not uncommon for the certificate to circulate within several teams and to be installed without being listed on a certain number of servers. The impact can be important.

Taking our example of Google. Let’s imagine that only the images.google.com server has been hacked and that mail.google.com has not been affected. The certificate for images.google.com being a wildcard certificate for *.google.com which is common to mail.google.com, the cyber-attacker having compromised the images service has by rebound usurped the identity of the mail.google.com server and can intercept the traffic of the mail service while this server has never been hacked!

Good practice: one TLS/SSL certificate per server…

In our last example, if we were to have two certificates instead of one, with each server having only access to its own certificate, we would have limited the risk. In an ideal world, each certificate should only be used for one server (or a homogeneous cluster of servers). Different services on different servers should have their own certificates, generally not wildcard certificates.

A wildcard can be used if you have a lot of host names, of subdomain type, pointing to the same service on the same server. Be careful however that this generic certificate does not also cover host names pointing to other servers, in which case each service should have its own certificates.

Lastly, if you have a few host names pointing to single servers and everything else on a single service, then it is better to disassociate the host names. For example, you may have a certificate for login.mysite.com and a (wildcard) certificate for *.clients.mysite.com. On this last example, if the number of clients is fixed or clearly defined, it is better to go for a certificate with a precise SAN list, to better control secure host names and not allow the httpS:// on uncontrolled host names.

Conclusion

The option of a wildcard certificate exists and it is a good thing for some very specific needs. But in practice, there should never be a need to install a wildcard certificate, nor should the same certificate be installed on different servers not built in cluster.

HTTPS://: China doesn’t like confidentiality and blocks the ESNI extension

China doesn't like confidentiality and blocks the ESNI extension- Great Firewall
Image source: HealthWyze via Pixabay

According to a joint report by iYouPort, the University of Maryland, and the Great Firewall Report, TLS connections using the preliminary encrypted SNI extension (ESNI) are being blocked in China. A new step towards censorship and a desire to be able to track Internet users.

What is SNI (Server Name Indication)?

When an Internet user consults a website in HTTPS://, it means that the site is secured by an SSL/TLS certificate. The consultation of the website begins with the establishment of the secure connection, the “handshake”. This handshake consists of several steps and aims to check the certificate and establish the encryption level of the connection. The first message of a TLS handshake is called “client hello”. With this message, the client asks to see the TLS certificate of the web server. The server must attach the certificate to its response.

Presenting the right certificate poses no problem in the case of dedicated hosting: one IP address, one certificate, possibly containing several SAN (Subject Alternative Name) belonging to the same organization. The problem occurs with shared hosting where the host has the same IP address but wants to install several different certificates, otherwise he will have to be the owner of the certificate by adding SAN for all his customers. Not a recommended practice.

The SNI responds to this specific request from hosting providers and their shared hosting. With the SNI protocol, the client indicates the hostname with which it tries to start a TLS negotiation. This allows the server to present several certificates for the same IP address (but different host names). The SNI could be compared to the apartment number of a postal address: a building has several apartments, so each apartment must be identified by a different number. Similarly, if the server is indicated by the IP address, client devices must include the SNI in their first message to the server to indicate which website (which apartment) they are trying to reach.

What is ESNI (Encrypted Server Name Indication)?

The establishment of an encrypted TLS connection begins at the end of the handshake. Problem, the SNI is not encrypted because the “client hello” message is sent at the beginning of the TLS handshake. A hacker can reconstruct the path of an Internet user by reading the SNI part of the handshake, even if he is not able to decrypt subsequent communications. The main interest for the pirate is to be able to trick the Internet user by creating a phishing site. On the other hand, the major web players like confidentiality, and wish to preserve the confidentiality of users’ browsing data. The ESNI was therefore born.

The ESNI (Encrypted server name indication) encrypts the Server Name Indication (SNI) part in the TLS handshake. The ESNI extension is accessible through the latest version of the TLS protocol, 1.3, which is being increasingly adopted today. The principle is to retrieve an encryption key through DNS (which can be secured through DNS via HTTPS). Still at the draft stage, some large hosting providers are already implementing it.

And China in all this?

In their report, iYouPort, the University of Maryland and the Great Firewall Report, detail how China views handshake encryption in a very negative light. This effectively prevents the Chinese government’s Great Firewall monitoring tool from seeing what Internet users are doing online. China has therefore decided to simply block HTTPS connections established through the latest version of the TLS protocol (1.3) associated with ESNI. In addition, the IP addresses involved in the connection are temporarily blocked for two to three minutes.

Some circumventing methods exist… but until when?

All three organizations appear to have found circumventing methods to apply on either the client side (in applications and software) or the server side to evade the current blocking implemented by the Great Firewall. ” Unfortunately, these specific strategies may not be a long-term solution: as the cat and mouse game progresses, the Great Firewall will likely continue to improve its censorship capabilities“, write the three organizations in their report.

The importance of reverse DNS

Reverse DNS - Nameshield
Image source : Jonbonsilver via Pixabay

Reverse DNS is often unknown to domain name managers, especially when the names are hosted by major hosting companies. Reverse DNS allows you to resolve from an IP address to an FQDN. This is the exact opposite of the classic use of DNS, which associates domain names to IP addresses. The reverse DNS allows to answer the question: I have an IP address, what is the FQDN related to it?

Reverse DNS operates by creating a reverse DNS zone in which DNS PTR records (for Pointer Record) will be configured.

  • Classic DNS: Record A: we know the name of a site and we want to obtain its IP address…
  • Reverse DNS PTR: we know an IP address and we want to retrieve the name of the site.

The resolution system is constructed in a similar way to the classic resolution. To perform DNS resolution, the IP address to be queried is configured in the reverse zone with the suffix .arpa and points to the required destination. The principle is the same for IP v4 and v6 addresses according to the following construction:

Ex: IPv4: 11.80.92.81.in-addr.arpa. IN PTR capp.perf1.com.

Ex: IPv6: 0.0.0.0.0.0.0.0.0.1.0.1.0.0.0.0.0.8.c.0.0.1.0.a.2.ip6.arpa. 4080 IN PTR capp.perf1.com.

This construction enables to operate a classic DNS resolution on a domain name with a “.arpa” extension.

Why is this so important?

Reverse DNS is mainly used to track the origin of a website visitor, the origin of an e-mail message, etc. It is usually not as critical as the classic DNS, visitors will reach the website even without the presence of reverse DNS for the IP of the web server or the IP of the visitor.

However, Reverse DNS is important for one particular application: the e-mail system.

Many mail servers on the Internet are configured to reject incoming mail from any IP address that does not have reverse DNS. For those who manage their own mail server, reverse DNS must exist for the IP address from which the outgoing e-mail is sent.

Regardless of the address to which the reverse DNS record of the IP address points, a reverse DNS record is expected. In case of hosting several domains on a single mail server, it is enough to configure the reverse DNS to point to the domain name considered as the main one (mail servers checking the reverse DNS recognize that it is normal to host many domains on a single IP address and that it would be impossible to list all these domains in the reverse DNS for IP). We recommend that you check the possibility of setting up reverse DNS with your DNS hosting solution.

Choosing the right TLD based on DNS performance

Comparative analysis of the famous Top Level Domains (.com, .fr…)

The crux of the war for high-visibility websites is the download time. As a natural referencing factor admitted by Google, this download time can be significantly impacted during DNS resolution. If it is necessary to rely on a first-class DNS infrastructure, the choice of the extension associated with a domain name is important. Indeed, not all registries perform equally well in terms of DNS, not to say that some have disappointing performance. The offer in terms of TLDs (nearly 1400) has greatly increased since ICANN’s New Extensions Program. Analysis to follow.

A quick look at DNS resolution time and its impact on load time

Resolving a domain such as nameshield.net follows several steps before you can contact the content server. The DNS resolver contacts the root DNS servers (.), then the DNS servers of the registry of the extension concerned (.net) in order to obtain the list of DNS servers responsible for the domain, and finally these DNS servers to obtain the requested response. The response obtained is certainly cached by the DNS resolver (generally managed by the Internet Service Provider), but this will not always be the case depending on the popularity of your domain.

This means that if the DNS for the top level domain (.net) is slow, it may actually delay DNS resolution for the domain itself and, in the very unlikely worst case scenario, even cause a breakdown. There’s not much you can do about this, apart from choosing the right TLD.

Comparative Analysis

Bunny CDN, a Slovenian content delivery player, conducted the following surprising analysis. Relying on their global network, they monitored DNS performance worldwide from more than 50 sites and networks.

For each TLD, their system chose a random name server published for each top-level domains and queried a random domain name. The results were grouped by region and the data recorded every 10 seconds.

Results

They tested 42 of the most popular top-level domains and then aggregated the results into a global median average and an 85-percentile aggregation (the 15% slowest responses were not taken into account). These tests were conducted only from their network, so a more complete study would certainly be worthwhile, but they provide a good overview.

Choosing the right TLD based on DNS performance
Source : BunnyCDN

The results were quite surprising

The most surprising domains are .info and .org, which have shown really poor performance, especially in the 85 percentile range, despite their seniority and the millions of domains registered. It seems that 4 of the 6 names servers function extremely poorly, which explains the poor results.

The .net and .com have been very slightly slower than expected in Europe and North America, but otherwise offer excellent and stable performance in all regions, visible in the global median. .net and .com have much larger networks, but remain a very interesting choice for absolute maximum performance.

Less expected is the performance of the .co, .biz and .in TLDs, well ahead of the others.

Some new domains (.online, .top, .blog…), which are attractive from a marketing point of view and growing strongly, show disappointing performances…

… on the other hand, very good surprises for .live, .email, .news, managed by Donuts Inc or .club and .buzz managed by Neustar Inc, with, however, a very important decrease in performance in regions outside Europe and North America, which further aggravates the problem.

42 of the most popular TLDs among the 1400+ available have been tested. Without drawing any definitive conclusions, we can assume that many may not work much better.

Conclusion

Do you need to revolutionize the management of your domain name portfolio and the choice of TLDs for your most visible websites? Should you switch everything to .biz or .co immediately to increase performance?

Certainly not. First of all, DNS responses are heavily cached, especially for very popular websites, resolvers may not need to reach many top-level names servers. Then, the choice of a domain name is primarily driven by marketing imperatives (brand, geographical area, name availability) that are often far more impactful than the additional 50 milliseconds of loading time for the first page to load.

However, if you are trying to compress absolutely every last bit of performance and ensure high reliability in a system where every last millisecond counts, then you may want to think twice before choosing your domain. The differences aren’t huge, but if you’re aiming for that one-second loading time, things can add up to 200 ms in some cases.

Choosing the right TLD based on DNS performance is indeed a good thing, but probably not a cause for too much concern.

Let’s Encrypt, do not confuse confidentiality and security

Let’s Encrypt was recently the subject of discussions in the small world of TLS certificates, by suddenly revoking 3 048 289 certificates which should not have been issued. A bug in its validation software prevented CAA registrations controls, and the certificates in question should not have been initially issued. These significant disruptions resulted from this mass revocation, but it is difficult to complain about a free service.

I am often asked what I think of Let’s Encrypt, and I always have this same answer: Let’s Encrypt has done a lot to encrypt the web, but is undermining the security of the web. Encryption allows to ensure confidentiality (no one can spy on) and integrity (no one can modify) of exchanges. But encryption alone is not enough if I do not have any guarantee of the identity of the one I am exchanging with (legitimate or fraudulent?)… And that is the whole problem.

Let's Encrypt - SSL TLS certificates - Nameshield

In 2015, the Let’s Encrypt initiative supported by leading players of the Internet (EFF, Mozilla, Cisco, Akamaï…) was created with the purpose of massively and freely spreading SSL certificates to the whole world. More than five years later, the organization secures 190 million websites and has just announced that it has issued a billion certificates. The milestone was reached on February 27, 2020. This is undoubtedly a great performance.

96% of the web encrypted in January 2020

In 2015, less than half of the web traffic was encrypted, to reach 96% in January 2020. Of course, Let’s Encrypt is not the only player responsible for this rise. Edward Snowden launched the first alert, Google has largely stepped into the breach, between referencing policy and changes in web security indicators. But by providing to all, free certificates based on a largely automated system, Let’s Encrypt has democratized encryption… and put the concept of identity into oblivion.

No identity, no security

Let's Encrypt - SSL TLS certificates - Nameshield

Let’s Encrypt’s credo is simplicity, to “simplify to the extreme HTTPS deployment and put an end to its horribly complex bureaucracy” (says EFF in the launch campaign). The horribly complex bureaucracy has however a meaning: high authentication, which guarantees the identity of the certificate’s holder. Maybe not the absolute guarantee of legitimacy, not a guarantee of content either, but the guarantee of a registered company, legitimately owner of the concerned domain name and with a certificate validated according to a drastic procedure.

Let’s encrypt merely verifies the domain name’s control (DV, Domain Validation). One only has to click on a link in an email or to fill in a TXT record on the domain name’s DNS zone. Yet domain names registration in most TLDs is purely declarative. It is quite easy to register a domain name, to request a certificate from Let’s Encrypt and to publish a website in HTTPS://.

The results?

In five years, all phishing and fraudulent websites have switched to HTTPS://. Since 2016, Vincent Lynch alerted on this problem, 15 270 certificates with the term “Paypal” had been issued by Let’s Encrypt, 14 766 of these certificates were fraudulent.

The market has been brought down in terms of authentication level. Let’s Encrypt is far from being the only one responsible, Google and Mozilla, with their 70% of market shares, have largely supported the initiative, the big Cloud hosting providers followed, as well as the Certification Authorities, challenged on the prices. Today we have a secure web with 77% (November 2019) of certificates whose proprietary’s legitimacy is not verified.

High authentication changes the game

The web has become encrypted by default. Does that make it more secure? Nothing is certain. The web user educated for twenty years to check the presence of the padlock in the address bar, trusts a web where all the fraudulent websites display the security padlock. Today, Internet is confidential but that does not make it safe.

It is urgent to return to high authentication. High authentication ensures a set of compulsory, drastic and controlled steps in order to obtain certificates. The procedures are enacted by CA/B Forum, regularly strengthened, and followed by audit from Certification Authorities.

23% of the certificates are still issued on the basis of high authentication, mostly in the corporate world, where CISO are pushing to preserve it. We all have to rely on them and support initiatives supporting OV (Organization Validation) and EV (Extended Validation) certificates, especially EV to guarantee the identity of the websites visited by web users. While identity on the Internet seems to have been somewhat forgotten for some time in favor of confidentiality, it is likely to come back to the spotlight again soon, driven in particular by web users and the need of personal data protection.

Apple announces the limitation of SSL certificates duration to 1 year in Safari

Apple Safari - SSL certifcates one year - Nameshield
Source de l’image : kropekk_pl via Pixabay

Apple announced this week that the maximum lifetime of SSL / TLS certificates on its devices and Safari browser would be limited to 398 days (1 year, and 1 month to cover the renewal period). The change, announced by Apple at the CA / Browser Forum meeting in Bratislava, Slovakia, will take effect for certificates issued after August 31, 2020.

Apple’s announcement follows a failure of the CA / B Forum’s vote on one-year certificates (Bulletin SC22), which was held in August 2019, and reflects a continuing trend to shorten lifespan certificates. Following this vote, Google had also expressed its intention to reduce certificate lifetime outside the framework of the CA / B forum if they do not position themselves quickly. This announcement is a bit of a surprise, we would rather have thought that Google or Mozilla would take the first step.

What are the consequences for companies and their SSL / TLS certificates?

Is shorter validity a good thing?

The shorter the validity period of a certificate, the more secure the certificate. By requiring replacement of certificates over a shorter period of time, security updates are made to certificates, they deploy faster. The shorter private key lifetime of a certificate is also a strong recommendation from online security players to limit the potential duration of fraud following a compromise.

From a security perspective, everyone agrees that reducing the life of certificates is a good thing. The problem lies on the operational side with the consequences of this reduction being: more frequent intervention on certificates, therefore greater complexity in keeping an up to date inventory and the need for optimal organization with partners for certificate issuance.

Should Apple’s announcement be taken into account?

Safari is one of the two main web browsers, with 17.7% in January 2020, behind Google Chrome (58.2%) and ahead of Microsoft Internet Explorer and Edge (7.1%). It is difficult to ignore the announcement as it will affect 1/5 of Internet users, what is more is that if Google does follow, it is better to anticipate and prepare. Nameshield’s has already adopted this stance.

Things to keep in mind

Certificates issued before September 1, 2020 are not affected by this change. They will remain valid for the entire two-year period. All certificates issued on or after September 1 must be renewed each year to be considered reliable by Safari.

We must therefore prepare to move towards having certificates with a maximum duration of one year compared to the current two years. Being able to rely on a partner and effective tools is more essential than ever.

Towards the end of the correlation between authentication and technical certificate management

What seems to be taking shape within the CA / B Forum is the idea of allowing an authentication duration identical to that which we know today (two years) while forcing the certificates to be replaced several times during this same period.

The main Certification Authorities, the bodies that issue certificates, anticipate these changes and are working on several automation systems to manage certificate life cycle. They would thus limit the need to go through a potentially cumbersome re-authentication procedure with each replacement. Companies could replace their certificates as many times as they want during this period. This would make it possible to anticipate possible further reductions in the maximum lifetime of certificates.

The trend is also towards the installation of automation tools for the maintenance of a precise inventory of certificates on the one hand and technical reinstallation on the other. Nameshield is closely monitoring these various developments and will allow you to continue working with confidence.

Our team is also at your disposal to anticipate these changes and answer any questions you may have.

2020 and the SSL, a small prediction exercise

Browsers and Certification Authorities, the battle continues.

Cybersecurity - SSL 2020 - Nameshield Blog
Image source : TheDigitalArtist via Pixabay

2019 was a busy year, with growing differences of opinion between browsers makers and Certification Authorities, an explosion in the number of phishing sites encrypted in HTTPS and significant progress on the depreciation of TLS v1.0.

Discussions on extended validation, more generally the visual display of certificates in browsers, and the reduction of the duration of certificates have taken a prominent place. None of these discussions are over, no consensus seems to be emerging, 2020 is looking like a busy year. Time to look ahead…

Will the fate of Extended Validation be determined?

2019 saw the main browsers stop displaying the famous green address bar with the padlock and the name of the company, in favor of a classic and unique display, no longer taking into account the authentication level of the certificates:

SSL 2020 - EV certificate - Nameshield

However, discussions are still ongoing at the CA/B forum level, as well as within the CA Security Council. Both of these certificates regulatory bodies will be looking in 2020 for an intuitive way to display identity information of websites.

Historically approved by everyone, including the financial industry and websites with transactions, EV (the acronym for Extended Validation) was Google’s target in 2019. Other browsers, under the influence of Google, between Mozilla financed by Google and Microsoft and Opera based on Chromium open source, have followed in this direction. Only Apple continues to display EV.

For browsers, the question is whether or not TLS is the best way to present the authentication information of websites. It seems that it is not. Google assumes that it is not up to Certification Authorities to decide the legitimate content of a website and wants the use of certificates for encryption purposes only.

Of course, the Certification Authorities see things differently. One can certainly see a purely mercantile reaction, EV certificates are much more expensive. One can also wonder about the purpose of authentication beyond encryption. The answer seems to lie in the staggering statistics of phishing websites encrypted with HTTPS. Browsers have for the moment imposed an encrypted web indeed… but no longer authenticated!

2020 will therefore be the year of proposals from Certification Authorities: providing better authentication, including identification of legal entities, following the path of PSD2 in Europe… One thing is certain, identity has never been so important on the Internet and it is up to all interested parties to find a solution, including browsers to find a way to display strong authentication of websites. To be continued…

Certificates with a shorter duration: towards one-year certificates

825 days, or 27 months, or 2 years, the maximum duration currently allowed for SSL Certificates. However, since 2017 and a first attempt within the CA/B forum, the industry is moving towards a reduction of this duration to 13 months (1 additional month to cover the renewal period).

Google and browsers came back in 2019 with another vote submitted to the CA/B forum, again rejected but by a smaller majority. The market is on the move. Players like Let’sEncrypt propose certificates with a duration of 3 months, others want to keep long durations to avoid overloads of intervention on servers. One thing is certain, the market does not have the automation systems in place yet to make the management and installation of certificates easier, a delay of one or two more years would otherwise be preferable, or at least judicious.

But all this is without counting on Google threatening to act unilaterally if the regulator does not follow… certainly in 2020.

From TLS 1.0 to TLS 1.3: forced advance

Expected in January 2020, Microsoft, Apple, Mozilla, Google and Cloudflare have announced their intention to depreciate support for TLS 1.0 (a protocol created in 1999 to succeed SSL 3.0, which has become highly exposed) and TLS 1.1 (2006), both of which are currently suffering from too much exposure to security flaws.

While TLS 1.2 (2008) is still considered secure today, the market seems to be pushing for TLS 1.3, the most recent version of the standard, finally released in the summer of 2018. TLS 1.3 abandons support for weak algorithms (MD4, RC4, DSA or SHA-224), allows negotiation in fewer steps (faster), and reduces vulnerability to fallback attacks. Simply put, it is the most secure protocol.

A small problem, however, is that many websites are taking action. At the beginning of 2019, only 17% of the Alexa Top 100,000 websites supported TLS 1.3, while just under 23% (22,285) did not even support TLS 1.2 yet. If the decision to depreciate older versions of the protocol is a good one, the form adopted by the major web players can be criticized, in particular by its unilateral nature. In the meantime, get ready, we are heading there.

The threat of quantum computing

Companies are talking more and more about quantum computing, including Google. But the reality is, while quantum will impact our industry, it certainly won’t be in 2020, or for at least a decade. There are still many questions that need to be answered, such as: What is the best algorithm for quantum resistance? No one has that answer, and until there is a consensus in the industry, you are not going to see any quantum solutions in place.

IoT is growing, but the lack of security remains a problem

IoT is a success, but a number of deployments are being delayed due to a lack of security. In 2020, cloud service providers will provide or partner with security companies to provide a secure provisioning and management of devices, as well as an overall secure IoT ecosystem, for their customers.

The regulatory frameworks for IoT manufacturing and deployments will most certainly be led by the EU, although we will also see an increase in the US. Attacks, compromises and IoT hacking will, unfortunately, continue. In addition, security standards will not be met and we will not even come close to a higher percentage of secure devices. Why is that? Original Equipment Manufacturers (OEMs) are still not willing to pay the costs involved or pass them on to consumers for fear of losing sales.

China’s encryption laws will create a lot of uncertainty

In recent years, part of the digital transformation of the world has led to the codification of rights and restrictions on data in national laws and regional organizations. PSD2, GDPR, CCPA, PIPEDA… a real headache for international companies faced with regulatory standards and compliance.

On January 1, 2020, China’s encryption law was due to come into force. An additional data and… still unclear to those doing business in China. Clarification is still needed on several fronts. For example, commercial encryption for international companies must be approved and certified before it can be used in China – but this certification system has not yet been created. Similarly, there is uncertainty about the key escrow and the data that must be made available to the Chinese government. This has led to a wave of speculation, misinformation and, ultimately, overreaction. Given the opacity of parts of the new Regulation, many companies are opting for a wait-and-see approach. This is a wise tactic, assuming your organization does not have an experienced Chinese legal expert.

In conclusion, the certificates industry continues to change. Nameshield’s certificates team is at your disposal to discuss all these topics.

Best wishes for 2020.