An Empirical Survey on the Early Adoption of DNS Certification Authority Authorization

04/20/2018 ∙ by Jukka Ruohonen, et al. ∙ 0

A new certification authority authorization (CAA) resource record for the domain name system (DNS) was standardized in 2013. Motivated by the later 2017 decision to enforce mandatory CAA checking for most certificate authorities, this paper surveys the early adoption of CAA by using an empirical sample collected from the Alexa's top-million domains. According to the results, (i) the adoption of CAA is still at a modest level; only a little below two percent of the popular domains sampled have adopted CAA. Among the domains that have adopted CAA, (ii) authorizations dealing with wildcard certificates are rare compared to conventional certificates. Interestingly, (iii) the results only partially reflect the market structure of the global certificate business. With these timely results, the paper contributes to the ongoing large-scale empirical research on the use of encryption technologies.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

The CAA resource record (RR) passed formal standardization in 2013.111 This manuscript was submitted for double-blind peer review to Journal of Cyber Security Technology (ISSN: 2374-2917) in November 6, 2017. After this submission, two relevant papers have been published: [5] and [32]. A reader should consult these papers in addition to this manuscript. It was only four years later, in March 2017, when blackmany certificate authorities (CAs) were mandated to implement CAA checking [14]. This decision was celebrated due to increasing concerns about the issuance of fraudulent or rogue certificates in the global public key infrastructure (PKI). Although CAA is only a small step toward better PKI security, these concerns are a good way to briefly motivate the paper’s empirical survey on the adoption and use of the new CAA resource record among popular Internet domains.

The transport layer security (TLS) and its predecessor, the secure sockets layer (SSL), constitute the almost universally adopted cryptographic protocols for establishing communications security in the Internet and the world wide web in particular. These protocols have largely also survived the test of time. While many revisions and alterations have been required to patch the protocols, no cryptographic vulnerability is known to exist that would allow to fully compromise the underlying end-to-end security model. This said, a number of high-profile TLS/SSL vulnerabilities (including the so-called blackHeartbleed, FREAK, and DROWN) have been discovered and disclosed in recent years [25, 34]. In addition to these vulnerabilities, a long-standing weakness originates from the global PKI and its CA-based trust model [12, 16]. This type of a weakness is also what motivated the standardization and the later enforcement of CAA checking among most certificate authorities.

The TLS protocol uses public-key cryptography for the initial exchange of keys. If the exchange is successful, symmetric encryption is used afterwards. The PKI-induced weakness exposes itself through server authentication. When a client connects to a web server using TLS, the client’s web browser verifies the server’s certificate (key) by evaluating it against a set of trusted certificates signed by trusted but still third-party authorities. This evaluation places the trust provision entirely into the hands of certificate authorities. In principle, a CA can sign a certificate for any domain, and this certificate will be trusted by most web browsers and operating systems. There are hundreds of CAs located in almost every corner of the world, and all of these CAs are equally trusted [8]. What is more, the trust relationship is transitive: web browsers and operating systems will trust certificates issued also by intermediate authorities [2]. These fundamental pillars of the global PKI allow to understand why it can be desirable to only trust some CAs and mistrust others. To put theoretical issues aside, there have been two tangential real-world weaknesses in this trust model.

On one hand, the history knows many cases of erroneous signing of certificates by CAs [23]. For instance, in 2001 two certificates were issued by VeriSign in Microsoft’s name to an individual not affiliated with Microsoft [12]. While VeriSign sold its certificate business to Symantec later in 2010, controversies continued. For instance, recently in March 2017, Google blamed Symantec for incorrectly issuing tens of thousands of certificates [6]. A few months later, in August 2017, Symantec in turn sold its certificate business to DigiCert, but regardless of the ownership, the controversies are likely to continue about the rigor (or lack thereof) that CAs use for certificate issuance.

