Newsgroup: it.comp.os.linux.sys
Titolo: Squid e https (lunghetto)

Ciao a tutti,
ho un problema con squid che non capisco. La configurazione vede 
squid+havp+squidguard. Ha sempre funzionato tutto bene ma negli ultimi 3 
giorni ho provato ad accedere al sito 
https://www.monetaonline.it
 per la 
generazione di una carta virtuale e la pagina resta vuota. L'ultima volta 
che ho acceduto al sito e' stato a maggio e da allora tanto e' cambiato sul 
sistema ma sicuramente niente a livello di configurazione squid (di release 
si). La versione in uso e' la 3.1.4-2.fc12 la distro una fedora core 12 come 
base.
Ho gia' provato ad escludere dalla configurazione sia havp sia squidguard, 
separatamente ed insieme, ma senza risultato.
Con chrome ottengo il messaggio Errore 324 (net::ERR_EMPTY_RESPONSE), con IE 
error 503. Ho escluso problemi del client provando da altri sistemi. La 
risoluzione del nome avviene correttamente. I parametri di ssl e tls sui 
browser dei client sono corretti.
L'unico modo che ho trovato per far funzionare il tutto consiste 
nell'escludere squid e forzare il forward direttamente dal client verso il 
sito.
Per ora e' l'unico sito che mi crea problemi ma non puo' essere un problema 
del sito perche' nel momento che escludo squid funziona.
Qualche idea di cosa possa essere?
Grazie
-- 
 ************** (.)_(.)  **************
 Un amico è uno che sa tutto di te e,
 nonostante questo, gli piaci
(E. Hobbard) 

 non si fa passare dal proxy.
Ma anche si, il metodo CONNECT esiste per questo.

 Davide
Non credo, non arrivo a vedere l'autenticazione. Per l'https ho la classica 
configurazione con la definizione della porta SSL ed il metodo CONNECT.



Domanda:
allora il metodo CONNECT risolve il problema che si potrebbe presentare 
con la nuova estensione per SSL?
Questa è la RFC: 
http://tools.ietf.org/html/rfc5746
-- 
Wikipedia Admin: "wikipedia non è un blog"
Iosif Stalin: "i compagni hanno scambiato il partito per un circolo di 
discussione"

 Questa è la RFC: 
http://tools.ietf.org/html/rfc5746
Non vedo cosa ci azzecchi.


Usando questa nuova estensione (che IMHO usano ancora in pochi) il proxy 
viene visto come "M.I.T.M. Proxy", la connessione viene rigettata e 
alcuni browser chiudono del tutto la connessione.
Questo succede perché il proxy intermedia l'handshake non so in che modo 
con precisione.
Mi chiedevo se tramite il metodo CONNECT viene bypassato l'handshake 
tramite proxy.... tutto qui.



insomma: chiedevo lumi a un luminare dell'informatica e invece "mi tocca 
maledire l'oscurità" (*).
(*) citazione necessaria: Lao Tze


 tramite proxy.... tutto qui.
Ok, 
non sai cosa è il connect.

 [CUT]
Aggiornamento: se al posto del nome inserisco l'ip finale ci arrivo senza 
problemi.
Un errore di risoluzione del nome da parte di squid? Come lo verifico?


 Un errore di risoluzione del nome da parte di squid? Come lo verifico?
Il telco ha cambiato i DNS }:-[



Ebbene si, connect è alternativo al metodo get, e tra le altre cose, ti 
consente di usare ssh attraverso i proxy.
Il problema è: perché dici che l'RFC per la renegotiation non ci 
azzecca, quando invece ci azzecca tantissimo? Probabilmente senza 
CONNECT la renegotiation di SSL fallisce sempre e comunque.


 renegotiation di SSL fallisce sempre e comunque.
perche' CtRiX aveva gia' indicato che per SSL si deve usare CONNECT e l'RFC 
che hai indicato non aggiunge ne toglie nulla a quanto era gia' stato detto
Comunque grazie a tutti
Ciao


 Il telco ha cambiato i DNS }:-[
Io pero' non ho capito perche'. Il nome veniva risolto. I vecchi dns 
rispondevano. Non ricordo l'indirizzo che mi davano. Forse e' cambiato anche 
l'ip del sito. Altrimenti non riesco a capire.


 l'IP, ergo il problema.
Si infatti senza cambio di ip non me lo spiego. Cmq la cache di squid e' 
stata la prima cosa che ho pulito. La prossima volta mi scrivo tutto quello 
che faccio e che vedo cosi' non mi restano + dubbi (e chi ci crede ;-) )


 perche' CtRiX aveva gia' indicato che per SSL si deve usare CONNECT
Non confondiamo le cose.
Il "si deve" di CtRiX è una best practice, condivisa dal sottoscritto, 
ma con l'SSL che abbiamo conosciuto fino a ieri, non è  obbligatoria ai 
fini del funzionamento della connessione. Ovvero: la connessione, per 
funzionare funziona, anche con i metodi GET.
Con la nuova estensione il "si deve" diventa invece un "must", 
altrimenti non va.
ANZI per la precisione:
- Firefox ha stabilito una policy per cui, dopo averti mostrato un 
alert, ti lascia passare ugualmente (e non è il solito alert relativo ai 
certificati self-signed, ma relativo al fatto che la rinegoziazione è 
fallita).
- chromium ti sega la connessione, con un bel messaggio: connesione SSL 
fallita, i dettagli dell'errore sono come segue:
Fai una cosa, così ci sbrigiamo prima. Apri il seguente sito, sia con 
Chrome, sia con Firefox: 
https://sunshinepress.org/


 Non confondiamo le cose.
Cheppalle.
Quando uno non sa come funziona un proxy, dovrebbe quanto meno astenersi 
dallo sparare cazzate o dallo scrivere a vanvera.


sali di qualche messaggio, sali sali sali e poi sali.
Ci sei sul fatto che io AVEVO CHIESTO SUL METODO CONNECT e NON PROCLAMATO?
