A Security Model for Web-Based Communication

Abstract

1 Introduction

A fundamental base for leveraging Web content is trustworthy communication with the remote content endpoint. Assessing the level of provided security is challenging, though, due to the complexity of the current Web, which involves multiple protocols and stakeholders when accessing a Web page as depicted in Figure 1. To demonstrate the communication workflow and respective security pitfalls, we consider the simple case of inquiring information about COVID-19 guidance as a resident of Jackson County in Missouri. Through a search engine, an online ad, a recommendation from friends, among others, the URL is quickly discovered: https://jacohd.org. When visiting the Website, the presence of a green padlock in the address bar indicates only the confidentiality and integrity of data exchange, but does not indicate whether the Website belongs to the supposed service (that is, Health Department of Jackson County in Missouri instead of one of the other 22 Jackson Counties). The generic domain name could have been registered and operated by anyone. An attacker could have published a forged Website implementing the look and feel of the real health department. 

At no stage does the user receive a chance to authenticate the identity (that is, identification) of the service provider because the supplied domain validation (DV) certificate does not include any identification information. In contrast, the health department of Jackson County in Michigan, reachable under www.co.jackson.mi.us, is under a restricted top-level domain (TLD), that is, registration required an eligible entity, which indicates that it belongs to Jackson County (co.jackson) in Michigan (mi.us). It is accompanied by an extended validation (EV) certificate, which serves as a definitive proof of identity.

In this paper, we introduce a generic security model for Web services based on three dimensions of resolution, transaction, and identification. Using this model, we provide a framework to understand whether and how specific integration of a service provider in the domain namespace and its use of DNSSEC and X.509 certificates impact secure communication (see Figure 1). Our model allows us to calculate an Assurance Score for a given service provider and qualify its level of security as an inadequate, a weak, or a strong Assurance Profile. We apply our model in practice by systematically investigating the Web representations of organizations active in emergency management or diplomatic relations. The starting points for our study are three datasets: (i) the list of Alerting Authorities (AA) in the U.S. (US-AA), (ii) list of fire departments, police, municipalities, and Red Cross chapters in 200 most populous cities in Germany (DE-EM), and (iii) list of Websites of Ministries of Foreign Affairs (MFA) used to create Diplomatic Pulse, a search engine for official press releases of UN Member States.²³ We analyze domain names and certificates of all these Websites.

This paper complements our previous study¹² by contributing a solution for general Web communication, instead of limiting the analysis to Alerting Authorities. Our key finding is that none of the investigated Web services provide strong security measures, but 95%-99% exhibit an inadequate Assurance Profile, depending on the type of service. This decomposes as follows: (i) only about 6% of observed hosts provide secure resolution and are susceptible to name spoofing and certificate misissuance, (ii) transaction security is dominated by domain validation certificates and about 1% of all investigated services are provided by servers delivering none or invalid certificates, none reaching the secure transaction level, and, finally, (iii) two thirds of investigated organizations cannot be uniquely identified due to shared names or certificates, or just by using domain validation certificates that provide no identity information.

2 A Security Model for Web-Based Communication

We define a security model for web-based communication based on three dimensions: (i) securely verifying that users have not been misdirected (“resolution” of name to network service), (ii) ensuring that the content was not altered, privacy was not leaked, etc. during the session (“transaction” security), and (iii) securely authenticating the authoritative service (“identification” of the person, organization etc. behind the service name). Although different methods can be utilized to implement such a secure workflow, here we focus on those technologies that are most accessible to (and deployable by) users and service operators in the current Internet, namely the DNS and the Web PKI.

Almost all transactions on the Web start with looking up a domain name, for example, www.example.com, and resolving it to an IP address, for example, 93.184.216.34. The domain name system (DNS), the hierarchical distributed database that enables such domain name resolution, is susceptible, though, to a number of vulnerabilities which can end with domain hijacking and impersonation. To counter, a set of security extensions dubbed as DNSSEC have been introduced that secure name resolutions.

After retrieving an IP address, a communication channel is established. The Transport Layer Security (TLS) protocol is the de facto standard to secure this channel. TLS was designed to provide integrity, that is, modified data in transit can be detected at both ends, and confidentiality, that is, no party other than the communicating endpoints can comprehend the exchanged data. To achieve any of these two security goals, authentication of the contacted endpoint is required. Without proper authentication, a malicious party can intercept or impersonate any endpoint while also providing integrity and confidentiality for this impersonated endpoint or proxy.

