Certificate Warnings during 802.1x

Certificate Warnings during 802.1x

Why am I getting a warning from my 802.1x supplicant about my RADIUS server certificate even though it was issued by a trusted CA?

All Environments

When a device configured for 802.1x begins the authentication process, it may receive an x509 certificate from the RADIUS server to identify itself to the device. This happens before the device has an IP address, so there can be no revocation status verification or DNS based verification as would be available during an HTTPS connection. There are only two criteria to protect the device from rogue RADIUS servers. The first one is the certificate trust chain and the second one is the subject name in the certificate being presented by the RADIUS server. 

Ideally, the 802.1x connection would be defined on the client device with a specific server name to look for in the RADIUS server certificate in addition to trusting the CA which issued the certificate. Without a server name defined in the 802.1x connection, ANY certificate issued by a CA could be trusted for this 802.1x session. This would present a major security risk since any certificate issued by a major 3rd party trusted CA could be used to put up a rogue RADIUS server. 

If an unsuspecting user were to connect to a rogue 802.1x service such as a wireless LAN which used EAP-PEAP with MSCHAP v2 for authentication, they would be susceptible to providing their password hash to an untrusted 3rd party simply because that party had a certificate issued by a public, trusted CA such as Verisign. 

In the absence of a named RADIUS server in the 802.1x configuration, some supplicants will provide the user with a pop up prompt to show the user of the device the certificate being supplied by the RADIUS server. It is up to the user to check the name on this certificate and make a decision on whether or not to trust this RADIUS server. 

To avoid the pop up warning, the 802.1x supplicant needs to be configured to trust a specific RADIUS server name. Instructions on how to do this vary from device to device. 

ClearPass Onboard performs this task during device registration to facilitate RADIUS connections without pop-up warnings to end users during 802.1x authentication.

ref:-https://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Certificate-Warnings-during-802-1x/ta-p/176460

How secure is your EAP-PEAP v0

How secure is your EAP-PEAP v0 deployment?

PEAP stands for Protected Extensible Authentication Protocol. PEAP is one of many types of EAPs available. EAP types are like different flavors of ice cream. You can have simple vanilla or a complex rocky road type of EAP. The different types of EAPs provide different levels of administration and security. Some EAPs are consider weak, like LEAP which can be breached with Asleap.

Commonly referenced EAPs used on WiFi networks:

EAP-PEAP
EAP-LEAP
EAP-TLS
EAP-TTLS
EAP-FAST

EAP-PEAP is the most common and widely deployed EAP used on wireless networks world wide. It is also very secure, if configured and deployed properly. EAP-PEAP has a few different versions. These versions identify what type of internal authentication is conducted AFTER the outer TLS tunnel is created. This internal tunnel is where credentials are passed. The most commonly used EAP-PEAP type used is EAP-PEAP v0 based on MsChapV2.

EAP-PEAP v0 - MsChapV2
EAP-PEAP v1 - GTC
EAP-PEAP v2 - TLS

The intent of this blog post is to keep the understanding and configuration of EAP-PEAP client side simple and easy to understand.

The reason why PEAPv0 is widely adopted is because Microsoft was part of PEAP development. Microsoft uses their own protocol MsChapV2 as the internal tunnel to pass credentials. The windows wireless supplicant natively supports PEAP v0. This resulted is wide adoption.

How you configured EAP-PEAPv0 is very important. If not properly configured you can expose yourself and your network to a man in the middle attack. To understand this process we need to understand some of the mechanics of PEAP.

SERVER SIDE CERTIFICATE

PEAPv0 uses a server side certificate. The certificate is installed on the radius server. This server side certificate is used to create the outer TLS tunnel between the client and the radius server. This prevents prying eyes from sniffing frames to expose the user ID and password.

When a WiFi client connects to a WLAN configured with EAP, the radius server sends the server side certificate to the client. The client then uses this server side certificate to hash his/her network credentials and passes it back to the radius server. The radius server has the private key for that server side certificate. You may recall when you created the CSR (certificate signing request) a private key was created in that process. The private key resides on the radius server. Think of the private key as a secret decoder ring. After the radius server decodes the client hash, it can send the user ID and password to AD for user authentication.

MAN IN THE MIDDLE

While there are other documented PEAP attacks. The most realistic and real world attack is the man in the middle attack. We just discussed how the server side certificate is used to securely pass user IDs and passwords.

What if we compromised the users connection by presenting our own server side certificate via a rogue access point broadcasting your WLAN, whereby collecting the user ID and password?

Imagine for a moment…………

You work for Acme Company. Your Acme computer is configured to a WLAN called ACME-WIRELESS-NETWORK. You connect each and every day without fail. One day you connect and get a validate certificate popup. You, like almost everyone else, click accept without reading the content of the popup. What you just did was accepted a server side certificate from a rogue radius server and you passed your user ID and password.

This article is not intended to share all the specifics on how to set up a man in the middle attack. You’re one google search and a FREE RADIUS setup away!

