IOS Authentication Proxy & HTTPS

[kurtpatzer]

I am trying to determine a graceful way of implementing secure authentication (i.e. not clear text HTTP) authentication proxy on an IOS router. It seems the only difference in router configuration between HTTP based auth-proxy and HTTPS based is the use of the command "http secure-server" Upon first connection, the router generates a self signed x.509 certificate for use in HTTPS.

Here's the problem that I have. User X tries to connect to a web server on the other side of the router. The router intercepts the request & challenges for a user id and password. All as if we weren't using secure authentication methods. The post of the challenge response to the router is HTTPS, even if the original interecepted request was HTTP. Now, the problem is, the user will get a security alert in their browser at this point - every time. 1) Dates are fine. 2) Signature may or may not be fine. If we didn't enroll the router with a trusted CA, & hence the cert is self signed, User X will have to install the router's SSL certificate in the browser. This isn't a big issue, because it is a one time deal. 3) The name in the URL (the original request that was intercepted) does not match the name on the certificate (the router's CN). This will never match and hence the users will always get a security alert upon authentication challenge.

I can dream up some hacked up ideas such as setting up a server off an unused interface & set up DNS so the router's host name resolves to the name of this server & telling the users to connect to that server to initiate authentication, then continue todo what they are authorized to do across the router. But this is a hosed up complex mess.

I could also tell the users to ignore the security alert they get when they authenticate in this one instance. But users will generalize and some will interpret in that they can disregard all security alerts from IE.

Is there something simple that I am missing? Is there a fairly elegant resolution? The PIX has the concept of "virtual http" which they seem to have completely missed on the router.

[benhur.p]

Any update on thsi?

[kurtpatzer]

I am still watching for responses. Obviously there haven't been any. I've played with it some more on my own, but still don't have an elegant solution. I'm not sure how Cisco could have thought adding HTTPS support could be used in an effective way from the behavior it brings.

[computerone1]

I up this topic as I have the same problem, an reach the same conclusion: with nowadays 'https everywhere' and 'HTTP Strict Transport Security', the IOS HTTPS auth-proxy function is broken (because of the Common Name error generated). It is not an option to train the users to bypass browser security warnings.

Is the only option left to revert to HTTP auth-proxy? It does create some security issues (sniffing and MITM over the user's credentials).

Here is an extract I found in Cisco ISE doc:

"Important Note about HTTPS Redirection

Switches are able to redirect HTTPS traffic. Thus, if the guest client has a homepage in HTTPS, the redirection occurs correctly.

The whole concept of redirection is based upon the fact that a device (in this case, the switch) spoofs the website IP address. However, a major issue arises when the switch intercepts and redirects HTTPS traffic because the switch can present only its own certificate in the Transport Layer Security (TLS) handshake. Since this is not the same certificate as the website originally requested, most browsers issue major alerts. The browsers correctly handle the redirection and presentation of another certificate as a security concern. There is no workaround for this, and there is no way for the switch to spoof your original website certificate."

Source: https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/113362-config-web-auth-ise-00.html

I need to implement auth-proxy for my Cisco ISE, so the issue is quite actual.

Any input is welcomed !