Depuis cette nuit Verisign (la registry, pas netsol) a mis un wildcard
A sur *.com et *.net : tout ce qui n'est pas enregistré arrive sur
64.94.110.11, ou il y a une belle page web avec un moteur de
recherche, et un serveur de mail qui refuse tout.
Conséquences:
- Toutes les urls avec un noms de domaine incorrect dans .com et .net
que tapent vos utilisateurs arrivent chez eux. Bonjour la confidentialité.
- Tous les mails avec des domaines incorrects que vos utilisateurs envoient
finissent chez eux. Actuellement ils bouncent des la phase SMTP, mais
rien ne dit qu'ils ne gardent pas dans une liste une jolie liste
de domaines à créer et d'adresses emetteur et destinataires.
- Plus grave : Tous les spammeurs vont pouvoir a nouveau utiliser
n'importe quoi dans leur enveloppe SMTP (il faut espérer que l'effet
de bord qui consistera a flooder le serveur de Verisign avec des
bounces sera suffisant pour qu'ils crevent la bouche ouverte).
*PIRE*, Verisign est present dans *tous* nos navigateurs, on peut
imaginer que les glorieux marketoïdes qui sont derriere tout ça
vont générer automatiquement des certificats SSL qui seront corrects
pour n'importe quelle faute de frappe.
La solution brutale:
- null router 64.94.110.11 (ca fait mal parce que les mails incorrects
vont rester des jours dans la file). C'est visiblement ce qu'ont
commencé à faire des ISPs.
- bloquer l'accès à 64.94.110.11 sur vos relais HTTP (facile).
- Pour les mails, c'est moins simple, je ne connais pas de
serveur de mail permettant de refuser de relayer des messages
sur l'adresse IP de destination.
Il y a aussi des patches de Bind en préparation visiblement.
J'en suis encore sur le cul, j'essaye de faire une liste des implications
éventuelles sur la sécurité, il y a surement des choses à creuser,
notamment au niveau du XSS.
"Jean-Yves Bernier" a écrit dans le message de news:1g1emhj.key8wl1yno7fmN%
Franchement, quelle attitude raisonnable adopter devant un dialogue disant "TrustMe certifie que ce serveur est bien celui de ShopMe"?
Ben le problème c'est que les certifs root sont déjà dans les browsers de la plupart des internautes, qui ne voient pas : JE certifie que vous faite confiance à machin. Ils ne voient qu'une clef ou un cadenat fermé et se disent "c'est sur, je peux donner mon numéro CB"[1] :-(
A part lui bander les yeux (ce qui revient à déplacer la confiance vers l'auteur du navigateur et ne résoud rien), je ne vois pas.
Il a déjà les yeux bandés. c'est pour ça que c'est difficile de lui expliquer en quoi ce qui arrive est grave!
Je serais fort étonné que les spécialistes de la chose ne nous pondent pas un patch qui refuse les wildcards au toplevel, ou toute autre contre-mesure ou escalade de contre-mesures.
Il est déjà dispo sur le site d'ISC. Avec un justificatif qui me fait bien rire, un peu sous la forme "on n'est pas contre verisign, on répond à une demande de nos clients" :).
Eric
[1] je ne confonds pas authentification et cryptage...
"Jean-Yves Bernier" <grokub@pescadoo.net> a écrit dans le message de
news:1g1emhj.key8wl1yno7fmN%grokub@pescadoo.net...
Franchement, quelle attitude raisonnable adopter devant un dialogue
disant "TrustMe certifie que ce serveur est bien celui de ShopMe"?
Ben le problème c'est que les certifs root sont déjà dans les browsers de la
plupart des internautes, qui ne voient pas : JE certifie que vous faite
confiance à machin. Ils ne voient qu'une clef ou un cadenat fermé et se
disent "c'est sur, je peux donner mon numéro CB"[1] :-(
A part lui bander les yeux (ce qui revient à déplacer la confiance vers
l'auteur du navigateur et ne résoud rien), je ne vois pas.
Il a déjà les yeux bandés. c'est pour ça que c'est difficile de lui
expliquer en quoi ce qui arrive est grave!
Je serais fort étonné que les spécialistes de la chose ne nous pondent
pas un patch qui refuse les wildcards au toplevel, ou toute autre
contre-mesure ou escalade de contre-mesures.
Il est déjà dispo sur le site d'ISC. Avec un justificatif qui me fait bien
rire, un peu sous la forme "on n'est pas contre verisign, on répond à une
demande de nos clients" :).
Eric
[1] je ne confonds pas authentification et cryptage...
"Jean-Yves Bernier" a écrit dans le message de news:1g1emhj.key8wl1yno7fmN%
Franchement, quelle attitude raisonnable adopter devant un dialogue disant "TrustMe certifie que ce serveur est bien celui de ShopMe"?
Ben le problème c'est que les certifs root sont déjà dans les browsers de la plupart des internautes, qui ne voient pas : JE certifie que vous faite confiance à machin. Ils ne voient qu'une clef ou un cadenat fermé et se disent "c'est sur, je peux donner mon numéro CB"[1] :-(
A part lui bander les yeux (ce qui revient à déplacer la confiance vers l'auteur du navigateur et ne résoud rien), je ne vois pas.
Il a déjà les yeux bandés. c'est pour ça que c'est difficile de lui expliquer en quoi ce qui arrive est grave!
Je serais fort étonné que les spécialistes de la chose ne nous pondent pas un patch qui refuse les wildcards au toplevel, ou toute autre contre-mesure ou escalade de contre-mesures.
Il est déjà dispo sur le site d'ISC. Avec un justificatif qui me fait bien rire, un peu sous la forme "on n'est pas contre verisign, on répond à une demande de nos clients" :).
Eric
[1] je ne confonds pas authentification et cryptage...
Xavier Henner
"Cedric Blancher" wrote in message news:
Ces mecs là ne méritent plus amha d'avoir un root server chez eux. Y'a plein de monde qui gueule pour en avoir un autre en Europe, c'est peut être l'occasion. Et ils méritent d'ailleurs encore moins que je leur fasse confiance en matière de certification.
Malheureusement, ils restent toujours "operator" de la zone .com... Pour qu'ils ne le soient plus, il faut soit que leur contrat avec l'ICANN expire, ou que les Service Level Agreement (SLA) ne soient pas respectées... Je ne les ai pas, mais si quelqu'un les avait ça serait cool de donner un lien.
3. VGRS shall not in any way attempt to warehouse, or register domain names in its own right other than through an ICANN-accredited registrar, except for names designated for operational purposes in compliance with Section 24 of the Registry Agreement. VGRS will certify to ICANN every six months that it is abiding by this commitment.
or actuellement, ils squattent TOUS les domaines disponibles, sans passer par un registrar
-- Xavier Henner
"Cedric Blancher" <blancher@cartel-securite.fr> wrote in message
news:pan.2003.09.16.20.52.20.93789@cartel-securite.fr...
Ces mecs là ne méritent plus amha d'avoir un root server chez eux. Y'a
plein de monde qui gueule pour en avoir un autre en Europe, c'est peut
être l'occasion. Et ils méritent d'ailleurs encore moins que je leur
fasse confiance en matière de certification.
Malheureusement, ils restent toujours "operator" de la zone .com... Pour
qu'ils ne le soient plus, il faut soit que leur contrat avec l'ICANN expire,
ou que les Service Level Agreement (SLA) ne soient pas respectées... Je ne
les ai pas, mais si quelqu'un les avait ça serait cool de donner un lien.
3. VGRS shall not in any way attempt to warehouse, or register domain
names in its own right other than through an ICANN-accredited registrar,
except for names designated for operational purposes in compliance with
Section 24 of the Registry Agreement. VGRS will certify to ICANN every
six months that it is abiding by this commitment.
or actuellement, ils squattent TOUS les domaines disponibles, sans
passer par un registrar
Ces mecs là ne méritent plus amha d'avoir un root server chez eux. Y'a plein de monde qui gueule pour en avoir un autre en Europe, c'est peut être l'occasion. Et ils méritent d'ailleurs encore moins que je leur fasse confiance en matière de certification.
Malheureusement, ils restent toujours "operator" de la zone .com... Pour qu'ils ne le soient plus, il faut soit que leur contrat avec l'ICANN expire, ou que les Service Level Agreement (SLA) ne soient pas respectées... Je ne les ai pas, mais si quelqu'un les avait ça serait cool de donner un lien.
3. VGRS shall not in any way attempt to warehouse, or register domain names in its own right other than through an ICANN-accredited registrar, except for names designated for operational purposes in compliance with Section 24 of the Registry Agreement. VGRS will certify to ICANN every six months that it is abiding by this commitment.
or actuellement, ils squattent TOUS les domaines disponibles, sans passer par un registrar
-- Xavier Henner
Patrick
Un autre document intéressant est la réponse de l'IAB :
Document relatif au débat sur l'implémentation IDN testbed de Verisign. Donc ce n'est pas stricto sensu la réponse de l'IAB sur ce que VErisign vient de faire.
Par contre certains des points sont/seraient identiques, notamment: At the core of all of the IAB's concerns is the architectural principle that the DNS is a lookup service which must behave in an interoperable, predictable way at all levels of the DNS hierarchy. Furthermore, as a lookup service it is such a fundamental part of the Internet's infrastructure that converting it to an application-based search service, as the deployed system does, is not appropriate even in the case where the query presented would not normally map to a registered domain.
Patrick.
Un autre document intéressant est la réponse de l'IAB :
Document relatif au débat sur l'implémentation IDN testbed de Verisign.
Donc ce n'est pas stricto sensu la réponse de l'IAB sur ce que VErisign
vient de faire.
Par contre certains des points sont/seraient identiques, notamment:
At the
core of all of the IAB's concerns is the architectural principle that the
DNS is a lookup service which must behave in an interoperable, predictable
way at all levels of the DNS hierarchy. Furthermore, as a lookup service
it is such a fundamental part of the Internet's infrastructure that
converting it to an application-based search service, as the deployed
system does, is not appropriate even in the case where the query presented
would not normally map to a registered domain.
Document relatif au débat sur l'implémentation IDN testbed de Verisign. Donc ce n'est pas stricto sensu la réponse de l'IAB sur ce que VErisign vient de faire.
Par contre certains des points sont/seraient identiques, notamment: At the core of all of the IAB's concerns is the architectural principle that the DNS is a lookup service which must behave in an interoperable, predictable way at all levels of the DNS hierarchy. Furthermore, as a lookup service it is such a fundamental part of the Internet's infrastructure that converting it to an application-based search service, as the deployed system does, is not appropriate even in the case where the query presented would not normally map to a registered domain.
Patrick.
Patrick
Un autre document intéressant est la réponse de l'IAB :
Et, malheureusement, le côté obscur contrecarre avec la réponse d'août du SECSAC (ICANN Security and Stability Advisory Committee) sur le même sujet qui, en gros, dit que puisque d'autres Registries le font...
Je cite: If we are to take issue with what Verisign is doing, then we it seems reasonable to take issue with the others as well. However, although the practices give us some discomfort, we can't really see a technical basis for objecting to what Verisign is doing.
D'ailleurs sur la liste ga, certains laissent penser que les wildcards ca doit être interdit pour les gTLD, mais qu'on peut laisser les ccTLD s'en servir...
Patrick.
Un autre document intéressant est la réponse de l'IAB :
Et, malheureusement, le côté obscur contrecarre avec la réponse d'août du
SECSAC (ICANN Security and Stability Advisory Committee)
sur le même sujet qui, en gros, dit que puisque d'autres Registries le
font...
Je cite:
If we are to take issue with what Verisign is doing, then we it seems
reasonable to take issue with the others as well. However, although the
practices give us some discomfort, we can't really see a technical basis for
objecting to what Verisign is doing.
D'ailleurs sur la liste ga, certains laissent penser que les wildcards ca
doit être interdit pour les gTLD, mais qu'on peut laisser les ccTLD s'en
servir...
Et, malheureusement, le côté obscur contrecarre avec la réponse d'août du SECSAC (ICANN Security and Stability Advisory Committee) sur le même sujet qui, en gros, dit que puisque d'autres Registries le font...
Je cite: If we are to take issue with what Verisign is doing, then we it seems reasonable to take issue with the others as well. However, although the practices give us some discomfort, we can't really see a technical basis for objecting to what Verisign is doing.
D'ailleurs sur la liste ga, certains laissent penser que les wildcards ca doit être interdit pour les gTLD, mais qu'on peut laisser les ccTLD s'en servir...
Patrick.
Stephane Catteau
Jean-Yves Bernier nous disait récement dans fr.comp.securite <news:1g1fyov.1hpt7p81h4r8s3N% :
J'hésite entre l'incompétence technique crasse, pour avoir totalement négligé la charge qu'entraînerait une telle manip, ou le ballon d'essai, pour mesurer la réaction de l'internet.
Hier lorsque je suis tombé sur leur jolie page j'ai eu droit à une jolie pub pour un site en ".fr"... Pour un ballon d'essais, ils ont bien préparé leur affaire je trouve. Mais de toute façon la question ne se pose même pas, regarde le message dans lequel Alain Thivillon démonte l'implementation du MTA[1] qu'ils ont placé sur la machine. C'est de l'incompétence pure et, à la limite, ça fait encore plus peur. Imagine que leurs techniciens aient déjà fait mumuse avec les serveurs DNS, qu'est-ce qui nous protége d'une faille permettant de faire du DNS poisonning en partant des root-servers[2] ?
Il ne leur reste plus que l'excuse du stagiaire viré.
Copieur ;-)
[1] Peut-on vraiment appeller ce "truc" un MTA ? :-/
[2] C'est rien, une pillule et au lit... -- "Si ceux qui disent du mal de moi savaient exactement ce que je pense d'eux , ils en diraient bien davantage." Sacha Guitry
Jean-Yves Bernier nous disait récement dans fr.comp.securite
<news:1g1fyov.1hpt7p81h4r8s3N%grokub@pescadoo.net> :
J'hésite entre l'incompétence technique crasse, pour avoir
totalement négligé la charge qu'entraînerait une telle manip, ou
le ballon d'essai, pour mesurer la réaction de l'internet.
Hier lorsque je suis tombé sur leur jolie page j'ai eu droit à une
jolie pub pour un site en ".fr"... Pour un ballon d'essais, ils ont
bien préparé leur affaire je trouve. Mais de toute façon la question ne
se pose même pas, regarde le message dans lequel Alain Thivillon
démonte l'implementation du MTA[1] qu'ils ont placé sur la machine.
C'est de l'incompétence pure et, à la limite, ça fait encore plus
peur. Imagine que leurs techniciens aient déjà fait mumuse avec les
serveurs DNS, qu'est-ce qui nous protége d'une faille permettant de
faire du DNS poisonning en partant des root-servers[2] ?
Il ne leur reste plus que l'excuse du stagiaire viré.
Copieur ;-)
[1]
Peut-on vraiment appeller ce "truc" un MTA ? :-/
[2]
C'est rien, une pillule et au lit...
--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry
Jean-Yves Bernier nous disait récement dans fr.comp.securite <news:1g1fyov.1hpt7p81h4r8s3N% :
J'hésite entre l'incompétence technique crasse, pour avoir totalement négligé la charge qu'entraînerait une telle manip, ou le ballon d'essai, pour mesurer la réaction de l'internet.
Hier lorsque je suis tombé sur leur jolie page j'ai eu droit à une jolie pub pour un site en ".fr"... Pour un ballon d'essais, ils ont bien préparé leur affaire je trouve. Mais de toute façon la question ne se pose même pas, regarde le message dans lequel Alain Thivillon démonte l'implementation du MTA[1] qu'ils ont placé sur la machine. C'est de l'incompétence pure et, à la limite, ça fait encore plus peur. Imagine que leurs techniciens aient déjà fait mumuse avec les serveurs DNS, qu'est-ce qui nous protége d'une faille permettant de faire du DNS poisonning en partant des root-servers[2] ?
Il ne leur reste plus que l'excuse du stagiaire viré.
Copieur ;-)
[1] Peut-on vraiment appeller ce "truc" un MTA ? :-/
[2] C'est rien, une pillule et au lit... -- "Si ceux qui disent du mal de moi savaient exactement ce que je pense d'eux , ils en diraient bien davantage." Sacha Guitry
Eric Razny
"Stephane Catteau" a écrit dans le message de news:
[1] Peut-on vraiment appeller ce "truc" un MTA ? :-/
a) il ne respecte aucune RFC b) il ne permet même pas de transférer des e-mail (le but d'un MTA il me semble :-) ).
Corrolaire : en plus d'être des truands ce sont des incompétants (s'il fallait encore démontrer un des deux points!)
Accessoirement en parlant de MTA j'ai mis mon sendmail à jour et je conseille à ceux qui en ont un d'aller faire un tour des alertes sécu... C'est parti pour recompiler sec, cette semaine :)
"Stephane Catteau" <steph.nospam@sc4x.net> a écrit dans le message de
news:bkadrt.3vvckiv.1@sc4x.org...
[1]
Peut-on vraiment appeller ce "truc" un MTA ? :-/
a) il ne respecte aucune RFC
b) il ne permet même pas de transférer des e-mail (le but d'un MTA il me
semble :-) ).
Corrolaire : en plus d'être des truands ce sont des incompétants (s'il
fallait encore démontrer un des deux points!)
Accessoirement en parlant de MTA j'ai mis mon sendmail à jour et je
conseille à ceux qui en ont un d'aller faire un tour des alertes sécu...
C'est parti pour recompiler sec, cette semaine :)
"Stephane Catteau" a écrit dans le message de news:
[1] Peut-on vraiment appeller ce "truc" un MTA ? :-/
a) il ne respecte aucune RFC b) il ne permet même pas de transférer des e-mail (le but d'un MTA il me semble :-) ).
Corrolaire : en plus d'être des truands ce sont des incompétants (s'il fallait encore démontrer un des deux points!)
Accessoirement en parlant de MTA j'ai mis mon sendmail à jour et je conseille à ceux qui en ont un d'aller faire un tour des alertes sécu... C'est parti pour recompiler sec, cette semaine :)
On 17 Sep 2003 13:30:24 GMT, (Jean-Yves Bernier) wrote:
Comment déjà le système de tiers de confiance peut-il fonctionner alors que, pour l'internaute de base, les noms VeriSign, Thawte, CyberTrust, TrustCenter n'évoquent rien, et que pour l'internaute dégrossi, ils évoqueraient plutôt la méfiance?
Tu veux dire que finalement, l'action de Verisign a un point positif, en ce sens qu'elle apporte une preuve supplémentaire que les "tiers de confiance" sont un ramassis d'escrocs ?
-- Let's face it, boys: the Trash Heap _is_ all. -- the Trash Heap, Fraggle Rock, ep 1
On 17 Sep 2003 13:30:24 GMT, grokub@pescadoo.net (Jean-Yves Bernier)
wrote:
Comment déjà le système de tiers de confiance peut-il fonctionner alors
que, pour l'internaute de base, les noms VeriSign, Thawte, CyberTrust,
TrustCenter n'évoquent rien, et que pour l'internaute dégrossi, ils
évoqueraient plutôt la méfiance?
Tu veux dire que finalement, l'action de Verisign a un point positif,
en ce sens qu'elle apporte une preuve supplémentaire que les "tiers de
confiance" sont un ramassis d'escrocs ?
--
Let's face it, boys: the Trash Heap _is_ all.
-- the Trash Heap, Fraggle Rock, ep 1
On 17 Sep 2003 13:30:24 GMT, (Jean-Yves Bernier) wrote:
Comment déjà le système de tiers de confiance peut-il fonctionner alors que, pour l'internaute de base, les noms VeriSign, Thawte, CyberTrust, TrustCenter n'évoquent rien, et que pour l'internaute dégrossi, ils évoqueraient plutôt la méfiance?
Tu veux dire que finalement, l'action de Verisign a un point positif, en ce sens qu'elle apporte une preuve supplémentaire que les "tiers de confiance" sont un ramassis d'escrocs ?
-- Let's face it, boys: the Trash Heap _is_ all. -- the Trash Heap, Fraggle Rock, ep 1
Avant de bloquer l'adresse 64.94.110.11, jetez un oeil sur leur "Privacy Policy".
Où peut-on la lire ?
Ils ont aussi publié deux white papers : - leur implémentation <http://www.verisign.com/resources/gd/sitefinder/implementation.pdf> - et leurs "recommendations" <http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf>
-- Kilian <|Leo404|> tu peux m'aider à configurer ma connexion? delepine| Mais encore ? <|Leo404|> va te faire enculer -+- Leo404 in Guide du linuxien pervers - "Connexions inavouables" -+-
Laurent Chemla wrote:
Fabien LE LEZ <gramster@gramster.com> wrote:
Avant de bloquer l'adresse 64.94.110.11, jetez un oeil sur leur
"Privacy Policy".
Où peut-on la lire ?
Ils ont aussi publié deux white papers :
- leur implémentation
<http://www.verisign.com/resources/gd/sitefinder/implementation.pdf>
- et leurs "recommendations"
<http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf>
--
Kilian
<|Leo404|> tu peux m'aider à configurer ma connexion?
delepine| Mais encore ?
<|Leo404|> va te faire enculer
-+- Leo404 in Guide du linuxien pervers - "Connexions inavouables" -+-
Avant de bloquer l'adresse 64.94.110.11, jetez un oeil sur leur "Privacy Policy".
Où peut-on la lire ?
Ils ont aussi publié deux white papers : - leur implémentation <http://www.verisign.com/resources/gd/sitefinder/implementation.pdf> - et leurs "recommendations" <http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf>
-- Kilian <|Leo404|> tu peux m'aider à configurer ma connexion? delepine| Mais encore ? <|Leo404|> va te faire enculer -+- Leo404 in Guide du linuxien pervers - "Connexions inavouables" -+-
