Can a TLS Certiﬁcate Be Phishy?

Kaspar Hageman

, Egon Kidmose

, Ren

e Rydhof Hansen

and Jens Myrup Pedersen

Department of Electronic System, Aalborg University, Denmark

Department of Computer Science, Aalborg University, Denmark

Keywords:

Phishing, Digital Certiﬁcate, Certiﬁcate Transparency, TLS.

Abstract:

This paper investigates the potential of using digital certiﬁcates for the detection of phishing domains. This is

motivated by phishing domains that have started to abuse the (erroneous) trust of the public in browser padlock

symbols, and by the large-scale adoption of the Certiﬁcate Transparency (CT) framework. This publicly

accessible evidence trail of Transport Layer Security (TLS) certiﬁcates has made the TLS landscape more

transparent than ever. By comparing samples of phishing, popular benign, and non-popular benign domains,

we provide insight into the TLS certiﬁcates issuance behavior for phishing domains, focusing on the selection

of the certiﬁcate authority, the validation level of the certiﬁcates, and the phenomenon of certiﬁcate sharing

among phishing domains. Our results show that phishing domains gravitate to a relatively small selection of

certiﬁcate authorities, and disproportionally to cPanel, and tend to rely on certiﬁcates with a low, and cheap,

validation level. Additionally, we demonstrate that the vast majority of certiﬁcates issued for phishing domains

cover more than only phishing domains. These results suggest that a more pro-active role of CAs and putting

more emphasis on certiﬁcate revocation can have a crucial impact in the defense against phishing attacks.

1 INTRODUCTION

Decades after its inception in the ’90s, phishing re-

mains a signiﬁcant problem. This scalable form of

criminal activity can be characterized by the use of

deception in which impersonation is used to obtain

information from a target (Lastdrager, 2014). The

Anti-Phishing Working Group (APWG) still reports

the discovery of tens of thousands of phishing sites

monthly (Anti-Phishing Working Group, 2021). This

indicates that phishing is far from a solved problem,

and that there remains a need for novel and improved

detection, prevention and mitigation methods.

A signiﬁcant effort, from both an academic and

commercial perspective, has been made towards the

detection and identiﬁcation of phishing entities, such

as URLs, emails, websites and domains. Existing ap-

proaches are in many cases based on identifying sim-

ilarities between suspicious entities and known legit-

imate ones, as criminals conducting phishing attacks

(referred to as phishers) often attempt to deceive vic-

tims into believing they are interacting with a legiti-

mate system. However, entities that so far ha not re-

ceived a similar degree of scrutiny are digital certiﬁ-

cates. Such certiﬁcates are used in establishing a se-

cure communication channel between (among others)

web browsers and web servers. It raises the research

question on whether TLS certiﬁcates can be labeled as

‘phishy’ or benign in the same manner URLs and do-

mains have historically been given these labels, ulti-

mately preventing Internet users from interacting with

websites serving these certiﬁcates. The recent large-

scale adoption of two technologies has resulted in a

trail of certiﬁcates, which potentially can be used for

an alternative detection method of phishing attacks:

• HTTPS, i.e., HTTP over Transport Layer Secu-

rity, by phishing websites, for encrypting trafﬁc

between the browser and web server

• The submission of newly-issued TLS certiﬁcates

to Certiﬁcate Transparency (CT) logs by certiﬁ-

cate authorities

Certiﬁcate Transparency has been developed for third

parties to monitor the logs for fraudulently issued cer-

tiﬁcates, resulting in TLS certiﬁcates being inserted

in these logs in near real-time and additionally on a

global scale. Furthermore, the issuance of certiﬁcates

is assumed to occur early in the lifecycle of a do-

main, and thereby also of the phishing attack. Prior

research has identiﬁed a general short domain lifetime

and disposable nature of phishing domains, which we

hypothesize to be reﬂected in the CT log artifacts we

can observe:

Hageman, K., Kidmose, E., Hansen, R. and Pedersen, J.

Can a TLS Certiﬁcate Be Phishy?.

DOI: 10.5220/0010516600380049

In Proceedings of the 18th International Conference on Security and Cryptography (SECRYPT 2021), pages 38-49

ISBN: 978-989-758-524-1

1. The selected certiﬁcate authority that phishing

domains resort to for issuing their certiﬁcates are

expected to be cheap and certiﬁcate issuance is ex-

pected to be automated. In addition, an analysis of

CA selection may reveal certain patterns related to

the phishing hosting infrastructure of phishers.

2. The validation level of certiﬁcates is a proxy for

the monetary cost that phishers invest into increas-

ing the perceived legitimacy of phishing websites.

3. Phishing attacks may be part of a larger campaign,

and the preparation of those attacks may be coor-

dinated. It is hypothesized that this is reﬂected in

certiﬁcates covering more than one phishing do-

main, which in practice would simplify the host-

ing infrastructure of the phishing attack.

In this work, we test these hypotheses by analyz-

ing a large collection of TLS certiﬁcates, hinting to-

wards the ‘phishiness’ of the certiﬁcates. The results

serve as a preliminary motivation for pursuing a CT-

based phishing mitigation system. It is namely impor-

tant that phishing domains and non-phishing domains

handle their infrastructure signiﬁcantly different from

a TLS perspective, in order to rely on them for such

as mitigation system.

Prior to testing these hypotheses, we used our col-

lected data to show that for the majority of phishing

domains, a certiﬁcate is issued before the domain gets

blacklisted, which emphasizes the relevancy of a CT

log-based protection system. Our main ﬁndings are

as follows:

• Phishers resort to a relatively small set of CAs for

their certiﬁcate issuance, and the issuer of certiﬁ-

cates reveals information regarding the infrastruc-

ture on which services for domains are served,

as illustrated by a signiﬁcant number of cPanel

servers for phishing domains.

• Phishers seldom resort to the more expensive EV

certiﬁcates, and rarely to OV certiﬁcates, although

these results apply to non-popular domains as

well.

• Certiﬁcates rarely cover only phishing certiﬁcates,

but a large fraction of certiﬁcates issued for phish-

ing domains cover other domains as well.

The remainder of the paper is structured as follows.

We present the context of the paper in the background

and related work in Sections 2 and 3. This is followed

by a description of the methodology and the results in

Sections 4 and 5. The overall impact of the results is

discussed in Section 6.

2 BACKGROUND

Transport Layer Security (TLS) — like its predeces-

sor SSL — is the underlying protocol suite for en-

crypting communication on the Internet. The secure

communication it provides is facilitated by a public

key infrastructure, in which the identity of an entity

(such as a domain name) is bound to a cryptographic

public key. The proof of such a binding is stored and

distributed in the form of an X.509 certiﬁcate, and

consists of the identities, the public key and a cryp-

tographic signature that allows a web browser to ver-

ify the identity of the web server it is initiating a TLS

connection with. The process of issuing certiﬁcates

is handled by one of the hundreds of certiﬁcate au-

thorities (CAs), which are inherently-trusted, third-

party organizations. The X.509 certiﬁcate standard

supports the binding with multiple identities (Cooper

et al., 2008), and these identities are referred to as

