4. Ensure TLS v1.2 or greater has been implemented where required

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.

GET HELP

• Webhosting Companies  .BANK | .INSURANCE
• Certificate Authority (e.g.)
  • Let’s Encrypt
  • Comodo
  • DigiCert
  • EnTrust
  • GlobalSign
  • IdenTrust
• Check with Your Registrar
• Email Provider

 
ADDITIONAL REQUIREMENT DETAIL

1. Web Connections: TLS v1.2 or greater must be implemented and TLS v1.0 must be disabled.
2. 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.
3. Other Services: TLS v1.2 or greater must be implemented and TLS v1.0 must be disabled.
4. 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.

CBC¹: 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:

Port  Service

• 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.

¹ 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.

ADDITIONAL RESOURCES

• Full fTLD TLS v1.2
  Documentation
  
• Wireshark: The world’s foremost and widely-used network protocol analyzer, can be implemented to detect which version(s) of TLS are employed by tools/integrations on your website.