Authentication can succeed by pre-sharing keys in controlled environments or through X.509 certificates in open environments like the Web. A certificate binds a cryptographic (public) key to a subject which compromises a set of attributes such as organization, country, common name and can be further elaborated by Subject Alternative Names (SAN) like domain names and IP addresses. Its authenticity is vouched for by a trusted third party called a Certification Authority (CA). The most basic form of a subject is a domain name. A certificate holder can prove the ownership of that name based on a cryptographic signature. This is referred to as domain validation or DV for short. A subject can also map to a natural or legal person in the real world. In such cases, we speak of identification as an extension of authentication. Organization and Extended Validation (OV and EV) certificates fall under this category. In a secure setting, it would be possible to identify and authenticate the communication partner before initiating the transaction. Yet, the starting point for Web communications are domain names, which cannot be used for secure identification, while Web PKI certificates (as proofs of identity) are provided only after resolution succeeds and a transaction is initiated. We argue that domain names that are under restricted namespaces, for example, .gov for U.S. governmental organizations, are a necessary (yet not sufficient) precursor for identification.

Authentication only holds if the certificate itself is authentic, for example, not misissued. Within the Web PKI ecosystem, any trusted CA can issue a certificate for any arbitrary name. A rogue or a compromised CA can, thus, be tricked into issuing a valid certificate to an entity that does not match the certificate subject. To counter this threat, the DNS-based authentication of Named Entities (DANE) was introduced, which extends the DNSSEC trust to the Web PKI by signaling clients what (type of) certificate to expect from the server. This is an additional security measure to prevent adversaries from presenting bogus certificates to clients in case of server or CA compromises even if name resolution succeeds securely.

In our security model, we consider resolution to be secure if it is backed by DNSSEC. We consider a secure transaction to be reached if a valid, dedicated certificate matching DANE records is provided. If DANE is missing or the certificate is shared between distinct service providers, we classify it as a weak transaction (see Figure 2). Regarding identification, we consider the highest assurance level to be reached if a service endpoint is under a restricted namespace, provides an OV or EV certificate, and caters to secure resolution (see Figure 3).

Finally, to provide a comprehensive view on all three security dimensions, we introduce Assurance Scores and Assurance Profiles. An Assurance Score defines a measure that combines the contributions of each security dimension to web-based communication. Each Score is then mapped to a Security Profile, which groups multiple deployment options into strong, weak, or inadequate. In detail, we first codify each possible label of insecure, partial, and secure as 0, 1, and 2, respectively. Since resolution can either be secure or insecure it is codified with 0 or 2. Then, we calculate the Assurance Score as $resolution+transaction+2\times Identification$. We add extra weight to identification because this dimension is integral in secure communication—even if resolution and transaction are both secure, there is still a need to at least partially identify the communication partner. This weighting represents an example that illustrates our basic contribution. Our general contribution would allow users to employ different weightings as well.

3 DNS Namespace Analysis

In this section, we aim to answer the following questions by studying domain names:

1. Does each service provider have its own dedicated domain name?

2. How do service providers integrate in the global DNS namespace?

3. Do service providers secure their names using DNSSEC?

The first question is concerned with how an organization maintains its online presence without introducing unnecessary dependencies. Lack of a dedicated name, for example, leads to dependence on someone else for authentication and data security as X.509 certificates are bound to domain names. The second question aims to investigate the preference regarding TLDs to take advantage of recognizability (for example, governmental organization under .gov) and security (restricted vs. non-restricted TLDs). The last question considers measures taken into account to secure names against threats such as spoofing or DNS hijacking, which can also lead to impersonation and phishing. Table 1 summarizes our findings.

3.2 Namespace Structure

To analyse namespace structures, we group various TLDs and country code second-level domains (ccSLDs) as follows:

• gTLD: generic top-level domain (for example, .org).

• ccTLD: country code top-level domain (for example, .us).

• ccSLD: country code second-level domain (for example, gouv.fr).

• sTLD: sponsored top-level domain (for example, .mil).

• geoTLD: top-level domains for “geographical, geopolitical, ethnic, social or cultural representation” (for example, .eu).

