An information leak (memory disclosure) can be exploited by a rogue SSH server to trick a client into leaking sensitive data from the client memory, including for example private keys.
Si la fuite est dans le client SSH, ceux qui utilisent un agent n’ont a priori pas à craindre pour leurs clefs privées, vu que celles-ci sont dans la mémoire du processus de l’agent et pas dans celle du client proprement dit.
Pour des modifs pas trop volumineuses, on peut aussi simplement envoyer un patch par e-mail, même pas besoin d’avoir son propre dépôt public qelque part.
Malheureusement il y a des développeurs « responsables du dépôt principal » qui ne connaissent rien d’autre que GitHub et ne savent rien faire en-dehors…
J’ai déjà envoyé des patchs simplissimes (genre une ligne) à un développeur upstream qui, au lieu de les appliquer directement sur son dépôt, les a importé sur GitHub pour pouvoir créer des « Pull requests » et immédiatement les merger via l’interface de GitHub…
(Non pas que ça me dérange outre mesure, après tout c’est le développeur upstream qui à mon avis se complique inutilement la tâche, pas moi… et à vrai dire je préfère ça plutôt qu’il me renvoie mon patch en me demandant de faire moi-même la pull request sur GitHub.)
Qu’il ne faille plus utiliser RC4, certes. Mais de là à dire qu’il est cassé au point que la NSA le lit en temps réel, soit on me donne des détails soit j’achète pas, désolé.
Surtout quand juste après le même gars dit « Or to put it another way: academics have said RC4 is broken for years. Listen to them. »
Il y a une grosse marge entre « les chercheurs en cryptographie disent que c’est cassé » et « la NSA le casse en temps réel », ce n’est pas simplement « dire la même chose d’une autre façon ». La première phrase est factuelle, la seconde est pure spéculation. Et comme la première est, à elle seule, suffisante pour justifier le retrait de RC4, le recours à la seconde discrédite complètement le propos.
De manière générale, j’accorde peu de crédit aux discours alarmistes du genre « omg on va tous mourir la NSA peut [insérer ici des allégations dignes des Bruce Schneier facts] ».
Ah, et comme on ne parle que de crypto ici, je crois que c’est le bon endroit/moment pour rappeler que la crypto ne vous sauvera pas (version vidéo). Même s’il n’y a pas d’exemples relatifs à TLS, les multiples cas présentés où la cryptographie a été complètement contournée sans jamais être attaquée de front sont très intéressants.
Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it.
Non, en tout cas pas une implémentation « native » (intégrée par défaut de base dans le navigateur)
À noter tout de même le travail de Viktor Dukhovni (a.k.a « Monsieur DANE », auteur ou co-auteur d’à peu près tous les RFCs sur DANE, et auteur de l’implémentation correspondante dans Postfix) pour implémenter DANE directement dans OpenSSL, où ça aura un bien plus grand impact (pouvant bénéficier à une tripotée d’applications) que dans un seul navigateur.
Ce que j'ai compris est que les downgrades ne sont pas possible avec TLS
Malheureusement si, pour les mêmes raisons qui font que le downgrade de TLS (toutes versions) à SSl 3.0 est possible.
Sauf encore une fois si le RFC 7507 (le fameux TLS_FALLBACK_SCSV) est implémenté des deux côtés.
(Une rapide recherche ne m’a pas permis de trouver à quel point le support de ce RFC était répandu parmi les navigateurs — et à partir de quelles versions — , juste qu’apparemment Microsoft ne prévoit pas de l’implémenter dans IE : « At this time we de not plan on making this change », et notez que le bug est closed.)
À votre avis est-ce que nous allons bientôt avoir une implémentation de DANE dans nos navigateurs ?
À mon avis ? Non, en tout cas pas une implémentation « native » (intégrée par défaut de base dans le navigateur). Je ne sais pas pour Firefox, mais les devs de Chrome ont clairement fait savoir que ce n’était pas au programme.
En attendant, il y a toujours ce plugin que je ressors à chaque discussion sur le sujet. Et (attention, auto-promotion éhontée) ma propre implémentation pour Uzbl.
Quand SSLv3 a été jugé trop troué, il a été désactivé à ce moment-la (et pas avant).
Pas d’accord. La désactivation massive de SSL 3.0 date d’il y a quelques mois (c’est POODLE qui a donné le coup de pied au cul nécessaire), et ça fait bien plus longtemps que ça qu’on savait que SSL 3.0 avait trop de failles.
Firefox et Chrome ont désactivé SSL 3.0 après POODLE non pas parce que c’était la faille de trop, mais parce que c’est avec cette faille qu’ils se sont rendus compte qu’il y avait encore trop de serveurs dans la nature qui offraient sans sourciller du SSL 3.0.
Quel risque réel de downgrade avec TLS 1.0?
Faible a priori si client et serveur supportent le mécanisme anti-repli (mécanisme qui au passage n’aurait jamais du être nécessaire si serveurs et clients avaient respecté le protocole TLS, au lieu d’adopter le comportement du « ça passe pas en TLS n alors je me fous de la sécurité et je tente en TLS n−1, ah ben là ça passe c’est donc bien que ça devait être une erreur et pas une tentative d’attaque », mais c’est une autre histoire). Après, on n’est jamais à l’abri d’une erreur dans une implémentation (erreur à laquelle tu fermes complètement la porte en ne supportant pas le protocole plus faible en premier lieu).
Note, je ne suis pas en train de dire de ne pas supporter TLS 1.0 (même si idéalement il faudrait). Comme indiqué sur la page du wiki de Mozilla que j’ai cité par ailleurs, c’est à évaluer en fonction du public attendu.
ça c'est une autre histoire, mais pareil pourquoi désactiver alors que c'est peut-être le seul moyen et qu'il vaut mieux un peu de sécu que pas du tout?
J’aimerais vraiment que tu me trouves un client encore en service (même avec 0.00009% de part de marché) qui ne supporte rien de mieux que les suites EXPORT.
Et contrairement à d’autres technos déjà déconseillées mais contre lesquelles les attaques relèvent encore aujourd’hui de la spéculation (SHA-1 par exemple, on soupçonne fortement que créer des collisions est à la portée d’un adversaire de niveau étatique mais ça n’a pas encore été fait — de même que casser du RSA 1024 bits), il existe des attaques complètement réalistes (et à la portée de quiconque a un peu d’argent à dépenser sur Amazon EC2) contre les suites EXPORT.
Je n’ai pas d’objection à ce qu’on continue à supporter une technologie obsolète après avoir pesé les avantages et les inconvénients, si on estime qu’on peut encore avoir des clients qui en ont besoin.
Le problème, c’est de continuer à supporter une technologie obsolète sans avoir fait cette analyse, juste parce que cette technologie est activée par défaut. Il est à peu près certains que la plupart des administrateurs de sites web ne savaient même pas que leur logiciel serveur offrait par défaut des suites EXPORT (full disclosure : je ne le savais pas non plus).
en quoi conserver de vieilles techniques pour les vieux bousin impacte les gens à jour?
Ça ouvre la porte à de possibles downgrade attacks, où un client et un serveur qui supporte tous deux une technologie moderne et résistante basculent sans raison sur une techno plus ancienne et potentiellement craquable.
Et il y a aussi le cas des technos tellement anciennes qu’elles ne sont même pas justifiées par le besoin de rester compatible avec les (très) vieux clients, mais que les serveurs supportent toujours simplement parce qu’elles sont activées par défaut et que personne n’a pris la peine de les désactiver. C’est typiquement le cas de toutes les suites EXPORT par exemple. Je pense que c’est surtout à ça que ton interlocuteur faisait référence.
et oui, je continue d'avoir du 3DES
À raison. Il n’y a aucune attaque praticable connue contre 3DES.
Si quelqu'un a une page qui récapitule les suites supportées par navigateur et version, ça m'intéresse de voir
Il y a cette page maintenue par Mozilla, qui sans donner directement la récapitulation que tu cherches, indique les plus vieux navigateurs compatibles avec leurs trois configurations recommandées (« moderne / intermédiaire / vieux »).
Tu retardes, le futur n’est plus dans la cryptographie à base de courbes elliptiques, mais dans la cryptographie post-quantique.
La NSA (qui a longtemps été une des principales forces poussant à l’utilisation de la cryptographie ECC via sa « Suite B ») a annoncé l’année dernière qu’elle n’y croyait plus :
Unfortunately, the growth of elliptic curve use has bumped up against the fact of continued progress in the research on quantum computing, which has made it clear that elliptic curve cryptography is not the long term solution many once hoped it would be.
En attendant, ceux qui redoutent sérieusement que les agences en trois lettres puissent casser leurs clefs RSA et/ou leurs groupes DH de 2048 bits devraient, pour être cohérent (hé, il y a un risque que la NSA ait un ordinateur quantique d’ici 2030), se mettre tout de suite à utiliser du McEliece ou assimilé. Des clefs de plusieurs mégaoctets, voilà qui devrait les satisfaire.
si la suite de chiffrement négociée n’est pas une suite PFS (Perfect Forward Secrecy)
J’ai délibérément négligé ce cas-là, en effet, parce qu’à part pour supporter de très vieux navigateurs je ne vois guère de raison de continuer à offrir des suites de chiffrement sans confidentialité persistante.
des paramètres DH de 2048 bits, donc fragiles par rapport à LogJam
Toujours pas d’accord sur le caractère fragile. Le vrai problème de LogJam n’est même pas que les serveurs utilisaient des paramètres DH de 1024 bits (même si 1024 bits est en effet un peu trop faible pour être à l’aise), mais surtout que la plupart des serveurs ont utilisé pendant des années (jusqu’à la révélation de l’attaque en fait) les mêmes paramètres DH pour tout le monde (ceux proposés par le RFC 2409), offrant ainsi à énorme jackpot aux grandes oreilles : il leur suffisait de casser un seul groupe DH pour être en mesure de déchiffrer les communications de n’importe quel serveur.
révoque le certificat immédiatement (ce qui t’empéchera de l’utiliser)
Ça c’est si les mécanismes de révocation fonctionnaient correctement, ce qui n’est pas le cas.
Les CRLs n’ont jamais vraiment fonctionné, et Chrome et Firefox ne les utilisent même plus.
OCSP pose au moins autant de problèmes qu’il n’en résoud (dont un joli problème de vie privée, en révélant à la CA toute connexion aux sites dont elle a signé le certificat), est souvent désactivé par défaut (notamment sur Chrome), et quand il est activé c’est toujours en mode soft-fail, de sorte qu’il suffit de bloquer la requête (ou la réponse) OCSP pour passer outre la vérification (et si on passe en mode hard-fail c’est encore plus drôle, on peut faire un déni de service sur le site visé en attaquant le serveur OCSP de sa CA).
Reste l’OCSP Stapling (j’aimerais bien des stats sur son utilisation), et les « CRLsets » de Chrome qui ne sauraient être applicables à une grande échelle.
HSTS n'est pas dangereux du moment que nous sommes certain que le site sera dorénavant toujours en HTTPS.
Si, le risque c’est que la moindre erreur de configuration rende le site inaccessible, parce que le navigateur n’aura pas le droit de passer outre.
Typiquement, un administrateur oublie de renouveller son certificat et le laisse expirer (un des écueils que Let’s Encrypt cherche à éviter en automatisant le plus possible, justement parce qu’on a constaté que ce genre de choses arrivaient trop souvent dans la réalité) :
Sans HSTS, ce n’est pas trop grave, le navigateur va afficher un message d’erreur mais va laisser à l’utilisateur la possibilité de passer outre (« il y a un problème avec le certificat de ce site. Voulez-vous continuer ? » — ce à quoi l’utilisateur répond « un problème avec quoi ? Évidemment que je veux continuer, je veux continuer ma visite moi. »).
Avec HSTS et si l’utilisateur a déjà visité le site préalablement, c’est mort, le navigateur qui respecte le RFC 6797doit avorter la connexion.
C’est justement le but recherché de HSTS, qui signifie en gros « l’administrateur de ce site ne fait pas d’erreurs, si votre navigateur détecte un problème, c’est qu’il y a réellement quelque chose de louche, ce n’est pas un truc que vous pouvez ignorer en mettant ça sur le compte du laxisme de l’administrateur ».
D’où l’importance de n’utiliser HSTS que si l’on ne fait réellement pas d’erreur…
HPKP pour moi est un vrai risque car il faut faire le pari que ton visiteur va revenir dans le laps de temps qui lui est imparti.
Ce n’est pas un problème, ça. Si le visiteur revient après la durée d’épinglage, on se replace juste dans le cas initial d’une première connexion. Ça n’interdit pas l’accès au site, c’est juste qu’on n’a pas, pour cette « première » connexion, la protection apportée par HPKP.
Pour info, HSTS a un comportement similaire : lui aussi a une directive "max-age" au-delà de laquelle le navigateur ne doit plus considérer que le site doit être accédé en HTTPS uniquement.
les navigateurs décident d'implémenter leur propre résolveur
Je préférerais que les systèmes d’exploitations fournissent par défaut un résolveur DNS validant (que non seulement les navigateurs mais aussi toutes les autres applications pourront utiliser) plutôt qu’un « stub resolver ». À ma connaissance, aucun système ne fait ça à l’heure actuelle, celui qui veut un résolveur validant doit l’installer lui-même.
Il est parfaitement possible d’automatiser tout cela, mais les clients de Let’s Encrypt ne le font pas
Pour être honnête, la faute n’incombe pas qu’à Let’s Encrypt. HPKP est encore récent et il n’existe pas, à ma connaissance, d’outils pré-existant pour gérer ça de manière automatisée (à la manière de OpenDNSSEC pour gérer les clefs DNSSEC).
Je prédis que HPKP ne connaîtra pas un grand déploiement tant que de tels outils n’existeront pas, et on ne peut pas mettre ça sur le dos de Let’s Encrypt (même si eux seraient sans doute bien placés pour créer les outils en questions).
Pour moi, Let's encrypt permet justement de renforcer la sécurité générale, car elle évitera que des certificats trop faible persistent sur le web trop longtemps.
Rien à redire là-dessus, je n’ai rien contre des certificats à validité courte. Au contraire, je préfère une réduction de leur période de validité plutôt qu’une augmentation de la taille des clefs.
Je ne connais pas HPKP, mais s'il ne permet pas de changer les certificats assez aisément (donc avec une automatisation) et fréquemment, alors pour moi c'est lui qui pose problème.
Non, HPKP prévoit bel et bien le remplacement de certificat. C’est pour ça qu’il est obligatoire d’épingler (au moins) deux clefs dans l’en-tête HPKP, dont une qui ne doit pas être actuellement utilisée. Ça permet les rotations de clefs.
Il est parfaitement possible d’automatiser tout cela, mais les clients de Let’s Encrypt ne le font pas, et c’est bien là le problème. Seuls les « geeks maîtrisant X.509 et assimilés » seront en mesure de le faire eux-même, alors que Let’s Encrypt se targue de mettre le chiffrement à la portée de tous les administrateurs en herbe.
En effet, je ne prendrai jamais le risque de rendre mes sites inaccessibles à cause d'une erreur de manipulation d'administration système (l'erreur est humaine et fréquente).
Publier des en-têtes HSTS et/ou HPKP est effectivement un risque (avec ou sans Let’s Encrypt) : ces en-têtes interdisent aux navigateurs de passer outre les erreurs de sécurité. Il ne faut les publier que si l’on est sûr que sa configuration est correcte (et correcte non seulement aujourd’hui, mais dans le futur).
Je ne suis pas d’accord avec la section « Des paramètres par défaut insuffisant » — une clef RSA de 2048 bits par défaut convient très bien.
J’ai déjà dit récemment qu’une clef RSA de 4096 bits était « disproportionnée » pour un certificat valide deux ans, mais alors pour un certificat valide 90 jours, c’est carrément ridicule.
Il va falloir plus qu’un post de blog pour me convaincre qu’il y a quelque part (sur Terre, hein, pas dans une galaxie lointaine, très lointaine) un attaquant capable de casser une clef RSA de 2048 bits en moins de trois mois…
Pour info, l’ANSSI (qui selon l’auteur « déconseille officiellement » les clefs de 2048 bits) admet en réalité que cette taille de clef est toujours satisfaisante jusqu’en 2030 (p. 17, RègleFact-1).
En revanche, je suis d’accord avec le reste. Notamment, l’interaction de l’automatisation promise par Let’s Encrypt avec les autres mécanismes de sécurité (particulièrement HPKP, et DANE dans une moindre mesure) n’a pas été suffisamment pensée (je serais en fait enclin à dire que ça n’a pas été pensé du tout), de sorte qu’en effet
une mise-en-œuvre correcte de cette solution reste une fois encore uniquement à la portée de geek maîtrisant X.509 et assimilés sur le bout des doigts, la solution officielle se contentant […] de cas d’usage rapidement très limités voire dangereux si l’utilisateur ne se rend pas compte des implications (HPKP)
il faut que le numéro soit sur un site style pages jaunes.
Qui est probablement considéré comme une Qualified Independent Information Source (section 11.11.5 des guidelines, p. 27), soit :
a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that:
① Industries other than the certificate industry rely on the database for accurate location, contact, and other information; and
② The database provider updates its data on at least an annual basis.
_
se reposer sur un site listant un numéro de téléphone sans faire de vérifications, est-ce vraiment valider?
Les CA sont invitées (mais sans obligation, SHALL et non MUST…) à « utiliser un processus documenté pour vérifier la fiabilité » de la QIIS, je ne doute pas un seul instant qu’elles le font ⸮
Bref, à ce que mon identité a été authentifée selon les normes les plus élevées de l'industrie dixit la pub
C’est beau de croire la pub… S’il fallait croire la page que tu cites, les certificats EV « [assurent] ainsi aux utilisateurs que votre site est fiable ».
C’est un mensonge éhonté, comme la section 2.1.3 des guidelines le stipule clairement :
EV Certificates focus only on the identify of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is not [l’emphase est d’origine] intended to provide any assurances, or otherwise represent or warrant […] that it is “safe” [guillemets d’origine…] to do business with the Subject named in the EV Certificate.
C’est d’ailleurs LE gros mensonge de tout le système TLS/X.509 appliqué au web (et la raison pour laquelle j’ai envie de jeter mon café à la face de « Laura du Web » et les autres « journalistes » dans son genre quand ils disent de ne pas donner son numéro de carte bleue avant d’avoir vérifié qu’il y a bien « un piti cadenas dans le bas de votre écran ») : la seule chose que ce système peut garantir (et encore, s’il tenait ses promesses, ce qui n’est pas le cas), c’est que le visiteur est bien sur le site sur lequel il voulait aller et que personne entre lui et le site n’intercepte la communication (c’est seulement ça que veut dire le « piti cadenas »). Mais ce que veut savoir le visiteur est beaucoup plus large que ça : il veut savoir s’il peut se fier au site qu’il a en face de lui, ce qui certes inclut d’être certain de son identité mais pas seulement…
Ou, comme l’illustre très bien Grise Bouille avec l’exemple de Facebook : « Notez que le protocole HTTPS assure seulement le chiffrement des communications : il ne garantit pas du tout que le site visité est digne de confiance ! »
l'avantage c'est de ne pas dépendre d'un logiciel, d'une synchronisation, tu peux y accéder depuis un smartphone sans rien installer de plus
Alors, ça va sans doute en faire hurler plus d’un, mais pour ma part, mes mots de passes les plus importants (tous générés aléatoirement, sans « master secret » commun ou quoi que ce soit dans le genre) sont stockés… sur un bout de papier au format « carte de crédit ».
Je ne dépends d’aucun logiciel pour les retrouver et je peux les utiliser depuis n’importe où sans aucune synchronisation préalable.
Je considère qu’ils sont plus à l’abri dans mon porte-feuille, hors de portée de toute attaque informatique, que sur mon ordinateur connecté à Internet (a fortiori dans un gestionnaire de mots de passe, sachant que les bad guys ont bien compris l’intérêt qu’il y avait à s’attaquer àces outils).
ça n'a pas l'air pire que les revues scientifiques
Marrant que tu dises ça, j’ai toujours pensé que le monde de l’édition scientifique était pourri et n’offrait pas ce qu’on attendait de lui, et maintenant que j’y pense, je me demande si ce n’est pas pour les mêmes raisons qui font que le système PKIX est pourri et n’offre pas ce qu’on attend de lui…
Les autorités de certification prétendent se livrer à des vérifications sérieuses avant de délivrer un certificat. De même, certains éditeurs prétendent faire de la « revue par les pairs » (peer review) alors qu’il est évident à voir certains papiers qu’ils n’ont jamais été relu par quiconque, encore moins un « pair » spécialiste du sujet — sinon comment expliquer qu’on puisse publier des articles ouvertement bidons générés par un pipotron ?
Il n’est pas dans l’intérêt des CA de refuser un certificat à un client. De même, il n’est pas dans l’intérêt des éditeurs de rejeter un papier. Je veux croire que ce n’est pas le cas des éditeurs « sérieux », mais c’est clairement le cas de la tripotée d’éditeurs douteux qui ont vu le jour ces dernières années, qui en surfant sur la vague de l’Open Access acceptent en pratique tout ce qu’on leur soumet (predatory publishers).
Même les plus grosses CAs (Comodo, Verisign, etc.) ne sont pas irréprochables. Même les éditeurs historiques prestigieux n’hésitent pas à fouler le principe de la relecture par les pairs, comme lorsque Nature Publishing a publié l’histoire des « STAP stem cells » contre l’avis des relecteurs pour qui les données expérimentales étaient insuffisantes pour soutenir les conclusions.
Le business des CA ne souffre manifestement pas des différentes révélations montrant qu’elles ne sont pas dignes de confiance. De même, les éditeurs historiques conservent tout leur prestige (demandez à n’importe quel chercheur s’il ne voudrait pas voir son prochain papier publié dans Nature ou Science…), sans être affectés par les cas révélant les faiblesses du système.
Les mécanismes de révocation (CRLs, OCSP) sont largement inopérants. De même, les rétractions d’articles scientifiques passent largement inaperçues, et les papiers rétractés sont encore cités comme si de rien n’était. (Le meilleur exemple — ou le pire, question de point de vue — est probablement celui du papier qui prétendait démontrer un lien entre autisme et vaccination, que les anti-vaccinations continuent de brandir longtemps après que personne n’a pu répliquer les résultats et même après que le caractère frauduleux du papier a été établi.)
but 256-GCM is far, far more desirable than 128-GCM.
Si tu lis le message référencé, tu verras que ce n’est pas une opinion partagée par tout le monde :
On a scale of security AND speed
128-GCM > 128-CBC
128-GCM > 256-CBC
128-GCM ~ 256-GCM
Ou, plus loin dans le même débat :
the difference between AES 128 and 256 isn't "medium-grade" vs "high-grade". it's more like "high-grade and pretty fast" vs "high grade and slow for no reason".
_
Et c'est aussi une question d'image, c'est important l'image technique pour les geeks.
Ça doit dépendre des geeks, mais perso quelqu’un qui joue à qui à la plus grosse avec ses clefs cryptographiques ne me fait pas une bonne impression, ça me renvoie plutôt l’image de quelqu’un qui ne sait pas ce qu’il fait réellement et pousse simplement tous les leviers au maximum parce que c’est forcément mieux — comme ce type que j’ai vu affirmer sans rire qu’il fallait privilégier SHA-512 à SHA-3 sans autre raison que 512 est supérieur à 3…
et un Android 4.4 [prend du AES256] alors que 5.0 passe en 128
Je ne sais pour Android 4.4 précisément, mais
Android 4.1 ne supporte que le mode CBC, en 128- et 256-bits ;
Android 5.0 supporte le mode CBC en 128- et 256-bits, et GCM en 128-bits uniquement (comme Firefox).
Donc, rien d’étonnant encore une fois à ce qu’un Android 4.x choisisse AES256 (il a le choix entre AES128-CBC et AES256-CBC, il prend « le plus gros ») là où un Android 5.x choisira AES128-GCM (le critère déterminant est le mode, non la taille de la clef).
[^] # Re: Déjà des correctifs
Posté par gouttegd . En réponse au journal OpenSSH, UseRoaming no. Évalué à 8.
Si la fuite est dans le client SSH, ceux qui utilisent un agent n’ont a priori pas à craindre pour leurs clefs privées, vu que celles-ci sont dans la mémoire du processus de l’agent et pas dans celle du client proprement dit.
[^] # Re: Contribuer au projet sans GitHub
Posté par gouttegd . En réponse à la dépêche Le retour de la Méthode R.A.C.H.E. Évalué à 4.
Pour des modifs pas trop volumineuses, on peut aussi simplement envoyer un patch par e-mail, même pas besoin d’avoir son propre dépôt public qelque part.
Malheureusement il y a des développeurs « responsables du dépôt principal » qui ne connaissent rien d’autre que GitHub et ne savent rien faire en-dehors…
J’ai déjà envoyé des patchs simplissimes (genre une ligne) à un développeur upstream qui, au lieu de les appliquer directement sur son dépôt, les a importé sur GitHub pour pouvoir créer des « Pull requests » et immédiatement les merger via l’interface de GitHub…
(Non pas que ça me dérange outre mesure, après tout c’est le développeur upstream qui à mon avis se complique inutilement la tâche, pas moi… et à vrai dire je préfère ça plutôt qu’il me renvoie mon patch en me demandant de faire moi-même la pull request sur GitHub.)
[^] # Re: Juste pour compléter la liste
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1.
Est-ce que la sécurité de ton installation dépend du fait que personne ne connaît ou ne peux trouver le nom abcdefghijkl123.mondomaine.com ?
[^] # Re: Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3.
Qu’il ne faille plus utiliser RC4, certes. Mais de là à dire qu’il est cassé au point que la NSA le lit en temps réel, soit on me donne des détails soit j’achète pas, désolé.
Surtout quand juste après le même gars dit « Or to put it another way: academics have said RC4 is broken for years. Listen to them. »
Il y a une grosse marge entre « les chercheurs en cryptographie disent que c’est cassé » et « la NSA le casse en temps réel », ce n’est pas simplement « dire la même chose d’une autre façon ». La première phrase est factuelle, la seconde est pure spéculation. Et comme la première est, à elle seule, suffisante pour justifier le retrait de RC4, le recours à la seconde discrédite complètement le propos.
De manière générale, j’accorde peu de crédit aux discours alarmistes du genre « omg on va tous mourir la NSA peut [insérer ici des allégations dignes des Bruce Schneier facts] ».
Ah, et comme on ne parle que de crypto ici, je crois que c’est le bon endroit/moment pour rappeler que la crypto ne vous sauvera pas (version vidéo). Même s’il n’y a pas d’exemples relatifs à TLS, les multiples cas présentés où la cryptographie a été complètement contournée sans jamais être attaquée de front sont très intéressants.
On rapprochera ça des propos de Snowden sur l’efficacité du chiffrement :
[^] # Re: Implémentation de DANE TLSA dans nos navigateurs ?
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3.
À noter tout de même le travail de Viktor Dukhovni (a.k.a « Monsieur DANE », auteur ou co-auteur d’à peu près tous les RFCs sur DANE, et auteur de l’implémentation correspondante dans Postfix) pour implémenter DANE directement dans OpenSSL, où ça aura un bien plus grand impact (pouvant bénéficier à une tripotée d’applications) que dans un seul navigateur.
[^] # Re: Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 4.
Malheureusement si, pour les mêmes raisons qui font que le downgrade de TLS (toutes versions) à SSl 3.0 est possible.
Sauf encore une fois si le RFC 7507 (le fameux TLS_FALLBACK_SCSV) est implémenté des deux côtés.
(Une rapide recherche ne m’a pas permis de trouver à quel point le support de ce RFC était répandu parmi les navigateurs — et à partir de quelles versions — , juste qu’apparemment Microsoft ne prévoit pas de l’implémenter dans IE : « At this time we de not plan on making this change », et notez que le bug est closed.)
[^] # Re: Implémentation de DANE TLSA dans nos navigateurs ?
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 2.
À mon avis ? Non, en tout cas pas une implémentation « native » (intégrée par défaut de base dans le navigateur). Je ne sais pas pour Firefox, mais les devs de Chrome ont clairement fait savoir que ce n’était pas au programme.
En attendant, il y a toujours ce plugin que je ressors à chaque discussion sur le sujet. Et (attention, auto-promotion éhontée) ma propre implémentation pour Uzbl.
[^] # Re: Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3.
Pas d’accord. La désactivation massive de SSL 3.0 date d’il y a quelques mois (c’est POODLE qui a donné le coup de pied au cul nécessaire), et ça fait bien plus longtemps que ça qu’on savait que SSL 3.0 avait trop de failles.
Firefox et Chrome ont désactivé SSL 3.0 après POODLE non pas parce que c’était la faille de trop, mais parce que c’est avec cette faille qu’ils se sont rendus compte qu’il y avait encore trop de serveurs dans la nature qui offraient sans sourciller du SSL 3.0.
Faible a priori si client et serveur supportent le mécanisme anti-repli (mécanisme qui au passage n’aurait jamais du être nécessaire si serveurs et clients avaient respecté le protocole TLS, au lieu d’adopter le comportement du « ça passe pas en TLS n alors je me fous de la sécurité et je tente en TLS n−1, ah ben là ça passe c’est donc bien que ça devait être une erreur et pas une tentative d’attaque », mais c’est une autre histoire). Après, on n’est jamais à l’abri d’une erreur dans une implémentation (erreur à laquelle tu fermes complètement la porte en ne supportant pas le protocole plus faible en premier lieu).
Note, je ne suis pas en train de dire de ne pas supporter TLS 1.0 (même si idéalement il faudrait). Comme indiqué sur la page du wiki de Mozilla que j’ai cité par ailleurs, c’est à évaluer en fonction du public attendu.
J’aimerais vraiment que tu me trouves un client encore en service (même avec 0.00009% de part de marché) qui ne supporte rien de mieux que les suites EXPORT.
Et contrairement à d’autres technos déjà déconseillées mais contre lesquelles les attaques relèvent encore aujourd’hui de la spéculation (SHA-1 par exemple, on soupçonne fortement que créer des collisions est à la portée d’un adversaire de niveau étatique mais ça n’a pas encore été fait — de même que casser du RSA 1024 bits), il existe des attaques complètement réalistes (et à la portée de quiconque a un peu d’argent à dépenser sur Amazon EC2) contre les suites EXPORT.
Je n’ai pas d’objection à ce qu’on continue à supporter une technologie obsolète après avoir pesé les avantages et les inconvénients, si on estime qu’on peut encore avoir des clients qui en ont besoin.
Le problème, c’est de continuer à supporter une technologie obsolète sans avoir fait cette analyse, juste parce que cette technologie est activée par défaut. Il est à peu près certains que la plupart des administrateurs de sites web ne savaient même pas que leur logiciel serveur offrait par défaut des suites EXPORT (full disclosure : je ne le savais pas non plus).
[^] # Re: Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3.
Ça ouvre la porte à de possibles downgrade attacks, où un client et un serveur qui supporte tous deux une technologie moderne et résistante basculent sans raison sur une techno plus ancienne et potentiellement craquable.
Et il y a aussi le cas des technos tellement anciennes qu’elles ne sont même pas justifiées par le besoin de rester compatible avec les (très) vieux clients, mais que les serveurs supportent toujours simplement parce qu’elles sont activées par défaut et que personne n’a pris la peine de les désactiver. C’est typiquement le cas de toutes les suites EXPORT par exemple. Je pense que c’est surtout à ça que ton interlocuteur faisait référence.
À raison. Il n’y a aucune attaque praticable connue contre 3DES.
[^] # Re: Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3.
Il y a cette page maintenue par Mozilla, qui sans donner directement la récapitulation que tu cherches, indique les plus vieux navigateurs compatibles avec leurs trois configurations recommandées (« moderne / intermédiaire / vieux »).
[^] # Re: Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 2. Dernière modification le 05 janvier 2016 à 08:45.
Tu retardes, le futur n’est plus dans la cryptographie à base de courbes elliptiques, mais dans la cryptographie post-quantique.
La NSA (qui a longtemps été une des principales forces poussant à l’utilisation de la cryptographie ECC via sa « Suite B ») a annoncé l’année dernière qu’elle n’y croyait plus :
(Tout le monde est invité à se joindre aux spéculations sur les vraies motivations de la NSA, plus on est de fous…)
En attendant, ceux qui redoutent sérieusement que les agences en trois lettres puissent casser leurs clefs RSA et/ou leurs groupes DH de 2048 bits devraient, pour être cohérent (hé, il y a un risque que la NSA ait un ordinateur quantique d’ici 2030), se mettre tout de suite à utiliser du McEliece ou assimilé. Des clefs de plusieurs mégaoctets, voilà qui devrait les satisfaire.
[^] # Re: Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3.
J’ai délibérément négligé ce cas-là, en effet, parce qu’à part pour supporter de très vieux navigateurs je ne vois guère de raison de continuer à offrir des suites de chiffrement sans confidentialité persistante.
Toujours pas d’accord sur le caractère fragile. Le vrai problème de LogJam n’est même pas que les serveurs utilisaient des paramètres DH de 1024 bits (même si 1024 bits est en effet un peu trop faible pour être à l’aise), mais surtout que la plupart des serveurs ont utilisé pendant des années (jusqu’à la révélation de l’attaque en fait) les mêmes paramètres DH pour tout le monde (ceux proposés par le RFC 2409), offrant ainsi à énorme jackpot aux grandes oreilles : il leur suffisait de casser un seul groupe DH pour être en mesure de déchiffrer les communications de n’importe quel serveur.
[^] # Re: Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 5.
Ça c’est si les mécanismes de révocation fonctionnaient correctement, ce qui n’est pas le cas.
Les CRLs n’ont jamais vraiment fonctionné, et Chrome et Firefox ne les utilisent même plus.
OCSP pose au moins autant de problèmes qu’il n’en résoud (dont un joli problème de vie privée, en révélant à la CA toute connexion aux sites dont elle a signé le certificat), est souvent désactivé par défaut (notamment sur Chrome), et quand il est activé c’est toujours en mode soft-fail, de sorte qu’il suffit de bloquer la requête (ou la réponse) OCSP pour passer outre la vérification (et si on passe en mode hard-fail c’est encore plus drôle, on peut faire un déni de service sur le site visé en attaquant le serveur OCSP de sa CA).
Reste l’OCSP Stapling (j’aimerais bien des stats sur son utilisation), et les « CRLsets » de Chrome qui ne sauraient être applicables à une grande échelle.
[^] # Re: Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 5.
Si, le risque c’est que la moindre erreur de configuration rende le site inaccessible, parce que le navigateur n’aura pas le droit de passer outre.
Typiquement, un administrateur oublie de renouveller son certificat et le laisse expirer (un des écueils que Let’s Encrypt cherche à éviter en automatisant le plus possible, justement parce qu’on a constaté que ce genre de choses arrivaient trop souvent dans la réalité) :
Sans HSTS, ce n’est pas trop grave, le navigateur va afficher un message d’erreur mais va laisser à l’utilisateur la possibilité de passer outre (« il y a un problème avec le certificat de ce site. Voulez-vous continuer ? » — ce à quoi l’utilisateur répond « un problème avec quoi ? Évidemment que je veux continuer, je veux continuer ma visite moi. »).
Avec HSTS et si l’utilisateur a déjà visité le site préalablement, c’est mort, le navigateur qui respecte le RFC 6797 doit avorter la connexion.
C’est justement le but recherché de HSTS, qui signifie en gros « l’administrateur de ce site ne fait pas d’erreurs, si votre navigateur détecte un problème, c’est qu’il y a réellement quelque chose de louche, ce n’est pas un truc que vous pouvez ignorer en mettant ça sur le compte du laxisme de l’administrateur ».
D’où l’importance de n’utiliser HSTS que si l’on ne fait réellement pas d’erreur…
Ce n’est pas un problème, ça. Si le visiteur revient après la durée d’épinglage, on se replace juste dans le cas initial d’une première connexion. Ça n’interdit pas l’accès au site, c’est juste qu’on n’a pas, pour cette « première » connexion, la protection apportée par HPKP.
Pour info, HSTS a un comportement similaire : lui aussi a une directive "max-age" au-delà de laquelle le navigateur ne doit plus considérer que le site doit être accédé en HTTPS uniquement.
Je préférerais que les systèmes d’exploitations fournissent par défaut un résolveur DNS validant (que non seulement les navigateurs mais aussi toutes les autres applications pourront utiliser) plutôt qu’un « stub resolver ». À ma connaissance, aucun système ne fait ça à l’heure actuelle, celui qui veut un résolveur validant doit l’installer lui-même.
[^] # Re: Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 4.
Pour être honnête, la faute n’incombe pas qu’à Let’s Encrypt. HPKP est encore récent et il n’existe pas, à ma connaissance, d’outils pré-existant pour gérer ça de manière automatisée (à la manière de OpenDNSSEC pour gérer les clefs DNSSEC).
Je prédis que HPKP ne connaîtra pas un grand déploiement tant que de tels outils n’existeront pas, et on ne peut pas mettre ça sur le dos de Let’s Encrypt (même si eux seraient sans doute bien placés pour créer les outils en questions).
[^] # Re: Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 6. Dernière modification le 04 janvier 2016 à 21:32.
Rien à redire là-dessus, je n’ai rien contre des certificats à validité courte. Au contraire, je préfère une réduction de leur période de validité plutôt qu’une augmentation de la taille des clefs.
Non, HPKP prévoit bel et bien le remplacement de certificat. C’est pour ça qu’il est obligatoire d’épingler (au moins) deux clefs dans l’en-tête HPKP, dont une qui ne doit pas être actuellement utilisée. Ça permet les rotations de clefs.
Il est parfaitement possible d’automatiser tout cela, mais les clients de Let’s Encrypt ne le font pas, et c’est bien là le problème. Seuls les « geeks maîtrisant X.509 et assimilés » seront en mesure de le faire eux-même, alors que Let’s Encrypt se targue de mettre le chiffrement à la portée de tous les administrateurs en herbe.
Publier des en-têtes HSTS et/ou HPKP est effectivement un risque (avec ou sans Let’s Encrypt) : ces en-têtes interdisent aux navigateurs de passer outre les erreurs de sécurité. Il ne faut les publier que si l’on est sûr que sa configuration est correcte (et correcte non seulement aujourd’hui, mais dans le futur).
# Let’s Encrypt
Posté par gouttegd . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 10.
Je ne suis pas d’accord avec la section « Des paramètres par défaut insuffisant » — une clef RSA de 2048 bits par défaut convient très bien.
J’ai déjà dit récemment qu’une clef RSA de 4096 bits était « disproportionnée » pour un certificat valide deux ans, mais alors pour un certificat valide 90 jours, c’est carrément ridicule.
Il va falloir plus qu’un post de blog pour me convaincre qu’il y a quelque part (sur Terre, hein, pas dans une galaxie lointaine, très lointaine) un attaquant capable de casser une clef RSA de 2048 bits en moins de trois mois…
Pour info, l’ANSSI (qui selon l’auteur « déconseille officiellement » les clefs de 2048 bits) admet en réalité que cette taille de clef est toujours satisfaisante jusqu’en 2030 (p. 17, RègleFact-1).
En revanche, je suis d’accord avec le reste. Notamment, l’interaction de l’automatisation promise par Let’s Encrypt avec les autres mécanismes de sécurité (particulièrement HPKP, et DANE dans une moindre mesure) n’a pas été suffisamment pensée (je serais en fait enclin à dire que ça n’a pas été pensé du tout), de sorte qu’en effet
[^] # Re: Théorie vs pratique
Posté par gouttegd . En réponse au journal SSL EV, étendue oui, validation euh.... Évalué à 4.
Bien vu, autant pour moi, j’ai confondu avec SHOULD.
Ça me rassure du coup, parce qu’il est évident qu’une CA n’oserait jamais manquer aux obligations du CA/Browser Forum… n’est-ce pas ?
# Théorie vs pratique
Posté par gouttegd . En réponse au journal SSL EV, étendue oui, validation euh.... Évalué à 4. Dernière modification le 30 décembre 2015 à 16:24.
Si tu veux t’amuser, tu peux consulter les guidelines du CA/Browser Forum pour la délivrance des certificats EV (guidelines auxquelles Comodo déclare se conformer dans son Certificate Practice Statement), et comparer avec ton expérience…
Par exemple :
Qui est probablement considéré comme une Qualified Independent Information Source (section 11.11.5 des guidelines, p. 27), soit :
_
Les CA sont invitées (mais sans obligation, SHALL et non MUST…) à « utiliser un processus documenté pour vérifier la fiabilité » de la QIIS, je ne doute pas un seul instant qu’elles le font ⸮
C’est beau de croire la pub… S’il fallait croire la page que tu cites, les certificats EV « [assurent] ainsi aux utilisateurs que votre site est fiable ».
C’est un mensonge éhonté, comme la section 2.1.3 des guidelines le stipule clairement :
C’est d’ailleurs LE gros mensonge de tout le système TLS/X.509 appliqué au web (et la raison pour laquelle j’ai envie de jeter mon café à la face de « Laura du Web » et les autres « journalistes » dans son genre quand ils disent de ne pas donner son numéro de carte bleue avant d’avoir vérifié qu’il y a bien « un piti cadenas dans le bas de votre écran ») : la seule chose que ce système peut garantir (et encore, s’il tenait ses promesses, ce qui n’est pas le cas), c’est que le visiteur est bien sur le site sur lequel il voulait aller et que personne entre lui et le site n’intercepte la communication (c’est seulement ça que veut dire le « piti cadenas »). Mais ce que veut savoir le visiteur est beaucoup plus large que ça : il veut savoir s’il peut se fier au site qu’il a en face de lui, ce qui certes inclut d’être certain de son identité mais pas seulement…
Ou, comme l’illustre très bien Grise Bouille avec l’exemple de Facebook : « Notez que le protocole HTTPS assure seulement le chiffrement des communications : il ne garantit pas du tout que le site visité est digne de confiance ! »
[^] # Re: gné
Posté par gouttegd . En réponse au journal Générateur de mot de passe. Évalué à 1.
Alors, ça va sans doute en faire hurler plus d’un, mais pour ma part, mes mots de passes les plus importants (tous générés aléatoirement, sans « master secret » commun ou quoi que ce soit dans le genre) sont stockés… sur un bout de papier au format « carte de crédit ».
Je ne dépends d’aucun logiciel pour les retrouver et je peux les utiliser depuis n’importe où sans aucune synchronisation préalable.
Je considère qu’ils sont plus à l’abri dans mon porte-feuille, hors de portée de toute attaque informatique, que sur mon ordinateur connecté à Internet (a fortiori dans un gestionnaire de mots de passe, sachant que les bad guys ont bien compris l’intérêt qu’il y avait à s’attaquer à ces outils).
# PKIX et édition scientifique, même combat
Posté par gouttegd . En réponse au journal SSL EV, étendue oui, validation euh.... Évalué à 10.
Marrant que tu dises ça, j’ai toujours pensé que le monde de l’édition scientifique était pourri et n’offrait pas ce qu’on attendait de lui, et maintenant que j’y pense, je me demande si ce n’est pas pour les mêmes raisons qui font que le système PKIX est pourri et n’offre pas ce qu’on attend de lui…
Les autorités de certification prétendent se livrer à des vérifications sérieuses avant de délivrer un certificat. De même, certains éditeurs prétendent faire de la « revue par les pairs » (peer review) alors qu’il est évident à voir certains papiers qu’ils n’ont jamais été relu par quiconque, encore moins un « pair » spécialiste du sujet — sinon comment expliquer qu’on puisse publier des articles ouvertement bidons générés par un pipotron ?
Il n’est pas dans l’intérêt des CA de refuser un certificat à un client. De même, il n’est pas dans l’intérêt des éditeurs de rejeter un papier. Je veux croire que ce n’est pas le cas des éditeurs « sérieux », mais c’est clairement le cas de la tripotée d’éditeurs douteux qui ont vu le jour ces dernières années, qui en surfant sur la vague de l’Open Access acceptent en pratique tout ce qu’on leur soumet (predatory publishers).
Même les plus grosses CAs (Comodo, Verisign, etc.) ne sont pas irréprochables. Même les éditeurs historiques prestigieux n’hésitent pas à fouler le principe de la relecture par les pairs, comme lorsque Nature Publishing a publié l’histoire des « STAP stem cells » contre l’avis des relecteurs pour qui les données expérimentales étaient insuffisantes pour soutenir les conclusions.
Le business des CA ne souffre manifestement pas des différentes révélations montrant qu’elles ne sont pas dignes de confiance. De même, les éditeurs historiques conservent tout leur prestige (demandez à n’importe quel chercheur s’il ne voudrait pas voir son prochain papier publié dans Nature ou Science…), sans être affectés par les cas révélant les faiblesses du système.
Les mécanismes de révocation (CRLs, OCSP) sont largement inopérants. De même, les rétractions d’articles scientifiques passent largement inaperçues, et les papiers rétractés sont encore cités comme si de rien n’était. (Le meilleur exemple — ou le pire, question de point de vue — est probablement celui du papier qui prétendait démontrer un lien entre autisme et vaccination, que les anti-vaccinations continuent de brandir longtemps après que personne n’a pu répliquer les résultats et même après que le caractère frauduleux du papier a été établi.)
[^] # Re: Et c'est joli au moins?
Posté par gouttegd . En réponse au journal SSL EV, étendue oui, validation euh.... Évalué à 5.
Indirectement :
Et c’est bien pour des questions de performance que les développeurs de Chrome ont choisi de ne pas supporter AES256-GCM :
[^] # Re: Et c'est joli au moins?
Posté par gouttegd . En réponse au journal SSL EV, étendue oui, validation euh.... Évalué à 2.
Je sais, mais j’ai testé avec ce que j’avais sous la main. ;)
[^] # Re: Et c'est joli au moins?
Posté par gouttegd . En réponse au journal SSL EV, étendue oui, validation euh.... Évalué à 9.
Si tu lis le message référencé, tu verras que ce n’est pas une opinion partagée par tout le monde :
Ou, plus loin dans le même débat :
_
Ça doit dépendre des geeks, mais perso quelqu’un qui joue à qui à la plus grosse avec ses clefs cryptographiques ne me fait pas une bonne impression, ça me renvoie plutôt l’image de quelqu’un qui ne sait pas ce qu’il fait réellement et pousse simplement tous les leviers au maximum parce que c’est forcément mieux — comme ce type que j’ai vu affirmer sans rire qu’il fallait privilégier SHA-512 à SHA-3 sans autre raison que 512 est supérieur à 3…
[^] # Re: Et c'est joli au moins?
Posté par gouttegd . En réponse au journal SSL EV, étendue oui, validation euh.... Évalué à 3.
Je ne sais pour Android 4.4 précisément, mais
Donc, rien d’étonnant encore une fois à ce qu’un Android 4.x choisisse AES256 (il a le choix entre AES128-CBC et AES256-CBC, il prend « le plus gros ») là où un Android 5.x choisira AES128-GCM (le critère déterminant est le mode, non la taille de la clef).