[stand by] HTTPS ?
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
[stand by] HTTPS ?
Salut
Bien que beaucoup d'instances militent pour la disparition de http, je ne voyais jusqu'à maintenant pas l'utilité de passer WRI en http sécurisé.
Le but n'est pas de sécuriser l'intégrité du serveur (on peut tout aussi bien l'attaquer en https) mais les données utilisateurs circulant sur internet (actuellement, pour WRI, je ne vois que le mot de passe).
Le problème, c'est que les fournisseurs de butineurs semblent voir plus loin: ils ont identifiés la position de l'utilisateur comme donnée sensible et, bien que notre application ne le fasse pas, soupçonnent chaque page opérant une géolocalisation d'être en mesure de la transmettre au serveur.
La tendance est donc d'inhiber la fonction geolocalisation sur les pages transmises par http. Le premier à faire ça est Chrome à partir de la version 50. Résultat, on ne peut plus se géolocaliser sur les cartes WRI.
Bien que ce ne soit pas une fonction primordiale, je trouvais sympa (si on a une porteuse):
- de suivre sa progression par rapport à un point WRI
- de géolocaliser et créer un point directement devant la cabane sans avoir à enter la position (je l'ai fait au moins une fois )
Les autres explo allant suivre un jour ces recommandations, la fonction geolocalisation de WRI ne sera plus opérationnelle tant qu'on ne sera pas passé en https.
Je ne sais pas si GPL services peut partager un certificat ni combien ça coûterait ni si le jeu en vaut la chandelle. A discuter.
Note 1: On a le problème avec la geolocatisation actuellement mais d'autres features sont sur la sellette, l'ambition étant bien de rendre la vie difficile à ceux qui ne seront pas sécurisés (sans jugement de valeur sur cette tendance qui pourtant m'en inspire).
Note 2 (qui n'a rien à voir): lors de ma dernière balade, ayant bêtement oublié la carte, j'ai sauvé la journée en suivant la carte WRI et son point de géolocalisation. Non seulement ça marche très bien (même hors porteuse en parcourant en avance le trajet pour garder les dalles en cache) mais c'est plus efficace que mon vrai GPS de rando puisque je peux avoir les dalles de la carte IGN !
Maintenant, je ne pourrais plus
Bien que beaucoup d'instances militent pour la disparition de http, je ne voyais jusqu'à maintenant pas l'utilité de passer WRI en http sécurisé.
Le but n'est pas de sécuriser l'intégrité du serveur (on peut tout aussi bien l'attaquer en https) mais les données utilisateurs circulant sur internet (actuellement, pour WRI, je ne vois que le mot de passe).
Le problème, c'est que les fournisseurs de butineurs semblent voir plus loin: ils ont identifiés la position de l'utilisateur comme donnée sensible et, bien que notre application ne le fasse pas, soupçonnent chaque page opérant une géolocalisation d'être en mesure de la transmettre au serveur.
La tendance est donc d'inhiber la fonction geolocalisation sur les pages transmises par http. Le premier à faire ça est Chrome à partir de la version 50. Résultat, on ne peut plus se géolocaliser sur les cartes WRI.
Bien que ce ne soit pas une fonction primordiale, je trouvais sympa (si on a une porteuse):
- de suivre sa progression par rapport à un point WRI
- de géolocaliser et créer un point directement devant la cabane sans avoir à enter la position (je l'ai fait au moins une fois )
Les autres explo allant suivre un jour ces recommandations, la fonction geolocalisation de WRI ne sera plus opérationnelle tant qu'on ne sera pas passé en https.
Je ne sais pas si GPL services peut partager un certificat ni combien ça coûterait ni si le jeu en vaut la chandelle. A discuter.
Note 1: On a le problème avec la geolocatisation actuellement mais d'autres features sont sur la sellette, l'ambition étant bien de rendre la vie difficile à ceux qui ne seront pas sécurisés (sans jugement de valeur sur cette tendance qui pourtant m'en inspire).
Note 2 (qui n'a rien à voir): lors de ma dernière balade, ayant bêtement oublié la carte, j'ai sauvé la journée en suivant la carte WRI et son point de géolocalisation. Non seulement ça marche très bien (même hors porteuse en parcourant en avance le trajet pour garder les dalles en cache) mais c'est plus efficace que mon vrai GPS de rando puisque je peux avoir les dalles de la carte IGN !
Maintenant, je ne pourrais plus
Dominique http://chemineur.fr
-
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
Je n'aime pas faire quelque chose parce que des navigateurs me l'imposent. Mais comme par ailleurs je suis plutôt favorable au https, ou tout du moins à laisser le choix aux internautes.
Et qu'ajouté à ça il parait qu'une initiative à vu le jour pour délivrer gratuitement et automatiquement des certificats (let's encrypt) je ne vois pas trop de freins (à part mon temps) à tenter de mettre ça en place.
Si pas d'objection, je tenterais le coup pour voir ce que ça donne, sans forcer personne à y passer.
ps: par contre, je vois gros comme une maison que dans ~5ans ça ne marchera plus parce que tel navigateur aura décidé que ce genre de certificat ne sont pas assez sûr et que, in finé, il faudra passer à la caisse mais bon, ça aura au moins tourné 5 ans !
Et qu'ajouté à ça il parait qu'une initiative à vu le jour pour délivrer gratuitement et automatiquement des certificats (let's encrypt) je ne vois pas trop de freins (à part mon temps) à tenter de mettre ça en place.
Si pas d'objection, je tenterais le coup pour voir ce que ça donne, sans forcer personne à y passer.
ps: par contre, je vois gros comme une maison que dans ~5ans ça ne marchera plus parce que tel navigateur aura décidé que ce genre de certificat ne sont pas assez sûr et que, in finé, il faudra passer à la caisse mais bon, ça aura au moins tourné 5 ans !
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
Je viens de passer chemineur et c'est une vraie galère !
Tous les abonnements à des cartes sont à rectifier.
Ensuite, l'explorateur râle parce que la belle page https appelle des images non sécurisées... si certaines sources ont un accès https, d'autres non !...
D'ici qu'il leur prenne la fantaisie de déclarer insecure une page qui inclue des images http !
Ensuite viennent les liens internes. C'est fou ce qu'on a pu mettre comme petites icônes... et quelquefois avec le mauvais shéma !
Bon j'ai au moins essuyé les plâtres si tu y vas, préviens moi avant !
Tous les abonnements à des cartes sont à rectifier.
Ensuite, l'explorateur râle parce que la belle page https appelle des images non sécurisées... si certaines sources ont un accès https, d'autres non !...
D'ici qu'il leur prenne la fantaisie de déclarer insecure une page qui inclue des images http !
Ensuite viennent les liens internes. C'est fou ce qu'on a pu mettre comme petites icônes... et quelquefois avec le mauvais shéma !
Bon j'ai au moins essuyé les plâtres si tu y vas, préviens moi avant !
Dominique http://chemineur.fr
-
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
En html, bien sûr, mais en JS, AJAX et dans la tripaille de Leaflet, l'url relative devient une notion très relative.
Avec une pensée émue pour la récupération de l'adresse des icônes de couches externes à WRÏ.
Avec une pensée émue pour la récupération de l'adresse des icônes de couches externes à WRÏ.
Dominique http://chemineur.fr
-
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
Et voilà https d'activé pour https://www.refuges.info
Comme anticipé, les zones cartes font brailler les navigateurs qu'il y a des images png accedées en http, ouloulou le drame terrible.
Comme anticipé, les zones cartes font brailler les navigateurs qu'il y a des images png accedées en http, ouloulou le drame terrible.
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
Ça va, pas trop de dégâts.
Le code de WRI est mieux écrit que celui de chemineur...
J'avais anticipé l'autorisation sur les cartes anglaises, j'attends la clé IGN (c'est toujours très long), les Suisses sont automatiquement en https et je mettrai dans la journée une lib Leaflet qui appelle des images https quand c'est possible.
Et j'ai récupéré la localisation
Merci !
Le code de WRI est mieux écrit que celui de chemineur...
J'avais anticipé l'autorisation sur les cartes anglaises, j'attends la clé IGN (c'est toujours très long), les Suisses sont automatiquement en https et je mettrai dans la journée une lib Leaflet qui appelle des images https quand c'est possible.
Et j'ai récupéré la localisation
Merci !
Dominique http://chemineur.fr
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
Heu... je ne sais pas si c'est un gros travail, mais est il possible d'avoir https://dom.refuges.info , ... ?
Dominique http://chemineur.fr
-
- Messages : 81
- Enregistré le : 14 avr. 2014, 03:03
- Localisation : 71/2B
Une remarque en passant :
dans des coins trèèès reculés où le réseau GSM est ultra-capricieux (devinez où ), l'utilisation du httpS ajoute une lenteur sensible (surplus de connexions à établir et de données à échanger...) quand ce n'est pas l'échec complet du chargement d'un site (du fait de connexions-déconnexions-pertes de signal-changement d'IP qui rendent la sécurisation invalide).
Donc le https, c'est bien, mangez-en tout plein ; mais pour des usages sur mobile dont on peut s'attendre qu'ils s'effectuent dans des coins à très bas débit, pour l'échange de données non sensibles et/ou "d'urgence", le simple http peut malgré tout rester de mise.
/ceci était un message de qqn qui s'est récemment surpris à maudire les serveurs qui forcent le passage en SSL/TLS.
dans des coins trèèès reculés où le réseau GSM est ultra-capricieux (devinez où ), l'utilisation du httpS ajoute une lenteur sensible (surplus de connexions à établir et de données à échanger...) quand ce n'est pas l'échec complet du chargement d'un site (du fait de connexions-déconnexions-pertes de signal-changement d'IP qui rendent la sécurisation invalide).
Donc le https, c'est bien, mangez-en tout plein ; mais pour des usages sur mobile dont on peut s'attendre qu'ils s'effectuent dans des coins à très bas débit, pour l'échange de données non sensibles et/ou "d'urgence", le simple http peut malgré tout rester de mise.
/ceci était un message de qqn qui s'est récemment surpris à maudire les serveurs qui forcent le passage en SSL/TLS.
-
- Messages : 539
- Enregistré le : 28 févr. 2013, 17:28
- Localisation : Montagne noire
Salut,
J'arrive après la guerre.
Pour Let's Encrypt, je l'utilise pour une dizaine de noms de domaine, et ça fonctionne très bien. Il faut cependant noter la validité de seulement 3 mois des certificats et il peut être utile d'automatiser le renouvellement via une tache CRON.
J'ai entendu la communauté autour de Firefox annoncer qu'il allait bientôt être impossible d'utiliser des champs de type password dans des formulaires non HTTPS. Ce sera alors un gros problème, je pense qu'il est aussi préférable de passer à l'HTTPS si possible.
Ça fonctionne à merveille en tout cas ici.
Léo
J'arrive après la guerre.
Pour Let's Encrypt, je l'utilise pour une dizaine de noms de domaine, et ça fonctionne très bien. Il faut cependant noter la validité de seulement 3 mois des certificats et il peut être utile d'automatiser le renouvellement via une tache CRON.
J'ai entendu la communauté autour de Firefox annoncer qu'il allait bientôt être impossible d'utiliser des champs de type password dans des formulaires non HTTPS. Ce sera alors un gros problème, je pense qu'il est aussi préférable de passer à l'HTTPS si possible.
Ça fonctionne à merveille en tout cas ici.
Léo
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
Très intéressant. Merci (je vais en profiter pour faire quelques tests).SQFP.info a écrit :Une remarque en passant :
dans des coins trèèès reculés où le réseau GSM est ultra-capricieux (devinez où ), l'utilisation du httpS ajoute une lenteur sensible (surplus de connexions à établir et de données à échanger...) quand ce n'est pas l'échec complet du chargement d'un site (du fait de connexions-déconnexions-pertes de signal-changement d'IP qui rendent la sécurisation invalide).
Donc le https, c'est bien, mangez-en tout plein ; mais pour des usages sur mobile dont on peut s'attendre qu'ils s'effectuent dans des coins à très bas débit, pour l'échange de données non sensibles et/ou "d'urgence", le simple http peut malgré tout rester de mise.
/ceci était un message de qqn qui s'est récemment surpris à maudire les serveurs qui forcent le passage en SSL/TLS.
Dominique http://chemineur.fr
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
Sly,
comment se fait il que sur http://www.refuges.info, $_SERVER retourne: 'REQUEST_SCHEME' => 'https' ?
Bon, pas grave puisque je viens de m’apercevoir que la clé IGN que j'ai demandé pour https fonctionne aussi dans une page http... mais j'aime bien comprendre et j'en aurais peut être besoin plus loin. Prendre 'SERVER_PROTOCOL' ?
comment se fait il que sur http://www.refuges.info, $_SERVER retourne: 'REQUEST_SCHEME' => 'https' ?
Bon, pas grave puisque je viens de m’apercevoir que la clé IGN que j'ai demandé pour https fonctionne aussi dans une page http... mais j'aime bien comprendre et j'en aurais peut être besoin plus loin. Prendre 'SERVER_PROTOCOL' ?
Dominique http://chemineur.fr
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
Question bête, pour minimiser les râleries des explos: peut on/doit on avoir un accès https à map.refuges.info ?
Dominique http://chemineur.fr
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
J'ai corrigé les cartes IGN et clicks sur les cartes.
Par contre, ça y est: une requête bloquée pour contenu non sécurisé !
Plus d'OSM-OVERPASS.
leaflet.js?1467562984:315 Mixed Content: The page at 'https://www.refuges.info/nav/433' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://api.openstreetmap.fr/oapi/interp ... 2811678675'. This request has been blocked; the content must be served over HTTPS.reload @ leaflet.js?1467562984:315fireEvent @ leaflet.js?1467562984:33_resetView @ leaflet.js?1467562984:70(anonymous function) @ leaflet.js?1467562984:164(anonymous function) @ leaflet.js?1467562984:27
leaflet.js?1467562984:315 XMLHttpRequest cannot load http://api.openstreetmap.fr/oapi/interp ... 2811678675. Failed to start loading.
Et pourtant, j'ai passé toutes les URL en HTTPS !
Je ne vois pas où il prend le HTTP qu'il envoie ?
C'est l'enfer HTTPS !!!
Par contre, ça y est: une requête bloquée pour contenu non sécurisé !
Plus d'OSM-OVERPASS.
leaflet.js?1467562984:315 Mixed Content: The page at 'https://www.refuges.info/nav/433' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://api.openstreetmap.fr/oapi/interp ... 2811678675'. This request has been blocked; the content must be served over HTTPS.reload @ leaflet.js?1467562984:315fireEvent @ leaflet.js?1467562984:33_resetView @ leaflet.js?1467562984:70(anonymous function) @ leaflet.js?1467562984:164(anonymous function) @ leaflet.js?1467562984:27
leaflet.js?1467562984:315 XMLHttpRequest cannot load http://api.openstreetmap.fr/oapi/interp ... 2811678675. Failed to start loading.
Et pourtant, j'ai passé toutes les URL en HTTPS !
Je ne vois pas où il prend le HTTP qu'il envoie ?
C'est l'enfer HTTPS !!!
Dominique http://chemineur.fr