Doléances et suggestions ...

[Cathy]

Merci pour votre proposition d'aide , je vais ouvrir un sujet spécifique dans la section présentation.

[Rocella Tintoria]

Bonjour,
je remarque que le site n'est pas sous https;

https est très important pour sécuriser la communication entre un site (le serveur) et le navigateur (le client).

est il envisagé de pallier le problème?

[Tugdual]

https est très important pour sécuriser la communication entre un site (le serveur) et le navigateur (le client).

Cette sécurité n'a de sens que si les informations
qui transitent nécessitent une telle sécurité.

Dans le cas d'un forum comme celui-ci, ou encore
d'un simple site d'informations, cela a peu d'utilité ...

[Rocella Tintoria]

https est très important pour sécuriser la communication entre un site (le serveur) et le navigateur (le client).

Cette sécurité n'a de sens que si les informations
qui transitent nécessitent une telle sécurité.

Dans le cas d'un forum comme celui-ci, ou encore
d'un simple site d'informations, cela a peu d'utilité ...

C'est à présent une sécurité indispensable et pour le site et pour les usagers, notamment les sites sensibles "comme celui-ci" qui ont trait à une condition médicale et des témoignages a priori anonymes et parfois sensibles.
Cette question est loin d'être anodine; je m'étonne que personne ne semble en prendre la mesure.

"HTTPS permet au visiteur de vérifier l'identité du site web auquel il accède, grâce à un certificat d'authentification émis par une autorité tierce, réputée fiable (et faisant généralement partie de la liste blanche des navigateurs internet). Il garantit théoriquement la confidentialité et l'intégrité des données envoyées par l'utilisateur (notamment des informations entrées dans les formulaires) et reçues du serveur. Il peut permettre de valider l'identité du visiteur, si celui-ci utilise également un certificat d'authentification client.
Depuis le début des années 2010, le HTTPS s'est également généralisé sur les réseaux sociaux."

https://fr.wikipedia.org/wiki/HyperText ... col_Secure
http://articles.fr.softonic.com/https-p ... e-securite (curieusement celui-ci est toujours http...)

[Tugdual]

Il y a également peu de chance

Il garantit théoriquement la confidentialité et l'intégrité des données envoyées par l'utilisateur (notamment des informations entrées dans les formulaires) et reçues du serveur.

Ici, chacun est anonyme, ce qui relativise
la sensibilité des infos qui transitent entre les
utilisateurs (clients) et le serveur du forum.

HTTPS permet au visiteur de vérifier l'identité du site web auquel il accède, grâce à un certificat d'authentification émis par une autorité tierce, réputée fiable (et faisant généralement partie de la liste blanche des navigateurs internet).

Ce risque est ici infime. Aucun hacker n'a le moindre
intérêt ni de temps à perdre pour générer un pseudo
forum identique et leurrer les utilisateurs, tout ça
pour ne récupérer aucune info pertinente (infos
personnelles, bancaires ... etc ...), et sans la moindre
chance de pouvoir en retirer un quelconque bénéfice ...

Depuis le début des années 2010, le HTTPS s'est également généralisé sur les réseaux sociaux."

Ce contexte est différent, du fait que ces réseaux
sociaux font pression sur leurs utilisateurs pour
qu'ils s'inscrivent sous leur identité réelle. Là,
on commence à avoir des données monnayables ...

Mais peut-être passera-t-on au "https"' dans l'avenir ...

Il ne faut pas trop se faire peur non plus ...

On peut comparer "https" au verrou d'une porte (qui
n'empêchera d'ailleurs pas un voleur motivé d'entrer).

Chez moi, ce verrou a un intérêt, puisque j'y stocke
mes papiers, ma carte bleue, mon porte feuille ... etc ...

Mais pour ma cabane de jardin ne contenant au mieux
qu'une brouette et quelques outils, à quoi bon un verrou ...

[freeshost]

Ça coûte cher, le https ?

[Tugdual]

Ça coûte cher, le https ?

En gros, le coût d'un certificat numérique pour le serveur,
ce qui peut aller de quelques dizaines à quelques centaines
d'euros chaque année, selon l'organisme certificateur ...

[freeshost]