On the other hand, the trust provision has exposed a more pressing concern about the security of the CAs themselves. Any CA is a lucrative target for attacks. In addition to limiting the availability of a CA through denial-of-service attacks [22], compromising a CA opens numerous possibilities for tampering with confidentiality and integrity, including issuance of rogue certificates, stealing or substituting keys used for signing, and manipulating requests for issuing valid certificates for fraudulent purposes [13, 17]. These scenarios are not only theoretical. The likely most well-known attack occurred in 2011 against the Dutch certificate authority DigiNotar, which later went also bankrupt due to the attack. By compromising the CA, an attacker was able to issue a wildcard certificate for Google’s main domain, which was subsequently used to conduct man-in-the-middle attacks against users in Iran [20]. The same pattern had already occurred a few months earlier when another certificate authority, Comodo, was compromised. Both cases led to speculations about the potential involvement of state-level actors. Such speculations have also intensified in recent years due to numerous legislative changes made to increase the power of national intelligence agencies [8]. For instance, concerns were raised in October 2017 about the implications of a Dutch law for trusting the national, state-level CA of the Netherlands [7]. On the bright side, the attacks and the controversies led to many initiatives for improving the security of the global PKI.

The current initiatives for improving TLS/PKI security are too voluminous [38] to adequately summarize in the present context. Nevertheless—insofar as the certificate issuance problems are considered, the standardization of the so-called certificate transparency [19] is noteworthy because it enables auditing of CAs through publicly available logs. Although there is still room for improvements, the transparency logs have also proven useful for better understanding the Internet-wide TLS/PKI ecosystem [36]. Given the increasing concerns about the ever increasing mass surveillance [11, 33], also the so-called Let’s Encrypt (LE) initiative is worth remarking. By offering a free certificate and easy configuration options, the initiative is noteworthy as it attempts to democratize certificate issuance by challenging both the state-led mass surveillance endeavors and the global certificate business [1]. The initiative also supports and respects blackcertification authorization [21], which is one of the standardized initiatives for improving TLS/PKI security. Before proceeding to discuss CAA in detail, it should be emphasized that the rationale behind CAA is to address the first weakness type, the erroneous issuance of certificates. This rationale is implemented through DNS by allowing any domain name owner to restrict the issuance of certificates by CAs.

2 blackCertification Authority Authorization

The CAA resource record type was created to allow a domain name owner to specify those certificate authorities who are allowed to issue certificates for the domain name. Before issuing certificates for domains, CAs evaluate the presence of CAA records via live DNS resolving. If the records are either missing or the records specifically authorize a given CA, the certificate authority is permitted to proceed with the certificate issuance. In essence, therefore, CAA provides an additional assertion to prevent erroneous or accidental issuance of certificates. This DNS-based authorization mechanism neither addresses nor prevents threats originating from the insecurity of certificate authorities. That isblack: by compromising a CA, it is presumably trivial to also bypass CAA checking when issuing rogue certificates or conducting some related attacks.

The RFC 6844 specification [15] for CAA is fairly simple. The RR structure contains flags, tags, and values. Currently, only the so-called critical flag is defined. Specifying this flag instructs a CA to not issue a certificate in case the CA does not implement or understand the semantics of a given tag-value pair. There are three valid tags: (1) the issue tag is used to define a certificate authority who is authorized to issue certificates for the domain in question; (2) the issuewild tag is similar but authorizes the issuance of wildcard certificates; and (3) the iodef tag enables the use of a standardized message exchange format [9] to report CAA-related problems to the owner of the domain. For the issue and issuewild tags, the value specifies the CA who is authorized. An empty value is interpreted to disallow the issuance. For instance, the following imaginary record disallows the issuance of wildcard certificates, while permitting DigiCert to issue normal certificates and instructing CAs to use electronic mail for reporting problems:    CAA 0 issuewild ";"    CAA 0 issue ""    CAA 0 iodef ""

Despite of this simple format, many DNS servers and tools do not yet support the CAA resource record. In addition to this lack of supporting software, the current adoption challenges relate to domain name aliases, the lack of clearly defined accounting criteria on how CAs are evaluating CAA records in practice, and configuration problems for multinational companies who may control hundreds of domains and their subdomains [27]. While many of these problems likely continue to hinder adoption, the question about domain name aliases is directly relevant also for this paper. In other words, a few details about the empirical sample should be elaborated before proceeding to evaluate the adoption of the blackcertification authority authorization.

