802.1X and HTTPS face off when it comes to server certificate validation

Adam Uncategorized

802.1X and HTTPS face off when it comes to server certificate validation

Share

This is part 2 of our series on server certificate validation.

In talking with many customers about setting up RADIUS certificates, it is clear many admins have a difficult time describing the server certification validation process to their user base. Noting the differences in the transactions that occur during a typical HTTPs connection and the more secure, 802.1x authentication will hopefully help clear up any confusion your users may have.

The typical HTTPS transaction initiated within a browser looks something like this:

  1. A browser sends an HTTPS request to www.google.com on port 443.
  2. Google responds with a web server certificate.
  3. The browser checks the web server certificate provided by Google and validates the following items:
    1. URL in browser matches the Common Name (CN) of the certificate.
    2. Certificate is signed by a chain in the machine or browser’s certificate trust store (keychain in OS X). This step establishes the chain of trust so that the signed certificate can be recognized as “trusted” by the client. In other words, you are proving you are who you say you are.
    3. Date on the certificate is valid.
  4. If the checks pass, the connection is established and the browser will load the requested website.
  5. If any of the three checks listed above fail, the user is warned that the site is untrusted and may be redirected away. Some browsers will allow you to inspect the web certificate to understand why it may be warning you. Often this is due to a ‘Self Signed’ certificate, in which no trust chain exists.
Connection Untrusted

What Chrome users are presented with if the HTTPS certificate fails to validate.

Why is server certificate validation so much more difficult during the 802.1X authentication process?

  1. 802.1X Clients/Supplicants are very opaque:  Most clients or supplicants do not present a User Interface (UI) layer. If there is a UI present, it is often buried deep in the network configuration settings.
  2. 802.1X is time sensitive:  If the EAP transaction does not complete within a defined window (approximately 60 seconds) the transaction will be aborted but may be restarted. Often this is too short of a time window for a user to accept a certificate.
  3. The client does not know which RADIUS server it should be talking to:  With a web browser, the client can simply check the CN of the certificate against what is in the browser. 802.1x is fundamentally different. Because the RADIUS server for any given network is buried deep in the wireless infrastructure settings, it’s virtually impossible for a user to identify the DNS name of the RADIUS server, making it much more difficult to know if the RADIUS server you are talking to is the correct one.

If the only requirement is that the certificate must be signed by a public Certificate Authority (CA), we would essentially be passing along user credentials at anyone with a public certificate for ANY domain. 802.1X client configurations require the client/supplicant to specify which certificate chain must be signed by the trust store. To strengthen the level of security even more, some configurations allow the CN of the RADIUS server to be specified. If the server presents a certificate different from what is configured in the supplicant, the client will quietly stop the authentication before credentials are sent.

How to ensure all clients are configured for server certificate validation:

In Windows Domain environments, the supplicant settings and certificate validation can be pushed out through Windows Group Policy (GPO) settings. Configuring clients and supplicants becomes more challenging in environments containing non-Windows Domain devices.

One option is to allow users to configure their own device. However, relying on manual configuration by the end user introduces a bevy of missteps and security challenges. If not configured precisely, users can easily fall victim to a man-in-the-middle attack, which involves an attacker broadcasting an imitation SSID with the intention of tricking improperly configured devices into connecting and giving up user credentials. This is a nightmarish scenario for corporations and universities, as just about anyone with basic hacking knowledge can potentially steal credentials, gain unauthorized access to confidential data and wreak havoc for the IT department.

Will buying a certificate from a public CA resolve this problem?

No. Obtaining a certificate from a public CA such as Thawte or Verisign may save you from needing to distribute a root and/or intermediate certificates necessary to complete the trust chain, but still leaves the user responsible for specifying the proper certificates required for your network. Given the large number of existing CA certificates in the trust store, this often proves too difficult for end users successfully navigate.

SecureW2 delivers powerful tools that streamline the onboarding process for your users. Our automated, browser-based BYOD solution can help your organization gain the full benefits of WPA2-Enterprise, while eliminating human error and creating an onboarding process that is painless from start to finish.