Et pour le site Asperansa, tu estimerais à combien (chez un bon fournisseur-certificateur) ?

[Tugdual]

Je n'ai pas étudié les différences précises entre
les différentes offres disponibles. Mais les ordres
de prix sont ceux que j'ai précisé ci-dessus ...

[Rocella Tintoria]

asperansa est ébergé par gandhi ?
https://www.gandi.net/ssl/grid?lang=fr

pour vous Tugdual, parce que vos remarques montrent bien que vous n'y comprenez pas grand chose:

eff.org
Comment déployer HTTPS correctement

Écrit par Chris Palmer et Yan Zhu

Publié le 15 novembre 2010. Révisé le 12 décembre 2013.

Les spécialistes de l’internet ont toujours su que HTTP est non sécurisé et qu’il cause beaucoup de risques pour les utilisateurs. Parce que le trafic HTTP n'est pas chiffré, toutes les données envoyées via HTTP peuvent être lues et modifiées par quiconque a accès au réseau. Comme l’ont révélé les documents de Snowden sur la surveillance de la NSA, le trafic HTTP peut être également collecté et fouillé par des organismes gouvernementaux sans préavis aux utilisateurs ou aux webmasters. Compte tenu de ces risques, l’EFF estime que les sites Web devraient offrir le protocole HTTPS sur l’ensemble de leurs pages dès que possible.

Tandis que HTTPS existe depuis longtemps comme le strict minimum pour la sécurité sur le Web, certains sites ont été lents à l’adopter. Cela s’explique en partie par le fait qu’une certaine attention est nécessaire pour pouvoir offrir correctement et entièrement une application via HTTPS.

Cet article est conçu pour encourager et pour aider les opérateurs de sites Web dans la mise en œuvre et l'amélioration de la prise en charge de HTTPS. Bien qu'aucune précaution ne puisse prémunir contre toutes les menaces, la prise en charge de HTTPS protégera les utilisateurs contre un large éventail d'attaques courantes.
Contexte

HTTPS apporte trois garanties de sécurité :

L’authentification du serveur permet aux utilisateurs d'avoir confiance qu'ils communiquent avec le serveur d'application réel. Sans cette garantie, il ne peut y avoir de garantie de confidentialité ou d'intégrité.
La confidentialité des données signifie que les espions ne peuvent comprendre le contenu des communications entre le navigateur et le serveur web, car les données sont chiffrées.
L’intégrité des données signifie qu'un attaquant du réseau ne peut pas endommager ou modifier le contenu des communications entre le navigateur et le serveur web, car elles sont validées par un code d'authentification en message cryptographique.

Le HTTP ne fournit aucune garantie de sécurité et les applications qui l'utilisent ne peuvent pas vraiment fournir de sécurité à leurs utilisateurs. Lorsque vous utilisez une application Web hébergée via HTTP, les gens n'ont aucun moyen de savoir s’ils parlent au serveur d'application réel, et ne peuvent s’assurer que les attaquants n'ont pas lu ou modifié des communications entre l'ordinateur et le serveur.
Modes d'attaque et de Defense

De quelque manière que les utilisateurs se connectent à l'Internet, il existe une variété de personnes qui peuvent les attaquer, que ce soit en les espionnant, en les imitant, en falsifiant leurs communications, ou en faisant tout cela en même temps. L'opérateur du réseau Wi-Fi peut le faire ; n'importe quel FAI se trouvant entre le client et le serveur peut le faire ; quiconque peut reconfigurer le routeur Wi-Fi ou autre routeur peut le faire ; et souvent, n'importe qui d'autre utilisant le même réseau peut le faire aussi.

Firesheep est un exemple d'attaque de réseau passive : il intercepte le contenu des communications réseau entre le navigateur et le serveur, mais ne les redirige pas et ne les modifie pas. Les programmes gouvernementaux de surveillance tels que XKeyscore utilisent également des attaques passives sur le trafic HTTP pour recueillir des quantités massives de données relatives aux communications en ligne.