3 Data

The empirical sample is based on the Alexa’s top-million busiest domains [4]. Although some skepticism is warranted about the representativeness of the list particularly in the DNS context [37], the list is commonly used as a benchmark in large-scale empirical studies exploring TLS/PKI [35, 36], among other Internet measurement topics [10, 30]. Because the paper’s focus is restricted to DNS, a simple client-side DNS resolver [29] blackwas used to query for CAA resource records of each domain in the Alexa’s popularity list using Google’s name server at This querying requires a brief elaboration.

Each domain in the list was resolved three times in order to rule out timeouts and other temporary resolution failures. The same applies to further resolving required to process the CAA records from the viewpoint of certificate authorities [15]. For dealing with aliases (CNAMEs), a generally recommended upper limit [18] is used by fixing the maximum number of recursive queries to eight. This recursion depth is also noted in the errata for the CAA standard [26]. As an example: if the CAA records of a domain a.b.c are aliased to d.e.f, which in turn has a CNAME pointing to g.h.i, after two recursive queries (for resolving d.e.f and g.h.i), the CAA records of g.h.i are used for a.b.c, provided that these are present. If this recursive search does not find CAA records, the records are queried by moving upward in the DNS hierarchy until the top-level domain (TLD) name is reached [15]. For instance: if no CAA records are found by traversing the CNAME chain of a.b.c, the CAA records of b.c, if present, are used for the domain a.b.c. If also this hierarchical query fails, the domain a.b.c is finally concluded to operate without CAA records, given that the subsequent hierarchical level denotes a top-level domain to which the hierarchical querying does not traverse.

A brief semantic validation is carried out for each CAA record. Namely: (1) each resource is verified to include a flag, a tag, and a value; (2) flags are asserted to equal , blackone, or zero; (3) tags are validated to be either issue, issuewild, or iodef; and (4) values specified with iodef are checked to start either with the character string mailto or with the string http. These basic checks caught a few small errors in the specifications of the CAA records among the domains sampled. For instance, a few domains omit the mailto, http, or https prefixes when specifying values for the iodef tag. Also other innocent mistakes are present: the domains,,, and have tried to specify wildcard authorizations but spelled the corresponding tag as issuewold. Likewise, the domain has spelled the iodef tag as ideof, and the domain

has specified two flags. While these few cases are statistical outliers, the cases are excluded to ensure consistent parsing. It is worth to also remark that it would be possible to carry out further validation by resolving also the authorized domains, including the mail exchange (MX) records for the email addresses delivered via the

iodef tag. As the focus of the paper is on the adoption of CAA, such validation experiments can be left for further work, however.

4 Results

The dataset obtained via live DNS resolving contains domains with CAA resource records. Thus, in absolute terms, the adoption is still at a rather modest level: only about 1.6% of the domains in the Alexa’s top-million list have specified blackcertification authority authorizations in their DNS records. Even though existing scholarly research is limited, there are good reasons to suspect that the pace of adoption has increased after the CAA checking was voted as mandatory for certificate authorities participating in the CA/Browser Forum. For instance, only 307 domains out of Alexa’s top-million list were reported to have deployed CAA records in early April 2017 [3]

. If this amount is used as a coarse heuristic, the adoption has increased by over 5000% in about six months. To a small extent, the adoption has been slower among more popular domains compared to less popular domains. This observation is illustrated in Fig. 

1, which shows the presence of CAA records across Alexa’s popularity rank. Although com is the most frequent TLD among the sampled domains with CAA records, also many country-code TLDs appear in the ranking shown in Fig. 2.

Figure 1: Presence of CAA Records and Alexa’s Popularity Ranks
Figure 2: Domains with CAA Records According to TLDs
Figure 3: Domains Authorized

