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.1 or greater should be maintained.
- Server-to-Server Email: For domains sending or receiving email, TLS v1.1 or greater must be offered at the highest priority. However, when exchanging mail with out-of-zone domains earlier versions of TLS/SSL are permitted, including, as the lowest priority, defaulting to unencrypted email when it is not possible to provide encryption.
- Other Services: TLS v1.1 or greater should be used and TLS v1.0 does not need to be disabled at this time.
- 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, CBC, DES, 3DES, FIPS, GOST 28147-89, IDEA, SEED, WITH_SEED, MD5, NULL, SHA (SHA1), RC4, EXPORT, EXPORT1024 and SRP.
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.1 or greater. Any ports not offering services should be closed.
STARTTLS: is an open protocol 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 older plaintext protocols to an encrypted, TLS-based connection. The advantage of STARTTLS is that it is an open standard and extensions are provided for in email (in RFC 2595 and RFC 3207), instant messaging and presence (in RFC 6120), and directory services (in RFC 2830).
Today most mainstream providers of services—especially email and file transfer—employ STARTTLS as the alternative to these legacy approaches. For instance, Google has a real-time report on email encryption available HERE.
Commercial software supporting these internet services widely supports STARTTLS. 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. Only in extraordinary cases, such as when sending emails to legacy domains (e.g.,.com), should transmissions default back to plaintext. STARTTLS should always be attempted, but some connections will not support TLS. However, since all modern browsers support strong encryption, there should not be a fallback for HTTP connections.