TLS stands for Transport Layer Security. TLS is an open standard for encryption that makes it possible for people and applications to communicate in private over the internet. When a client and server communicate, TLS is used to ensure the messages passed between them cannot be read or changed during the transmission. TLS is the successor to a technology called Secure Sockets Layer (SSL) and it provides three essential services to help ensure security on the internet:
- Message Confidentiality—TLS provides a mechanism for encrypting the messages between application clients and servers with the aim of ensuring that, even if someone captures the messages as they were in transit between the sender and destination, the messages could not be read.
- Authentication—TLS provides a mechanism to validate the identity of the endpoints of the communications. Servers authenticate themselves to clients and clients, optionally, authenticate themselves to servers.
- Message Integrity—TLS provides a mechanism to ensure that messages are not changed as they move between client and server.
TLS is often associated with protecting the contents of messages, but the protocol is also very useful in protecting against threats such as masquerade attacks, man-in-the-middle or bucket brigade attacks, rollback attacks and replay attacks.
What are the fTLD Domain Security Requirements for TLS?
There are three requirements that reference TLS/encryption:
- Registrar and Registrant access to registration systems must be mutually authenticated via Transport Layer Security and secured with multi-factor authentication, NIST Level 3 or better.
- Registration Authorities and Registrants are required to use encryption practices defined by NIST Special Publication 800-57, or its successor, for all electronic communication between parties, including but not limited to web access, mail exchange, and file transfer, avoiding the use of unencrypted protocols to prevent tampering with messages.
- Transport Layer Security (the successor to SSL) must be implemented as defined in the requirement.
- Ensure that message confidentiality and integrity is part of the authentication process for access to registration systems.
- Ensure the benefits of TLS are present in all interactions between registries-registrars, registrars-registrants and registrants and their customers including email and web interactions.
- Specify the TLS protocol version and related cipher prohibitions.
An fTLD Domain is an HTTPS-only community to support confidentiality and integrity of web and other services by default. Public key certificates must be deployed to meet the TLS/encryption requirement.
As .BANK is on the HSTS preload list, domains that are not HTTPS compliant will not be accessible via browsers (like Chrome) following this list. As a global HSTA security policy becomes increasingly common, additional browsers are expected to block sites that are not HTTPS compliant.
How Does TLS Work?
TLS is built from a pair of protocols: the “record” protocol and the “handshake” protocol. Fundamentally, TLS exchanges records—the content and formatting of those records being agreed at the start through a “negotiation” between client and server. The content of those records may be control messages for TLS, the actual encrypted content flowing between both parties and a variety of other information. The TLS Record Protocol provides connection security that has two basic properties:
- The connection is private. Every message between two endpoints is secured by encryption. A shared secret is used for the message encryption. The shared secret is generated uniquely for each connection between the two endpoints and is based on the results of another protocol (often the TLS Handshake Protocol).
- The connection is reliable. Every message has a checksum applied so that the receiving end can always check to see if the message that was received is identical to the message that was sent.
The shared secret is important because symmetric cryptography is significantly faster than public key cryptography. However, the shared secret is a problem because both endpoints need to know the same shared secret to exchange messages; this is where the TLS Handshake Protocol plays a role. The TLS Handshake Protocol provides connection security between two endpoints on the internet, and has the following three properties:
- Each end of the communications channel can be authenticated (that is, they can be forced to prove that they are who they say they are). This authentication takes place using public key cryptography. In traditional web applications only the server is authenticated.
- The negotiation of a shared secret is secure. The secret that is generated and shared (to be used by the Record Protocol) is impossible for an eavesdropper to obtain. The shared secret cannot be discovered, even by attackers who place themselves in the middle of the session.
- The negotiation is reliable. If an attacker attempts to insert themselves into the negotiation process, they can be discovered by the peers during the negotiation.
The combination of the negotiated secret provided by the TLS Handshake Protocol and the symmetric cryptography and check-sums provide a secure communications channel for any application layer protocol on the internet (e.g., World Wide Web, email, VoIP). The handshake is essential to TLS, and fairly complex. The following overview describes the handshake when both ends of the connection must authenticate themselves to one another.
- The client begins the handshake by sending an initial message to the server indicating the highest version of the TLS protocol that it supports, a list of cryptographic suites it supports, a list of message compression methods it supports and a random number.
- The server responds:
- First, with a message with the highest version of the TLS protocol that the two sides have in common, the best of the cipher suites that the two have in common, the most efficient compression methodology that both support and a random number.
- Second, it sends the server’s Digital Certificate.
- Third, it sends the public key for the server.
- Fourth, it requests that the client send a copy of the client’s Digital Certificate.
- Fifth, it sends a short message to indicate that it is done with this part of the negotiation.
- The client then responds:
- First, with a copy of its Digital Certificate.
- Second with a message containing the public key of the client.
- Third, the client uses its private key to sign the previous handshake messages.
- This signature can be verified as authentic by checking it using the client’s certificate’s public key. This proves that the client has access to the private key of the certificate and thus owns the certificate.
- The server and client then send messages using the random numbers that have been exchanged to generate a common secret. For the remainder of this connection, all cryptographic material is generated from this common secret.
- Once the common secret has been generated the client sends a message to the server telling the server that all future communications sent to the server will be authenticated and encrypted.
- The client sends a last message indicating that its part of the handshake is complete.
- The server decrypts the last message of the client (if the decryption fails, the handshake is considered to have failed).
- The server sends a message to the client telling the client that all future communications sent to the client will be authenticated and encrypted.
- The server sends a last message indicating that its part of the handshake is complete.
- The client decrypts and verifies the last message from the server.
- The handshake is successful, and the application continues with all messages encrypted identically to its “last messages” in the handshake.
TLS is a powerful tool for ensuring secure channels of communications. However, there are known attacks on the protocol and every security professional working with an fTLD Domain should be aware of the known vulnerabilities of TLS. Details are beyond the scope of this document, but a summary is available here: https://tools.ietf.org/html/rfc7457.
Crucial to the handshake is the availability of a digital certificate. Digital certificates are files with a specific, standardized format which attests to the identity of an entity. That entity could be nearly anything such as a person, a named user, a server, a smartphone or a program on a client. Inside the certificate, along with the attestation of identity, is the public key. Here’s what a sample certificate looks like:
When using TLS, each side of the connection can use the digital certificate to try to validate its contents and the claim of identity for the entity. One of the fields that is often used for this is called the “Common Name.” Each side of the conversation can check the Common Name against what they expect. They can also check the expiration date of the certificate. Especially useful in these circumstances, both sides can check who issued the certificate. Digital certificates are issued by Certificate Authorities (CA). There are companies that offer a service to do validation of the identity information in the digital certificate and then issue certificates that they can confirm. These companies are often called Trusted Certificate Authorities. The real value of certificates appears when they come from a trusted source. Self-signed certificates should be avoided for web services and connections as they generate warnings in web browsers, which makes their authenticity less reliable.
TLS/Encryption for an fTLD Domain
The primary use for TLS in an fTLD Domain environment is in securing activity on the internet. The first requirement specifies that registrar and registrant access to registration systems must be mutually authenticated via TLS and secured with multi-factor authentication, NIST Level 3 or better.
When the registration system is an application running in cooperation with a web server, this implies that the clients and servers must have digital certificates, must support at least the TLS specified in the Requirements, and must be able to fully negotiate the handshake that sets up the secured session.
The second requirement specifies that all electronic communication between parties, including, but not limited to, web access, mail exchange, and file transfer, use encrypted protocols to prevent tampering with messages.
The third requirement specifies that TLS must be implemented using trusted protocol versions because some early implementations of TLS and some cipher suites supported by the protocol are known to be insecure. A public key certificate must be used to meet this requirement.
fTLD Domains must support the TLS specified in the Requirements. Changes to TLS protocols are ongoing and registrants should confirm the current requirement. Registrants and registrars will be notified of changes to any Requirements on a timely basis.
In addition, a series of cipher suites which are currently known to be insecure are not permitted for use with an fTLD Domain and are identified in the third requirement.
The steps required to implement TLS on a web server is discussed in the next section of this document. If the services are built to be used via a web browser, access through the https:// schema makes TLS implementation straightforward. Services built to be used through other tools, for instance through an iPhone, Android or Windows Phone app, need to use the secure transport APIs for the particular platform being targeted.
However, this does not prohibit an fTLD Domain from using content from other services. As an example, if an fTLD Domain incorporates information from a social media feed, the content from the social media may not originate or be hosted from an fTLD Domain service. It is acceptable to incorporate content from other sources in an fTLD Domain.
In addition to implementing TLS, registrars and registrants may choose to implement HTTP Strict Transport Security (HSTS). HSTS is effectively a backup for TLS. It was engineered to ensure that security remains intact even in the case of configuration problems and implementation errors. HSTS protection is simple to implement: you set a single response header in your websites. After that, browsers that support HSTS will enforce it. While the use of HSTS is not currently a requirement, it is strongly encouraged by fTLD and may become a requirement in the future.
Once implemented, HSTS does not allow any insecure communication with the website that uses it. It achieves this goal by automatically converting all plaintext links to encrypted ones. It also makes it harder for a user to click-through certificate errors and warnings which may be a leading indicator of a more significant problem such as malware or a man-in-the-middle attack (Certificate errors are a potential indicator of an active MITM attack. Studies have shown that almost all users click through these warnings without heeding them.).
TLS/Encryption Deployment for Registrars and Registrants
For an fTLD Domain, implementing TLS on web servers requires six primary steps:
- Generating a server certificate request file. A certificate request is essentially certificate data that has not been signed by a Certificate Authority (CA). The CA turns the request into a certificate by signing it. Building the certificate request file is a task that is specific to each operating system and web server. The end of the process is simply a file that will be transmitted to a Certificate Authority.
- Generating a server certificate. To submit your TLS server certificate request file to a Certificate Authority you must follow the enrollment instructions the CA provides. Most CAs publish their enrollment instructions on their website. Enrollment instructions vary among commercial CAs and for different server certificate types. The end of the process is a digital certificate signed by the CA and returned to your organization.
- Installing a server certificate on the web server. Most web servers and operating systems have Digital Certificate management and administration tools that allow you to install the new Digital Certificate on your server. Once the Digital Certificate has been installed the web server must be configured to use it as part of the TLS Handshake.
- Configuring TLS on a web server. Each web server hosting registration system will have to be configured to support the current version of the requirement. Details of configuration are specific to each web server and operating system, but often it consists of adding support via an included module or selection of a configuration option. Some examples of this are Microsoft IIS and Apache. fTLD Domain servers should also consider configuration of HSTS as a default response header.
- Generating, acquiring, and installing client certificates. As mutual authentication via TLS is required, client certificates are necessary for those computers on which browsers are accessing the registration system. The registrar must deploy a system for generation, acquiring and installing client certificates.
- Ensuring that TLS clients trust the CA certificate. This generally means making sure that the CA’s certificate is stored in the client’s trusted root certificate store.
In step 2, above, the Certificate Authority generates the Certificate used for TLS. The certificate is tied to a specific FQDN. fTLD suggests that registrars and registrants ensure that their certificates cover all the names to be used with a site. If the main domain name is going to be www.myexample.bank, you may also wish to have certificates configured for myexample.bank and other names which users might use (or, which your financial institution uses for brand recognition purposes); a wildcard certificate (e.g., *.myexample.bank) is one solution to cover every DNS name. A secure fTLD Domain web server should have a certificate that is valid for every DNS name configured to point to it. The goal is to avoid invalid certificate warnings at the browser, which will potentially confuse users and may weaken their trust. Once installed and configured, the server should be able to respond properly to client requests for TLS sessions. It is possible to test the configuration of the server and determine if the combination of the certificate installation and the server configuration has been successful. Several organizations provide free services to make this check such as:
- DigiCert® Certificate Inspector – https://www.digicert.com/cert-inspector.htm
- CheckTLS.com – https://www.checktls.com
- Wormly – https://www.wormly.com/tools
Encryption of Web, Mail and Other Service Ports
As an example, in the case of electronic mail, one approach for meeting this requirement (typically for legacy systems) is to implement implicit encryption via STARTTLS. STARTTLS is a protocol level command that improves upon plaintext protocols such as email and file transfer. 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.
An alternative, and typically preferred solution to STARTTLS is leveraging explicit encryption solutions. Internet standards bodies have designated certain ports to secure (TLS-based) services. This is an analog to HTTP and HTTPS. For instance,
- SMTP had a variant on port 465 for SMTPS
- POP3 had a variant on port 995 for POP3S
- IMAP had a variant on port 993 for IMAPS
- NNTP had a variant on port 563 for NNTPS
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/
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 an fTLD Domain should always attempt to have transmission encrypted. The only case where defaulting back to plaintext for transmission is in extraordinary cases: for instance, sending emails to legacy domains. In those cases 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 unencrypted HTTP connection.