Each TLD group features different properties. In general, there are little to no delegation limits and naming conventions for names under gTLDs or ccTLDs, except for the .us namespace. Under the .us ccTLD more than 3,000 names are reserved and unavailable for public registration. This DNS sub-tree has a rigorous structure on the second, third, and fourth level. The structuring reflects the “political geography” (see RFC1480) and defines a number of reserved names for designated organizations or purposes and territory of operation (for example, county or city). Sponsored TLDs (.edu, .gov, and .mil) impose stricter eligibility requirements and thus have an advantage over gTLD names as only eligible registrants are granted domain name ownership in these namespaces. The sTLDs, however, are mainly limited to the U.S. so that non-U.S. entities are forced to make use of local counterparts under their respective country code SLDs, for example, .ac.uk for academic institutes in the UK or gouv.fr for the French government.

The majority of US-AA entries are located under gTLD namespaces followed by sTLD, ccSLD, and ccTLD namespaces (see Table 1). It is noteworthy that the .us locality namespace (part of .us ccSLD) exhibits a relatively low penetration among AAs. When considering the canonical forms [ci,co].<locality>.<state-code>.us for cities or counties, we observe only 9 out of 66 actual cities that use this naming pattern. Similarly, for names that include the term county, there are only 218 of 696 cases using the canonical form.

In contrast to Alerting Authorities, DE-EM and MFA organizations face more limitations in choice of appropriate and restricted namespaces. For instance, none of the entries in DE-EM are under restricted namespaces ($\approx$ 90% under .de), and the majority of MFAs resolve to ccSLD namespaces of their countries (for example, .gov.af).

Finally, we examined whether the specific choice of top-level domains of an organization correlates with its field of operation. Figure 4 depicts how widely used various TLD types are in different fields of operation. The majority of Alerting Authorities opt for gTLDs with the exception of educational and military organizations that exclusively take advantage of restricted TLDs (.edu and .mil respectively). DE-EM and MFA organizations primarily choose ccTLD namespaces.

4 Web PKI Analysis

The ecosystem of Web PKI revolves around X.509 certificates. We investigate the deployment and characteristics of certificates to answer the following questions:

1. To what extent do entities embrace the Web PKI?

2. How and for what purposes (identification vs encryption) are certificates utilized?

3. How is the historic landscape of X.509 shaped among organizations in our dataset?

4.2 Certificate Usage

Although the technical basis of all X.509 certificates is the same, the semantics of a certificate are defined by the governing validation policies and how a certificate is in use. A Web PKI X.509 certificate must at least fulfill domain validation, that is, authenticate the ownership of a domain name. For OV and EV certificates, the identity of the certificate holder (to various degrees) can be authenticated as well. Identification assurances, however, can be diluted through certificate sharing. Except EV certificates, both DV and OV certificates allow wildcard names as subject alternative names (SAN) to avoid enumerating all FQDNs under the control of the certificate holder. In practice, the SAN extension also allows sharing a certificate among different hosts. For example, in 2019, the U.S. federal government issued OV certificates with more than 600 specific and wildcard SAN entries. Certificate sharing, on the one hand, defeats the purpose of identification and, on the other hand, expands the attack surface and increases operational costs so that if one of the hosts is compromised or the certificate is revoked, every other host necessarily also needs to be configured with a new certificate (sometimes called “fate-sharing”).

To detect certificate sharing, we count the number of unique domain names in the SAN section of a certificate while ignoring www.* subdomains. We consider any SAN count greater than 1 or the existence of wildcard names as an indication of a shared certificate. In the case of EV certificates and regardless of the number of SANs, the certificate is considered dedicated as the certification authority is mandated to ensure that all alternative names are representations of one and the same entity. This is not necessarily the case for OV certificates as we discuss below.

For those organizations behind an SSL/TLS enabled server, we observe that only a small fraction is represented by an EV certificate, $\approx 2\%$ for US-AA, 1% for DE-EM, and $\approx 3\%$ for MFA entries. As we discuss later in Section 5, this is likely due to a decision by major browser vendors to abandon visual cues for different validation types altogether.¹¹ OV certificates amount to one third for entries in DE-EM and MFA datasets each, and 22% for US-AA; 84%, 82%, and 90%, respectively, using shared certificates. The remaining majorities are represented by DV certificates with a portion of 40% (US-AA), 41% (DE-EM), and 57% (MFA).