Subject Alternative Names (SANs). This allows an

organization to request a single certiﬁcate for multiple

domains (or other entity types such as IP addresses),

thereby reducing the number of certiﬁcates required

to secure web trafﬁc towards their infrastructure.

An applicant applies for a certiﬁcate at a CA with

information about the to-be-created certiﬁcate, such

as the SANs to cover, the validation level of the cer-

tiﬁcate, and the period for which the certiﬁcate is

valid. The CAs are tasked to verify that the requester

of a certiﬁcate does in fact own all entities that the

certiﬁcate is about to cover. This veriﬁcation can be

done via a variety of methods depending on the CA,

including email veriﬁcation, an HTTP endpoint, or

more thorough background checks. After an appli-

cant proves ownership of all SANs, the CA issues a

certiﬁcate, signed by their own root (or intermediate)

certiﬁcate.

Each certiﬁcate has a validation level associated

with it, indicating the depth - and therefore also the

cost - of the veriﬁcation process the CA and requester

went through to get the certiﬁcate issued. Domain

validated (DV) certiﬁcates require the least validation,

followed by organization validated (OV) certiﬁcates

and lastly extended validated (EV) certiﬁcates. The

latter validation type is reserved for corporations and

recognized entities, and requires an in-depth back-

ground check. The beneﬁt of these more expensive

OV and EV certiﬁcates used to be a different indica-

tor in the browser, although most browsers are mov-

ing towards removing these differences

, as different

indicators have proven to be ineffective (Thompson

et al., 2019).

https://blog.chromium.org/2018/05/evolving-chromes-

security-indicators.html

Can a TLS Certiﬁcate Be Phishy?

In addition to the validation level and SANs to be

covered in the domain, an applicant must declare the

duration of the validity period of the certiﬁcate. As a

security mechanism, certiﬁcates expire after a times-

pan after which a certiﬁcate cannot successfully be

veriﬁed and TLS connections must be rejected. Typi-

cally, this period lies between a few months and cou-

ple of years, and since 2020, the CA/Browser Base-

line Requirements restricts the validity period to a

maximum of 13 months (CA/Browser Forum, 2020).

This period prevents certiﬁcates from being abused

for long periods of time, in case the private key of

the cryptographic key pair of the certiﬁcate owner is

compromised.

2.1 Certiﬁcate Transparency

Fraudulent issuance of a certiﬁcate — regardless of

its malicious intent — can have a disastrous impact,

as demonstrated by two incidents in 2011. Attack-

ers were able to obtain certiﬁcates for domains in-

cluding google.com and microsoft.com, allowing

them to perform large-scale man-in-the-middle at-

tacks (Prins, 2011). The reputation damage eventu-

ally resulted in the bankruptcy of one of the CAs.

As a direct response to these incidents, the Certiﬁ-

cate Transparency project was initiated with the goal

of monitoring and auditing the certiﬁcate issuance of

CAs. The project encourages CAs to submit every

issued certiﬁcate to publicly accessible, append-only

CT ‘logs’. These CT logs can be run by third-party

organizations and, due to their public availability, al-

low anyone to monitor for fraudulent issuance of cer-

tiﬁcates for their domains. As of February 2021,

Chrome’s CT policy recognizes more than a hundred

logs being operated by 21 different organizations, and

they contain over 12 billion issued certiﬁcates

After submitting a certiﬁcate to a CT log, a CA

obtains a Signed Certiﬁcate Timestamp (SCT), which

acts as a proof from the log operator that the certiﬁ-

cate is, or will soon be, appended to the log. This

SCT is embedded in the certiﬁcate, which can be

used during the TLS handshake between a browser,

and a web server to verify the inclusion of the cer-

tiﬁcate in the logs. As of April 2018, Chrome has

started to require any certiﬁcate to comply with its

CT policy, effectively requiring all certiﬁcates to be

logged in at least two CT logs

. A similar policy was

introduced by Apple in October 2018

. Due to the

large combined browser market share of Google and

https://www.certiﬁcate-transparency.org/known-logs

https://github.com/chromium/ct-policy/blob/master/

ct policy.md

https://support.apple.com/en-us/HT205280

