Journal HTTP poussé vers la sortie ?

Posté par Spack le 03 mai 2015 à 13:36. Licence CC By‑SA.

Étiquettes :

mai

2015

Accompagnée d'organisations telles que l'IETF ou le W3C, la fondation Mozilla a annoncée son intention de mettre fin au support du protocole HTTP dans sa forme non sécurisée et souhaite encourager la mise en place de TLS pour la plupart des sites Web. L'équipe de Chromium elle aussi y pense fortement.

En effet l'ambiance du moment est de retirer les protocoles en texte clair de l'usage d'Internet afin d'assurer une meilleure protection de la vie privée. Notons aussi que Google attribue un meilleur classement aux sites HTTPS (ironie du sort, leur blog n'est lui pas disponible en HTTPS).

Notons toujours que Mozilla a décidée d'implémenter la prochaine génération du protocole HTTP, HTTP/2, uniquement qu'à travers TLS. Firefox supporte d'ors et déjà ce nouveau protocole depuis la version 36.

Alors si la majeure partie du contenu disponible sur le Web est dit public, il n'empêche que l'usage d'un protocole en texte clair apporte quelques problèmes concernant la vie privée :

il est possible d'espionner tout trafic aussi anodin soit-il et pouvoir établir le profil de l'utilisateur ;
et on peut se permettre de modifier le contenu à la volée.

L'usage exclusif de HTTPS n'est pas non plus sans apporter son lot de soucis. Aussi bien que Mozilla entend bien continuer à supporter HTTP mais n'y apportera aucune nouvelle fonctionnalité. Il n'empêche qu'assurer la bonne sécurité de son site Web via SSL/TLS n'est pas une chose aisée. Rappelons que si l'attaque POODLE [PDF] a été rendu possible, en plus d'un mauvais code, c'est aussi à cause de l'usage répandu du vieux protocole SSLv3 largement déprécié par les versions ultérieurs de TLS. Alors vaut-il mieux être non sécurisé ou mal sécurisé ?

Pour aider à la configuration de son serveur HTTP, Mozilla a mis en ligne un générateur de configuration SSL. Mais un copier/coller sans comprendre ce que l'on fait suffit-il à se croire en sécurité ?

Le système des autorités de certification n'est lui aussi pas parfait. Que faire d'une autorité dont la confiance peut être mise en cause ou d'une à qui on veut bien faire confiance mais qui a du mal à se faire accepter ? Doit-on déléguer la gestion de cette confiance à notre navigateur ? Le projet Certificate Transparency a pour but de répondre a ces questions mais mis, je ne sais pas quelle est la portée de ce projet.

Sans compter qu'obtenir un certificat est le plus souvent payant, ce qui peut être un frein pour les petites structures. Il y a bien des initiatives en cours telles que Let's Encrypt ou SSLMate (payant) pour démocratiser la création de certificats. Mais dans le cas de Let's Encrypt, il reste encore à voir ce que cela donnera à l'usage.

Alors cher journal, prêt à passer à HTTPS ?

# Portail captif.

Posté par robin le 03 mai 2015 à 14:20. Évalué à 3.

Merci pour le journal, c'est très intéressant, et j'espère qu'il va apporter son lot de question.

En parlant de question, comment ça se passe pour les portails captifs ? Il me semble que je n'arrive pas à m'y connecter quand les sites que j'essaie de voir sont en https. (donc le premier onglet que je charge est toujours en http, pour me connecter et ensuite je surf normalement).

Est-ce que c'est une limitation inhérente aux portails captifs, et donc le passage au tout https pourrait poser problème, où est ce qu'il « suffirait » que les admins mettent à jour leur portails ?

bépo powered
- [^] # Re: Portail captif.
  
  Posté par BAud (site web personnel) le 03 mai 2015 à 15:28. Évalué à 8.
  comment ça se passe pour les portails captifs ?
  
  mal :
  - tant pour Mozilla Firefox
  - que pour Google Chrome/Chromium
  La RFC 6585 propose l'ajout d'un code d'erreur HTTP 511 permettant de rediriger vers une page d'authentification préalable.
  
  Le "contournement" pour l'instant reste l'appel d'une page en HTTP puis l'utilisation d'une page en HTTPS.
  
  C'est l'occasion de mieux le prendre en compte avec le HTTP2 ;-)
# Mélange

Posté par Blount (site web personnel) le 03 mai 2015 à 14:21. Évalué à 10.

Le problème, c'est le mélange entre chiffrer une connexion et certifier une connexion.
Vu comment les navigateurs présentent les certificats auto-signés, on a l'impression d'avoir affaire à une escroquerie quand le navigateur balance ça page "d'erreur".
Le HTTP n'est pas certifié, pourtant il n'y a pas ce fameux message d'avertissement alors qu'il est d'autant plus concerné.

S'ils veulent mettre en place un tel système, je pense qu'il faudrait avant tout différencier clairement ces deux points.

Bon, sinon, le prix d'un certificat devient abordable. Chez Gandi, c'est 12€ / an.
- [^] # Re: Mélange
  
  Posté par Antoine le 03 mai 2015 à 14:34. Évalué à 7.
  
  Le problème des certificats est moins leur prix (il y a même des certificats gratuits chez StartSSL) que la charge que représente la gestion des certificats et clés privées : mise en place, sécurisation du stockage, renouvellement.
  
  On peut espérer que https://letsencrypt.org/ résoudra le problème.
