Discussion :

[RyzenOC]

Ben ouais, moi je trouve ça complètement normalement, le principe d'un certificat c'est qu'il soit signé par un tiers de confiance. Si cette condition n'est pas remplie il est complètement normal que le navigateur affiche une alerte à ce sujet puisque seul toi atteste assure que c'est bien toi (super comme garantie !)

Quid du site le plus sécurisé ? http ou https non certifier ?
Mon site c'est pas un site de banque hein, c'est juste un simple chat avec aucune info confidentiel. Le https pour moi, sa permets au pirate de ne pas déchiffrer les messages des internautes, que le certificat soit signer ou pas sa change rien (a moins que je n'ai rien compris au ssl ? et au chiffrement par clé publique/privée)

Pour le reste, cela dit, ça n'a rien de bloquant. Après on peut discuter de la probabilité qu'un utilisateur lambda continue sa navigation, mais là ça rentre dans le subjectif, donc je ne m'y aventurerai pas.

Bah si discutons justement, sa me semble être justement le fond du problème. Un certificat ssl c'est cher, pour les petits comme moi qui n'ont comme serveur qu'un modeste raspberry et qui ne mettent pas de pub sur leurs site. Surtout pour des sites qui n'ont pas besoin de chiffrer les connections.

StartSSl a 10ans de retard, (faut refaire un compte chaque année )

Bientôt je vais m'agrandir, je vais acheter un raspberry 2 le certificat ssl c'est le prix de mon serveur.

[Matthieu Vergne]

De mon côté je ne vois pas trop l'intérêt de passer tout le web en https. Par contre si ce sont des fonctionnalités nécessitant de faire transiter des données sensibles, là, ok, pourquoi ne pas exiger du HTTPS

L'intérêt est que tu n'as plus besoin de te demander si tu as effectivement des données sensibles qui transitent ou pas. Sur un forum où les gens sont censés parler de la pluie et du beau temps, par exemple, rien n'empêche certains d'échanger des messages plus personnels sur des sujets plus ou moins cachés dans les méandres du forum, ou (plus intelligemment) par MP. Cependant, ces messages privés transitant en clair sur le réseau, n'importe qui sniffant la chose y aura accès. Le fait de tout passer en HTTPS te permet d'être sûr que ce qui a besoin de l'être l'est. Pour ce qui n'a pas besoin de l'être... qui peut le plus peut le moins : le fait que ça passe par HTTPS n'apporte pas d'inconvénient particulier* (ou pour les gens plus rigoureux, pas d'inconvénient notable), on n'a donc pas de raison spécifique d'être contre... sauf si on souhaite que ces donnés puissent être utilisées dans un autre but que celui escompté.

* Pour les inconvénients du HTTPS, on pourra regarder là :http://www.developpez.com/actu/78832...-du-protocole/
Et pour ce que j'en ai lu de la source, si les coûts supplémentaires semblent être significatifs, ils semblent être suffisamment acceptable pour que "50% of web traffic flows today are secure, including, for the first time, large content (e.g., 50% of YouTube streaming flows are over HTTPS)", après tout, une augmentation de 50% de pas grand chose, ça reste toujours pas grand chose (merci de ne pas me sortir le paradoxe sorite, je fais pas dans le récursif), et il y a de quoi se dire que ces problèmes diminueront dans le futur.

[RyzenOC]

sauf si on souhaite que ces donnés puissent être utilisées dans un autre but que celui escompté.

Si on a la clé privée, le cryptage ne sert a rien.

Nos cher gouvernement discute en se moment même si faudrait pas interdire le chiffrement, afin de pouvoir "assurer notre protection".

[Matthieu Vergne]

Si on a la clé privée, le cryptage ne sert a rien.

Je vois pas le lien entre ce que tu cites et cet argument. Tu peux clarifier ?

[Spartacusply]

Quid du site le plus sécurisé ? http ou https non certifier ?

Le http n'a pas de sécurité et le certificat auto signé une sécurité de valeur nulle.
Certes il encrypte toujours les données, mais ne garantis en rien de ton intégrité. Or un certificat fait les deux, toujours, il te garantis de l'encryption des données ET que tu les transmet à la "bonne" personne.

Après je comprend bien ton argument de "modeste site sans info perso" et que tu te fous du deuxième intérêt du certificat, le truc c'est que tu pourrais très bien coder un site banque avec ce certificat justement, donc ton navigateur gueulera toujours de la même manière peu importe ce qui se trouve derrière.

[yann2]

Rebonjour

L'intérêt est que tu n'as plus besoin de te demander si tu as effectivement des données sensibles qui transitent ou pas. Sur un forum où les gens sont censés parler de la pluie et du beau temps, par exemple, rien n'empêche certains d'échanger des messages plus personnels sur des sujets plus ou moins cachés dans les méandres du forum, ou (plus intelligemment) par MP. Cependant, ces messages privés transitant en clair sur le réseau, n'importe qui sniffant la chose y aura accès. Le fait de tout passer en HTTPS te permet d'être sûr que ce qui a besoin de l'être l'est. Pour ce qui n'a pas besoin de l'être... qui peut le plus peut le moins : le fait que ça passe par HTTPS n'apporte pas d'inconvénient particulier* (ou pour les gens plus rigoureux, pas d'inconvénient notable), on n'a donc pas de raison spécifique d'être contre... sauf si on souhaite que ces donnés puissent être utilisées dans un autre but que celui escompté.

Je ne crois pas qu'utiliser HTTPS dispense de se poser la question sur la sensibilité des données. Par exemple, on ne stocke pas des mots de passes en clair. Ou, encore, on ne permet pas à tout le monde de voir les messages privés d'un utilisateur du forum. Bref, ce n'est pas vraiment un bon argument.

Si, demain, j'ouvre site web statique pour y écrire des articles, je suis obligé de le mettre en HTTPS parce que Mozilla le veut ? Je ne comprend pas trop l'intérêt.

[Matthieu Vergne]

Je ne crois pas qu'utiliser HTTPS dispense de se poser la question sur la sensibilité des données. Par exemple, on ne stocke pas des mots de passes en clair. Ou, encore, on ne permet pas à tout le monde de voir les messages privés d'un utilisateur du forum.

Attention, on ne parle pas de stockage mais de communication : HTTPS c'est quand tu envois les données ou quand tu les demandes. Si par exemple je stocke les mots de passe avec un super algorithme de cryptage, par exemple un masque jetable, mais que quand tu me demandes d'afficher ton profil je t'affiche le mot de passe décrypté, on se fiche pas mal de comment je stock ton mot de passe : un Man-in-the-Middle (MitM) pour intercepter la communication et ton mot de passe on l'obtient, indépendamment de comment tu stock ton mot de passe. Même si on part du principe qu'on stock un hash salé, donc "impossible" de retrouver le mot de passe en clair, si quand tu changes ton mot de passe c'est une connexion HTTP et non HTTPS, un MitM permet de voir le mot de passe passer en clair vers le serveur. Certes il y sera hashé puis oublié, mais le mal est déjà fait.

Après, je suis d'accord que ça ne dispose pas de se poser la question. Mais il y a des cas où tu est tout simplement incapable de répondre à la question, tout simplement parce que tu n'as pas les connaissances suffisantes sur le contenu. Le cas du mot de passe, le gestionnaire du site sait que quel que soit le contenu c'est un mot de passe, utilisé dans des champs définis du site, et donc une donnée sensible. Le contenu d'un message privé, en revanche, ça dépend du contenu, et je doute que beaucoup soient diplômés d'une école agréée en voyance. Dans ce cas de figure, l'approche préventive me semble s'appliquer : on chiffre la communication pour s'assurer que le message ne sera en clair qu'à chaque bout, là où l'auteur s'attend à ce que ça le soit, et pas ailleurs. A contrario, l'approche "ben si c'est sensible il a qu'à le dire ailleurs" présuppose que l'utilisateur est suffisamment formé pour évaluer :
- la sensibilité de ses données
- le risque de les voir fuiter
- si fuite il y a, le risque de les voir utilisées abusivement
- les dangers de telles utilisations
- quels sites lui permettent de minimiser tout ça

Ça implique de partir du principe que tout le monde a été formé en réseaux sociaux, big data, attaques réseaux et j'en passe. Quand on parle d'utilisateur lambda, ça n'a pas de sens.

[Laurent 1973]

Le problème du https c'est qu'il inclus 2 notions différentes:
- La cryto des données transférées.
- La validation que le site distant est de confiance.
On peux vouloir le premier (clef auto-généré, facile à faire) sans vouloir le deuxième qui nécessite un "petit" contrôle de la personne morale ou physique qui fait cette demande.
Je suppose, bien que je trouve le service un peu chère quand même, que ce contrôle de la véracité de la personne demandante coûte un peu à la société validatrice.

Sinon, je peux comprendre pour la sécurité numérique que Mozilla s'enflamme contre le HTTP mais quand est-il des emails?
Il y a bien de l'authentification ssl sur les serveurs SMTP/POP/IMAP, mais la communication intra-serveurs se fait-elle toujours suivant des trames sécurisées?
Et même si nous utilisons de l'authentification SSL sur notre compte email, est-on sur que notre correspondant fait de même et ne récupère pas votre message en clair sur le net?
Combien parmi nous utilisons des emails cryptés?

Je me demande à quel point il y aurait pas plus de données sensible qui passent par les protocoles d'emails que par des sites en http non sécurisé....
Est ce que Thunderbird n'acceptera bientôt à l'avenir que des emails cryptés?

[RyzenOC]

Je vois pas le lien entre ce que tu cites et cet argument. Tu peux clarifier ?

J'ai du mal comprendre ce que tu as voulue dire, je voulais dire que si un développeur malveillant veut espionner le trafique du site, si il a la clé privée, il peut sans problème.

Dans l'https ce qui m'interesse c'est la crypto, la certification (payante) je m'en balance comme de l'an 40.

Moi ce que je comprend pas, c'est pourquoi un site de e-commerce en http sa passe nickel alors qu'en https (non certifié) on nous agresse que ce site et potentiellement dangereux ? alors que d'un point de vue purement technique c'est l'inverse.

Je paye un abonnement internet (30€/mois), un nom de domaine (10€/ans), le courant de mon serveur (3Watt) il est hors de question que je paye encore un autre service (je sais je suis radin ) dont je ne vois pas l'utilité pour mon site.

Au final c'est l'utilisateur qui se fait avoir, il donne ces coordonnées bancaire a un site non sécurisé (http), alors qu'il aurait mieux value de les données a un site avec une connexion cryptée, mais que sont navigateur déconseille.

Je considère un internaute comme un néophyte, pas un expert comme sur ce site, si il voit sont navigateur devenir rouge l'invitant a fuir mon site car il est dangereux, il le fait.

HS: L'année dernière je me rappelle avoir incendier MS car leur filtre smartscreen bloquait mon site (sans raison), ils ont corriger le probleme assez rapidement cela dit, en jour c'était reglé

[Matthieu Vergne]

je voulais dire que si un développeur malveillant veut espionner le trafique du site, si il a la clé privée, il peut sans problème.

Je suis tout à fait d'accord.

Dans l'https ce qui m'interesse c'est la crypto, la certification (payante) je m'en balance comme de l'an 40.

Moi ce que je comprend pas, c'est pourquoi un site de e-commerce en http sa passe nickel alors qu'en https (non certifié) on nous agresse que ce site et potentiellement dangereux ? alors que d'un point de vue purement technique c'est l'inverse.

N'importe qui peut se faire son propre certificat. Comme dit précédemment, il n'y a pas que la crypto bout en bout qui intervient, mais aussi la certification que celui qui est à l'autre bout est bien celui qu'il prétend être. En particulier, c'est ses propres clés qui sont utilisés pour crypter/décrypter les données : le principe de la crypto asymétrique est que tu utilises bien la clé publique du serveur que tu souhaites contacter, pour que seul celui-ci puisse décrypter le message. Ce n'est pas simplement de crypter les données, mais de s'assurer que les données n'arrivent qu'à celui qui est censé les recevoir. En ce sens, rien ne m'empêche de dire que je suis Google et de fournir mon propre certificat avec ma propre clé publique qui correspond à ma propre clé privée. C'est à cause de ça que les auto-certifiés ne sont pas valides, et c'est cela que les organismes de certification doivent permettre d'éviter.

Par contre, je suis d'accord que si la seule notion d'identité à considérer est "le site que j'ai contacté", alors il n'y a pas besoin de s'assurer que le site correspond à un site nommément identifié : la phase de contact dudit site met en place la connexion sécurisée de façon à s'assurer que tout futur message envoyé pour ce site (identifié à la volée) sera toujours lisible uniquement par celui-ci. Je sais pas si j'ai été clair, mais je suis d'accord qu'il y a 2 notions mélangées qui mériteraient d'être séparées.

[RyzenOC]

tout a fait d'accord, j'aimerais bien avoir un autre système permettant de crypter les transmissions, sans certification et sans l'entité qui a soumis la certification du coup.

[Matthieu Vergne]

C'est ce que me semble permettre Let's Encrypt. C'est toujours le même système, mais on met moins d'importance à connaître les détails de l'identité dudit site. Tant que c'est le site en question, peu importe le reste.

[Spartacusply]

Bon ceci dit je vois vraiment pas ce que vous lui reprocher à startssl.com, je viens encore de me créer un certificat à l'instant, en 5 minutes c'était installé.

[Matthieu Vergne]

Si j'ai bien compris, c'est le service après vente qui serait mal foutu : tant que tout va bien, ça va bien, mais si quelque chose va mal, ça va très mal.

[TiranusKBX]

Si j'ai bien compris, c'est le service après vente qui serait mal foutu : tant que tout va bien, ça va bien, mais si quelque chose va mal, ça va très mal.

le service après vente chez eux ?

• Réponse en 7/8 jours
• En cas d'inaccessibilité compte -> tu doit t'en recréer un(mais bien-sûr avec un autre email)
• si un certif en cours est sur un autre compte pour un site tu ne peut pas lui en re-générer un avant son expiration
• tu doit faire du copié/collé des données certificats pour les récupérer, la concurrence te donne les fichiers
• la vérification de l'identité pour les services payants et longue, requiert 2 pièces d'identité(et si j'ai pas de passeport ni permis de conduire ?) et payante

[tontonnux]

Après on peut discuter de la probabilité qu'un utilisateur lambda continue sa navigation, mais là ça rentre dans le subjectif, donc je ne m'y aventurerai pas.

Cela dit, à partir du moment où Mozilla considère l'auto certification comme non sûre, il y a fort à parier qu'au final les sites concernés soient tout simplement considérés comme des site http classiques.
De fait, ils auraient probablement les mêmes limitations au sein de Firefox.

[Spartacusply]

le service après vente chez eux ?

• Réponse en 7/8 jours
• En cas d'inaccessibilité compte -> tu doit t'en recréer un(mais bien-sûr avec un autre email)
• si un certif en cours est sur un autre compte pour un site tu ne peut pas lui en re-générer un avant son expiration
• tu doit faire du copié/collé des données certificats pour les récupérer, la concurrence te donne les fichiers
• la vérification de l'identité pour les services payants et longue, requiert 2 pièces d'identité(et si j'ai pas de passeport ni permis de conduire ?) et payante

Nan mais moi je parle du service gratuit, si payant t'es pas content, c'est pas la concurrence qui manque.

[TiranusKBX]

je n'ai que une ligne sur la payant

[yann2]

Attention, on ne parle pas de stockage mais de communication : HTTPS c'est quand tu envois les données ou quand tu les demandes. Si par exemple je stocke les mots de passe avec un super algorithme de cryptage, par exemple un masque jetable, mais que quand tu me demandes d'afficher ton profil je t'affiche le mot de passe décrypté, on se fiche pas mal de comment je stock ton mot de passe : un Man-in-the-Middle (MitM) pour intercepter la communication et ton mot de passe on l'obtient, indépendamment de comment tu stock ton mot de passe. Même si on part du principe qu'on stock un hash salé, donc "impossible" de retrouver le mot de passe en clair, si quand tu changes ton mot de passe c'est une connexion HTTP et non HTTPS, un MitM permet de voir le mot de passe passer en clair vers le serveur. Certes il y sera hashé puis oublié, mais le mal est déjà fait.

Après, je suis d'accord que ça ne dispose pas de se poser la question. Mais il y a des cas où tu est tout simplement incapable de répondre à la question, tout simplement parce que tu n'as pas les connaissances suffisantes sur le contenu. Le cas du mot de passe, le gestionnaire du site sait que quel que soit le contenu c'est un mot de passe, utilisé dans des champs définis du site, et donc une donnée sensible. Le contenu d'un message privé, en revanche, ça dépend du contenu, et je doute que beaucoup soient diplômés d'une école agréée en voyance. Dans ce cas de figure, l'approche préventive me semble s'appliquer : on chiffre la communication pour s'assurer que le message ne sera en clair qu'à chaque bout, là où l'auteur s'attend à ce que ça le soit, et pas ailleurs. A contrario, l'approche "ben si c'est sensible il a qu'à le dire ailleurs" présuppose que l'utilisateur est suffisamment formé pour évaluer :
- la sensibilité de ses données
- le risque de les voir fuiter
- si fuite il y a, le risque de les voir utilisées abusivement
- les dangers de telles utilisations
- quels sites lui permettent de minimiser tout ça

Ça implique de partir du principe que tout le monde a été formé en réseaux sociaux, big data, attaques réseaux et j'en passe. Quand on parle d'utilisateur lambda, ça n'a pas de sens.

Oui ben je sais bien qu'on parle de transport, je sais ce qu'est HTTP sinon je ne répondrai pas . Je voulais juste attirer l'attention sur le fait que ce n'est pas parce que le transport est sécurisé qu'on ne doit plus se poser des question sur quelles données sont sensibles.
Je n'aime pas qu'on impose HTTPS pour une raison principale : ça déresponsabilise. Quand on connait l'ampleur des sites vulnérables aux injections SQL, par exemple, je suis persuadé que certaines personnes vont penser que vu que leur site est en HTTPS, c'est bon, c'est "secure". Je prend l'exemple des injections SQL parce que c'est quelque chose de très simple à sécuriser mais, pourtant, ça ne l'est pas. Ça prouve que peu de créateurs de sites internets sont sensibilisés à la sécurité. Ce n'est pas à Mozilla ou M Michou de choisir si un site doit être accessible via HTTPS. C'est un expert en sécurité qui doit prendre cette décision et, surtout, il doit être capable de justifier son choix.

J'aime bien l'exemple des messages. Prenons la messagerie google : gmail. C'est accessible via HTTPS mais, n'importe qui peut faire un client HTTP et, surtout, ça ne protège pas du tout le contenu puisqu'il est, à minima, lu par google et la NSA. Bref, HTTPS c'est juste un premier niveau de protection mais bon... toutefois, je comprend parfaitement vos exemples et je suis tout à fait d'accord que des messages privés devraient toujours transiter via HTTPS. Cependant, je pourrai vous citer des tas d'autres exemples où HTTPS est complétement inutile.

[Matthieu Vergne]

je pourrai vous citer des tas d'autres exemples où HTTPS est complétement inutile.

Inutile, je n'en doute pas, mais qu'en est-il des cas où il est gênant ? Un cas où ça n'a ni avantage ni inconvénient, c'est un cas qui ne vaut pas comme argument. Du point de vue de la déresponsabilisation, je suis à moitié d'accord : être responsable consiste à prendre les décisions et à en rendre compte, et la déresponsabilisation consiste à enlever ce pouvoir de décision. Cependant je ne vois pas où est le mal ici, car on passe d'un état où il faut décider si on crypte ou non à un état où tout est crypté, qui est a priori mieux au sens de Pareto (au moins un avantage pour aucun inconvénient). Garder la possibilité de choisir, à ce niveau là, c'est se garder la possibilité de faire des bétises.

Je comprendrais ta remarque si tu me donnais des cas où HTTPS est gênant, mais je n'en ai toujours pas vu, donc j'attends. Par contre je ne prendrai pas en compte les arguments du style "il faut payer pour avoir un certificat", ni "l'auto-certifié apparait comme non sécurisé sur les navigateurs", et cela pour deux raisons :
- le tout HTTPS prôné par Mozilla n'est pas pour maintenant, là, tout de suite ; il convient donc de le prendre en compte dans une vision d'avenir et non avec le biais de ce qui se fait seulement maintenant,
- Mozilla fait partie du projet Let's Encrypt qui prévoit de fournir des certificats à la demande, valides et gratuits, et cela dans le courant de l'année (prévu pour mi-2015) c'est à dire un avenir proche, ce qui met à bas ces deux arguments et donc justifie le fait de ne pas les prendre en compte, tout du moins jusqu'à finalisation de ce projet.

Donc si tu as d'autres arguments montrant que le tout HTTPS est gênant soit pour l'utilisateur, soit pour l'admin du site, je suis tout ouïe.