Hello 
Le problème ne vient pas de Squid ou SquidGuard, mais du protocole https lui même. Il n’est pas prévu pour être redirigé.
Même si vous arrivez redirigé une url https bloqué vers une autre page en https bloqué avec un certificat valide : vous aurez quand même un soucis.
Imaginions que vous bloquiez le site de la française des jeux (au boulot on est pas là pour jouer) et que vous redirigiez le site bloqué vers Google (lui aussi en https maintenant par défaut), vous allez donc avoir :
google.fr/
Ben même là vous allez avoir un beau Warning du navigateur qui va dire : "Il y a un soucis mon gars, le certificat n’est valable que pour les domaines *.google.com *.google.fr *.google.es *.google.it *.google.de etc…)
Alors vous vous dites bon ben je vais rediriger vers du http normal alors.
Là aussi le navigateur va interpréter cela comme un comportement anormal et va faire un warning.
Sauf si l’on fait une redirection propre et c’est une chose sur laquelle je travaille dans mon entreprise.
Pour ma part j’ai arrêté avec SquidGuard qui n’est plus mis à jour depuis plus de quatre ans.
Le projet Ufdbguard est beaucoup plus réactif (juillet 2013) et performant. Son développeur répond aux questions par mail.
Lui même dans sa documentation soulève toute cette problématique de la redirection SSL.
La solution ? Faire du SSL bump (du man-in-the-middle en fait)
Un joli tuto ici : monblog.system-linux.net/blog/20 … us-debian/
Notez bien qu’il vous faudra un certificat valide, ou alors déployer avec un stratégie sur votre parc le certificat autosigné.
A titre personnel ma maquette n’est pas opérationnelle (malgré un certificat valide dans le navigateur) car nous rencontrons des difficultés avec WCCP (protocole CISCO de redirection des fluxs http, https). Pour ceux que ça intéresse je pourrai faire un retour dans ce thread.