VALIDATING SERVER SIDE CERTIFICATE

It is important we validate the server side certificate on the wireless client that connects to our enterprise wireless network. In other words we are trusting only specific certificates from our own radius server(s). All other request get ignored and don't get displayed to the user as a popup to override. This is critical to prevent a man in the middle attack.

From an enterprise perspective this isn't a simple check box on the infrastructure and the problem goes away. Rather its standardizing on client side configuration and ensuring this configuration is deployed on every wireless device connecting to your network. The other problem, wireless supplicants aren't created equally. iOS and OSX you need to push a profile whereby validating the certificate like windows. Some supplicants may or may not allow you to validate certificates.

HUMAN FACTOR

You need to remove the human decision making process from this security equation. You don't want to give a user the ability to choose what certificate they should and should not validate when connecting to your enterprise network.

WINDOWS 7 / 8.1 - APPLE iOS and OSX

Windows 7, 8.1 and Apple devices require the user to validate a wireless network when presented with a certificate for wireless authentication, if a wireless profile is not setup for that WLAN. Once accepted the certificate trust is remembered in the WLAN profile. If you delete the WLAN profile these certificate trusts also get deleted. By manually configuration or profile pushing you can negate the certificate trust popup.

CONFIGURE VALIDATING SERVER SIDE CERTIFICATE DETAIL

http://support.microsoft.com/kb/941123

Method 1: Limit the trusted root CAs that are available to the user
Overall, the best way to reduce these potential risks is to limit the trusted root CAs that are permitted for PEAPv0. To do this, click to clear the check boxes for all non-applicable CAs in the Trusted Root Certification Authorities list. This prevents the user from trusting new root CAs, because the user is presented with an explicit list of permitted authentication servers.

Method 2: Prevent the user from being prompted for certificate validation
PEAPv0 configuration includes an option that prevents the user from being prompted for certificate validation. This is the Do not prompt user to authorize new servers or trusted root certification authorities option. By default, this option is disabled. If you enable this option, the user is not presented with the UI that may be difficult for the user to understand. Therefore, the user cannot select an unapproved root certification authority.

To enable this option, follow these steps:

1 In the Protected EAP Properties dialog box, click to select the Validate server certificate check box.

2 Click to select the Do not prompt user to authorize new server or trusted certification authorities check box.

3 Install the root certificate of the server in the NTAuth store, or click to select the root certificate in Trusted Root Certificate Authorities list.

If you cannot use this method, you can educate users to make sure that they reject the request to authorize any new servers or certification authority.

Method 3: Limit authentication servers
PEAPv0 configuration lets you limit the servers that can be trusted for an authentication. The Connect to these servers option uses a list of server names, each separated by a semicolon, to explicitly define the servers against which the client may authenticate. When you enable this option and use the strict list of accepted servers, this man-in-the-middle attack is much more difficult to execute. Or, this attack may be impossible to execute, depending on the specific PKI structure that your organization uses.

To enable the Connect to these servers option, follow these steps:

1 In the Protected EAP Properties dialog box, click to select the Validate server certificate check box.

2 Click to select the Connect to these servers check box.

3 In the Connect to these servers box, type a list of all back-end authentication servers. Separate each server name with a semicolon. For example, type the following for the domain acme.com and for authentication servers auth1 and auth2: auth1.contoso.com;auth2.contoso.com

Overview

1 - Validate Server Certificate
- Select the CA that signed your server side certificate

2 - Enter the CN name of the server side certificate(s). If more than 1 CN is used (radius servers) separate CN with a “;” and make sure there are spaces between CNs.

3 - Check box the Do Not Prompt user ….. This is an extra fail safe that a user won’t get the popup.

4 - Enter enable identify privacy — Enter a value in this field. This field is presented in clear text during the EAP-PEAP process. Make sure its not a user ID. :)

Guide to SSL Certificates

SSL stands for “Secure Socket Layer.” It is a technology that establishes a secure session
link between the visitor’s web browser and your website so that all communications transmitted
through this link are encrypted and are, therefore, secure. SSL is also used for transmitting secure email,
secure files, and other forms of information.

SSL creates a safe and private channel for you to communicate.

What Is an SSL Certificate? 

An SSL certificate is a digital computer file (or small piece of code) that has two
specific functions:
1   Authentication and Verification: The SSL certificate has information about
the authenticity of certain details regarding the identity of a person, business or
website, which it will display to visitors on your website when they click on the
browser’s padlock symbol or trust mark (e.g., the Norton™ Secured Seal). The
vetting criteria used by Certificate Authorities to determine if an SSL certificate
should be issued is most stringent with an Extended Validation (EV) SSL
certificate; making it the most trusted SSL certificate available.

2   Data encryption: The SSL certificate also enables encryption, which means that
the sensitive information exchanged via the website cannot be intercepted and
read by anyone other than the intended recipient.
In the same way that a identity document or passport may only be issued by the
country’s government officials, an SSL certificate is most reliable when issued by a
trusted Certificate Authority (CA). The CA has to follow very strict rules and policies
about who may or may not receive an SSL certificate. When you have a valid SSL
certificate from a trusted CA, there is a higher degree of trust by your customers,
clients or partners.