En revanche, d’autres outils disponibles gratuitement effectuent des attaques de réseau actives, où l'attaquant modifie le contenu ou redirige les communications. Ces outils varient du grave, tel que sslstrip, au ridicule, tel que le Upside-Down-Ternet. Bien que Upside-Down-Ternet soit une farce drôle, il est techniquement identique à des attaques potentiellement plus destructrices telles qu’une attaque injectant du code malveillant ou des renseignements inexacts dans des pages web ; en même temps, il montre que ces attaques sont assez faciles pour être des blagues. Les points d’accès Wi-Fi ont été connus pour injecter des publicités dynamiquement dans pages Web que visitent leurs utilisateurs, montrant que les attaques actives de réseau consitituent un modèle d'affaires viable. Des outils comme Caïn and Abel permettent une série d'attaques, y compris la redirection du trafic de réseau local à travers le système de l'attaquant. (Voir aussi Arpspoof et dsniff).

Seul un mécanisme offrant (au minimum) l'authentification, la confidentialité et l'intégrité des données peuvent défendre contre une série d'attaques. Actuellement, le protocole HTTPS est notre meilleure option concernant les applications Web.

Cependant, il y a quelques pièges potentiels que les opérateurs de site doivent éviter afin de déployer HTTPS en toute sécurité.
Contenu mixte

En hébergeant une application via HTTPS, il ne doit y avoir aucun contenu mixte ; autrement dit, tout le contenu de la page doit être obtenu via HTTPS. Il est fréquent de voir une prise en charge partielle de HTTPS sur les sites, où les pages principales sont récupérés via HTTPS, mais certains ou tous les éléments multimédias, feuilles de style et JavaScript de la page sont récupérés via HTTP.

Cela est dangereux parce que même si le chargement de la page principale est protégé contre les attaques de réseau actives et passives, aucune des autres ressources ne l’est. Si une page charge du code JavaScript ou CSS via HTTP, un attaquant peut fournir un fichier de code falsifié et malveillant et prendre en charge le DOM (Document Object Model) de la page une fois chargé. Ainsi, l'utilisateur serait de retour à une situation non sécurisée. C’est pourquoi tous les principaux navigateurs avertissent les utilisateurs concernant les pages qui chargent du contenu mixte. Pareillement, il n'est pas sécurisé de référencer des images via HTTP : Que se passe-t-il par exemple si l'attaquant inverse les icônes pour Enregistrer et pour Sauvegarder un message dans une application de messagerie Web ?

Vous devez fournir l’ensemble du domaine de l'application via HTTPS. Redirigez les requêtes HTTP avec des réponses HTTP 301 ou 302 à la ressource HTTPS équivalente.

Certains opérateurs de site fournissent uniquement la page de connexion via HTTPS, s’appuyant sur la théorie que seul le mot de passe de l’utilisateur est sensible. Les utilisateurs de ces sites sont vulnérables aux attaques passives et actives.

Malheureusement, beaucoup de sites chargent aujourd’hui du contenu à partir de sites externes et utilisent du CDN (Content Delivery Network) qui ne prend pas en charge le protocole HTTPS. S'il n'est pas possible de servir ces ressources à partir de votre propre hôte ou d’un autre prenant en charge le protocole HTTPS, vous devriez inviter ces sites à commencer à offrir HTTPS dans l’immédiat.
Sécurité et Cookies

