Bonjour,
pour faire suite à la discussion sur le forum , je lance ce nouveau fil de discussion.
Comme je le disais, le RSSI a effectué des tests et sa conclusion est la suivante :
Alors pour faire court, le spip_loader construit ses connexions réseaux « à la main » (sans être péjoratif du tout) au travers d’appels de fsockopen.
Le type de flux désiré (UDP, TCP, SSL/TLS) se fait au moment de l’ouverture de la socket réseau.
fsockopen(« », 80, … ) pour http fsockopen(« udp://dns.ac-amiens.fr », 53, … ) pour DNS fsockopen(« ssl://www.ac-amiens.fr », 443, … ) pour https fsockopen(« tls://smtp.ac-amiens.fr », 465, … ) pour du smtps etc… Dans le cas d’un proxy, la connexion ne se fait pas vers le serveur de destination mais on ouvre une socket simple (tcp) vers le serveur proxy et ensuite, on effectue des demandes de connexions au « vrai » serveur au travers de cette socket. Là où ça se complique trop, c’est dans dans connexions « mixtes » : bascule http vers https lors d’une redirection (type 301 redirect) car le mode connexion pour un flux chiffré (TLS ou SSL) réclame de nombreuses opération supplémentaires (helo, handshake, vérification des certificats sources et destinations etc…) et toutes ces opérations ne sont pas implémentées dans les fonctions utilisées par spip_loader (et peut être spip aussi…). Bref, c’est une implémentation complète d’un client http qu’il faudrait intégrer. Ce qui était parfaitement suffisant dans le cas d’une connexion « en clair » se révèle maintenant inopérant. A moins de vouloir réinventer la roue, il semblerait bien plus efficace d’abandonner le mode « à la main » pour privilégier un client http plus complet (via la libcurl par exemple, exhaustive de ce point de vue). C’est, à ne pas douter, ce que les devs de spip vont prochaine devoir implémenter. En mode transitoire, la solution serait de ne pas faire de renvoi http=>https tant que les mises à jours ne sont pas disponibles, ou, à défaut, créer un miroir local des dépôts SPIP accessible en http.
La dessus, il à modifier le spip_loader (fichier joint) pour prendre en charge les serveurs hébergés derrière un proxy.
Cela permet de suivre un redirect (301) de http vers https qui n’est pas implémenter dans la version actuelle.
Le script ne change rien à ceux qui n’ont pas php5-curl (ou php-curl en php7) ou qui n’ont pas de proxy de défini.
Il continue ses investigations afin de permettre à nouveau le fonctionnement de la mise à jour des dépôts non fonctionnelle également (tout comme « mise à jour auto » de Couteau Suisse)
spip_loader_support_proxy_https_redirect_via_curl.diff (1.77 KB)
