​​The Internet, once a fundamental tool for society’s progress, today represents an environment loaded with hoaxes, fake news, phishing, hate speech and similar. Most of this malicious behavior stems from inherent anonymity built in the very core of the Internet. Although the Internet is well equipped with technical mechanisms that ensure machine-to-machine (M2M) trust, it is lacking any mechanisms whatsoever to enable person-to-person (P2P) trust. On the other side, even if we, as a society, could implement mechanisms that would enable P2P trust on the Internet, we have to keep in mind that anonymity is an essential element of democracy.

​​

Online trust

The essence of what Internet browsers presented about ensuring M2M trust online – is about making sure that when a person visits a website, they are truly visiting the intended website. On the other hand, the essence of EC’s eIDAS 2.0 proposition regarding QWACs is about enabling mechanisms for P2P trust online – allowing a person to check that the web site truly belongs to a specific company. The difference between the two becomes obvious in cases of fake sites. Today, a person can very easily buy a domain and register it anonymously while paying for it with crypto, and provide a proper M2M trust mechanism (SSL) for the site. So this will be a proper HTTPS site (M2M trusted), however, in real life, the presented “company” will have no connection with a true company as a legal entity whatsoever. It is very likely that the site visitor will be fooled into believing they are transactioning with a legitimate legal entity.

eIDAS 2.0 and browser security

Internet browsers’ position on why the proposed eIDAS 2.0 art. 45.2. will negatively affect browser security is based on 2 main arguments: 

1. browser providers have no direct management of EU’s QWAC trust list with no ability to directly remove non-compliant TSPs,
2. technical inappropriateness of QWACs. 

Internet browsers make a valid case for both arguments, which are both within the scope of M2M trust. 

On the other side, EC (eIDAS 2.0) is describing the necessity for P2P trust on the Internet. 

Internet browsers have properly argued that implementing P2P trust by forcefully “pushing” QWACs on browser’s M2M security level would negatively influence overall browser security. However, this does not mean that the level of P2P trust that QWACs enable is impossible to achieve. 

The proper way to go is to build P2P trust on top of M2M trust. The proposed solution, created by an informal group of EU and browser representatives, is a compromise that will enable best features of both worlds (M2M “technical” trust and P2P “person” trust):  

• it will enable EU citizens to check the identity of a person (legal or natural) that operates the specific domain (P2P trust),
• it will not negatively affect the browser’s established level of technical and procedural security controls over TSPs (M2M trust).

Browser manufacturer’s opposition to Article 45 of eIDAS 2.0

The opposition of web browser manufacturers to mandatory recognition of QWAC certificates issued by qualified trust service providers, and their opposition to mandatory addition of qualified trust service providers (TSPs) to the “Root Store” of a browser is based on 2 main objections:

1. Adding TSPs to the Root Store of a web browser based on law without independent control of the security aspects of TSPs by browser manufacturers using clearly defined, publicly available criteria, based on best security practices. 
2. Inadequacies in the use of QWAC certificates for website authentication as a result of the way web browsers work, and the fact that QWAC certificates are based on EV certificates, which have been shown not to increase the security of websites. In some cases, it has been shown that EV certificates make it easier to imitate valid domains. It is for these reasons that all browsers have discontinued support for EV certificates by removing special indicators used for EV-protected domains (green padlock and company name in the browser’s address bar).

No control over managing TSPs in Root Store

Browsers automatically trust all certificates issued by CAs that are included in the Root Store of a browser or operating system. Compromising a CA added to the Root Store would allow that CA to issue certificates for domains such as google.com, paypal.com, identyum.com, etc. to third parties, which from a browser perspective would behave the same as original domains.

That is, it would be possible to perform a MITM attack on a user’s browser with a well-known network traffic redirection method such as ARP cache poisoning and DNS cache poisoning, direct the user’s traffic to a server containing a fake certificate, and then have access to all the traffic of that user, which would enable the theft of personal data, censorship of a certain part of traffic, replacement of valid software the user is downloading with malware, etc.

One of the most significant examples of such a case of compromised CA included in the Root Store of a browser is the 2011 DigiNotar case, where a fake certificate was issued for google.com, which was then used to intercept user traffic from 298,140 different IP addresses in Iran. For these reasons, it is important that certificates present in the Root Store of browsers and operating systems be completely trusted. That the criteria for adding them to the Root Store are clearly defined, publicly available, and that they are constantly changing as Internet security standards change. Manufacturers of browsers and operating systems must be able to conduct periodic security audits of these CAs, and remove CAs from the Root Store as soon as possible in the event of CA security breach reports. It is also important to note that, according to Article 20 of eIDAS, audits of TSPs on the EU QWAC list are conducted every 24 months, while browsers review CAs included in the Root Store every 12 months. 

In the case of adding TSP to the Root Store of a browser by law, browser manufacturers would find it harder to refuse requests from states known for censorship and privacy violations to include their CAs, which would have a global impact given that the impact of a compromised CA is not limited to the country in which that CA is located.

Technical inappropriateness of QWACs

Qualified Web Authentication Certificates (QWACs) are a type of network authentication certificates that allow us to validate the authenticity of a web site by connecting it to a natural or legal person in the possession of a QWAC certificate. QWAC certificates are based on EV (extended validation) certificate technology, and the assumption that there will be a widespread adoption of EV certificates for website authentication. 

Because EV certificates are based on technology that has been shown to reduce online trust and security, there has been no widespread adoption of EV certificates, and any display of the difference between EV and DV (domain validated) certificates in browsers has been removed.

Some of the problems with EV/QWAC certificates:

