Protecting Basic Credentials: Selectively Intercepting SSL for the Purpose of Authentication

Products

• ProxySG Software - SGOS

Issue/Introduction

If your Edge SWG / ProxySG appliance has authentication realms that accept basic credentials, you need to ensure those credentials are encrypted on the wire. They should only be presented on an SSL connection to protect against eavesdropping.

Resolution

Transparent
For transparent clients, the answer is simple: configure a virtual URL for your realm(s) that uses an HTTPS virtual URL, and ensure that authentication always uses an origin-*-redirect or form-*-redirect authentication mode.

Explicit
For explicit clients, the above solution will work only for HTTP URLs – it will not work for HTTPS URLs. When browsers load an HTTPS URL, they start by sending an HTTP CONNECT message to the Edge SWG / ProxySG. The CONNECT message notifies the Edge SWG / ProxySG that the client is about to set up an encrypted tunnel with the OCS. Browsers will not honor an HTTP redirect that is sent in response to a CONNECT message. The only responses they will honor are an HTTP 200, meaning that it is okay to set up the tunnel, or an HTTP 407 authentication challenge. The 407 response should be avoided when basic credentials are in use, because the browser will respond with credentials before the tunnel has been set up. The credentials would therefore cross the wire in the clear.
One solution to that problem is to allow the CONNECT, intercept SSL, and then perform authentication in the encrypted tunnel. The policy below will do that:
 

<Proxy>
    ALLOW http.connect=yes
    ALLOW authenticate(basic_credential_realm) authenticate.mode(origin-cookie-redirect)
 
<SSL-Intercept>
    ssl.forward_proxy(https)

 
(Note that in order for SSL interception to work, you must enable the Detect protocol attribute on the Edge SWG / ProxySG’s Explicit Proxy service.)
 
The above policy ensures that Basic credentials are always presented at the realm’s virtual URL. If that URL uses HTTPS, then the credentials will always be encrypted on the wire.
The policy also intercepts all SSL traffic, which may not be ideal. If you only want to intercept SSL long enough for clients to authenticate, then you can use policy like this:
 

<Proxy>
    ALLOW authenticate(basic_credential_realm) authenticate.mode(origin-ip-redirect)  authenticate.tolerate_error(cannot_redirect_connect)
 
<SSL-Intercept>
    authenticated=no ssl.forward_proxy(https)
    ssl.forward_proxy(no)

 
When the above policy processes a CONNECT message from an unauthenticated client, the authentication will fail because the Edge SWG / ProxySG knows the CONNECT message can’t be redirected. Because the "cannot_redirect_connect" error is tolerated, the Edge SWG / ProxySG allows the request.
The client then begins the SSL handshake. Because the client has not authenticated yet, SSL will be intercepted. The Edge SWG / ProxySG will therefore see the first request in the encrypted tunnel, and will redirect it to the virtual URL for authentication.
When the client is redirected back to the origin content server (OCS) URL after authentication, it will send a new CONNECT message. Since the policy specifies origin-ip-redirect mode, the Edge SWG / ProxySG can now look up the authenticated session using the client’s IP address, thereby authenticating the CONNECT message without issuing a 407 challenge. Since the client is now authenticated, the Edge SWG / ProxySG will not intercept SSL when the client sets up its encrypted tunnel with the OCS. (This solution requires the use of an IP surrogate (origin-ip-redirect or form-ip-redirect) mode in order to authenticate the client prior to the SSL handshake.)