One-Way and Mutual SSL/TLS Authentication
One of the defining features of the SSL/TLS protocol is its role in authenticating otherwise anonymous parties on computer networks (such as the internet). When you visit a website with a publicly trusted SSL/TLS certificate, your browser can verify that the website owner has successfully demonstrated control over that domain name to a trusted third-party certificate authority (CA), such as SSL.com. If this verification fails, then the web browser will warn you not to trust that site.
For most applications, SSL/TLS uses this sort of one-way authentication of a server to a client; an anonymous client (the web browser) negotiates an encrypted session with a web server, which presents a publicly trusted SSL/TLS certificate to identify itself during the SSL/TLS handshake:
CertificateRequest message to the client. The client will respond by sending a certificate to the server for authentication:
Client Authentication (1.3.6.1.5.5.7.3.2) Extended Key Usage (EKU) is installed on the client device. All of SSL.com’s Email, Client, and Document Signing certificates include client authentication.
Mutual Authentication Use Cases
Mutual TLS authentication can be used both to authenticate end-users and for mutual authentication of devices on a computer network.
User Authentication
Business and other organizations can distribute digital client certificates to end-users such as employees, contractors, and customers. These client certificates can be used as an authentication factor for access to corporate resources such as Wi-Fi, VPNs, and web applications. When used instead of (or in addition to) traditional username/password credentials, mutual TLS offers several security advantages:
- Mutual TLS authentication is not vulnerable to credential theft via tactics such as phishing. Verizon’s 2020 Data Breach Investigations Report indicates that almost a quarter (22%) of data breaches are due to phishing. Phishing campaigns are out for easily harvested credentials like website login passwords, not the private keys to users’ client certificates. As a further defense against phishing, all of SSL.com’s Email, Client, and Document Signing certificates include publicly trusted S/MIME for signed and encrypted email.
- Mutual TLS authentication cannot be compromised by poor password hygiene or brute force attacks on passwords. You can require that users create strong passwords, but how do you know they don’t use that same “secure” password on 50 different websites, or have it written on a sticky note? A 2019 Google survey indicates that 52% of users reuse passwords for multiple accounts, and 13% of users reuse the same password for all of their accounts.
- Client certificates offer a clear chain of trust, and can be managed centrally. With mutual TLS, verification of which certificate authority (CA) issued a user’s credentials is baked directly into the authentication process. SSL.com’s online management tools, SWS API, and access to standard protocols like SCEP make issuing, renewing, and revoking these credentials a snap!
SSL.com offers multiple options for issuance and management of client certificates:
- Individuals or organizations requiring only one or a few certificates may order Email, Client, and Document Signing certificates á la carte from SSL.com.
- With an Enterprise PKI (EPKI) agreement from SSL.com, organizations can issue client certificates to users in bulk.
- Protocols like SCEP, EST, and CMP can be used to automate client certificate enrollment and renewal for company-owned and BYO devices.
- For customers requiring a large quantity of certificates, wholesale discounts are available through our Reseller and Volume Purchasing Program.
Authentication of IoT Devices
Mutual TLS authentication is also widely used for machine-to-machine authentication. For this reason, it has many applications for Internet of Things (IoT) devices. In the world of IoT, there are many cases in which a “smart” device may need to authenticate itself over an insecure network (such as the internet) in order to access protected resources on a server.
Example: A “Smart” Thermostat
As a simplified example of mutual TLS for the IoT, we’ll consider a manufacturer who is designing an internet-connected “smart” thermostat for home use. Once connected to the internet in the customer’s home, the manufacturer would like the device to send and receive data to and from the company’s servers, so that customers can access temperature conditions and thermostat settings in their home through their user account on the company’s website and/or a smartphone app. In this case, the manufacturer could:
- Ship each device with a unique cryptographic key pair and client certificate. Because all communication will be between the thermostat and the company’s servers, these certificates may be privately trusted, offering additional flexibility for policies like certificate lifespan.
- Provide a unique device code (such as a serial number or QR code) that the customer can scan or enter into their user account on the manufacturer’s web portal or smartphone app to associate the device with their account.
Once the device is connected to the internet via the user’s Wi-Fi network, it will open a mutual TLS connection with the manufacturer’s server. The server will authenticate itself to the thermostat and request the thermostat’s client certificate, which is associated with the unique code entered by the user into their account.
The two parties to the connection (server and thermostat) are now mutually authenticated and can send messages back and forth with SSL/TLS encryption over application-layer protocols like HTTPS and MQTT. The user can access data from the thermostat or make changes to its settings with their web portal account or smartphone app. There is never any need for unauthenticated or clear-text messages between the two devices.
To speak with an expert about how SSL.com can help you secure your IoT devices and improve user security with mutual TLS, please fill out and submit the form below: