3

I have a proxy server, it will have a captive portal page. Users will be required to sign in before gaining access to the internet.

So far I am aware of IP and/or MAC address based authentication.

Is it possible to use HTTP cookies to implement authentication? (Maybe third party cookies?) How does websense do it? (see cookie authentication)

If HTTP cookies are not usable for proxy authentication, is MAC address authentication the industry standard for this thing?

AviD
  • 72,138
  • 22
  • 136
  • 218
user2320724
  • 131
  • 1
  • 2
  • There exist proxies which can use HTTP cookies for authentication, but the details will depend which proxy you are using. (One method you don't mention is client certificates, which would avoid the need to "sign in" as such while still allowing you to monitor/control proxy use, but does have obvious PKI setup costs if you aren't using them already.) – armb May 08 '13 at 13:27
  • 1
    Thanks, can you provide an example or two of such proxies? I'd like to know how exactly they use cookies for authentication WITHOUT their hostname appearing in the browser address bar. – user2320724 May 08 '13 at 16:08
  • On second thoughts I was misreading your requirement e.g. https://kb.bluecoat.com/index?page=content&id=KB2931 http://www.novell.com/coolsolutions/feature/7830.html are talking about using cookies in the context of authenticating to a server being proxied, not authenticating to the proxy itself, and so is the WebSense example you give. And another example I was thinking of isn't really just a proxy. But if users are authenticating to the proxy, why don't you want the proxy's hostname appearing? Surely users should know what they are authenticating too? – armb May 08 '13 at 17:01
  • When I say without the hostname appearing in the browser bar, I mean after authentication, when the user is now freely browsing the internet. As you know most free online proxy servers serve the content in an iframe, and the address bar would be something like myfreeproxy.com/site=google.com. I don't want that. – user2320724 May 08 '13 at 17:10
  • Are you sure that those cookies being are not being used to authenticate to the proxy server itself? The link I provided seems to say that authentication mode of the **proxy server** is "cookie mode". – user2320724 May 08 '13 at 17:13
  • It depends what exactly you mean by authenticating to the server. It says "When one of the NTLM, LDAP, or Radius authentication methods is enabled", the proxy will do the authentication, and uses a cookie (or IP address, depending on mode) to distinguish users - what it cares about is "is this the same user I did an (e.g.) NTLM authentication for just now, if so, use a session that looks the same to the real server". So "is this the same user as before" is in a sense authentication - but I'm not sure it's the same thing as you want. – armb May 08 '13 at 17:28
  • StackExchange is suggesting I automatically move this to chat, but then says you don't have enough reputation for me to do that. But "extended discussions in comments" point taken. Maybe I should delete my comments and just ask for more details of what you are trying to do. My experience is that if you configure your browser to use a proxy, the address bar just works (though at least in the case of Websense, the content can be silently screwed up if configuration is wrong). This might mean you need someone with more experience, who can actually answer instead of asking questions in comments. – armb May 08 '13 at 17:35
  • Yes, authentication will be done through the captive portal page, and checked against a database that my proxy server has access to. I want to use cookies to distinguish users, to know that this is the same user that logged in 5 minutes ago, without having to resend user/pass with every request. – user2320724 May 08 '13 at 19:01

2 Answers2

2

Typically, the standard way to implement proxy authentication is, surprisingly, Proxy Authentication.
This is a set of matching response and request headers, that together implement authentication that is required between the user and the proxy.

This is commonly used with transparent proxies, and is well supported in both browsers and proxies. Some proxies do implement this differently (e.g. how the credentials are verified), but in most cases this is the much preferred solution. There are very few drawbacks to this solution, and alternate solutions that break standard HTTP, such as BlueCoat, have quite a few issues.

Now, you do mention that your proxy will be implementing a captive portal, but you did not mention why. If it is just to implement the authentication form, thinking that there is no built-in solution, I would recommend you change your solution, use standard proxies, and just define required authentication. Building your own captive portal is just way too tricky, and will likely open you up to a whole slew of vulnerabilities (from experience).
If there is some other reason to build the captive portal - random signups, payment options, crazy fun, etc - perhaps elaborate, and we can deal with them. Otherwise it does look like an XY problem (where you assume a solution and ask about that, instead of asking about your actual problem...)

Community
  • 1
AviD
  • 72,138
  • 22
  • 136
  • 218
1

BlueCoat when deployed as a transparent proxy can use the concept of cookie surrogates to authenticate a user, in order to make it work the core mechanism used is the redirection to a virtual URL that will always request authentication (HTTP 401), here's how it's implemented on it:

First time authentication:
1. UA (User agent) issues a GET / to HOST:www.example.com
2. Proxy server intercepts the GET and replies with a redirect (302) to the virtual URL and a query string that contains the original URL requested, e.g. "http://virtualURL.com?QueryString"
3. UA attempts to connect to virtual URL
4. Proxy replies with HTTP 401, requesting authentication
5. UA reissues the same request of step 3, but with authentication credentials
6. UA is redirected again (302), this time to the original URL, the query string is still attached to this redirect (http://www.example.com?QueryString), also there's a SET-COOKIE that appears to be coming from virtualURL (this will be used on requests to sites other than the initial one)
7. UA connects to the original URL + Query string, since it still have the Query String on the request the proxy issues a new 302, this time to www.example.com, also includes a SET-COOKIE, but this time the cookie behaves as being issued from example.com domain.
8. UA connects to www.example.com, the cookie is also received and accepted. This cookie notifies the proxy that the user is authenticated.
9. The proxy forwards the UA request to the original URL removing the cookie, to not interfere with the transaction.

Subsequent requests will follow as:

Request to www.newsite.com, get redirected to virtualURL?QueryString, this time there already is a cookie to the virtualURL domain, so no 401 is needed, new redirect to newsite.com?QueryString, SET-COOKIE for new domain, redirect to original URL.

I guess that using the same concept you can adapt it to your proxy server.

AviD
  • 72,138
  • 22
  • 136
  • 218
drak
  • 116
  • 2