On average, most of the domains with CAA records authorize only one CA. Most of these authorizations authorize CAs to issue only normal certificates. Authorizations involving wildcard certificates are less common (see Fig. 3). The so-called DNS graphs offer a good method to elaborate these observations further.

By using a common undirected and bipartite DNS graph representation [31], there are two types of vertices: the domains sampled from the Alexa’s list and the domains the sampled domains have authorized via the issue or the issuewild tags. Whenever a given “Alexa-domain” has authorized a “CA-domain”, an edge is placed between these two types of domain vertices. A resulting graph representation is illustrated in Fig. 6 by connecting the domains sampled (as represented by the green vertices with their sizes proportional to Alexa’s popularity ranks) to the CA-domains (as represented by blue vertices) that the sampled Alexa-domains have authorized to issue wildcard certificates. By constructing an analogous bipartite graph according to the issue tag, the most frequently authorized domains can be summarized by calculating the number of adjacent vertices to the Alexa-domains. The results from this calculation are shown in Fig. 6. There are many relevant observations to make from these two figures.

Figure 5: Most Frequently Authorized Domains
Figure 4: Bipartite DNS-CAA Graph According to Wildcard Authorization
Figure 5: Most Frequently Authorized Domains
Figure 6: Flags Set for the Authorizations
Figure 4: Bipartite DNS-CAA Graph According to Wildcard Authorization
Figure 7: Six DNS-CAA Subgraphs (two hops from the labels shown, issue)
Figure 8: A Summary of Reporting Targets
Figure 7: Six DNS-CAA Subgraphs (two hops from the labels shown, issue)

All of the big commercial CAs are represented, but the CAA authorizations do not entirely reflect the market blackshares of the CA companies [24]. Interestingly, neither are the numerous acquisitions and other changes in the market structure (yet) reflected in the results. What is more important, the most frequently authorized domain in the issue graph is Google’s This observation does not mean that many domains would authorize Google to issue certificates. The explanation rather is that many of Google’s domains are popular, and, hence, present also in the Alexa’s top-million list. A closer look reveals that out of the domains connected to in the issue graph, as much as contain the character string blogspot. These cases also reflect the resolving strategy; the CAA records for most of these cases were resolved via DNS hierarchy. In fact, out of the domains with CAA records, only three were obtained via the CNAME traversing, about 14% were directly available, and as much as 86% were retrieved by moving upward in the DNS hierarchy. A majority of the hierarchical resolving cases refer to Google’s domains.

The large disconnected subgraph in Fig. 6 represents domains that have disallowed the issuance of wildcard certificates for all authorities by specifying empty values for their issuewild tags. Given the concerns about erroneous certificate issuance, this observation can be seen as a positive finding. However, all of these domains have accompanied their empty issuewild tags with non-empty issue tags, meaning that the domains have still authorized CAs to issue normal certificates. It is also noteworthy that the amount of self-loops is only eight and fifteen in the issue and issuewild graphs, respectively. In other words, only a few blackdomains have authorized themselves. While is among these domains, most of these cases likely refer to deployments operating with self-signed certificates.

It is interesting to observe that many of the authorized CAs tend to cluster into their own dense subgraphs that are only sparsely connected to other clustered subgraphs. While this observation is a typical finding in empirical graph mining applications [28], the contextual interpretation is more interesting than statistical clustering as such. To aid the interpretation, Fig. 8 displays six subgraphs that include those vertices and edges that are two steps away from the labeled domains authorized via the issue tag.