Apple (an estimated 82.3% as of February 2021

this has resulted in the large-scale adoption of the

CT framework. Combined with a generally increased

adoption of HTTPS (an estimated 84% for phishing

URLs (Anti-Phishing Working Group, 2021)), this

makes the CT logs a promising data source for phish-

ing detection.

3 RELATED WORK

Scheitle et al. (Scheitle et al., 2018) recognized the

potential of CT logs for phishing detection based

on a preliminary experiment, focusing primarily on

typosquatting domains, the practice of registering

domains looking similar to other domains in or-

der to create confusion. More recently, Fasllija et

al. (Fasllija et al., 2019) explored this idea further

by implementing and evaluating a classiﬁer based

on the certiﬁcates contained in the CT logs. Simi-

larly, Sakurai et al. (Sakurai et al., 2020) built domain

name templates and match newly issued certiﬁcates

against these templates to identify new phishing do-

mains. Commercial initiatives such as CertSpotter

PhishFinder

, and Facebook

started to provide pro-

tection services that alert domain owners whenever a

certiﬁcate for their domains is submitted to a CT log.

These initiatives primarily rely on the lexical prop-

erties of the domains and do not explore the TLS-

speciﬁc information contained in the logs.

Alternative early detection systems for domain

abuse have been proposed in prior research. The

works of Hao et al. (Hao et al., 2013; Hao et al.,

2016) resulted in PREDATOR, a proactive detec-

tion system of spamming domains. The Dutch reg-

istry, SIDN, uses nDEWS (Moura et al., 2016) as

an early detection system for various types of do-

main abuse, operating at the level of a top-level do-

main. Lever et al. (Lever et al., 2016) detect do-

main ownership changes for identifying malicious re-

registrations. These systems primarily rely on the

DNS for their data, and could potentially be combined

with CT log data analysis for better performances.

The CT logs have been used as a source data

set for other application areas besides phishing do-

main detection. Manousis et al. (Manousis et al.,

2016) analyse the impact of Let’s Encrypt on the TLS

ecosystem, ﬁnding early evidence for the adoption of

typosquatters and malware hosters. Similarly, Aer-

https://www.w3counter.com/globalstats.php

https://sslmate.com/certspotter/

https://phishﬁnder.io/

https://developers.facebook.com/tools/ct

SECRYPT 2021 - 18th International Conference on Security and Cryptography

sten et al. (Aertsen et al., 2017) identify that in the ﬁrst

year of Let’s Encrypt’s introduction, primarily low-

cost domains started to resort to Let’s Encrypt as their

CA. VanderSloot et al. (VanderSloot et al., 2016) in-

vestigated the coverage of the entire TLS ecosystem

from various viewpoints (in terms of observed certiﬁ-

cates). They identiﬁed that CT logs at the time already

captured over 90% of all certiﬁcates, which since then

presumably has only increased further.

Prior research has relied on alternative certiﬁcate-

related datasets. These datasets were often collected

by either actively probing TLS servers (i.e.active mea-

surements) or monitoring network trafﬁc for TLS

handshakes (i.e.passive measurements). Active mea-

surements allow researchers to not only capture the

certiﬁcate, but also parameters exchanged during the

TLS handshake (Zhang et al., 2014). Drawbacks

of active measurements include its reliance a list of

known domains

, partial coverage caused by unavail-

ability of servers and the difﬁculty of performing

continuous measurements. In passive measurements,

such as the works by Razaghpanah et al. (Razagh-

panah et al., 2017), have no control of which cer-

tiﬁcate are observed. The degree of coverage of the

TLS ecosystem is highly dependent on the quality and

quantity of the observation point(s), as a small and ho-

mogenous client population is unlikely to query a sig-

niﬁcant portion of TLS-enabled servers. In contrast

to CT logs, neither active nor passive measurements

are guaranteed to provide certiﬁcates in a timely fash-

ion (i.e., immediately after the certiﬁcate has been is-

sued). Note that different measurement types can be

used in conjunction (Holz et al., 2019), compensat-

ing each other’s drawbacks and thereby resulting in a

higher quality dataset.

4 METHODOLOGY

To obtain a manageable dataset of certiﬁcates (in

terms of the cost of analyzing these certiﬁcates), we

collect certiﬁcates issued for a sample of three do-

main types. An exploratory analysis of all certiﬁcates

available from the CT logs is considered infeasible,

as they contain over twelve billion certiﬁcates. Rather

than considering Fully Qualiﬁed Domain Names

(FQDNs), we are primarily concerned with analyzing

root domains, the part of the FQDN under which

A TLS handshake involves the Server Name Indication ex-

tension of TLS (Blake-Wilson et al., 2003), i.e., a ﬁeld that

contains the domain name that the client intends to connect

to.

Tranco

.com zone

ECX

Domain sampling

Phishing

Popular,

benign

Non-popular,

benign

Domains

Certiﬁcate

retrieval

Google

BigQuery

Analysis

Figure 1: The process of retrieving the three samples of do-

mains and their associated certiﬁcates. The grey boxes rep-

resent the source data sets, the green boxes represent three

domain types and the red boxes represent the actions per-

formed by the authors. D = set of domains, U = set of URLs,

C = set of certiﬁcates.

the domain is registered by its owners

. Certiﬁcates

issued for domains under this root domain are gen-

erally requested by the domain owner since the do-

main owner is tasked to demonstrate ownership of the

domain to the CA, although newer veriﬁcation meth-

ods (such as an HTTP-based method) challenge this

assumption. The aforementioned three domain types

used for analysis are deﬁned as follows:

• Phishing domains (D

phish

) are those domains that

have historically been used in phishing attacks.

• Popular benign domains (D

pop

) represent the set

of domains used for highly popular services that

receive the majority of trafﬁc on the Internet.

• Non-popular benign domains (D

nonpop

) are do-

mains that receive a low amount of trafﬁc, yet

have not been seen as part of phishing attacks.

For each domain type, we sampled 10,000 domains,

resulting in a total number of 30,000 domains for

which certiﬁcates were collected. Figure 1 shows the

process to retrieve the sample of domains and their as-

sociated certiﬁcates. The domain sampling step con-

sists of converting the source domains into a set of

sampled, labeled domains. In the certiﬁcate retrieval

step, all certiﬁcates for these sampled domains are re-

trieved, which in turn are analyzed further.

Domain Sampling. The Tranco list (Pochat et al.,

2019) combines three other domain lists to provide a

robust list of the top one-million popular domains, in

terms of the popularity of those domains

. We as-

sume that the domains on the top of this list are in-

herently benign (i.e., they were not registered for ma-

licious purposes), under the assumption that a mali-

ciously registered domain will never become popular

enough to receive high amounts of trafﬁc. The top of

For instance, the root domain for the FQDN

www.example.co.uk is example.co.uk.

The deﬁnition of ‘popularity’ differs slightly between the

three source lists, but generally represents the amount of

trafﬁc the domain receives.

Can a TLS Certiﬁcate Be Phishy?

the list therefore represents popular, benign domains.

The APWG’s eCrime eXchange (eCX) platform

contains millions of known phishing URLs submitted

by contributing organizations, whenever the submit-

ted URL is found to host phishing content. The root

domains extracted from these URLs form the base of

the phishing domain sample, denoted as D

ecx

. Some

popular domains are often abused for hosting phish-

ing content, such as Facebook or Google Docs. This

however does not imply those domains are registered

for malicious purposes; the content on these sites is

merely user-generated and therefore contains a mix

of malicious and benign content. The set of phish-

ing domains is deﬁned as D

phish

= D

ecx

\ D

pop

, or the

root domains extracted from eCX URLs, excluding

any domain that is in the top 1M Tranco domains.

Lastly, the non-popular, benign domain type is de-

ﬁned as D

nonpop

= D

com

\ (D

ecx

∪ D

pop

), where D

com

is the set of all domains in the .com zone (comprising

almost half of all domains globally). None of these

domains receive a large amount of trafﬁc and have

never been seen in a phishing attack according to the

eCX platform.

Certiﬁcate Retrieval. We collect any certiﬁcate

submitted to the CT log ecosystem that covers (at

least) one of the domains in the domain sets. This

collection is done through a Google BigQuery dataset

provided by the Censys search engine (Durumeric

et al., 2015). The criterion for a certiﬁcate to cover

a domain name is that the SANs list of the certiﬁcate

contains (1) the root domain itself, (2) a subdomain of

the root domain, or (3) a wildcard domain under the

root domain. In addition to the raw certiﬁcates, we

also collect several extra ﬁelds, including the ﬁnger-

print of the certiﬁcate, and the validity of the certiﬁ-

cate according to different root stores.

5 RESULTS

All four datasets (i.e., the Tranco list, the .com zone

ﬁle, the eCX URLs, and certiﬁcates) were collected

in the beginning of 2020. We used the Tranco list

from February 20th, 2020

. The list of eCX URLs

comprises over 8.6 million URLs (belonging to 1.02

million unique root domains), and contains URLs dis-

covered up to February 27th, 2020. The certiﬁcates

from Censys were collected on March 12th, 2020.

An overview of the resulting dataset is shown in Ta-

ble 1. The vast majority of the 79.1 million collected

https://apwg.org/ecx/

Available at https://tranco-list.eu/list/XWNN.

Table 1: Overview of the collected dataset.

# domains

without cert

# certiﬁcates

% certiﬁcates

trusted

Phishing 10.0k 4.2k 184.9k 95.9

Popular 10.0k 175 78.9M 40.4

Non-pop. 10.0k 6.3k 95.6k 99.0

Total 30.0k 10.7k 79.1M

certiﬁcates were issued for popular domains. This is

partially explained by the fact that only a small frac-

tion of popular domains had no certiﬁcate issued for

it, compared to 4,235 phishing domains, and 6,283

of the non-popular domains. In our further analysis,

we discard certiﬁcates that are untrusted by browsers,

as those certiﬁcates cause browsers to present users

a warning page, instead of the actual content. The

purpose of issuing certiﬁcates in the ﬁrst place is to

make pages seem legitimate, which is defeated when

a warning page is shown. A certiﬁcate can be un-

trusted for various reasons, such as being self-signed

or being signed by a root certiﬁcate that a particu-

lar browser or operating system does not trust. This

ﬁltering of untrusted certiﬁcates primarily affects the

popular domains, with nearly 60% of all certiﬁcates

issued for those domains being untrusted. The table

suggests that phishing domains have adopted HTTPS

to a higher degree than non-popular domains, with

nearly twice the number of certiﬁcates issued for

them.

5.1 Temporal Analysis

As previously stated, one advantage of CT log analy-

sis over passive and active measurements is the pre-

sumed early submission and publication of certiﬁ-

cates to the CT logs. Using CT logs as a data source

for early detection is only viable if certiﬁcates can

consistently be monitored prior to the blacklisting of

the domains they cover, and as such we test the fol-

lowing hypothesis:

Hypothesis 1. Certiﬁcate issuance occurs prior to

blacklisting of phishing domains

We analyze the time difference between (1) the black-

listing of a phishing domain and (2) the issuance of its

certiﬁcate(s). This process is made more difﬁcult be-

cause a domain can both have been blacklisted mul-

tiple times, and have multiple certiﬁcates issued for

it. The former challenge is tackled by selecting the

ﬁrst timestamp of blacklisting seen for that speciﬁc

domain, whereas the latter is tackled by introducing

the notion of the closest certiﬁcate. For each times-

tamp of ﬁrst blacklisting, the most recent certiﬁcate

issuance before blacklisting is considered. If no cer-

tiﬁcate before blacklisting exists, the oldest certiﬁcate

SECRYPT 2021 - 18th International Conference on Security and Cryptography

certiﬁcate

blacklisting

Δtime

Figure 2: The computation of the time difference between

domain blacklisting and the closest certiﬁcate issuance. For

domain d

, the most recent certiﬁcate before the ﬁrst black-

listing timestamp is taken (resulting in a negative time dif-

ference), whereas for domain d

the earliest certiﬁcate is-

suance timestamp after the ﬁrst blacklisting timestamp is

taken (resulting in a positive time difference).

after blacklisting is considered. The ﬁrst motivation

for this deﬁnition is that the most recent certiﬁcate

before blacklisting is most likely to be issued by the

same owner of the domain at the time of blacklist-

ing, as older certiﬁcates may have been issued by a

previous owner of the domain. Secondly, certiﬁcates

issued after blacklisting are meaningless for early pro-

tection against phishing attacks abusing that domain,

hence the low priority of including those certiﬁcates.

This process is illustrated in Figure 2.

Certiﬁcates issued before the ﬁrst blacklisting date

are not necessarily requested by the same domain

owner that caused the domain to be blacklisted. Given

the decade-spanning time window of the CT logs, it

is possible to observe a certiﬁcate issued for a domain

ten years before it got blacklisted. Since the identi-

ﬁcation of domain ownership is inherently a difﬁcult

task, we instead estimated a lower and upper bound

for the number of phishing domains for which we can

identify a relevant certiﬁcate, issued before the do-

main got blacklisted.

Upper Bound. For all phishing domains in the

dataset, the time difference between the issuance

of the closest certiﬁcate (t

) and the earliest URL

blacklisting timestamp (t

) is computed (denoted as

∆(t

, t

)). A negative time difference implies that

the closest certiﬁcate was issued before the URL was

blacklisted. For 75.66% of all phishing domains, the

earliest certiﬁcate timestamp occurs before the earli-

est blacklisting timestamp, which serves as the upper

bound of the percentage of domains a CT log-based

phishing domain detection system can protect against.

Lower Bound. In order to estimate a lower bound,

the registration process of a domain is taken into ac-

count. Since domains can change their ownership

during their lifecycle, it is vital to only consider cer-

tiﬁcates issued by the same owner that owned the

domain during the time of blacklisting. A domain

domain

registration

domain

expiration

end of

auto-renew

45 days

end of

redemption period

available for

re-registration

30 days 5 days1+ year

auto-renew period

redemption period

Figure 3: Timeline of the re-registration process of a do-

main name.

end of

auto-renew

(-35d)

listed as

pending

delete (-5d)

re-registration

, t

)

