www.zeroshell.net

mike · Registrato: 02/05/15 12:27 Messaggi: 24

Buonasera

Ultimamente gli utenti di una mia distribuzione wifi non riescono ad aprire siti con protocollo https, non ricordo se ho cambiato qualche parametro, vorrei capire cosa influenza questa mancata apertura dei siti https, invece http funziona come sempre.

Grazie

Come configurazione ho quella classica con due gateway eth01 ed eth02 con uscita su eth00, se servono altre informazioni chiedete pure.

Intanto cerco di verificare eventuali differenze di configurazione su un clone di test con uguale confgurazione che utilizzo in ambiente locale simulato.

manu69x · Registrato: 22/09/12 09:29 Messaggi: 21

E' colpa del browser
Purtroppo gli ultimi aggiornamenti dei browser
hanno applicato dei criteri di sicurezza molto stretti.

Se gli utenti aprono il browser con un sito https
non riescono piu' ad autenticarsi col captive portal.
In piu' se tentano di aprire un sito https di ultima
generazione (tipo google) non è piu' nemmeno
possibile cliccare sul'opzione per procedere ed
aprire il sito a discapito della sicurezza.

Questo è un grave problema perchè gli utenti
non riescono poi ad autenticarsi col captive portal.

L'unica soluzione che ho trovato è quella di fargli aprire
http://www.google.it/?nord=1
sinchè funzionerà ne ho creato anche un dominio breve
wificp.xyz

Se qualcuno ha altre soluzioni sarebbero bene accette.

Diversamente bisognerebbe caricare sul captive portal
un certificato di classe enterprise che contenga un certificato
valido per tutti i maggiori siti https (ma dubito che esista)

mike · Registrato: 02/05/15 12:27 Messaggi: 24

Ciao

Non credo, nel mio caso, dipenda dal certificato, infatti se scrivo https://www.google.it verrà considerato il certificato di Google e non quello del sito ove risiede zeroshell e Google ha certamente un certificato valido. Il mio problema non è l'autenticazione che avviene regolarmente ma dopo non si apre Google se richiamato con https e di conseguenza nemmeno facebook, ecc.

Ho notato che se disattivo il Netbalancer in modalià solo failover riesco ad aprire url con protocollo https ed anche se lo riattivo continuo fino al riavvio dopodiché bisogna di nuovo disattivare ed attivare il netbalancr. Ho notato anche che se il netbalancer è disattivato non riesco ad accedere da remoto,

mike · Registrato: 02/05/15 12:27 Messaggi: 24

artone · Registrato: 10/03/16 14:29 Messaggi: 44

In pratica il Cp è diventato inutile sono tutti a chiedere come fare per accedere Sad

fdaniele · Registrato: 12/02/07 22:00 Messaggi: 46

anche io ho lo stesso problema, ma sulla versione precedente non si verificava ...

r3ason · Registrato: 04/11/11 01:14 Messaggi: 24

Stesso problema, con le ultime versioni di ios è praticamente inutilizzabile il captive, tra l'altro i messaggi che vengono rilasciati dai browser sono abbastanza inquietanti e l'utenza meno esperta spesso chiama impaurita pensando di essere stata addirittura hackerata. ..uso ZeroShell in 4 strutture alberghiere con una media di 200 connessioni al giorni per hotel ed è diventato praticamente impossibile star
dietro a tutte le chiamate, mio malgrado credo che dovrò trovare un alternativa dopo anni di onorato servizio del captive di zs

FUG-AZI · Registrato: 02/02/15 17:30 Messaggi: 3

Ciao a tutti,

sto completando una installazione con tre punti di accesso captive portal. Dal punto di vista della configurazione di zeroshell non ho avuto grosse difficoltà e sono riuscito a far funzionare tutto. Ho anche acquistato un certificato SSL commerciale e l'ho installato senza problemi.
Il problema grosso è legato alla chiamata HTTPS che viene fatta per aprire i siti web più famosi e utilizzati da tutti (Facebook, Twitter, Google...). Quando l'utente avvia il browser e cerca di aprire il sito web il captive portal cattura la chiamata, ma per qualche ragione "applica" il certificato del captive portal (e nel mio caso è un certificato commerciale, regolare) al sito web che si sta cercando di aprire. In pratica il browser mi dice che il certificato del mio server non può essere usato per www.google.it.
Perché il captive portal si comporta così? Il broswer non dovrebbe "vedere" il sito web sul quale uno vuole andare fino a quando non ci si è autenticati. Invece per qualche ragione sembra che il browser tenti inizialmente di andare sul sito e poi di reindirizzare la chiamata al captive portal. Così facendo crea un casino con il certificato SSL che naturalmente non è valido per quel sito web.
Questa cosa rende praticamente inutilizzabile il captive portal. Per alcuni siti non è neanche possibile dire al browser di proseguire lo stesso.
Ho fatto mille prove, ho provato con Chrome, Safari e Firefox. Ho provato su Android e iOS. Il risultato è sempre lo stesso. Per usare il captive portal la chiamata al sito web deve avvenire digitando http e non https. Io lo so, ma come faccio a spiegarlo a tutte le persone che dovranno usare il sistema?