• Given that the details of how EV marks would be displayed for a website was left to the choice of browser manufacturers, different browsers marked EV-protected domains differently. These marks were often not displayed at all on mobile browsers. The research showed that average users did not notice the difference between websites with DV and EV certificates, nor were they aware of the benefits of websites with EV certificates.
• It has been demonstrated that there is no support for verifying name conflicts in the EV certification process. That is, it has been shown that it is possible to buy an EV certificate for a legal entity that already exists if the certificate is purchased from another CA, which actually made it easier to impersonate domains with EV certificates since some browsers for EV domains removed the URL in the address bar and showed only the name of the legal entity. An example for this case was given by security researcher Ian Carroll, who was able to buy an EV certificate for Stripe, Inc (online transaction processor), even though he was registering a domain stripe.ian.sh:

Given that the result Safari browser displayed in the past did not show the URL, the user would not see the difference between these two pages.

• Although a website may be protected by an EV certificate, browsers do not establish only one connection to only that server when accessing a web page. In the background and before any data is displayed to the user, requests are executed through various protocols (HTTP/1.1, HTTP/2, HTTP/3, WebSocket) to different domains. If we look at an example of https://www.paypal.com/hr/home, we can see that in addition to downloading content from paypal.com, connections are established to paypalobjects.com and googleanalytics.com, which do not necessarily have EV certificates, and thus the EV domain itself is not any more secure than domains protected by DV certificates (JavaScript downloaded from these other domains will be executed in the same environment).

If the web page contains <iframe> elements, it is possible to include entire other web pages within the parent page without displaying their address bar, which would show the certificate type designation. These <iframe> elements are common on websites that have a payment form.

• Even connections to the same URL, or the same resource, are not necessarily identical, and will not always lead to certificate verification. In case the browser already contains this resource saved in its cache, the connection will not be established, instead the resource will be retrieved from disk. In case there is already a TCP connection to that server in the browser pool (for which the TLS handshake passed), this open connection will be used instead of opening a new connection and going through the TLS handshake process again. In the event that a connection is established and the certificate is verified, the current behavior of browsers does not differentiate between domains with EV/QWAC and DV certificates. Browsers set security limits based on Origin, a combination of URI scheme, hostname, and port. If it is possible to obtain a DV certificate for paypal.com and redirect traffic using one of the standard MITM methods, the browser will not show the user any warning or error message just because the web server is DV protected instead of EV protected.  One of the proposed solutions was to include EV in the URI scheme. In other words, to distinguish between https:// and evhttp:// websites, and in this way websites protected by EV certificates could block calls to DV websites. However, this solution was not introduced because it is not backwards compatible with servers and web applications that currently rely on EV certificates.
• Because identity verification is required for issuing QWAC certificates, they are not suitable for automatic issuance, which is necessary for organizations with a large number of domains and certificates. Not all organizations have the resources to take care of TLS of their servers, instead they often rely on automatic certificate renewal through the platform on which they host their sites. In addition, in the event of security incidents, it is necessary to be able to quickly revoke compromised certificates and replace them with new ones, which due to identity verification requirements is not possible with QWAC certificates.
• TLS server certificates are not necessarily the correct place to store identity information. The domain name and organization’s legal identity are two different things, therefore there should be two different types of certificates – which should be separate and independently changeable. Domain registration renewal dates will rarely coincide with company renewal deadlines. Also, many things can affect an organization’s identity, including name changes, mergers / acquisitions, bankruptcy, etc. If information about the organization is included in a TLS QWAC certificate, it will need to be revoked and replaced whenever any of these events occur.

The solution

The solution proposed by browser manufacturers, which would allow the verification of TLS connections to work with the same level of security as before, is the use of nt-QWAC certificates, with the added confirmation that the domain the user is currently visiting really belongs to a natural or legal person in possession of a qualified certificate. 

nt-QWAC (non-TLS QWAC) certificates would not replace the currently used TLS certificates, but would be used to supplement them. Certificates validated on the basis of CA present in the Root Store of a browser or operating system would still be used when establishing TLS connections. However, websites that want to indicate to users that the identity of the natural or legal person representing that website/domain has been verified would allow browsers to download an additional qualified certificate from a well known location, such as /.wellknown/ eidas/ntqwac.crt. This certificate would be cryptographically linked to a TLS certificate representing that domain. This would allow browsers to display an additional mark on these websites, such as the EU trust mark for qualified trust service.

We believe that the Internet should enable people to verify the identity (either legal or natural) of the web site owner. However, since anonymity must remain the key element of democracy, we also believe that people should have the ability to remain anonymous online. In other words, legal and natural persons should have mechanisms to credibly present their identity as site owners online, but it should be optional for them. At the end of the day, the decision to either trust an anonymous site or not should always remain with the person surfing the web.

Since for the last couple of decades, Internet has growingly become a place of distrust, if we introduce optional P2P trust verification mechanisms to the Internet, the true challenge will be of educational nature – we will have to educate people that they can verify other (legal or natural) person’s identity on the web and how they can do it and why it is credible.

More information can be found in the sources below.

Mozilla – Executive Summary – https://www.ccadb.org/documents/Qualified_Website_Authentication_Certificates_Interoperability.pdf

Alexander Sotirov, Mike Zusman – Breaking the Security Myths of Extended Validation SSL Certificates, BlackHat USA 2009

Troy Hunt – Extended Validation Certificates are Dead. https://www.troyhunt.com/extended-validation-certificates-are-dead/

Troy Hunt – Extended Validation Certificates are (Really, Really) Dead. https://www.troyhunt.com/extended-validation-certificates-are-really-reallydead/

Josephine Wolff – How a 2011 Hack You’ve Never Heard of Changed the Internet’s Infrastructure. https://slate.com/technology/2016/12/how-the-2011-hack-of-diginotar-changed-the-internets-infrastructure.html