How Does SSL encryption Work?
In the same way that you lock and unlock doors using a key, encryption makes use
of keys to lock and unlock your information. Unless you have the right key, you will
not be able to “open” the information.

Each SSL session consists of two keys:
• The public key is used to encrypt (scramble) the information.
• The private key is used to decrypt (un-scramble) the information and restore it
to its original format so that it can be read.

The Process: Every SSL certificate that is issued for a CA-verified entity is issued for a specific server and website domain (website address). When a person uses their browser to navigate to the address of a website with an SSL certificate, an SSL handshake (greeting) occurs between the browser and server. Information is requested from the server – which is then made visible to the person in their browser window. You will notice changes to indicate that a secure session has been initiated – for example, a trust mark will appear.If you click on the trust mark, you will see additional information such as the validity period of the SSL certificate, the domain secured, the type of SSL certificate, and the issuing CA. All of this means
that a secure link is established for that session, with a unique session key, and secure communications can begin.

How Do I Know that a Site Has a Valid SSL Certificate?

1   A standard website without SSL security displays “http:// ” before the website
address in the browser address bar. This moniker stands for “Hypertext
Transfer Protocol,” and is the conventional way to transmit information over
the Internet.
2.  However, a website that is secured with a SSL certificate will display “https:// ”
before the address. This stands for “Secure HTTP.”

Where Would I Use an SSL Certificate?  

The short answer to this question is that you would use an SSL certificate anywhere
that you wish to transmit information securely.
Here are some examples:
• Securing communication between your website and your customer’s Internet
         browser.
• Securing internal communications on your corporate intranet.
• Securing email communications sent to and from your network (or private email
         address).
• Securing information between servers (both internal and external).
• Securing information sent and received via mobile devices.

Different types of SSL Certificates 

There are a number of different SSL certificates on the market today.
• The first type of SSL certificate is a self-signed certificate. As the name implies,
this is a certificate that is generated for internal purposes and is not issued by a
CA. Since the website owner generates their own certificate, it does not hold the
same weight as a fully authenticated and verified SSL certificate issued by a CA.

• A Domain Validated certificate is considered an entry-level SSL certificate
and can be issued quickly. The only verification check performed is to ensure
that the applicant owns the domain (website address) where they plan to use
the certificate. No additional checks are done to ensure that the owner of the
domain is a valid business entity.

• A fully authenticated SSL certificate is the first step to true online security and
confidence building. Taking slightly longer to issue, these certificates are only
granted once the organization passes a number of validation procedures and
checks to confirm the existence of the business, the ownership of the domain,
and the user’s authority to apply for the certificate.

Tips

• A domain name is often used with a number of different host suffixes. For this
reason, you may employ a Wildcard certificate that allows you to provide full
SSL security to any host of your domain – for example, host.your_domain.com
(where “host” varies but the domain name stays constant).
• Similar to a Wildcard certificate, but a little more versatile, the SAN (Subject 
Alternative Name) SSL certificate allows for more than one domain to be added
to a single SSL certificate.
• Code signing certificates are specifically designed to ensure that the software
you have downloaded was not tampered with while en route. There are many
cybercriminals who tamper with software available on the Internet. They may
attach a virus or other malicious software to an innocent package as it is being
downloaded. These certificates make sure that this doesn’t happen.
• Extended Validation (EV) SSL certificates offer the highest industry standard
for authentication and provide the best level of customer trust available. When
consumers visit a website secured with an EV SSL certificate, the address bar
turns green (in high-security browsers) and a special field appears with the
name of the legitimate website owner along with the name of the security
provider that issued the EV SSL certificate. It also displays the name of the
certificate holder and issuing CA in the address bar. This visual reassurance has
helped increase consumer confidence in e-commerce.

SSL VPN

Definition - What does Secure Socket Layer Virtual Private Network (SSL VPN) mean?

A secure socket layer virtual private network (SSL VPN) allows remote users to access Web applications, client-server applications and internal network connections without having to install specialized client software on their computers.

Secure Socket Layer Virtual Private Network (SSL VPN)

Secure socket layer virtual private networks provide secure and private communication for all traffic types between devices equipped with similar technologies across public networks such as the Internet.

There are two major types of SSL VPN:

1. SSL Portal VPN: Allows single SSL connections to websites, allowing end users to securely access multiple network services. Remote users can access the SSL VPN gateway with any Web browser following authentication through a method supported by the gateway. Access is attained through a Web page that acts as a portal to other services.
2. SSL Tunnel VPN: Allows Web browsers to securely access multiple network services, as well non-Web-based protocols and applications, through tunnels running under SSL. SSL tunnel VPN requires that the Web browser handle active content and provide functionality that is not accessible through SSL portal VPN. It can uninstalled in PC with standalone agent directly or from the portal web page.

snapshot attached for reference