Auth Server should allow generation of relative URLs

[igough57@…]

The following describes a security issue with wifidog.

Auth server configuration allows SSL to be used for a particular virtual host by setting the Allow SSL on this Server setting. This flag toggles whether the prefix to all absolute URL links within returned pages are prefixed by http or https. This allows you to have an insecure or secure session.

There is one problem with this approach. If the wifidog administrator chooses to set up the virtual host to *not* use SSL, but an SSL certificate exists, then the user cannot do her own risk assessment and determine that for this particular login session that she wants to use a secure session, or even just a secure login transaction. This is of importance when doing logins over unsecured wireless networks, where any joker running WireShark? can collect your unencrypted credentials. It is of crucial importance to wifidog admins logging in as the privledge level allows any blackhat to bring down the entire system once he captures the admin credentials.

For example. If I go to an unsecured wifidog auth portal as  https://auth.some-portal.ca, then the returned pages contain a login links for  http://auth.some-portal.ca/login/ instead of login. The absolute URL prevents me from continuing with a secure session and makes it very difficult for me to login securely without hand crafting a web page or address.

The problem really comes down to the fact that the returned web pages contain absolute URLs as links. If you were to code all links as relative, a lot of these problems goes away. The only issue then becomes how does a user simply login using SSL or not. This is sometimes solved on other systems that want to give users the choice by having a Button or Link to "Login" AND "Securely Log in", one which has a relative URL and the other which has an absolute URL to  https://the-login-url.

Any Questions to igough57@…

[benoitg]

Quite frankly, I have trouble seeing this as a problem. If administrators decide not to enable SSL, it's the administrator that is at fault. We'd love to autodetect the availability of SSL. Unfortunately, we didn't find a reasonable way to detect from PHP if a SSL version of the current URL is available.

In fact, one of the main reason why wifidog uses absolute links is so that the naive user cannot accidentally use plaintext for login if SSL is enabled. I see no reason to give the user a choice given the availability of SSL.

And indeed, if SSL is enabled, even if the user accesses  http://auth.some-portal.ca, the login link will be  https://auth.some-portal.ca/login/. In fact, even if the user were to manually re-craft the url as  http://auth.some-portal.ca/login/, the form would STILL post as SSL.