The presence of dense subgraphs means that most Alexa-domains tend to only authorize one CA-domain, which is understandable because most certificates cost money. Interestingly, however, the domains that have authorized via the issue tag tend to form a more dense subgraph than many of the domains that have authorized commercial CAs. Even though LE is less frequently authorized than DigiCert black(see Fig. 6), for instance, this result likely again reflects the sampling from the Alexa’s list. In other words, the most popular domains are not the primary target audience of the LE initiative. The denseness of the LE-subgraph in Fig. 8 likely reflects this target audience. In absolute terms, the results also implicitly correlate rather well with previous results according to which about 5% of domains in the Alexa’s top-million list used a LE’s certificate in late 2016 [1]. While also the earlier remark about Google’s domains is vividly reinforced by the subgraph illustration in Fig. 8, the upper-left subgraph is also noteworthy because it indicates the presence of a few configuration mistakes. That is, specifying both an empty value and a specified issuer is identical to specifying just the specified issuer alone [15]. Analogous point can be made regarding the flags specified for authorizations; a few domains have set a value one rather than the value for specifying the critical flag (see Fig. 6). Finally, most of the domains that have used the iodef tag prefer electronic mail for reporting CAA-related issues (see Fig. 8). The majority of the domains with CAA records (about 65%, to be precise) have not bothered to announce any contact details, however.

5 Conclusion

This paper surveyed the adoption of the blackcertification authority authorization. By using a dataset based on live DNS resolving of domains in the Alexa’s top-million list, the adoption of CAA was observed to still be at a modest level. Among the domains that have specified CAA records in their DNS configurations, the authorization of normal certificates is more common than the authorization of wildcard certificates. In fact, many domains explicit disallow CAs to issue wildcard certificates. In terms of the authorized CAs, the results reported reflect only partially the market structure of the global certificate business. In addition to new initiatives such as Let’s Encrypt, particularly the domains owned by Google have pushed the adoption of CAA forward. These results align well with the continuing concerns about weaknesses in the global TLS/PKI ecosystem. blackFour limitations can be also noted for further work on CAA.

