Comment ? Parce que par définition, l'ARP ne sort pas du LAN.
L’ARP ne sort pas du LAN, mais le poisonning peut venir d’en dehors du LAN.
Aucun de ces projets ne parle d'ARP, sauf si j'ai loupé un truc.
Ce n’est pas de l’ARP spoofing à proprement parlé, mais ça fait des trucs tout aussi dégeu sur plus ou moins toutes les couches du réseau (TCP, DNS, routage, web, JS…).
J’ai aussi oublié, dans le cadre de Google justement, le programme MUSCULAR, et sa célèbre image du bidouillage de la NSA sur le LAN de Google en vue de se placer sur les nœuds d’interco des datacenters (corrigé depuis par Google via du chiffrement y compris en échange interne). Donc non, ton LAN n’est pas plus safe que le reste :)
Ça, ça ne dépend que de toi. Par exemple, Google prévient quand il ne sait pas faire de TLS (enfin, c'est en cours de dépoiement).
C’est une rustine qui n’a aucun sens technique.
Tu ne peux PAS savoir à l’avance si chiffrement il y aura ou non.
Ce n’est pas parce que le message précédent a été chiffré que le tien le sera.
Tu peux tomber sur un MX différent, non sécurisé.
Tu peux tomber sur un bout de réseau soumis à STARTTLS-drop (par exemple via un routeur turc) alors que les précédents étaient clean.
Tu peux tomber pile au moment où les admins sys du destinataire se sont gauffrés sur la config du serveur, en ont mis un nouveau mal configuré, ont une panne qui fera que tu passeras sur leur secondaire bien moins sécurisé, etc.
Bref, ce n’est pas parce que tu vois un cadenas rouge que ça partira en clair, et inversement un cadenas vert ne te garantit absolument pas que ça sera chiffré.
Le seul moyen de réellement t’assurer de la sécurité… c’est d’avoir déjà envoyé ton mail !
Donc, pourquoi tu parle de ARP poisining ?
Parce que tu peux faire du ARP poisining même en dehors de ton LAN ?
Qu'ils interceptent le trafic avec l'aide des transitaires, je veux bien. Mais qu'il viennent faire de l'ARP poisining chez moi, j'ai comme un doute.
Faut arrêter les conneries : d'accord les CA ne sont pas terribles, mais dire que ça n'apporte aucune sécurité est du mensonge (il y a un différence énorme quand même entre signé par soit même et signé par une CA reconnue comme relativement fiable par ton navigateur ou OS, nier cette différence et dire que les CA accepteront Mallory tranquille est du pur troll)
Dans le cas de SMTP (et uniquement dans ce cas), les CA sont sans intérêt.
La présence des MX et de STARTTLS, qui ne sont PAS authentifiés (sauf si MX protégé par DNSSec ET MTA émetteur vérifiant DNSSec ET ne fallbackant pas en clair en cas d’erreur, soit 0.0000001% des cas), casse toute possibilité de confiance en SMTP+STARTTLS. Le seul intérêt est de chiffrer (un tiers autre que le serveur en face n’accédera pas aux données), non d’authentifier (je cause avec le bon tiers).
Si tu es en position de faire du MITM, alors tu ne t’attaqueras pas au certificat, mais tu usurperas un MX ou tu vireras STARTTLS (93% du trafic SMTP, y compris vers Google, est downgradé en plain/text si tu es en Turquie par exemple).
Pas convaincu, il y a vraiment des algos trop faciles à casser pour ne pas les virer, ça donne juste un faux sentiments de sécurité. Qu'on soit plus tolérant qu'en HTTPS, je comprends, mais sinon il vaut mieux faire un fallback en clair, quitte à avoir une alerte à ce niveau pour s'en rendre compte.
Le problème est que justement, on n’a AUCUN alerte.
Et il vaudra toujours mieux avoir du chiffrement, aussi pourri soit-il que pas de chiffrement du tout.
Il y a DNSSEC pour ça
Oui, mais combien le déploie ?
Si tu n'as pas confiance dans ton lan, ce n'est pas SMTP le problème.
Là on cause MTA vers MTA, donc c’est tout sauf du LAN.
La NSA s’amuse à faire ce genre de truc niveau réseau mondial.
Une attaque passive n’est pas facilitée ou non par le CN ou SAN du certificat. Le simple fait d’avoir du chiffrement suffit (et du coup il vaut mieux ne pas faire de vérification et avoir une couche de chiffrement que de faire la vérif et de fallback en clair).
Si on est actif, SMTP est fucked de base :
DNS spoof pour hijacker le MX
ARP spoof pour hijacker le serveur
Pas de vérification du domaine et des CA
STARTTLS non authentifié (dropper les paquets contenant « STARTTLS » suffit à faire une downgrade attack vers plain/text, très utilisé en Turquie par exemple (96% du traffic se fait downgrader)).
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…
[^] # 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 20 février 2016 à 21:08.
L’ARP ne sort pas du LAN, mais le poisonning peut venir d’en dehors du LAN.
Ce n’est pas de l’ARP spoofing à proprement parlé, mais ça fait des trucs tout aussi dégeu sur plus ou moins toutes les couches du réseau (TCP, DNS, routage, web, JS…).
J’ai aussi oublié, dans le cadre de Google justement, le programme MUSCULAR, et sa célèbre image du bidouillage de la NSA sur le LAN de Google en vue de se placer sur les nœuds d’interco des datacenters (corrigé depuis par Google via du chiffrement y compris en échange interne). Donc non, ton LAN n’est pas plus safe que le reste :)
[^] # 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 20 février 2016 à 17:41.
C’est une rustine qui n’a aucun sens technique.
Tu ne peux PAS savoir à l’avance si chiffrement il y aura ou non.
Ce n’est pas parce que le message précédent a été chiffré que le tien le sera.
Tu peux tomber sur un MX différent, non sécurisé.
Tu peux tomber sur un bout de réseau soumis à STARTTLS-drop (par exemple via un routeur turc) alors que les précédents étaient clean.
Tu peux tomber pile au moment où les admins sys du destinataire se sont gauffrés sur la config du serveur, en ont mis un nouveau mal configuré, ont une panne qui fera que tu passeras sur leur secondaire bien moins sécurisé, etc.
Bref, ce n’est pas parce que tu vois un cadenas rouge que ça partira en clair, et inversement un cadenas vert ne te garantit absolument pas que ça sera chiffré.
Le seul moyen de réellement t’assurer de la sécurité… c’est d’avoir déjà envoyé ton mail !
Parce que tu peux faire du ARP poisining même en dehors de ton LAN ?
Turmoil https://nsa.imirhil.fr/pages?filter=turmoil&size=10
Turbine https://nsa.imirhil.fr/pages?filter=turbine&size=10
Discoroute https://nsa.imirhil.fr/pages?filter=discoroute&size=10
Quantum https://nsa.imirhil.fr/pages?filter=quantum&size=10
Foxacid https://nsa.imirhil.fr/pages?filter=foxacid&size=10
[^] # Re: cacert ?
Posté par Aeris (site web personnel) . En réponse au journal Pourquoi je suis passé à Let's Encrypt. Évalué à 2.
Dans le cas de SMTP (et uniquement dans ce cas), les CA sont sans intérêt.
La présence des MX et de STARTTLS, qui ne sont PAS authentifiés (sauf si MX protégé par DNSSec ET MTA émetteur vérifiant DNSSec ET ne fallbackant pas en clair en cas d’erreur, soit 0.0000001% des cas), casse toute possibilité de confiance en SMTP+STARTTLS. Le seul intérêt est de chiffrer (un tiers autre que le serveur en face n’accédera pas aux données), non d’authentifier (je cause avec le bon tiers).
Si tu es en position de faire du MITM, alors tu ne t’attaqueras pas au certificat, mais tu usurperas un MX ou tu vireras STARTTLS (93% du trafic SMTP, y compris vers Google, est downgradé en plain/text si tu es en Turquie par exemple).
[^] # 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.
Le problème est que justement, on n’a AUCUN alerte.
Et il vaudra toujours mieux avoir du chiffrement, aussi pourri soit-il que pas de chiffrement du tout.
Oui, mais combien le déploie ?
Là on cause MTA vers MTA, donc c’est tout sauf du LAN.
La NSA s’amuse à faire ce genre de truc niveau réseau mondial.
[^] # 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é à 2.
Une attaque passive n’est pas facilitée ou non par le CN ou SAN du certificat. Le simple fait d’avoir du chiffrement suffit (et du coup il vaut mieux ne pas faire de vérification et avoir une couche de chiffrement que de faire la vérif et de fallback en clair).
Si on est actif, SMTP est fucked de base :
[^] # 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…