Oui mais ça n’a aucun intérêt en terme de sécurité.
L’interdiction de vérifier la chaîne de certification fait que n’importe qui peut fournir un certificat contenant un CN ou SAN valide pour le domaine en question (et conduira au mieux à renvoyer en plain/text par derrière si tu fais la vérification du CN/SAN, ce qui est encore pire…).
D'autre part, ma réelle inquiétude est de savoir jusqu'où Google compte aller. Il n'y a qu'un pas à franchir entre afficher une alerte parce que le serveur du correspondant n'utilise pas du tout TLS, et parce qu'il utilise un certificat auto-signé
Sois rassuré sur ce point, Google ne peut tout simplement pas virer les connexions qui utiliseraient un certificat auto-signé. Ils ne peuvent même pas bloquer un certificat qui ne correspondrait pas au domaine en question.
Parce qu’on ne sait pas valider un certificat pour STARTTLS.
Et que les RFC sont très claires (par exemple RFC 7672, on ne doit chercher à vérifier ni la chaîne de certification ni le domaine).
Le domaine tout simplement parce qu’on ne sait pas décider quoi valider.
Comme on passe par les MX, un domaine @xxx.fr peut avoir un MX en yyy.fr.
On s’attend à quoi quand on va lancer la connexion STARTTLS dans le certificat ? xxx.fr ou yyy.fr ?
Se pose aussi le problème (et en particulier pour Google lui-même justement) qu’un même serveur mail peut servir X domaines différents (c’est le cas des serveurs de Google, ils hébergent @lemonde.fr par exemple), et que le certificat présenté peut ne pas être valide pour le domaine du destinataire (si tu écris à @lemonde.fr, tu recevras un certificat en mx.google.com).
Et la chaîne de confiance non plus n’est pas vérifiable. Le RFC 7672 indique bien
SMTP client MTAs cannot be expected to be configured with a suitably complete set of trusted public CA
Ici, c’est surtout parce que SMTP est opportuniste. Si l’établissement de la connexion TLS échoue, l’émetteur retente avec une connexion plain/text.
On a donc intérêt à être le plus laxiste possible et à autoriser tout et n’importe quoi (y compris SSLv2/SSLv3, RC4, DES ou pire, un certificat expiré, de domaine invalide ou de CA inconnue) afin d’obtenir au moins la sécurité du tuyau (la sécurité du destinataire n’est pas possible avec SMTP sans DNSSec et TLSA) plutôt que pas de sécurité du tout.
Google ne peut donc pas se permettre de blacklister un serveur qui aurait un certificat invalide (self-signed ou domaine invalide).
Let’s Encrypt n’a aucun intérêt ici, la chaîne de validation ne peut ni ne doit être vérifié.
Un certificat auto-signé fera parfaitement l’affaire sans diminuer la sécurité, sauf à intégrer DNSSec et DANE/TLSA, mais alors Let’s Encrypt devient un enfer sur Terre, puisque RFC 7672 indique qu’on ne peut pinner que sur le certificat ou sur la clef (CA ou intermédiaire explicitement interdits sur SMTP), qui sont par défaut renouvelés tous les 90j et posent donc de gros problèmes d’intégration avec DNSSec.
Oui et non.
Il te signale qu’il n’a jamais vu ce serveur et demande donc à (re)vérifier la clef.
Tu peux simplifier la vérification (et la rendre indépendante de l’IP) via SSHFP et ton DNS.
Du point de vue réseau, un hidden service n’a même plus d’IP (c’est tout le but de la manœuvre). Donc pas de soucis ni de risque particulier, même sur une connexion avec IP changeante ou redémarrage du client Tor.
(De base SSH n’est de toute façon pas impacté par un changement d’IP)
En gros, on regarde toutes les connexions SSH du monde, et le jour où on veut taper, on cherche l’IP source chez les GAFAM. Si un compte match, bingo, tu connais l’admin sys qui a accès à la machine visée. Plus qu’à aller lui casser les genoux.
L’intérêt de passer par Tor via un Hidden Service est donc d’éviter d’avoir son IP dans la nature, et donc d’être recroisable via X-Key-Score ou équivalent.
Tu te connecte à ce que tu veux - la validation du VPN ce fait après.
La validation du VPN se fait à l’établissement de la connexion.
Tu ne peux pas te connecter à un VPN qui présenterait un certificat invalide pour le domaine auquel tu te connectes.
La plupart des systèmes VPN utilisent un certificat X509 - mais il est rarissime qu'il y ait une architecture PKI derrière.
T’as pas besoin d’une PKI au sens littéral du terme, mais tu as a minima besoin d’une CA qui puisse émettre les certificats clients et serveurs, que l’un et l’autre puisse
De toutes façons la première étape de quasiment tous les VPN est de créer un tunnel puis de faire la validation par ce tunnel.
Totalement faux. Ça serait même du délire au niveau sécurité, puisque tu pourrais te prendre un bon gros MitM dans la tronche sans rien pouvoir détecter.
Si tu veux être en sécurité, tu dois valider AVANT l’établissement du tunnel sécurisé que tu discutes avec la bonne personne.
Tout ce qui se passe dans le tunnel est déjà privé.
Non, pas si tu n’as pas validé AVANT l’établissement du tunnel que tu discutais avec la bonne personne et qu’il n’y avait pas un attaquant sur ta ligne qui pourrait alors lire l’intégralité de tes communications.
J'ai des VPN vers des domaines locaux, à savoir tu te connectes au VPN par IP ou par un DN classique, mais une fois le VPN monté ta carte virtuelle est sur mondomaine.local. Le certificat signe mondomaine.local et c'est le seul certif que le client valide.
Donc ZMAP ne peut rien faire.
Si ton certificat contient mondomaine.local, alors mondomaine.local ne sera pas privé et sera détecté par ZMap.
Cf démonstration précédente, ce certificat leakera bien gentillement au passage de ZMap.
Je n'ai pas du tout cela avec OpenVPN. Comment as-tu ce problème ?
Tu as ce problème avec OpenVPN, puisque tu fournis côté serveur une CA (pour valider le client), une clef privée et un certificat, et au client une CA (pour valider le serveur), une clef privée et un certificat.
À moins que le client ne connaisse pas à l'avance la clef publique du serveur (on à alors la même « sécurité » que le cadenas d'un site web : modifier le DNS permet de tout contrôler).
Le client ne connaît pas à l’avance la clef publique du serveur, c’est même pour ça qu’on lui renseigne une CA qui permettra de garantir que l’émetteur du certificat est bien une personne de confiance.
En ce qui concerne la mitigation d'attaque - tu n'es pas obligé de me croire sur parole (encore heureux) - mais je t'invite à lire les docs que j'ai linké chez CloudFlare qui sont raisonnablement accessibles (Oui parce que les docs sur les systèmes de cryptographie ça devient vite pénible pour le non initié).
Encore une fois, la doc de CloudFlare n’est pas de la mitigation d’attaque, mais de la diminution d’amplification d’attaque.
Ce n’est pas CloudFlare qui est visé directement par le DDOS, mais CloudFlare qui génère le DDOS.
Un attaquant Y souhaitant massacrer un serveur X va envoyer des tonnes de requêtes DNS (via UDP donc) avec un spoof de l’IP source en X.
Si le domaine est signé par DNSSec, alors la requête DNS faite par l’attaquant à un serveur DNSSec de CloudFlare est très courte (par exemple pour le NSEC3 q0da90gqv16l28ro6i5s6ce4ogqe0cp4.imirhil.fr, la question est Type50? q0da90gqv16l28ro6i5s6ce4ogqe0cp4.imirhil.fr. (72) = 58 octets) mais la réponse est TRÈS longue (je vous passe les détails, mais elle fait 1074 octets).
L’IP source étant spoofée (merci UDP), cette réponse ne va pas retournée chez l’attaquant, mais chez l’attaqué !
Du coup, on a un traffic de 58Mbps entre l’attaquant et CloudFlare (une simple ligne fibre classique suffit), mais un trafic entre CloudFlare et l’attaqué de 1.074Gbps (facteur d’amplification de 18) !
Si en plus l’attaquant a le bon goût de contrôler un petit botnet d’une centaine de machines, c’est 100×50Mbps = 5Gbps de traffic qui se transforme en 100×1Gbps = 100Gbps chez l’attaqué… Rideau…
Là je n’ai que ×18 d’amplification, mais on peut monter à ×4000 sans soucis avec les bonnes requêtes DNS qui vont bien et des serveurs résolveurs mal configurés (genre avec le AXFR actif, qui vont transformer « AXFR? imirhil.fr » (17 octets) en le dump intégral de ma zone DNSSec (69885 octets, soit amplification ×4110)) .
Si en plus CloudFlare a le bon goût d’avoir voulu protégé ses propres clients d’un listing de domaine via DNSSec, ce qui impose de resigner à la volée les zones, alors CloudFlare va aussi s’écrouler, puisque les millions de requêtes DNSSec qui vont lui être faites vont littéralement lui faire exploser tous ses CPU, et se faire DDOS par elle-même.
De simple vecteurs d’attaque, CloudFlare devient une victime collatérale du DDOS.
La position de CloudFlare est donc la suivante : si ECDSA était utilisé dans DNSSec, ça diminuerait déjà de beaucoup les amplifications DNS possibles (une signature ECDSA est beaucoup plus courte que RSA), mais en plus si CloudFlare était quand même vecteur malencontreux d’un DDOS, elle ne se DDOSerait pas elle-même à coup de CPU-burn (ECDSA beaucoup plus léger en calcul que RSA).
Ce que CloudFlare dénonce, c’est donc valable pour tout les serveurs DNSSec faisant autorité qui peuvent se retrouver par mégarde vecteur d’amplification d’un DDOS, et tomber eux-même s’ils ont activé les protections contre le domaine listing.
CloudFlare n’est pas plus sécurisé que les autres, puisque ECDSA n’est actuellement pas déployable dans DNSSec, c’est d’ailleurs ce qu’ils aimeraient voir adopter bien plus vite que ce qui n’est actuellement le cas.
Tout ça pour dire que mon serveur peut avoir comme reverse truc.chose.tld, comme nom de domaine accédé par le client waouh.super.net, comme domaine cible (IE une fois la connexion VPN établie) un.deux.test et avoir un certificat avec comme DN : CN=tutu, CN=titi, DC=pipo, DC=root - du moment que le certificat est reconnu par le client comme valide pour le domaine cible ça va passer.
Non justement.
Si ton client se connecte au serveur VPN via waouh.super.net (qui résout via le DNS en X.X.X.X et X.X.X.X qui reverse en truc.muche.org), il faut obligatoirement que le certificat soit valide pour ce nom, donc :
soit qu’il possède un /CN=waouh.super.net (ou au moins *.super.net)
soit qu’il possède un SubjectAltName DNS:waouh.super.net (ou au moins *.super.net)
soit qu’il possède un SubjectAltName IP:X.X.X.X
Tout aute valeur de CN ou de SubjectAltName ne validerait pas la connexion.
(/CN=X.X.X.X ne serait pas valide puisque le matching est fait en comparant strictement avec le nom saisi par l’utilisateur, ici waouh.super.net)
La plupart du temps/sur les configs VPN classiques, c’est /CN=waouh.super.net (moins couramment avec en plus SubjectAltName=DNS:waouh.super.net), et donc le domaine waouh.super.net ne peut pas rester caché (même avec un reverse IP qui donne autre chose) et sera détecté par ZMap (scan de la plage IP, passage sur X.X.X.X, récupération du certificat présenté, obtention du CN ou SubjectAltName).
À noter que la CA émmettrice n’a aucun impact ici, ZMap ne cherchera pas à vérifier la validité réelle du certificat et donc en auto-signé, en signé par une root CA connue ou par une root CA interne, le domaine de connexion du VPN leakera dans tous les cas.
GNI ??? Déjà de quel type de VPN tu parles ? OpenVPN ? IPSec (et lequel ?) L2TP ? PPTP ? Parce que ces différents systèmes VPN ne nécessitent pas franchement de certificats avec correspondances des noms - en fait ils ne nécessitent même pas de nom résolus au niveau DNS - en IP pure ça passe. Du moment que tu valider le certificat
OpenVPN et IPSec, c’est basé sur X.509, donc ça contient forcément un Subject(Alt)Name dans le certificat sauf à ce que les clients s’y connectent via l’IP directement dans leur client VPN. Si le subject(alt)name ne matche pas le TEXTE saisi par le client (et non pas sa résolution ni même son existence DNS ou reverse), alors le certificat est invalide (on peut aussi insérer des IP:X.X.X.X dans le certificat, mais c’est assez très rare).
L2TP et PPTP, je connais moins, mais en tout cas L2TP utilise aussi apparament X.509.
Les VPN « corrects » ne font pas de reverse, ou du moins pas obligatoirement.
Je ne te parle pas du reverse (DNS) mais du fait que le certificat (X.509) que va présenter le serveur VPN doit obligatoirement correspondre au domaine que le client a saisi dans son client VPN.
Sinon le certificat présenté est invalide et sera rejeté par le client (OpenVPN par exemple).
Et donc le certificat servit par le serveur X.X.X.X doit forcément contenir le nom de domaine private.example.org si c’est celui-ci qui est utilisé par les clients, que X.X.X.X ait pour reverse DNS private.example.org ou duchmol.foo.bar.
Et donc quand zmap va zmapiser tout IPv4, il tombera sur X.X.X.X, lui demandera bien gentiment son certificat en simulant une connexion OpenVPN, regardera le contenu du champ SubjectName ou SubjectAlternativeName et en déduira que c’est un VPN pour la boîte possédant le domaine example.org ainsi que la présence du champ DNS private.example.org, qui ne sera donc plus du tout privé..
A moins d'essayer en force brute toutes les possibilités d'entrées DNS, ZMAP n'a aucune chance de tomber sur abcdefghijkl123.mondomaine.com si celui ci n'est pas référencé ailleurs que sur les DNS.
Faux.
Si ce domaine héberge un VPN, il devrait obligatoirement présenté un certificat contenant abcdefghijkl123.mondomaine.com, sous peine de casser l’authentification côté client.
Et donc se fera dégommer par ZMap.
Si ce domaine héberge du HTTPS, bien que ça ne soit pas obligatoire, il y a de forte chance d’y trouver aussi un certificat avec le nom réel de la machine en SubjectName et la liste de tous les domaines servis en SubjectAltName, ne serait-ce que pour éviter une erreur flippante si un client se connecte directement dessus. C’est par exemple le cas chez CloudFlare.
A noter cependant qu'il ne s'agit pas de "mon" installation. Si je devais faire du DNSSEC, je le ferai très probablement via CloudFlare aujourd'hui. Principalement parce qu’ils ont réussi a encaisser de grosses attaques sur DNSSEC sans s'effondrer.
Non, ils indiquent juste qu’effectivement avec de la puissance de frappe on peut énumérer les domaines d’un serveur, et que ECDSA permettrait de minimiser la taille des réponses donc les facteurs d’amplification si ton résolveur DNS sert de vecteur d’attaque DDOS (et non s’il est la cible finale).
Donc ça sera strictement la même chose si tu avais ton propre serveur DNSSec autorité (qui plus est non résolveur pour ne pas pouvoir servir de vecteur d’attaque).
Ben si, tu le sais.
Si ça répond un truc, c’est que c’est utilisé.
Si ça te donne des certificats qui sont tenus à jour, c’est que c’est utilisé.
Et avec les noms contenus dans les certificats, tu sais parfaitement qui utilise telle IP.
C’est encore plus flagrant avec le VPN, qui à l’inverse de HTTPS ne supporte pas de SNI donc possède nécessairement une info utile sur le nom de domaine dans le certificat X.509 présenté (si tu scannes X.X.X.X et que tu tombes sur un VPN, tu regardes le nom de domaine du certificat présenté, tu en déduis le nom de domaine utilisé par les clients pour se connecter, 99% de chance que ça soit un nom de domaine parlant et sur un sous-domaine du client final).
Ben vas-y scanne tout internet, fait un reverse lookup de toutes les IP et fait la corrélation. Je ne pense pas qu'il existe de machine capable de faire ce que tu proposes. Surtout qu'en plus il n'y a qu'un seul reverse par IP alors qu'il peut y avoir plusieurs noms de domaine.
Benjamin Sonntag a réussi à construire une liste contenant le tiers des noms de domaine en .fr en se basant sur des outils de ce type.
Donc en gros, ta protection par l’obscurité, t’as un taux de perte de 33% de base avec des outils débiles. En étant plus intelligent, on doit pouvoir monter au minimum à 50%.
Étant donné qu’il est très simple et très rapide de scanner toute la plage IP (cf ZMap et son utilisation la plus efficace, Shodan), avoir un DNS obscurci ne sert à rien : on trouvera facilement quel serveur (= IP) héberge un VPN, au mieux on aura scanné toute ta plage de port, au pire tout l’Internet :P
Et on te répond que non, car ça implique le bon fonctionnement de l'interface chaise-clavier, et tout le monde sauf Aeris sait que cette interface merde un max.
Et ça merde un max des 2 côtés.
Mais en tout cas, cliqueter sur un lien vers Firefox portable, dézipper l’archive, lancer, ça sera toujours over moins compliqué qu’aller migrer une Debian old-old-old-stable en stable ou un Windows serveur 2003 en 2010.
Je n’ai jamais dis que ça sera fait, à quelle vitesse ni avec quel pourcentage de réussite.
Mais la maj du client est possible et la procédure pour en obtenir un fiable est connu, documenté et déroulable, reproductible et généralisable, alors que celle d’un serveur, non.
Abstraction faite du pur problème humain, tu sais obtenir un Firefox à jour avec ALL d’activé avec une facilité X, alors que tu ne sais pas obtenir un serveur à jour avec ALL d’activé avec une facilité globale < X.
Donc tes arguments militent toujours pour le contraire de ta conclusion, quand on prend en compte un facteur que tu oublie (l'humain qui veut et l'humain qui a le pognon)
Peu importe le reste des arguments, le simple fait que le contrôle par le serveur fait que tu es seul responsable de la sécurité des données de tes visiteurs prime par dessus tout. Tu n’as pas et ne peux pas déléguer cette responsabilité à what-mille entités tierces.
(Sérieusement, il faut vraiment expliquer pourquoi des IE/XP sont toujours dans la nature?)
Parce que les utilisateurs sont justement des brelles en sécu informatique (voire en informatique tout court ?)
Ha, excuse-moi, en fait tu descends ton propre argument tout seul. Pas besoin des autres!
Ca ne te fait pas bizarre de dire une chose et son contraire dans la même phrase?
J’ai dis que c’était facile de mettre à jour un nav’ comparé à un serveur.
On a une porte de sortie possible pour proposer une mise-à-jour safe des navigateurs de nos visiteurs (Firefox portable), ça ne signifie pas que ça sera fait dès le lendemain de la découverte d’une faille, ni que ça sera fait tout court.
On n’a aucune porte de sortie identifiée pour les serveurs, c’est du cas par cas à chaque fois et sans recette magique possible.
Non (perte d'utilisateurs, et les utilisateurs ont le pognon).
Mais… En fait, pourquoi on pourrait pas? Si les serveurs perdent de l'argent faute de visiteurs, ils vont vite migrer. Ca ne tient pas!
Non, ils ne vont pas vite migrer. J’ai dis que c’était facile, pas que c’était rapide.
Parce qu’il y a suffisamment de lobby pour que ces modifs soient faites beaucoup trop longtemps après la bataille.
On l’a vu pour SSLv3, pour SHA-1, pour RC4, pour 3DES. Et je promet déjà une sacrée longue traîne avant l’exclusion des suites RSA au profit des suites ECC, et pire, la désactivation de TLSv1.2 après l’intégration de TLSv1.3.
Ça demande des palabres infinis pour que les navs se mettent d’accord de qui intègre quoi. Et ça ne fonctionne pas, la preuve chaque navigateur a une liste de choses supportées différente de celles des voisins…
Et des suites restrictives côté serveur, c’est remettre le problème de la compatibilité dans la boucle (tu ne maîtrise pas la configuration des navigateurs autre que le tient et ne peut garantir qu’il supporte les mêmes ciphers que toi, donc un serveur ne peut pas se limiter aux mêmes ciphers que toi non plus).
Si justement. Je peux garantir que je n’aurais pas de problème de config en instaurant ALL sur tous les navigateurs.
Et je contrôle au moins MES données qui circulent sur MON serveur, ce que je ne peux pas faire avec un ALL côté serveur et une suite restrictive sur le client puisque je suis alors dépendant du bon vouloir de Google, Mozilla et Microsoft pour mettre à l’abri mes visiteurs.
La grosse différence est surtout là pour le choix client-first ou serveur-first : je suis légalement responsable de la sécurité de mes utilisateurs, je n’ai donc pas à subir des décisions externes (les suites dans les navigateurs) pour les mettre à l’abri.
RC4 = downgrade attack possible, chiffrement équivalent 0 bits pour la NSA si c’est le cas = F
Encore une fois avec un Firefox récent, je ne peux pas me faire downgrader en SSLv3 ou RC4
Et avec tout le reste ? IE6 sous XP ? OpenSSL par défaut ? curl ? wget ? Java ? Mustard ou Twidere ?
Et environ 99% des user-agent qui traînent dans le coin. Ah oups, c’est pas désactivé là bas…
Raison de plus de laisser les serveurs comme ça (ceux qui acceptent RC4 et AES) et taper sur les navigateurs, plus faciles à mettre à jour (ton argument) en désactivant RC4.
Parce que les gens s’en foutent. C’est BEAUCOUP plus simple de maj un navigateur qu’un serveur et il existe au moins des recettes miracles pour y arriver (au Firefox portable), mais ce n’est pas fait régulièrement parce que les gens ne connaissent pas l’hygiène de base de l’informatique (si tu en es encore à utiliser IE6 sous XP alors que tu pourrais utiliser Firefox sécurisé sous XP…).
Donc on arrête d’attendre des maj de nav, on les laisse avec tout d’activer par défaut et on ne s’emmerde plus. Un admin qui prend soin de sa sécu pourra enfin faire les choses proprement sans se préoccuper d’activer ou non des suites faillibles pour faire plaisir à tel ou tel navigateur et pourra corriger rapidement son serveur en cas de faille de sécu sans avoir à attendre la maj divine du navigateur qui va traîner des pieds. Un admin qui ne prend pas soin de sa sécu continuera à dégeuler la vie privée de ses utilisateurs.
il est maintenant de la responsabilité du navigateur si il accepte une connexion SSLv3 et DES.
Non, puisque SSLv3 et 3DES est désactivé sur mon serveur.
C’est l’intérêt du serveur-first : tu maîtrises ce qui se passe chez toi, quelque soit ce qui se présente en face.
Et comme indiqué plus haut, je ne trouverais pas du tout anormal qu’un client se mette à supporter tout et n’importe quoi. On aurait BEAUCOUP MOINS d’emmerde pour migrer nos serveurs et plus de question à se poser si ça sera compatible ou non avec nos config. On pourra patcher nos failles de sécu sans attendre que Duchmol-browser ou Tartampion-user-agent ait activé les mêmes suites que nous…
Tu n'as pas démontré que c'est mieux côté serveur que navigateur (et honnêtement, quand on lis ton argumentaire, on en déduit plutôt même le contraire de ta conclusion : tes arguments, une conclusion inverse complètement).
Si, cf la démo quelque part dans ce topic.
Le matos pourri côté serveur, on ne pourra jamais s’en passer, encore moins rapidement.
Et des suites restrictives côté client, c’est remettre le problème de la compatibilité dans la boucle (tu ne maîtrise pas la configuration des serveurs autre que le tient et ne peut garantir qu’il supporte les mêmes ciphers que toi, donc un navigateur ne peut pas se limiter aux mêmes ciphers que toi non plus).
La seule config qui mettrait fin au bordel ambiant et permettrait à tous de faire les maj de sécu sans se prendre la tête de savoir qui on va dégager ou pas du parc, c’est « ALL » sur les clients et « une unique suite secure de ton choix » sur les serveurs. En cas de pépin, les admins peuvent migrer quand ils voudront, sans avoir besoin de synchroniser quoi que ce soit et en étant assuré que leurs clients continueront à voir leur site en version pourrie ou en version sécurisée par la suite. Et de ton point de vue, tu peux assurer la sécurité de tes clients dès publication de la faille de sécurité si tu en as envie.
Si tu fais l’inverse, ie des clients restrictifs, à chaque pépin de sécu, tu retombes dans le bordel de la compat. Il faut déjà prendre une décision collégial pour se mettre d’accord sur les nouvelles suites à implémenter dans tous les navigateurs. Puis attendre que suffisamment de clients se soient mis à jour pour faire la bascule côté serveur et virer l’ancienne suite (et exclure de facto tous visiteurs pas à jour).
Ou alors tu actives toutes les suites côté serveur, et une suite unique côté client. Mais alors tu ne maîtrises ni ne peut assurer la sécurité de tes propres utilisateurs, qui s’ils ne sont pas à jour, utiliseront potentiellement des suites pourries avec ton service.
Bref, dans le 1er cas, c’est toi qui est maître de la sécurité de tes visiteurs, dans le 2nd cas non.
Rhaa. Mais tu lis un peu avant de balancer des affirmations péremptoires ?
Oui. Les chiffres que tu avances viennent de Firefox et de Chromium, pas des banques elles-mêmes.
Elles, elles refusent de virer RC4 et 3DES au titre qu’encore trop de leurs clients (chiffres avancés entre 1 et 4%) qui sont sur des trucs pas compatibles autre chose (vieux Android, IE6 sous Windows XP et IE8 sous Windows Vista), et aussi une grosse partie de leur infra bancaire pas compatible (typiquement les DAB sous Windows XP donc ne supportant guère plus que SSLv3 parfois).
Elles ont aussi du matos de terminaison TLS qui ne supportent pas mieux (toujours pas de PFS sur les F5 10.x par exemple ou de TLS > 1.0 sur les F5 9.X), faute de pouvoir être upgrader (problème du chiffrement hardware) ou d’avoir les moyens (il faut racheter des licences) et le temps de le faire.
Responsabilité du navigateur
Tout ce que tu dis s'applique indifféremment au serveur ou navigateur, mais tu accuses l'un et pas l'autre.
Cf ma démonstration ailleurs dans le topic, mais il faut justement que la responsabilité ne soit que d’un seul côté si on veut éviter la spirale infernale sécurité = incompatibilité et incompatibilité = pas de sécurité.
Et du coup elle ne peut être que côté serveur si on veut éviter les downgrade attack tout en ayant une bonne compatibilité.
[^] # Re: Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 1. Dernière modification le 15 février 2016 à 11:29.
Oui mais ça n’a aucun intérêt en terme de sécurité.
L’interdiction de vérifier la chaîne de certification fait que n’importe qui peut fournir un certificat contenant un CN ou SAN valide pour le domaine en question (et conduira au mieux à renvoyer en plain/text par derrière si tu fais la vérification du CN/SAN, ce qui est encore pire…).
# Google ne peut pas exclure les self-signed
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 8. Dernière modification le 15 février 2016 à 00:03.
Sois rassuré sur ce point, Google ne peut tout simplement pas virer les connexions qui utiliseraient un certificat auto-signé. Ils ne peuvent même pas bloquer un certificat qui ne correspondrait pas au domaine en question.
Parce qu’on ne sait pas valider un certificat pour STARTTLS.
Et que les RFC sont très claires (par exemple RFC 7672, on ne doit chercher à vérifier ni la chaîne de certification ni le domaine).
Le domaine tout simplement parce qu’on ne sait pas décider quoi valider.
Comme on passe par les MX, un domaine @xxx.fr peut avoir un MX en yyy.fr.
On s’attend à quoi quand on va lancer la connexion STARTTLS dans le certificat ? xxx.fr ou yyy.fr ?
Se pose aussi le problème (et en particulier pour Google lui-même justement) qu’un même serveur mail peut servir X domaines différents (c’est le cas des serveurs de Google, ils hébergent @lemonde.fr par exemple), et que le certificat présenté peut ne pas être valide pour le domaine du destinataire (si tu écris à @lemonde.fr, tu recevras un certificat en mx.google.com).
Et la chaîne de confiance non plus n’est pas vérifiable. Le RFC 7672 indique bien
Ici, c’est surtout parce que SMTP est opportuniste. Si l’établissement de la connexion TLS échoue, l’émetteur retente avec une connexion plain/text.
On a donc intérêt à être le plus laxiste possible et à autoriser tout et n’importe quoi (y compris SSLv2/SSLv3, RC4, DES ou pire, un certificat expiré, de domaine invalide ou de CA inconnue) afin d’obtenir au moins la sécurité du tuyau (la sécurité du destinataire n’est pas possible avec SMTP sans DNSSec et TLSA) plutôt que pas de sécurité du tout.
Google ne peut donc pas se permettre de blacklister un serveur qui aurait un certificat invalide (self-signed ou domaine invalide).
Let’s Encrypt n’a aucun intérêt ici, la chaîne de validation ne peut ni ne doit être vérifié.
Un certificat auto-signé fera parfaitement l’affaire sans diminuer la sécurité, sauf à intégrer DNSSec et DANE/TLSA, mais alors Let’s Encrypt devient un enfer sur Terre, puisque RFC 7672 indique qu’on ne peut pinner que sur le certificat ou sur la clef (CA ou intermédiaire explicitement interdits sur SMTP), qui sont par défaut renouvelés tous les 90j et posent donc de gros problèmes d’intégration avec DNSSec.
[^] # Re: quid de la verification de l'identité
Posté par Aeris (site web personnel) . En réponse au message Exposer SSH via un service tor, bonne ou mauvaise idée ?. Évalué à 1.
Oui et non.
Il te signale qu’il n’a jamais vu ce serveur et demande donc à (re)vérifier la clef.
Tu peux simplifier la vérification (et la rendre indépendante de l’IP) via SSHFP et ton DNS.
[^] # Re: quid de la verification de l'identité
Posté par Aeris (site web personnel) . En réponse au message Exposer SSH via un service tor, bonne ou mauvaise idée ?. Évalué à 3.
Du point de vue réseau, un hidden service n’a même plus d’IP (c’est tout le but de la manœuvre). Donc pas de soucis ni de risque particulier, même sur une connexion avec IP changeante ou redémarrage du client Tor.
(De base SSH n’est de toute façon pas impacté par un changement d’IP)
# I Hunt Sys Admins
Posté par Aeris (site web personnel) . En réponse au message Exposer SSH via un service tor, bonne ou mauvaise idée ?. Évalué à 3. Dernière modification le 03 février 2016 à 12:07.
Programme I Hunt Sys Admin de la NSA : https://theintercept.com/document/2014/03/20/hunt-sys-admins/
En gros, on regarde toutes les connexions SSH du monde, et le jour où on veut taper, on cherche l’IP source chez les GAFAM. Si un compte match, bingo, tu connais l’admin sys qui a accès à la machine visée. Plus qu’à aller lui casser les genoux.
L’intérêt de passer par Tor via un Hidden Service est donc d’éviter d’avoir son IP dans la nature, et donc d’être recroisable via X-Key-Score ou équivalent.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 0.
La validation du VPN se fait à l’établissement de la connexion.
Tu ne peux pas te connecter à un VPN qui présenterait un certificat invalide pour le domaine auquel tu te connectes.
T’as pas besoin d’une PKI au sens littéral du terme, mais tu as a minima besoin d’une CA qui puisse émettre les certificats clients et serveurs, que l’un et l’autre puisse
Totalement faux. Ça serait même du délire au niveau sécurité, puisque tu pourrais te prendre un bon gros MitM dans la tronche sans rien pouvoir détecter.
Si tu veux être en sécurité, tu dois valider AVANT l’établissement du tunnel sécurisé que tu discutes avec la bonne personne.
Non, pas si tu n’as pas validé AVANT l’établissement du tunnel que tu discutais avec la bonne personne et qu’il n’y avait pas un attaquant sur ta ligne qui pourrait alors lire l’intégralité de tes communications.
Si ton certificat contient mondomaine.local, alors mondomaine.local ne sera pas privé et sera détecté par ZMap.
Cf démonstration précédente, ce certificat leakera bien gentillement au passage de ZMap.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 0.
Tu as ce problème avec OpenVPN, puisque tu fournis côté serveur une CA (pour valider le client), une clef privée et un certificat, et au client une CA (pour valider le serveur), une clef privée et un certificat.
Le client ne connaît pas à l’avance la clef publique du serveur, c’est même pour ça qu’on lui renseigne une CA qui permettra de garantir que l’émetteur du certificat est bien une personne de confiance.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1.
Encore une fois, la doc de CloudFlare n’est pas de la mitigation d’attaque, mais de la diminution d’amplification d’attaque.
Ce n’est pas CloudFlare qui est visé directement par le DDOS, mais CloudFlare qui génère le DDOS.
Un attaquant Y souhaitant massacrer un serveur X va envoyer des tonnes de requêtes DNS (via UDP donc) avec un spoof de l’IP source en X.
Si le domaine est signé par DNSSec, alors la requête DNS faite par l’attaquant à un serveur DNSSec de CloudFlare est très courte (par exemple pour le NSEC3 q0da90gqv16l28ro6i5s6ce4ogqe0cp4.imirhil.fr, la question est
Type50? q0da90gqv16l28ro6i5s6ce4ogqe0cp4.imirhil.fr. (72)= 58 octets) mais la réponse est TRÈS longue (je vous passe les détails, mais elle fait 1074 octets).L’IP source étant spoofée (merci UDP), cette réponse ne va pas retournée chez l’attaquant, mais chez l’attaqué !
Du coup, on a un traffic de 58Mbps entre l’attaquant et CloudFlare (une simple ligne fibre classique suffit), mais un trafic entre CloudFlare et l’attaqué de 1.074Gbps (facteur d’amplification de 18) !
Si en plus l’attaquant a le bon goût de contrôler un petit botnet d’une centaine de machines, c’est 100×50Mbps = 5Gbps de traffic qui se transforme en 100×1Gbps = 100Gbps chez l’attaqué… Rideau…
Là je n’ai que ×18 d’amplification, mais on peut monter à ×4000 sans soucis avec les bonnes requêtes DNS qui vont bien et des serveurs résolveurs mal configurés (genre avec le AXFR actif, qui vont transformer « AXFR? imirhil.fr » (17 octets) en le dump intégral de ma zone DNSSec (69885 octets, soit amplification ×4110)) .
Si en plus CloudFlare a le bon goût d’avoir voulu protégé ses propres clients d’un listing de domaine via DNSSec, ce qui impose de resigner à la volée les zones, alors CloudFlare va aussi s’écrouler, puisque les millions de requêtes DNSSec qui vont lui être faites vont littéralement lui faire exploser tous ses CPU, et se faire DDOS par elle-même.
De simple vecteurs d’attaque, CloudFlare devient une victime collatérale du DDOS.
La position de CloudFlare est donc la suivante : si ECDSA était utilisé dans DNSSec, ça diminuerait déjà de beaucoup les amplifications DNS possibles (une signature ECDSA est beaucoup plus courte que RSA), mais en plus si CloudFlare était quand même vecteur malencontreux d’un DDOS, elle ne se DDOSerait pas elle-même à coup de CPU-burn (ECDSA beaucoup plus léger en calcul que RSA).
Ce que CloudFlare dénonce, c’est donc valable pour tout les serveurs DNSSec faisant autorité qui peuvent se retrouver par mégarde vecteur d’amplification d’un DDOS, et tomber eux-même s’ils ont activé les protections contre le domaine listing.
CloudFlare n’est pas plus sécurisé que les autres, puisque ECDSA n’est actuellement pas déployable dans DNSSec, c’est d’ailleurs ce qu’ils aimeraient voir adopter bien plus vite que ce qui n’est actuellement le cas.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 0. Dernière modification le 11 janvier 2016 à 23:54.
Non justement.
Si ton client se connecte au serveur VPN via waouh.super.net (qui résout via le DNS en X.X.X.X et X.X.X.X qui reverse en truc.muche.org), il faut obligatoirement que le certificat soit valide pour ce nom, donc :
Tout aute valeur de CN ou de SubjectAltName ne validerait pas la connexion.
(/CN=X.X.X.X ne serait pas valide puisque le matching est fait en comparant strictement avec le nom saisi par l’utilisateur, ici waouh.super.net)
La plupart du temps/sur les configs VPN classiques, c’est /CN=waouh.super.net (moins couramment avec en plus SubjectAltName=DNS:waouh.super.net), et donc le domaine waouh.super.net ne peut pas rester caché (même avec un reverse IP qui donne autre chose) et sera détecté par ZMap (scan de la plage IP, passage sur X.X.X.X, récupération du certificat présenté, obtention du CN ou SubjectAltName).
À noter que la CA émmettrice n’a aucun impact ici, ZMap ne cherchera pas à vérifier la validité réelle du certificat et donc en auto-signé, en signé par une root CA connue ou par une root CA interne, le domaine de connexion du VPN leakera dans tous les cas.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1.
OpenVPN et IPSec, c’est basé sur X.509, donc ça contient forcément un Subject(Alt)Name dans le certificat sauf à ce que les clients s’y connectent via l’IP directement dans leur client VPN. Si le subject(alt)name ne matche pas le TEXTE saisi par le client (et non pas sa résolution ni même son existence DNS ou reverse), alors le certificat est invalide (on peut aussi insérer des IP:X.X.X.X dans le certificat, mais c’est assez très rare).
L2TP et PPTP, je connais moins, mais en tout cas L2TP utilise aussi apparament X.509.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 2.
Je ne te parle pas du reverse (DNS) mais du fait que le certificat (X.509) que va présenter le serveur VPN doit obligatoirement correspondre au domaine que le client a saisi dans son client VPN.
Sinon le certificat présenté est invalide et sera rejeté par le client (OpenVPN par exemple).
Et donc le certificat servit par le serveur X.X.X.X doit forcément contenir le nom de domaine private.example.org si c’est celui-ci qui est utilisé par les clients, que X.X.X.X ait pour reverse DNS private.example.org ou duchmol.foo.bar.
Et donc quand zmap va zmapiser tout IPv4, il tombera sur X.X.X.X, lui demandera bien gentiment son certificat en simulant une connexion OpenVPN, regardera le contenu du champ SubjectName ou SubjectAlternativeName et en déduira que c’est un VPN pour la boîte possédant le domaine example.org ainsi que la présence du champ DNS private.example.org, qui ne sera donc plus du tout privé..
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 0. Dernière modification le 11 janvier 2016 à 17:43.
Faux.
Si ce domaine héberge un VPN, il devrait obligatoirement présenté un certificat contenant abcdefghijkl123.mondomaine.com, sous peine de casser l’authentification côté client.
Et donc se fera dégommer par ZMap.
Si ce domaine héberge du HTTPS, bien que ça ne soit pas obligatoire, il y a de forte chance d’y trouver aussi un certificat avec le nom réel de la machine en SubjectName et la liste de tous les domaines servis en SubjectAltName, ne serait-ce que pour éviter une erreur flippante si un client se connecte directement dessus. C’est par exemple le cas chez CloudFlare.
SubjectName = CN=ssl277212.cloudflaressl.com
SubjectAltName =
DNS:ssl277212.cloudflaressl.com, DNS:.anglospizza.com, DNS:.bouncyballs.org, DNS:.bursleyburslem.com, DNS:.businessownersideacafe.com, DNS:.coordinatescollection.com.au, DNS:.daanindianfoodonline.com, DNS:.delhi2go-online.co.uk, DNS:.elearnapp.com, DNS:.ellieclothing.com, DNS:.flamesnewcastle.co.uk, DNS:.indianatakeaway.com, DNS:.korben.info, DNS:.lighthousebanff.com, DNS:.mamamia-crewe.com, DNS:.marinosonline.co.uk, DNS:.no1chinesetakeawaykirkcaldy.co.uk, DNS:.p2pchange.is, DNS:.pizza-parlour.co.uk, DNS:.pizzaworld-basingstoke.com, DNS:.predictableprofits.com, DNS:.ricekungfuonline.co.uk, DNS:.rootofspice.com, DNS:.seriesblog.tv, DNS:.thegreenroomjazzcafeonline.co.uk, DNS:.tulipwokonline.com, DNS:.warungbumbuonline.co.uk, DNS:anglospizza.com, DNS:bouncyballs.org, DNS:bursleyburslem.com, DNS:businessownersideacafe.com, DNS:coordinatescollection.com.au, DNS:daanindianfoodonline.com, DNS:delhi2go-online.co.uk, DNS:elearnapp.com, DNS:ellieclothing.com, DNS:flamesnewcastle.co.uk, DNS:indianatakeaway.com, DNS:korben.info, DNS:lighthousebanff.com, DNS:mamamia-crewe.com, DNS:marinosonline.co.uk, DNS:no1chinesetakeawaykirkcaldy.co.uk, DNS:p2pchange.is, DNS:pizza-parlour.co.uk, DNS:pizzaworld-basingstoke.com, DNS:predictableprofits.com, DNS:ricekungfuonline.co.uk, DNS:rootofspice.com, DNS:seriesblog.tv, DNS:thegreenroomjazzcafeonline.co.uk, DNS:tulipwokonline.com, DNS:warungbumbuonline.co.uk
Non, ils indiquent juste qu’effectivement avec de la puissance de frappe on peut énumérer les domaines d’un serveur, et que ECDSA permettrait de minimiser la taille des réponses donc les facteurs d’amplification si ton résolveur DNS sert de vecteur d’attaque DDOS (et non s’il est la cible finale).
Donc ça sera strictement la même chose si tu avais ton propre serveur DNSSec autorité (qui plus est non résolveur pour ne pas pouvoir servir de vecteur d’attaque).
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1.
Ben si, tu le sais.
Si ça répond un truc, c’est que c’est utilisé.
Si ça te donne des certificats qui sont tenus à jour, c’est que c’est utilisé.
Et avec les noms contenus dans les certificats, tu sais parfaitement qui utilise telle IP.
C’est encore plus flagrant avec le VPN, qui à l’inverse de HTTPS ne supporte pas de SNI donc possède nécessairement une info utile sur le nom de domaine dans le certificat X.509 présenté (si tu scannes X.X.X.X et que tu tombes sur un VPN, tu regardes le nom de domaine du certificat présenté, tu en déduis le nom de domaine utilisé par les clients pour se connecter, 99% de chance que ça soit un nom de domaine parlant et sur un sous-domaine du client final).
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3. Dernière modification le 10 janvier 2016 à 17:29.
C’est exactement ce que permet ZMap. Et la plage IPv4 est scannée intégralement chaque jour, par exemple pour mesurer les handshakes TLS, les bannières SMTP, POP3, IMAPS, les noms inclus dans les certificats, les réponses AXFR DNS, les reverses DNS associés, le tout qui reboucle sur lui-même pour faire un reverse DNS sur l’intégralité de toutes les IP ou noms de domaine qui auraient pu être trouvé (Project Sonar includes a regular DNS lookup for all names gathered from the other scan types, such as HTTP data, SSL Certificate names, reverse DNS records, etc).
Benjamin Sonntag a réussi à construire une liste contenant le tiers des noms de domaine en .fr en se basant sur des outils de ce type.
Donc en gros, ta protection par l’obscurité, t’as un taux de perte de 33% de base avec des outils débiles. En étant plus intelligent, on doit pouvoir monter au minimum à 50%.
[^] # Re: Juste pour compléter la liste
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1.
Étant donné qu’il est très simple et très rapide de scanner toute la plage IP (cf ZMap et son utilisation la plus efficace, Shodan), avoir un DNS obscurci ne sert à rien : on trouvera facilement quel serveur (= IP) héberge un VPN, au mieux on aura scanné toute ta plage de port, au pire tout l’Internet :P
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1.
Ce n’était en tout cas pas le cas pour le réglement de l’impôt sur le revenu en octobre 2015. Seuls RC4 et 3DES étaient proposés.
Cf https://twitter.com/aeris22/status/684666360652247040
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 0.
Et ça merde un max des 2 côtés.
Mais en tout cas, cliqueter sur un lien vers Firefox portable, dézipper l’archive, lancer, ça sera toujours over moins compliqué qu’aller migrer une Debian old-old-old-stable en stable ou un Windows serveur 2003 en 2010.
Je n’ai jamais dis que ça sera fait, à quelle vitesse ni avec quel pourcentage de réussite.
Mais la maj du client est possible et la procédure pour en obtenir un fiable est connu, documenté et déroulable, reproductible et généralisable, alors que celle d’un serveur, non.
Abstraction faite du pur problème humain, tu sais obtenir un Firefox à jour avec ALL d’activé avec une facilité X, alors que tu ne sais pas obtenir un serveur à jour avec ALL d’activé avec une facilité globale < X.
Peu importe le reste des arguments, le simple fait que le contrôle par le serveur fait que tu es seul responsable de la sécurité des données de tes visiteurs prime par dessus tout. Tu n’as pas et ne peux pas déléguer cette responsabilité à what-mille entités tierces.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à -1. Dernière modification le 06 janvier 2016 à 16:25.
Parce que les utilisateurs sont justement des brelles en sécu informatique (voire en informatique tout court ?)
J’ai dis que c’était facile de mettre à jour un nav’ comparé à un serveur.
On a une porte de sortie possible pour proposer une mise-à-jour safe des navigateurs de nos visiteurs (Firefox portable), ça ne signifie pas que ça sera fait dès le lendemain de la découverte d’une faille, ni que ça sera fait tout court.
On n’a aucune porte de sortie identifiée pour les serveurs, c’est du cas par cas à chaque fois et sans recette magique possible.
Pas avec une suite ALL dans le navigateur.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 0. Dernière modification le 06 janvier 2016 à 16:21.
Non, ils ne vont pas vite migrer. J’ai dis que c’était facile, pas que c’était rapide.
Parce qu’il y a suffisamment de lobby pour que ces modifs soient faites beaucoup trop longtemps après la bataille.
On l’a vu pour SSLv3, pour SHA-1, pour RC4, pour 3DES. Et je promet déjà une sacrée longue traîne avant l’exclusion des suites RSA au profit des suites ECC, et pire, la désactivation de TLSv1.2 après l’intégration de TLSv1.3.
Ça demande des palabres infinis pour que les navs se mettent d’accord de qui intègre quoi. Et ça ne fonctionne pas, la preuve chaque navigateur a une liste de choses supportées différente de celles des voisins…
Si justement. Je peux garantir que je n’aurais pas de problème de config en instaurant ALL sur tous les navigateurs.
Et je contrôle au moins MES données qui circulent sur MON serveur, ce que je ne peux pas faire avec un ALL côté serveur et une suite restrictive sur le client puisque je suis alors dépendant du bon vouloir de Google, Mozilla et Microsoft pour mettre à l’abri mes visiteurs.
La grosse différence est surtout là pour le choix client-first ou serveur-first : je suis légalement responsable de la sécurité de mes utilisateurs, je n’ai donc pas à subir des décisions externes (les suites dans les navigateurs) pour les mettre à l’abri.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 0.
RC4 = downgrade attack possible, chiffrement équivalent 0 bits pour la NSA si c’est le cas = F
Et avec tout le reste ? IE6 sous XP ? OpenSSL par défaut ? curl ? wget ? Java ? Mustard ou Twidere ?
Et environ 99% des user-agent qui traînent dans le coin. Ah oups, c’est pas désactivé là bas…
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à -1.
Parce que les gens s’en foutent. C’est BEAUCOUP plus simple de maj un navigateur qu’un serveur et il existe au moins des recettes miracles pour y arriver (au Firefox portable), mais ce n’est pas fait régulièrement parce que les gens ne connaissent pas l’hygiène de base de l’informatique (si tu en es encore à utiliser IE6 sous XP alors que tu pourrais utiliser Firefox sécurisé sous XP…).
Donc on arrête d’attendre des maj de nav, on les laisse avec tout d’activer par défaut et on ne s’emmerde plus. Un admin qui prend soin de sa sécu pourra enfin faire les choses proprement sans se préoccuper d’activer ou non des suites faillibles pour faire plaisir à tel ou tel navigateur et pourra corriger rapidement son serveur en cas de faille de sécu sans avoir à attendre la maj divine du navigateur qui va traîner des pieds. Un admin qui ne prend pas soin de sa sécu continuera à dégeuler la vie privée de ses utilisateurs.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à -1.
Non, puisque SSLv3 et 3DES est désactivé sur mon serveur.
C’est l’intérêt du serveur-first : tu maîtrises ce qui se passe chez toi, quelque soit ce qui se présente en face.
Et comme indiqué plus haut, je ne trouverais pas du tout anormal qu’un client se mette à supporter tout et n’importe quoi. On aurait BEAUCOUP MOINS d’emmerde pour migrer nos serveurs et plus de question à se poser si ça sera compatible ou non avec nos config. On pourra patcher nos failles de sécu sans attendre que Duchmol-browser ou Tartampion-user-agent ait activé les mêmes suites que nous…
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à -1.
Si, cf la démo quelque part dans ce topic.
Le matos pourri côté serveur, on ne pourra jamais s’en passer, encore moins rapidement.
Et des suites restrictives côté client, c’est remettre le problème de la compatibilité dans la boucle (tu ne maîtrise pas la configuration des serveurs autre que le tient et ne peut garantir qu’il supporte les mêmes ciphers que toi, donc un navigateur ne peut pas se limiter aux mêmes ciphers que toi non plus).
La seule config qui mettrait fin au bordel ambiant et permettrait à tous de faire les maj de sécu sans se prendre la tête de savoir qui on va dégager ou pas du parc, c’est « ALL » sur les clients et « une unique suite secure de ton choix » sur les serveurs. En cas de pépin, les admins peuvent migrer quand ils voudront, sans avoir besoin de synchroniser quoi que ce soit et en étant assuré que leurs clients continueront à voir leur site en version pourrie ou en version sécurisée par la suite. Et de ton point de vue, tu peux assurer la sécurité de tes clients dès publication de la faille de sécurité si tu en as envie.
Si tu fais l’inverse, ie des clients restrictifs, à chaque pépin de sécu, tu retombes dans le bordel de la compat. Il faut déjà prendre une décision collégial pour se mettre d’accord sur les nouvelles suites à implémenter dans tous les navigateurs. Puis attendre que suffisamment de clients se soient mis à jour pour faire la bascule côté serveur et virer l’ancienne suite (et exclure de facto tous visiteurs pas à jour).
Ou alors tu actives toutes les suites côté serveur, et une suite unique côté client. Mais alors tu ne maîtrises ni ne peut assurer la sécurité de tes propres utilisateurs, qui s’ils ne sont pas à jour, utiliseront potentiellement des suites pourries avec ton service.
Bref, dans le 1er cas, c’est toi qui est maître de la sécurité de tes visiteurs, dans le 2nd cas non.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 1. Dernière modification le 06 janvier 2016 à 15:39.
Oui. Les chiffres que tu avances viennent de Firefox et de Chromium, pas des banques elles-mêmes.
Elles, elles refusent de virer RC4 et 3DES au titre qu’encore trop de leurs clients (chiffres avancés entre 1 et 4%) qui sont sur des trucs pas compatibles autre chose (vieux Android, IE6 sous Windows XP et IE8 sous Windows Vista), et aussi une grosse partie de leur infra bancaire pas compatible (typiquement les DAB sous Windows XP donc ne supportant guère plus que SSLv3 parfois).
Elles ont aussi du matos de terminaison TLS qui ne supportent pas mieux (toujours pas de PFS sur les F5 10.x par exemple ou de TLS > 1.0 sur les F5 9.X), faute de pouvoir être upgrader (problème du chiffrement hardware) ou d’avoir les moyens (il faut racheter des licences) et le temps de le faire.
[^] # Re: Let’s Encrypt
Posté par Aeris (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à -1.
Cf ma démonstration ailleurs dans le topic, mais il faut justement que la responsabilité ne soit que d’un seul côté si on veut éviter la spirale infernale sécurité = incompatibilité et incompatibilité = pas de sécurité.
Et du coup elle ne peut être que côté serveur si on veut éviter les downgrade attack tout en ayant une bonne compatibilité.