0.0

0.5

1.0

ECDF

56.13%

of domains

75.66%

Figure 4: The ECDF of the time difference between the is-

suance of the closest certiﬁcate and the earliest URL black-

listing timestamp, for each phishing domain. The ﬁgure is

zoomed in on the period around the auto-renew and regis-

tration period of a domain.

registered under the .com top-level domain (TLD)

goes through a process after a domain expires, dur-

ing which the control of the domain is taken back

by the registrar, and after which a domain can poten-

tially change owner

. An auto-renew period of 45

days is followed by a 30-day redemption period, af-

ter which the domain is listed as ‘pending delete’ for

5 days. After this period, the domain is up for re-

registration (Lauinger et al., 2017) (see Figure 3). In

the auto-renew period, domain owners have the op-

portunity to renew or sell their domain, and as such

a domain cannot change ownership in the 35-day pe-

riod between the end of the auto-renew period, and the

earliest potential to re-register a domain. Given a do-

main for which a URL was blacklisted at an arbitrary

timestamp t = 0, all certiﬁcates issued in the period

[−35 days, 0] are requested by the same owner that

owned the domain at the time of blacklisting. Figure 4

shows a zoomed-in portion of the Empirical Cumula-

tive Distribution Function (ECDF) of ∆(t

, t

) of all

phishing domains, and shows that 56.13% of domains

had their closest certiﬁcate issued in this period for

which there exists the previously described certainty

about the ownership of the domain. As such, this per-

centage is considered the lower bound. The ﬁgure

Note that other TLDs may have different processes re-

garding the expiration of a domain, but given the large

market share of .com, their expiration process drives our

methodology

Can a TLS Certiﬁcate Be Phishy?

also illustrates the aforementioned upper bound.

These results indicate that for between 56.13%

and 75.66% of phishing domains, a certiﬁcate is-

suance can be observed before a URL for that do-

main is being blacklisted. Even though this implies

that perfect coverage of all domains does not seem

feasible, it is important to note that CT logs cover do-

mains across all TLDs and their coverage is arguably

only getting higher due to the ever-increasing adop-

tion of HTTPS. Therefore, CT log-based detection of

phishing domains could potentially cover a larger set

of domains than active or passive measurement-based

methods.

5.2 Issuers

Each certiﬁcate in circulation has been signed by a

CA, which has deliberately been approached by the

requester of the certiﬁcate (through the submission of

a certiﬁcate signing request). As such, the choice of

CA of a certiﬁcate reﬂects the behavior of the domain

owner. CAs have individual differences, such as pric-

ing models, countries in which they operate, the pro-

cess of verifying the identity of the requester, etc. As

these differences may be important considerations for

phishers, we test the following hypothesis:

Hypothesis 2. The CA selection of phishing domains

provides insight in the monetary considerations, and

the operations of phishers

In reality, it is not trivial to identify the underlying CA

that signed a certiﬁcate, as certiﬁcates are generally

signed by intermediate certiﬁcates