- [^] # Re: Mélange
  
  Posté par Zenitram (site web personnel) le 03 mai 2015 à 15:51. Évalué à -10.
  
  Vu comment les navigateurs présentent les certificats auto-signés, on a l'impression d'avoir affaire à une escroquerie quand le navigateur balance ça page "d'erreur".
  
  Comment peux-tu faire la différence entre escroquerie et légitime dans ce cas.
  Parce que bon, c'est quand même pas mal "on ne se connait pas, j'utilise une chaine de confiance inexistante, mais promis c'est moi".
  Les certificats auto-signés (et ceux signés par des autorités qui ne sont pas dans les navigateurs principaux de leurs utilisateurs), c'est mal (à utiliser que pour la machine de test).
  
  Bon, sinon, le prix d'un certificat devient abordable.
  
  Voir 0 (startssl, où tu payes que si tu te fait piquer ton certificat, ce qui est très rare si tu fais un minimum attention).
  - [^] # Re: Mélange
    
    Posté par Blount (site web personnel) le 03 mai 2015 à 16:39. Évalué à 10.
    
    Comment peux-tu faire la différence entre escroquerie et légitime dans ce cas.
    Parce que bon, c'est quand même pas mal "on ne se connait pas, j'utilise une chaine de confiance inexistante, mais promis c'est moi".
    Les certificats auto-signés (et ceux signés par des autorités qui ne sont pas dans les navigateurs principaux de leurs utilisateurs), c'est mal (à utiliser que pour la machine de test).
    
    Tu n'as pas compris ce que je voulais exprimer.
    Je ne remet pas en question le fait de certifier le destinataire mais le mélange fait entre chiffrer et certifier.
    On peut souhaiter chiffrer la connexion entre deux machines sans pour autant demander une certification. Pourquoi un certificat de "confiance" (fourni par un organisme tiers) serait nécessaire pour juste chiffrer une connexion ?
    
    Si on souhaite ensuite avoir un certificat signer par un organisme tiers dans le cas où on souhaiterait aller plus loin dans la sécurité de son site (ecommerce, banque, etc.), alors oui, ce sera effectivement plus approprié.
    
    Dans mon cas, je souhaiterai chiffrer la connexion entre mes utilisateurs et mon blog pour leur vie privée, mais je n'ai pas besoin d'avoir un truc signer par un tiers pour juste chiffrer des données.
    Que ce certificat soit payant ou non ;)
    - [^] # Re: Mélange
      
      Posté par Zenitram (site web personnel) le 03 mai 2015 à 16:49. Évalué à 0. Dernière modification le 03 mai 2015 à 16:50.
      
      Dans mon cas, je souhaiterai chiffrer la connexion entre mes utilisateurs et mon blog pour leur vie privée, mais je n'ai pas besoin d'avoir un truc signer par un tiers pour juste chiffrer des données.
      
      A moins que j'ai loupé un passage, de ce que je comprend du chiffrement aujourd'hui, sans certification tu ne protèges pas la vie privée de tes utilisateurs, à part cas exceptionnel (que celui qui veut regarder ne soit pas sur le chemin).
      
      Veux-tu dire que protéger la vie privée de tes utilisateurs dans le cas exceptionnel où celui qui veut regarder n'est pas sur le chemin (bref, un dump Wifi plutôt que la boite noire chez le FAI, comprenant celui qui fournit le Wifi) te suffirait? Ca me parait bien maigre comme besoin surtout comparé au faible coup de la certification en plus qui apporte quand même beaucoup de mon point de vue.
      - [^] # Re: Mélange
        
        Posté par lockidor le 03 mai 2015 à 18:05. Évalué à 2.
        
        A moins que j'ai loupé un passage, de ce que je comprend du chiffrement aujourd'hui, sans certification tu ne protèges pas la vie privée de tes utilisateurs, à part cas exceptionnel (que celui qui veut regarder ne soit pas sur le chemin).
        
        Justement, si j'ai bien compris ce qu'il voulait dire, il souhaiterait pouvoir découpler la certification et le chiffrement de la communication. Ainsi, il pourrait chiffrer le communications entre ses utilisateurs et son blog sans mettre en branle tout le principe de chaîne de confiance - nécessaire à la certification -, dont il n'a techniquement pas besoin dans ce cas.
        
        [^] # Re: Mélange
        
        Posté par barmic le 03 mai 2015 à 18:15. Évalué à 2.
        
        Qu'est-ce qui m'empêche dans ce cas de proxifier son blog (et donc de récupérer toutes les informations que je veux) ?
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Mélange
        
        Posté par groumly le 03 mai 2015 à 23:03. Évalué à 4.
        
        Le chiffrement ne sert strictement a rien si tu ne sais pas a qui appartient la cle avec laquelle tu chiffre.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Mélange
        
        Posté par Kaane le 05 mai 2015 à 02:36. Évalué à 1.
        
        Le chiffrement ne sert strictement a rien si tu ne sais pas a qui appartient la cle avec laquelle tu chiffre.
        
        Et la certification par tiers n'est qu'une des nombreuses façons de s'assurer du propriétaire. Pour SSH par exemple la certification par tiers est superflue.
        
        De plus que tu connaisses le propriétaire de la clef de chiffrement ou non, tu passes quand même de la situation "tout le monde peut intercepter la communication" à "seules les personnes avec la clef privée peuvent intercepter la communication". Ça fait malgré tout une vraie différence.
        
        Pour finir, on peut imaginer un protocole ou tu demandes au serveur de te répondre en utilisant ta clef publique - là la certification ne sert plus à rien. Et il y aurait pas mal d'applications - en fait à chaque fois que la réponse est sensible, mais pas la question.
        
        [^] # Re: Mélange
        
        Posté par Zenitram (site web personnel) le 05 mai 2015 à 08:18. Évalué à 0.
        
        Pour SSH par exemple la certification par tiers est superflue.
        
        Pardon?
        Que tu répondes "rien à foutre, j'attendais un nouveau fingerprint donc j'accepte n'importe quel fingerprint même si le MITM en profite à ce moment peut-être" quand SSH te dis qu'il y a un nouveau fingerprint ne veut pas dire que tout le monde n'utilise pas de tiers pour transmettre le fingerprint (qui sera vérifié, ou pas)
        De même, on s'amuse souvent à filer sa clé publique à l'admin, qui doit avoir confiance, donc on a un tiers (souvent un site web dans lequel on rentre sa clé publique, donc protection… par HTTPS! donc le système de tiers qui est conspué ici).
        
        Par curiosité, toi qui dit "Pour SSH par exemple la certification par tiers est superflue.", comment fais-tu pour avoir confiance la première fois que tu te connectes à une machine? Toujorus premier accès en physique?
        
        Pour finir, on peut imaginer un protocole ou tu demandes au serveur de te répondre en utilisant ta clef publique - là la certification ne sert plus à rien. Et il y aurait pas mal d'applications - en fait à chaque fois que la réponse est sensible, mais pas la question.
        
        Pas compris : la réponse en chiffrant avec ta clé publique permet que personne ne regarde, mais tout le monde peut envoyer, donc la confiance reste relative (le méchant peut alors t'envoyer de force informations). quelle utilisation vois-tu de chiffrement par clé publique sans authentifier celui qui chiffre.
        
        J'avoue ne pas encore avoir été convaincu par les exemples de chiffrement utile sans authentifier le correspondant… Et encore moins à coup de "pour x la certification par tiers est superflue" balancé comme ça, j'aimerai des arguments sinon je peux aussi dire sans démonstration "chiffrer c'est que vous avez quelque chose à cacher".
        
        [^] # Re: Mélange
        
        Posté par jyes le 05 mai 2015 à 08:40. Évalué à 3.
        
        Ta réponse me laisse penser que ton usage de GPG est très modéré, voire inexistant, pourtant il répond bien au problème de l’identification avec sa toile de confiance qui évite le SPOF que constitue chaque CA. HTTPS malgré ses défauts répond à un certain besoin, mais du point de vue de la sécurité ce n’est quand-même pas la panacée et je suis surpris de ton entêtement à le défendre. Par exemple, dans la pratique, je ne me rappelle jamais avoir récupéré un clé SSH sur une page Web, par contre, plusieurs fois depuis un e-mail signé (en même temps je suis un admin sys amateur du dimanche et veux bien croire que des pratiques différentes sont communes). Je ferais volontiers pareil pour le certificat de mon serveur auto-hébergé si ce n’était pas aussi compliqué pour les utilisateurs de faire accepter un certificat récupéré depuis ailleurs que la page d’alerte de sécurité dans les navigateurs courants. Les « gens du web » (comme dirait Tanguy) ont une vision CA-centriste qui me déçoit.
        
        J'avoue ne pas encore avoir été convaincu par les exemples de chiffrement utile sans authentifier le correspondant…
        
        Je suis d’accord avec toi là dessus. Sauf qu’HTTPS et le système de CA n’est ni la seule, ni la meilleure manière d’authentifier un correspondant.
        
        [^] # Re: Mélange
        
        Posté par groumly le 05 mai 2015 à 09:54. Évalué à 0.
        
        plusieurs fois depuis un e-mail signé
        
        et la cle qui a genere la signature, tu l'as recuperee comment (meme question pour le correspondant)? T'as du faire confiance a un tiers pour t'assurer que t'as recupere la bonne cle publique. C'est pas different d'un systeme de CA.
        Ou alors t'as fait un echange en personne, mais v'la la scalabilite de la solution.
        
        Tu peux tourner le probleme comme tu veux, le but d'https/tls c'est d'etablir un lien de confiance dans un environement pas de confiance.
        A un moment, il va falloir echanger quelque chose, et il va falloir s'assurer qu'on parle bien a la bonne personne. Et evidemment, comme c'est internet, ca se fait tres vite et a tres grande echelle.
        Ya un moment ou va falloir faire confiance a quelqu'un pour authentifier la personne a qui on parle. Si t'as une meilleure idee qu'un tiers de confiance, je suis tout ouie.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Mélange
        
        Posté par diorcety le 05 mai 2015 à 10:18. Évalué à 7.
        
        Justement tu marques, de confiance, les personnes en qui tu as confiance (oula), d'ailleurs il y a plusieurs niveaux de confiance que tu peux attribuer avec GPG.
        
        Effectivement le principe de confiance est le même, mais la comparaison s'arrête la.
        
        Le biais dans ton raisonnement est que tu mets la même confiance envers un ami, un collègue et comodo, digicert et consort (dans la plupart des cas d'autres que l'on ne connais même pas)
        
        La confiance que tu peux attribuer à ses boites est purement virtuelle, elle se basse sur le faite qu'elles sont soit disant sûre et font les vérifications, qu'elles ne sont pas de mèche avec un service de renseignement et que au pire si ce n'est pas le cas, après l'accident, elle mettront la clé sous la porte car elle seront supprimées des CAs du navigateur/OS en qui tu as confiance (il y pas mal de frique en jeu la derrière)
        
        Au final tu compares un système pyramidal de confiance (système des CA) à un système de toile de confiance (GPG). Dans le premier cas faut que un maillon de la chaîne merde pour faillir, ce qui n'est pas(généralement et préférablement) le cas dans le deuxième cas.
        
        [^] # Re: Mélange
        
        Posté par jyes le 06 mai 2015 à 09:24. Évalué à 7.
        
        Si t’as une meilleure idée qu’un tiers de confiance, je suis tout ouïe.
        
        J’ai effectivement dû mal m’exprimer.
        
        PGP ne supprime pas la nécessité d’un tiers de confiance, mais ce tiers est une toile (soit des tiers de confiance) et la confiance que l’on accorde à chacun est pondérée et à la discrétion de l’utilisateur, là où le système de CA n’est qu’une liste de toiles à un fil qui obligent à faire confiance à chaque tiers au bout de chaque fil. Il faut donc identifier chaque tiers individuellement, ce que personne ne fait et préfère considérer que la liste de CA qu’il a récupérée en HTTP avec son Firefox vérolé sur télécharger.com est fiable. PGP permet juste de de ne choisir de faire confiance que si un chemin de confiance — qui peut s’établir uniquement via des échanges de clés sûrs (physiques présentiels) — nous lie au signataire de la ressource à authentifier.
        
        Le système de toile a pour seul défaut (encore majeur pour le moment, je l’admets volontiers) son manque d’utilisateurs à portée des Michu pour établir les premiers fils vers la toile, défaut qui doit beaucoup au peu de support proposé par les gros acteurs du Web. Mais à l’inverse, établir une mini-toile avec des potes ou un client que l’on a l’occasion de rencontrer au moins une fois physiquement, c’est très facile et bien plus sûr que le système des CAs pour lequel on a rarement l’occasion de visiter les bureaux de Verisign avec une clé USB pour récupérer leur empreinte.
        
        [^] # Re: Mélange
        
        Posté par Zenitram (site web personnel) le 05 mai 2015 à 12:14. Évalué à -1.
        
        Ta réponse me laisse penser que ton usage de GPG est très modéré,
        
        Je voulais faire un passage sur GPG puis j'ai oublié.
        GPG = c'est tellement facile à utiliser que quasi personne n'arrive à utiliser.
        Faut arrêter le délire de dire "utilise GPG" : d'abord, il faut fournir un façon simple pour les utilisateurs d'avoir confiance.
        Moi-même je me considère comme pas trop à la ramasse en gestion de sécurité et n'ai rien compris à Enigma pour Thunderbird et de comment on gère le bousin pour arriver à ses fins. Alors je n'ose imaginer l'utiliser moyen des emails…
        
        Par exemple, dans la pratique, je ne me rappelle jamais avoir récupéré un clé SSH sur une page Web, par contre, plusieurs fois depuis un e-mail signé (en même temps je suis un admin sys amateur du dimanche et veux bien croire que des pratiques différentes sont communes).
        
        Ce n'est pas scalable.
        en pratique, tu files ta clé publique sur l'interface d'admin de l'hébergeur et il s'occupe de la mettre sur le serveur (bien sûr, uniquement si tu acceptes qu'il y accède :), généralement je vois ça pour du partagé plutôt, mais l'idée est la : il faut fournir sa clé par un moyen tiers, et je me demande comment les gens qui disent que le tiers est superflu avec SSH font, soit pour filer leur lcé publique soit pour avoir confiance dans le fingerprint SSH à la première connexion bref toujorus cette première connexion… que les décriées CA font, pas 100% sûr mais ce qui s'en approche le plus d'une façon utilisable par le commun des mortels).
        
        [^] # Re: Mélange
        
        Posté par Kaane le 05 mai 2015 à 15:53. Évalué à 1.
        
        Pour clarifier, je ne dis pas que la certification SSH est inutile, mais que la certification par tiers SSH est superflue.
        Une entreprise A monte un serveur SSH, une entreprise B veut accéder à ce SSH (typiquement pour faire du SFTP) dans 99,9% des cas elles ne passeront pas par une entreprise C.
        Après il y a pas mal de méthode pour permettre à la société B de valider le certificat quand même. De la visite des locaux de l'entreprise A à un simple coup de fil.
        C'est d'autant plus vrai que dans la majorité des cas (je pense) la société A et la société B sont une seule et même entité.
        De toutes les façons SSH ne dispose pas de moyen de valider un certificat tiers dans les implémentations les plus courantes. Il va se contenter de vérifier que la clef publique est connue. Si on veut des mécanismes d'expiration, de renouvellement ou de révocation de clef il faut mettre en place des procédures spécifiques - le plus souvent en dehors de SSH.
        
        Pour le chiffrement des données par un serveur en utilisant ma clef publique, cela ne permet effectivement rien d'autre que la protection des données elles-mêmes. Ni l'expéditeur ni la connexion ne sont protégés, seul le contenu l'est. Ça ne sert effectivement que si tu peux faire le tri entre les données désirées et des données non sollicités. Le bon vieux problème ham/spam qui n'a pas franchement empêché les emails de fonctionner.
        
        [^] # Re: Mélange
        
        Posté par Zenitram (site web personnel) le 05 mai 2015 à 18:08. Évalué à 0.
        
        la certification par tiers SSH est superflue
        
        C'est ton idée, pas celle de tout le monde.
        On parlait de CA, mais du coup ton histoire de SSH est hors-sujet : si c'est superflu pour SSH, c'est superflu d'avoir un CA, donc plus de CA, donc plus de problèmes avec HTTPS.
        
        bref, je ne vois pas où tu veux en venir.
        
        Une entreprise A monte un serveur SSH, une entreprise B veut accéder à ce SSH (typiquement pour faire du SFTP) dans 99,9% des cas elles ne passeront pas par une entreprise C.
        
        Oui, elles passent généralement juste par Internet. Euh, attend…
        (perso, ça me fait rire les gens qui proposent du SFTP sans filer le fingerprint par un moyen sûr, en disant que c'est mieux que FTP pas de problème : euh… OK, faisons comme les autres en fait, autant garder FTP, ça suffit comme sécurité en fait. Note que je sais bien que SFTP est quand même mieux car ça évite le MITM après la première connexion et avant que la clé ne change, juste que penser que ça sécurise tout le temps est se mentir, il faut une chaine de confiance à un moment donné, et c'est tout le problème du besoin de CA décrié mais dont on ne propose pas d'alternative pour une généralisation)
        
        [^] # Re: Mélange
        
        Posté par Kaane le 05 mai 2015 à 18:40. Évalué à 7.
        
        bref, je ne vois pas où tu veux en venir.
        
        Le post de référence est celui de Blount qui parle de faire le distinguo entre certification et chiffrement - et je répond à Groumly qui dit
        
        Le chiffrement ne sert strictement a rien si tu ne sais pas a qui appartient la cle avec laquelle tu chiffre.
        
        en disant que la certification par tiers de confiance n'est ni la seule méthode, ni la panacée quand il s'agit de connaitre le propriétaire légitime d'une clef publique. En fait toutes les personnes qui possèdent un CA ont nécessairement utilisé une de ces nombreuses méthodes alternatives pour faire valider ce CA par le tiers de confiance.
        
        En ce qui concerne la transmission de fingerprint, la méthode que j'utilise personnellement est archive chiffrée par mail/envoi physique + mot de passe de l'archive par téléphone. Quand on a "que" quelques centaines de clients, c'est très largement gérable par une équipe de 3 personnes.
        
        Les tiers de confiance ne devraient intervenir que dans le cas ou quelqu'un que je ne connais pas cherche à se connecter chez moi et s'assurant qu'il est bien chez la bonne personne. Là effectivement pas d'autre solutions que de passer par une personne qui nous connait tous les deux.
        
        Pour finir le système de CA est plutôt déficient - de l'avis même de ceux qui opèrent ce genre de système. C'est pour ça qu'on a des certifications "extended validation" et en banque des certificats doublement voire triplement contre-signés - le tout sur des lignes dédiées.
        
        Très honnêtement madame Michu connait beaucoup mieux son agence et son chargé de compte que la société Verisign ou DigiCert. La faire passer par un CA tiers quand elle veut se connecter pour lire ses comptes en ligne ne fait pas sens du point de vue de la sécurité. Donc même en HTTPx sur des utilisations ultra classiques, la certification directe sans tiers de confiance devrait avori son rôle à jouer.
        
        Après reste le problème du coût de mise en place et de l'adoption par les utilisateurs - qui est un problème réel - mais de là à jeter aux orties toute certification directe ou auto-certification…
        
        [^] # Re: Mélange
        
        Posté par groumly le 05 mai 2015 à 10:06. Évalué à -1.
        
        en fait à chaque fois que la réponse est sensible, mais pas la question.
        
        Si la reponse est sensible, tu penses pas que le serveur ferait mieux de s'assurer que c'est bien a toi, Kaane, qu'il envoie la reponse?
        Comment fait il donc pour s'assurer que la cle publique qu'il est la tienne? Tu lui envoye, ok, mais a ce moment la, comment tu t'assures que tu l'envoyes a la bonne personne?
        
        De plus que tu connaisses le propriétaire de la clef de chiffrement ou non, tu passes quand même de la situation "tout le monde peut intercepter la communication" à "seules les personnes avec la clef privée peuvent intercepter la communication". Ça fait malgré tout une vraie différence.
        
        Ca fait pas de difference si n'importe qui peut t'envoyer sa clef privee a lui et que tu n'as pas de moyen de t'assurer de qui est en face de toi.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Mélange
        
        Posté par Anthony Jaguenaud le 05 mai 2015 à 11:02. Évalué à 7.
        
        Ca fait pas de difference si n'importe qui peut t'envoyer sa clef privee a lui et que tu n'as pas de moyen de t'assurer de qui est en face de toi.
        
        Tu n’envoies jamais ta clé privée. Tu transmets ta clé publique. Tout détenteur de ta clé publique pourra :
        
        t’envoyer du contenu chiffrer que toi seul peut déchiffrer ;
        
        vérifier ta signature numérique pour garantir que ton message n’a pas été modifié.
        
        [^] # Re: Mélange
        
        Posté par groumly le 05 mai 2015 à 11:29. Évalué à -10.
        
        Enculeur de mouche, t'as tres bien compris ce que je voulais dire.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Mélange
        
        Posté par Zenitram (site web personnel) le 04 mai 2015 à 07:29. Évalué à 3.
        
        il souhaiterait pouvoir découpler la certification et le chiffrement de la communication.
        
        qu'on m'explique alors l’intérêt de chiffrer si la planète entière peut déchiffrer (vu que la planète entière peut être entre toi et le destinataire sans certification).
        
        Encore une fois, je demande un cas concret de l'utilité du chiffrement sans authentification. A ma connaissance, le chiffrement n'est utile que si tu peux certifier la source. Je demande juste qu'on m'explique en quoi le chiffrement sans certifier la source apporte une quelconque protection de la vie privée de ses utilisateurs.
  - [^] # Re: Mélange
    
    Posté par eingousef le 03 mai 2015 à 18:33. Évalué à 10.
    
    Les certificats auto-signés (et ceux signés par des autorités qui ne sont pas dans les navigateurs principaux de leurs utilisateurs), c'est mal (à utiliser que pour la machine de test).
    
    Ben j'imagine que tu ne te connectes jamais non plus à un serveur ssh sur le net alors, parce qu'à la première connexion il y a un message d'erreur te demandant d'accepter la clé.
    
    *splash!*
    - [^] # Re: Mélange
      
      Posté par jihele le 04 mai 2015 à 10:19. Évalué à 2. Dernière modification le 04 mai 2015 à 10:19.
      
      Sauf si tu l'as déjà rentrée à la main, non ?
      
      (OK, moi aussi j'accepte la première fois, dans la vraie vie.)
    - [^] # Re: Mélange
      
      Posté par arnaudus le 04 mai 2015 à 10:40. Évalué à 10.
      
      Ben j'imagine que tu ne te connectes jamais non plus à un serveur ssh sur le net alors, parce qu'à la première connexion il y a un message d'erreur te demandant d'accepter la clé.
      
      Sauf que pour ssh, ce n'est pas un message d'erreur, et qu'il est clair. Je trouve que la manière dont Firefox gère le truc est beaucoup trop technique et cryptique. Il faudrait un message beaucoup plus simple qui explique très clairement 1) pourquoi ce message apparait (connexion sécurisée mais certificat autosigné), 2) comment accepter ce certificat (avec un seul bouton "j'accepte de prendre ce risque"), 3) une explication claire des risques pris ("on n'est pas certain que c'est bien le site cible qui est en train de communiquer avec nous), 4) une indication de la "normalité" du processus (si on se connecte à un blog ou un site associatif, c'est possible; si c'est une banque, c'est hyper-louche).
      - [^] # Re: Mélange
        
        Posté par eingousef le 04 mai 2015 à 11:08. Évalué à 5.
        
        Et puis si les sites affichaient une page avec quelques mots sur leur politique de sécurité aussi, ce ne serait pas du luxe. Avec CertPatrol j'ai régulièrement des alertes de changements "louches" (c'est à dire bien avant la date d'expiration) de certificats ou de CA, et j'ai encore jamais vu un site afficher un truc du style "on vient de changer de CA, si le certif a changé, ne vous inquiétez pas, tout est normal".
        
        *splash!*
      - [^] # Re: Mélange
        
        Posté par Joris Dedieu (site web personnel) le 04 mai 2015 à 14:01. Évalué à 3. Dernière modification le 04 mai 2015 à 14:06.
        
        Je trouve que la manière dont Firefox gère le truc est beaucoup trop technique et cryptique
        
        Elle est surtout de ce que j'en comprends erronée par rapport au principe même de x509. En x509 les utilisateurs doivent gérer des autorités et non des certificats.
      - [^] # Re: Mélange
        
        Posté par Ph Husson (site web personnel) le 04 mai 2015 à 21:15. Évalué à 2.
        
        En fait, d'un côté je suis d'accord
        D'un autre, si un attaquant fait du MITM avec un certificat non certifié, tu vas dire à l'utilisateur "c'est bon c'est presque safe" ?
        Si on en est arrivé à ces messages d'erreurs ignobles, c'est bien parce que PEBKAC…
        
        [^] # Re: Mélange
        
        Posté par jyes le 05 mai 2015 à 08:45. Évalué à 4.
        
        Et à force de message qui font peur partout, le PEBKAC a appris à passer outre n’importe quelle alerte de sécurité, ayant pris l’habitude qu’elles soient trop techniques et cryptiques pour lui. Un message, moins alarmiste et plus clair ne serait sûrement pas une diminution de la sécurité des PEBKAC. Les pires continueraient à valider mais les autres auraient au moins une chance de comprendre à quoi correspond leur validation.
        
        [^] # Re: Mélange
        
        Posté par xcomcmdr le 05 mai 2015 à 10:08. Évalué à 0.
        
        Et à force de message qui font peur partout, le PEBKAC a appris à passer outre n’importe quelle alerte de sécurité
        
        Ce n'est pas les messages en eux-mêmes, c'est les guguss qui font de l'auto-signé en disant "vas y ignore le message qui fait peur". Ou comment répandre une mauvaise pratique…
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
- [^] # Re: Mélange
  
  Posté par barmic le 03 mai 2015 à 18:14. Évalué à 5.
  
  Le problème, c'est le mélange entre chiffrer une connexion et certifier une connexion.
  
  C'est normal, ça n'a pas de sens de les distinguer. Chiffrer sert principalement à éviter le man in the middle, mais si tu ne certifie pas la connexion alors tu as tout loisir de te faire avoir par cette technique.
  
  Le seul cas où ça aurait une différence c'est pour éviter de se faire sniffer une connexion en cours, mais bon, t'obliger à te déconnecter (par exemple sur un wifi) pour mettre en place le MITM n'a rien d'impossible.
  
  Donc, non ça n'a pas de ses de distinguer les deux.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Mélange
  
  Posté par Laurent J (site web personnel, Mastodon) le 04 mai 2015 à 12:18. Évalué à 4.
  
  Donc, si ta connexion passe par un proxy à la con qui "espionne" le contenu (donc en "cassant" la liaison ssl et en proposant un certificat non certifié au navigateur), tu n'y verras que du feu si ton navigateur ne t'avertis pas de la non certification de la connexion chiffrée.
  
  Bref, comme ça été dit, une connexion chiffrée non certifiée, ça ne sert à rien.
# Certificats SSL

Posté par Anonyme le 03 mai 2015 à 14:58. Évalué à 3.

Je veux bien faire du full SSL, mais j’ai pas envie d’acheter des certificats SSL.

Si je me souviens bien, Mozilla est à l’origine d’une autorité de certification, il me semble, gratuite, mais qu’en est-il de DANE, par exemple ?
# Commentaire supprimé

Posté par Anonyme le 03 mai 2015 à 15:13. Évalué à 9.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Complexité de configuration serveur
  
  Posté par barmic le 03 mai 2015 à 18:14. Évalué à 4.
  
  Ça ne résous pas la question de la gestion des certificats (le mettre à jour, ne pas le laisser n'importe où, garder le fichier de révocation, etc) et c'est ce qui est important avec le modèle SSL/TLS.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Complexité de configuration serveur
  
  Posté par Joris Dedieu (site web personnel) le 03 mai 2015 à 18:45. Évalué à 4.
  Cependant prendre connaissance de tous les combinaisons possibles concernant les algos de chiffrement et les protocoles d'échanges de clés est un travail horriblement long et fastidieux.
  
  C'est pour cela que openssl propose les macros HIGHT, MEDIUM et LOW. HIGH:!aNULL:!MD5:!LOW que j'utilise actuellement permet d'obtenir un résultat satisfaisant (note de A au test ssllabs en ne dropant que les IE6/XP) sans avoir a se palucher chaque algo (ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK par exemple)
  
  A noter que haproxy te permet d'afficher une page d'erreur explicite pour mitiger POODLE par exemple ce qui peut être bien pratique.
```
  acl sslv3 ssl_fc_protocol SSLv3
  use_backend bk_sslv3 if sslv3

backend bk_sslv3
  mode http
  errorfile 503 /etc/haproxy/pages/sslv3.http
```
# Certificate Transparency…

Posté par gouttegd le 03 mai 2015 à 16:41. Évalué à 7.

Que faire d'une autorité dont la confiance peut être mise en cause ou d'une à qui on veut bien faire confiance mais qui a du mal à se faire accepter ? […] Le projet Certificate Transparency a pour but de répondre a ces questions

Non.

Certificate Transparency répond aux questions « ce certificat a-t-il été émis par telle CA ? » et « y a-t-il en circulation un autre certificat pour le même domaine, émis par l’une quelconque des CA participant à Certificate Transparency ? ».

Certificate Transparency ne répond pas du tout à la question « que faire d’une CA indigne de confiance ? ». Et pour cause, ce n’est pas une question technique susceptible d’être résolue par un protocole, c’est une question politique, qui dépend de facteurs comme « combien de nos utilisateurs vont se plaindre si on retire cette CA du magasin de notre navigateur ? », « ceux qui vont se plaindre parlent-ils la même langue que nous ? », « quelles sont nos relations avec cette CA (est-ce que je joue au golf avec son PDG) ? », etc.

Certificate Transparency ne répond même pas à la question « cette CA est-elle digne de confiance ? ». Si Certificate Transparency détecte un doublon (une CA qui émet un certificat alors qu’un autre a déjà été enregistré dans les journaux CT), ça peut tout au plus laisser planer un doute mais ça ne dit pas avec certitude que l’un des certificats est frauduleux (il y a des raisons légitimes de faire émettre un certificat pour un même domaine à deux CA différentes, HPKP encourage cette pratique d’ailleurs), ni lequel des deux est frauduleux (ce n’est pas forcément celui qui a été émis en deuxième).

Certificate Transparency répond surtout aux inquiétudes des autorités de certification qui commençaient à craindre que les propositions de validation alternative (Convergence, DANE et assimilés) ne finissent par saper leur position. Trop de gens se mettaient à dire qu’il serait temps de se passer des CA, heureusement CT est là pour remettre les pendules à l’heure et rappeler à tout le monde que les CA sont indispensables (rappel : les journaux CT n’acceptent que les certificats émis par les CA « reconnues », en pratique les mêmes que celles dont le certificat est inclus dans les navigateurs).
# Mauvais problème

Posté par Sytoka Modon (site web personnel) le 03 mai 2015 à 20:56. Évalué à -1. Dernière modification le 03 mai 2015 à 20:57.

Quand je consulte wikipedia, je me fiche d'être en http ou https… Il y a tout plein de site dont on se fiche éperdument que les données soient chiffrées. Que cela n'empêche pas de les proposer en deux versions mais il peut être très pratique de laisser une version en http dont on est assurer qu'elle soit en lecture seule (pas de password qui passe par là).

Le problème pour moi viens de l'authentification et des cookies. Je propose de virer les champs cachés ainsi que les cookies d'http, surtout les cookies. De plus, on limite les en têtes afin de revenir a seulement quelques champs simple et on vire tout le reste. On aura ainsi du http pour des sites simples sans authentification et on chiffre lorsque c'est nécessaire. Ainsi on est plus serein coté client mais aussi coté serveur. Quand on fait du http, on n'aura pas de mot de passe du trousseau ou des cookies qui pourront se balader. Le https n'empêche absolument pas de se faire tracer SAUF qu'on croit que tout est clean…

En passant mais non directement liée, quel est le surcoût électrique du TLS actuellement ?

Bref, je milite pour du http en read-only ! Moi, je veux consulter google en http et que cet enfoiré ne compile pas tout cela dans mon compte gmail;-)
- [^] # Re: Mauvais problème
  
  Posté par ondex2 le 03 mai 2015 à 21:18. Évalué à 10.
  
  Dans certains pays, la consultation de certaines pages Wikipedia peut être mal "perçue".
  
  Alors oui, il y a des solutions techniques (Tor & co), mais ça n'est pas accessible à tout le monde car il faut avoir quelques connaissances (savoir que ça existe tout simplement). Et si on fait des recherches sans SSL du type "comment ne pas être espionné", ben on est grillé également.
  
  Le chiffrement par défaut protège tout le monde car, entre autre, ceux qui ont besoin de se protéger se fondent dans la masse.
  - [^] # Re: Mauvais problème
    
    Posté par MTux le 03 mai 2015 à 23:36. Évalué à 5.
    
    Dans certains pays, la consultation de certaines pages Wikipedia peut être mal "perçue".
    
    Et le HTTPS n'y change absolument rien puisque la requête montrera toujours que tu te connecte à wikipedia.
    - [^] # Re: Mauvais problème
      
      Posté par groumly le 03 mai 2015 à 23:47. Évalué à 4.
      
      La requete montrera pas grand chose, a part une ip.
      Ip qui peut etre un proxy vers wikipedia (ou autre chose).
      
      Linuxfr, le portail francais du logiciel libre et du neo nazisme.
      - [^] # Re: Mauvais problème
        
        Posté par MTux le 03 mai 2015 à 23:56. Évalué à 2.
        
        Si tu commence à parler de proxy/VPN alors on s'éloigne du sujet…
        
        De toutes façons avec la fiabilité des CA, HTTPS ne garantit pas que le gouvernement ne verra pas ce que tu fais, au contraire.
        
        [^] # Re: Mauvais problème
        
        Posté par groumly le 04 mai 2015 à 01:20. Évalué à 2.
        
        Pourquoi on s'eloignerais du sujet? une chaine de confiance est necessaire pour quelque chose du genre.
        
        Pour la fiabilite des CA, le ssl pinning aide a resoudre le probleme.
        Pour des applis natives, c'est relativement simple a mettre en place, t'embarque la ca dans le binaire et tu rejette toute connexion qui n'est pas signee par ce cert specifique.
        Pour les navigateurs, des extensions pourraient permettre d'avoir le meme comportement.
        
        'fin, je sais pas, tu proposerais quoi comme alternative?
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Mauvais problème
        
        Posté par MTux le 04 mai 2015 à 08:53. Évalué à 5.
        
        Pour commencer j'aimerais que les gens arrêtent de vivre dans le fantasme que HTTPS est à la solution magique à tout. Comme tu dis cela passe par une chaîne d'éléments de confiance et ce que font Chrome et Firefox (c'est presque pareil d'ailleurs) c'est de la bêtise.
        
        [^] # Re: Mauvais problème
        
        Posté par groumly le 04 mai 2015 à 17:42. Évalué à 1.
        
        Tu propose pas d'alternative, tu rales juste la.
        
        Donc je repose la question, ton alternative plus fiable que https, ca serait quoi?
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
        
        [^] # Re: Mauvais problème
        
        Posté par Sytoka Modon (site web personnel) le 04 mai 2015 à 20:08. Évalué à 3.
        
        Par exemple, j'aime pas qu'on ne puisse pas avoir un recouvrement lors du changement de certificat. Ainsi, on pourrait avoir une chaîne de confiance dans la durée plutôt que par le haut. La dernière version de SSH implémente enfin cela.
        
        On pourrait implémenter des certificats GPG et se baser sur cette chaîne de confiance. On pourrait alors décider de faire confiance aux amis de Google ou d'Amazon ou … autres et avoir ainsi une autre forme de chaîne indépendant des éditeurs de certificats SSL, une chaîne que chacun pourrait adapter à ses besoins…
        
        Bref, cette chaîne SSL n'est pas top top mais je ne sens pas de grande motivation pour aller vers un système plus décentralisé.
        
        [^] # Re: Mauvais problème
        
        Posté par gouttegd le 04 mai 2015 à 20:35. Évalué à 3.
        
        On pourrait implémenter des certificats GPG et se baser sur cette chaîne de confiance.
        
        C’est déjà spécifié, mais à ma connaissance il n’y a que GnuTLS qui implémente ça.
        
        Il y a aussi Monkeysphere, qui vise à peu près la même chose de façon indépendante.
        
        [^] # Re: Mauvais problème
        
        Posté par Spack le 04 mai 2015 à 12:47. Évalué à 2.
        
        Pour la fiabilite des CA, le ssl pinning aide a resoudre le probleme.
        
        J'en doute, je peux toujours mettre en proxy en coupure, casser la connexion SSL et faire croire que mon CA est le bon.
        
        Pour des applis natives, c'est relativement simple a mettre en place, t'embarque la ca dans le binaire et tu rejette toute connexion qui n'est pas signee par ce cert specifique.
        
        Jusqu'au jour où ton certificat expire et qu'il faut mettre à jour ton application sauf que l'éditeur ne l'entend pas de cette oreille. Oui c'est de vous dont je parle applications Java.
        
        [^] # Re: Mauvais problème
        
        Posté par groumly le 04 mai 2015 à 17:41. Évalué à 2.
        
        Tu peux pinner une cle publique, plutot qu'un cert, auquel cas tu peux renouveler le cert, sous reserve que t'utilise la meme cle privee pour le regenerer.
        
        Dans ce contexte (appli native), tu peux aussi contourner les CA entierement, vu que tu distribue le cert toi meme avec l'appli.
        Reste a distribuer et executer ton appli de facon fiable, et les stores serieux aident a resoudre le probleme.
        
        Apres, est ce que ca marche dans 100% des cas? Non, probablement pas, mais si t'as une solution qui marche dans 100% des cas, je serais ravi de l'entendre.
        
        Linuxfr, le portail francais du logiciel libre et du neo nazisme.
    - [^] # Re: Mauvais problème
      
      Posté par Zenitram (site web personnel) le 03 mai 2015 à 23:48. Évalué à 3.
      
      et https change tout ca il y a 99.99% de pages ok et que personne ne sait quelle page tu regardes.
      mauvais exemple (ca change pour les sites 100% "subversif", oui, pas pour l'exemple)
    - [^] # Re: Mauvais problème
      
      Posté par 태 (site web personnel) le 04 mai 2015 à 07:39. Évalué à 7.
      
      En https, la requête montrera que tu te connectes à wikipedia mais pas quelle page tu visites.
      
      Donc ce pays ne saura pas si tu visites "certaines pages wikipedia dont la consultation peut être mal perçues" ou simplement des pages bien pensantes.
  - [^] # Re: Mauvais problème
    
    Posté par gouttegd le 03 mai 2015 à 23:46. Évalué à 10.
    
    Un pays dans lequel le simple fait de consulter certaines pages Wikipédia peut t’attirer des ennuis est probablement un pays dans lequel les fournisseurs d’accès aux ordres du gouvernement n’hésiteront pas à faire du MITM avec des certificats frauduleux signés par une sous-CA complaisante…
    
    Dans ce cas de figure, le chiffrement généralisé non seulement ne protège personne (du moins tant qu’on n’aura pas d’autres moyens de vérifier un certificat que de faire confiance à des CA), mais met en danger les gens qui visiteront les sites interdits en se croyant naïvement protégés, alors qu’ils n’auraient peut-être pas pris ce risque si on ne leur avait pas promis une (illusoire) protection.
    - [^] # Re: Mauvais problème
      
      Posté par Nicolas Boulay (site web personnel) le 04 mai 2015 à 13:10. Évalué à 3.
      
      Cela n'est vrai que pour les pays puissant, il y a plein de pays en dictature ou presque, qui n'ont pas les moyens de faire ça.
      
      "La première sécurité est la liberté"
      - [^] # Re: Mauvais problème
        
        Posté par gouttegd le 04 mai 2015 à 13:24. Évalué à 6.
        
        Du MITM avec de faux certificats, ça ne demande pas des ressources énormes (ce n’est pas de la cryptanalyse). Beaucoup d’entreprises le font sur leur réseau.
        
        Faire ça à l’échelle d’un pays est un peu plus difficile, mais pas d’inquiétude, la France peut fournir (et a fourni à certains) l’équipement nécessaire.
        
        [^] # Re: Mauvais problème
        
        Posté par Nicolas Boulay (site web personnel) le 04 mai 2015 à 13:27. Évalué à 3.
        
        "Beaucoup d’entreprises le font sur leur réseau."
        
        Oui, à condition de maitriser les installation des navigateurs pour leur changer leur certificat racine. Sinon, cela ne marche pas sans démarche illégale.
        
        D'ailleurs, je pense même que mettre des proxy espion menteur TLS, est à la limite de la légalité, le jour ou une affaire sort suite à l'espionnage des ces connexions, la boite risque d'avoir mal. (donné bancaire, mail perso syndical ou médical,…). Personne n'acceptera un enregistrement de ses conversations au téléphone pro, alors pourquoi l’accepter sur internet ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mauvais problème
        
        Posté par Benoît Sibaud (site web personnel) le 04 mai 2015 à 13:48. Évalué à 7.
        
        Pour la France, la CNIL dit « Du point de vue " informatique et libertés ", ce déchiffrement est légitime du fait que l'employeur doit assurer la sécurité de son système d'information ». (31 mars 2015)
        Cf http://www.cnil.fr/linstitution/actualite/article/article/analyse-de-flux-https-bonnes-pratiques-et-questions/
        
        On va supposer que l'employé ne va pas utiliser ses propres infos bancaires perso depuis le réseau de l'entreprise, ni ses données médicales (ou moyens d'accès à ses données médicales), mais aussi qu'il ne fera rien au niveau syndical ou même qu'il ne participera pas aux scrutins par vote électronique par internet concernant son entreprise depuis son poste professionnel…
        
        [^] # Re: Mauvais problème
        
        Posté par Nicolas Boulay (site web personnel) le 04 mai 2015 à 14:26. Évalué à 3.
        
        La cnil depuis le changement de président, c'est du grand n'importe quoi.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mauvais problème
        
        Posté par flan (site web personnel) le 04 mai 2015 à 20:38. Évalué à 2.
        
        Parfois, la sécurité informatique prime, c'est normal de devoir surveiller ce qui sort de ton réseau local quand il y a potentiellement des informations un peu sensibles (je pense à Bercy, par exemple).
        
        [^] # Re: Mauvais problème
        
        Posté par Sytoka Modon (site web personnel) le 04 mai 2015 à 21:31. Évalué à 3.
        
        Ils ont mis des brouilleurs à Bercy ? Si non, je ne sais pas alors ce qu'ils surveillent réellement…
        
        Le TCP/IP par pigeon voyageur a sa RFC. Pour certaines données, on utilise le disque dur par DHL, ça a un débit par si mauvais…
        
        [^] # Re: Mauvais problème
        
        Posté par Nicolas Boulay (site web personnel) le 05 mai 2015 à 20:36. Évalué à 5.
        
        Ne pas prendre ses employés pour des cons, leur faire confiance, leur donner les moyens de travailler, cela marche mieux à mon avis.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mauvais problème
        
        Posté par Anthony Jaguenaud le 06 mai 2015 à 09:15. Évalué à 4.
        
        leur faire confiance…
        
        Oui, mais il faut surtout les former. Un employé que tu fais chier avec la sécurité (mot de passe à changer, internet limité, interdire les clé USB…) fera tout pour passer outre s’il ne comprend pas le pourquoi.
        
        Pour revenir sur la confiance, c’est vrai. Mais peut-on objectivement penser que tous les employés qui vont passer sont digne de confiance ? L’équilibre à trouver ne me semble pas simple.
        
        [^] # Re: Mauvais problème
        
        Posté par Nicolas Boulay (site web personnel) le 06 mai 2015 à 16:02. Évalué à 2.
        
        " (mot de passe à changer, internet limité, interdire les clé USB…)"
        
        Ceux qui prennent ce genre de mesure oublie que l'on doit travailler. Cela me rappelle un bocal sans réseau extérieur, ni clef usb : mais comment faire pour lire les specs ?!
        
        Le pourquoi peut être compris, mais c'est insupportable au quotidien. Ou alors, il faut fournir 2 machines, l'une pour le dev, l'autre pour trouver des informations sur internet. Mais en général, les directions sont trop pingres pour faire ça.
        
        "Mais peut-on objectivement penser que tous les employés qui vont passer sont digne de confiance ? L’équilibre à trouver ne me semble pas simple."
        
        Non, si un personne veut vraiment faire sortir des infos, elle peut booter sur un liveCD ou autre, et recopier des fichiers, ou même démonter un disque dur.
        
        Pour éviter ce genre de cas, ces mesures de sécurité font chi… tous les jours les personnes honnêtes qui veulent faire leur boulot.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Mauvais problème
        
        Posté par oinkoink_daotter le 06 mai 2015 à 20:52. Évalué à 2.
        
        Le pourquoi peut être compris, mais c'est insupportable au quotidien
        
        Oui oui. Mais en même temps, les merdes arrivent par les clefs USB. On fait quoi ?
        
        Non, si un personne veut vraiment faire sortir des infos, elle peut booter sur un liveCD ou autre, et recopier des fichiers, ou même démonter un disque dur.
        
        Oui oui. Mais en même temps, en SSI, on a coutume de dire que 80% de la menace est interne (prestataires, employés pas contents, stagiaires curieux, etc.). On fait quoi ? On se met la tête dans le sable et on prie que rien ne se passe ?
        
        Pour éviter ce genre de cas, ces mesures de sécurité font chi… tous les jours les personnes honnêtes qui veulent faire leur boulot.
        
        De toute façon, ce que tu cites dans ton message "mot de passe …" ne sert pas seulement à se protéger de la menace interne, mais aussi (et surtout) des merdes qui viennent de l'extérieur. En 2015, si tu n'as pas ce genre de pratiques, ben, tu te fais défoncer, exfiltrer, et tu ne t'en rends même pas compte (sauf si tu as le bonheur de tomber sur un cryptolocker, qui va aussi revendre tes données après t'avoir pris ton pognon). Sauf si ce que tu fais n’intéresse personne.
        
        [^] # Re: Mauvais problème
        
        Posté par flan (site web personnel) le 06 mai 2015 à 20:15. Évalué à 2.
        
        On ne parle pas spécialement d'utilisateur, on parle de filtrage des communications entre l'intranet et l'internet. Ces communications peuvent être faites par les utilisateurs, ou par des spywares qui vont communiquer en HTTPS pour se noyer justement dans le flux licite.
        
        Après, pour le digne de confiance, il faut bien distinguer deux niveaux : les utilisateurs malveillants (concrètement, on ne doit pas pouvoir faire grand-chose contre eux à mon avis), et les utilisateurs négligents (là, fliquer peut aider pas mal, mais il faut qu'ils soient prévenus).
        
        Bien sûr, tout dépend du niveau de sécurité demandé, mais c'est parfois nécessaire. Ça ne me choquerait pas qu'il y ait pas mal de mesures de sécurité pour des ministères comme Bercy.
        
        [^] # Re: Mauvais problème
        
        Posté par gouttegd le 04 mai 2015 à 14:42. Évalué à 2.
        
        Oui, à condition de maitriser les installation des navigateurs pour leur changer leur certificat racine.
        
        Non, il suffit de demander à une CA reconnue un certificat avec l’extension Basic Contraints CA:true, et tu deviens de fait une sous-CA capable de signer des certificats que tout le monde acceptera.
        
        Les CA ne sont pas supposées délivrer de tels certificats à la légère, mais dans les faits ce n’est pas difficile d’en trouver qui le font. D’ailleurs quand l’une d’elles admet qu’elle le fait, il s’en trouve pour… applaudir son honnêteté (“I Think Trustwave should be commended for being the first CA to come forward”).
        
        Sinon, cela ne marche pas sans démarche illégale.
        
        IANAL, mais je ne pense pas qu’il soit illégal de demander à une CA un certificat pouvant servir de sous-CA, ni qu’il soit illégal pour une CA de délivrer un tel certificat. C’est contraire aux consignes du CA/Browser Forum, mais celles-ci n’ont pas force de loi, elles ne servent qu’aux navigateurs pour décider d’inclure ou non une CA dans leurs magasins.
        
        [^] # Re: Mauvais problème
        
        Posté par Nicolas Boulay (site web personnel) le 04 mai 2015 à 14:48. Évalué à 3.
        
        Si les boites n'ont pas besoin de faire de l'usurpation d'identité pour avoir le certificat, le problème est donc dans le système de certificat.
        
        "La première sécurité est la liberté"
- [^] # Re: Mauvais problème
  
  Posté par Tonton Th (Mastodon) le 03 mai 2015 à 21:35. Évalué à 4.
  
  Le problème pour moi viens de l'authentification et des cookies. Je propose de virer les champs cachés ainsi que les cookies d'http, surtout les cookies.
  
  Pourquoi tant de haine contre les cookies ?
- [^] # Re: Mauvais problème
  
  Posté par Harry le 04 mai 2015 à 00:03. Évalué à 2.
  
  Le chiffrement ne résout pas uniquement le problème de la confidentialité (des logins, mots de passe, cookies, etc.), mais aussi celui de l'intégrité. Il est très désagréable de visiter un site web sur lequel de la publicité est rajoutée par le fournisseur d'accès. Plus grave, un attaquant peut effectuer du man-in-the-middle pour injecter du contenu dans une page web afin d'exploiter une vulnérabilité dans le navigateur web ou un de ses plugins pour finalement en prendre le contrôle.
  
  Avoir un site en HTTPS dont l'intégralité du contenu est en HTTPS (ie : il ne dépend pas de ressources en HTTP) protège l'utilisateur de ces différentes menaces.
  - [^] # Re: Mauvais problème
    
    Posté par Sytoka Modon (site web personnel) le 04 mai 2015 à 09:55. Évalué à 4.
    
    L'intégrité peut se résoudre sans chiffrement, via signature numérique. C'est une autre fonction qui peut être résolue indépendamment.
- [^] # Re: Mauvais problème
  
  Posté par Joris Dedieu (site web personnel) le 04 mai 2015 à 13:39. Évalué à 5.
  
  Bref, je milite pour du http en read-only ! Moi, je veux consulter google en http et que cet enfoiré ne compile pas tout cela dans mon compte gmail;-)
  
  Quitte a dénoncer un faux problème, autant parler du vrai que tu évoques ici. Le vrai problème d'HTTP est sémantique (et non HTTP/2.0 ne le règlera pas. Son objet est justement de préserver la sémantique en modifiant le transport). Dans la mesure ou il n'y a aucun moyen de savoir si une requête est susceptible de provoquer des effets de bord, il n'existe aucun moyen de connaitre la pertinence de l'envoie d'informations (notamment des cookies), d’où l'application de filtres qu'il faut paramétrer au cas par cas manuellement (adblock, noscript et autres) ou encore des entêtes qui sous forme de prières demandent aux méchants de ne pas l'être.
  
  Par exemple sur la version sécurisé du site du CIC (https://www.cic.fr/fr/), on voit que deux cookies sont positionnés par xiti et envoyés pour le téléchargement d'un gif transparent. A partir de là quelle confiance puis-je avoir en cette page qui est pourtant certifiée avec validation étendue et dans laquelle, si j'étais client du CIC, j'aurais à saisir mes identifiants.
# Must be a joke

Posté par BohwaZ (site web personnel, Mastodon) le 03 mai 2015 à 22:10. Évalué à 10.
Pourtant on n'est pas le 1er avril…

En 5 minutes je pense déjà à des tonnes d'arguments pour exprimer à quel point cette idée est profondément stupide :
- le système des CA SSL est complètement cassé, de par sa conception-même. Ça fait des années que tout le monde dans le monde de la sécurité dit que c'est de la merde. Plutôt que de nous emmerder avec des rustines inutiles comme "letsencrypt" ou à recopier l'UI de Chrome, Mozilla ferait mieux de réfléchir à une alternative crédible pour qu'HTTPS devienne enfin quelque chose de sécurisé et accessible à tout le monde, pas seulement aux riches occidentaux.
- un certificat ça coûte des thunes. Oui oui StartSSL, letsencrypt machin. Non je suis pas d'accord, car c'est un monopole (bientôt duopole), si demain ils décident de faire payer c'est foutu. De plus quand on veut des sous-domaines c'est tout de suite très chiant (et cher). Et quand on veut un wildcard, c'est là que ça devient marrant. Enfin ou pas.
- ça veut dire que tous les gens qui n'ont pas de thune vont aller faire certifier leur site auprès d'une autorité centralisée (startssl ou letsencrypt, whatever). Big brother toussa. Si un jour ces autorités n'acceptent plus votre site parce que vous êtes un index de bittorrent, un média alternatif ou autre truc qui dérange, vous êtes bien dans la merde. Et combien de temps avant qu'un CA ne soit obligé par la justice à la demande de la RIAA ou autre à révoquer le certif d'un site ?
- la gestion des certificats c'est chiant, grave. J'ai une dizaine de domaines en HTTPS à gérer, tous les 6 mois il faut que je renouvelle les certificats. A chaque fois je finit par en enlever un, parce que c'est super chiant. Une fois que j'ai mis en place un truc, je veux que ça marche sans avoir à y revenir tous les ans ou tous les 6 mois, je suis pas admin sys, je fait ça sur mon temps libre. Et moi je suis un geek, je kiffe jouer de la config apache (enfin pas trop quand même), mais pour le péquin lambda, qui aura le courage d'aller se faire chier à faire un certif, le mettre à jour etc.
- Mozilla devient CA, et juste après parle de ne plus faire que du httpS. Tiens tiens, un business plan sous le coude ?
- C'est un sacré frein à la création de site web et à l'amateurisme (au sens noble), la barrière d'entrée sur le web devient encore plus haute.
Bref à mon avis Mozilla ne voit le web que comme un conglomérat de grosses boîtes et gros sites avec des budgets dédiés à tout et n'importe quoi, et n'en à rien à faire des millions de particuliers, assos, bénévoles et enthousiastes du monde entier qui font du web ce qu'il est : un gros bordel collaboratif, la plus belle invention de l'humanité.

Ce que veux Mozilla c'est un web propre et beau, et sécurisé (parce que bon c'est bien connu le SSL c'est la sécurité, ah ah), et tous ces gentils bidouilleurs ne sont qu'un obstacle à la productivité et à son objectif de marché. Donc il cherche à les éliminer. Si vous ne me croyez pas regardez un peu la modification du traitement des certificats auto-signés avec le temps… c'est devenu un enfer, et ce n'est pas pour "la sécurité".

Oui je suis énervé, mais même pas surpris, après avoir supprimé le "http://" de l'URL ce n'est qu'une étape logique, que j'avais déjà annoncée il y a quelques années. Ce qui m'énerve c'est d'avoir raison et de voir que Mozilla, le seul représentant du web non commercial (enfin logiquement) est en réalité un vendu et ne fait plus rien pour la communauté, mais ne travaille que pour son intérêt propre.

Bref encore une fois je répète mon refrain habituel : mais crève donc Mozilla, crève donc, tu fera de la place pour quelque chose d'autre. Et cette chose ne peut pas être pire que Mozilla.

« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
- [^] # Re: Must be a joke
  
  Posté par Spack le 03 mai 2015 à 22:31. Évalué à 3.
  
  Mozilla devient CA
  
  C'est la deuxième fois que je vois ça dans le fil de discussion mais il ne me semble pas avoir vu l'information passer. Un lien vers cette actualité ?
  - [^] # Re: Must be a joke
    
    Posté par BohwaZ (site web personnel, Mastodon) le 03 mai 2015 à 22:46. Évalué à 4.
    
    https://letsencrypt.org/
    
    Ça peut sembler être une bonne idée, mais ça ne règle aucun problème : il n'y a toujours aucune chaîne de confiance crédible, et ça centralise toutes les données. Grâce à OCSP letsencrypt saura aussi qui visite quel site (ça fait partie du business model des certifs gratuits de StartSSL je crois, de profiler les visiteurs des sites dont ils font les certifs).
    
    De plus ça ne supporte toujours pas les certificats wildcards, histoire de pas marcher sur les plates-bandes des CA commerciaux, donc pour pas mal de sites ça sert absolument à rien.
    
    De plus perso je ne laisserais pas ce genre de truc modifier automatiquement mes fichiers de config, surtout quand on héberge des centaines de sites en SNI…
    
    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
    - [^] # Re: Must be a joke
      
      Posté par Laurent J (site web personnel, Mastodon) le 04 mai 2015 à 12:25. Évalué à 5.
      
      Ce n'est pas Mozilla qui gère ça ! c'est un participant au groupe de travail rien de plus. même les développeurs les plus actifs ne sont pas chez Mozilla (suffit de jeter un coupe d'oeil au github et au site)
- [^] # Re: Must be a joke
  
  Posté par Zenitram (site web personnel) le 03 mai 2015 à 22:51. Évalué à -1. Dernière modification le 03 mai 2015 à 22:53.
  
  le système des CA SSL est complètement cassé,
  
  un truc apporte de la sécurité dans 99% des cas, mais comme ça ne marche pas dans 1% des cas, il vaut mieux avoir zéro.
  chacun son truc, mais cette idée de tout ou rien n'est pas mon idée. On n'avance jamais avec un telle façon de voir.
  
  un certificat ça coûte des thunes. Oui oui StartSSL, letsencrypt machin. Non je suis pas d'accord, car c'est un monopole (bientôt duopole),
  
  Qu'est-ce qui empêche un triopole, un quadruopole, puis un… bon, je passe, en fait ce n'est pas un argument : tu peux ajouter un n-ième cas si tu veux.
  
  la gestion des certificats c'est chiant, grave.
  
  gni? vraiment?
  
  tous les 6 mois il faut que je renouvelle les certificats.
  
  Tu te fous de la gueule de qui?
  
  Au pire, c'est 2 ans (certificats EV) moins disons 1 mois de marge, soit 3,9 fois plus que 6 mois. Et ce que parce que les diffuseur de certificats ont la flemme de vendre au max possible (2 ans plus quelques mois) mais tu es libre de faire une autorité que propose 27 mois donc tu as 26 avant de changer.
  Pour le classique, c'est 3 ans moins disons 1 mois de marge depuis 2014 (jusqu'à 2014, j'avais un certificat qui avait une durée de vie de 10 ans, bons ils abusaient… Je l'ai tué avec le passage à SHA-2).
  
  6 mois, le problème est chez toi.
  
  Mozilla devient CA, et juste après parle de ne plus faire que du httpS. Tiens tiens, un business plan sous le coude ?
  
  Quel lien financier entre les deux?
  
  C'est un sacré frein à la création de site web et à l'amateurisme (au sens noble), la barrière d'entrée sur le web devient encore plus haute.
  
  Connerie : les web amateurs sont hébergé en mutualisés, l'hébergeur s'occupe de tout (DNSSEC même, c'est d'office ou alors mauvais hébergeur).
  
  mais crève donc Mozilla, crève donc,
  
  On m'accuse d'anti-Mozillaisme, mais la j'ai trouvé mille fois pire que moi…
  
  MERCI Mozilla (et les autres en fait) pour ce choix.
  (je sais que les fanboys Mozilla oublieront ce côté positif que j'ai envers Mozilla à la prochaine critique de Mozilla que je ferai et m'accuseront de toujours cracher sur Mozilla, mais je sais moi que j'aurai défendu Mozilla sur ce point).
  - [^] # Re: Must be a joke
    
    Posté par gouttegd le 03 mai 2015 à 23:04. Évalué à 3.
    
    Tu te fous de la gueule de qui?
    
    Au pire, c'est 2 ans
    
    Pas forcément, la réduction de la durée de validité des certificats est une des idées en vogue en ce moment. C’est une des pistes pour contourner les faiblesses des mécanismes de révocation (les CRL qui sont quasiment inutiles en pratique et OCSP qui pose plus de problèmes qu’il n’en résout).
    
    Le raisonnement est qu’avec un certificat à courte durée de vie, si la clef privée est compromise, à défaut de pouvoir révoquer le certificat (ou plutôt, à défaut de pouvoir faire parvenir aux clients l’information que le certificat est révoqué), au moins il expirera vite et la période pendant laquelle la clef privée compromise pourra faire des dégâts sera réduite.
    
    Plusieur sites de Google ont déjà des certificats valides pour seulement un mois. Adam Langley va jusqu’à proposer des certificats valides quelques jours.
    - [^] # Re: Must be a joke
      
      Posté par Zenitram (site web personnel) le 03 mai 2015 à 23:54. Évalué à 1.
      
      je pensais a une obligation qu'il aurait (il choisis 6 mois, on ne lui impose pas), la c'est un choix, et si tu fais du journalier (ou si tu as plein de sites à gérer) c'est automatisé.
      
      bef, je critique sa critiques qui attaques avec des arguments eux-mêmes criticables.
      et surtout, comme très souvent, pas d'alternatives "mieux"…
      
      facile de critiquer, mais ensuite?
- [^] # Re: Must be a joke
  
  Posté par MTux le 03 mai 2015 à 23:39. Évalué à 10.
  
  De toutes façons la suppression du HTTP est totalement irréaliste, ou pas avant une bonne ~~dizaine~~ vingtaine d'années. Suffit de voir qu'en 2015 on se traîne encore flash dont tout le monde avait annoncé la mort ainsi que des compatibilités IE7.
  - [^] # Re: Must be a joke
    
    Posté par Reihar le 04 mai 2015 à 02:48. Évalué à 10.
    
    Tiens, ton message me fait passer au passage à l'IPv6.
    - [^] # Re: Must be a joke
      
      Posté par MTux le 04 mai 2015 à 08:48. Évalué à 10.
      
      Voilà c'est un excellent exemple, en 2015 on est toujours en IPv4.
      - [^] # Re: Must be a joke
        
        Posté par eingousef le 04 mai 2015 à 10:25. Évalué à 1.
        
        Parle pour toi.
        
        *splash!*
        
        [^] # Re: Must be a joke
        
        Posté par MTux le 04 mai 2015 à 10:49. Évalué à 4.
        
        J'ai chez moi un tunnel ipv6 en /48 et 2 sous-réseaux ainsi que radvd pour l'accès des périphériques. Mes deux VPS ont aussi de l'ipv6. Donc je suis équipé.
        
        [^] # Re: Must be a joke
        
        Posté par eingousef le 04 mai 2015 à 11:00. Évalué à 2.
        
        Hé ben moi aussi j'ai un /48 et c'est même pas un tunnel c'est du natif tavu alors pouette pouette :o
        
        *splash!*
- [^] # Re: Must be a joke
  
  Posté par Thierry Thomas (site web personnel, Mastodon) le 04 mai 2015 à 10:53. Évalué à 3.
  
  Pour aller dans le même sens, lire aussi l’article de PHK SSL revisited.
- [^] # Re: Must be a joke
  
  Posté par Elfir3 le 04 mai 2015 à 10:54. Évalué à 7.
  Oui, le système des CA est cassé, mais pour le moment il n'y a que lui et la mise en place d'une nouvelle CA est une solution sur le court terme. Rien n'empêche de travailler en même temps sur le long terme. Ca prends du temps de créer un nouveau système de certification et qu'il soit accepté par tout le monde. Après tout, faut que ce soit quelque chose d'un poil solide.
  J'ignore si ils y travaillent, mais en tout cas je n'ai rien vu qui va à l'encontre de cette idée.
  
  Mozilla devient CA, et juste après parle de ne plus faire que du httpS. Tiens tiens, un business plan sous le coude ?
  
  Il n'est pas question de ne faire que du https, mais de supprimer les fonctionnalités qui peuvent avoir un impact sur la sécurité en http.
  
  Depuis https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ :
  1. Setting a date after which all new features will be available only to secure websites
  2. Gradually phasing out access to browser features for non-secure websites, especially features that pose risks to users’ security and privacy.
  Ca limite un peu l'usage du navigateur en HTTP, mais à part pour les sites se foutant vraiment de la vie privée des visiteurs, ça ne devrait pas vraiment se voir.
  
  Bref à mon avis Mozilla ne voit le web que comme un conglomérat de grosses boîtes et gros sites avec des budgets dédiés à tout et n'importe quoi, et n'en à rien à faire des millions de particuliers, assos, bénévoles et enthousiastes du monde entier qui font du web ce qu'il est : un gros bordel collaboratif, la plus belle invention de l'humanité.
  
  Oui, d'où la mise à disposition d'une CA gratuite.
  
  Ce qui m'énerve c'est d'avoir raison et de voir que Mozilla, le seul représentant du web non commercial (enfin logiquement) est en réalité un vendu et ne fait plus rien pour la communauté, mais ne travaille que pour son intérêt propre.
  
  Je suppose que tu ne t'énerves donc pas, vu qu'en créant un outil qui offre à n'importe quel CA la possibilité d'etre compatible avec l'outil, il y a un peu plus que mozilla qui profite de leur travail.
  - [^] # Re: Must be a joke
    
    Posté par gouttegd le 04 mai 2015 à 11:26. Évalué à 5.
    
    Oui, le système des CA est cassé, mais pour le moment il n'y a que lui et la mise en place d'une nouvelle CA est une solution sur le court terme.
    
    La mise en place d’une nouvelle CA est peut-être une solution au problème que pas assez de monde ne chiffre, mais sûrement pas une solution au problème que « le système des CA est cassé »…
    
    Ca prends du temps de créer un nouveau système de certification et qu'il soit accepté par tout le monde.
    
    Ça en prend encore plus quand on ne fait rien qui aille dans ce sens, ce qui est précisément le cas des éditeurs de navigateurs (qui sont pourtant les mieux placés pour le faire, ce sont eux qui décident de ce qui est accepté ou pas).
    
    Le seul effort en la matière actuellement est Certificate Transparency (c’est le seul qui a une chance d’aboutir, puisque poussé par Google — Convergence, DANE, les clefs brutes, et tous les autres sont condamnés d’avance pour ce qui est du web¹), et ce n’est pas un « nouveau système de certification », au contraire c’est une affirmation qu’on ne veut absolument pas se passer de l’ancien, et que toutes les propositions alternatives peuvent aller se faire voir. (CT considère comme un problème le fait que l’on puisse créer son certificat dans son coin et le publier dans le DNS.)
    
    ¹ Ils ont en revanche plus d’avenir du côté d’autres protocoles, comme SMTP, IMAP, XMPP, SIP & co.
- [^] # Re: Must be a joke
  
  Posté par Laurent J (site web personnel, Mastodon) le 04 mai 2015 à 12:30. Évalué à 5.
  
  Mozilla devient CA, et juste après parle de ne plus faire que du httpS. Tiens tiens, un business plan sous le coude ?
  
  FUD !
  
  Comme je l'ai déjà dit en commentaire dans un autre journal, Mozilla encourage le projet let's encrypt, mais n'y participe que très peu. Voir les commits du projet sur github.
  
  Comme on peut lire sur le site, let's encrypt est une organisation indépendante. Elle est simplement sponsorisé par Mozilla, mais aussi par d'autres grosses boites comme indiqué sur le site (akamai, cisco etc…).
- [^] # Re: Must be a joke
  
  Posté par Yves (site web personnel) le 02 juin 2015 à 11:54. Évalué à 2.
  
  Autre problème qui fait que je suis contre la généralisation de HTTPS à tout: Forcer HTTPS limite fortement les petits services que l'on peut s'installer pour optimiser la navigation :
  — un proxy cache, pour rapprocher les ressources statiques ;
  — un proxy transformant, qui va réduire la taille des images par exemple : utile pour la navigation mobile avec un petit forfait internet ;
  — un proxy filtrant, soit pour optimiser (suppression des grosses ressources), soit pour virer des pub ou des malwares…
  
  Ce ne sont que des exemples.
# DANE

Posté par 🚲 Tanguy Ortolo (site web personnel) le 04 mai 2015 à 09:24. Évalué à 10.

La solution la plupart des problèmes des chaînes de certification X.509 actuellement utilisées pour TLS existe, c'est DANE. L'ennui, c'est que les fabricants de navigateurs Web n'en ont rien à foutre.
- [^] # Re: DANE
  
  Posté par eingousef le 04 mai 2015 à 10:44. Évalué à -1.
  
  Justement j'ai une question : c'est quoi les problèmes que ça va résoudre ? Dans PKI, le principal problème à l'origine de beaucoup d'autres c'est que c'est un système centralisé. Est-ce que tu n'a pas l'impression que DANE ne fait que déplacer la centralisation du système CA+navigateurs vers le DNS (racines+registrars) ?
  
  Autre question : comment ça va se passer si je veux faire un certif sur une machine sans nom de domaine (juste avec l'IP) ?
  
  *splash!*
  - [^] # Re: DANE
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 04 mai 2015 à 11:25. Évalué à 4.
    
    Justement j'ai une question : c'est quoi les problèmes que ça va résoudre ? Dans PKI, le principal problème à l'origine de beaucoup d'autres c'est que c'est un système centralisé.
    
    Pas tout à fait, ce n'est pas un système avec un centre mais avec plusieurs centres mal contrôlés.
    
    Est-ce que tu n'a pas l'impression que DANE ne fait que déplacer la centralisation du système CA+navigateurs vers le DNS (racines+registrars) ?
    
    C'est un façon de voir les choses, et effectivement la responsabilité est placée sur les registres, la fraude correspondant l'émission d'un faux certificat par une autorité reconnue ayant pour équivalent le transfert illégitime d'un nom de domaine par son registre.
    
    Mais une autre façon de voir les choses est de reconnaître que, de toute façon, on se fie déjà aux registres du DNS. On passe alors d'un système basée sur la confiance en les registres des TLD et les autorités de certification X.509, à un système basé sur la confiance en les seuls registres de TLD.
    
    Par ailleurs, DANE permet d'indiquer des contraintes sur les certificats ou sur les clefs qui peuvent, au choix de l'administrateur, se substituer ou s'ajouter à celles liées à la validation X.509.
    
    Autre question : comment ça va se passer si je veux faire un certif sur une machine sans nom de domaine (juste avec l'IP) ?
    
    Je ne pense pas que tu le puisse en effet.
    - [^] # Re: DANE
      
      Posté par claudex le 06 mai 2015 à 21:06. Évalué à 3.
      
      on se fie déjà aux registres du DNS
      
      Pas vraiment, avec le système actuel de TLS, si le DNS t’envoie au mauvaise endroit, le certificat ne sera pas valide (sauf problème de CA, mais c'est la CA le problème dans ce cas).
      
      Ce que je trouve plus intéressant avec DANE, c'est que le DNS est beaucoup plus difficile à cibler, du coup, si un TLD balance des mauvais identifiants de clefs pour un sous-domaine, beaucoup plus de monde risque de le voir, alors qu'actuellement, c'est assez facile à cibler.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
      - [^] # Re: DANE
        
        Posté par Spack le 10 mai 2015 à 11:10. Évalué à 2.
        
        Pas vraiment, avec le système actuel de TLS, si le DNS t’envoie au mauvaise endroit, le certificat ne sera pas valide (sauf problème de CA, mais c'est la CA le problème dans ce cas).
        
        Le DNS renvoie une adresse IP, le certificat lui valide le plus souvent un domaine.
        
        Si je contrôle le DNS, je peux très bien renvoyer l'IP d'un serveur que je maîtrise. Et comme j'ai quelques potes qui ont des CA, j'ai en ma possession un certificat tout aussi valide pour le même domaine.
        
        L'utilisateur n'y voit que du feu.
        
        [^] # Re: DANE
        
        Posté par claudex le 10 mai 2015 à 19:15. Évalué à 3.
        
        Je ne vois pas où tu veux en venir. Avec DANE, tu n'as besoin de que contrôler un TLD, tu n'as pas besoin de pote.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: DANE
  
  Posté par Aissen le 04 mai 2015 à 11:24. Évalué à 1.
  
  Dane n’est pas exempt de problèmes, notamment les certificat 1024 bits (crackables en quelques semaines) encore présents dans la chaine de root…
  https://www.imperialviolet.org/2015/01/17/notdane.html (je vous laisse lire tous les liens présents dans l’article, yen a pour un moment)
  - [^] # Re: DANE
    
    Posté par Aissen le 04 mai 2015 à 11:31. Évalué à 1.
    
    Bon je met à jour, j’ai confondu 1024 et 768 bits… Il n’empêche que les clefs 1024bits sont crackables aujourd’hui par quelques entités sur la planète, et le seront plus largement dans 5 ans; sans Perfect-Forward-Secrecy, ça expose toutes les connexions à un décryptage a-posteriori sur une échelle de temps plutôt courte.
    - [^] # Re: DANE
      
      Posté par gouttegd le 04 mai 2015 à 11:37. Évalué à 9. Dernière modification le 04 mai 2015 à 11:38.
      
      sans Perfect-Forward-Secrecy, ça expose toutes les connexions à un décryptage a-posteriori sur une échelle de temps plutôt courte.
      
      Il ne faut pas tout mélanger. Les clefs de DNSSEC ne sont pas utilisées pour chiffrer, elles ne font que signer.
      
      Si quelqu’un casse la clef DNSSEC d’un domaine (ou même de la racine) dans cinq ans, ça lui permettra, à ce moment-là, de falsifier des signatures DNSSEC (et donc, dans le cas de DANE, de falsifier un enregistrement TLSA et de faire accepter un certificat qui n’est pas celui publié par le propriétaire du site visé).
      
      Ça ne permettra absolument pas de revenir déchiffrer les communications préalablement enregistrées avant que la clef ne soit cassée, il n’y a même pas besoin de Forward Secrecy pour le garantir.
      - [^] # Re: DANE
        
        Posté par Aissen le 04 mai 2015 à 11:48. Évalué à 3.
        
        Exact, merci.
    - [^] # Re: DANE
      
      Posté par gouttegd le 04 mai 2015 à 11:59. Évalué à 2.
      
      D’après ce que j’ai constaté, la plupart des KSK en circulation font 2048 bits, ce sont les ZSK qui font souvent 1024 bits.
      
      Des clefs de 2048 bits qui changent tous les deux ans (pas obligatoire, mais c’est la période de validité la plus souvent recommandée pour les KSK) et des clefs de 1024 bits qui changent tous les quelques mois (encore une fois, ce n’est pas obligatoire, mais ça semble être la pratique courante), ça me paraît un assez bon compromis entre performance (les signatures sont d’autant plus grosses, et leur vérification plus longue, que les clefs sont de grande taille) et sécurité.
      
      Je ne serais pour ma part pas mécontent qu’on mette un peu le hola à l’augmentation irréfléchie de la taille des clefs cryptographiques. Une bonne gestion des clefs (incluant, par exemple, un renouvellement fréquent) est plus pertinent à mon sens que des clefs de 3072 ou 4096 bits.
      - [^] # Re: DANE
        
        Posté par syl le 04 mai 2015 à 20:20. Évalué à 2.
        
        Une bonne façon de réduire la taille des clés, c'est d'utiliser les algorithmes de signature sur courbes elliptiques. Là, une clé de 256 bits est largement suffisante.
        
        On y gagnerait non seulement en taille de clé mais aussi en temps de calcul.
        
        [^] # Re: DANE
        
        Posté par gouttegd le 04 mai 2015 à 20:47. Évalué à 10.
        
        Oh oui, jetons aux oubliettes ce RSA qui ne résiste aux attaques que depuis trente ans, et jetons-nous à corps perdus dans des algorithmes chaudement recommandés par la NSA et dont les paramètres (pour les courbes autorisées dans DNSSEC) ont été choisis sur des critères non-spécifiés ⸮
- [^] # Re: DANE
  
  Posté par antistress (site web personnel) le 04 mai 2015 à 18:02. Évalué à 3.
  
  Je n'ai lu que le 1er paragraphe, mais ça m'a fait penser à la solution envisagée par Caliopen pour l'échange de clés :
  
  À la création d'un contact (ou lors de son importation depuis un outils tiers), Caliopen va essayer de trouver, via différents protocoles (enregistrement DNS ou SKS) les clés publiques associées à l'adresse email fournie, et proposer leur intégration au trousseau associé au compte utilisateur sur le serveur Caliopen. L'objectif, ici, est de faciliter au maximum la vie de l'utilisateur tout en permettant, par une gestion centralisée des trousseaux, de gérer au mieux la répudiation d'une clé par un contact.
  
  cf cette FAQ (question « Q. Comment est géré le chiffrement des emails sortant, la gestion de la clef privée et le trousseau de clef publique des destinataires ? »)
  
  Ça a un rapport ?
  - [^] # Re: DANE
    
    Posté par gouttegd le 04 mai 2015 à 18:31. Évalué à 4.
    
    L’idée est globalement la même, à savoir publier les clefs dans le DNS. Je ne sais pas à quels enregistrements DNS ils font référence, mais il s’agit probablement des enregistrements de type CERT (RFC 4398), qui sont précisément conçus pour ça. (DANE de son côté utilise des enregistrements TLSA (RFC 6698).)
    
    Le principe est que si je cherche un certificat (X.509 ou OpenPGP, les enregistrements CERT sont utilisables pour les deux) pour Monsieur Michu michu@example.net, je peux le trouver dans le DNS sous la forme d’un enregistrement CERT pour le nom michu.example.net..
    
    C’est une approche intéressante et en théorie prometteuse de la distribution des clefs, dans la mesure où elle pourrait être réalisée automatiquement par les fournisseurs de messagerie (qui ont logiquement le contrôle de la zone DNS dans laquelle se trouve les adresses de leurs utilisateurs). En théorie seulement car ① je ne connais aucun fournisseur de messagerie qui fasse cela ou même qui ait exprimé un quelconque intérêt à cette technique, et ② ce n’est fiable que si les zones DNS des fournisseurs de messagerie sont signées, ce qui n’est le cas de pratiquement aucune.
    - [^] # Re: DANE
      
      Posté par antistress (site web personnel) le 04 mai 2015 à 18:43. Évalué à 2.
      
      merci
# La pire nouvelle pour l'internet depuis longtemps

Posté par marzoul le 04 mai 2015 à 10:35. Évalué à 4.

Moi touriste sur le web, je REFUSE d'être obligé de rouler avec une voiture qui décrète CONTRE MON GRÉ que je n'ai pas envie d'aller sur cette route avec la fenêtre ouverte.
C'est aussi ubuesque que de dire : il est interdit de construire des maisons sans mur de 15m de haut autour du jardin, parce qu'un voisin risquerait de regarder par mégarde.

Le chiffrement ralentit internet et augmente sa consommation en énergie. Et ça va couper l'envie à 99% des gens de faire la moindre page web perso. Et je REFUSE de rentrer dans ce jeu-là.

C'est aux sites internet eux-mêmes de proposer gentiment de passer sur la version sécurisée s'il y en a une. Ou au navigateur, s'il voit que le site a déclaré une version sécurisée.

J'espère fortement que Mozilla annonce ça juste pour l'effet choc que ça produit, et qu'ils n'ont en aucun cas l'intention de mettre cette menace à exécution.
- [^] # Re: La pire nouvelle pour l'internet depuis longtemps
  
  Posté par X345 le 04 mai 2015 à 10:58. Évalué à 10.
  
  Le chiffrement ralentit internet […]
  
  Ça c'est pas grave puisque le Pentium 4 accélère l'Internet. Du coup, ça compense.
- [^] # Re: La pire nouvelle pour l'internet depuis longtemps
  
  Posté par Laurent J (site web personnel, Mastodon) le 04 mai 2015 à 12:38. Évalué à 2.
  
  Le touriste du web a rarement son nom de domaine, et héberge son blog ou son contenu chez des hébergeurs en sous domaine. Du coup, ils profiteront du https sans rien débourser.
  
  Le chiffrement ralentit internet
  
  LOL. Internet n'est pas ralenti parce que le contenu de tes paquets TCP sont chiffrés. Un octet est un octet.
  
  Ce qui "ralentit" Internet, c'est plutôt tous ces conn**ds de spammeurs, et surtout tous ceux qui visionnent des videos (via youtube, dailymotion, netflix…)
  
  Tu dois confondre avec le ralentissement de l'affichage des pages sur ta machine, qui doit déchiffrer le contenu que t'amène Internet :-p
  
  et augmente sa consommation en énergie.
  
  Bof..
  - [^] # Re: La pire nouvelle pour l'internet depuis longtemps
    
    Posté par marzoul le 04 mai 2015 à 13:02. Évalué à 4.
    
    Le ralentissement vient effectivement des opérations de chiffrement et déchiffrement, mais pas que.
    Négocier une connexion sécurisée demande plusieurs échanges, invisibles pour l'internaute, avant même de parler du contenu de la page demandée. Ça coûte de la bande passante et surtout de la latence, augmente le nombre paquets à router, fait chauffer les routeurs.
    
    Quand charger une page prend 10s parce que google-analytics ne répond pas ou que la page charge 20 régies de pub par-dessous le tapis, je ne voudrais pas voir ce que ça donnerait en chiffré.
    
    Je n'ai rien contre le chiffrement en lui-même, d'ailleurs j'y tiens pour certains sites. Cependant le chiffrement généralisé est une méthode inappropriée au vu des problèmes qu'elle prétend résoudre. Il est encore plus dangereux de faire croire aux gens que chiffrement = sécurité (en tous cas avec les méthodes de chiffrement actuelles et les gouvernements qui vont avec).
    - [^] # Re: La pire nouvelle pour l'internet depuis longtemps
      
      Posté par Joris Dedieu (site web personnel) le 04 mai 2015 à 13:52. Évalué à 5.
      
      Il est encore plus dangereux de faire croire aux gens que chiffrement = sécurité (en tous cas avec les méthodes de chiffrement actuelles et les gouvernements qui vont avec).
      
      Pas seulement.
      - Le chiffrement ne résout pas le problème du leak d'information crossdomain
      - Ni les problèmes viraux du client
      - Ni les problèmes de prédictibilité et de répétition des mots de passes
      - Ni les problèmes de confidentialité
      - …
      
      Bref le chiffrement n'apporte de la sécurité que face aux oreilles non autorisés à condition que le CA n'est pas divulgué sa clé à quelques officines contre de juteux marchés. Personnellement, je me sens plus en sécurité grâce à noscript, qu'a Symantec.
      - [^] # Re: La pire nouvelle pour l'internet depuis longtemps
        
        Posté par ckyl le 04 mai 2015 à 18:53. Évalué à 5.
        
        En attendant ton fai revend tous tes hits http:// à a peu près la même clique que ceux qui font du leak cross domain. Bon on est en France, ils sont anonymisés avant hein.
        
        Y'a plusieurs niveaux avant d'arriver à vouloir échapper à la nsa…
# HTTP c'est pas seulement sur Internet

Posté par alberthier (site web personnel) le 05 mai 2015 à 11:10. Évalué à 10.

C'est dommage cette évolution.

La simplicité du protocole permet de l'implémenter sur de petits microcontrôleurs (genre PIC32)
On peut faire une simple interface de config avec une série de balises input
Faire du HTTPS sur ce type de matériel est exclu

J'imagine que python & co vont se mettre à la page si HTTP en clair est supprimé, mais pour l'instant, python -m SimpleHTTPServer c'est du HTTP tout court. Ces petits serveurs sans prétention existent dans tous les langages et sont bien pratiques en dev.

HTTPS sur internet, pourquoi pas, mais sur le réseau local, bof, bof…
- [^] # Re: HTTP c'est pas seulement sur Internet
  
  Posté par oinkoink_daotter le 06 mai 2015 à 21:08. Évalué à 3.
  
  La simplicité du protocole permet de l'implémenter sur de petits microcontrôleurs (genre PIC32)
  On peut faire une simple interface de config avec une série de balises input
  Faire du HTTPS sur ce type de matériel est exclu
  
  En même temps, ce genre de pratiques est-il toujours souhaitable ? C'est marrant techniquement, mais c'est inmaintenable dans la durée.
  
  HTTPS sur internet, pourquoi pas, mais sur le réseau local, bof, bof…
  
  On peut aussi faire du telnet et du rsh. C'est du même tonneau.
# shttp

Posté par bakeru le 05 mai 2015 à 12:23. Évalué à -2.

Et si on allait chercher trop loin alors qu'on a déjà des solutions ?

Mon point de vue est qu'on devrait faire de HTTP ce qu'on a fait avec FTP, en l'adaptant aux besoins.

Si l'objectif est de protéger la vie privée, d'éviter les interceptions en clair et de modifier le contenu des paquets, alors je ne pense pas qu'on est besoin de la chaîne de confiance, toute relative, d'HTTPS.

On garde HTTP, on peut réfléchir aux problèmes d'HTTPS mais à côté, on peut implémenter SHTTP.

SHTTP, ça serait des tunnels SSH pour sécuriser HTTP. Un système de clé privée/publique par domaine, avec son empreinte qu'on pourrait publier dans les enregistrements DNS, et le tout avec du Perfect Forward Privacy.

Les avantages, c'est qu'SSH est déjà bien connu, et qu'on sait faire du PFP avec.

Avec l'exemple d'SFTP, on peut avoir une idée des points négatifs qu'on aurait avec SHTTP.

Du point de vue de l'administration système, je trouve ça plus gérable. (On génére une paire de clefs pour un domaine donné, ça fait une ou deux lignes dans un fichier de conf, on récupére l'empreinte, qu'on publie dans le dns pour le domaine donné.)

Ca permet une transition en douceur, même si il reste des questions techniques à résoudre.
- Est-ce qu'on garde le port 80, par exemple.

Ca permet de ne pas confondre HTTP dans HTTPS et de garder les certificats pour ce qu'ils sont.
Généraliser HTTPS, c'est, peut-être, faire croire qu'il n'y plus de risques et l'utilisateur si il voit un cadenas, pensera qu'il est à l'abri.

Je m'imagine donc une prise en charge des naviguateurs et des serveurs web en douceur, puisse qu'on ne touche pas à HTTP, ni à HTTPS et qu'on verrait apparaître des liens en shttp:// sur les pages web et les moteurs de recherche.

L'enregistrement des empreintes dans le naviguateur pour la comparer les empreintes avec celle du DNS. Ainsi, soit le site aurait compromis si l'empreinte change, soit il aurait changé de clefs.

Les points négatifs, j'ai du mal à les voir.

La charge plus importante pour encrypter les données, mais que ça soit du SHTTP ou HTTPS, ça posera les mêmes problèmes, je pense.
- [^] # Re: shttp
  
  Posté par gouttegd le 05 mai 2015 à 12:55. Évalué à 6.
  
  Et si on allait chercher trop loin alors qu'on a déjà des solutions ?
  
  C’est exactement ce que je me suis dit en lisant ta proposition…
  
  Un système de clé privée/publique par domaine, avec son empreinte qu'on pourrait publier dans les enregistrements DNS, et le tout avec du Perfect Forward Privacy.
  
  On peut faire tout ça sans avoir à créer un nouveau protocole, tout est déjà en place. Mince, je fais déjà tout ça, moi tout seul dans mon coin, qu’on ne vienne pas me dire que ce n’est pas possible.
  
  Le problème n’est pas de pouvoir faire ça, mais de faire en sorte que les clients s’en servent. Et là, je te souhaite bon courage pour obtenir des éditeurs de navigateurs qu’ils prennent en charge ton shttp.
  
  Je m'imagine donc une prise en charge des naviguateurs et des serveurs web en douceur, puisse qu'on ne touche pas à HTTP, ni à HTTPS
  
  Et la marmotte… DANE non plus ne touche à rien de ce qui existe déjà, il peut complètement coexister avec le modèle actuel, et regarde les réticences qu’il rencontre.
  
  Les points négatifs, j'ai du mal à les voir.
  
  Premier point : si les empreintes sont publiées dans le DNS, il faut pouvoir se fier aux données du DNS. Bonne nouvelle, il suffit de les signer, et DNSSEC et là pour ça. Mauvaise nouvelle : les acteurs du web mettent un point d’honneur à faire comme si DNSSEC n’existait pas.
  
  (En fait, ils se moquent tellement de DNSSEC et du fait que le DNS seul n’est pas fiable que lors de l’annonce de la faille Kaminsky — qui trivialise l’empoisonnement de cache —, beaucoup de gens ont réagi en disant « bof, pas grave, de toute façon on a SSL par-derrière pour “garantir” (sic) qu’on se connecte bien au bon serveur, si le DNS nous envoie ailleurs la couche SSL nous avertira ».)
  
  Deuxième point : c’est le même point négatif que toutes les autres alternatives envisagées depuis des années : tant que tu ne mettras pas Google, Mozilla, Microsoft ou Apple derrière toi, ça ne sera jamais implémenté que par quelques geeks dans leur coin.
  - [^] # Re: shttp
    
    Posté par bakeru le 05 mai 2015 à 15:19. Évalué à -4.
    
    Et la marmotte… DANE non plus ne touche à rien de ce qui existe déjà, il peut complètement coexister avec le modèle actuel, et regarde les réticences qu’il rencontre.
    
    Au temps pour moi, j'avais zappé la discussion sur DANE et surtout sa description. C'est très intéressant d'ailleurs.
    
    Premier point : si les empreintes sont publiées dans le DNS, il faut pouvoir se fier aux données du DNS. Bonne nouvelle, il suffit de les signer, et DNSSEC et là pour ça. Mauvaise nouvelle : les acteurs du web mettent un point d’honneur à faire comme si DNSSEC n’existait pas.
    
    Pas mieux, j'ai pas encore essayé DNSSEC, uniquement à cause de l'énumération des enregistrements DNSSEC de la zone.
    
    Deuxième point : c’est le même point négatif que toutes les autres alternatives envisagées depuis des années : tant que tu ne mettras pas Google, Mozilla, Microsoft ou Apple derrière toi, ça ne sera jamais implémenté que par quelques geeks dans leur coin.
    
    On est d'accord. Je vais divergé un peu mais mon opinion c'est que Mozilla ne défend plus les utilisateurs.
    
    Premier exemple, Firefox 31.6.0 sous Windows (à vérifier pour GNU/Linux, *BSD), ne permet plus de désactiver javascript par l'interface utilisateur, il faut passer pour about:config.
    
    Les requêtes safebrowsing semblent interroger les serveurs de Google, donc les sites qu'on visite, les fichiers qu'on télécharge, peuvent être connus de Google (Je serais moins réfractaire si c'était les serveurs de Mozilla).
    
    Les requêtes Jquery (j'entends par là, tout ce qui va sur googleapis.com) qu'on retrouve sur certains sites et qui intérrogent les serveurs de Google encore, je comprends pas pourquoi on fait des requêtes (sur Google), alors que le principe d'Internet c'est d'être décentralisé, du coup je préférerais avoir la librairie incluse dans le navigateur par exemple.
    
    Un dernier petit exemple, les referer, on sait que Facebook & co, peuvent suivre les utilisateurs, même si ils ne sont pas inscrits grâce au bouton "j'aime" parce ce que le navigateur transmet le site référant à l'image du bouton.
    
    C'est pour tout ça et pour d'autres exemples que je pense que Mozilla a arrêté de se battre pour des idéaux. Et si ils ont arrêté de se battre, alors on a plus rien à attendre d'eux.
    
    Et je sais bien que certains exemples, que j'ai cité, peuvent casser certains sites web ou sont contraires aux RFCs mais je résumerai en disant qu'avant, on avait au moins le choix, maintenant on a le choix du conformisme.
    
    Pour revenir au sujet, DANE semble aller dans le bon sens pour résoudre les faiblesses d'HTTPS mais j'aime bien mon idée aussi.
    En fait, je pense que les deux sont bonnes, DANE résout les faiblesses d'HTTPS, alors que ma proposition voudrait généraliser le cryptage des données de la plus simple des manières.
    
    DANE pour la sécurité des transactions, la chaîne de confiance, SHTTP pour généraliser la protection de la vie privée et des correspondances.
    
    Et d'ailleurs, il faudrait appliquer les mêmes principes à SMTP mais celui-là est encore plus oublié qu'HTTP, et il faut rajouter le cryptage des requêtes DNS.
    - [^] # Re: shttp
      
      Posté par claudex le 06 mai 2015 à 21:11. Évalué à 3.
      
      Pas mieux, j'ai pas encore essayé DNSSEC, uniquement à cause de l'énumération des enregistrements DNSSEC de la zone.
      
      Tu parle de NSEC vs. NSEC3 ?
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
      - [^] # Re: shttp
        
        Posté par oinkoink_daotter le 06 mai 2015 à 21:17. Évalué à 2.
        
        J'imagine qu'il doit parler de la gestion du nxdomain. C'est toujours d'actualité le retour des champs immediatement autour d'où auraient été l'enregistrement dans le fichier de zone normalisé ? Je me rappelle que c'était un problème vers 2000, mais j'ai un peu lâché le truc après.
        
        [^] # Re: shttp
        
        Posté par claudex le 06 mai 2015 à 23:28. Évalué à 4.
        
        C'est le problème de NSEC, corrigé par NSEC3 (qui utilise le même principe que NSEC mais avec un hash, du coup, on peut prédire les hash autour, mais pas le vrai nom derrière).
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: shttp
        
        Posté par bakeru le 07 mai 2015 à 10:29. Évalué à 0.
        
        J'ai trouvé un article sur dnscurve.org qui résume les problématiques NXT vs NSEC vs NSEC3, par contre, il date un peu donc je sais pas si c'est toujours d'actualité.
    - [^] # Re: shttp
      
      Posté par oinkoink_daotter le 06 mai 2015 à 21:14. Évalué à 3.
      
      Les requêtes safebrowsing semblent interroger les serveurs de Google, donc les sites qu'on visite, les fichiers qu'on télécharge, peuvent être connus de Google (Je serais moins réfractaire si c'était les serveurs de Mozilla).
      
      saï plus compliquaï : http://en.wikipedia.org/wiki/Google_Safe_Browsing
      
      il faut rajouter le cryptage des requêtes DNS.
      
      Et on chiffre avec quoi ?
      - [^] # Re: shttp
        
        Posté par bakeru le 07 mai 2015 à 10:01. Évalué à 0.
        
        Et on chiffre avec quoi ?
        
        DTLS est évoqué dans ce sens
        
        [^] # Re: shttp
        
        Posté par oinkoink_daotter le 07 mai 2015 à 12:16. Évalué à 2. Dernière modification le 07 mai 2015 à 12:17.
        
        Quand je dis "on chiffre avec quoi", c'est avec quelle clef, ou certificat, comment on établit la confiance, ce genre de trucs. Et ça n'a pas l'air d'être évoqué dans la RFC que tu évoques, qui ne fait que discourir sur comment chiffrer de l'UDP.
        
        Parce que si c'est pour faire comme pour HTTPS, on rate un peu le problème.
        
        [^] # Re: shttp
        
        Posté par bakeru le 07 mai 2015 à 16:15. Évalué à 0. Dernière modification le 07 mai 2015 à 16:17.
        
        Il y a DNSCurve avec un système de clefs publiques et de courbes elliptiques (voir Wikipedia pour plus de détails).
        
        dnscache le supporte et il y a curvedns mais pas de support dans BIND ou d'autres.
- [^] # Re: shttp
  
  Posté par Zenitram (site web personnel) le 05 mai 2015 à 15:21. Évalué à 3. Dernière modification le 05 mai 2015 à 15:22.
  
  avec son empreinte qu'on pourrait publier dans les enregistrements DNS
  
  donc avec DNSSEC. Mais du coup, si DNSSEC est déployé partout et que ça marche bien (que c'est crédible), DANE n'est plus loin et plus de reproches à faire à HTTPS (c'est résolu avec DANE), donc finalement c'est résolu avant d'attaquer un SHTTP tout nouveau, pshit.
  le problème reste la première connexion. Tu ne résouts aucunement le problème, tu proposes un changement de la partie qui n'est pas critique, sans résoudre le problème critique. autrement dis, tu cherches à résoudre le problème qui en n'est pas un sans résoudre le problème qui en est un.
  
  Sinon, pour info, je vois maintenant plus de FTPS (donc équivalent de HTTPS) que de SFTP. Je crains que ça n'aille pas dans le sens que tu aimerais…
  - [^] # Re: shttp
    
    Posté par gouttegd le 05 mai 2015 à 15:48. Évalué à 2.
    
    le problème reste la première connexion
    
    Euh, dans ton hypothèse où « DNSSEC est déployé partout et que ça marche bien », la première connexion n’est plus critique. Tu récupères l’empreinte du certificat du serveur dans le DNS avant la première connexion au serveur TLS, donc le serveur est correctement authentifié dès le départ, il n’y a pas besoin de leap of faith ou de trust on first use.
    
    Le seul « acte de foi » requis est envers le gérant de la zone DNS : s’il te raconte n’importe quoi (par malveillance, incompétence ou parce que son système d’avitaillement a été piraté — ce qu’on peut ranger dans l’incompétence en un sens, il lui appartient de savoir se protéger), ce n’est pas DNSSEC qui va te protéger de ça.
    
    C’est l’équivalent, dans le monde DNSSEC/DANE, de l’acte de foi envers les autorités de certification du monde PKIX. À celà près que dans le monde PKIX, tu dois faire confiance à toutes les CA reconnues, quand DNSSEC/DANE te demande de faire confiance au seul bureau d’enregistrement du domaine que tu visites.
    - [^] # Re: shttp
      
      Posté par kna le 05 mai 2015 à 16:11. Évalué à 2.
      
      J'ai un .fr chez Gandi. Si je veux mettre DNSSEC, je peux balancer ma clé sur l'interface de Gandi. Je ne sais pas, moi, comment elle est transmise derrière à l'AFNIC. Donc si Gandi se fait pirater, le malotru pourra mettre sa clé à la place/en plus de la mienne, qui sera envoyée de la même façon à l'AFNIC, donc sa fausse zone sera validée par DNSSEC.
      
      Avec mon raisonnement, je ne dois pas simplement faire confiance au gérant de la zone, mais aussi à tous les registars avec lesquels il travaille.
      Ou alors quelque chose m'échappe, et je veux bien qu'on m'explique.
      - [^] # Re: shttp
        
        Posté par gouttegd le 05 mai 2015 à 18:22. Évalué à 2.
        
        je ne dois pas simplement faire confiance au gérant de la zone, mais aussi à tous les registars avec lesquels il travaille.
        
        Erreur de vocabulaire de ma part, désolé.
        
        L’acte de foi est bien envers le bureau d’enregistrement auprès de qui le gérant de la zone a obtenu son domaine (et à qui il communique sa clef DNSSEC, ou l’empreinte de celle-ci).
        
        Pour ce qui est du gérant de la zone, il faut certes aussi lui faire confiance, mais je partais du principe que celui-ci relève généralement de la même entité que celle qui gère le service auquel je veux me connecter — cette entité n’est pas un tiers de confiance, c’est l’une des deux parties dans la communication.
        
        [^] # Re: shttp
        
        Posté par kna le 05 mai 2015 à 20:53. Évalué à 2.
        
        Erreur de vocabulaire de ma part aussi, en fait :)
        
        Je voulais dire « gérant du TLD » en fait. Le bureau d'enregistrement n'est qu'un intermédiaire entre lui et le client final qui va gérer le domaine. Mais c'est bien au niveau du TLD que va être mise la clé pour signer ta zone. Donc il y a bien 2 intermédiaires. Dans mon exemple :
        
        AFNIC -> Gandi -> example.fr
        
        Et je ne compte pas l'ICANN qui gère la racine, les registars qui achètent les noms de domaine à d'autres registars, les délégations de sous-domaines…
        
        [^] # Re: shttp
        
        Posté par gouttegd le 06 mai 2015 à 02:18. Évalué à 5.
        
        Question intéressante sur laquelle je ne m’étais pas penchée. Si un attaquant s’en prend à l’AFNIC et obtient le contrôle de la zone fr. (ou si l’attaquant est l’AFNIC, ce qui revient au même), que peut-il faire ?
        
        L’option la plus simple, je pense, est de supprimer l’enregistrement DS pour example.fr., brisant ainsi la chaîne de confiance allant de la racine jusqu’au contenu de la zone. L’enregistrement TLSA pour www.example.fr. sera toujours là, mais en l’absence de délégation sécurisée cet enregistrement sera considéré non-sécurisé et le navigateur web devra obligatoirement l’ignorer (RFC 6698, §4.1). L’attaquant peut alors tenter son attaque MITM en présentant un faux certificat — la réussite ou l’échec de cette attaque dépendra des autres moyens de vérification implémentés dans le navigateur (PKIX, Convergence, éventuellement HPKP si ce n’est pas la première visite, etc.), mais l’attaquant ne sera plus gêné par DANE qui est hors-jeu à ce stade.
        
        Une faiblesse de cette attaque est qu’elle est facilement détectable : une zone entière qui devient subitement non-sécurisée, il y a peu de chance que ça passe inaperçu. Par contre, un avantage est qu’elle offre un certain déni plausible : si l’AFNIC est prise la main dans le sac, elle peut facilement faire passer ça pour une honnête erreur (« oups, désolé, l’enregistrement DS a sauté à cause d’une bête erreur dans le script qui re-signe périodiquement le fichier de zone, ~~on a viré le stagiaire~~ ça n’arrivera plus, promis ») — un peu comme les CA prises à émettre des certificats frauduleux, d’ailleurs.
        
        Donc il y a bien 2 intermédiaires. Dans mon exemple :
        
        AFNIC -> Gandi -> example.fr
        
        Oui, clairement. J’argumenterais que ça reste mieux que le système PKIX où il faut faire confiance à toutes les CA, mais dire que le bureau d’enregistrement est le seul tiers de confiance était exagéré.
        
        Et je ne compte pas l'ICANN qui gère la racine
        
        Il faudrait pourtant, même si une attaque à ce niveau serait probablement encore moins discrète qu’une attaque au niveau du TLD.
  - [^] # Re: shttp
    
    Posté par bakeru le 05 mai 2015 à 16:24. Évalué à -4.
    
    Je suis plus attaché au principe général, qu'au principe technique que je propose:
    
    Un système de clé privée/publique (par domaine/enregistrement dns) avec le support de PFP et l'enregistrement de l'empreinte dans le dns.
    Et si il peut être adapter à SMTP ou d'autres, c'est encore mieux.
    
    Le principe de clé privée/publique, il est commun à TLS, SSH. Alors, peu importe l'aspect technique.
    
    Le sujet, c'est Mozilla qui pousse HTTP vers la sortie, mais je ne pense pas que généraliser HTTPS soit la solution, il y a trop de contraintes à gérer les certificats alors que une bonne paire de clefs avec un support PFP peut faire le travail.
    - [^] # Re: shttp
      
      Posté par Zenitram (site web personnel) le 05 mai 2015 à 18:01. Évalué à 4.
      
      mais je ne pense pas que généraliser HTTPS soit la solution
      
      Beaucoup pour penser que HTTPS n'est pas la solution, personne pour proposer une meilleure (en pratique, pas la théorie branlette intellectuelle) solution…
      En attendant, on fait quoi? Rien mieux que HTTPS qui a fait ses preuves (si, ça a fait ses preuves et ça marche globalement bien), sérieux?
      
      Ca me fait penser aux français qui poussaient ATM "trop bien ça vire les merdes d'IP ce protocole sans qualité" et IP leur a massacré la gueule (vaut mieux 10 Gbps sans qualité que 622 Mbps avec qualité garantie, ben la pareil pour HTTPS : des gens proposes des contraintes fortes pour une "meilleure qualité" mais en pratique…)
      PS : pour les plus jeunes, si vous ne connaissez pas ATM c'est normal, c'était un protocole très cher qui résolvait un problème qu'IP a résolu avec de petites évolutions et qu'en fait ce n'était pas un problème qui valait autant de fric pour le supprimer.
      
      Je suis plus attaché au principe général
      
      Ton principe général résout un problème qui n'existe pas sans résoudre le problème que tu soulèves (oui, je me répète).
      - [^] # Re: shttp
        
        Posté par bakeru le 05 mai 2015 à 18:50. Évalué à -3.
        
        Beaucoup pour penser que HTTPS n'est pas la solution, personne pour proposer une meilleure (en pratique, pas la théorie branlette intellectuelle) solution…
        
        J'aime bien la théorie branlette intellectuelle, et alors? Y a ceux qui ont les idées, et ceux qui les appliquent (à leur sauce si ils veulent).
        
        Ton principe général résout un problème qui n'existe pas sans résoudre le problème que tu soulèves (oui, je me répète).
        
        Je t'ai relu et en fait, je ne comprends pas ce que tu veux dire, ni quel problème je soulève.
        Je pense avoir assez explicité mon idée donc je ne vais pas me répéter.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.