[stand by] HTTPS ?

[sly]

Selon moi et mon avis seulement :
A part le logo en ce moment même en haut à gauche qui fait penser le contraire mais l'adresse ("canonique") du site est www.refuges.info
refuges.info étant le domaine (comme au bon vieux temps de l'invention du dns quoi !), le fait que cela réponde sur http://refuges.info n'est qu'une "convenance" afin de réduire les oublis de saisies.

Mais sachant que la plupart des navigateurs se chargent maintenant de tester ces oublis on pourrait tout aussi bien décider de stopper le pointage dns de refuges.info

[Dominique]

Bof. J'aime bien les URL courts.
Et franchement, je trouve cette habitude d'âge canonique peu adaptée au grand public qui n'en a que faire et n'en connait pas la signification, surtout pour un site entièrement accessible via internet (sans intranet à différencier, ...)

[sly]

peu adaptée au grand public qui n'en a que faire

Le "grand public" ne sait pas faire la différence entre la barre d'adresse et une recherche sur google...

Il tapera "infos refuges" et ça marchera, donc la question du "court" ne me semble pas entrer beaucoup en ligne de compte pour eux.

Ma raison est donc principalement technique, même si c'est la préhistoire du net qui nous tient la jambe, on est pour l'instant obligé de composer avec : Il est impossible d'avoir un enregistremetn DNS CNAME sur refuges.info obligé d'avoir un A, et ça gêne une grosse partie de la flexibilité du clustering/multi IPs/en cas de panne.
Et si j'en crois http://google.fr http://apple.com http://sncf.com http://orange.fr et bien d'autres (gros) encore je ne suis pas le seul à penser cela et y voir un avantage

[Dominique]

C'est bizarre, je vois 2 enregistrements A* pour refuges.info
Peut être un load balancing mais pas une redondance ?

Nom d'hôte TTL Classe Type Adresse IP
refuges.info. 10800 IN AAAA 2001:bc8101::1
refuges.info. 10800 IN A 212.83.149.234
mx2.gplservice.net. 10800 IN A 212.129.13.6
mx1.gplservice.net. 10800 IN A 212.129.13.6
ns1.gplservice.net. 10800 IN A 46.105.40.209
ns2.gplservice.net. 10800 IN A 212.129.25.180
refuges.gplservice.net. 10800 IN A 212.83.149.234
refuges.gplservice.net. 10800 IN AAAA 2001:bc8101::1

[sly]

C'est bizarre, je vois 2 enregistrements A* pour refuges.info

A* ? l'algorithme de routage des paquets sur les routes de l'internet ? Algorithme_A*

A -> IPv4
AAAA -> IPv6

point de load balancing ni de redondance, wri tourne sur un serveur virtuel avec une seule adresse réseau.


Edition: P.... de phpBB code, on ne peut plus faire de blague tranquille sans avoir son url coupée en rondelles. Ce forum est trop charcuté, les [ url ] ne marchent plus on dirait. Ho non, j'ai pas envie d'y replonger...
Bon ouf, c'est uniquement à cause du * dans l'url, bon ben tant pis

[Dominique]

Je réactive le sujet avec la question du https sur map.refuges.info
Ce n'est pas indispensable mais chrome détecte une incohérence de schéma entre https://www.refuges.info/nav et les tuiles de MRI
Quand ils nous tiennent par un bout...

Mixed Content: The page at 'https://www.refuges.info/nav' was loaded over HTTPS, but requested an insecure image 'http://maps.refuges.info/hiking/14/8321/5861.png'. This content should also be served over HTTPS.

[sly]

Je réactive le sujet avec la question du https sur map.refuges.info

Un peu la galère à cause d'un OS Linux trop vieux (2013 !) pour le let's encrypt ssl gratos mais voilà qui est fait :
https://maps.refuges.info/

[Dominique]

Un peu la galère à cause d'un OS Linux trop vieux (2013 !) pour le let's encrypt ssl gratos mais voilà qui est fait :
https://maps.refuges.info/

Super merci.
Ce truc de https est une vrai galère pour un site accédant à de multiples services. Parce que certains ne sont pas encore s ou même parce qu'ils n'ont pas mis à jour leur certificat et que ce qui marchait hier ne marche plus aujourd'hui.
Exemple : https:// cdn.leafletjs.com/leaflet-0.7/leaflet.js (ne marche plus)
Bon, c'est plus pour de la démo que de la prod, mais chrome refuse de charger le script et si tu ne vas pas voir dans la console, tu ne comprends pas !

Je sais bien qu'il faut sécuriser mais pas forcément tout. Une consultation d'info publique comme WRI ne devrait pas en avoir besoin par exemple.
Ce que je me demande c'est dans quelle mesure les majors du web ne s'assurent pas un contrôle (et un droit de censure) via les autorités de certification Mais bon, il ne faut peut être pas voir big brother partout ?

[sly]

Exemple : https:// cdn.leafletjs.com/leaflet-0.7/leaflet.js (qui ne marche plus en 2021)

C'est un des problèmes qui nous pend au nez avec cette manie du https, les projets de petite taille dont l'aciduité du webmaster est aléatoire vont avoir des certifs qui expirent, qui sont re-paramétrés (comme ici ou le cloud du cluster du machine fait que le certif est pour *.cloudfront.net)

Ce que je me demande c'est dans quelle mesure les majors du web ne s'assurent pas un contrôle (et un droit de censure) via les autorités de certification :satan: Mais bon, il ne faut peut être pas voir big brother partout ?

Je préfère voir un big brother qui finalement y est pas que ne pas en voir un qui y est !
Je ne saurais dire si c'est par l'invalidation du certif ou la remonté de la barrière d'entrée d'accès au https après que tout le monde s'y soit habitué, mais oui, cette histoire de navigateurs tenus par des gros qui tout doucement nous impose le https et peuvent décider par la magie de l'upgrade automatique si leur navigateur ne va pas refuser une autorité de certif (pour faire pression et par exemple imposer l'invalidation du certif de tel site) sans que l'utilisateur puisse, à pas trop compliqué, l'outrepasser.

Et ça m'inquiète, on nous servira cela avec une sauce "c'est pour votre sécurité car il y avait un méchant virus sur ce site" ou "c'était le site d'un vilain pirate très méchant" mais au final des sites pourraient en pâtir.

[sly]

Un peu la galère à cause d'un OS Linux trop vieux (2013 !) pour le let's encrypt ssl gratos mais voilà qui est fait :
https://maps.refuges.info/

Super merci.

Tiens, je ne sais pas si c'est parce que c'est resté en suspend ou si c'est une regression mais je navigue maintenant en https sur wri et j'ai l'alerte de firefox qui me dit que maps.refuges.info est accédé en http

[Dominique]

Tiens, je ne sais pas si c'est parce que c'est resté en suspend ou si c'est une regression mais je navigue maintenant en https sur wri et j'ai l'alerte de firefox qui me dit que maps.refuges.info est accédé en http

Moi aussi (dans la console). Bien que ça reste très discret.
L'étau se resserre : http://www.ecommercemag.fr/Thematique/s ... R79r8XJ.97

C'est d'autant plus dommage que j'ai implémenté le schéma des cartes dépendant du schéma de la page dans la lib mais que je n'ai pas livré cette dernière
Je vais voir ça.
Par contre, il y aura toujours des cartes pour lesquelles nous attendons https (Espagne par exemple)


Pour la petite histoire, je suis cette semaine branché sur un hot spot qui détourne la page demandée aux fins d'identification.
Hors, mon navigateur par défaut est "chrome" et ma page de démarrage "https://www.google.fr" (ben oui, on ne peut pas s'en passer )
Donc, quand je me connecte au réseau, j'obtiens de la part de chrome une page haute en rouges me signalant qu'un pirate à intercepté ma ligne (ça, je le savais, pour une bonne cause) MAIS M'INTERDISANT COMPLETEMENT DE PASSER OUTRE, ce qui est fort gênant car je ne peux pas m'identifier...
Bon, ça se contourne (pour le moment) mais, quand tous les sites seront HTTPS et que tous les explorateurs auront le même comportement parano, il faudra m'expliquer comment je m'identifie sur le hotspot
Même GG ne pense pas à tout !

[sly]

On passe un peu plus (ou carrément on force ?) le forum en https ?

== avantages ==
* Comme nous l'avions prédit, les navigateurs sont de plus en plus alarmistes avec les sites accédé en http, d'autant plus si un mot de passe est transmis en http, ce qui peut être le cas de notre forum qui est accessible en http autant qu'en https.
* Et je conviens, qu'avec le piratage en augmentation la donne a un peu changé. Le risque des mot de passer identique utilisé un peu partout font que le forum de refuges.info en http pourrait faire courir un risque plus élevé de vol de mot de passe. Risque que nous devrions tenter de réduire.
* Les utilisateurs qui, comme moi, on choisi de naviguer le site en https ou qui sont venu par google qui ne référence le site plus que en https sont dans une situation perturbante quand les mails provenant de phpBB n'offre que des liens en http

== inconvénients ==
J'entends toutefois l'argument qui dit que quand on est dans la cambrousse avec une connexion 2G on peut préférer accéder au site avec une latence minimum. Mais accéderait-on au forum dans ces situations ?
Je conviens aussi que si le certificat expire par erreur le forum devient alors pas ou difficilement utilisable.
Et je soupçonne que des effets de bords léger pourraient avoir lieu (devoir se reconnecter peut-être ?) pour les utilisateurs ayant leur bookmarks en http qui se retrouverons en https

== proposition ==
Les avantages dépassant selon moi les inconvénients (et pis y'a bien un jour ou les navigateurs nous l'imposerons) autant commencer maintenant.
Je propose en phase 1 : que les mails qui partent du forum proposent des liens https* pour tout le monde
en phase 2 : que l'accès au forum soit forcé en https par redirection


* correction : j'avais écris http

[Claude Mauguier]

... mon navigateur par défaut est "chrome" et ma page de démarrage "https://www.google.fr" (ben oui, on ne peut pas s'en passer )

Disons qu'on peut s'en passer à 85,847 %, pour les "travaux courants"
Firefox ==> Duckduck (Qwant est squelettique et pauvre en résultats) ==> etc. GG c'est juste une question de statistique en résultats de recherches (bien que DD trouve parfois ce que GG ne trouve pas), puisque l'échantillonnage ne se base pas sur les mêmes critères.
Mais c'est pas le sujet.
Le passage en https côté WRI va-t-il affecter non seulement ce qui en sort, mais aussi ce qui y rentre ?? Par ex.si on poste un lien en http,est-ce que ça va bloquer qqpart, du genre cartes espagnoles, comme disait Dominique

[Dominique]

J'entends toutefois l'argument qui dit que quand on est dans la cambrousse avec une connexion 2G on peut préférer accéder au site avec une latence minimum. Mais accéderait-on au forum dans ces situations ?

Ya pas que le 2G : https passe très mal sur 3G et 3G+
C'est un ariégeois qui le dit : tu ne m'aurais plus comme client quand j'irai voir ma famille
La fibre et le 4G, c'est bien pour la ville... essaye donc sur une aire d'autoroute déjà

Quant à l’éradication du http et donc l'exclusion de tous les éloignés de la civilisation, je crains qu'on y arrive mais le plus tard possible pour WRI s'il te plait.

en phase 1 : que les mails qui partent du forum proposent des liens https pour tout le monde

je vote oui

en phase 2 : que l'accès au forum soit forcé en http par redirection

Je vote contre. Si c'est par défaut, il faudrait un moyen de revenir en http

Le passage en https côté WRI va-t-il affecter non seulement ce qui en sort, mais aussi ce qui y rentre ?? Par ex.si on poste un lien en http,est-ce que ça va bloquer qqpart, du genre cartes espagnoles, comme disait Dominique

Soit rassuré, ça n'affecte ni la connexion ni la saisie / récupération des infos

[sly]

Quant à l’éradication du http et donc l'exclusion de tous les éloignés de la civilisation, je crains qu'on y arrive mais le plus tard possible pour WRI s'il te plait.

"exclusion", tout de suite les grands mots, n'exagérons pas non plus...
Toutefois, je n'ai aucunement l'intention de forcer du https pour une zone du site dans laquelle ne passe pas de données personnelles privées. Je dirais même que tant que je n'y vois aucun inconvénients (bien que ça nous pende au nez : google étant parti en croisade contre le http pour on ne sait quelle obscure raison sournoise, il finira par nous dé-référencer, signaler par du rouge, du orange ou autres messages angoissant) je voterais pour la résistance.

en phase 1 : que les mails qui partent du forum proposent des liens https pour tout le monde

je vote oui

Je vais essayer depuis l'admin de phpBB, ça doit bien se paramétrer quelque part.

en phase 2 : que l'accès au forum soit forcé en http par redirection

Je vote contre. Si c'est par défaut, il faudrait un moyen de revenir en http

J'ai dû mal à comprendre ta réticence, le forum va plutôt vite à charger, du https en plus ne rajoutera pas énorme de latence non ? Et dans un cas de mobilité sur réseau médiocre, je ne m'imagine pas vraiment lire et participer sur le forum, un vrai clavier avec un vrai écran me semble préférable de toute façon.
Mais admettons, sur le même principe qu'avant, je n'ai rien contre le fait que le contenu du forum soit accessible en http, c'est uniquement le formulaire de login que je souhaite protéger.
Je m'étais juste dis que cette fonctionnalité n'avait certainement pas été prévue, mais peut-être y'a-t-il un moyen de protéger uniquement ucp.php?mode=login quitte à retrouver du http une fois authentifié ?