Après la grande discussion sur le certificat CACert de LinuxFR ayant eu lieu dans la dépêche Firefox 32, après l'entrée de suivi à ce sujet, pourquoi ne pas faire un sondage auprès des utilisateurs du site ?
-
Rester avec CACert en dépit des critiques :
277(12.6 %)
-
Opter pour Gandi (donc Comodo) comme l'April et l'AFUL :
488(22.2 %)
-
Un certificat auto-signé car je vous fais confiance :
277(12.6 %)
-
Un certificat GlobalSign gratuit (ceux réservés aux projets libres) :
257(11.7 %)
-
Un certificat Verisign car avec eux c'est du sérieux, ils ont des cravates ! :
61(2.8 %)
-
Yaka supprimer le HTTPS ! :
151(6.9 %)
-
De toute façon c'est foutu, la NSA a des ordinateurs quantiques. :
689(31.3 %)
Total : 2200 votes
# [X] Un vrai certificat reconnu par défaut par les navigateurs
Posté par JoeltheLion (site web personnel) . Évalué à 10.
Peu importe lequel. Si ça coûte quelque chose je veux bien contribuer.
[^] # Re: [X] Un vrai certificat reconnu par défaut par les navigateurs
Posté par CM63 . Évalué à 0. Dernière modification le 05 novembre 2014 à 11:51.
Désolé de répondre à ton post, JoelTheLion, je voulais répondre au sondage au niveau général, mais je n'ai pas trouvé où cocher.
Voici maintenant ma réponse:
Il aurait fallu ajouter une case "je ne comprends pas à quoi servent ces certifications", et j'aurais coché cette case.
Merci, à plus. :-)
[^] # Re: [X] Un vrai certificat reconnu par défaut par les navigateurs
Posté par CM63 . Évalué à -3.
Ah si, ca y est, j'ai trouvé.
# Et Français dans tout ca ?
Posté par Anonyme . Évalué à 6.
demander le soutien d'un AC certifiée française et se faire offrir un certificat.
[^] # Re: Et Français dans tout ca ?
Posté par 2PetitsVerres . Évalué à 1.
Tu veux probablement dire une AC certifiée francophone, car tout le monde sait que le .fr dans l'url est là pour francophone, pas pour français.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Et Français dans tout ca ?
Posté par CM63 . Évalué à 2.
AH bon? Les noms de domaine du Quebec et de la Belgique ne sont pas en .fr que je sache ?
[^] # Re: Et Français dans tout ca ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Il parlait du "Fr" dans LinuxFr.org (et donc il voulait dire Fr. et pas .fr je présume).
[^] # Re: Et Français dans tout ca ?
Posté par 2PetitsVerres . Évalué à 4.
Oui, désolé, j'ai rajouté inconsciemment un point, je voulais dire le "fr", et pas le ".fr". Du coup c'est un peu raté /o\
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Et Français dans tout ca ?
Posté par BAud (site web personnel) . Évalué à 3.
t'es bon pour garder ton .be ;-)
[^] # Re: Et Français dans tout ca ?
Posté par Anonyme . Évalué à 2.
Opentrust, certeurope, certinomis par exemple … Ce sont des ACs françaises pur jus !
[^] # Re: Et Français dans tout ca ?
Posté par Tonton Th (Mastodon) . Évalué à 4.
Tu confonds avec Usenet, où le fr. est là pour la francophonie (et un éléphant aigri). Et d'autre part, le .fr ne couvre pas la France entière, puisqu'il y a des tlds différents pour les dom-toms.
[^] # Re: Et Français dans tout ca ?
Posté par maboiteaspam . Évalué à 2.
arnaud montebourd sort de ce corps ? fais un effort au moins.
# auto signé
Posté par voxmundix . Évalué à -2.
Les organismes de certifications ne servent a rien a part enrichir les riches et faire c…. les autres (quand est-ce que Firefox va se décider a supprimer "l'avertissement de sécurité" qui est une insulte envers l'auto hebergement?)
[^] # Re: auto signé
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Il me semble préférable de passer par CAcert, qui :
[^] # Re: auto signé
Posté par Adrien . Évalué à 10.
CAcert est tellement bien que plein de gens le refuse, comme Debian assez récemment.
Ça veut dire quoi ? ils se plantent tous ? ou alors que CAcert pose de réel problèmes, non résolus ?
[^] # Re: auto signé
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Qu'aucune solution satisfaisante ne remplit les critères de tout le monde, alors chacun choisit son moins pire, suivant ses propres critères ? Ça peut être la simplicité (ce qui marche par défaut dans les navigateurs), la gratuité, l'indépendance, la sécurité, l'éthique, faire comme les autres, etc., sur toute la gamme allant du pragmatisme/court-termiste à l'idéalisme/utopisme.
[^] # Re: auto signé
Posté par Zenitram (site web personnel) . Évalué à 1.
Merci pour la bonne blague.
Tu sais très bien que c'est faux (pour s'en convaincre, il suffit de voir qu'ils n'osent même pas demander à des pro-libres de regarder chez eux).
Que tu n'aimes pas les autorités "classiques", soit, mais j'avoue avoir du mal à comprendre pourquoi tu as besoin de mentir (oui, à partir du moment où on t'a déjà démontré 10x que c'est faux, ça devient du mensone) aux gens pour "vendre" ce que tu aimes subjectivement.
A part quelques perdus, qui de sérieux reconnait cette autorité? Ils ont même fini chez Debian (qui est quand même rempli de personnes bien libristes) à virer la chose tellement ça craint…
A la place de continuer à militer pour un cadavre (c'est mort! Arrêtez avec CACert, ça fait des années qu'on nous dit "tu vas voir, ça va aller mieux bientôt". Changez le nom aussi, parce que la réputation de CACert pour ceux qui connaissent est plutôt dans la section humour), si vous vous bougiez pour proposer un CA crédible pour prouver qu'on peut mieux faire que les CA que vous critiquez?
PS : et comme l'a dit déjà le premier commentaire, mais il faut insister : on s'en fout complet du CA retenu, l'important est qu'il soit valide (=reconnu par 99% des navigateurs), le problèmes est toujours (je sias je me répète) militez pour inciter les gens à ne pas faire attention aux avertissements de sécurités. Si vous avez un CA communautaire crédible, ça ira aussi. Non, CACert ne rempli pas un critère important (la crédibilité).
[^] # Re: auto signé
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Euh, j'étais sérieux là. Autorité de certification commerciale : il faut fournir quelque chose comme un de relevé de compte en banque (un truc que n'importe qui peut falsifier) et une adresse électronique et un numéro de téléphone où être rappelé. Aucun contact direct. CAcert : il faut rencontrer en personne trois ou quatre accréditeurs CAcert qui vérifieront tes papiers d'identité et la correspondance de la photo avec ton visage.
Là, je n'ai pas compris.
[^] # Re: auto signé
Posté par Zenitram (site web personnel) . Évalué à -5. Dernière modification le 06 novembre 2014 à 10:20.
C'est ce qui en fait la chose rigolote.
Non : juste une adresse mail en fait pour les plus faciles. Ce n'est pas le problème principal (ce n'est pas le maillon faible de la chaine).
Oui, alors la porte est blindé, mais la fenêtre est ouverte 1 mètre plus loin. C'est beau la sécurité!
Le problème de CACert n'est pas de vérifier l'identité, c'est tout ce qu'il y a après (qu'ils ont l'air d'avoir oublié…), CACert c'est la porte blindée avec les fenêtre ouvertes, je te parle des fenêtres ouvertes et tu me réponds que tu ne vois pas le problème car la porte est blindée, et tu ne comprends pas qu'on en rigole de ta réponse. Bravo!
Sérieusement, tu n'es pas au courant que CACert n'ose même pas demander à entités les plus libristes (allez, au pif : Debian, Mozilla, des "petits cons" qu'il ne faudrait pas croire quand ils pensent ne pas pouvoir faire confiance) de vérifier si CACert est digne de confiance?
toi, tu dis que si je te dis que je peux être de confiance, tu me crois, comme ça, automatiquement. C'est ta façon de faire avec CACert, aimer une façon de faire enlève toute notion de sécurité.
Je serai je crois toujours impressionné par la façon dont les gens suppriment des problèmes dans leur tête du moment où ce dont ils parlent leur palit trop bien trop dans leur idées. Bravo!
La sécurité, c'est une chaine de confiance. J'avoue ne pas comprendre comment on peut "oublier" ça. CACert c'est la pire des choses : accepté par quasi personne comme chaine dde confiance, mais des gens arrivent à militer quand même pour, tant pis si en pratique ils militent pour que les gens ignorent des avertissement de sécurité. Ou comment dire qu'on veut de la sécurité en agissant pour que le contraire arrive, digne de politiciens de base.
[^] # Re: auto signé
Posté par patrick_g (site web personnel) . Évalué à 8.
Tu as déjà oublié la discussion sur la news Firefox 32 on dirait.
Allez je te recolle le lien qui avait été donné : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434#239
Et mon commentaire à ce sujet : https://linuxfr.org/nodes/103173/comments/1559748
[^] # Re: auto signé
Posté par Zenitram (site web personnel) . Évalué à -7. Dernière modification le 06 novembre 2014 à 11:06.
Tiens ça revient le coup du "Qui veut noyer son chien l'accuse de la rage", ça faisait longtemps…
(non, je n'ai pas oublié, juste que c'est trouver des excuses, accuser les autres, quand on n'est pas capable de faire, ni capable de proposer mieux en pratique, et que ça ne convainc que ceux qui veulent être convaincus. bizarrement les gens qui s'interessent à la sécurité des distros/navigateurs n'ont pas été convaincus par ces "arguments", mais on nous demande de l'être)
PS : mais pourquoi donc cette "haine" des CA classiques supprime toute notion de sécurité aux gens? Mystère… Et c'est dommage, car du coup impossible de trouver une "meilleure" solution au problème, et on reste avec le problème sur le bras (bon, des gens plus sérieux ont posé DANE, espérons que ça prenne).
[^] # Re: auto signé
Posté par Thomas Debesse (site web personnel) . Évalué à 6. Dernière modification le 07 novembre 2014 à 18:08.
Le chien c’est CaCert et celui qui accuse de la rage c’est Zenitram ? Ou alors j’ai pas compris ?
Bon bref, mis à part le blabla général qu’on peut attribuer à tout le monde…
Donc Tanguy te donne un argument précis, et toi tu le réfutes avec une analogie.
On ne pourra juger de la recevabilité de ton analogie que si et seulement si tu décris la chose réelle qui est comparée.
Dans l’analogie « porte et fenêtre », Tanguy a défini la vérification d’identitée comme « la porte blindée », maintenant il faut que tu définisses « la fenêtre ouverte ». Sinon c’est du FUD.
Note que je n’y connais rien à CACert, tout ce que je sais c’est qu’en lisant cette discussion je vois un gros FUDeur sans argument, toi.
Ma seule expérience des CA est d’avoir déjà réussi à obtenir un certificat avec identité vérifiée (pas un EV) alors qu’il me manquait les documents d’identité que le CA me demandait. D’après ce que dis Tanguy je n’aurais toujours pas mon certificat aujourd’hui. Ce qui est un bon point pour CACert. Le fait que FireFox distribue comme autorité le CA qui m’a certifié est une énorme fenêtre ouverte.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: auto signé
Posté par LeMagicien Garcimore . Évalué à 2.
Sauf qu'en fait, tu n'as pas besoin de rencontrer qui que ce soit pour obtenir un certificat CAcert. La seule contrainte c'est qu'il expire au bout de 6 mois.
http://wiki.cacert.org/FAQ/Privileges
[^] # Re: auto signé
Posté par Tonton Benoit . Évalué à 3. Dernière modification le 07 novembre 2014 à 22:27.
Y'a une vérification au niveau du domaine, et c’est pareil chez les CA commerciale pour l'entrée de gamme/gratuit.
Je vient d'obtenir un wildcard valide 5 ans chez GlobalSign dans les mêmes conditions.
Un certificat permet déjà de chiffrer les communications avec le serveur, après faut voir ce qu'il certifie, exemple pour LinuxFr :
Nom commun (CN): linuxfr.org
Organisation (O): Ne fait pas partie du certificat
Unité d'organisation (OU): Ne fait pas partie du certificat
Ça veut dire que tu communique bien avec le serveur qui, à la date de création du certificat, répondait quand on contacte le domaine linuxfr.org.
Aucune info certifiée sur quelle organisation est derrière.
Il faut aussi voir l'assurance, c’est surtout utile pour les sites de paiement, mais la CA garantie un certain dédommagement en cas d'erreur de leur part (oups j'ai donné un certificat pour paypal.com à EscrocRusse Inc) ça va de quelques milliers d'euros à plusieurs millions de garantie suivant la CA et le niveau du certificat.
[^] # Re: auto signé
Posté par LeMagicien Garcimore . Évalué à 3.
Absolument, je nuançait un peu la remarque de Tangy et Thomas qui avaient l'air de penser que grâce a CAcert on avait un meilleur "niveau de certification" que les CA classiques. Ce qui est faux.
[^] # Re: auto signé
Posté par Thomas Debesse (site web personnel) . Évalué à 9.
Attention, j’ai bien précisé que je n’y connaissait rien à CACert, mais que dans le débat Tanguy vs. Zenitram le premier sort des arguments qui me convainquent, et que le second ne fait que du FUD. La position de Zenitram est peut-être la vraie, mais il ne la défend pas avec des arguments rationnels.
Je renchéris seulement avec une expérience personnelle avec un CA qui n’est pas CACert et qui selon Tanguy, fait moins bien que CACert sur le point précis que Tanguy évoque. Mon expérience confirme sur ce point là que le CA auquel j’ai du traité fait moins bien que ce que dit Tanguy de CACert, sur ce point.
Par contre je ne peux pas confronter mon expérience avec ce que dit Zenitram de CACert. En fait Zenitram ne dit pas grand chose de CACert sinon que de dire que c’est moins bien, mais il ne dit pas vraiment pourquoi… Si vraiment c’est si facile de démontrer que CACert a des fenêtres grandes ouvertes, on doit pouvoir me les montrer.
Peut-être que Tanguy se trompe ou même ment, j’en sais rien, mais ce qu’il dit ressemble à quelque chose d’assez sérieux à coté du FUD très très grossier de Zenitram. Le diable a peut-être le plus mauvais avocat…
Ce qui est sûr pour moi, c’est que Firefox distribue une autorité que je connais pour avoir pu outrepasser ses exigences. Je ne me suis d’ailleurs tournée vers elle que parce que je voulais un certificat reconnu par Firefox et autres grands de ce monde, ce qui forme une espèce de racket, je ne me suis pas tourné vers ce CA parce qu’il était fiable, mais parce que Firefox le déclare comme fiable.
Si un jour Firefox déclare fiable ToToCert alors que ce n’est pas complètement vrai mais vois-tu, il-est-gros-je-peux-pas-couper-mes-clients-de-ses-services, ToToCert verra son chiffre d’affaire augmenter grâce à ce parrain. C’est juste une mafia avec des parrains et des trop gros pour mourir (et l’incapacité de former un certificat signé par deux CA est une des plus grosses garanties de survie cette mafia).
En ce moment Firefox (et Chrome et Opera etc.) est dans une logique de « allez chez ToToCert c’est pas cher et on fermera les yeux sur la validité de vos certificats ».
Je sais juste qu’il n’y a pas besoin d’aller chez CACert pour avoir des procédures de certifications non respectées, mais que Firefox, Microsoft et Google ferment déjà les yeux sur ce problème, alors rien ne me prouve qu’ils ne ferment pas les yeux sur les autres problèmes, même ceux que reproche Zenitram à CACert.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: auto signé
Posté par Zenitram (site web personnel) . Évalué à -6. Dernière modification le 08 novembre 2014 à 09:13.
Ils te convainquent que parce que tu veux l'être. Parce que bon, j'ai du mal à comprendre comment CACert peut convaince de la moindre sécurité vu la façon dont ils ne veulent pas qu'on regarde trop chez eux.
Zenitram dit que :
- Il y a déjà eu plein de discussion dessus, si tu t'interesses tu verrais.
- Saloperie de gens qui connaissent la sécurité, eux, et ne font pas confiance. Oui, je fais confiance à des gnes qui ont montré qu'ils connaissent la sécurité. Désolé de faire plus confiance à Mozilla qui risque sa réputation qu'à Tanguy qui ne risque absolument rien. Toi, tu fais confiance au premier inconnu qui te demande ton portefeuille "comme ça", parce qu'il n'est pas connu de ta part.
Chacun sa vision de la sécurité sans doute…
Quand aux critiques sur la sécurité des trucs utilisé, c'est toujours le problème des trucs utilisé, les gens essayent e casser ces sécurités. C'est sûr que l'avantage de CACert est que comme personne n'utilise, personne ne s'interesse à tester leur sécu.
Tiens, ça me rappelle les gens assez idiots pour balancer que les virus sous Linux n'existent pas et que c'est mieux que sur Windows, juste parce qu'en fait les virus sont développés pour… L'OS utilisé (la faille de sécurité étant l'interface chaise-clavier, il suffit de réfléchir 5 secondes pour savoir que le seul avantage de Linux est de ne pas être utilisé sur le desktop, quel avantage! Ici, pareil, on dit que CACert est bien comme ça, sans démonstration technique, sans oser demander un audit indépendant…)
Mais bon, Les CA classiques sont des méchants, CACert est le sauveur, on s'en fout que ce soit viable ou pas, ce n'est pas l'idée des gens qui veulent juste cracher sur les CA classiques. C'est dommage, mais bon, heureusement à part LinuxFr comme "gros site" personne d'autre ne tombe dans un tel dogme qui enlève toute notion de sécurité aux défenseurs.
[^] # Re: auto signé
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
Mais je m'en balance de CACert ! Je n'ai pas besoin d’être convaincu, je n'ai aucun intérêt dans CACert. Si je n'avais pas à ajouter manuellement le certificat de DLFP à mon navigateur je n'aurai jamais entendu d’eux dans ma vie (tout comme je ne connaissais pas Commodo avant de lire ce sondage, wouhou).
Super, depuis le début t’es incapable de sortir le moindre argument dans cette conversation autre que « mon grand-frère m’a dit ».
Sérieux, relis cette discussion, regarde qui n’oppose aucun argument recevable ! T’as peut-être raison, mais tu ne le montres pas du tout. Franchement, CACert m’en touche une sans faire bouger l’autre, mais si tu penses qu’il en va de la sécurité et du bien commun de pointer les défauts de CACert, alors fais-le, évite de te planquer derrière le « mon grand-frère m’a dit ». Si c’est si facile, tu n’aurais aucun problème à ne pas botter en touche comme tu ne cesses de le faire ici.
Ou alors si vraiment c’est si facile de trouver des argumentaires qui dénoncent le manque de fiabilité de CACert, t’es juste un trolleur chaud dans son fauteuil qui a le temps pour pondre pavés sur pavés mais pas le temps pour lire et recopier un tel argumentaire qui serait au coin de la page ?
Avec le temps que t’as passé à pondre des commentaires à rallonge, si c’était si facile de trouver un argumentaire convaincant et que tu ne l’as toujours pas rapporté ici, c’est que tu perds vraiment ton temps parce que ça ferait longtemps que tu aurais pu démonter tous tes opposants. Ou alors tu aimes juste t’épancher à longueur de post et que montrer une fois pour toute que tu as raison t’empêcherai de troller, donc tu ne le fais pas.
Franchement, relis cette discussion d’un regard extérieur, tes commentaires affolent le FUDomètre.
Avec de si mauvaises accusations en forme de « mon grand frère m’a dit », CACert semble n’avoir rien à craindre.
T’es le meilleur défenseur de CACert dans cette discussion, car tu es celui qui réduit les détracteurs de CACert à des FUDeurs-trolleurs à ignorer.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: auto signé
Posté par patrick_g (site web personnel) . Évalué à 10.
Moi ce qui me stupéfie dans cette discussion c'est le fait que Zenitram n'évoque à aucun moment le lien, donné dans la news Firefox 32, que j'ai recollé plus haut.
On dirait qu'il ignore délibérément ce lien parce qu'il ne cadre pas avec ce qu'il pense.
Pourtant c'est de l'or en barre ce lien !! On a là un retour d'expérience de la part du mec qui a fait les audits de CAcert !! Qu'est ce qui pourrait être mieux que ça pour nourrir avec des faits les échanges que nous avons entre nous ?
[^] # Re: auto signé
Posté par Zylabon . Évalué à 5.
Donc ils font une vérification sérieuse ?
Donc ils ne font pas de vérification sérieuse ?
Si tu veux réfuter une idée et qu'on te prenne au sérieux, n'introduit pas d'incohérence dans ton argumentaire.
Please do not feed the trolls
[^] # Re: auto signé
Posté par Anonyme . Évalué à 7.
C'est valable pour beaucoup de certificats SSL
Les certificats du type DV (Domain Validated) tout automatique avec la procédure que tu as indiqué mais , dès que tu demandes des certificats du type OV (Organisation validated) alors la les choses se compliquent avec justification juridique de l'organisation.
Ensuite les certificats EV, pareil, les contrôles sont plus fins, requête OCSP a chaque connexion sur le site … c'est pas mal.
Ensuite les certificats avec des niveau de RGS, et, il me semble, que c'est qu'a partir du 2* que la remise en face a face a lieu. Les contrôles sont a chaque niveau de plus en plus fins et forcement les coûts de délivrance sont de plus en plus élevés, mais des assurances sont liées :-)
Tout ca étant reconnu dans les navigateurs web bien entendu !
Alors, ce n'est pas parce que c'est commercial que c'est mal, faut bien payer les gens qui font les contrôles et ca prends beaucoup de temps.
[^] # Re: auto signé
Posté par maboiteaspam . Évalué à -2.
c'est tellement vrai.
mais ce n'est pas prêt d'arriver. Ce genre de protection est un moyen de faire patte blanche vis-à-vis des mainstreameux à la tête de DSI qui doivent faire des choix aux noms des autres.
Par contre ce serait sympa d'avoir une option.
[^] # Re: auto signé
Posté par voxmundix . Évalué à -1.
Si c'est gratuit, why not. Mais si c'est payant, c'est un peu con de dépenser de précieux euro pour un service tiers tellement décrié dans les précédents articles.
Toute façon les utilisateurs de linuxfr ne fuiront pas en voyant "une alerte de sécurité firefox".
PS: si quelqu'un sait comment désactiver cette alerte, je suis preneur
[^] # Re: auto signé
Posté par patrick_g (site web personnel) . Évalué à 5.
https://linuxfr.org/aide#aide-certificatssl
[^] # Re: auto signé
Posté par voxmundix . Évalué à -2.
Ma question était plus tôt: comment supprimer TOUTES les alertes de sécurité de certificat sur firefox?
mais merci quand même ;)
[^] # Re: auto signé
Posté par Reihar . Évalué à -2.
Avec une extension Firefox (lien de téléchargement).
[^] # Re: auto signé
Posté par voxmundix . Évalué à 0.
merci bien ;)
[^] # Re: auto signé
Posté par xcomcmdr . Évalué à 10.
Sympa : l'extension qui automatise une mauvaise habitude de sécurité.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: auto signé
Posté par voxmundix . Évalué à 3.
L'erreur de sécurité c'est de crier au loups inutilement. Une alerte légitime c'est un changement de certificat (et encore, comment l'utilisateur peut savoir si c'est légitime ou non? En vérifiant les valeurs bidons qu'on a rentré lors de la création? :D ).
Toute façon tu crois franchement qu'un nouvel utilisateur comprends quoi que se soit quand il tombe sur une alerte de sécurité sur un service auto-hébergé? Non il accepte le certificat après avoir cru que les services sont inaccessible et avoir harcelé le webmaster…
Je trouve aberrant qu'on fasse de la FUD en faisant peur aux gens dés qu'ils visitent un certificat auto-hébergé alors que les certificats certifié sont sous le jouc des gouvernements qui forme la menace principale sur internet…
[^] # Re: auto signé
Posté par NumOpen . Évalué à 2.
http://patrol.psyced.org/
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: auto signé
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Il n'y a pas (plus) de messages privés sur le site web LinuxFr.org. Et une des raisons est qu'il est compliqué techniquement et pratiquement d'avoir une solution de messages privés chiffrés non accessibles aux admins (à l'ère post-Snowden, on voulait éviter ce point).
[^] # Re: auto signé
Posté par octane . Évalué à 2.
Il y a zerobin pour ce genre de choses, non?
http://sebsauvage.net/wiki/doku.php?id=php:zerobin
[^] # Re: auto signé
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Alice et Bob ont chacun un compte sur LinuxFr.org. Alice veut envoyer "kikou LOL MDR!" à Bob. Alice utilise un zerobin-like (géré par LinuxFr.org ou ailleurs, on verra plus tard ça) et va obtenir une URL identifier#key correspondant à son message. Il suffirait maintenant que Bob ait cette URL, mais Alice ne sait pas comment lui transmettre. Si cette URL est connue des admins de LinuxFr.org, alors ils peuvent lire le message.
Dans un monde sans spam et sans relou', Bob publierait un moyen de contact (visible uniquement des comptes authentifiés au besoin) et Alice l'utiliserait (et le contenu ne passerait pas par LinuxFr.org).
[^] # Re: auto signé
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Ce qui est une insulte, ce n'est pas l'avertissement, qui est légitime (rien de garantit qu'il n'y a pas un attaquant en réécriture sur la ligne), mais la hiérarchie des avertissements :
[^] # Re: auto signé
Posté par ɹǝɓuᴉɹǝɐH ʅǝnuɐɯɯƎ-sᴉxǝʅⱯ . Évalué à 3.
La hiérarchie des avertissements, c'est une très judicieuse remarque.
Idéalement, je verrais la refonte de l'indicateur du niveau de "confiance" d'un site plus fin selon les détails indiqués, associé à un deuxième niveau confiance qui lui serait décentralisé, tel que gpg.
Au pays de Candy, j'imaginerais un indicateur qui serait à 99% positif lorsque le site :
- est certifié par une Autorité de Confiance "approuvée" (avec une CRL "à jour")
- est indiqué que la signature "est approuvée" par son réseau de confiance
- a été visité au moins x fois
- etc. voir plus encore soyons fou !
Mais peut-être qu'une bonne question serait de se demander si Mozilla serait assez indépendant pour oser braver cette juteuse pyramidale coterie des Autorité de Confiance ?
[^] # Re: auto signé
Posté par voxmundix . Évalué à -4.
On peut aussi simplement se poser la question de l'utilité réelle des certificats, surtout sachant qu'il a déjà été démontré qu'on peut créer des faux: https://en.wikipedia.org/wiki/Collision_attack
SSL devrait se contenter de faire se qu'il sait faire: chiffrer.
[^] # Re: auto signé
Posté par matp75 . Évalué à 5.
à quoi ca sert de chiffrer si tu ne sait pas avec qui ?
Tu discutes peut etre avec un attaquant au milieu de ta conversation qui déchiffre puis rechiffre…
La vrai problématique est de savoir comment distribuer des certificats de manière dite "sécurisée" et comment palier les déficiences et risques du mode autorités de certifications actuels (d'ou par exemple les evolutions actuelles vers du pinning par exemple)
[^] # Re: auto signé
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
À se prémunir des attaques par simple écoute passive, même si c'est vulnérable aux attaques par réécriture active, en effet.
Par ailleurs, si cela ne permet pas de détecter les attaquants actifs présents depuis le début de la session, cela rend détectable l'introduction d'un nouvel attaquant actif en cours de session.
Bref, c'est mieux que de communiquer en clair, et moins bien que de communiquer en chiffré avec une vraie vérification du propriétaire de la clef publique.
[^] # Re: auto signé
Posté par gouttegd . Évalué à 4.
À ma connaissance, les seuls cas avérés de certificats falsifiés étaient des certicats utilisant un condensat MD5.
Ce n’est pas parce que les autorités de certification font n’importe quoi — comme continuer à utiliser un algorithme longtemps après que sa résistance a été mise en doute — qu’il faut jeter le bébé avec l’eau du bain. Ce ne sont pas les certificats X.509 le problème, mais la manière de valider leur authenticité.
Sans authentification (ou avec une fausse promesse d’authentification comme celle apportée par les autorités de certification), ça ne sert à rien contre les attaquants actifs — ça protège contre Eve, pas contre Mallory.
[^] # Re: auto signé
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Oh que non, il y a aussi eu des cas d'autorités de certification qui ont émis des certificat pour des noms de domaines données à l'intention de gens qui n'en étaient pas du tout propriétaires.
La plus belle preuve que les autorités de certification ont fait n'importe quoi, c'est qu'elles ont introduit de nouveaux certificats avec Extended Validation qui veulent dire que là, c'est sérieusement vérifié. Autrement dit, que sans EV, c'est vérifié n'importe comment.
Si. Les certificats X.509 ne pouvant porter qu'une seule signature d'autorité, ce qui encourage le maintien d'un oligopole très restreint d'autorités de certification (on ne peut pas raisonnablement prendre un certificat signé par un petit nouveau, qui ne sera pas reconnu partout, et on ne peut pas prendre un certificat signé à la fois par un petit nouveau et par un acteur établi puisque le format de certificats ne le permet pas).
À son tour, la grande importance des acteurs majeurs de cette coterie empêche leur retrait en cas de problème (too big to fail: même si VeriSign émet, disons, des certificats pour la NSA portant sur des noms de domaines qu'elle ne possède pas, on ne peut pas retirer VeriSign des navigateurs sinon le Web commercial cesse en pratique de fonctionner). Compte tenu de cela, les autorités de certification, qui ne sont pas payées à la vérification mais à la certification et qui n'ont aucun intérêt à effectuer des vérifications trop poussées (au risque de refuser des clients !), mais au contraire tout intérêt à accepter à peu près n'importe quel client sans se montrer trop exigeantes, n'ont pas grand chose qui les retiennent de maintenir un niveau de vérification très bas.
Et oui, tous ces problèmes sont en grande partie des conséquences du format technique X.509.
[^] # Re: auto signé
Posté par BAud (site web personnel) . Évalué à 3.
coterie : très bien trouvé comme terme, j'essaierai de le replacer ;-)
[^] # Re: auto signé
Posté par gouttegd . Évalué à 4.
Je me suis peut-être mal exprimé, par « certificats falsifiés » je voulais parler, pour répondre à voxmundix, de certificats générés avec une fausse signature, rendue permise par une collision sur l’algorithme de condensation.
Je n’incluais pas dans ce lot les certificats avec une signature authentique (réellement apposée par l’autorité de certification) mais émise à mauvais escient (par une AC malhonnête ou piratée).
[^] # Re: auto signé
Posté par Ely . Évalué à 3.
Parce que si tu supprimes cet avertissement, tu autorises n'importe quel attaquant à faire ce qu'il veut du réseau puisqu'il peut se faire passer pour un site légitime avec un certificat auto-signé.
Il y a une chose qu'il ne faut pas oublier avec la cryptographie moderne, c'est qu'au bout de la chaîne, il y a toujours un (ou plusieurs) humain(s) à qui il faut faire confiance.
La cryptographie ne répond pas à la problématique "comment faire pour que ce contenu soit honnête et vrai", mais plutôt "comment prouver que ce contenu provienne bien de la bonne personne (à qui je fais confiance) et n'ait pas été corrompu au passage".
Du coup, autant essayer de réglementer et d'encadrer le plus possible ces humains => et là sont nées les autorités de certification. Alors c'est loin d'être parfait - là-dessus on est tous d'accord -, mais il n'y a pas non plus de solution miracle pour ce problème.
[^] # Re: auto signé
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
N'importe quel attaquant capable de réécrire à la volée ton trafic réseau. Ça limite quand même un peu.
[^] # Re: auto signé
Posté par Ely . Évalué à 6.
Soit tous les FAI, les hébergeurs, les noeuds, les admins des réseaux des entreprises, les responsables de serveur DNS qui peuvent te rediriger sur tout et n'importe quoi, les services de proxy et de vpn [..]
[^] # Re: auto signé
Posté par voxmundix . Évalué à 1.
Faire confiance a tout ces gens là c'est pas malin ^ (suffit de taper The Pirat Bay pour voir quelle confiance on peut accorder a des gens dépendant du bon vouloir gouvernementale)
Mais si non pour en revenir au certificat, sachant que tu as quand même une alerte dés que tu tombe sur n'importe quel certif auto-signé, l'alerte perd sa valeur. (un peu comme un antivirus trop bavard qui va pousser l'utilisateur a choisir "accepter par défaut" voir "pire" a désinstaller l'antivirus).
[^] # Re: auto signé
Posté par Tonton Th (Mastodon) . Évalué à 6.
J'espère bien jamais, et j'aimerais bien aussi que le choix par défaut soit « cette session uniquement ».
[^] # Re: auto signé
Posté par voxmundix . Évalué à 2.
Comment fais-tu dans ces conditions pour savoir quand tu es face a un MITM? (c'est une question pas un troll :) )
[^] # Re: auto signé
Posté par Zylabon . Évalué à 3. Dernière modification le 05 novembre 2014 à 17:39.
Parce que pour vérifier l'empreinte d'une clé il faut faire confiance à une entreprise que quelqu'un à payer pour ça. Tu peux pas le faire toi même. Trop compliqué. Trop long. Et ça suppose de comprendre comment ça marche. Et pourquoi faire quelque chose gratuitement quand quelqu'un a payer quelqu'un d'autre pour le faire à ta place ?
Please do not feed the trolls
[^] # Re: auto signé
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Pas du tout. Une autorité de certification n'est pas payée pour vérifier quoi que ce soit, elle est payée par ces clients pour leur fournir un certificat signé. La vérification, ce n'est pas la prestation qu'elles vendent, mais simplement un devoir déontologique, qui a l'inconvénient d'être opposé à leur intérêt financier. Plus une autorité de certification vérifie, plus elle refuse de clients, et moins elle gagne d'argent.
[^] # Re: auto signé
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
Ce qui est complètement con. Parce que tu ne sauras pas la prochaine fois si le certificat que tu as accepté la première fois est toujours le même, et donc si tu es potentiellement victime ou pas d'un MITM.
[^] # Re: auto signé
Posté par rakoo (site web personnel) . Évalué à 4.
A une époque j'utilisais Certificate Patrol, qui si mes souvenirs sont bons te disaient si le certificat pour un même hostname changeait. C'est considéré comme une mauvaise pratique, mais a la longue il y a du y avoir peut-être 1 site sur 100 qui faisait les choses correctement, pour tous les autres j'ai du accepter a la mano chaque certificat a chaque fois qu'il changeait…
Au final j'ai vite compris que l’authenticité offerte par le système est inutile si tu vérifies pas correctement (ce que le navigateur ne fait pas par défaut), et vue que je me retrouvais a tout accepter sans regarder, autant ne plus faire confiance a personne.
[^] # Re: auto signé
Posté par voxmundix . Évalué à 2.
N'y a-t-il pas moyen de faire un petit script qui passerait par le Web normal et ensuite par Tor (pour les sites accessible via hidden service donc sans sortir du réseau Tor) puis comparer les deux certificats pour vérifier l'authenticité? Ce système pourrait-être plus robuste et ne pas nécessité de tiers.
[^] # Re: auto signé
Posté par claudex . Évalué à 3.
Justement, je préfère avoir l'alerte à chaque, ça me rappelle que je n'ai pas vérifié ça, pour ceux auxquelles je transmets vraiment des informations (mots de passe, adresses mails), je fais la vérification et à ce moment là, je coche la case.
« 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
# i2p
Posté par alpha_one_x86 (site web personnel) . Évalué à 2.
Et pourquoi pas i2p? Avec le cryptage de bout en bout…?
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: i2p
Posté par dinomasque . Évalué à 2.
Et pourquoi pas avec du détergeant pendant qu'on y est ?
BeOS le faisait il y a 20 ans !
# À propos d'X.509
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
À propos, pour ceux que ça intéresse, j'en profite pour mentionner cet article à propos des conséquences « sociales » du modèle technique X.509. En deux mots, ce que j'en retiens, c'est que la conception technique d'X.509 encourage : 1. une centralisation oligopolistique, dont l'équilibre serait même un monopole ; 2. que ses acteurs principaux, les autorités de certification, fassent mal leur travail.
# PKIX + DANE + Monkeysphere
Posté par gouttegd . Évalué à 10. Dernière modification le 05 novembre 2014 à 12:19.
Je propose un certificat :
signé par une autorité de certification quelconque (CAcert ou une autre, peu importe, le problème des CA vient du système même des CA, non d’une CA particulière) ;
publié dans le DNS via un enregistrement TLSA ;
transformé en clef publique OpenPGP signée par un administrateur du site et publiée sur un serveur de clefs OpenPGP.
Comme ça tout le monde est content :
ceux qui se contentent de PKIX et de ses faiblesses inhérentes ;
ceux qui ont un résolveur DNS validant et un navigateur qui connaît DANE ;
ceux qui connaissent directement l’administrateur du site, ou qui ont un chemin vers lui dans leur réseau de confiance OpenPGP.
[^] # Re: PKIX + DANE + Monkeysphere
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Oui, c'est ma solution préférée aussi (mais ça fait plus d'adminsys pour l'équipe de site). Bon ensuite les gens râleront quand même parce que n'importe quelle CA pourra toujours sortir un faux certificat, que DANE n'est pas utilisable réellement avec des navigateurs courants (pas sur Chrome, et sur Firefox uniquement avec plugin sauf erreur, et rien pour les autres) et que pas grand monde n'a encore accès au réseau de confiance OpenPGP comprenant les admins LinuxFr.org :).
[^] # Re: PKIX + DANE + Monkeysphere
Posté par briaeros007 . Évalué à 4.
C'est l'histoire de l'oeuf ou de la poule.
Si personne ne fait l'effort de mettre du DANE, il ne sera jamais implémenté dans les différents navigateurs.
C'est une solution correcte , si on est prêt à accepter que DNSSEC soit suffisant pour ce type de travail (et perso je le pense. C'est mieux penser que les pki et leurs contributions d'attributions de CA secondaire obscure).
[^] # Re: PKIX + DANE + Monkeysphere
Posté par gouttegd . Évalué à 8.
Je profite de ce thread pour présenter une manière de valider les certificats que j’aimerais voir dans les navigateurs (et que j’ai déjà
implémentébidouillé dans mon Uzbl).L’idée maîtresse est de permettre de vérifier un certificat par toute une série de mécanismes distincts — au lieu de se reposer uniquement sur le système PKIX comme actuellement — et de prendre la décision finale d’accepter le certificat (et donc d’afficher la page) ou de le rejeter (et de présenter un message d’erreur) en fonction du résultat combiné de tous les mécanismes.
Le principe consiste en une sorte de « pipeline de validateurs », où chaque validateur teste à tour de rôle le certificat présenté par le serveur et renvoie un score négatif pour un certificat invalide, un score positif pour un certificat valide, ou un score nul si la validation est impossible (le validateur ne peut pas se prononcer sur ce certificat). À la sortie du pipeline, le certificat est accepté si le score final est positif, rejeté si le score est négatif. Si le score est nul, la décision revient à l’utilisateur, à qui un message présente les résultats de chaque validateur.
Les validateurs possibles incluent (liste non exhaustive, justement un des buts de cette approche est de pouvoir ajouter de nouveaux mécanismes de validation sans tout chambouler) :
un validateur PKIX, comme ce qui existe déjà dans tous les navigateurs (renvoie 1 si le certificat est correct et signé — directement ou non — par une autorité de certification qui a la confiance de l’utilisateur, -1 si le certificat n’est pas correct, ou 0 si l’autorité de certification n’est pas connue) ;
un validateur DANE (renvoie 1 si le certificat correspond à au moins un enregistrement TLSA, 0 s’il n’y a pas d’enregistrements TLSA, -1 s’il y a des enregistrements TLSA et que le certificat du serveur ne correspond à aucun d’entre eux) ;
un validateur Monkeysphere (renvoie 1 si le certificat est présent dans la toile OpenPGP et qu’il existe un chemin de confiance jusqu’à lui, 0 dans tous les autres cas) ;
un validateur mémorisant les certificats associés à chaque hôte (renvoie 1 si le certificat actuellement présenté par le serveur est le même que celui mémorisé lors d’une précédente visite, -1 s’il est différent, 0 lors de la première visite) ;
un validateur de « bonnes pratiques », qui attribue un score négatif à tout certificat ne respectant pas certains critères de qualité (par exemple avoir une clef suffisamment grande, ou ne pas utiliser SHA-1).
L’utilisateur aurait la possibilité d’activer ou désactiver les validateurs de son choix, et aussi éventuellement de changer le « poids » accordé à chaque validateur dans le score final.
En gros, on ne jette pas PKIX à la poubelle (même si franchement, j’aimerais beaucoup…), mais on considère ça comme un moyen de valider un certificat parmi d’autres. On pourrait aussi ajouter des validateurs pour Convergence, Certificate Transparency, etc.
P.S. : Je sais qu’il existe pour Firefox des plugins pour chacun des mécanismes de validation décrits ci-dessus (DNSSEC/TLSA Validator, xul-ext-monkeysphere, CertWatch, etc.). Mais il manque, à ma connaissance, l’intégration de tous ces plugins dans un « pipeline » unique, donnant un seul résultat en sortie.
# C'est foutu !
Posté par xof . Évalué à -2.
Un article qui date du 3 juillet dernier…
http://www.20minutes.fr/high-tech/1414499-20140703-nsa-surveille-extremistes-communaute-linux
My 2c
# CA Cert
Posté par Philippe GRAILLE . Évalué à 0.
CA Cert ou auto signé. Le niveau de confiance envers LinuxFR sera pour moi pareil.
Une petite préférence pour CA Cert qui malgré tout a une fonction de vérification un cran au dessus.
Le plus gros problème avec CA Cert c'est de trouver les accréditeurs dans son rayon géographique !
La difficulté de se faire accréditer et le fait qu'aucun OS ne veuillent l'intégrer en CA racine induise probablement sa mauvaise réputation.
Et aussi l'image pas forcément bien structurée qu'ils donnent. (Enfin cela a déjà été débattu).
Le réseau de confiance GPG est bien mais lourd à mettre en œuvre aussi.
Donc au final en bon utilisateur lambda et bien je ne fais rien … honte à moi !
```
[^] # Re: CA Cert
Posté par Zenitram (site web personnel) . Évalué à 3.
Non : le plus gros problème avec CACert c'est de trouver une distro (pas perdue dans un coin) ou navigateur (pareil) qui a confiance en eux.
Les accréditeurs dans son rayon géographique, c'est un tout petit problème comparé à la ligne au dessus.
La, on est d'accord, c'est exactement le même niveau de confiance (les mêmes problèmes pour valider la chaine de confiance).
[^] # Re: CA Cert
Posté par ianux (site web personnel, Mastodon) . Évalué à 4.
Ça existe : https://www.archlinux.org/packages/core/any/ca-certificates-cacert/
[^] # Re: CA Cert
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5. Dernière modification le 06 novembre 2014 à 10:06.
Autrement dit, le plus gros problème de CAcert c'est qu'ils font une vérification d'identité sérieuse, en somme. Personnellement j'appelle ça un avantage.
[^] # Re: CA Cert
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
Largement insuffisant. Tu oublies l'aspect technique : sécurisation des serveurs, des clés privées etc… Et là bizarrement, personne ne fait confiance à CACert parce qu'ils reconnaissent eux-même qu'ils ne peuvent satisfaire toutes les exigences en matières de sécu que demandent Mozilla, Debian etc… Ce sont les fenêtres ouvertes dont parle Zenitram plus haut.
# HTTPS ?
Posté par gUI (Mastodon) . Évalué à -2.
J'ai voté Yaka supprimer le HTTPS, et je le pense très sérieusement. C'est pas ma banque, c'est pas mon mail perso.
C'est naïf, mais je veux bien qu'on m'explique ce que je risque en naviguant sur un tel site sans authentifier la source.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: HTTPS ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Transmettre ton mot de passe en clair.
[^] # Re: HTTPS ?
Posté par dinomasque . Évalué à -2.
Et ?
Au pire, quelqu'un voulant me nuire peut me voler mon compte Linuxfr. La belle affaire.
Je ferai le deuil de mes quelques points de karma puis j'en créerai un autre.
BeOS le faisait il y a 20 ans !
[^] # Re: HTTPS ?
Posté par patrick_g (site web personnel) . Évalué à 10.
Cet usurpateur peut se loguer sous ton nom et poster un journal sur le cyclimse. Et alors ta web-réputation s'effondre !
[^] # Re: HTTPS ?
Posté par ariasuni . Évalué à 2. Dernière modification le 07 novembre 2014 à 16:11.
À part le fait que j’ai pas mal de Karma (5124), c’est pratique de voir les contenus qu’on a publié, bien sûr le fait que je perde mon pseudo sur le site, etc. Je pense que la plupart des gens préfèrent être tranquille de ce côté-là, s’ils ont fait l’effort de s’inscrire (ils ne vont peut-être même pas faire l’effort de se réinscrire).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: HTTPS ?
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 07 novembre 2014 à 21:19.
bah, tu peux redemander la maîtrise de ton pseudo via la ML team ou moderateurs, cela arrive 4-5 fois par an de recevoir ce genre de demande (et les admins sont assez réactifs avec vérification efficace de vraisemblance de la demande).
Bon, je n'ai pas récupéré mon multi qui m'était bien utile pour différencier mes interventions (et tous mes contenus ont été réattribués à un seul pseudo, ce qui entraîne un peu de confusion… mais bon).
[^] # Re: HTTPS ?
Posté par BAud (site web personnel) . Évalué à 6.
Et, bien sûr, tu n'utilises pas le même mot de passe sur LinuxFr.org et d'autres sites ? J'imagine que l'usurpation d'identité ne te dérangerait pas si elle te faisait dire des choses que tu ne penses pas ? (voire répréhensible).
[^] # Re: HTTPS ?
Posté par voxmundix . Évalué à 10.
Chiffrer le trafic non critique permet d’offusquer ton trafic critique.
Si tu ne chiffre que ton trafic critique, alors un adversaire sait qu'il n'a qu'a s'attaquer à ces données et supprimer les autres. Si tu chiffre tout il va devoir tout enregistrer et tout déchiffrer avant de faire son petit tri.
[^] # Re: HTTPS ?
Posté par Adrien . Évalué à 6.
Perso j'ai une vie privée. Utiliser le HTTPS permet de rendre difficile mon fichage par les écouteurs de réseaux.
J'ai pas spécialement envie que tout le monde sache quelles pages je visitent, qui je plussois, quel article je commente…
[^] # Re: HTTPS ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Quel article tu commentes, ça c'est une information publique. Pour le reste, d'accord.
[^] # Re: HTTPS ?
Posté par BAud (site web personnel) . Évalué à 6.
Faut-il encore faire le lien entre son pseudo et son IP pour tenter de remonter à son vrai nom… Bon, avec toi dont le nom est affiché en clair, c'est plus facile ;-)
[^] # Re: HTTPS ?
Posté par AgentSteel (site web personnel) . Évalué à 1.
Bloquer linuxfr au boulot si le firewall voit passer des mots qui lui plaisent pas :)
(à supposer que le firewall du boulot ne fasse pas encore du DPI…)
[^] # Re: HTTPS ?
Posté par gUI (Mastodon) . Évalué à 3.
Merci à tous, j'ai eu ce que je voulais : de bonne raisons de passer en HTTPS :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Et linuxfr*.onion ?
Posté par 2PetitsVerres . Évalué à 3.
Pourquoi ne pas suivre l'exemple de facebook et rendre également accessible DLFP sur un hidden service ?
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Et linuxfr*.onion ?
Posté par voxmundix . Évalué à 2.
Je plussoie.
A noter que Tor Bundle n'enregistre PAS les certificats et donc qu'a chaque visite d'un https non certifié (hidden service y compris) on se tape l'alerte de sécurité (se qui est très dommage car on ne sait JAMAIS si on se fait MITM ou pas quand on va sur son auto-hebergement sans passer par l'hidden service)
# Y'a pas moyen de sauver CAcert ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 9.
On a le même problème pour notre site de démo, et franchement ça me génerait de prendre un service centralisé, CAcert est vraiment celui qui colle le plus à mon avis aux valeurs libres et communautaires.
Qui suit un peut de ce côté si ça avance ? Est-ce qu'il y a une volonté de faire passer l'audit Mozilla ? De revenir dans Debian ?
Qu'est-ce qu'il leur manque ? Des gens ? Des moyens ? On ne pourrait pas monter un financement ? Forker le projet s'il n'y a plus de volonté d'avancer ?
On est en train de perdre un super projet par manque d'intérêt, et j'ai l'impression qu'il ne sont pas super aidés (il y avait un intérêt certain pour eux il y a quelques années, mais il a disparu, ou du moins énormément diminué).
Bref, qu'est-ce qu'on peut faire ? Malheureusement je n'ai pas le temps de contribuer directement, j'ai déjà largement assez de choses à faire, mais je n'ai pas envie de voir CAcert disparaitre, et si même DLFP s'en sépare, après Debian je pense que ça sera difficile de remonter la pente…
[^] # Re: Y'a pas moyen de sauver CAcert ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
Iang écrivait sur la liste cacert [traduit par mes soins] en mars dernier « L'audit est un boulot énorme. Cela requiert une réflexion stratégique à long terme et des quantités importantes d'effort. Cela nécessite plus ou loin l'attention de peut-être 50 à 100 volontaires sur des années. Là où nous en sommes, nous avons peut-être 20 à 30 volontaires, soit la moitié de ce dont nous aurions besoin. (…) Ceci, c'est pour un audit. Nous aurions besoin de 3 audits. Alors multipliez par trois ce qui précède. Et ça coûte, n'oubliez pas que ça coûte de l'argent. »
Il indique aussi que tout cela est tellement compliqué que les distributions ne comprennent pas forcément tout le processus, et qu'elles préfèrent se rabattre sur le travail des autres (par exemple celui qui est fait par Mozilla).
Il ne considère pas l'audit comme faisant partie d'une feuille de route plausible, parlant d'une somme nécessaire à 6 chiffres, du fait que Chrome est devenu le leader, etc. et recommande une approche plus sociale (installer la racine dans son navigateur). Il considère toujours CAcert comme protégeant mieux les utilisateurs que les autres processus.
Il est l'auteur d'un texte (que je n'ai pas lu) sur l'audit http://iang.org/papers/open_audit_lisa.html
Et d'après lui, oui il y a besoin de coups de main sur CaCert.
Sinon il continue à se passer des choses côté CaCert : il y a eu des modifications sur les politiques internes et aussi suite aux dernières failles de sécurité par exemple.
[^] # Re: Y'a pas moyen de sauver CAcert ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Oui c'est énorme, surtout en ramenant à une petite structure comme ça. Mais quand tu vois à quel point ça peut être utile (potentiellement tous les projets libres + de nombreux autres cas), il y aurait peut-être moyen d'avoir un coup de main du côté de structures comme Mozilla, Mediawiki, Debian, Red Hat ou autre…
Parce que l'argumentation de la FAQ DLFP sur CAcert est toujours valide.
Enfin bref, plus facile à dire qu'à faire je m'en rends bien compte.
# Cloudflare ?
Posté par zebul0n (site web personnel) . Évalué à 2.
Cloudflare permet d'obtenir un certificat SSL gratuitement, évidemment il faut que le traffic passe par leurs serveurs et c'est pas trop dans la philosophie de linuxFR j'imagine, mais c'est une option.
https://www.cloudflare.com/ssl
[^] # Re: Cloudflare ?
Posté par KiKouN . Évalué à 3.
Mouai, au final, on a, certe, un joli carré vert dans la barre de navigation. Mais entre cloudflare et linuxfr, ça se fait en clair ou avec un autosigné.
Autant faire direct en autosigné, au moins on sais où on en est et cloudflare ne voit rien.
[^] # Re: Cloudflare ?
Posté par Kioob (site web personnel) . Évalué à 1.
euh… sauf que dans ce cas CloudFlare impose (légitimement) que le serveur backend ait lui aussi du SSL. Du coup, il n'y a pas tellement de gain, si ce n'est qu'on n'a pas besoin de fournir notre certif SSL à CloudFlare.
alf.life
[^] # Re: Cloudflare ?
Posté par zebul0n (site web personnel) . Évalué à 2.
Le gain c'est qu'on peut proposer du SSL avec un certificat auto-signé entre ton serveur et cloudflare sans que les utilisateurs ait un avertissement.
[^] # Re: Cloudflare ?
Posté par Kioob (site web personnel) . Évalué à 1.
Ah, je ne pensais pas que CloudFlare acceptait de se connecter vers de l'auto-signé. Je comprends mieux.
alf.life
# Sondage à choix unique
Posté par Wawet76 . Évalué à 5.
Je n'ai pas d'avis sur la question du sondage, mais j'ai un problème avec le format du sondage :
Actuellement les adeptes de Gandi sont en tête du sondage (si on retire les "on s'en fout").
Oui mais les adeptes du "il faut ajouter un certificat à la main dans son navigateur" (CA-Cert + auto-signé) sont plus nombreux que les adeptes de Gandi.
Oui mais les adeptes du certificat reconnu par défaut par les navigateurs (Gandi + GlobalSign + Verisign) sont plus nombreux que les CA-Cert + auto-signé.
-> Bref, le sondage à choix unique c'est pas bien pour se faire une idée de ce que veulent les lecteurs de LinuxFr.
(ce commentaire vous est apporté par un fan de CGP Grey, et en particulier de ses vidéos sur les systèmes de vote. https://www.youtube.com/user/CGPGrey )
[^] # Re: Sondage à choix unique
Posté par BAud (site web personnel) . Évalué à 1.
bin
# Laisser le choix aux visiteurs ?
Posté par rh . Évalué à 2. Dernière modification le 07 novembre 2014 à 20:31.
Pourquoi ne pas laisser le choix aux visiteurs en proposant deux sous-domaines, chacun utilisant sa propre CA ?
Par exemple : tls0.linuxfr.org pour CAcert et tls1.linuxfr.org pour Commodo.
Je vous offre le certificat Commodo 3 ans si nécessaire :)
[^] # Re: Laisser le choix aux visiteurs ?
Posté par BAud (site web personnel) . Évalué à 1.
Le SNI est plus facile avec nginx qu'apache sur un serveur mutualisé ? Ou tu supposes que la fondation Free va gentiment proposer 2 IP publiques pour un même serveur ? (je ne crois pas, quoique en demandant sympathiquement…). Sans parler des navigateurs rétrogrades :/
[^] # Re: Laisser le choix aux visiteurs ?
Posté par rh . Évalué à 1.
Du moment que NGINX est compilé avec le support de SNI ça se configure auto-magiquement.
Globalement, depuis que la part de Windows XP commence à être négligeable, je considère que la compatibilité SNI n'est plus un problème. Et encore cela fonctionne sous Windows XP avec Firefox et Chrome. Aujourd'hui j'héberge des dizaines de sites web avec le SNI et les seuls visiteurs gênés sont les scanner web qui utilisent des clients HTTPS qui ne le supportent pas. S'il y a vraiment une inquiétude à ce sujet, il y a la possibilité de vérifier la proportion de personnes concernées par un problème de compatibilité à partir des stats de LinuxFr.
[^] # Re: Laisser le choix aux visiteurs ?
Posté par BAud (site web personnel) . Évalué à 3.
sans vouloir te laisser à charge d'argumenter, https://linuxfr.org/statistiques devrait te permettre de fournir le ratio et son évolution sur les derniers mois ?
[^] # Re: Laisser le choix aux visiteurs ?
Posté par rh . Évalué à 0.
J'y avait bien jeté un œil mais il n'y a malheureusement pas assez de détails pour pouvoir calculer ce ratio. À moins d'avoir raté un lien quelque part, j'ai l'impression Webalyser n'affiche que des "TOP" et découpe un peu trop grossièrement les User Agent pour avoir le détail du système d'exploitation.
Même si j'arrive à mettre la main sur la liste complète des User Agent, j'ai peur que les robots qui s'annoncent parfois avec des User Agent aléatoires créent du bruit non négligeable, surtout qu'il s'agit de dénombrer une supposée minorité. Il y a un peu travail et des choix à faire donc. Par exemple : faut-il prendre en compte les IP chinoises (0.43% des hits) et les visiteurs qui ne font qu'une requête GET /phpmyadmin ?
Du coup c'est un argumentaire qui demande un peu trop de travail pour un vendredi soir :)
[^] # Re: Laisser le choix aux visiteurs ?
Posté par BAud (site web personnel) . Évalué à 1. Dernière modification le 07 novembre 2014 à 23:58.
tu reconnais donc n'avoir que peu d'information pour promouvoir ta "solution", en quoi cela motiverait les admins de changer quoi que ce soit ?
une entrée dans le suivi serait déjà un moyen d'en discuter…
[^] # Re: Laisser le choix aux visiteurs ?
Posté par Sufflope (site web personnel) . Évalué à 4.
Le SNI est très bien géré depuis longtemps côté serveur, et côté client il ne pose problème que pour un couple IE + XP… pour les gros nazes donc (fin 2014 on doit enfin pouvoir le dire non ?).
Ca suffit pas comme argument sur linuxfr ?
[^] # Re: Laisser le choix aux visiteurs ?
Posté par BAud (site web personnel) . Évalué à 0.
une entrée dans le suivi, argumentée, serait plus efficace ;-)
# StartSSL
Posté par tuxicoman (site web personnel) . Évalué à 2.
StartSSL (en Israel) fournit gratuitement des certificats reconnus sur tous les navgateurs.
Pourquoi se prendre la tête?
Pour les paranos, la seule solution est le pinning de certificat de toute façon.
[^] # Re: StartSSL
Posté par claudex . Évalué à 4.
Le certificat gratuit de StartSSL n'est valable que pour le sujet et un nom alternatif. Cela fait 3 domaines. Or, linuxfr en a au moins 3 : linuxfr.org, www.linuxfr.org (qui redirige sur le précédent) et img.linuxfr.org. Du coup, ça voudrait dire, réduire le nombre de domaines. Ou en laisser certains chez CaCert/en auto-signé.
« 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: StartSSL
Posté par tuxicoman (site web personnel) . Évalué à 1.
Tu peux avoir plusieurs virtual sites avec chacun leur certificats sur le même serveur.
Ces certificats peuvent partager la même clé privée si besoin.
# et httpseveywhere ?
Posté par Pascal.Petit . Évalué à 0.
Une suggestion indépendante :
Pourquoi ne pas faire en sorte que linuxfr.org soit dans la base de httpseverywhere ?
ainsi, on garantirait l'accès en https à tous ceux qui l'utilisent.
[^] # Re: et httpseveywhere ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Pour rester en HTTPS :
[^] # Re: et httpseveywhere ?
Posté par voxmundix . Évalué à 1.
J'utilise HTTPS everywhere et quand je viens sur linuxfr depuis un moteur de recherche il ne switch pas sur https.
[^] # Re: et httpseveywhere ?
Posté par Donk . Évalué à 2.
Dans HTTPS everywhere, la règle pour linuxfr est désactivée par défaut, car linuxfr utilise CACert
# Utilisation de vérification via les enregistrements DNS(SEC)
Posté par tao popus . Évalué à 1.
Ce système est déjà proposé pour les connexions SSH (SSHFP, rfc4255, utilise DNSSEC) et pour les mails (DKIM, RFC 4871 et 5672). Cela permet une relative indépendance par rapport un organisme tiers et peut se mettre en place simplement.
Une empreinte de clé est contenue dans un enregistrement de type TXT d'un DNS, le client vérifie donc, la correspondance entre ce que propose le DNS et ce que propose le serveur.
[^] # Re: Utilisation de vérification via les enregistrements DNS(SEC)
Posté par gouttegd . Évalué à 3.
C’est proposé aussi pour les clefs OpenPGP (il y a plusieurs propositions d’ailleurs).
Le type TLSA a été créé pour ça (RFC 6698).
# Ergnonomie Tor Bundle et certificat SSL
Posté par voxmundix . Évalué à 1. Dernière modification le 16 novembre 2014 à 11:36.
j'ai trouvé un bon exemple des dérangements provoqués par les avertissements de sécurité firefox envers les certificats ssl: https://forum.ubuntu-fr.org (a essayer avec Tor Bundle)
le seul moyen d'avoir accès a l'interface correctement c'est d'ouvrir le code source, de chercher après une URL pointant vers les CSS, (https://www-static.ubuntu-fr.org/theme2010/css/forum-ubuntu.css) et d'aller dessus. Et répeter cette opération fastidieuse a chaque fois (pour un avertissement toujours plus inutile vu qu'aucun certificat n'est sauvegardé).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.