We observe common deployment models that make use of shared certificates. Most prominently, Cloudflare uses its own CA to issue an OV certificate to itself, that is, ‘Cloudflare, Inc.’ as organization name and sni.cloudflaressl.com as common name, and includes a customer domain name as SAN. In this model, despite the organization validation, the certificate cannot be used to identify the service provider, for example, Wilco County in Texas under www.wilco.org provides a certificate that does not relate to its infrastructure provider Cloudflare. Another model, observed in the US-AA dataset, is when a certificate is shared among different customers of a multitenancy cloud provider (dubbed as “cruise-liner certificates” by Cangialosi et al.³). For instance, Granicus, a cloud provider for governmental organizations in the U.S., uses Let’s Encrypt DV certificates to create a single certificate for many customers at once. Here, not only is identification ambiguous but also confidentiality is jeopardized by shared server keys, leaving customers insufficiently isolated from each other. It is worth noting that Let’s Encrypt certificates only allow up to 100 DNS type SANs. The disadvantage of such an approach compared to the former model is that a single compromised or revoked certificate affects multiple unrelated customers, often called “fate sharing.” Beside cloud service providers, individual organizations also commonly make use of shared certificates to have a single certificate to subdomains that are all managed by a single technical entity.

Table 2 combines our findings from this Section and Section 3 to reveal different combinations of DNS and X.509 certificate characteristics, linked to different levels of assurance. In 3, we group our results by organization types. Due to low DNSSEC deployment, lack of TLSA records, popularity of open TLDs, and pervasiveness of DV certificates, the majority of hosts fall under the inadequate Assurance Profile.

Table 2. 