Comme Chris Palmer le décrit dans une publication sur la gestion de session sécurisée pour les applications web, les opérateurs de site doivent limiter les cookies sensibles (tels que les cookies utilisés pour l'authentification de l'utilisateur) à une origine sécurisée. Si un cookie a une large portée (avec l'attribut Domain dans le Set-Cookie défini en tant que : header), il peut « diivulguer » des informations à d'autres hôtes ou applications (potentiellement moins sécurisés) du même domaine.

L'application doit également définir l'attribut Secure sur le cookie lors de l'installation. Cet attribut indique au navigateur d’envoyer le cookie uniquement via un transport sécurisé (HTTPS) et jamais via un transport non sécurisé (HTTP).
Utiliser le HTTP Strict Transport Security

Le HTSTS (HTTP Strict Transport Security) est une extension du protocole HTTP qui permet aux opérateurs de site d'ordonner aux navigateurs de demander à ce que le site utilise le protocole HTTPS.

Bien que tous les navigateurs ne prennent pas encore en charge HSTS, l’EFF invite tous ceux qui ne font pas (nous pensons surtout à vous, Apple et Microsoft) à suivre l'exemple donné par Google, Opera et Mozilla en adoptant ce mécanisme de sécurité utile. En effet, au bout du compte, nous prévoyons que HTTPS (et éventuellement de nouveaux protocoles tels que SPDY et QUIC) remplacera entièrement HTTP, tout comme SSH a remplacé Telnet et rsh.

Comme précaution supplémentaire, votre site doit prendre en charge la précharge du HSTS, qui empêche l'interception d'une requête HTTP si le navigateur n'a pas encore reçu d’en-tête HSTS valide depuis le serveur. La précharge du HSTS est implémentée via une liste de domaines avec option d’adhésion incluse dans Chrome, Google Chrome et Firefox. Voir la page de Chromium pour obtenir des instructions sur comment ajouter votre site à cette liste. Notez que vous devez également envoyer un en-tête de HSTS avec un max-age (âge maximum) d’une valeur supérieure à 18 semaines pour que Firefox inclue votre site dans sa liste de précharge HSTS.

Nous avons récemment activé HSTS et la précharge HSTS pour eff.org. Il nous a fallu moins d'une heure pour mettre cela en place, et nous avons trouvé le moyen de le faire sans rediriger de manière forcée les utilisateurs vers HTTPS, nous pouvons donc affirmer une préférence claire pour l'accès HTTPS en gardant le site toujours disponible via HTTP. Cela a fonctionné comme un charme et un pourcentage important de nos utilisateurs accède désormais automatiquement à notre site en HTTPS, peut-être sans même le savoir.
Choisir des protocoles rigoureux et des suites de chiffrement

Voici une brève liste de recommandations pour choisir les protocoles sécurisés et les suites de chiffrement d’un déploiement SSL :

Désactivez la prise en charge de SSLv2, SSLv3, and TLS 1.0.
Activez la prise en charge TLS 1.1 et 1.2.
Désactivez les suites de chiffrement NULL, aNULL et eNULL, qui n'offrent pas en même temps le chiffrement et l’authentification.
Utilisez des clés privées qui sont au moins aussi sûres qu'une clé RSA de 2048 bits.
Préférez des suites de chiffrement qui incluent l'échange de clés Diffie-Hellman éphémères. Celles-ci offrent le caractéristique important de Perfect Forward Secrecy (Confidentialité persistante parfaite), qui empêche le décryptage de votre trafic Web récent si votre clé privée SSL est compromise à l’avenir.
Désactivez les suites de chiffrement avec des tailles de clés inférieures à 128 bits pour le chiffrement.
Désactivez les suites de chiffrement utilisant MD5 pour le hachage. SHA-1 est également déconseillé mais peut être requis pour la compatibilité avec TLS 1.0 et SSLv3.
Désactivez les suites de chiffrement qui utilisent RC4 pour le chiffrement. AES-CBC est préférable au RC4 mais vulnérable à une attaque BEAST. Ainsi, AES-GCM est souvent recommandé.
Désactivez la compression de TLS afin d'éviter l'attaque CRIME.
Offrez uniquement la prise en charge de renégociations de TLS sécurisées conformes à RFC 5746, ou désactivez complètement la renégociation TLS.

Un outil utile pour tester les faiblesses connues dans un déploiement existant de HTTPS est le SSL Server Test de Qualys.
Préoccupations en matière de rendement

Plusieurs opérateurs de site indiquent qu'ils ne peuvent pas migrer leurs sites vers HTTPS pour des raisons de rendement. Cependant, la plupart des gens qui disent cela n'ont pas réellement mesuré la perte de rendement, n’ont peut-être pas du tout mesuré le rendement, et n'ont pas profilé ni optimisé le comportement de leur site. Habituellement, les sites ont une latence beaucoup plus élevée ou un débit beaucoup plus bas que nécessaire même en hébergeant le site via HTTP, ce qui indique que le HTTPS n'est pas le problème.

La clé du problème de rendement se trouve souvent à la couche de contenu ou encore à la couche de base de données. Après tout, les applications Web sont fondamentalement gourmandes en E/S. Prenez en considération cette sagesse des développeurs de Gmail :

Nous avons d’abord répertorié toutes les transactions entre le navigateur et les serveurs de Google, à partir de l'instant ou le bouton « Se connecter » est appuyé. Pour ce faire, nous avons utilisé un grand nombre d'outils de développement Web, comme Httpwatch, WireShark et Fiddler, ainsi que nos propres systèmes de mesure de rendement. [...]

Nous avons passé des heures penchés sur ces traces pour voir exactement ce qui se passait entre le navigateur et Gmail pendant la séquence de connexion, et nous avons trouvé qu'il y avait entre quatorze et vingt-quatre requêtes HTTP pour pouvoir charger et afficher une boîte de réception. Pour mettre ces chiffres en perspective, la page d’accueil d’un site populaire d’actualités en ligne nécessite autour de 180 demandes pour charger entièrement, comme je l'ai vérifié hier. Mais quand nous avons examiné ces demandes, nous avons réalisé que nous pouvions faire mieux. Nous avons décidé d'attaquer le problème à partir de plusieurs angles à la fois : réduire le nombre de requêtes globales, rendre plus de demandes mises en cache par le navigateur et réduire les frais généraux de chaque demande.

Nous avons fait de bons progrès sur tous les fronts. Nous avons réduit le poids de chaque requête proprement dite en éliminant ou en réduisant la portée de certains de nos cookies. Nous avons fait en sorte que toutes nos images soient mises en cache par le navigateur, et nous avons consolidé les images de petites icônes dans de simples meta-images, une technique connue comme spriting. Nous avons combiné plusieurs demandes en une seule demande et réponse combinée. Le résultat est qu'il faut maintenant aussi peu que quatre demandes après avoir cliqué sur le bouton « Se connecter » pour afficher votre boîte de réception.

Adam Langley de Google fournit des détails supplémentaires :

Pour cela nous n’avons pas eu besoin de déployer de machine supplémentaire ou de matériel spécial. Sur nos ordinateurs frontaux de production, SSL/TLS consomme mois de 1 % de CPU, moins de 10 Ko de mémoire par connexion et moins de 2 % de la charge réseau. Beaucoup de gens croient que SSL consomme beaucoup de temps processeur et nous espérons que les chiffres ci-dessus (rendus publics pour la première fois) aideront à dissiper ce fait. [italiques dans l'original]

Faut-il s'étonner que Gmail fonctionne bien, même s’il utilise exclusivement HTTPS ? Les opérateurs de site peuvent apporter des améliorations graduelles en ajustant progressivement leurs applications Web. Chris a fait un exposé à cet effet à Web 2.0 Expo 2009.
Conclusion

Le protocole HTTPS fournit la base de la sécurité pour les utilisateurs d'applications Web, et il n'y a aucune raison relative au rendement ou aux coûts pour rester sur du HTTP. Les fournisseurs d'applications Web sapent leurs modèles d'entreprise lorsque, en continuant à utiliser le protocole HTTP, ils permettent à un large éventail d'attaquants n'importe où sur l'internet de compromettre les informations de leurs utilisateurs.

[WinstonWolfe]

C'est un point du vue intéressant. La condescendance à l'égard de Tugdual me gêne un peu, par contre. J'ose y voir une maladresse...

[freeshost]

Je ne suis pas le seul chantre des libertés et droits numériques.

[3enfants]

Bonjour,
j'ai une suggestion à faire pour la partie "présentation" : on pourrait mettre une balise à nos présentations, ainsi dès le titre, on saurait si on se présente en tant que parent d'enfant ayant un TSA, en tant que personne ayant un TSA, ou parent TSA d'enfant TSA, ou professionnel, étudiant...
Merci.


Modération (Loup) : Déplacement du message dans le sujet correspondant.

[Loup]

On en a discuté mais ça nous semble un peu lourd à l'utilisation (déjà qu'on a un système de balises dans "arts et littérature" et dans "à propos..."). La mention sur la signature nous semble déjà bien suffisante.

[Benoit]

Vu que vous évoquez l' "organisation de rencontres" dans la charte, est-ce envisageable qu'à terme un jour on puisse utiliser le forum pour faciliter les rendez-vous, faire des groupes entre personnes qui se connaissent et / ou même avoir un site "mobile" ?