Why Okta Verify protects your identity by pinning TLS connections

What is Public Key Pinning?

Normally, traffic between a client application and its server-side relies on Public Key Infrastructure (PKI). While this mechanism is sufficient for most internet traffic, the Okta Secure Identity Commitment requires us to consider advanced, persistent, targeted attackers, even including nation state-level actors.

Okta uses PKI and TLS as a baseline for all communication between services, including Okta Verify. In advanced attack scenarios, however, a public certificate outside Okta’s control could be compromised and accepted by a device’s operating system or explicitly trusted by the user of that device. In such cases, a threat actor can then inspect and manipulate the traffic between Okta Verify and Okta’s server-side endpoints via an attacker-in-the-middle (AITM) attack, which causes a number of problems we’ll explain later.

Public Key Pinning is a way to allow-list only the certificates expected by the client application, blocking all others. This means that even in the event of a public certificate authority compromise (e.g. Digicert), our client applications won’t accept those certificates. Instead, an attacker would have to have stolen Okta’s internally held private keys to impersonate our servers.

Attack example: Bogus WiFi or VPN

Imagine a user is working from a coffee shop. Another customer at the coffee shop has a pineapple in their backpack. This device can impersonate the shop’s WiFi and aggressively take over connections by faking high signal strength, among other clever tactics.

When a device connects to a WiFi network, it picks up network settings such as DNS and proxy settings, which allow it to route all traffic to itself before sending it to the proper destination. With an SSL certificate stolen from a third party (or accepted profile), even HTTPS traffic can be decrypted without raising an alarm.

Once this is in place, flows such as OpenID Connect become vulnerable to traffic rerouting,  which can cause access tokens to be stolen or set to another URL.

In the flow above, the following sequence occurs:

1. Okta Verify attempts to connect to the organization’s openid-configuration setup, which is required by the protocol spec.
2. The traffic is re-routed to the attacker’s infrastructure.
3. The values returned by the attacker’s infrastructure will change key parameters:
   1. Change keys_uri to the attacker’s keys endpoint. This allows the attacker to send JWTs, which will pass verification despite lacking legitimate private keys.
   2. Change endpoints such as token_endpoint that could cause token exchange flows defined by the standard to route to the attacker’s infrastructure (which can then be intercepted).
4. At this point, the attacker has significantly expanded the surface area, potentially leading to account takeover if combined with some type of phishing.

How pinning protects you

There are three main goals of pinning our TLS connections: authenticity, integrity, and privacy.

Authenticity

Okta’s client applications are deployed with anti-tamper protection and public keys burned in. Okta’s infrastructure holds the private keys, so we use them to confirm the identity of the server using those burned-in keys. This means Okta Verify can’t be fooled into connecting to a phishing site or other attacker-controlled infrastructure.

Integrity

Though most data transferred between the client and server are already encapsulated in verifiable structures such as JSON Web Tokens, the endpoints needed to verify these structures may not (e.g. `/oauth2/v1/keys`). Key pinning prevents the client from accepting a manipulated set of keys, which could lead to a large attack surface including misconfiguration and phishing attacks.

Privacy

Though Okta works to minimize the use of personally identifiable information (PII), the nature of Okta Verify Device Assurance includes successful identification of the device and detailed signals associated with it to increase the security of your organization. Should third parties read this data, they could gather information about users and their devices for use in attacks or data harvesting.
 

Example of attack when pinning is active

When pinning is active, Okta Verify examines the TLS connection during the TLS handshake before sending or receiving any data. The client then drops the connection, immediately closing off any chance of a non Okta infrastructure reading or modifying data in transit.

This protection represents a mitigating control for Okta FastPass that is not achievable by other phishing-resistant authenticators like hardware keys / WebAuthN, as these rely on the browser’s (unpinned) implementation of PKI + TLS for sending signed assertions over the internet.

The downsides

The main downside of pinning for Okta is operational complexity. As always, we’re willing to accept that extra work to keep our customers more secure.

Some organizations have policies that inspect all traffic within their network perimeter. If Okta Verify traffic is included in the inspection rules, it will block its own network connections, just as it would if an attacker performed traffic inspection or modification. 

For the reasons listed above, we can’t allow inspection of traffic between Okta Verify and its infrastructure without opening up customers to the attack scenarios listed above. If you need to inspect traffic in your network, you can allow-list Okta’s infrastructure from inspection rules. Organizations that need to inspect login traffic between browsers and Okta infrastructure can use a custom domain and inspect traffic to that domain without impacting Okta Verify.

We're watching this space and would be open to exploring alternatives that represent security and operational improvements. You can rest assured that if that happens, the replacement’s security bar will be at or above the current level.

Okta has made a commitment to putting security first. We strive every day to make Okta Verify the most secure authenticator in the world, protecting Okta and our customers. Key pinning is a critical piece of Okta Verify’s overall security, and we will continue to do all we can to keep you safe.

Have questions about this blog post? Reach out to us at [email protected].

Explore more insightful Engineering Blogs from Okta to expand your knowledge.

Ready to join our passionate team of exceptional engineers? Visit our career page.

Unlock the potential of modern and sophisticated identity management for your organization. Contact Sales for more information.