Les serveurs utilisent des certificats TLS (ex SSL) pour permettre des échanges chiffrés avec les navigateurs (éviter les écoutes, les modifications, protéger la vie privée, sécuriser des échanges financiers, permettre de vérifier que le serveur est le bon, etc.). Et donc soit on auto-certifie son propre certificat, soit on passe par une autorité de certification (ou une chaîne d'autorités).
Côté client, les autorités acceptées sont gérées soit par le navigateur (Firefox, Chrome, Opéra, un navigateur basé sur java…) et c'est alors spécifique au navigateur , soit le navigateur délègue ça au système (rekonq, konqueror, iceweasel…) et c'est alors spécifique au système.
LinuxFr.org utilise un même certificat sur les différents domaines gérés, dont les serveurs de production et de test, le serveur cache des images, ainsi que le gestionnaire de listes de diffusion. Ce certificat doit être mis à jour sous peu (le 7 juin). Et comme à chaque mise à jour, les mêmes questions vont revenir, c'est donc l'occasion de faire le point sur le sujet (dans la seconde partie de la dépêche).
Voici quelques questions que vous pouvez vous poser à ce sujet :
- d'abord les points déjà présents dans la foire aux questions :
- comment gérer l'alerte dans les navigateurs en raison de l'autorité de confiance Cacert
- pourquoi nous ne prenons pas un certificat SSL/TLS gratuit ou payant de chez Machin qui est par défaut dans un navigateur
- pourquoi les avatars et images ne s'affichent pas chez moi en HTTPS ? (oui le certificat est utilisé sur les différents domaines du site, dont les serveurs de production et de test, ainsi que le gestionnaire de listes de diffusion)
- pas d'utilisation de HSTS : d'une part, nous ne voulons pas forcer tous nos utilisateurs à passer en HTTPS, d'autre part, si la navigateur ne reconnaît pas le certificat, alors il affiche une page blanche au lieu de la page d'avertissement qui permet d'ajouter un certificat.
- utilisation de cookies pour rester en HTTPS : quand quelqu'un se connecte depuis la version HTTPS du site, ses cookies sont en mode sécurisé : ils ne sont envoyés que quand on se connecte en HTTPS, pas en HTTP. Un autre cookie https, pas secure celui-là, est également ajouté. Quand ce cookie est présent et que l'utilisateur demande une page en HTTP, il est automatiquement redirigé vers la page équivalent en HTTPS.
- HTTPS Everywhere : aux dernières nouvelles, l'extension ne fonctionnait pas bien avec le site.
- la syntaxe « relative protocol» (on ne précise pas HTTP ou HTTPS, celui-ci reste le même que sur la page actuellement consultée qui contient le lien) est autorisée par les RFC 1808 partie 2.2 et RFC 3986 partie 4.2.
- la question des flux Atom : les lecteurs de flux ne supportent pas toujours les cookies.
- l'autorité CaCert a renforcé son système d'assurance : les assureurs doivent passer avec succès un test sous forme de QCM avec 25 questions (prises au hasard dans un ensemble plus vaste) sur la procédure d'assurance, les certificats, le fonctionnement de CaCert, etc. J'étais déjà assureur pour l'association LinuxFr et j'ai par exemple dû passer le test pour récupérer mon statut et produire le nouveau certificat. C'est une bonne chose de vérifier les connaissances des assureurs.
Une fois que l'on a rappelé tout cela, on peut espérer qu'un certain nombre de nos visiteurs auront vu cette dépêche avant de rencontrer un souci lors du changement de navigateur. Mais peut-on faire plus, comment détecter qu'un navigateur va avoir un souci de certificat sur un serveur donné ?
L'entrée dans le système de suivi Proposer une page d'aide à la configuration HTTPS cherche à trouver une solution permettant de prévenir les soucis : il faudrait créer une page d'aide pour la configuration HTTPS. Cette page comporterait des explications sur le certificat CAcert utilisé par LinuxFr.org ainsi qu'un mécanisme pour détecter si l'utilisateur peut accéder à linuxfr.org et au sous-domaine img.linuxfr.org. N'hésitez pas à contribuer à cette réflexion !
# Flux atom et https
Posté par alpha_one_x86 (site web personnel) . Évalué à 0.
Perso j'ai du mal à comprendre l'avantage d'utilisé le https sur les flux atom, vu que par définition c'est public. Alors les cookies…
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Flux atom et https
Posté par claudex . Évalué à 10.
Ce n'est pas parce que c'est public que tu veux que tout le monde soit au courant de ce que tu lise (par exemple, parce que tu es dans un WiFi public).
« 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: Flux atom et https
Posté par Anonyme . Évalué à 6.
Ca permet aussi d'etre sur que personne ne l'a modifié.
[^] # Re: Flux atom et https
Posté par Juke (site web personnel) . Évalué à 3.
Quel est le rapport ?
[^] # Re: Flux atom et https
Posté par flan (site web personnel) . Évalué à 4.
Il y a l'assurance que personne ne regarde ce que tu fais, et que tu lis la chose que tu veux vraiment lire.
Bon, faut bien reconnaître que pour linuxfr, ce n'est pas non plus super critique.
[^] # Re: Flux atom et https
Posté par rakoo (site web personnel) . Évalué à 6.
Non, on ne saura pas quel est le contenu exact que tu lis. Par contre, il y a quand même l'information que tu te connectes a linuxfr.org sur une socket TCP sur le port 443. C'est quand même beaucoup, suffisamment pour savoir ce que tu fais, et j'aurais presque tendance a dire que la page que tu consultes après n'a pas d'importance en comparaison.
[^] # Re: Flux atom et https
Posté par Nahuel . Évalué à 4.
Pas que tu te connectes à "linuxfr.org", mais à l'IP associée, ça ne dit pas de quel vhost tu récupères les données.
[^] # Re: Flux atom et https
Posté par Zenitram (site web personnel) . Évalué à 5.
tu crois qu'il y a combien de vhosts sur la machine de linuxfr et/ou sur n'importe quel site un temps soit peu utilisé?
[^] # Re: Flux atom et https
Posté par Gof (site web personnel) . Évalué à 6.
Le nom de domaine passe en claire dans la négociation TLS. [http://en.wikipedia.org/wiki/Server_Name_Indication]
[^] # Re: Flux atom et https
Posté par claudex . Évalué à 0.
C'est une extension de TLS et pas mal de site ne la prenne pas en charge à cause du non support d'IE8.
« 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: Flux atom et https
Posté par Gof (site web personnel) . Évalué à 6.
IE8 supporte cette extension, c'est Windows XP qui ne la supporte pas.
Et la prise en charge du serveur n'a rien à voir. Si le client la prends en charge (cet à dire quasiment tous les navigateur de nos jour) , le nom de domaine sera présent en clair dans le premier paquet envoyé par le client.
En pratique, le nom de domaine des sites visité en https passent toujours en clair.
[^] # Re: Flux atom et https
Posté par billux (site web personnel) . Évalué à 1.
Oui, mais juste avant tu auras fait une requête DNS pour résoudre linuxfr.org., que la personne malveillante pourra voir passer.
À condition que tu n'ai pas de cache DNS sur ta machine bien sûr.
[^] # Re: Flux atom et https
Posté par Juke (site web personnel) . Évalué à 3.
tu as evidemment un cache dns et de toute facon tu fais passer tes requetes dns par ton proxy socks :)
[^] # Re: Flux atom et https
Posté par Xavier Teyssier (site web personnel) . Évalué à 2.
de toute facon tu fais passer tes requetes dns par ton proxy socks
Ouais… D'ailleurs, chrome le fait en natif, Firefox daigne le faire si on va trifouiller une clef dans about:config, et pour Opéra ? Y'a pas moyen de lui indiquer que les requêtes DNS doivent passer par le proxy socks ?
[^] # Re: Flux atom et https
Posté par ariasuni . Évalué à 3.
Tu veux parler de la clé
network.proxy.socks_remote_dns? (et effectivement, à faux par défaut)Quels sont les avantages et les inconvénients à faire ça? Ça m’intéresse beaucoup de connaitre la réponse.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Flux atom et https
Posté par Xavier Teyssier (site web personnel) . Évalué à 2.
Oui, cette clef là.
L'intérêt, c'est que ce soit bien l'ensemble du trafic qui passe par le proxy socks, et non, tout le trafic sauf les requêtes DNS. Ainsi, quelqu'un qui sniff la connexion utilisé, au lieu de connaître juste la liste des sites accédé, ne donnais rien du tout.
Et je pense pouvoir ajouter qu'ainsi, je suis sur du DNS que j'utilise, ce qui me permet d'éviter les DNS menteurs de certains hotels…
[^] # Re: Flux atom et https
Posté par ariasuni . Évalué à 1.
Mais si c’est mieux, pourquoi ça n’est pas activé par défaut?
Sinon je suis pas sûr de bien comprendre ce qu’est un proxy socks et comment il fonctionne. En regardant sur Wikipédia, ce que je vois c’est que c’est un proxy qui transmet notre requête au serveur — mais le proxy il sort d’où? En quoi c’est plus sûr de rajouter un maillon à la chaine?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Flux atom et https
Posté par Juke (site web personnel) . Évalué à 2.
Parce que tout le monde ne fais pas passer son traffic par un proxy, quand on est à la maison par exemple, l'interet est limité en dehors du cache, par contre effectivement quand on choisi de regler un proxy socks le traffic dns pourrait passer par defaut par le proxy comme le propose Foxy Proxy.
Tu l'installe sur ton serveur, OpenSSH fais ça tres bien.
ça n'a rien de plus sûr, ça permet de chiffrer et de faire passer son traffic par un serveur quelque part, ça t'evites d'utiliser l'ip du boulot ou de la chambre d'hotel par exemple.
[^] # Re: Flux atom et https
Posté par ariasuni . Évalué à 2.
Ok, merci.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Flux atom et https
Posté par claudex . Évalué à 3.
L'avantage, c'est de chiffrer aussi les communication DNS (éviter du DNS poisining sur le réseau local, avoir un DNS que tu as choisi et pas celui menteur du réseau local, éviter qu'on puisse espionner tes requêtes DNS…). L'inconvénient, c'est que c'est potentiellement beaucoup plus long (en fonction de ton proxy Socks, de ton DNS local…). De plus, il faut un DNS à contacter (autre le celui du réseau local).
« 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: Flux atom et https
Posté par ariasuni . Évalué à 1.
C’est la que je n’ai pas compris: faut configurer le DNS sur la machine qui fait proxy?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Flux atom et https
Posté par Juke (site web personnel) . Évalué à 2.
En regle general ton proxy sais resoudre le dns (sur localhost ou sur autre chose)
[^] # Re: Flux atom et https
Posté par ariasuni . Évalué à 1.
Donc si j'ai compris ça sert à rien de mettre un proxy sur mon serveur pour naviguer sur Internet à partir de chez moi… Par contre ça peut être très utile si je suis ailleurs.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Flux atom et https
Posté par Juke (site web personnel) . Évalué à 2.
Exactement. Mais ça peut être intéressant chez toi si ça sert de proxy cache pour tous tes terminaux.
[^] # Re: Flux atom et https
Posté par claudex . Évalué à 3.
Ça peut être intéressant d'utiliser un proxy chez toi si tu ne fais pas confiance à ton FAI.
« 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: Flux atom et https
Posté par Juke (site web personnel) . Évalué à 2.
heu dans ces cas là il faut sortir sur un autre fai non ?
[^] # Re: Flux atom et https
Posté par claudex . Évalué à 3.
Il y a plein de bonnes et mauvaises raisons d'avoir et/ou de garder un FAI dont on est pas satisfait.
« 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: Flux atom et https
Posté par Juke (site web personnel) . Évalué à 2.
Certes mais ça implique d'avoir un fournisseur d'acces different pour son serveur.
[^] # Re: Flux atom et https
Posté par claudex . Évalué à 3.
Ah oui, évidemment.
« 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: Flux atom et https
Posté par ariasuni . Évalué à 1.
Du coup c’est con parce que j’ai un serveur auto-hébergé…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Flux atom et https
Posté par claudex . Évalué à 3.
Si tu as confiance en ton FAI, ça ne pose pas de problème.
« 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: Flux atom et https
Posté par ariasuni . Évalué à 1.
Parce qu’il y a encore des FAI auxquels on peut faire confiance? (à part le réseau FFDN)
Je suis chez l’opérateur qui supprime les pubs des pages. Donc non j’ai pas trop confiance mais en attendant que je sois chez moi (et pas chez mes parents), je subis.
Écrit en Bépo selon l’orthographe de 1990
# Redirection ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Ça c'est moche. Si l'utilisateur est sujet à une attaque, la première chose que le pirate bloquera, c'est cette redirection. L'utilisateur, habitué à taper une adresse non sécurisée dans sa barre d'adresse sans se soucier de la suite, se connectera en clair…
[^] # Re: Redirection ?
Posté par Christie Poutrelle (site web personnel) . Évalué à 0.
Si l'utilisateur est sujet à une attaque, c'est contrecarré par le fait que le cookie de session HTTPS ne sera lu côté serveur que si la connexion est bien en HTTPS, donc même si l'attaque réussi à forger des requêtes avec le navigateur de l'utilisateur, elle ne pourra pas pour autant prendre son identité, puisqu'une requête aboutissant en HTTP ne permettra pas au code malicieux de faire quoi que ce soit. Et puis finalement tout ce que ça pourra faire est une infinite redirect loop, puisqu'en bloquant la redirection puis en tapant de nouveau le serveur, il redirigera de nouveau, etc… Si vraiment le hacker vire le cookie non secure et tente une action sur le site, le site sait que la connexion à la base provient d'une session HTTPS et n'identifiera normalement pas l'utilisateur en HTTP, encore une fois.
[^] # Re: Redirection ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Oulà, je ne suis pas sûr de tout comprendre. Sois sûr qu'un attaquant se connectera bien au site en HTTPS : ce n'est qu'entre le client et l'attaquant que la connexion sera en HTTP.
[^] # Re: Redirection ?
Posté par Christie Poutrelle (site web personnel) . Évalué à -2.
Je vois pas comment un utilisateur ayant tapé la bonne adresse puisse se faire prendre à ça, mis à part si sa couche réseau est sujette à un beau man-in-the-middle et qu'il ne cause pas à la machine à laquelle il pense causer. Si c'est le cas y'a juste plus rien à faire. Où alors j'ai pas saisi ta remaque ?
[^] # Re: Redirection ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Le principe même des certificat est d’empêcher tout MIN.
"La première sécurité est la liberté"
[^] # Re: Redirection ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Pas vraiment. D'empêcher tout MITM autre que par une autorité de certification ou quelqu'un autorisé par une autorité de certification.
[^] # Re: Redirection ?
Posté par nud . Évalué à 4.
Je dirais même plus, dans pas mal d'entreprises un "proxy https" est présent, sur le même modèle qu'un proxy http, et joue aux MITM en utilisant un certificat reconnu par les ordinateurs de l'entreprise, ce qui fait que tout passe en clair au niveau du proxy sans que ce soit forcément visible par les usagers.
[^] # Re:Redirection ?
Posté par Juke (site web personnel) . Évalué à 1.
Et ça vous derange pas que les admins lisent vos correspondances ?
[^] # Re:Redirection ?
Posté par claudex . Évalué à 7.
« 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:Redirection ?
Posté par Juke (site web personnel) . Évalué à 3.
Si ils installent un certificats pour faire un MITM c'est pour le faire et pour exploiter ces données sinon pourquoi depenseraient-ils de l'argent pour le faire ?
[^] # Re:Redirection ?
Posté par claudex . Évalué à 4.
Ils peuvent très bien vouloir mettre en place un filtrage sur le nom de domaine sans jamais lire le contenu des requêtes.
« 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:Redirection ?
Posté par Juke (site web personnel) . Évalué à 2.
Dans ce cas il n'ont pas besoin de mettre de certificat MITM, le domaine est en clair.
[^] # Re:Redirection ?
Posté par claudex . Évalué à 3.
Ça dépend des navigateurs (et s'il suffit d'utiliser IE8 sur XP pour pouvoir aller sur Facebook, ça va vite se savoir dans l'entreprise). De plus, les solutions qui offrent ces fonctionnalités font du MITM de base, donc ce n'est pas désactivable sans perdre la fonctionnalité de filtrage.
« 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:Redirection ?
Posté par Anonyme . Évalué à 2.
C’est antinomique. Si tu filtres sur le contenu, tu lis le contenu, par définition.
[^] # Re:Redirection ?
Posté par barmic . Évalué à 2.
Ça ne coûte pas plus chère qu'un proxy http classique. Les proxy http peuvent permettre d'avoir un cache au niveau du réseau de filtrer sur les nom de domaines ou en fonction de l'heure. Il y a pleins de raisons possibles.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Redirection ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Personnellement j'attend le premier admin passant au tribunal pour avoir lu des connections privés à des banques ou à des mails.
C'est du même niveau que d'écouter une conversation téléphonique.
"La première sécurité est la liberté"
[^] # Re:Redirection ?
Posté par Juke (site web personnel) . Évalué à 3.
Que ça soit à des banques, des mails aux copains, à la femme du patron ou à des syndicalistes ou qui leak les données de la boites c'est la meme chose qu'écouter une conversation téléphonique effectivement.
[^] # Re: Redirection ?
Posté par Xavier Teyssier (site web personnel) . Évalué à 5.
Je ne vois pas où est le souci.
Dans une boite avec une infrastructure suffisamment développée pour qu'il y ait un proxy HTTPS, tu as certainement signé une charte où tu t'engages à ne pas utiliser les structures de la boite à des fins privées, et où tu autorises les admins à y accèder.
Par ailleurs, le but premier de ce genre de proxy n'est pas de permettre aux admins d'assouvir un voyeurisme supposé, mais plutôt de permettre, par exemple, la mise en place d'outil qui vérifie que des données confidentielles qui ne sont pas censées sortir de la boite ne sont effectivement pas en train de sortir…
Quand à l'admin passant au tribunal, pas besoin d'attendre, c'est déjà arrivé quelque fois.
Un exemple récent : Par principe, un e-mail reçu sur la messagerie professionnelle n'est pas personnel
Je cite : "Le secret des correspondances ne s'applique pas à l'utilisation dans le cadre professionnel, de la messagerie électronique, dès lors que les échanges ne sont pas identifiés comme étant de nature personnelle"
Et au regard des différentes jurisprudence de ces dernières années, identifier les échanges comme étant de nature personnel n'est pas trivial. En gros, si tu n'as pas un gros [strictement personnel] dans l'objet de ton mail, il sera probablement considéré comme potentiellement professionnel.
[^] # Re: Redirection ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
" tu as certainement signé une charte où tu t'engages à ne pas utiliser les structures de la boite à des fins privées, et où tu autorises les admins à y accèder."
C'est pas parce que tu l'as signé, 1) qu'elle est légale, 2) et que l'admin a le droit de le vérifier.
"la mise en place d'outil qui vérifie que des données confidentielles qui ne sont pas censées sortir de la boite ne sont effectivement pas en train de sortir…"
Je me doute. Mais il n’empêche qu'ouvrir le courrier nominatif est strictement interdit dans une boite, ouvrir ses communications en ligne privé est du même niveau. Le secret de communication est dans la charte des droits de l'homme. Et il est admis qu'il y a des communications privés au sein d'une entreprise. En plus, c'est se tirer une balle dans le pied. Avec la mode du BYOD, les gens ne vont plus seulement utiliser leur propre appareil mais aussi le réseau 3G. Et il n'y aura plus rien à filtrer.
Je cite : "Le secret des correspondances ne s'applique pas à l'utilisation dans le cadre professionnel, de la messagerie électronique, dès lors que les échanges ne sont pas identifiés comme étant de nature personnelle"
Et donc il suffit de mettre un tag "perso" dessus, et c'est bon? idem pour les messages non lus ? Il est question ici de mail et pas d'internet au sens général.
Il est très simple d'avoir un mail perso, et donc on peut éviter l'usage du mail professionnel pour les données personnels. Mais dans les boites qui s'amusent avec des proxy MIN https, filtre en général tous les webmails. Dans ce cas, difficile de dire que les mails sont professionnel "la plus part du temps".
DE toutes façon, le cas du mail est connu. Ici, on parle de https, donc quand on va voir ses mails privé, sa banque, … ou même simplement, on ne veut pas que son patron regarde les mots clef que l'on tape dans google (maladie, médecin, grossesse,…).
"La première sécurité est la liberté"
[^] # Re:Redirection ?
Posté par Juke (site web personnel) . Évalué à 3.
Pourtant tout le monde possede un appareil photo sur son téléphone ou de la memoire pour se souvenir du contenu confidentiel, ça me semble contre productif.
[^] # Re:Redirection ?
Posté par claudex . Évalué à 4.
La plupart du contenu confidentielle s'échappe de manière involontaire (un client qui demande plus d'infos qu'il ne pourrait avoir accès, un zip vite fait qui contient tous les gros contrats, un employé qui veut bosser et s’envoie ses documents sur son adresse gmail…).
« 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:Redirection ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
un coup de 7zip, et le filtre ne verra rien, idem si les noms de fichier sont trop vagues.
"La première sécurité est la liberté"
[^] # Re:Redirection ?
Posté par claudex . Évalué à 5.
Les solutions dont j'ai entendu parler, elles savent dézipper et consulte l'intérieur des fichiers. Encore une fois, c'est pour lutter contre l'involontaire, pas la personne qui veut faire fuiter des informations à tout prix.
« 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:Redirection ?
Posté par Juke (site web personnel) . Évalué à 2.
Et la formation ou le licenciement ?
[^] # Re:Redirection ?
Posté par claudex . Évalué à 3.
La formation c'est en complément (tous le monde fait des fautes d’inattention). Le licenciement, c'est trop tard.
« 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:Redirection ?
Posté par Juke (site web personnel) . Évalué à 2.
Vu comme ça, c'est sensé. Mais je trouve ça bien trop intrusif.
[^] # Re:Redirection ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
ET puis j'ai un gros doute sur la manière de programmer un robot pour lui dire qu'un contenu est confidentiel ou pas.
"La première sécurité est la liberté"
[^] # Re:Redirection ?
Posté par claudex . Évalué à 3.
Je connais un type qui a mis ça en place, il m'a dit que ça marche (ça ne veut pas dire que c'est parfait, il a des faux et vrai négatif).
« 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: Redirection ?
Posté par nud . Évalué à 2.
De ce que j'ai pu voir c'est une config assez standard (style checkpoint ou ms machin truc), et c'est principalement utilisé pour empêcher les employés d'aller sur https://www.facebook.com
[^] # Re: Redirection ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 9.
Le but n'est pas d'être habitué à taper une adresse en http, mais de se retrouver face à une adresse en http que tu n'as pas tapée et qui vient d'une recherche sur un moteur, d'un lien envoyé par message instantanée, diffusé par courriel, etc. Ça t'évite de te faire avoir et de te retrouver en http quand tu voulais rester en https.
Cf l'aide sur les cookies
# Le meilleur des deux mondes?
Posté par Larry Cow . Évalué à 3.
En sachant que ce n'est pas exclusif : on peut tout à fait auto-certifier son propre certificat racine, et donc bénéficier de certains des avantages d'une autorité de certification. Le principe est généralement de produire un certificat racine à longue durée de vie (10 ans?), de stocker très précieusement sa clé privée, et de s'en servir à intervalles réguliers pour re-générer de nouveaux certificats.
L'avantage étant qu'on peut faire tourner régulièrement les certificats des serveurs, rajouter des certificats sur de nouveaux serveurs, sans pour autant avoir à modifier les clients (une fois qu'ils ont le certificat racine installé, et tant qu'il est valide).
Par rapport à un pur auto-signé, ça a un inconvénient de taille : ça demande une plus grande confiance de la part des utilisateurs. En effet, si on ajoute une exception pour un certificat "final", on ne peut - en cas de problème - être trompé que pour un site que ce certificat signait. En revanche, si on accepte une nouvelle racine, on s'expose à ce qu'un usage délictueux de la racine signe des choses pour Google ou Facebook. Sauf s'il existe un moyen de spécifier qu'une racine n'est valide que pour un certain nombre de (sous-)domaines, mais je n'ai jamais rien trouvé en ce sens.
[^] # Re: Le meilleur des deux mondes?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 6.
Il faut surtout faire un certificat d'autorité racine de longue durée, genre 10-50 ans, généré des autres certificats d'autorité avec une durée du genre 5 ans signé par le premier créer. Le premier sera placé dans un coffre dans une banque et on y accède uniquement lorsqu'il faut révoquer ou générer de nouveaux certificats d'autorités. À partir de là, même si le certificat d'autorité ayant signé le certificat serveur est compromis, le problème est moindre. C'est juste un peu chiant en terme de temps de réaction, mais il est toujours possible de créer une autorité sur trois étages avec au premier étage le CA racine dans le coffre à la banque, le deuxième étage des CA sur CD distribué à chaque admin ou gestionnaire des certificats et le troisième étage sur les serveurs avec la clé privée chiffrée par un mot de passe fort. Ainsi l'autorité de certification sera assez solide et réactive.
Dans le cas d'une association, on peut même envisager que le mot de passe des CA 1 et 2 soient découpés en petit morceau avec http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing et ainsi distribué la possibilité de généré des CA 3 en partageant le secret entre les diverses membres de l'association en définissant un quorum à atteindre pour que le secret existe.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Le meilleur des deux mondes?
Posté par Larry Cow . Évalué à 2.
Marrant, j'avais eu la même idée il y a quelques années, et puis le besoin ne s'est finalement jamais tant fait sentir que ça. Peut-être qu'intégrer ssss dans un truc "facile" comme XCA pourrait être une bonne solution.
# La question qui manque
Posté par Zenitram (site web personnel) . Évalué à 4.
Quand CACert va avoir le courage de se faire certifier, au minimum avec les navigateurs utilisés (oui, je sais, c'est dans Debian, mais vu l'utilisation de Debian sur le desktop…) qui aiment le libre (ça fait plus de 50% des utilisateurs touchés quand même)?
Car à défaut, on peut craindre le pire question confiance (à commencer par celle qu'eux-même ont sur eux) en la sécurité de CACert… La certification n'est pas la garantie que tout est bien (vu les trous qu'il y a eux chez certains organisme), preuve en est que le niveau demandé n'est pas bien élevé, mais même ça ce n'est pas fait.
Mais bon, c'est toujours le cordonnier le plus mal chaussé :).
[^] # Re: La question qui manque
Posté par Aris Adamantiadis (site web personnel) . Évalué à 4.
Je plussoie (comme quoi des fois on est d'accord :)). Si CACert ne respecte pas les critères pour être inclus dans des browsers comme FF,Chrome ou IE, je ne vois aucune raison pour laquelle je leur ferais confiance et les rajouterais en tant que CA.
Et le fait que d'autres CA ont eu leur lot de bavure n'est pas pour moi un argument positif pour CACert, voire même le contraire.
Pour le moment je me contente de rajouter une exception pour linuxfr.org.
[^] # Re: La question qui manque
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Bah, de toute façon les organismes reconnus ont des politiques de certification déplorables, et les vérifications qu'ils effectuent sur les identités de leurs clients sont risibles : leur intérêt, c'est de vendre des certificats, pas de refuser d'en vendre aux gens qui ne passent pas une vérification stricte !
À côté de ça, l'intérêt des gens qui effectuent les vérifications d'identité pour CAcert, c'est à dire les assureurs CAcert qui sont des gens comme vous et moi, c'est de bien faire ce travail de vérification. Entre CAcert et VeriSign, j'ai nettement plus confiance en CAcert qu'en VeriSign dont l'intérêt est de mal faire son travail.
[^] # Re: La question qui manque
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 06 juin 2013 à 11:37.
Tu as confiance en des gens qui ne souhaitent pas qu'on regarde trop chez eux alors que quand même, c'est un peu la base pour un certificat d'être dans les navigateurs, pourquoi pas…
Moi, j'ai du mal à faire confiance à des gens qui ne souhaitent pas se faire vérifier par Mozilla… Chacun sa confiance sans doute, mais j'ai plus confiance en la sécurité de Mozilla que de Debian (qui a accepté le certificat racine).
[^] # Re: La question qui manque
Posté par Adrien . Évalué à 3.
Alerte monde de bisounours : tu pars du principe que les gens sont bien intentionné… si un piiiarte devient assureur, c'est pas pour certifier le blog de chaton de sa grand-mère…
Dans ce cas pourquoi la totalité des banques, des magasins en lignes n'utilisent pas CAcert ??
[^] # Re: La question qui manque
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Parce que CAcert n'est pas reconnu par les navigateurs.
[^] # Re: La question qui manque
Posté par Zenitram (site web personnel) . Évalué à 0.
Et pourquoi CAcert n'est pas reconnu par les navigateurs?
Ca tourne en boucle, pour une raison simple : tu as confiance, mais les autres, qui ont des risques à gérer (que ce soit Mozilla ou les banques qui ne demandent pas que CACert soit inclu), non.
Perso, quand il y a autant de monde qui n'a pas confiance, il y a comme un doute sur la sécurité…
La confiance, ça se gagne, et force est de constater que CACert, dont le but est la confiance, a du mal à être mis comme de confiance. C'est gênant… En attendant, ça reste un truc de "geeks hyper branché" (les seuls à avoir confiance) dans leur petit monde, sans se frotter à la réalité (tout le monde se fout de CACert, il ne risque pas de se faire attaquer).
Dire que tout ça sera plus simple si CACert osait se faire vérifier… Trop simple sans doute.
[^] # Re: La question qui manque
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Ils l'ont fait, mais, par exemple, pour être dans OS X, il faut payer 75'000$ puis 10'000$ par an. Pour Firefox, le processus est bloqué car ils attendent sur Mozilla http://wiki.cacert.org/InclusionStatus …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: La question qui manque
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 06 juin 2013 à 14:03.
Ce n'est pas pour rien que j'ai parlé de navigateur qui aiment le libre (sans compter que moins d'une année.homme en fric, c'est jouable si il y a un intérêt. Ca ne vaut même pas ça pour vous? ca en dit long sur l’intérêt que vous y apportez en fait)… Mais bon, passons.
A ma connaissance, c'est CACert qui ne veut pas.
Si ce n'est pas le cas, qu'ils soient plus clairs, qu'ils diffusent le message, pour faire bouger les choses.
CACert est-il si important pour les libristes, ou est-ce juste pour le fun de faire chier avec un avertissement, afin de bien pourrir l'expérience utilisateur en SSL (car à force de cliquer n'importe comment, l'utilisateur se dit que c'est pas bien grave ce warning)?
[^] # Re: La question qui manque
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Pas vu, désolé.
Ouais en fait c'est un peu plus tordu, j'avais suivi l'histoire, me faut juste reprendre un bain de mailing list pour que la mémoire. Ils ont fait la requête puis lancé un audit, l'audit à détecté des problèmes, du coups la requête a été suspendue chez Mozilla et depuis j'ai plus suivi (aussi parce qu'après avoir contacter plein de monde j'ai jamais réussi à obtenir mes 5 ou 10 points manquant pour devenir assureur (une personne dans les 100km autour de chez moi et plus loin les gens ne répondaient pas ou alors qu'il ne faisait plus ou pas le temps ou …).
Mais un résumé de la situation de la requête, à l'époque, est là https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158 …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: La question qui manque
Posté par Zenitram (site web personnel) . Évalué à -2.
C'est bien le problème!
[^] # Re: La question qui manque
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Si mes souvenirs sont exacts, il ne s'agit pas de problèmes de sécurité mais de capacité à grandir qui ont été problématique.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: La question qui manque
Posté par barmic . Évalué à 3.
Non. En informatique le problème ce n'est jamais le bug ou l'erreur, c'est la manière de la gérer et le temps qu'on a mis pour le faire.
Ça n'est pas un problème que mediainfo ai des bugs, il faut juste que tu sois pas trop autiste et que tu les gère.
C'est un fantasme d'imaginer qu'on peut concevoir quelque chose sans faille.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La question qui manque
Posté par Zenitram (site web personnel) . Évalué à 2.
Je ne fais pas de sécurité.
Le problème est la : le but est de fournir un lien de confiance, et personne qui a des trucs sensible ne fait confiance à CACert, ça ne parait pas bizarre?
Tu me prend comme exemple, mais voila : mon but, je le rempli le plus possible, et je n'emmerde pas trop d'utilisateurs avec un crash à chaque lancement.
Ici, ben le produit a un problème : la sécurité ne marche que pour 1% des gens (bon, vu le degré de linuxiens, on va dire un peu plus avec des gens sous Debian, mais pas sous Ubuntu, Fedora…), et en attendant on incite les gens à contourner les warnings des navigateurs.
Si, c'est un problème, le patch pour LinuxFr est assez rapide mais refusé "politiquement".
[^] # Re: La question qui manque
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Le but de TLS est d'offrir une forme d'authentification, une vérification de l'intégrité et la confidentialité. Dans le cas d'un certificat auto-signé, nous avons que 2 sur 3. Le serveur n'est pas authentifié , mais les messages transmis sont intègres et confidentiels. Donc oui, on ne sait pas si on parle vraiment avec le bon serveur, mais on est certain que ce qu'on transmet est ce qui est reçu et que uniquement l'inconnu et nous sommes en mesure de connaître le contenu.
Donc entre prendre un protocole où il n'y a ni authentification, intégrité et confidentialité (HTTP) ou en prendre un avec uniquement intégrité et confidentialité (HTTPS avec certificat auto-signé), c'est déjà une amélioration.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: La question qui manque
Posté par Zenitram (site web personnel) . Évalué à 2.
Vu que sans authentification, n'importe qui peut faire un MITM, non tes messages sont au final aucun des 3.
Il empêche une personne de facilement lire tes messages, seulement "facilement".
Bon, OK, si tu es une fois par an (moment que tu ne décides pas) à une endroit sûr, tu peux prendre le bon certificat auto-signé et l'enregistrer, tu auras une alerte en cas de MITM ailleurs. Mais aussi une alerte quand l'admin change le certificat (donc si tu es dans un endroit non sûr, tu ne sais pas si c'est un MITM ou normal, cette non connaissance incite fortement les gens à ne plus rien avoir à foutre des alertes de sécurité, très bonne éducation…)
[^] # Re: La question qui manque
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il ne serait pas possible de "réduire" l'alerte, si le nouveau certificat est signé par l'ancien ?
"La première sécurité est la liberté"
[^] # Re: La question qui manque
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Non, l'alerte vient du fait qu'aucune autorité de confiance sélectionnée par les fournisseurs de navigateurs et/ou système d'exploitation n'a signé le certificat. L'authentification, dans TLS, vient du fait qu'un tiers de confiance signe ton certificat. Sans ça, pas d'authentification.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: La question qui manque
Posté par Etienne Bagnoud (site web personnel) . Évalué à 5.
Non pas pour le libriste, mais pour tout le monde. Les gens ont pris l'habitude de cliquer sur "Je comprends le risques"->"Accepter de prendre tous les risques"->"Je risque de tuer de mignons petits chatons par milliers mais je vais continuer quand même"->"Oui, oui je risque d'atomiser l'espèce humaine mais je veux voir de putain de site parce que c'est peut-être ce que je cherche".
Les gens s'en tapent de la sécurité, et c'est un euphémisme (j'ai des histoires à ne plus en dormir, mais je peux pas les raconter), alors si en plus on bloque la possibilité aux professionnels ou passionnés de pouvoir sécuriser correctement de leur côté par des pratiques douteuses : une trentaine d'euro par an pour que ces messieurs vérifient qu'ils y aient bien XYZ dans un champs TXT de mon DNS (non sécurisé avec DNSSEC évidemment), c'est douteux.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Blabla
Posté par Benoît Sibaud (site web personnel) . Évalué à 9.
Ce sujet est-il si important pour que tu y répètes plein de fois la même chose en insistant lourdement, ou est-ce juste pour le fun ou le plaisir rhétorique ?
Donc soyons constructif, ta solution c'est de
?
[^] # Re: Blabla
Posté par Zenitram (site web personnel) . Évalué à 2.
Vous avez décidé d'utiliser CACert, CACert a décidé de ne pas faire l'effort d'être inclus, je ne peux pas y faire grand chose.
Je ne peux pas aider quand la solution est juste d'aller sur cette page par exemple.
Le reste, ben c'est des complications que vous voulez, donc je vous laisse faire.
Ben la solution est assez évidente, donc je vois mal comment on peut discuter.
Désolé, trouver une solution complexe pour le plaisir de la complexité, je vous laisse le plaisir!
Je pointe juste l’hypocrisie des "raisons" invoquées.
Je suis simple utilisateur, j’indique juste que l'expérience utilisateur n'est pas des plus agréables.
Je ne pars pas pour autant (dommage?).
[^] # Re: Blabla
Posté par 2PetitsVerres . Évalué à 2.
Ou aller sur cette page par exemple. Bon je te l'accorde, il faut chercher le lien. Dans la dépêche.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Blabla
Posté par flagos . Évalué à 3. Dernière modification le 07 juin 2013 à 08:39.
10 Passer par un prestataire qui est reconnu par les navigateurs grand public ?
[^] # Re: Blabla
Posté par Anonyme . Évalué à 2.
C'est le 1.
[^] # Re: Blabla
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
En fait la solution pourrait être beaucoup plus simple. Il semblerait que l'IETF penche sur la possibilité de diffusé son certificat auto-signé via le serveur DNS (sécurisé avec DNSSEC) http://tools.ietf.org/html/draft-ietf-dane-protocol-08, il semblerait que Mozilla est en train de mettre en place ce fonctionnement dans son navigateur https://wiki.mozilla.org/Security/DNSSEC-TLS-details … Google avait mis un système similaire dans Chrome en 2011, j'ai testé avec la dernière version de Chrome ça ne fonctionne plus http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Blabla
Posté par Larry Cow . Évalué à 3.
On en parle un peu plus bas : https://linuxfr.org/news/certificat-ssl-tls-pour-serveur-web-https-et-problemes-associes#comment-1458456 ;)
C'est effectivement une piste très intéressante.
[^] # Re: La question qui manque
Posté par karteum59 . Évalué à 2.
J'aimerais bien comprendre justement : c'est CAcert qui ne veut pas être certifié ou c'est Mozilla qui ne veut pas certifier ? Qu'est-ce qui manque dans l'infrastructure ou les procédures de CAcert pour que ça puisse être certifié et ajouté chez Mozilla et Webkit/Chrome/Safari ? Est-ce que ça n'est qu'une histoire d'argent ? (auquel cas CAcert pourrait faire un appel à dons ou crowdfunding)
Autre question à propos de :
Pour moi, il s'agit d'un bug, non ? Est-ce que ça ne concerne que Firefox ou aussi d'autres navigateurs ? Est-ce que des bug-reports existent à ce sujet ? (apparemment ça n'a donc pas évolué depuis cette dépêche qui date de 2011 ?)
[^] # Re: La question qui manque
Posté par Aris Adamantiadis (site web personnel) . Évalué à 4.
Le bug existe: https://bugzilla.mozilla.org/show_bug.cgi?id=215243
TL;DR: Bug fermé comme invalide parce que la demande doit émaner du CA lui-même. CACert ne fait pas la demande car ils savent qu'ils ne respectent pas les conditions d'accès. Le bug n'a pas évolué depuis 2009 on dirait.
[^] # Re: La question qui manque
Posté par karteum59 . Évalué à 3.
OK, ça répond au point sur l'inclusion de CAcert (qui n'est pas un bug, c'est un choix)
Par contre, le comportement consistant à afficher une page blanche (plutôt que le dialogue pour ajouter le CA) dans le cas de HSTS est selon moi un bug (qui se présente avec tout certificat auto-signé, pas seulement avec cacert), d'où mes questions: est-ce spécifique à Mozilla ? (ça se comporte comment avec Chrome/Safari/IE ?)
# Et du HTTP intègral ?
Posté par azerttyu (site web personnel) . Évalué à 1.
Bonjour
Je ne remet pas en cause les choix de Cacert. Toutefois je ne peux me connecter en HTTPS car à chaque fois l’entité CA n'est jamais reconnue. De guère las je préfères me connecter en HTTP.
Du coup est ce qu'on pourrait avoir la possibilité d'avoir tout en HTTP aussi, dont les images ? C'est énervant à la longue de ne voir qu'une moitié de dépêche.
Ainsi https pour ceux qui veulent et une accès dégradé pleinement fonctionnel pour les autres. Je crois que cela fera des heureux :)
[^] # Re: Et du HTTP intègral ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
ça devrait toujours être le cas quand tu es en http (sinon c'est une erreur de celui qui a écrit ou édité/modéré, et que la technique n'a pas re-corrigé derrière).
[^] # Re: Et du HTTP intègral ?
Posté par azerttyu (site web personnel) . Évalué à 1.
Bonjour
Oups alors :) La page d'accueil de maintenant (delta de 5minutes) j'ai :
<img src="https://linuxfr.org/images/historique/sgl2013/IMG_20130528_091028-small.jpg" alt="CNIT" />
[^] # Re: Et du HTTP intègral ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Oui, erreur de celui qui a saisi une adresse https pour l'image (et qu'aucun système technique n'a recorrigé derrière). Corrigé, merci.
[^] # Re: Et du HTTP intègral ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
C'est dommage, parce qu'il vaut mieux être connecté en SSL avec une clef non certifiée qu'être connecté en clair pour transmettre un mot de passe. Une clef non certifiée est vulnérable aux attaques par interception — man in the middle — mais protège au moins des attaques par écoute simple et des introductions de nouveaux intercepteurs, contrairement à une connexion en clair qui ne protège de rien de tout ça.
[^] # Re: Et du HTTP intègral ?
Posté par Larry Cow . Évalué à 2.
Le souci, et ça avait largement été débattu à l'époque où la fonctionnalité avait été intégrée dans Firefox, c'est que les alertes en cas de "mauvais" certificat sont mal dimensionnées.
[^] # Re: Et du HTTP intègral ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Non, le souci c'est que les navigateurs, tous confondus, n'affichent aucun avertissement lorsqu'on transmet un mot de passe en clair, ce qui est bien pire que d'accéder à un site Web sécurisé par une clef non certifiée.
[^] # Re: Et du HTTP intègral ?
Posté par Ely . Évalué à 2.
Il te suffit d'intégrer le certificat racine CAcert à ton navigateur/ordinateur :
http://www.cacert.org/index.php?id=3
# Dernières nouvelles de HTTPS Everywhere
Posté par JGO . Évalué à 4.
J'utilise depuis un bon moment (actuellement en version 3.0.4), je n'ai pas de problème particulier sur linuxfr.
[^] # Re: Dernières nouvelles de HTTPS Everywhere
Posté par ariasuni . Évalué à 3.
Pareil, jamais eu de problèmes avec alors que je l’utilise depuis plusieurs mois.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Dernières nouvelles de HTTPS Everywhere
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Cool, une bonne nouvelle :)
[^] # Re: Dernières nouvelles de HTTPS Everywhere
Posté par Atem18 (site web personnel) . Évalué à 2.
Même chose ici. :)
# pinaillage
Posté par pipo_molo . Évalué à 4.
C'est juste un détail, mais TLS (ex SSL) est le protocole, et X.509 définit les certificats.
[^] # Re: pinaillage
Posté par Bernez . Évalué à 3.
En effet, on lit très souvent « certificat SSL », mais TLS peut aussi utiliser des certificats OpenPGP, et X.509 est utilisé par d'autres protocoles tels que S/MIME. Ces deux standards ont été définis totalement indépendamment.
[^] # Re: pinaillage
Posté par akh2020 . Évalué à 0. Dernière modification le 10 juin 2013 à 20:57.
D’ailleurs quitte à faire la validation à la main, ça ne serait pas mieux d’utiliser OPGP ?
Si on regarde avec en tête le problème de l'homme du milieu, on a :
* pour CACert, lorsque le certificat est proposé à l’ajout (parce qu’il n’est pas fourni avec la distribution), il peut y avoir une interception ;
* de même, lorsqu’on accéde la clé PGP pour l'ajouter à notre liste ;
* pour DANE (discuté plus bas), ça serait peut être plus compliqué, mais envisageable avec du DNS cache poisoning ou DNS spoofing.
Je me trompe peut être, mais j’ai l’impression que ces solutions restent donc vulnérable dans l'absolu.
[^] # Re: pinaillage
Posté par claudex . Évalué à 3.
Vu que DNSSEC lutte contre le DNS spoofing, je ne vois pas bien comment.
« 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: pinaillage
Posté par akh2020 . Évalué à 0.
Il me semblait que ça se résumait souvent (pour le spoofing) à une question de celui qui criait le plus fort ou le premier les annonces, donc il y a des cas où ça reste possible. OK, au moment où une relation est établi, ce ne sera plus possible (enfin peut-être avec un autre type d'attaque en parallèle). Mais si je rejoins un réseau avec une machine neuve (ou situation équivalente), la première fois que je reçois une réponse comment je peux faire la différence entre le bon et le mauvais DNS ? Dans ce cas, il y aurait forcément une préférence pour un DNSSEC par rapport à un DNS normal (surtout si la réponse de celui-ci est la première)? Est ce qu'un faux DNSSEC avec un vrai certificat pourrait faire illusion sur un réseau local ?
Il y a le mauvais dns, il écoute le réseau et quand il y a une demande de résolution, ben il répond. Pis il y a le bon dns, il écoute le réseau et quand il y a une demande de résolution, ben il répond, mais c'est pas la la même chose.
(ok je sors).
[^] # Re: pinaillage
Posté par claudex . Évalué à 3.
pour l'instant, c'est possible de spoofer parce qu'il existe trop de domaines non dnssec mais il est possible de vérifier au niveau hiérarchique plus élevé si le domaine est censé utilisé dnssec. Pour ton faux dnssec avec vrai certificat, je ne comprends pas ce que tu veux dire.
« 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
# Mort aux AC, vive DANE
Posté par ondex2 . Évalué à 5.
DANE semble être une solution séduisante. Plutôt que de faire un mauvais résumé : http://www.bortzmeyer.org/6698.html
[^] # Re: Mort aux AC, vive DANE
Posté par Larry Cow . Évalué à 4.
C'est effectivement très séduisant, et ça règle(ra) le plus gros du problème. Reste à attendre que les navigateurs l'implémentent (ce qui résoudra les soucis d'HTTPS), si quelqu'un a des pointeurs là-dessus d'ailleurs. Reste aussi apparemment à ce que les protocoles qui dépendent du DNS de manière plus complexe qu'HTTP (SMTP, XMPP, …) soient intégrés dans l'équation.
Et reste surtout à ce que DNSSEC décolle, et soit utilisable partout. Et là, j'avoue ne pas être au courant du tout de l'état des lieux. Si quelqu'un a des pointeurs, encore une fois…
[^] # Re: Mort aux AC, vive DANE
Posté par Gof (site web personnel) . Évalué à 1.
DNSSEC est biensur un énorme progrès. Mais est-ce que ça résout complètement le problème ?
On dépends en effet toujours d'une organisation de certification. Comment est-ce que google.ir ou google.cn peuvent faire confiance au DNS?
La solution est: Namecoin https://dot-bit.org/
[^] # Re: Mort aux AC, vive DANE
Posté par claudex . Évalué à 4.
Avec DNSSEC, tu ne dépends uniquement que de l'autorité de ton nom de domaine. Et si tu ne lui fait pas confiance, alors, il ne faut pas prendre un nom de domaine chez eux, ils peuvent faire pire que modifier le certificat.
« 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: Mort aux AC, vive DANE
Posté par Gof (site web personnel) . Évalué à 3.
Exactement. D'où ma proposition d'utiliser namecoin, comme ça on ne dépends plus d'aucun organisme ou autorité.
# Mise à jour le 7 juin...
Posté par shbrol . Évalué à 6.
… ah, chouette, une mise en prod le 'dredi ! Vivement demain !
[^] # Re: Mise à jour le 7 juin...
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
En l'occurrence elle est déjà faite :).
[^] # Re: Mise à jour le 7 juin...
Posté par shbrol . Évalué à 3.
Rhaa, c'est malin ça ! Faire la mise en prod du 'dredi le 'eudi, pour éviter le mauvais sort… bravo !
[^] # Re: Mise à jour le 7 juin...
Posté par Misc (site web personnel) . Évalué à 2.
En general, la mise en prod le vendredi, c'est surtout parce que tout le monde veut éviter de bosser le weekend. Soit c'est pas payé plus, et en tant qu'admin, ça te fait chier. Soit c'est plus cher, et ton patron veut éviter.
Dans le cas d'un site basé sur le bénévolat, la donne est différente, car tu doit te libérer du temps quelque soit la date. Le lundi n'a rien de différent du vendredi, car tu peux aussi bien avoir des obligations que tu peux pas répousser le lundi ( genre du travail, des occupations en dehors du dit travail ) que le vendredi ( genre du travail, depart en weekend etc ).
La règle "pas de mise en prod le vendredi" est mal énoncé, ça devrait être "pas de mise en prod le dernier jour ouvré de la semaine", ce qui montre bien que ça n'a pas vraiment de sens pour Linuxfr.
[^] # Re: Mise à jour le 7 juin...
Posté par claudex . Évalué à 9.
Et il y a plein de société qui font des mises en prod le vendredi soir pour avoir le temps de bien tester pendant le weekend avant que les utilisateurs y ait accès (même si les admins sont payés plus, ça coûte moins que 400 personnes qui ne peuvent pas bosser pendant une journée).
« 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: Mise à jour le 7 juin...
Posté par Anonyme . Évalué à -1.
Heu… La mise en prod, ça se fait pas quand tous les test ont été fait ?
[^] # Re: Mise à jour le 7 juin...
Posté par claudex . Évalué à 8.
Oui, c'est bien connu, il n'y a jamais de bug en prod, ils sont toujours détecté en pré-prod, les environnements de tests étant parfait et tous les use case étant testés.
« 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: Mise à jour le 7 juin...
Posté par Zenitram (site web personnel) . Évalué à 2.
Si lors d'un changement, tu plantes la machine (toute ressemblance avec un élément passé est fortuit), tu seras bien content d'aller sur place en jour ouvré.
Si, ça a du sens aussi pour LinuxFr, car LinuxFr n'est pas auto-hébergé ;-).
[^] # Re: Mise à jour le 7 juin...
Posté par Xavier Teyssier (site web personnel) . Évalué à 3.
Et les admins bénévoles ont probablement plus de temps le week-end pour aller en salle serveur qu'en semaine où ils sont au boulot. En fait, ça a du sens une mise en prod le vendredi ;-)
# https everywhere
Posté par Misc (site web personnel) . Évalué à 3.
sauf erreur de ma part, j'utilise le dit "https everywhere", et j'ai pas constaté de souci sur mon usage de linuxfr.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.