Author: Christophe Gérard

CPO - Nameshield Group

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.