, and a single CA

may operate many intermediate certiﬁcates. In addi-

tion, cross-signing of certiﬁcates is not uncommon, in

which the root certiﬁcate of a CA signs the interme-

diate certiﬁcate of another CA, resulting in a chain of

trust rooted in more than one CA. We therefore an-

alyze the issuer of certiﬁcates rather than identifying

the underlying CA, as the issuer selection may pro-

vide a similar insight into phishing as the CA selec-

tion would.

In order to analyze the selection of CA, it is im-

portant to handle any potential biases that can be in-

duced. More speciﬁcally, it is imperative that a sin-

gle domain should not dominate other domains due

to the number of certiﬁcates issued for it (as demon-

strated earlier in Table 1), or a speciﬁc issuer to dom-

inate others due to the short validity period of their

certiﬁcate (thereby requiring customers to frequently

re-issue certiﬁcates).

The set of certiﬁcates issued for domain d

issued by

issuer a

is formalized as C

issuer

, a

). The duration

These intermediate certiﬁcates are in turn signed by a root

certiﬁcate or another intermediate certiﬁcate.

Figure 5: The distribution of the month of issuance of cer-

tiﬁcates for the three domain types.

of an individual certiﬁcate c’s validity period is de-

noted as v(c). The set of all existing issuers is A . Us-

ing these formulations, we deﬁne domain issuer pref-

erence P

issuer

, a

), which represents how much a

particular issuer is preferred by a domain:

issuer

, a

) =

∑

c∈C

issuer

)

v(c)

∑

a∈A

∑

c∈C

issuer

,a)

v(c)

(1)

This measure is a value between one and zero, and

∑

a∈A

issuer

, a) = 1. This deﬁnition is used to ex-

press the domain type issuer preference for domain

type k towards an issuer a

issuer

, a

) =

∑

d∈D

issuer

(d, a

)

∑

a∈A

∑

d∈D

issuer

(d, a)

(2)

Where D

is the set of all domains for domain

type k. Similar to Eq. 1, the following holds:

∑

a∈A

issuer

, a) = 1. Eq. 1 ensures that certiﬁcates

are weighted proportionally to their validity period,

and that each domain within a domain type is equally

weighted disregarding the number of certiﬁcates is-

sued for the domain, whereas Eq. 2 ensures a proper

comparison between domain types.

Using Eq. 2, we compute the domain type pref-

erences for all combinations of issuers and domain

types, of which the results are illustrated in Table 2.

The top 10 most preferred issuers are shown in the

table. In total, 853 issuer certiﬁcates were used to

sign the set of certiﬁcates, of which 846 were used for

popular domains, 132 for phishing domains and only

125 for non-popular domains. Generally, the prefer-

ence for phishing domains and non-popular domains

are fairly similar, with the popular domains having a

vastly different preference proﬁle.

Although Let’s Encrypt is the most preferred is-

suer for popular domains (with 15.7%), it is not nearly

as popular as the other two domain types (46.19%

and 61.46% for phishing and non-popular domains re-

spectively). One explanation could be that Let’s En-

crypt is a relatively new CA, and popular domains

tend to be long-lived, resulting in a stronger prefer-

ence for CAs that have been operating longer, or for

SECRYPT 2021 - 18th International Conference on Security and Cryptography

Table 2: The domain type issuer preference (as percentage) for the ten most preferred issuers and the three domain categories.

issuer

(D, a

) (in %)

D = D

phish

D = D

pop

D = D

nonpop

Let’s Encrypt Authority X3

∗

46.19

∗

15.70

∗

61.46

cPanel, Inc. Certiﬁcation Authority

∗

33.53 1.23

∗

10.69

COMODO ECC Domain Validation Secure Server CA 2

∗

7.94 5.23

∗

4.51

DigiCert SHA2 Secure Server CA 0.06

∗

6.88 0.15

Amazon 0.14

∗

5.91 0.73

Go Daddy Secure Certiﬁcate Authority - G2 1.91 4.50 4.21

CloudFlare Inc ECC CA-2 3.65 1.33 4.43

GlobalSign CloudSSL CA - SHA256 - G3 0.32 4.23 0.06

DigiCert SHA2 High Assurance Server CA 0.01 4.09 0.02

Sectigo RSA Domain Validation Secure Server CA 1.38 1.55 4.03

∗

among the three most preferred authorities within the domain category.

Figure 6: Distribution of the month of URLs blacklisted

for phishing domains with cPanel certiﬁcates (black). The

month of the discovery of several critical vulnerabilities is

displayed in red.

now-defunct CAs. Figure 5 shows the distribution of

the month of issuance of certiﬁcates for the three do-

main types. The ﬁgure shows that the vast majority of

certiﬁcates are issued after 2018 and that there is no

major difference between the domain types, suggest-

ing that the age of Let’s Encrypt does not play a large

role in the issuer preference.

The issuer preference provides information re-

garding the infrastructure used to serve services us-

ing popular domains, of which the high preference for

the Amazon issuer by popular domains (5.91%, or the

third-most preferred issuer) is an example. Amazon

issues public certiﬁcates for customers of their AWS

cloud platform, which speciﬁcally focuses on “secur-

ing public websites with signiﬁcant trafﬁc require-

ments”

, indicating that part of the infrastructure of

popular domains with such certiﬁcates operates on

AWS. Similarly, we ﬁnd that phishing domains have a

strong preference for the cPanel issuer (33.53%) com-

pared to popular (1.23%) and non-popular (10.69%)

benign domain types. cPanel is a popular web host-

ing platform with the option for automatic issuance

and deployment of TLS certiﬁcates. We hypothesize

that either (1) phishers rely on cPanel for their host-

https://docs.aws.amazon.com/acm/latest/userguide/acm-

overview.html

ing infrastructure on a large scale, or (2) that cPanel

accounts are compromised at a large scale and repur-

posed for conducting phishing attacks. Under the as-

sumption that the second hypothesis can only occur

on a large scale in case of the discovery of a criti-

cal vulnerability, we would expect to see a peak of

submissions of phishing URLs on the eCX for do-

mains running cPanel software, as cPanel hosts are

compromised around the time of the vulnerability dis-

closure. Several critical vulnerabilities were reported

for cPanel in September 2019

, but according to Fig-

ure 6 this did not coincide with unusual numbers of

related URLs being reported. We have found no evi-

dence of peaks of URL submissions for phishing do-

mains running on cPanel software, suggesting that the

ﬁrst hypothesis holds true, but this requires further re-

search to conﬁrm.

5.3 Validation Level

In addition to the CA selection, the selection of a val-

idation level provides insight in the monetary invest-

ment in conducting phishing attacks, which leads to

the following hypothesis:

Hypothesis 3. Phishers resort to certiﬁcates with

higher validation levels to increase the perceived le-

gitimacy of phishing websites.

Similar to the issuer analysis, the analysis of vali-

dation level differences requires a normalization step

taking into account the number of certiﬁcates and the

validity duration of certiﬁcates. The set of all certiﬁ-

cates issued for domain d

with a validation level l

denoted as C

val

, l

). The set of possible validation

