Tag: TLS

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.

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.

Soon a maximum duration of one year for SSL certificates?

Soon a maximum duration of one year for SSL/TLS certificates?

What is happening?

The industry actors plan to reduce the lifetime of SSL/TLS certificates, allowing the HTTPS display in browsers, to 13 months, i.e. almost half of the present lifetime of 27 months, in order to improve security.

Google through the CA/Browser Forum has indeed proposed this modification, approved by Apple and a Certification Authority, making it eligible to vote. During the next CA/B Forum meetings, if the vote is accepted, the modification of the requirements will come into effect in March 2020. Any certificate issued after the entry into force date will have to respect the requirements of the shortened validity period.

The aim for this reduction is to complicate things for cyber attackers by reducing the duration of the use of the potentially stolen certificates. It could also force companies to use the most recent and the most secured available encrypting algorithms.

If the vote fails, it’s not to be excluded that browsers supporting this requirement, unilaterally implement it in their root program, thus forcing the change to the Certification Authorities. It’s likely that this could be the case, this change follows Google’s precedent initiative that aimed to reduce the lifespan from three years to two years in 2018, period during which Google already wished to reduce it to 13 months or even less.

Who is impacted?

The changes proposed by Google would have an impact on all the users of TLS certificates of public trust, regardless of the Certification Authority that issued the certificate. If the vote passes, all certificates issued or reissued after March 2020 will have a maximum validity of 13 months. The companies using certificates with a validity period superior to 13 months will be encouraged to reconsider their systems and evaluate the impact of the proposed modifications on their implementation and their use.

The TLS certificates issued before March 2020 with a validity period superior to 13 months will stay operational. The public non-TLS certificate, for the code signing, the TLS private code and clients’ certificates, etc. are not concerned.  It will not be necessary to revoke an existing certificate following the implementation of the new standard. The reduction will have to be applied during the renewal.

What do the market players think about this?

It would be a global change for the industry with impacts on all the Certification Authorities. They view this proposition in a negative light. We can see an economic interest above all, but not solely…

The main argument is that the market is not ready in terms of automation system of orders and certificates implementations. Indeed, there would be more human interventions with the risks associated with poor handling, or simply a higher risk of forgetting a certificate renewal.

For Certification Authorities, reducing the certificates’ lifespan to such a short term mainly presents an increase of the human costs related to the certificate portfolio management. If they are not fundamentally against this decision, they would particularly like more time to study what users and companies think.

The position of browsers makers

Be it Google or Mozilla, the spearheads of the native HTTPS massive adoption for all websites and the supporters of the Let’sEncrypt initiative, what is important is the encrypting of all web traffic. A reduction of the certificates lifespan reduces the risk of certificates theft on a long period and encourages the massive adoption of automated management systems. For these two actors, an ideal world would have certificate of maximum 3 months. If they are attentive to the market as to not impose their views too quickly, it is more than likely that in the long term the certificates’ lifespan will continue to decrease.

Nameshield’s opinion 

The market continues its evolution towards shorter and shorter certificates’ validity, as a continual decrease of the authentication levels and consequently a need for management automated solutions that will increase. We will align on these requirements and advise our customers to prepare themselves for this reduction which will, without a doubt, arrive. Our Certification Authorities partners will also follow this evolution and will allow to provide all systems of required permanent inventory and automation.

To be heard

The CA/Browser Forum accepts comments of external participants and all discussions are public. You can directly enter your comments to the Forum distribution list:  https://cabforum.org/working-groups/ (at the bottom of the page). Nameshield is in contact with CA/Browser Forum participants and will inform you of the future decisions.