Report from the Data Protection and Identity Committee
In 2022, M3AAWG deployed a survey to its members to understand more about how their platforms employ Transport Layer Security (TLS), the protocol that protects data in transit between systems. Specifically, we were curious about what deployments look like today and what plans might be for the future. M3AAWG – and the Data & Identity Protection Committee in particular – want to utilize this data to better understand how to further educate members and how to plan sessions relating to TLS. Our questions primarily focused on older and insecure versions of TLS, though we also inquired about TLSv1.3 plans.
TLS is a linchpin of the Internet today and is used to secure everything from email messages in transit to e-commerce websites. Its predecessor, SSL, was introduced in 1994 to secure web browsing. TLSv1.0 was created in 1999 and superseded SSLv3.0. TLSv1.3 was released in August 2018. While the newer versions are more secure and use better technologies, the older versions have now been found to actually be insecure. The older versions, TLSv1.0 and TLSv1.1, have been deprecated by the IETF (RFC8996) and the NSA, NIST, CISA, and NCSC have all recommended they be disabled on all systems.
Approximately 75% of the respondents both send and receive mail. This is not limited to traditional Mailbox Providers (MBPs), as senders of transactional or marketing email (ESPs) also need to receive mail in various forms. Outbound mail may be of specific concern as it likely involves the transfer of user credentials. These are the systems where users login via SMTP to send email to recipients via a third-party or mobile email client.
Concentrating on outbound mail for a moment, nearly 60% of respondents support the use of third-party email clients when sending messages. These clients could be Outlook, Thunderbird, Apple Mail, or various mobile apps. For MBPs, this is pretty common as users enjoy having some level of control over their clients. Many platforms had been set up some time ago, and may still support legacy versions of TLS. When asking if platforms supported TLSv1.0 or TLSv1.1, more than 65% said their platforms did support the legacy versions, along with another 19% saying they were unsure. Unfortunately, only 14% said they did not offer these older versions. Sites such as https://testtls.com/ can be used to test TLS offerings by various sites. Some of these sites allow for specifying ports and protocols, making those sites a bit more useful.
Additionally, respondents were asked if they knew which versions were supported when supporting outbound via SMTP.
It’s surprising to see some systems are running “<TLSv1.0”, which would imply SSLv3 or lower. SSLv3 was declared deprecated by the IETF in June 2015 via RFC7568.
Understanding that there are a fair number of systems still using older versions of TLS (and SSL), it makes sense to be curious as to why systems may still be running these older versions.
Looking at a few of these:
- No perceived threat - It is encouraging to see very few respondents stating this as a big impediment. TLSv1.0 and TLSv1.1 have been shown to have a number of vulnerabilities. These can manifest as stolen data or Denial of Service attacks.
- Lack of support from vendors - This could mean that vendors don’t support TLSv1.2, or don’t support the option to disable older versions of TLS. It makes sense that only a few stated this, as TLSv1.2 was finalized in 2008.
- Too many people are still using it - The most prominent impediment. If we look at the majority of mobile and desktop operating systems, they’ve supported TLSv1.2 since 2015 or so. That means if these users are still using older clients, their operating system is likely no longer supported and subject to any number of other security issues.
It is understandable if there could be some trepidation on the part of the entity. It is likely valuable to do the research to understand the size of the problem, and be able to present that to executives. Based on responses, it does appear that groups are moving in that direction. More than 50% of respondents noted that their organization has initiated the process to stop using these legacy versions of TLS.
However, “gathering information” could lead to the decision to hold off any further action due to some of the hurdles mentioned above. Regardless, initiation of the process is good, and brings awareness to the organization. Even if now is not currently an acceptable time, the organization could revisit the initiative in the future, or create some campaign to help users understand the importance of staying current.
Many experts in the industry have advocated deprecating these older versions for quite some time. Interestingly, it seems that if there were a coordinated (and publicized) effort, then organizations believe they could rise to the occasion. When asked if they could eliminate the legacy versions of TLS within twelve months given an industry-wide endeavor, nearly two-thirds responded affirmatively.
Within M3AAWG, the Data & Identity Protection Committee has been advocating that entities stop using TLSv1.0 and TLSv1.1 for a few years. In order for sites to be able to adequately protect user credentials and data, systems must stop using the insecure versions of TLS, that is TLSv1.0 and TLSv1.1. This may temporarily inconvenience a few users if they have outdated devices, though the continued exposure of insecure protocols and devices could have more disastrous consequences including theft or loss of data, as well as false sense of security.
There have also been cursory discussions about something like a “STARTTLS Awareness Day”, where organizations temporarily change their TLS requirements in order to drive further adoption of better TLS usage patterns. That change could require TLSv1.2 or TLSv1.3, or could merely require that all communications utilize TLS (a small percentage of MTA-to-MTA traffic is still unencrypted). This could take the form of customer-facing, or MTA-to-MTA communications, or both. The point to drive home is that these poorly encrypted (and/or unencrypted) sessions are no longer acceptable. We (the collective ecosystem) are reaching a point where there is little if any reason to have unencrypted traffic between systems.
If there were an industry-wide initiative to end support for TLSv1.0/1.1 for email/web protocols, do you believe you could accomplish that task within 12 months?
Overall, it seems as though the respondents understood that dependencies on TLSv1.0 and TLSv1.1 need to end, and that it’s time to move on to TLSv1.2 and TLSv1.3. While it may take time to convince organizational leaders, the drive to better secure these types of connections is present. As first-adopters move forward with disabling TLSv1.0 and TLSv1.1 on various systems, this may give others the courage to move forward as a cohesive unit. That movement can benefit the entirety of the Internet by ensuring users have more up-to-date devices, and make us all a little safer.
Watch for updates on this blog about issues related to inbound TLS soon. Our best practices can be found here, https://www.m3aawg.org/blog.
Some additional references:
NIST: https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final
NCSC: https://www.ncsc.gov.uk/guidance/using-tls-to-protect-data