Assign this task
WHY THIS IS IMPORTANT
TLS creates an encrypted connection, protecting your website and visitors, securing email communications, and supporting the safe and secure transmission of personal information and financial transactions.
ADDITIONAL REQUIREMENT DETAIL
- Web Connections: TLS v1.2 or greater must be implemented and TLS v1.0 must be disabled.
- Server-to-Server Email: For domains sending or receiving email, TLS v1.2 or greater must be offered. Earlier versions of TLS/SSL are permitted, including defaulting to unencrypted email when it is not possible to provide encryption.
- Other Services: TLS v1.2 or greater must be implemented and TLS v1.0 must be disabled.
- RFC 5746 must be implemented (preventing a known man-in-the-middle attack).
The following non-exhaustive list of cipher suite components (authentication, encryption, message authentication code and key exchange algorithms) are excluded from use in-zone and in the generation of TLS certificates:
Anon, DES, 3DES, FIPS, GOST 28147-89, IDEA, SEED, WITH_SEED, MD5, NULL, SHA (SHA1), RC4, EXPORT, EXPORT1024 and SRP.
CBC1: fTLD recommends excluding Cipher Block Chaining (CBC) cipher suite components from use due to known vulnerabilities. Registrants can confirm their TLS with the public tools under Check Your Work below.
Only high encryption ciphers should be used; low and medium ciphers, which are equal to or less than 128 bits, must be disabled. High encryption ciphers are currently defined as those with key lengths larger than 128 bits, and some cipher suites with 128-bit keys, in accordance with the OpenSSL documentation available here: https://www.openssl.org/docs/man1.1.1/man1/ciphers.html. Specific definitions for low and medium cipher suites are also available in the OpenSSL documentation.
TLS Encryption on Ports for Web Services
Ensure the server for your .BANK or .INSURANCE domain is using the appropriate TLS versions on ports for web services by implementing STARTTLS with TLS v1.2 or greater. Any ports not offering services should be closed. The following is a list of the ports tested:
- 21 FTP
- 22 SSH
- 23 FTP
- 25 SMTP
- 80 HTTP
- 110 POP
- 143 IMAP
- 389 LDAP
- 443 HTTPS
- 500 ISAKMP
- 513 rlogin
- 514 rcmd
- 587 SMTP
- 636 LDAPS
- 993 IMAPS
- 995 POP3S
- 989 FTPS
- 990 FTPS
Today most mainstream providers of services—especially email and file transfer—employ clear text (unencrypted) communication only as a legacy approach. For instance, Google has a real-time report on email encryption available at: google.com/transparencyreport/saferemail/.STARTTLS: is a protocol level command that improves upon plaintext protocols such as email and file transfer, and if implemented for web services and server-server email will comply with this requirement. Essentially, STARTTLS provides a way to upgrade plaintext communications to an encrypted, TLS-based connection. The advantage of STARTTLS is that legacy services like email (in RFC 2595 and RFC 3207), instant messaging (in RFC 6120), and directory services (in RFC 2830) are supported.
Commercial software supporting these internet services widely support both implicit and explicit TLS implementations. As an example, Microsoft Exchange uses a feature called Opportunistic TLS that enables TLS by default for the server. This enables any sending system to encrypt the inbound SMTP session to Exchange. By default, Exchange 2013 also attempts TLS for all remote connections. Traffic should be encrypted as the default option. Services in the .BANK or .INSURANCE space should always attempt to have transmission encrypted. Defaulting back to plaintext for transmission should only occur in extraordinary cases: for instance, sending emails to legacy domains. STARTTLS should always be attempted before falling back to clear text. It should be noted email is not analogous to web traffic. All modern browsers support strong encryption; web servers should never downgrade to an unecrypted HTTP connection.
1 In 2013, researchers demonstrated a timing attack against several TLS implementations using the CBC encryption algorithm (see isg.rhul.ac.uk). Additionally, the CBC mode is vulnerable to plain-text attacks in TLS v1.0, SSL 3.0 and lower. A fix has been introduced with TLS v1.2 in the form of the GCM mode which is not vulnerable to the BEAST attack. GCM should be preferred over CBC and search for CBC here: https://ciphersuite.info/ to learn more.