The paper’s scope was strictly restricted to DNS. Therefore, (1) further research is required for better understanding how the DNS-based certificate authorizations correlate with the actual issuance of certificates by certificate authorities. The certificate transparency logs provide a good empirical source to examine such correlations. The topic is important because CAA does not impose any technique for validating whether a CA is properly evaluating CAA resource records [27]. Likewise, the use of DNS security (DNSSEC) is strongly recommended to be used in conjunction with CAA [15]. Although this conjunction was not examined in this paper, (2) it should be addressed in further empirical research. Nor did the paper attempt to track the adoption across time. Given that CAA checking was recently voted to be mandatory for most certificate authorities, (3) further research is also needed to systematically track CAA’s future longitudinal evolution in different areas. For instance, an interesting topical area relates to the future adoption of CAA among content delivery networks and their DNS infrastructures. Finally, the sample used in the paper was restricted to the most popular domains. As this restriction presumably entails some biases for observing new TLS/PKI openings such as LE, (4) further work is required to evaluate different sampling strategies for large-scale empirical Internet measurement experiments.


  • Aertsen et al. [2017] Aertsen, M., Korczyński, M., Moura, G. C. M., Tajalizadehkhoob, S., and van den Berg, J. (2017). No Domain Left Behind: Is Let’s Encrypt Democratizing Encryption? In Proceedings of the Applied Networking Research Workshop (ANRW 2017), pages 48–54, Prague. ACM.
  • Akhawe et al. [2013] Akhawe, D., Amann, B., Vallentin, M., and Sommer, R. (2013). Here’s My Cert, So Trust Me, Maybe?: Understanding TLS Errors on the Web. In Proceedings of the 22nd International Conference on World Wide Web (WWW 2013), pages 59–70, Rio de Janeiro. ACM.
  • Aleksandersen [2017] Aleksandersen, D. (2017). Stop CAs from Misissuing Certificates for Your Domains with CAA Records. Ctrl Blog, 4 April. Available online in October 2017:
  • Alexa Internet, Inc. [2017] Alexa Internet, Inc. (2017). The Top Million Websites. Data feed retrieved in 21 October (monthly averages, daily updates):
  • Amann et al. [2017] Amann, J., Gasser, O., Scheitle, Q., Brent, L., Carle, G., and Holz, R. (2017). Mission Accomplished?: HTTPS Security After DigiNotar. In Proceedings of the 2017 Internet Measurement Conference (IMC 2017), pages 325–340, London. ACM.
  • BBC [2017] BBC (2017). Google and Symantec Clash on Website Security Checks. Available online in October 2017:
  • Chirgwin [2017] Chirgwin, R. (2017). Mozilla Devs Discuss Ditching Dutch CA, Because Cryptowars: We Don’ Want no STEENKIN’ Proxies, As Will Be Possible Under New Local Laws. The Register, 30 October. Available online in October 2017:
  • Dacosta et al. [2012] Dacosta, I., Ahamad, M., and Traynor, P. (2012). Trust No One Else: Detecting MITM Attacks Against SSL/TLS Without Third-Parties. In Foresti, S., Yung, M., and Martinelli, F., editors, Proceedings of the European Symposium on Research in Computer Security (ESORICS 2012), Lecture Notes in Computer Science (Volume 7459), pages 199–216, Pisa. Springer.
  • Danyliw et al. [2007] Danyliw, R., Meijer, J., and Demchenko, Y. (2007). The Incident Object Description Exchange Format (RFC 5070). Internet Engineering Task Force (IETF). Available online in October 2017:
  • Delamore and Ko [2015] Delamore, B. and Ko, R. K. L. (2015). A Global, Empirical Analysis of the Shellshock Vulnerability in Web Applications. In Proceedings of the IEEE Trustcom/BigDataSE/ISPA 2015, pages 1129–1135, Helsinki. IEEE.
  • Farrell and Tschofenig [2014] Farrell, S. and Tschofenig, H. (2014). Pervasive Monitoring Is an Attack (RFC 7258). Internet Engineering Task Force (IETF). Available online in October 2017:
  • Forno and Feinbloom [2001] Forno, R. and Feinbloom, W. (2001). Inside Risks: PKI: A Question of Trust and Value. Communications of the ACM, 44(6):120–120.
  • Grimm [2016] Grimm, J. (2016). PKI: Crumbling Under the Pressure. Network Security, (5):5–7.
  • Hall [2017] Hall, K. (2017). Results on Ballot 187 – Make CAA Checking Mandatory. The CA/Browser Forum. Available online in October 2017:
  • Hallam-Baker and Stradling [2013] Hallam-Baker, P. and Stradling, R. (2013). DNS Certification Authority Authorization (CAA) Resource Record (RFC 6844). Internet Engineering Task Force (IETF). Available online in October 2017:
  • Hunt [2001] Hunt, R. (2001). Technological Infrastructure for PKI and Digital Certification. Computer Communications, 24(14):1460–1471.
  • Kim et al. [2017] Kim, D., Kwon, B. J., and Dumitraş, T. (2017). Certified Malware: Measuring Breaches of Trust in the Windows Code-Signing PKI. In Proceedings of the ACM Conference on Computer and Communications Security (CCS 2017), pages 1435–1448, Dallas. ACM.
  • Kumar et al. [1993] Kumar, A., Postel, J., Neuman, C., Danzig, P., and Miller, S. (1993). Common DNS Implementation Errors and Suggested Fixes (RFC 1536). Internet Engineering Task Force (IETF). Available online in March 2017:
  • Laurie et al. [2013] Laurie, B., Langley, A., and Kasper, E. (2013). Certificate Transparency (RFC 6962). Internet Engineering Task Force (IETF). Available online in October 2017:
  • Leavitt [2011] Leavitt, N. (2011). Internet Security under Attack: The Undermining of Digital Certificates. Computer, 44(12):17–20.
  • Let’s Encrypt [2017] Let’s Encrypt (2017). Certificate Authority Authorization (CAA). Available online in November 2017:
  • Lin et al. [2012] Lin, J., Jing, J., and Liu, P. (2012). Evaluating Intrusion-Tolerant Certification Authority Systems. Quality and Reliability Engineering International, 28(8):825–841.
  • Meyer and Schwenk [2014] Meyer, C. and Schwenk, J. (2014). SoK: Lessons Learned from SSL/TLS Attacks. In Kim, Y., Kim, H., and Perrig, A., editors, Proceedings of the International Workshop on Information Security Applications (WISA 2013), Lecture Notes in Computer Science (Volume 8267), pages 189–209, Jeju Island. Springer.
  • Netcraft, Ltd. [2015] Netcraft, Ltd. (2015). SSL Survey. Available online in November 2017:
  • Oh et al. [2016] Oh, S., Kim, E., and Kim, H. (2016). Empirical Analysis of SSL/TLS Weaknesses in Real Websites: Who Cares? In Choi, D. and Guilley, S., editors, Proceedings of the International Workshop on Information Security Applications (WISA 2016), Lecture Notes in Computer Science (Volume 10144), pages 174–185, Jeju Island. Springer.
  • RFC Editor [2017] RFC Editor (2017). RFC Errata for RFC 6844. Available online in October 2017:
  • Rowley [2017] Rowley, J. (2017). The Latest on Certification Authority Authorization. CA Security Council. Available online in November 2017:
  • Ruohonen et al. [2016] Ruohonen, J., Holvitie, J., Hyrynsalmi, S., and Leppänen, V. (2016). Exploring the Clustering of Software Vulnerability Disclosure Notifications Across Software Vendors. In Proceedings of the 13th ACS/IEEE International Conference on Computer Systems and Applications (AICCSA 2016), pages 1–8, Agadir. IEEE.
  • Ruohonen and Leppänen [2016] Ruohonen, J. and Leppänen, V. (2016). On the Design of a Simple Network Resolver for DNS Mining. In Proceedings of the 17th International Conference on Computer Systems and Technologies (CompSysTech 2016), pages 105–112, Palermo. ACM.
  • Ruohonen and Leppänen [2017a] Ruohonen, J. and Leppänen, V. (2017a). How PHP Releases Are Adopted in the Wild? In Proceedings of the 24th Asia-Pacific Software Engineering Conference (APSEC 2017), pages 71–80, Nanjing. IEEE.
  • Ruohonen and Leppänen [2017b] Ruohonen, J. and Leppänen, V. (2017b). Investigating the Agility Bias in DNS Graph Mining. In Proceedings of the 17th IEEE International Conference on Computer and Information Technology (IEEE CIT 2017), pages 253–260, Helsinki. IEEE.
  • Scheitle et al. [2018] Scheitle, Q., Chung, T., Hiller, J., Gasser, O., Naab, J., van Rijswijk-Deij, R., Hohlfeld, O., Holz, R., Choffnes, D., Mislove, A., and Carle, G. (2018). A First Look at Certification Authority Authorization (CAA). ACM SIGCOMM Computer Communication Review, 48(2):1–13.
  • Schuster et al. [2017] Schuster, S., van den Berg, M., Larrucea, X., Slewe, T., and Ide-Kostic, P. (2017). Mass Surveillance and Technological Policy Options: Improving Security of Private Communications. Computer Standards & Interfaces, 50:76–82.
  • Sheffer and Holz [2015] Sheffer, Y. and Holz, R. (2015). Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) (RFC 7457). Internet Engineering Task Force (IETF). Available online in October 2017:
  • Springall et al. [2016] Springall, D., Durumeric, Z., and Halderman, J. A. (2016). Measuring the Security Harm of TLS Crypto Shortcuts. In Proceedings of the 2016 Internet Measurement Conference (IMC 2016), pages 33–47, Santa Monica. ACM.
  • VanderSloot et al. [2016] VanderSloot, B., Amann, J., Bernhard, M., Durumeric, Z., Bailey, M., and Halderman, J. A. (2016). Towards a Complete View of the Certificate Ecosystem. In Proceedings of the 2016 Internet Measurement Conference (IMC 2016), pages 543–549, Santa Monica. ACM.
  • Wander [2017] Wander, M. (2017). Measurement Survey of Server-Side DNSSEC Adoption. In Proceedings of the Network Traffic Measurement and Analysis Conference (TMA 2017), pages 1–9, Dublin. IEEE.
  • Wei and Wolf [2017] Wei, X. and Wolf, M. (2017). A Survey on HTTPS Implementation by Android Apps: Issues and Countermeasures. Applied Computing and Informatics, 13(2):101–117.