Firwen a écrit 562 commentaires

Merci pour ta réponse, j'aime particulièrement ton point de vue sur CA transparency.

Juste quelques points :

en quoi est-il déraisonnable d’épingler ce certificat dans un enregistrement TLSA ?

Parce que ça force l'infrastructure et l'intégralité des clients à supporter le bousin ?
TLSA tout seul sans DNSSEC est inutile.
Et DNSSEC est un monstre à déployer et supporter. Un monstre qui actuellement n'est supporter par personne, ni coté client, ni coté serveur.

Je suis actuellement dans une organisation de 15000 personnes où ni DNSSEC ni DANE ne peut pas marcher, et ne marchera sûrement jamais. Simplement parce que les requètes DNS sont filtrées, comme dans beaucoup d'environnement pro.

Certificate Transparency corrige quoi au juste ?

Autant le dire : Certificate Transparency ne sert à rien, et surtout pas à « corriger les problèmes des CA ».

L'idée derrière Certificate Transparency est de créer une base publique de tous les certificats émis existants.

Si l'utiliser pour détecter les conneries des CA peut être un premier cas d'utilisation évident.
L'idée sur le long terme est de pouvoir "pinner" dynamiquement chaque certificat sur ces databases, et ça çareglerait pas mal de problèmes.

Certificate Transparency est justement conçu pour s’assurer qu’elles ne disparaissent pas.

Ça l'est. Et je n'ai jamais dit que j'aimais particulièrement cette solution. cf mon commentaires précédents sur les alternatives.

C'est DANE/DNSSEC que je n'aime pas pour tout un tas de raisons evidentes expliquées plus haut.

Toutes ces méthodes sont intéressantes et la meilleure solution est à mon avis de permettre d’utiliser toutes ces méthodes selon ses besoins et convenances, plutôt que de vouloir absolument une méthode unique. DANE est une des méthodes possibles. Encore une fois, personne n’a prétendu que ça devait être la seule. Contrairement aux CA, qui ont pris soin de se rendre indispensable.