levels (i.e., DV, OV, EV, and unknown) is denoted as

L. The domain validation level preference P

val

, l

)

We used a CVE record with a score of 8 or higher as

the deﬁnition of a critical vulnerability, obtained from

https://www.cvedetails.com/vulnerability-list/vendor id-

1766/product id-3023/Cpanel-Cpanel.html

Can a TLS Certiﬁcate Be Phishy?

Table 3: Values of P

val

(D, l) for all domain categories and

validation levels (as percentage).

↓ D → l DV OV EV Unknown

phish

92.94 6.65 0.11 0.31

pop

49.41 39.17 4.03 7.38

nonpop

91.99 7.28 0.14 0.59

represents how much a particular validation level is

preferred by a speciﬁc domain:

val

, l

) =

∑

c∈C

val

)

v(c)

∑

l∈L

∑

c∈C

val

,l)

v(c)

(3)

Again, v(c) denotes the duration of the validity period

of certiﬁcate c, and this measure is a value between

one and zero, and

∑

l∈L

val

, l) = 1. Then, the do-

main type validation level preference for each of the

domain categories D

(i.e., D

phish

, D

pop

and D

nonpop

for phishing, popular and non-popular sampled do-

mains respectively) for a speciﬁc validation level l

deﬁned as follows:

val

, l

) =

∑

d∈D

val

(d, l

)

∑

l∈L

∑

d∈D

val

(d, l)

(4)

We rely on the reported validation levels from the

Censys dataset

to compute the preferences. Table 3

shows the results of the computation of these values,

for all domain type and validation level combinations.

Unsurprisingly, popular domains have a stronger pref-

erence for OV and EV certiﬁcates, as popular domains

have a larger incentive and budget for protecting the

legitimacy of their brand. Phishing and non-popular

benign domains have a highly similar preference.

Notably, we identiﬁed 133 EV certiﬁcates issued

for 16 unique phishing domains. Further inspection

shows that only two of those 16 domains are marked

by VirusTotal as malicious, questioning whether the

other 14 are really phishing domains in the ﬁrst place.

As such, we conclude that EV certiﬁcates are vir-

tually unused by phishers in our dataset, and this

suggests that EV certiﬁcates are in fact a meaning-

ful method for marking websites as trustworthy, even

though browsers stopped presenting such indicators

to users.

5.4 Certiﬁcate Sharing

Based on the following hypothesis, there is an ex-

pectation that phishing domains may be deployed on

We veriﬁed the correctness of these values by computing

a validation level based on the existence of speciﬁc Object

Identiﬁers (OIDs) in the X.509 certiﬁcate extensions and

matching those against the Censys values. Our method in

general led to more inconclusive results.

Figure 7: ECDF of the number unique roots of certiﬁcates

covering at least a single phishing domain (n = 975, 426).

The red line represents the fraction of covering only a single

unique root domain.

a shared infrastructure, which would be reﬂected by

shared certiﬁcates, or certiﬁcates that cover more than

a single phishing domain.

Hypothesis 4. Individual phishing attacks may be

part of a larger campaign, and the deployment of

those attacks is coordinated.

In order to test this hypothesis, we collect all certiﬁ-

cates in our dataset that cover at least a single phishing

domain. Note that we consider all phishing domains,

not only the 10,000 domains in the initial sample. In

total, 975k certiﬁcates were identiﬁed. For each cer-

tiﬁcate, we extract the unique root domains, and the

ECDF of the count is shown in Figure 7. 37.57% of

certiﬁcates issued for phishing domains cover only

a single unique root, indicating that the remaining

62.43% (or 608,934 certiﬁcates) is potential evidence

that certiﬁcate sharing is rampant in phishing attacks.

Surprisingly, only 0.90% (or 5,452) of these cer-

tiﬁcates cover only phishing roots, meaning that the

remaining certiﬁcates cover not only phishing roots,

but also domains of unknown nature. The implica-

tion of this is that there is a small portion of certiﬁ-

cates that can be considered unambiguously ‘phishy’,

whereas the vast majority of certiﬁcates cannot. The

existence of these ‘ambiguous’ certiﬁcates could be

interpreted in several ways, including:

1. Certiﬁcates are requested by a third party to which

domain control is delegated by the actual owner,

and this third party requests certiﬁcates that cover

benign and phishing domains.

2. There exists a vast number of domains that have

not yet been discovered to be phishing domains,

which means that in reality these ambiguous cer-

tiﬁcates are in fact ‘phishy’.

3. Not all domains owned by a particular domain

owner are used for phishing attacks. This in-

cludes for example benign domain owners whose

websites are hacked and repurposed for phish-

ing attacks, or phishers who manage domains for

non-phishing activities, and domains with user-

generated content of mixed nature.

We investigate the ﬁrst point through a case study:

SECRYPT 2021 - 18th International Conference on Security and Cryptography

Cloudﬂare. Cloudﬂare’s Content Delivery Net-

work (CDN) enables customers to encrypt trafﬁc to

their websites by proxying trafﬁc through Cloudﬂare

servers. This requires them to change the DNS name

server of their domain to Cloudﬂare, effectively del-

egating the control of their DNS conﬁguration to

Cloudﬂare, which is used by the ACME protocol to

verify the ownership of domains. Rather than re-

questing a single certiﬁcate for each domain, a sin-

gle certiﬁcate is requested for a set of domains, all

from different owners. In addition, these certiﬁ-

cates contain a Cloudﬂare-speciﬁc domain (usually

the ﬁrst domain name in the list of SANs), matching

the structure sni{6 digits}.cloudflaressl.com.

Naturally, none of these certiﬁcates can unambigu-

ously be assumed to be phishy, as they cover do-

mains from many different owners. This set of Cloud-

ﬂare certiﬁcates alone already comprises 91.369 cer-

tiﬁcates, or 9.37% of the full set of certiﬁcates is-

sued for phishing domains. We identiﬁed other sim-

ilar certiﬁcate structures to Cloudﬂare certiﬁcates,

that include SANs such as statuspage.io and

incapsula.com, leading us to believe that those do-

mains are used for similar purposes as the sni{6

digits}.cloudflaressl.com domains. Further re-

search is needed to fully differentiate ‘phishy’ certiﬁ-

cates from these CDN-type certiﬁcates.

6 DISCUSSION

The fact that between 56.13% and 75.66% of phish-

ing domains observe a relevant certiﬁcate being is-

sued before a URL is blacklisted is a promising result

and a strong motivation for pursuing the development

of CT log-based abuse prevention systems (accepting

Hypthesis 1). Given the constant growth of phish-

ing attacks being conducted over HTTPS (over 84%

of identiﬁed phishing attacks in the last quarter of

2020 according to the APWG (Anti-Phishing Work-

ing Group, 2021), compared to only 10% in the ﬁrst

quarter of 2017), CT log’s early coverage of phish-

ing domains is only expected to grow in the future.

Simultaneously, the introduction of more trafﬁc en-

cryption methods, such as ECN

could render pas-

sive measurements less effective, emphasizing the rel-

evance of CT logs even more.

We have demonstrated that phishing domains and

non-popular benign domains have similar preference