Proposed security model and measurement results, which exhibit specific security features per dataset.

	Security Model					Measurement Results
	Security Dimensions			Assurance		Unique Hosts [#]
#	Resolution	Transaction	Identification	Score	Profile	US-AA	DE-EM	MFA
1	$✗$	$✗$	$✗$	0		93	27	11
2	$✗$	$✗$	!	2		68	0	27
3	$✗$	!	$✗$	1		781	709	30
4	$✗$	!	!	3		713	18	85
5	$✓$	$✗$	$✗$	2		2	2	1
6	$✓$	$✗$	!	4		1	0	4
7	$✓$	!	$✗$	3		43	40	6
8	$✓$	$✓$	$✗$	4		0	0	0
					Total inadequate:	1701 (95%)	796 (99%)	164 (98%)
9	$✓$	!	!	5		87	2	5
10	$✓$	$✓$	!	6		0	0	0
					Total weak:	87 (5%)	2 (1%)	5 (2%)
11	$✓$	$✓$	$✓$	8		0	0	0

Measurable security dimensions (✗/0 : insecure, !/1 : partial, ✓/2 : secure) determine Assurance Scores (resolution + transaction + 2 × Identification) aggregated into Assurance Profiles (Image strong, Image weak, Image inadequate).

Table 3. 

Number of unique hosts per Assurance Profile grouped by field of operation.

Dataset	Field of operation	Assurance Profile
US-AA	Educational	6	0	0
	Governmental	646	28	0
	Law Enforcement	206	10	0
	Military	7	12	0
	Public Safety	819	33	0
	Other	18	4	0
MFA	Ministry of Foreign Affairs	164	5	0
DE-EM	Fire Department	200	0	0
	Municipality	200	0	0
	Police	197	2	0
	Red Cross	199	0	0

Image strong, Image weak, Image inadequate (see Table 2)

4.3 Historic X.509 Certificate Landscape

The historic analysis of X.509 certificates collected from Certificate Transparency logs helps us to gain a better understanding of security policy changes related to examined entities and CAs. We span eleven years. It should be noted that the total number of organizations providing publicly logged certificates changes for each year. We consider this in the following by normalizing the results either with respect to the number of unique hosts or the total number of certificates valid per year.

Certification Authorities.  In addition to common regulations, certification authorities implement and follow their own set of policies. From the perspective of relying parties, that is, Web users, such policies are opaque and as long as a CA is included in a user’s trust store, it is considered trustworthy. For the subscribers, however, these policies among other factors such as fees, offered certificate types, and operation costs are decisive in choosing an appropriate CA.

We focus our analysis on certification authorities with a market share of at least 20% in any year during the past decade. The calculation of market share is based on the number of covered subscribers. We use the term cover to differentiate from issuance: if a subscriber, for example, received a certificate from a CA valid from 2014 to 2016, we consider it to be covered by that CA for 2014, 2015, and 2016. Further, if a CA issues multiple short-lived certificates (for example, 90 days) for a subscriber within a given year, we only count that host as covered once in that year by the issuing CA.

Figure 5 depicts our findings in terms of relative market share development in the past decade. Compared with the CA market share for the Alexa 1M top domain list throughout the past decade^1,9,14 we observe parallels, such as decline of the GoDaddy market share and rapid gains of Let’s Encrypt, as well as discrepancies that cannot directly be explained due to dynamic nature of and fluctuations in the Alexa top list. This figure also highlights two factors that were evidently decisive for the organizations in our datasets in their choice of CA: convenience and cost. GoDaddy (among US-AA) and T-Systems (among DE-EM), for example, which have been the market leaders at some points in time, provide Web hosting and domain name registration in addition to certification services in convenient packages. In contrast, Let’s Encrypt, which has surged to the top in the short period after its public offering, offers automated DV certification at no cost.

Validation types.  In Section 2 we discussed the role of OV/EV certificates for secure identification. Although the current deployment of investigated entities (see subsection 4.1) reveals a low penetration of such certificates, historically a higher share of entities made use of OV/EV certificates as depicted Figure 6. The surging popularity of free and automated DV certificates (see Figure 5) has evidently led to a decrease in usage of OV/EV certificates.

Certificate Sharing.  Multitenant Web hosting and security service providers make use of shared certificates as discussed above. Figure 7 depicts the development of certificate sharing based on our analysis of historic data. Here, we also notice an increasing number of certificates shared across hosts which do not belong to the same logical entity. Most critically, also among OV certificates, we see service providers obtainngs certificates under their names and listing the hosts of their customers as SANs. This practically defeats the identification purpose of the certificates. At the time of writing, we observe cases of such certificates listing SANs that clearly belong to separate entities, for example, mo.gov, asap.farm, and incapsula.com within the same certificate. In this very specific case, records from the Wayback Machine archives show that asap.farm has previously belonged to Missouri Department of Agriculture but it was never removed from the certificate even though the domain name registration was transferred to another entity.

5 How to Proceed Further?

Our results draw a rather alarming picture of how security measures of Web-based communication are implemented and integrated. We now discuss some possible reasons for the observed deficiencies and suggest alternatives.

6 Conclusion and Outlook

In this article, we conceptualized a security model to algorithmically quantify and qualify trustworthiness in Web communication. This security model covers three security dimensions (resolution, transaction, identification), which are combined into Assurance Scores grouped into Assurance Profiles. Assurance Profiles provide a lean, yet powerful view on the security support of a specific Web service. They may serve as an advancement in future Web browsers to hide the complexities in secure Web communication by comprehensively notifying end users whether the level of security is strong, weak, or inadequate.

To showcase the applicability of our model in practice, we analyzed three classes of Websites that are relevant to the public, Alerting Authorities in the U.S., selected emergency management organizations in Germany, and input for the Diplomatic Pulse, a search engine for official press releases of UN Member States. We measured the deployment of common technologies providing potential security features (namespaces, DNSSEC, and Web PKI) for these Websites and embedded them in our model.

We uncovered deficiencies and discussed alternatives while emphasizing that common solutions are not necessarily technical but operational as well as political. Protecting Web-based communication, specifically in context of critical infrastructure and public safety, entails addressing operational and policy challenges on national and international levels and calls for commitment of all stakeholders from service providers to intermediate infrastructure operators and browser vendors alongside policy-makers.

In the future, when orthogonal security paradigms arise, such as content object security, or when emerging but fragmented edge networks, such as the Internet of Things, gain importance, the security model proposed in this article shall be extended, adapted, and applied. We urgently remind our community that complexity will always arise and demands for an automated and comprehensive security assessment integrated in end user software.

Acknowledgments

We would like to thank the Innovation Cell in the United Nations Department of Political and Peacebuilding Affairs (UN DPPA) for providing us the list of sources used in the Diplomatic Pulse database. We thank Jakob Bork for helping with the verification of German Emergency Service providers.

This work was supported in parts by the German Federal Ministry of Education and Research (BMBF) within the projects Deutsches Internet-Institut (grant no. 16DII111) and PRIMEnet.