Non, le soucis c'est un ordi portable sous Windows 7/8/Linux/Whatelse qui se connecte au wifi (sans WPA, cé maaal) et qui ensuite ouvre son navigateur qui, par défaut, ouvre https://fr.yahoo.com, https://www.google.pl ou encore https://account.live.com/.
Dans ce cas précis (mais pas rare), mon confrère avec lequel nous menons cette réflexion se prend IMMÉDIATEMENT un appel de support parce, je cite, "le wifi marche pas" (Hôtels, chambre d'hôtes, bref, des touristes étrangers pas toujours francophone).
Alors il explique qu'il faut ouvrir http://orange.fr ou http://lemonde.fr ou un de ces sites qui font du CDN qui ne sait pas leur fournir de SSL. Sauf que d'ici peu (hum) de temps, ces sites vont enfin rajouter du SSL et il ne restera plus que la possibilité d'en trouver qui n'a pas rajouté de HSTS et de lui dire de bypasser la vérification du certificat. C'est moche et ça donne de mauvaises habitudes aux end-users (si le mal n'est pas déjà fait).
Si c'est juste ça, il suffit de mettre en place une URL à fournir aux utilisateurs, du type https://monhotel.fr, à afficher à l'accueil, et faire en sorte que cette URL fonctionne depuis le réseau Wifi avant enregistrement (et affiche le portail captif). Et le support pourra fournir cette adresse aux client qui n'arrivent pas à se connecter.
C'est cette problématique que je tente de contourner. Si, en bonus, on a une solution qui permet d'éviter d'ouvrir des AP sans WPA, j'avoue que je ne cracherais pas dessus.
Idem, dans le cas d'un hôtel, il suffit de mettre une panneau à l'accueil / dans les chambres avec la clé à utiliser ...
Après, pour un wifi plus étendu (aéroport, campus, etc), le wifi ouvert est indispensable, et il faut passer par le portail captif, en espérant que les utilisateurs comprendront, en voyant l'erreur du navigateur, qu'il faut se connecter en http. Un DNS menteur ou un proxy ne réglera pas le problème.