proﬁles for the issuer selection of their certiﬁcates

(except cPanel), but a vastly different proﬁle com-

pared to popular domains. Our results provide some

https://tools.ietf.org/html/draft-ietf-tls-esni-10#page-6

insight in the operations of phishing domains (e.g.,

preference for cPanel), thereby we accept Hypothe-

sis 2. Further research is required to draw stronger

conclusions regarding the domains relying on cPanel,

but these results emphasize the importance of the po-

sition of CAs in the ﬁght against phishing. CAs have

the opportunity to interfere with the TLS ecosystem

through the revocation of certiﬁcates and in fact some

CAs state in their policies that malicious activity is

grounds for certiﬁcate revocation

. Although the ef-

fectiveness of certiﬁcate revocation have historically

been limited (Liu et al., 2015), our results are an ar-

gument for better handling of certiﬁcate revocation.

Our results for the validation level of certiﬁcates

show that phishers rarely resort to EV certiﬁcates

(thereby rejecting Hypothesis 3). Given the rela-

tively high cost of OV and EV certiﬁcates ($27.44 and

$72.18 per year at COMODO respectively for exam-

ple

), this suggests phishers are not willing to signiﬁ-

cant amounts of money, or are actually rejected during

the vetting process. Even though browser indicators

have been demonstrated to be ineffective from the per-

spective of users (Thompson et al., 2019), higher val-

idation levels could be an effective signal for identi-

fying certiﬁcates that are not used in phishing attacks.

EV certiﬁcates could act as a white-listing method for

identifying ‘benign’ certiﬁcates.

Lastly, we found few unambiguous cases of

shared certiﬁcates between phishing domains, with

5,452 certiﬁcates only covering phishing domains.

The vast majority of certiﬁcates that cover at least a

single phishing domain also covers domains whose

nature is unknown, which makes it difﬁcult to extract

meaningful information from the certiﬁcates about

the decisions of the phishers. A substantial part of

this challenge can be explained by the practice of do-

main owners delegating control to CDNs, which ag-

gregate many domains from many owners, and ob-

tain certiﬁcates covering many domains of various

types, including phishing. We found that 9.37% of

the phishing domains had been mixed with other do-

mains by Cloudﬂare, and indications that other CDNs

apply similar practices. Consequently, CDNs have a

role and a responsibility in the ﬁght against phishing,

when they offer the service of managing certiﬁcates,

and in general when applying practices that allows

phishers to mix with benign domain owners. We can-

not reject nor accept Hypothesis 4, which remains in-

conclusive.

This work provides preliminary characteristics of

Example of Sectigo: https://sectigo.com/uploads/ﬁles/

Sectigo-CPS-v5 2 2.pdf

https://comodosslstore.com/resources/dv-vs-ov-vs-ev-

ssl-which-certiﬁcates-are-good-for-site-security/

Can a TLS Certiﬁcate Be Phishy?

phishing certiﬁcates, suggesting that a there is a cer-

tain degree of ’phishiness’ that can be assigned to a

certiﬁcate. Even a simple-heuristics based warning

system can potentially be useful for identifying can-

didate phishing domains, by for example identifying

cPanel certiﬁcates covering several domains, includ-

ing a domain that previously already was blacklisted

by the eCx.

Limitations. Our methodology differentiates be-

tween three domain types, and considers phishing do-

mains a homogenous group of domains registered for

phishing purposes. Even though we accounted for

domain ownership changes in the collection of cer-

tiﬁcate for phishing domains, we do not address the

potential of domain compromise. Marooﬁ et al. (Ma-

rooﬁ et al., 2020) manually collected a dataset of

phishing URLs and identiﬁed 58% to be maliciously

registered and 42% to be compromised. This implies

that there is a likelihood that our analysis of phish-

ing domains leads to conclusions for compromised

domains, rather than maliciously registered domains.

Identifying whether a domain is compromised in itself

is already a challenging task, which is signiﬁcantly

more difﬁcult with historical data, where the website

may not be online anymore.

It is possible that the domain type samples contain

false positives of domains that in reality are placed in

the wrong class. One cause of this could be the (lack

of) vetting of URLs in the eCX platform, which could

result in URLs submitted to the platform that are in

reality not phishing URLs. In addition, it is unlikely

that the eCX URLs are fully complete, covering every

phishing URL in existence, as not all phishing attacks

are detected and reported. Additionally, the eCX re-

lies on member contributions, and these are unlikely

to be fully complete. As a result, there are likely to

be domains in the non-popular domain set that are in

reality phishing domains. Unfortunately, this is a core

limitation of the CT framework for phishing preven-

tion, as TLS certiﬁcates are issued on a domain basis

instead of on a URL basis.

7 CONCLUSIONS

This paper addresses the potential of using the phishi-

ness of digital certiﬁcates as a method to identify

phishing domains early in their lifecycle. By com-

paring the certiﬁcates issued for three distinct domain

sets, we identify relevant patterns in the differences

across these domain sets. Firstly, our temporal anal-

ysis shows that for 56.13% to 75.66% of phishing

domains, a certiﬁcate is issued before the domain is

being blacklisted, indicating the scale at which CT-

based mitigation can protect against phishing. Fur-

thermore, our results show that phishing domains re-

sort to a relatively small group of issuers, particularly

gravitating to cPanel, which emphasizes that stronger

adherence to certiﬁcate revocation lists produced by

these issuers can be highly valuable. We have also

shown that phishers are unlikely to resort to (expen-

sive) EV certiﬁcates, which could suggest that do-

mains that do employ them could serve as a whitelist

for non-phishing domains. Lastly, we found that cer-

tiﬁcates are unlikely to be unambiguously phishy or

benign, given the set of phishing domains they en-

compass. Although we identiﬁed only a few certiﬁ-

cates that only cover phishing domains, the majority

of certiﬁcates issued for phishing domains cover mul-

tiple phishing domains, which is a hopeful takeaway.

These results led us to provide several suggestions for

changes to the TLS ecosystem.

Our work opens up several pathways for future

work. Firstly, given the preliminary nature of our re-

sults, we encourage the research community to inte-

grate our results in novel or existing domain classi-

ﬁcation methods. An alternative promising direction

is the disambiguation of certiﬁcates, which - if suc-

cessful - could lead to a very effective way to propa-

gate the ‘phishiness’ of a certiﬁcate to all the domains

it covers. Additionally, the potential impact of CAs

(cPanel in particular) and certiﬁcate revocation could

be explored in more detail.

ACKNOWLEDGEMENTS

This research is carried out under the SecDNS project,

funded by Innovation Fund Denmark. We thank Cen-

sys.io for sharing their CT log data with us, and we

are thankful for the APWG for granting us access to

their eCX platform.

REFERENCES

Aertsen, M., Korczy

nski, M., Moura, G. C. M., Tajal-

izadehkhoob, S., and van den Berg, J. (2017). No

domain left behind: is let’s encrypt democratizing en-

cryption? In Proceedings of the Applied Networking

Research Workshop. ACM.

Anti-Phishing Working Group (2021). Phishing Activity

Trends Report - 4th Quarter 2020. https://docs.apwg.

