Precedente :: Successivo |
Autore |
Messaggio |
mike
Registrato: 02/05/15 12:27 Messaggi: 24
|
Inviato: Mar Ago 04, 2015 8:49 pm Oggetto: Mancato accesso https |
|
|
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. |
|
Top |
|
 |
manu69x
Registrato: 22/09/12 09:29 Messaggi: 21
|
Inviato: Lun Ago 17, 2015 8:04 am Oggetto: Re: Mancato accesso https |
|
|
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 ha scritto: | 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. |
|
|
Top |
|
 |
mike
Registrato: 02/05/15 12:27 Messaggi: 24
|
Inviato: Mar Ago 18, 2015 8:49 am Oggetto: |
|
|
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, |
|
Top |
|
 |
mike
Registrato: 02/05/15 12:27 Messaggi: 24
|
Inviato: Mer Ago 26, 2015 10:40 am Oggetto: |
|
|
Citazione: | 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, |
Purtroppo non riesco a risolvere.
Qualcuno ha avuto lo stesso problema? |
|
Top |
|
 |
artone
Registrato: 10/03/16 14:29 Messaggi: 44
|
Inviato: Sab Lug 30, 2016 10:45 am Oggetto: |
|
|
In pratica il Cp è diventato inutile sono tutti a chiedere come fare per accedere  |
|
Top |
|
 |
fdaniele
Registrato: 12/02/07 22:00 Messaggi: 46
|
Inviato: Mer Ago 17, 2016 5:19 pm Oggetto: |
|
|
anche io ho lo stesso problema, ma sulla versione precedente non si verificava ... |
|
Top |
|
 |
r3ason
Registrato: 04/11/11 01:14 Messaggi: 24
|
Inviato: Ven Set 30, 2016 7:44 am Oggetto: |
|
|
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 |
|
Top |
|
 |
FUG-AZI
Registrato: 02/02/15 17:30 Messaggi: 3
|
Inviato: Dom Ott 16, 2016 4:37 pm Oggetto: |
|
|
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? |
|
Top |
|
 |
artone
Registrato: 10/03/16 14:29 Messaggi: 44
|
Inviato: Dom Giu 11, 2017 10:03 am Oggetto: |
|
|
FUG-AZI ha scritto: | 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? |
Mi associo alla richiesta ... per altro ho anche impostato come prima pagina quella del target fissando a http://www.google.com ma niente
i client vengono redirezionati ad https://www.google.com
con la seguente risposta:
e come dettagli mi da
io uso i Let's Encrypt poi se l'utente cambia pagina ed azzecca quella giusta ad esempio ebay il captive parte
é risolvibile questo problema ?
Secondo me è importante risolvere questo problema perchè questo rende di fatto inutilizzabile il captive portal
Ciao |
|
Top |
|
 |
artone
Registrato: 10/03/16 14:29 Messaggi: 44
|
Inviato: Dom Giu 11, 2017 8:40 pm Oggetto: |
|
|
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 |
|
Top |
|
 |
aspide
Registrato: 21/10/10 12:36 Messaggi: 62
|
Inviato: Dom Giu 25, 2017 10:37 pm Oggetto: |
|
|
anche io ho lo stesso problema |
|
Top |
|
 |
marco.pedrazzi
Registrato: 14/12/17 21:40 Messaggi: 8
|
Inviato: Gio Dic 14, 2017 9:56 pm Oggetto: |
|
|
Stesso problema anche io, non capisco perchè nessuno ne dia peso, forse una soluzione c'è.. |
|
Top |
|
 |
tiger
Registrato: 02/02/16 10:34 Messaggi: 443
|
|
Top |
|
 |
marco.pedrazzi
Registrato: 14/12/17 21:40 Messaggi: 8
|
Inviato: Ven Dic 15, 2017 8:58 pm Oggetto: |
|
|
...ma se ho il certificato ssl, faccio il redirect con l'opzione 'cn' non posso fare il redirect con 'http://www.google.it' |
|
Top |
|
 |
tiger
Registrato: 02/02/16 10:34 Messaggi: 443
|
Inviato: Ven Dic 15, 2017 9:12 pm Oggetto: |
|
|
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. |
|
Top |
|
 |
marco.pedrazzi
Registrato: 14/12/17 21:40 Messaggi: 8
|
Inviato: Ven Dic 15, 2017 9:28 pm Oggetto: |
|
|
Il problema che ho è ben spiegato nei post precedenti...
artone ha scritto: | FUG-AZI ha scritto: | 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? |
Mi associo alla richiesta ... per altro ho anche impostato come prima pagina quella del target fissando a http://www.google.com ma niente
i client vengono redirezionati ad https://www.google.com
con la seguente risposta:
e come dettagli mi da
io uso i Let's Encrypt poi se l'utente cambia pagina ed azzecca quella giusta ad esempio ebay il captive parte
é risolvibile questo problema ?
Secondo me è importante risolvere questo problema perchè questo rende di fatto inutilizzabile il captive portal
Ciao |
|
|
Top |
|
 |
tiger
Registrato: 02/02/16 10:34 Messaggi: 443
|
Inviato: Ven Dic 15, 2017 10:33 pm Oggetto: |
|
|
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 |
|
Top |
|
 |
marco.pedrazzi
Registrato: 14/12/17 21:40 Messaggi: 8
|
Inviato: Ven Dic 15, 2017 10:52 pm Oggetto: |
|
|
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... |
|
Top |
|
 |
maverick
Registrato: 18/03/14 17:25 Messaggi: 624
|
Inviato: Mar Dic 19, 2017 5:33 pm Oggetto: |
|
|
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? |
|
Top |
|
 |
tiger
Registrato: 02/02/16 10:34 Messaggi: 443
|
Inviato: Ven Dic 22, 2017 2:55 pm Oggetto: |
|
|
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 |
|
Top |
|
 |
|