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.
These requirements:
- 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.