org/reports/apwg

trends report q4 2020.pdf. Ac-

cessed: 2021-02-12.

Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,

J., and Wright, T. (2003). Transport layer security (tls)

SECRYPT 2021 - 18th International Conference on Security and Cryptography

extensions. RFC 3546, RFC Editor. Accessed: 2021-

02-12.

CA/Browser Forum (2020). Baseline requirements for the

issuance and management of publicly-trusted certiﬁ-

cates (version 1.7.3). Technical report, CA/B Forum.

Accessed: 2021-02-08.

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Hous-

ley, R., and Polk, W. (2008). Internet X.509 Pub-

lic Key Infrastructure Certiﬁcate and Certiﬁcate Re-

vocation List (CRL) Proﬁle. RFC 5280, RFC Editor.

http://www.rfc-editor.org/rfc/rfc5280.txt.

Durumeric, Z., Adrian, D., Mirian, A., Bailey, M., and Hal-

derman, J. A. (2015). A search engine backed by

internet-wide scanning. In Proceedings of the 22nd

ACM SIGSAC Conference on Computer and Commu-

nications Security, pages 542–553. ACM.

Fasllija, E., Enis¸er, H. F., and Pr

unster, B. (2019). Phish-

hook: Detecting phishing certiﬁcates using certiﬁcate

transparency logs. In Lecture Notes of the Institute for

Computer Sciences, Social Informatics and Telecom-

munications Engineering, pages 320–334. Springer

International Publishing.

Hao, S., Kantchelian, A., Miller, B., Paxson, V., and

Feamster, N. (2016). PREDATOR: Proactive Recog-

nition and Elimination of Domain Abuse at Time-

Of-Registration. In Proceedings of the 2016 ACM

SIGSAC Conference on Computer and Communica-

tions Security, pages 1568–1579. ACM.

Hao, S., Thomas, M., Paxson, V., Feamster, N., Kreibich,

C., Grier, C., and Hollenbeck, S. (2013). Under-

standing the domain registration behavior of spam-

mers. In Proceedings of the 2013 Conference on Inter-

net Measurement Conference, IMC ’13, page 63–76,

New York, NY, USA. Association for Computing Ma-

chinery.

Holz, R., Amann, J., Razaghpanah, A., and Vallina-

Rodriguez, N. (2019). The era of TLS 1.3: Measuring

deployment and use with active and passive methods.

CoRR, abs/1907.12762.

Lastdrager, E. E. (2014). Achieving a consensual deﬁni-

tion of phishing based on a systematic review of the

literature. Crime Science, 3(1).

Lauinger, T., Chaabane, A., Buyukkayhan, A. S., Onarli-

oglu, K., and Robertson, W. (2017). Game of reg-

istrars: An empirical analysis of post-expiration do-

main name takeovers. In 26th USENIX Security Sym-

posium (USENIX Security 17), pages 865–880, Van-

couver, BC. USENIX Association.

Lever, C., Walls, R., Nadji, Y., Dagon, D., McDaniel, P.,

and Antonakakis, M. (2016). Domain-z: 28 registra-

tions later measuring the exploitation of residual trust

in domains. In 2016 IEEE Symposium on Security and

Privacy (SP), pages 691–706. IEEE.

Liu, Y., Tome, W., Zhang, L., Choffnes, D., Levin, D.,

Maggs, B., Mislove, A., Schulman, A., and Wilson,

C. (2015). An end-to-end measurement of certiﬁ-

cate revocation in the web’s pki. In Proceedings of

the 2015 Internet Measurement Conference, IMC ’15,

page 183–196, New York, NY, USA. Association for

Computing Machinery.

Manousis, A., Ragsdale, R., Drafﬁn, B., Agrawal, A., and

Sekar, V. (2016). Shedding light on the adoption of

let’s encrypt.

Marooﬁ, S., Korczynski, M., Hesselman, C., Ampeau, B.,

and Duda, A. (2020). COMAR: Classiﬁcation of com-

promised versus maliciously registered domains. In

2020 IEEE European Symposium on Security and Pri-

vacy (EuroS&P). IEEE.

Moura, G. C. M., Muller, M., Wullink, M., and Hesselman,

C. (2016). nDEWS: A new domains early warning

system for TLDs. In NOMS 2016 - 2016 IEEE/I-

FIP Network Operations and Management Sympo-

sium, pages 1061–1066. IEEE.

Pochat, V. L., Goethem, T. V., Tajalizadehkhoob, S., Ko-

rczynski, M., and Joosen, W. (2019). Tranco: A

research-oriented top sites ranking hardened against

manipulation. In Proceedings 2019 Network and Dis-

tributed System Security Symposium. Internet Society.

Prins, J. (2011). DigiNotar Certiﬁcate Author-

ity breach “Operation Black Tulip”. https:

//media.threatpost.com/wp-content/uploads/sites/

103/2011/09/07061400/rapport-fox-it-operation-

black-tulip-v1-0.pdf. Accessed: 2021-02-12.

Razaghpanah, A., Niaki, A. A., Vallina-Rodriguez, N., Sun-

daresan, S., Amann, J., and Gill, P. (2017). Study-

ing TLS usage in android apps. In Proceedings of the

13th International Conference on emerging Network-

ing EXperiments and Technologies, pages 350–362.

ACM.

Sakurai, Y., Watanabe, T., Okuda, T., Akiyama, M., and

Mori, T. (2020). Discovering HTTPSiﬁed phishing

websites using the TLS certiﬁcates footprints. In 2020

IEEE European Symposium on Security and Privacy

Workshops (EuroS&PW), pages 522–531. IEEE.

Scheitle, Q., Gasser, O., Nolte, T., Amann, J., Brent, L.,

Carle, G., Holz, R., Schmidt, T. C., and W

ahlisch, M.

(2018). The rise of certiﬁcate transparency and its im-

plications on the internet ecosystem. In Proceedings

of the Internet Measurement Conference 2018, IMC

’18, page 343–349, New York, NY, USA. Association

for Computing Machinery.

Thompson, C., Shelton, M., Stark, E., Walker, M.,

Schechter, E., and Felt, A. P. (2019). The web’s iden-

tity crisis: understanding the effectiveness of website

identity indicators. In 28th {USENIX} Security Sym-

posium ({USENIX} Security 19), pages 1715–1732.

VanderSloot, B., Amann, J., Bernhard, M., Durumeric, Z.,

Bailey, M., and Halderman, J. A. (2016). Towards a

complete view of the certiﬁcate ecosystem. In Pro-

ceedings of the 2016 Internet Measurement Confer-

ence, IMC ’16, page 543–549, New York, NY, USA.

Association for Computing Machinery.

Zhang, L., Choffnes, D., Levin, D., Dumitras¸, T., Mislove,

A., Schulman, A., and Wilson, C. (2014). Analysis

of ssl certiﬁcate reissues and revocations in the wake

of heartbleed. In Proceedings of the 2014 Conference

on Internet Measurement Conference, IMC ’14, page

489–502, New York, NY, USA. Association for Com-

puting Machinery.

Can a TLS Certiﬁcate Be Phishy?