Sono cosciente che questo problema nasce dalla restrizioni che ultimamente sono state introdotte nei moderni browser, ma se non si rivede il sistema di autenticazione del captive portal di zeroshell credo che lo stesso a breve non sarà più utilizzabile.

Chiedo a Fulvio se ha già riscontrato questo problema e se ha una soluzione.
Qualcuno ha trovato una soluzione?

artone · Registrato: 10/03/16 14:29 Messaggi: 44

artone · Registrato: 10/03/16 14:29 Messaggi: 44

ed aggiungo per poter essere anche di aiuto a qualcun altro che per rendere almeno sostenibile l'utilizzo , ma è solo un paliativo, io aggiungo il supporto al Shibboleth Authentication e quindi in config aggiungo alla whitelist:

www.google.com
www.facebook.com
www.amazon.it

accorgimento che a volte aggira il problema....per il resto Fulvio aiutaci tu

aspide · Registrato: 21/10/10 12:36 Messaggi: 62

anche io ho lo stesso problema

marco.pedrazzi · Registrato: 14/12/17 21:40 Messaggi: 8

Stesso problema anche io, non capisco perchè nessuno ne dia peso, forse una soluzione c'è..

tiger · Registrato: 02/02/16 10:34 Messaggi: 443

Nel cp fate fare il redirect ad http e non https a Google

Http://www.google.it

É non https://www.google.it

marco.pedrazzi · Registrato: 14/12/17 21:40 Messaggi: 8

...ma se ho il certificato ssl, faccio il redirect con l'opzione 'cn' non posso fare il redirect con 'http://www.google.it'

tiger · Registrato: 02/02/16 10:34 Messaggi: 443

se autentificazione la fai con il captive portale e alla voce redirect usi http non https se poi hai dei tuoi certificati SSL è un altro discorso. Il problema si poneva a me dopo immissione credenziale cp.

marco.pedrazzi · Registrato: 14/12/17 21:40 Messaggi: 8

Il problema che ho è ben spiegato nei post precedenti...

tiger · Registrato: 02/02/16 10:34 Messaggi: 443

Puoi tamponare al momento con Radius attivo e cp disattivo.

Cosa significa?

Che devi avere un ap o un ap/router con protezione Wi-Fi non wpa/o

bensì wpa enterprise

Dove li metti ip di zs porta 1812 e una psw da te creata

In zs aggiungi ap o ap/router alla voce Radius immettendo ip suo e stessa psw usata da ap

Questa farà in modo che l'utente che si colleghi in Wi-Fi deve mettere user e password creati in zs per poter accedere e navigare

Eliminando il problema del certificato del cp.

See you

marco.pedrazzi · Registrato: 14/12/17 21:40 Messaggi: 8

si ok grazie del suggerimento... ma resta il fatto che il sistema... cosi come è non è più utilizzabile... non capisco perchè si continui a sprecare tempo per fare porting verso ARM, quando captive portal de facto non va...
bo magari ragionerò in maniera arcaica io...

maverick · Registrato: 18/03/14 17:25 Messaggi: 624

Qualcuno a risolto?
Anche io ho lo stesso problema sebbene abbia installato i certificati
Senza captive Portal il wifi in produzione servono a ben poco effettivamente.

Qualcuno sa come risolvere?

tiger · Registrato: 02/02/16 10:34 Messaggi: 443

Il discorso del certificato è che Google o qlc sito https che utilizza una protezione chiamata hsts che Verifica se il certificato che il ptoprio sito hai corrisponde con il certificato che stai scambiando tu allora per risolvere il problema nelle pagine del browser di Android o di iPhone Va inserita la pagina iniziale in http e non https

Se metti http://www.google.it

Vedi che il cp apre la pagina di autentificazione

In https://www.google.it Google chiarisce il suo certificato al browser e il browser vedendo che la richiesta di tale certificato cozza con quello di zs blocca apertura pagina cp.

Ecco tutto impostare nei browser pagina iniziale qlc sia ma in http.

Come http://www.google.it

See you