A first peek into .ie security status

.IE Tech
Cybersecurity
Data and analytics
by Sebastian Castro
21 Oct 2021

Our .ie database allows us to provide benchmarks and data on how Ireland is thriving online – in terms of website usage and cyber security.

In this blog, we have taken a deep look into a variety of metrics publicly visible for domains, focusing on web security (HTTPS) and email security.

Web security

For an initial assessment of web security in .ie, we’ll dig into the presence and settings of secure websites in .ie domains. We’ve collected this data using sslyze4, which implements a variety of tests against sites.

321,404 domains were covered by these tests at the beginning of October 2021.

Feel free to play around with this interactive visualisation and find the distribution of the different categories.

We have three high-level categories:

  • Domains not supporting HTTPS, where the probing failed for a number of reasons: DNS error, the server being probed rejected the connection, or timed out, or the security handshake failed. This represents 45.47% of the domains.
  • Domains supporting HTTPS, but will eventually fail if a user tries to use it because the domain is using self-signed certificates, or expired certificates. This represents 14.70% of the domains.
  • Domains with working HTTPS, with 39.82% of the domains. For this category, we explore the most relevant Certificate Authorities, with Let’s Encrypt taking the first spot with 51,732 domains or 40.4% of all .ie domains with working HTTPS. That’s a strong market position, and potentially a challenge considering the issues this CA had recently with the expiration of their root certificate.

Quality in web security

We focus only on websites with working HTTPS from now on, with a view on the quality of the site setup. For this, we’ll report on versions of SSL/TLS support by each domain, if the certificate public key is of good quality, and if there are options enabled that improve or undermine the security of the site. Our scanning tool allows testing for specific HTTPS vulnerabilities like HeartBleed, ROBOT or CRIME, but we decided not to use them to avoid being considered bad actors.

It’s refreshing to discover most of the domains support modern TLS versions like 1.2 and 1.3, but it’s concerning to observe domains supporting SSL 2.0 (73 domains) which was deprecated in 2011, domains supporting SSL 3.0 (708 domains) which was deprecated in 2015, and TLS 1.0 (40,923 domains) which was deprecated in March 2020. If we get pedantic, TLS 1.1 shouldn’t be supported as Firefox and Google Chrome stopped supporting them in 2020 as well. Unfortunately, supporting a certain protocol doesn’t guarantee that will be the preferred protocol. We discovered, to our disbelief, 1,451 domains presenting TLS 1.0 as the highest version supported, and one domain even presenting SSL 3.0. Those domains are showing a disregard for good security hygiene as best practices indicate the minimum should be TLS 1.2 and ideally TLS 1.3.

Each domain using HTTPS will require a certificate, which contains a public key. The algorithm and key size used for the public key is very important as it establishes how strong it is to factorization. Currently it’s common to find RSA and ECC keys, that have different key sizes. To be considered strong, an RSA key needs to be at least 2048 bits long, compared to an ECC key that needs to be at least 256 bits long.

We are happy to see there are no domains using weak keys in .ie – all domains are using what is considered as strong keys.

Moving into HTTPS capabilities that we would prefer not to see in .ie due to the risk of making domains vulnerable to attack, we observe the following two: TLS Compression, which potentially makes servers exposed to the exploits of CRIME and BREACH, and TLS Session Renegotiation. Considering both bugs were discovered back in 2010, 11 years after those shouldn’t be observable on the wider Internet, but unfortunately, we see them in the .ie namespace. There are a total of 18 domains affected by TLS compression, and 2,282 affected by TLS Session Renegotiation.

According to SSL Labs SSL and TLS Deployment Best Practices, there are a number of beneficial configurations a domain can have to produce a robust setup on secure websites. We already covered supported protocols and strong keys, but now we’ll touch on the newer recommended settings:

  • Use Strong Key Exchange, where the recommendation is to use ECDH Exchanges.
  • Use OCSP Stapling, an extension to OCSP Protocol where the server delivers information about the certificate revocation status.
  • Use HSTS (HTTP Strict Transport Security), where the webserver indicates to a browser using this header, any insecure communication won’t be allowed.
  • Use HPKP (HTTP Public Key Pinning), an HTTP header restricting which CAs can issue certificates.
  • Use CAA (Certificate Authority Authorization), a DNS record that signals which Certificate Authorities are allowed to issue certificates for the domain.
  • Use CSP (Content Security Policy), a mechanism that provides a policy to restrict mixed content (secure and insecure).

How is the support for these recommended practices in .ie?

HPKP is considered a complex solution where it’s easy to get it wrong, which could explain the low level of adoption with only three domains using it. Within good practices, using CAA is a better alternative to HPKP, and it seems to be the case with nearly 6,000 domains, representing 4.7% of the domains with secure websites. Content Security Policy is showing a shy 11.5% adoption, followed by HSTS with 21% and OCSP Stapling a 44.4% adoption. It’s good news to see strong support for ECDH Key Exchange.

Email security

By digging into the DNS (pun intended for the DNS geeks out there), we can discover if a domain has enabled a feature that makes email more secure against spoofing. We focus on three capabilities:

  • SPF, Sender Protection Framework, it’s a DNS record listing all IP addresses allowed to send an email for your domain. When enabled, this greatly reduces the ability for miscreants to spoof emails, making others believe your organisation sent certain emails asking for cash, for example.
  • DKIM, DomainKeys Identified Mail, is an email security standard that allows the detection of email forgery while messages travel between email servers. You can find a detailed explanation here.
  • DMARC, Domain-based Message Authentication Reporting and Conformance, is an email validation system designed to protect your email’s domain from being used in email spoofing. It joins forces with SPF and DKIM, and it can be seen as a third layer of protection.
  • MTA STS, Mail Transport Agent Strict Transport Security, is another DNS record signalling the use of TLS between mail servers when sending messages. If you want more information, please check here.

As it’s perfectly possible that one domain can enable SPF but not DKIM, for example, we have to explore all potential combinations. Let’s try to do this using a parallel categories plot.

You should be able to notice that the largest category is for domains not having any email security, with nearly 48% of the domains. SPF is the most popular of the adopted technology in our review, with 49% of the domains using it. Less than 1% of domains implement SPF, DKIM and DMARC together, and only 7 domains use all four capabilities. For this summary, we have validated and inspected each record, as it’s rather common to see our probing asking for SPF and receiving other kinds of records.

Looking into SPF, one basic component of the record indicates what should happen when the policy is violated: a tag -all will cause email to be rejected if coming from un-authorized source, and there are 39,669 domains using it, if the tag is ~all, signals a soft fail, non-authorized emails will be accepted but marked, there are 109,086 domains using it. If the tag is +all, allows any server to send emails for your domain, basically making the SPF record useless, and there over 100 domains that allow this behaviour.

Wrapping up

We are taking the first look at the use of security for email and websites in the .ie namespace. This allows us to identify each domain and their capabilities, and potentially, weaknesses. Our plan is to continue doing these collections on a regular basis so as to keep the community informed, with different level of details. In the future we will use these results to further engage with key stakeholders so as to help drive industry best practice when it comes to the .ie namespace and the usage of TLS within it, stay tuned!

Read more about the range of critical services we do which underpin the .ie namespace – Technical Services 

Sebastian Castro is our Data Scientist and leads our data analytics team.

Back To Top