Nous sommes d'accord.
```

Pourquoi pas ? Implémenter DNSSEC/DANE n’interdit pas les autres méthodes. Personne n’a jamais dit que DANE devait être le seul moyen d’authentifier un serveur TLS.

Bien, comme ça au lieu d'avoir une surface d'attaque pour faire du MitM, on en aura deux.

Avec cet argument là, autant ne rien faire du tout…

Non, on fait simplement des choses avec des étapes de transitions raisonnables.

Au passage, Certificate Transparency est beaucoup moins flexible sur ce plan, puisqu’il interdit explicitement tout certificat qui n’aurait pas été émis par le cartel des CA.

Il n'a jamais été designé pour les remplacer, uniquement corriger leur problèmes: ce qui est le plus urgent à faire.

Je n'aime pas plus les certificate authority que vous: elles coûtent cher, ont un monopole honteux, une éthiques douteuses pour certaines d'entre elles. Je les verrai avec joie disparaitre.

Mais deployer DANE est juste remplacer un monstre par un autre qui ne corrige pas les problèmes du précédents et qui apporte son propre lot d'emmerdes. Le seul avantage de DANE est la réduction des couts pour les particuliers: plus besoin de payer le CA.

Un internet sans CA viendra bien plus probablement de choses comme :
- convergence, qui introduit le concept de notaries
- monkey-sphere, qui veut authoriser les signatures multiples et donc le création d'un Web-of-trust avec SSL
- namecoin, qui autorise la publication irrévocable via blockchain du fingerprint de tout certificat.
- TACKs, qui permet de faire du Trust-On-First-Use avec TLS/SSL.

Maintenant vous pouvez moinsé.

Et pour la majorité des utilisateurs. On fait quoi ? Parce que pour eux, il en suffit d'une pour foutre la merde partout.

On implémente le pinning proprement au niveau de TLS ? Et on mets en place le certificate transparency sur le long terme ?

Des trucs comme certificate transparency seraient bien, malheureusement les CA n'ont pas l'air de se bouger. Peut-être que si leur business se voit menacé par DANE, elles s'y mettront.

Tu es très optimiste.

Admettons que IE, Opera, Chrome, Safari et Firefox se décident d'implémenter DANE et de l'activer par défaut disons….la semaine prochaine.
Admettons que les infrastructures DNS de TOUS les FAI (même ceux du boudjikistan), les réseaux d'entreprises et TOUS les opérateurs mobiles se décident à forwarder correctement DNSSEC et DANE (ce qui est déjà hautement improbable, ça prendrait des années).

Tout comme IE6 ont pourrit la vie des devs Web pendant 10 ans, tu vas forcément continuer à avoir des utilisateurs sous IE9 ou Android 2.3 qui ne géreront pas correctement DANE pendant des années et des années. Donc rien que pour ceux là, tu devras aussi faire signer ton certificat par une autorité de certification et rentrer dans le business juteux des CAs qui continueroent de vivre paisiblement.

DANE/DNSSEC n'est pas en soit un mauvais standard. Mais c'est un standard qui arrive bien trop tard, quand le système de CA est déja le centre du monde et presque impossible à déloger.

Sauf les USA contrôlent déjà pleins d'autorités de certification. Donc, ils peuvent déjà signer pour le monde entier. Là, on limite à ¾.

En pratique, tous les noms de domaines des sites à gros trafic sont en .com sous leur control, tu changes uniquement 100% par 99%. Sans parler du fait que la "racine" elle-même a besoin d'être signée

Il ne reste plus qu'à avoir un script qui permet de vérifier que .com, le .be, le .br, le .ru et le .cn sont bien les mêmes et tu as beaucoup de chance que le contenu n'ait pas été modifié ☺.

Ils n'ont pas besoin de changer l'enregistrement de .com et ton script n'y changera pas grand chose. Si ils ont la clé privée qui sert à certifier les sous-domaines de .com, alors ils peuvent très bien falsifier la résolution de google.com et tu n'y verras que du feu. Tout comme avec le système de CA actuel.

La seul solution à ça est de ré implémenter encore une fois le pinning, mais cette fois avec DANE, comme mentionné dans l'article originel.

J'ai par ailleurs de gros problème avec l'association 1-1 entre DNS et autorité de certification de DANE.
Je veux choisir à qui je fais confiance.
Avec le système actuel, je peux: je l’enlève simplement de la liste des CA de confiance de mon application.

Avec DNSSEC, je ne peux pas : cette autorité est liée d'office à mon nom de domaine.

A mon sens, les hypothétiques avantages de DNSSEC/DANE ne justifient pas sa complexité de déploiement ni les problèmes annexes qu'il génerent :

• Quid des portails captifs qui faussent la résolution de noms de domaine ?
• Quid de l'abandon de UDP pour TCP/TLS sur la latence / charge des serveurs DNS ?
• Quid de la transitions entre les deux ? on va encore se taper les CA pour 10 ans en parallel ?

Des solutions comme TACKs, certificate transparency, ou convergence sont bien plus prometteuse que DANE à mon humble avis.

Je ne suis pas d'accord. Bien sûr, un gouvernement peut signer n'importe quoi pour son TLD mais, c'est limité à son TLD. Avec DANE, la Chine ne peut pas signer un certif pour google.com alors qu'elle le peut (et le fait) avec l'implémentation actuelle.

Donc la Chine pourra signer uniquement le .cn et les USA pourront signer la moitié du monde car ils contrôlent le .us et le 3/4 des domaines non-nationaux ( .com, .org, etc..)

Mais comme les USA sont une nation exemplaire qui jamais, au non, jamais n'autoriseront leur agence de renseignement, la NSA, à intercepter les communications privées des gens: Tout va bien, vous pouvez dormir tranquille braves gens…

Nan, nan je déconne: c'est la même merde.

DANE remplace un schéma cassé par un autre. Il ne règle pas absolument pas le problème des attaques MitM en cas d'authorité corrompues.

Il transforme juste un schéma cassé de certification à deux niveaux, en un schéma cassé de certifications à X niveaux.

C'est surtout que TACK ne réutilise pas les CAs en fait: est-ce que tu imagines avoir une TSK par serveur Google, y compris les CDNs un peu partout dans le monde

Il y a aucun souci à ça.
Tu peux utiliser une même TACK key pour signer plusieurs certificats X509.
Etant donné que les certificats de Google/facebook sont déja signé par un CA à leur génération, rajouter une signature devrait être un jeu d'enfant.

Le gros problème de TACK est qu'il rend l'architecture X509/CA/TLS encore plus monstrueuse, confuse et bordélique qu'elle ne l'est déja.

Pour digresser un peu, TACK a l'air de vouloir jeter le bébé avec l'eau du bain.

Sauf erreur de ma part, TACK n'interdit pas l'usage des CAs et surtout pas X509.

Il stipule simplement que tu peux te passer des CAs si tu acceptes une protection "TOFU" contre les attaques man in the middle.

HPKP est comme souvent avec Google, une solution simple(iste) mais efficace aux problèmes qui les touche plutôt qu'une tentative de résoudre le problème dans son ensemble.

Pour plus d'informations sur le sujet :

https://bitcointalk.org/index.php?topic=413196.0

Si une personne vote devant une urne, elle ne peut voter qu'une fois. Une personne qui vote devant son ordinateur, c'est plus complexe.

La blockchain règle trés bien ce problème, de manière sure et vérifiable publiquement.

Le problème principal est : "Est-ce bien toi qui vote, et non Mr X qui a acheté 500 votes / accounts sur internet à des électeurs peu scrupuleux ?"

Le système le plus développé et puissant que je connaisse basé sur ce principe est basé sur bitcoin/ zerocoin et ça marche.

Le gros problème de cette solution est justement est la vulnérabilité à l'achat de vote. Le token n'étant pas nominatif, il est tout à fait possible de le revendre/acheter/transmettre.

Les bulletins étant rendus publics après le scrutin, ce qui permet de vérifier celui-ci. On peut considérer que l'enjeu est suffisamment faible et les électeurs suffisamment éduqués pour éviter les pressions : ce n'est pas demande que quelqu'un viendra me promettre de me casser la gueule si je ne vote pas en priorité pour élire untel comme DPL.

Exactement.

Jusqu’à nouvel ordre on est "encore" dans un pays libre, même si le gouvernement a l'air d'aiemr les lois liberticide ces temps ci.

Et il serait peut-être bon que les gens apprennent à défendre leur opinions.

Ce n'est pas une erreur humaine. C'est une grave erreur d'incompétence.

• Le fait d'autoriser Java en plugin web browser en 2015 en tant qu'administrateur est une preuve d'incompétence.

• Le fait de ne même pas isoler un serveur critique du réseau des postes clients est une faute professionnel.

• Utiliser Windows et Skype pour communiquer avec Daesh, sans aucune protection particulière, alors qu'ils sont connu pour avoir un réseau d'activistes, c'est un gros manque de prudence.

• Twitter supporte l'authentification à deux facteurs comme Google, facebook, et probablement même le Vatican. Si ils se sont fait pirater leur Twitter, c'est qu'ils ne l'utilisaient pas. Dans leur position, et alors qu'ils se savaient menacés, c'est du haut niveau de branquignolle.

Et je parlerai même pas du fait d'installer un Infra 100% Windows avec les risques que ça peut causer, parce que c'est vendredi…

Je ne sais pas si le principe peut aussi être bon avec Qt mais pour mon soft, j'ai fais comme cela (avec Gtk du coup):

Le signal/slot system de Qt est thread-safe, tu peux faire exactement la même.

Np, je te ferai un patch dans la semaine si j'ai un poil de temps :)

Si tu veux un petit bug report <sup>^</sup>

Quand tu scan la collection sur le disque dur, essaye de le faire dans un thread séparé.

Je n'ai pas vérifié mais tu dois le faire via un signal/slot je suppose: l'interface "freeze" chez moi pendant 20-25 min due à la taille de ma collection :D Mon gestionnaire de fenetre me propose 10 fois de killer tonapplication à cause de ça.

C'est la dernière fois que je poste ici. J'ai la net impression que je perds mon temps et que tu n'as même pas essayer de comprendre ce que je voulais dire.

Tu me montre « la simple ligne de configuration » qui permet ça dans make, gprbuild, cmake ?

Exemple de mon point N°1, cmake :
CHECK_SYMBOL_EXISTS(SetConsoleMode "windows.h" HAVE_SETCONSOLEMODE)

Exemple de mon point N°2, cmake :
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/config.h.in ${CMAKE_CURRENT_BINARY_DIR}/config.h)

Exemple de mon point N°3, cmake: un simple "target_link_libraries(myexe somesystemlib)", PS: jette un coup d’œil à ce qu'il fait RÉELLEMENT derrière sur différente plateformes / compiler et tu comprendras la différence par rapport à Java / Gradle / Ceylan.

Je suis curieux de comment tu fais les deux premiers avec Maven… juste pour voir.

L'objectif c'est de lancer des tâches, d'avoir un cycle de vie intéressant (1 gestion de dépendance, 2 build, 3 lancement des tests, 4 déploiement là où tu veux - par exemple -),

Non, non et non.

Si tu es payé pour étudier et faire ton propre build system alors oui peut être.

Si ton objectif est d'avoir un outil qui t'autorise à automatiser au mieux les différentes taches d'un build, de la manière la plus efficace et la moins verbeuse possible, pour te faire gagner du temps alors non.

Ce que tu veux c'est un outil qui couvre tous tes besoins et au mieux. Et c'est justement ces "détails du bout de la lorgnette" qui te font gagner le plus de temps car ils sont spécialement fait pour le/les languages associés..

make ne sait pas lire du C++, il ne comprends rien au C non plus. Idem pour les autotools qui ne bittent rien d'autre que le langage spécifique de chacun des outils.

Bien evidemment, ce n'est pas des compilateurs et je n'ai jamais dit ça….
Mais ils intègrent tout ce qu'il faut pour faire ce que j'ai décris plus haut en une simple ligne de configuration.

Est-ce que Maven le fait ? non.

ça n'a rien rien de difficile ni pour maven, ni gradle, ni scons, etc.

En effet, SCons est l'exemple typique de build système qui tend à être universel et qui est au final un magnifique ratage. J'ai utilisé SCons dans plusieurs projets par le passé, et la finalité a été de tout migré sous CMake.

Les gens qui ont permis à maven de travailler sur du groovy, du scala, du ceylon

Tous des langages à JVM en gros  ?

De même pour ceux qui ont créé le plugin nar pour gérer du C et C++

Qui est tout juste bon pour intégrer quelques morceaux de C/C++ dans un projet java existant en bidouillant. ( Et encore si la chaine de compilation est pas trop dégeu. )

Mais si tu te sens un ame de révolutionnaire, n'hesite pas à me prouver que j'ai tord et créer ton propre plugin maven pour re-faire autotools, je suis curieux de voir….

mais des arguments contre intéressants j'en ai pas vu dans le commentaire parent.

Tu arrives un peu tard Michel <sup>^</sup> Mais peu importe, je vais essayer d'être plus clair.

Mon commentaire précédent pourrait se résumer à "Concernant les tools de compilations, evil is in the details" et par conséquent un outil designé pour un language est bien souvent inadapté pour un autre.

Les builds tools sont bien plus compliqués qu'il n'y parait dés qu'on creuse un peu.

Ça n'a rien à voir avec Maven ou pas maven.
Je conseillerais vivement la personne qui utilise autotools pour gérer un projet complètement en python d'aller voir un psy: c'est du sadomasochisme, ça n'a jamais été fait pour ça.

Il en va de même pour Java et Maven: Maven a principalement été conçu avec Java en tête : il est déclaratif, minimaliste, adapté à une chaine de compilation relativement simple pour un langage à bytecode multi-plateforme.

Maintenant, compare ça à C/C++ avec cmake ou autotools qui sont les mastodontes du secteurs pour de bonne raisons.

Ils gèrent un véritable dictionnaire de fonctionnalités nécessaires à la compil C/C++ :

• ils sont capable de générer des micro programmes, de les compiler et de vérifier le résultat pour tester le support du compiler pour
  • une fonction
  • un header
  • une signature

• ils parsent / transforment dynamiquement suivant la configuration/plateforme les headers de configurations ( les fameux config.h ) automatiquement pour garantir une certaine portabilités entre plateforme avant de les compiler

• ils gèrent de manière transparente le bordel liés à la multi-tudes d'options et de paramètre différents propre à chaque linker et à chaque compiler.

• ils changent les options passé au compilateurs suivant l'OS, la plateforme, l'architecture

  • Large file support ou pas
  • SSE1/2/3 ? pthread ? Windows thread ? socket ? winsocket ?

• ils détectent et enregistre la dernière date de modification ( ou checksum ) de chaque fichier du projet ( et uniquement du projet ) pour ne recompiler QUE les fichiers qui ont changer et minimiser les temps de compilations relativement long du C/C++.

• ils créent des arbres de dépendance pour pouvoir paralléliser la compilation de chaque fichier "objet" / shared library / executable sans causer des problèmes de linkages.

• ils doivent pouvoir supporter une gestion à la fois "automatique" et "fine grain" pour pouvoir supporter tous les hacks propres à la compilation C/C++

  • inclusion code assembleur
  • double compilation, cross compilations
  • symbol versioning
  • rpath
  • symbol stripping
  • etc, etc, etc… ….

Et j'en oublie encore beaucoup. Les build systems C/C++ sont des usines à gaz et c'est pas juste pour le plaisir de les rendre monstrueux.

Maven ne supporte pas ça, n'est pas adapté pour ça, ne le sera sûrement jamais…. Et à mon humble avis, ne doit pas essayer de l'être…. sous peine de devenir un bordel encore plus complexe que les autotools eux même.

Ou comment tirer un gros Scud sur Mozilla de manière indirecte ;-).

Ça c'est ton interprétation ou ta croisade personnelle mon cher Zenit.

Chez moi, et c'est le paramètre par défaut de ma distro. Firefox a effectivement OCSP activé par défaut mais configuré comme "non requis", donc pas de problème.

C'est pas la faute d'OCSP ça. Sinon autant dire que tous les protocoles autres que HTTP sont mauvais par design.

De mon point de vue c'est de la faute d'OCSP et de son design.
OCSP n'est pas seulement un protocole mais une "solution" pour fournir, entre autre, un système de révocation à TLS.

Non seulement cette solution ne prend même pas un cas de figure aussi courant en compte, mais en plus elle rend TLS inopérant quand il se présente.

Si tu design un protocole censé "renforcer" la sécurité d'une solution existante. Tu le fais au minimum sans pénaliser l'existant.

Même les CRLS qui sont généralement configurées pour "fetcher" de manière asynchrones les listes via un protocol X, ou DANE, ne souffrent pas de ce problème.

À mon humble avis, c'est plutot l'OCSP que StartCom dans cette histoire.
Il y a déja eu pas ma lde cas similaire dans le passé.

L'OSCP est mauvais par design, et ce n'est pas pour rien que les navigateurs principaux le désactive par défaut.

• Il cause des problèmes de latence
• Il ne marche pas lorsque le client est derrière un pare-feu/proxy un peu trop restrictif
• Il crée un goulot d'étranglement sur une techno qui a été créée pour ne pas en avoir.
• Il facilite grandement les attaques par DDOS ….

Même si ça sent grandement le troll, je dirais que même les CRLs étaient mieux conçu que OCSP….

Faire une telle généralisation c'est aller un peu vite en besogne.

Non, il a entièrement raison.

Le système de CA est cassé depuis des années, et tout le monde le sait.

https://www.youtube.com/watch?v=Z7Wl2FW2TcA

À l'heure actuelle, il y a environ plus de 1000 CA considéré comme valides dans la plupart des navigateurs: c'est une aberration.
Il suffit qu'UNE SEULE d'entre elles ait été corrompue ou trouve sympa de collaborer avec la NSA/FSB/GCHQ/DGSE/(inserer autre ici) pour que l'intégralité du système soit compromis.

Aussi "sérieuse" que peuvent être certains CA, ça ne change rien au problème. Et ni OCSP, ni les CRL ni HSTS ne fournit une solution acceptable à ça.

Le certificate pinning ne marche que pour les quelques "gros" acteurs du secteurs, le certificate transparency est uniquement à l'état de prototype et ne règle pas tous les problèmes. DANE est une blaque de complexité qui remplace un monstre par un autre.

À l'heure actuelle, si vous voulez réellement "sécuriser" votre application métier en interne… Le seul moyen est de créer votre propre CA et d'éliminer tous les autres….

Solution qui est bien évidemment inacceptable pour le Web.

Bref, c'est la merde.

Je parle de la majorité des VM qui tournent dessus, pas du système :D

Peut être parce que 1% c'était au siècle dernier ?

L'heure est aux infrastructure Cloud et aux services, avec tout ce que ça a de bon et de mauvais.

Linux et les écosystèmes libres offrent l'avantage d'être customisables à souhait et répliquables à l'infini ce qui est parfait pour la virtualization.

Amazon EC2, Google Cloud, Rackspace, IBM VMWare, les services privés/publiques basés sur OpenStack, tout ça c'est du Linux et il y a des raisons évidentes à ça.

Dans ce domaine c'est Microsoft qui est en position de faiblesse: Dans le domain du Iaas personne ne veut payer pour un OS, personne n'est intéressé par les avantages bloatwares habituels de Windows (Active directory, integration…), personne ne veut déployer un windows server complet pour containérisé un simple petit service….. Ici la première distro venu fait bien mieux le boulot.

Et je ne parle même pas des infras containers qui arrivent au galop pour finir de creuser leur tombe.

Et dans le domain du Cloud, c'est eux qui risquent d'être réduit à 1% si ils ne changent pas leur politique sur le long terme.
Et ça ils l'ont bien compris.

Maven a été designé pour Java.

Si j'étais d'humeur à troller, je dirais que même pour Java il a déja quelques problèmes ( c'est Vendredi)

Il n'est pas adapté au dev C++, même si il peut le faire pour des raisons évidentes.
Dans un environment C++, l'architecture, la taille des registres, la gestions des instructions de vectorisations (SSE…), le compilateur, la plate-forme sont des paramètres bien plus cruciaux que dans un environnent Java.

Maven n'a jamais réellement été développé avec ces problèmes en tête.

Sans même parler qu'installer une JVM de 200Mo pour compiler un programme de 20ko est propablement pas la manière la plus optimale de faire la chose.