> When a user opens up a browser or a shortcut to a bookmark link and
> the home or start page is a SSL web site https://webpage.domain.com
> the captive portal does not grab it. It will just time out.
SSL is meant for communication with the target machine only. This is ensured
by the server certificate, which's validity is checked by the browser (with
a challenge-response mechanism). This is to prevent man-in-the-middle
Now, the m0n0wall is NOT the target machine, therefore it cannot provide a
valid signature for it's response to the browser's request to the target
meachine. If the m0n0wall answers the request (instead of passing though an
unmodified encoded response which was correctly signed by the requested
target machine), the browser would display a distressing warning. Some
browsers may allow the user to dismissis this warning and to proceed anyway,
but the "secure" part of SSL would be rendered pointless at that point.
Sounds like you are screwed, eh? The SSL security concept is designed to
make such things impossible, so I'd recommend not to screw around and have
the user's live with this minor inconvinience...it's for their own safety!
Or their data's safety, at least ;-)
Of course there might be workarounds for some cases. For example, if the
user's always have to access the same https-host, you might set up an
external server which will, upon receipt of an ordinary http-request,
redirect it towards the https-site. That way the users could set up a
http-link to the mentioned external http server, which will get caught by
the captive portal and then be automatically be redirected to the
pre-configured https-site (or, optinally, an URL-encoded https-URL which is
passed as a parameter to the plain http-request). Disadvantages are, of
course, the plain bookmarking isn't sufficient to reach SSL sites, and
administration of the additional server. Yuk!
Best regards, klaus
This mail sent using V-webmail - http://www.v-webmail.orgg