Re: [FRnOG] [MISC] La "backdoor" de Chrome

[David Ponzone]

> Le 7 avr. 2021 à 19:11, Michel Py via frnog  a écrit :
> 
> 
> Yàplukà garder une VM avec XP et un vieux navigateur, c'est bon pour la 
> sécurité ça aussi :-(
> 

Sans aller jusque là:

https://github.com/themartorana/MultiFirefox 


Y a peut-être un truc similaire pour Chrome.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [MISC] La "backdoor" de Chrome

[Michel Py via frnog]

> Oliver varenne a écrit :
> Néanmoins, quand tu as besoin de créer 4 ou 5 VM différentes, juste pour 3h 
> de test, tu
> as pas envie de t'emmerder 600 fois dans la journée Tu utilise les certs 
> autosignés
> présents dans tes applications de test et voila. Enfin bref, moi ça me gonfle.

+1, la quantité de travail nécessaire juste à pouvoir accéder à une page est 
débile.

> Stephane Bortzmeyer a écrit :
> Habituer les utilisateurs à avoir des alertes sur les certificats n'est pas 
> une bonne idée.

Certes, mais concevoir un système qui demande tellement de travail que personne 
ne le mets en place, c'est pire. Demander à Claude Michu d'installer un 
certificat pour utiliser un machin IOT sur son réseau local, c'est tellement 
irréaliste que ce qui va arriver c'est justement l'habituer à voir les alertes 
et même à les détourner.

> Francois Lesueur a écrit :
> Alors perso, je n'ai rien contre le HTTP-pas-S. J'en fais tous les jours et 
> je m'en porte bien ;). Le risque
> d'accepter trop facilement les certificats autosignés, c'est que ça a un côté 
> canada dry : on a l'impression
> de faire du HTTPS, alors qu'en fait on a pas du tout le niveau de sécurité 
> attendu. Et oui, 99,9% du temps,
> on parle bien avec le bon serveur, mais ce sont les 99,9% du temps où on 
> avait en fait pas besoin de HTTPS.
> Le problème, c'est le 0,1% du temps où HTTPS aurait servi et où, du coup, on 
> se fait avoir.

Je plussoie : sur le réseau local, il vaut mieux faire du HTTP non chiffré que 
d'habituer les utilisateurs aux alertes. Mais apparemment ce n'est pas la route 
prévue, maintenant HTTP c'est déjà marqué "not secure", bientôt ça va être en 
rouge.

Yàplukà garder une VM avec XP et un vieux navigateur, c'est bon pour la 
sécurité ça aussi :-(

Michel.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Ghostdog]

Bonjour,

J'aime bien utiliser XCA pour ça : https://hohnstaedt.de/xca/

Facile à installer (tourne sous Windows aussi) et facile à utiliser.

Pierre.

On Wed, 7 Apr 2021 at 08:48, Francois Lesueur 
wrote:

>
> Bonjour,
>
> Le 06/04/2021 à 20:19, Oliver varenne a écrit :
> > Ce qui est super chiant quand tu développes (car tu bosses généralement
> avec de l'auto signé)
>
> Pour les certificats de dév, il y a mkcert
> (https://github.com/FiloSottile/mkcert) qui est super et exprès pour ça
> : création d'une CA locale et installation sur le système/les browsers
> en une ligne, puis création d'un certif signé par cette CA en une autre
> ligne, et zou !
>
> Pour aller un poil plus loin, la suite smallstep est top :
> https://smallstep.com/docs/step-ca/getting-started . Ça permet de
> générer une vraie CA, il y aussi une commande pour l'installer
> proprement sur les browsers locaux, puis les certifs. Ça fait même du
> ACME (protocole de Let's Encrypt) :
> https://smallstep.com/docs/tutorials/acme-challenge
>
> Dans les 2 cas, ça se joue en 2 lignes (plutôt mkcert pour du certif de
> dév, plutôt smallstep pour une CA locale) et, surtout, sans aucun
> appel/config à openssl, ça change un peu la vie côté CA !
>
> Bonne journée
> François
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: Re: [MISC] La "backdoor" de Chrome

[Stephane Bortzmeyer]

On Wed, Apr 07, 2021 at 04:44:42PM +0200,
 Adrien Rivas  wrote 
 a message of 88 lines which said:

> Tu parles de HSTS David je pense (et par extension Michel), ou là
> effectivement, on est à un point ou le serveur n'aime pas la blague de la
> manipulation de certificat en mode MITM et bloque toute tentative de
> dialogue,

HSTS, s'il a été vu précédemment, empêchera de passer en clair, ou
vers un certificat auto-signé, mais il n'empêchera pas l'Homme du
Milieu si la machine terminale a été infectée avec le certificat de
l'AC de l'intercepteur.

Et,de toute façon, il dépend du serveur HTTP donc, dans le cas des
équipements réseau à configurer, il n'est pas utilisé.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [MISC] La "backdoor" de Chrome

[Adrien Rivas]

Tu parles de HSTS David je pense (et par extension Michel), ou là
effectivement, on est à un point ou le serveur n'aime pas la blague de la
manipulation de certificat en mode MITM et bloque toute tentative de
dialogue, et où on se retrouve à devoir compter sur l'agent EDR de
l'antivirus côté poste de travail pour pouvoir voir ce que fait le poste
client en terme de navigation web.

Il est normalement possible sur la majeure partie des équipements du marché
de gérer des exceptions sur des domaines et/ou des catégories (au hasard,
le secteur bancaire).

Le mer. 7 avr. 2021 à 14:13, Stephane Bortzmeyer  a
écrit :

> On Wed, Apr 07, 2021 at 12:47:16PM +0200,
>  David Ponzone  wrote
>  a message of 33 lines which said:
>
> > J’ai des alertes quand même pour accéder à certains sites ou pour
> > les bloquer proprement (page d’erreur plutôt que redirect propre sur
> > la page qui annonce le bloquage).
>
> Il faudrait voir le détail des alertes en question. Peut-être
> Certificate Transparency  ?
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Alexis Lameire]

J'étais en train de lire le début du thread et alais proposer du BGP PIC.

Et que vois-je plus loin, la réponse de Julien.

Je pense vraiment que c'est la bonne voie où aller. Ça permet à tes
routeurs de calculer une route de backup pour chaque préfix qui sera promue
en cas de coupure.

Cordialement
Alexis Lameire

Le mer. 7 avr. 2021 à 10:10, Julien OHAYON  a écrit :

> Je confirme, "bgp additional-paths install" c'est magique pour ne pas
> attendre 20 min.
>
>
> Une petite doc pour optimiser le tout :
> https://eos.arista.com/inet-edge-config/
>
>
> 
>
> Arista EOS Central - Configurations and Optimizations for Internet Edge
> Routing
> eos.arista.com
> ContentsIntroductionA Note on 32 vs. 64 Bit EOSArista Multi-Agent BGP
> ConfigurationArista FlexRoute ConfigurationChanging ACL
> ImplementationAdjusting show tech-support OutputsISP Peering Configurations
> and OptimizationValidating Hardware before AdvertisingEnabling Fast Failure
> Detection with BFDEnabling missing route-map handling (RFC 8212
> behavior)Removing Private BGP ASNsEnabling BGP CommunitiesAdjusting
> community processing orderAdjusting BGP Maximum-Routes ValueFiltering
> Extraneous or Malicious RoutesBGP Prefix Independent ConvergenceResource
> Public... Continue reading →
>
>
>
> 
> De : frnog-requ...@frnog.org  de la part de
> Pierre LANCASTRE 
> Envoyé : mercredi 7 avril 2021 09:56:01
> À : Laurent Laurent
> Cc : David Ponzone; Clement Cavadore; FRnOG
> Objet : Re: [FRnOG] [Tech] Optimisation bascule BGP arista
>
> Hello
>
> Tu peux explorer la piste du pic-edge pour préinstaller en FIB le backup
> path
>
> router bgp 
> bgp additional-paths install
>
> Tu devrais avoir tes routes comme suit :
>
> * > x.x.x.x/yy 
> * b x.x.x.x/yy 
>
> J'ai pas encore testé avec un full feed mais en principe ça fonctionne.
>
> En tout cas en lab ca fait le boulot
>
> ++
>
> Pierre
>
>
> Le mer. 7 avr. 2021 à 09:42, Laurent Laurent 
> a écrit :
>
> > Je n'ai pas encore ouvert un ticket chez Arista car on est passé par un
> > intégrateur et lui est au courant, ça va être la prochaine étape ;)
> >
> > Voici le sh ip bgp summary de l'arista 2 :
> >
> >   Description Neighbor V  AS   MsgRcvd
> > MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
> >   Operateur 2xx.xx.xx.xx  4  x   17670891
> >  53466800   27d23h Estab   833592 833527
> >   arista-1 198.18.255.1 4  x   20127835
> > 365120500   27d23h Estab   827988 827988
> >
> > On voit que le arista 2 possède presque toutes les routes via l'ibgp.
> >
> > Merci encore pour votre aide.
> >
> > Le mer. 7 avr. 2021 à 09:30, David Ponzone  a
> > écrit :
> >
> > > Tu peux envoyer le sh ip bgp sum de arista2, au cas où.
> > >
> > > Tu as ouvert un case chez Arista ? C’est peut-être un bug connu chez
> eux.
> > >
> > > Le 7 avr. 2021 à 09:25, Laurent Laurent 
> a
> > > écrit :
> > >
> > > J'ai peur aussi que ce soit le cas, mais pas forcément la partie BGP
> mais
> > > plus la partie hardware.
> > >
> > >   Description  Neighbor V  AS   MsgRcvd
> > > MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
> > >   Operateur1   xx.xx.xx.xxx4  X1586
> > >  14998200   12:30:04 Estab   827948 827948
> > >   Arista2  198.18.255.2   4  X3080607
> > >  162422170027d23h Estab   5915   5915
> > >
> > > Quand on regarde la table de routage, j'apprends en IPv4 environs 830
> 000
> > > routes et je n'ai que 5915 routes via l'iBGP. Si mon opérateur 1 tombe,
> > il
> > > faut bien 2mns40 à l'arista 1 pour avoir les 830 000 routes, je pense
> que
> > > mon soucis vient de la, mais comment réussir a accélérer ça? Ça se
> trouve
> > > ce n'est pas possible et la seule solution serait de ne plus avoir
> d'iBGP
> > > et d'avoir un lien actif/passif :(
> > >
> > >
> > > Le mer. 7 avr. 2021 à 09:16, David Ponzone  a
> > > écrit :
> > >
> > >> Hmmm comme ça, j’ai envie de dire que le BGP de l’Arista est en
> mousse,
> > >> mais juste parce que sans trop chercher, je vois pas de raison que ça
> > mette
> > >> tout ce temps.
> > >> Ca devrait être 30 sec.
> > >>
> > >> > Le 7 avr. 2021 à 09:12, Laurent Laurent <
> laurent.lecomt...@gmail.com>
> > >> a écrit :
> > >> >
> > >> > Bonjour Clément, merci pour ta réponse.
> > >> >
> > >> > La bascule que j'ai mise en place n'est pas pour la partie LAN. Les
> 2
> > >> liens
> > >> > opérateur sont actif/actif. Si le lien opérateur 1 tombe
> (l'interface
> > >> passe
> > >> > down) sans bascule du vrrp le chemin va bien être : lan arista 1 -->
> > >> ibgp
> > >> > --> arista 2 --> opérateur 2, sauf que ça met 6 mns avant que le
> > >> routage re
> > >> > fonctionne.
> > >> > En basculant le vrrp je gagne gagne du temps, le temps que l'ibgp de
> > >> > 

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Michel 'ic' Luczak]

Hello,

> On 7 Apr 2021, at 10:09, Vincent Bernat  wrote:
> 
> L'auto-signé fonctionne désormais en mode "trust on first use", comme
> SSH. Cela apporte donc une authentification partielle. Dans Firefox, le
> hash du certificat est stocké dans "cert_override.txt" dans le profil de
> l’utilisateur.

Perso, je vends des boites (“consumer electronics” comme on dit) donc pas trop 
moyen de leur livrer un certificat valide, et les utilisateurs utilisent une 
adresse en .local de toute façon pour y accéder. Ce qu’on a fait c’est qu’on 
livre les fingerprints du certificat auto-signé sur un papier avec la boîte 
(nos utilisateurs sont plutôt geeks) et on leur explique qu’il faut vérifier à 
la première connexion. Chrome étant vraiment devenu pénible, merci pour 
l’astuce du “thisisunsafe” ça ira dans la FAQ.

Pro-tip: n’oubliez pas le alt-name dans vos auto-signés, c’est maintenant 
requis même s’il n’y a qu’un seul domaine dedans…

openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -keyout local.key 
-out local.crt -subj "/C=WW/ST=World/O=$MYNAME/OU=$MYNAME/CN=$MYNAME.local" 
-extensions san -config <( \
  echo '[req]'; \
  echo 'distinguished_name=req'; \
  echo "[san]"; \
  echo "subjectAltName=DNS:$MYNAME.local")

++ ic



---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [MISC] La "backdoor" de Chrome

[Stephane Bortzmeyer]

On Wed, Apr 07, 2021 at 12:47:16PM +0200,
 David Ponzone  wrote 
 a message of 33 lines which said:

> J’ai des alertes quand même pour accéder à certains sites ou pour
> les bloquer proprement (page d’erreur plutôt que redirect propre sur
> la page qui annonce le bloquage).

Il faudrait voir le détail des alertes en question. Peut-être
Certificate Transparency  ?




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Mickael Monsieur]

quelqu’un a déjà essayé avec un ipmi supermicro de pousser un certificat ? pas 
été vérifié si ipmitool le permet, mais j’ai de gros doutes.

> Le 7 avr. 2021 à 11:53, alexandre derumier  a écrit :
> 
> 
>> On 07/04/2021 10:38, Wallace wrote:
>> Ok LE c'est génial on l'utilise beaucoup, ce que veut dire Erwan c'est
>> que beaucoup d'équipements dont les IPMI cités ne sont pas programmables
>> soit en local (pas de crontab, pas d'os où l'on pourrait déposer un LE)
>> soit à distance pour pousser de nouveaux certificats.
>> 
>> La seule méthode que je vois actuellement sur les IPMI c'est programmer
>> un firefox ou chrome headless pour refaire les actions qu'un humain
>> ferait pour déposer de nouveaux certificats. Mais c'est sortir
>> l'artillerie lourde pour un élément qui est censé être simple.
> 
> on le fait au boulot pour les cartes idrac de dell, via puppet qui lance la 
> commande racadm,
> 
> avec un certif wildcard généré via letsencrypt sur un autre serveur
> 
> 
> '/usr/bin/racadm sslkeyupload -f /etc/ssl/private/star.rsa.domain.com -t 1 && 
> /usr/bin/racadm sslcertupload -f /etc/ssl/certs/star.rsa.domain.com.crt -t 1 
> && /usr/bin/racadm racreset'
> 
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [MISC] La "backdoor" de Chrome

[David Ponzone]

Je prends un FW du marché.
Je récupère son CA autosigné par défaut pour l’inspection DPI.
Je l’importe dans le PC du client.

J’ai des alertes quand même pour accéder à certains sites ou pour les bloquer 
proprement (page d’erreur plutôt que redirect propre sur la page qui annonce le 
bloquage).
Facebook par exemple.

J’admets que ça vient peut-être d’une erreur chez moi, mais je lis beaucoup de 
posts de gens avec des problèmes similaires.

> Le 7 avr. 2021 à 10:49, Stephane Bortzmeyer  a écrit :
> 
> On Wed, Apr 07, 2021 at 12:00:41AM +0200,
> David Ponzone  wrote 
> a message of 32 lines which said:
> 
>> Je sais pas si c’est lié, mais je remarque que les progrès d’HTTPS
>> permettent si j’ai bien compris de le rendre non-interceptable,
> 
> Je ne vois pas bien à quoi tu fais allusion. Aucune technique de
> sécurité n'est parfaite et aucun progrès de HTTPS (de TLS, sans doute,
> avec TLS 1.3 ?) ne permet de se protéger contre une attaque de l'homme
> du milieu, à part l'authentification (via une AC ou via DANE).
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Wallace]

Le 07/04/2021 à 11:50, alexandre derumier a écrit :
>
> on le fait au boulot pour les cartes idrac de dell, via puppet qui
> lance la commande racadm,
>
> avec un certif wildcard généré via letsencrypt sur un autre serveur
>
>
> '/usr/bin/racadm sslkeyupload -f /etc/ssl/private/star.rsa.domain.com
> -t 1 && /usr/bin/racadm sslcertupload -f
> /etc/ssl/certs/star.rsa.domain.com.crt -t 1 && /usr/bin/racadm racreset'
>
>
Merci pour l'information, je ne savais pas que racadm avait cette option.

Je vais tester du coup :)


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[alexandre derumier]

On 07/04/2021 10:38, Wallace wrote:

Ok LE c'est génial on l'utilise beaucoup, ce que veut dire Erwan c'est
que beaucoup d'équipements dont les IPMI cités ne sont pas programmables
soit en local (pas de crontab, pas d'os où l'on pourrait déposer un LE)
soit à distance pour pousser de nouveaux certificats.

La seule méthode que je vois actuellement sur les IPMI c'est programmer
un firefox ou chrome headless pour refaire les actions qu'un humain
ferait pour déposer de nouveaux certificats. Mais c'est sortir
l'artillerie lourde pour un élément qui est censé être simple.


on le fait au boulot pour les cartes idrac de dell, via puppet qui lance 
la commande racadm,


avec un certif wildcard généré via letsencrypt sur un autre serveur


'/usr/bin/racadm sslkeyupload -f /etc/ssl/private/star.rsa.domain.com -t 
1 && /usr/bin/racadm sslcertupload -f 
/etc/ssl/certs/star.rsa.domain.com.crt -t 1 && /usr/bin/racadm racreset'





---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Francois Lesueur]

Re-,

Le 07/04/2021 à 10:28, OB via frnog a écrit :
> Autant sur des systèmes qui ne sont accessible que sur le LAN , tel que
> les bornes wifi, les imprimantes, ... bref des services qui pourraient
> tout aussi bien tourner en HTTP finalement, je trouve ça overkill. Je
> vais pas monter un CA pour 3 bornes wifi , une imprimante et la caméra
> d'une TPE derrière une livebox !

Alors perso, je n'ai rien contre le HTTP-pas-S. J'en fais tous les jours
et je m'en porte bien ;). Le risque d'accepter trop facilement les
certificats autosignés, c'est que ça a un côté canada dry : on a
l'impression de faire du HTTPS, alors qu'en fait on a pas du tout le
niveau de sécurité attendu. Et oui, 99,9% du temps, on parle bien avec
le bon serveur, mais ce sont les 99,9% du temps où on avait en fait pas
besoin de HTTPS. Le problème, c'est le 0,1% du temps où HTTPS aurait
servi et où, du coup, on se fait avoir.

Il faut, à mon sens, voir un auto-signé comme plus proche du HTTP que du
HTTPS. Et c'est dans ce sens que va l'évolution des browsers depuis
quelques années, s'assurer que le HTTPS est bien du "vrai" HTTPS. Et
sinon, on peut encore faire du HTTP, mais la non-sécurisation est
explicite au moins.


> Le "trust on first use" de Firefox dont parles Vincent, utilisé depuis
> des année en SSH me parait être un bon compromis.

Je crois que SSH a intégré le modèle CA récemment, aussi ;). Le TOFU,
c'est cool, mais c'est un peu comme les exceptions de sécurité je trouve
: quand ça ne marche pas, l'utilisateur supprime l'ancienne clé ("le
serveur a du être réinstallé, tout va bien"), et hop, perdu. Comme d'hab
en sécu : quand on sait ce qu'on fait et pourquoi, on se méfiera à ce
moment, mais globalement les logiciels doivent d'abord faire l'hypothèse
que l'utilisateur n'est pas un fin connaisseur de la sécu, et donc avoir
des réglages sûrs de base.

Pour autant, je ne suis pas du tout un défenseur du modèle CA, il est
fondamentalement mauvais, et oui, vivement DANE partout ;).

Bonne journée !
François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [MISC] La "backdoor" de Chrome

[Stephane Bortzmeyer]

On Wed, Apr 07, 2021 at 12:22:38AM +0200,
 N R  wrote 
 a message of 71 lines which said:

> Un parallèle avait été donné (je sais plus la ref exact, peut-être
> le livre Cyberstructure de Bortzmeyer) avec une carte d'identité,

Peut-être :-)

> La différence avec les cartes d'identité, c'est que les CA n'étant
> pas des état mais des entreprises, le reste des arguments est
> d'ordre purement commercial, en jouant sur la peur inspirée par les
> messages d'avertissements anxiogènes des navigateurs.

Il y a évidemment des décisions qui sont d'ordre commercial mais il y
a aussi un réel problème de sécurité sous-jacent. Un certificat
auto-signé ne prouvant rien, il rend trivial l'écoute par un attaquant
actif.

La question est chaudement discutée dans le cadre du projet Gemini
 qui se veut justement
non-commercial et accessible à tous, et où les AC sont mal vues. Outre
les AC et DANE (je suis d'accord avec Willy que DANE est la bonne
solution), une solution proposée est le TOFU. Il marche bien pour SSH,
où on se connecte à peu de machines, et dont on connait les
admins. C'est moins évident pour l'accès à des serveurs publics, comme
c'est le cas avec le Web ou Gemini.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [MISC] La "backdoor" de Chrome

[Stephane Bortzmeyer]

On Wed, Apr 07, 2021 at 02:15:50AM +,
 Michel Py via frnog  wrote 
 a message of 43 lines which said:

> Ce qui est un recul en matière de sécurité : le merdiciel contenu
> dans les pubs et autres est en train de devenir impossible à
> inspecter au niveau du pare-feu, ce qui me dérange. Ce qui est
> derrière mon pare-feu, je devrais pouvoir faire de l'interception
> SSL

C'est un peu comme les gouvernements qui disent « on voudrait un
chiffrement qui protège contre les méchants mais laisse les bons
accéder aux messages ». Les maths (et l'informatique) ne fonctionnent
pas comme ça. Soit le système est sûr contre tout le monde, soit il ne
l'est pour personne.

L'interception de communications chiffrées a été tellement abusée
qu'il est logique que de nouvelles mesures soient prises. Attends voir
avec QUIC :-)

> La sécurité c'est comme la lessive : chaque fois qu'il y en a une
> nouvelle, elle lave plus blanc que la précédente; c'est la pub à la
> télé qui le dit, ça doit être vrai. A force, les fringues vont
> devenir transparentes.

Je dirais plutôt : la lutte de l'épée et de la cuirasse est
éternelle. Chaque fois que l'épée se perfectionne, la cuirasse
s'améliore. Et cela ne finira jamais. C'est la grosse différence entre
sécurité et sûreté, où l'ennemi ne s'améliore pas.

> Pour les domaines en .local et quand on va direct avec l'adresse IP
> dans le navigateur, ils pourraient arrêter de nous emmerder, quand
> même.

C'est vrai qu'il n'y a jamais d'attaques portant sur le routage, ou
sur la résolution mDNS.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [MISC] La "backdoor" de Chrome

[Stephane Bortzmeyer]

On Wed, Apr 07, 2021 at 12:00:41AM +0200,
 David Ponzone  wrote 
 a message of 32 lines which said:

> Je sais pas si c’est lié, mais je remarque que les progrès d’HTTPS
> permettent si j’ai bien compris de le rendre non-interceptable,

Je ne vois pas bien à quoi tu fais allusion. Aucune technique de
sécurité n'est parfaite et aucun progrès de HTTPS (de TLS, sans doute,
avec TLS 1.3 ?) ne permet de se protéger contre une attaque de l'homme
du milieu, à part l'authentification (via une AC ou via DANE).


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [MISC] La "backdoor" de Chrome

[Stephane Bortzmeyer]

On Tue, Apr 06, 2021 at 11:05:04PM +0200,
 OB via frnog  wrote 
 a message of 82 lines which said:

> A quoi servent ces restrictions sur les certificats de la part des
> navigateurs ?

Cf. l'excellente réponse de François Lesueur.

> Alors oui, _techniquement_ un certificat auto-signé pourrais être
> remplacé subrepticement par notre FAI, ou par un opérateur
> tiers. Mais est-ce que vous avez déjà rencontré ce cas en pratique ?

Très fréquemment. Maintenant que tout est en HTTPS, beaucoup de
détournements DNS ou BGP se traduisent par une alerte sur le
certificat. Si l'utilisateur est habitué à cliquer « OSEF, on
continue », cette alerte ne servira pas. 

> La plupart des appliances réseau qui utilisent des certificats
> auto-signé (au hasard : Ubiquiti) sont cantonnés sur un LAN,
> accessible que via VPN.

Habituer les utilisateurs à avoir des alertes sur les certificats
n'est pas une bonne idée.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Wallace]

Ok LE c'est génial on l'utilise beaucoup, ce que veut dire Erwan c'est
que beaucoup d'équipements dont les IPMI cités ne sont pas programmables
soit en local (pas de crontab, pas d'os où l'on pourrait déposer un LE)
soit à distance pour pousser de nouveaux certificats.

La seule méthode que je vois actuellement sur les IPMI c'est programmer
un firefox ou chrome headless pour refaire les actions qu'un humain
ferait pour déposer de nouveaux certificats. Mais c'est sortir
l'artillerie lourde pour un élément qui est censé être simple.

Le problème est aussi le même sur différents appliances fermés qui ne te
permettent pas de mettre le nécessaire pour recevoir les certificats.

On pourrait même comparer cela au DNSSEC où les clefs sont censés
tourner régulièrement, dans les faits quand tu gères des domaines sur
plusieurs registres qui ont chacun leurs API différentes et qu'en plus
ils se permettent de ne pas marcher ou refuser tes clefs sans donner de
raisons. La solution la plus viable qu'on a trouvé c'est de mettre une
expiration très longue quitte à sortir des guidelines et mettre 
sous
supervision pour nous rappeler de les changer le moment venu.

Après Chrome ils sont sympas mais j'apprécie pas du tout la direction,
on a bien un Chromium pour faire des tests pour les clients mais on
utilise tous Firefox.

Et puis bon c'est pas comme si Chrome n'était plus du tout recommandé à
l'usage :

https://www.eff.org/deeplinks/2021/03/google-testing-its-controversial-new-ad-targeting-tech-millions-browsers-heres


Le 07/04/2021 à 09:25, Stéphane Rivière a écrit :
>
> Regarde dans les tutos... Je ne dis pas que c'est ce qu'il te faut,
> c'est juste pour t'informer :)
>
>
> J'avais tout une gestion de certs auto-gérés, avec une petite 
applic
> maison. C'était il y a plus de 20 ans. LE m'a changé la vie. C'est
> beaucoup plus simple désormais, pour mon use-case, sans généraliser.
>
>
> En fait n'importe quel système avec une communication sécurisée devrait
> mettre à jour ses clés régulièrement. Il n'y a que les *** de *** pour
> mettre leurs clés radios à jour... tous les deux ans :>
>
> Et c'est vrai manifestement dans plein d'autres secteurs. La gestion des
> clés, c'est une horreur. Les militaires ont des systèmes de gestion
> dédiés et des procédés d'introductions spécifiques pour ce use-case.
>
>
> LE n'est pas pénible en soit parce qu'une maj entre le 2e et 3e de
> validité est obligatoire. Il faut juste mettre en œuvre la bonne manière
> de faire (ça prends du temps à ce moment) et ensuite, ça 
s'oublie.
>
> En termes de sécurité absolue (face à des états) c'est un leurre mais
> pour du commercial et du tout venant c'est au moins l'assurance de ne
> pas voir ses mots de passes et autres données s'étaler sur le 
net.
>
>
> J'aimerai l'équivalent pour le mail : universel et simple (j'ai du 
mal
> avec les clé GPG et Enigmail ;).
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[David Ponzone]

> Le 7 avr. 2021 à 10:28, OB via frnog  a écrit :
> 
> 
> Le fait que chrome ne permettre plus d'outrepasser ce genre de sécurité est à 
> mon sens une décision plus stratégique que technique - à la limite tant mieux 
> pour Firefox, mais bon j'ai déjà des clients qui ont dû changer de 
> navigateurs pour cette raison - et c'est une perte de temps pour eux.
> 

Ben si justement, tu peux avec « thisisunsafe » .
C’est pas pour tout le monde, mais à priori, se connecter sur un équipement 
dont le cert est pas valide, ça doit pas être pour tout le monde.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[OB via frnog]

reBonjour,

Le 07/04/2021 à 08:55, Francois Lesueur a écrit :

Le but du modèle HTTPS/CA, c'est de chiffrer *avec la bonne personne*.

> [...]

C'est un peu comme le déploiement de DNSSEC ou RPKI, tant que ce n'est
pas contraint côté client, ça ne protège pas vraiment des attaques tel
qu'attendu...


Alors justement , autant je suis d'accord avec tout ça dans le cas de 
services disponible directement sur Internet, quitte à "juste" utiliser 
Let's Encrypt.


Autant sur des systèmes qui ne sont accessible que sur le LAN , tel que 
les bornes wifi, les imprimantes, ... bref des services qui pourraient 
tout aussi bien tourner en HTTP finalement, je trouve ça overkill. Je 
vais pas monter un CA pour 3 bornes wifi , une imprimante et la caméra 
d'une TPE derrière une livebox !



Le "trust on first use" de Firefox dont parles Vincent, utilisé depuis 
des année en SSH me parait être un bon compromis.


Le fait que chrome ne permettre plus d'outrepasser ce genre de sécurité 
est à mon sens une décision plus stratégique que technique - à la limite 
tant mieux pour Firefox, mais bon j'ai déjà des clients qui ont dû 
changer de navigateurs pour cette raison - et c'est une perte de temps 
pour eux.


En tous cas merci pour vos réponses.

Julien


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Vincent Bernat]

 ❦  7 avril 2021 08:45 +02, Francois Lesueur:

>> Ce qui est super chiant quand tu développes (car tu bosses généralement avec 
>> de l'auto signé)
>
> Pour les certificats de dév, il y a mkcert
> (https://github.com/FiloSottile/mkcert) qui est super et exprès pour ça
> : création d'une CA locale et installation sur le système/les browsers
> en une ligne, puis création d'un certif signé par cette CA en une autre
> ligne, et zou !

Ce n'est pas forcément la panacée non plus. On se retrouve avec un
certificat racine qui permet d'intercepter tout le trafic HTTPS.
Certains auront vite fait de se partager une CA déjà générée. C'est bien
signalé dans le README, mais il faut sans doute bien faire l'éducation
des users sur le sujet.

Il serait pas mal de limiter la validité de la CA à un domaine
particulier avec l'extension Named Constraints.

> Pour aller un poil plus loin, la suite smallstep est top :
> https://smallstep.com/docs/step-ca/getting-started . Ça permet de
> générer une vraie CA, il y aussi une commande pour l'installer
> proprement sur les browsers locaux, puis les certifs. Ça fait même du
> ACME (protocole de Let's Encrypt) :
> https://smallstep.com/docs/tutorials/acme-challenge

Ça a effectivement l'air très sympathique comme produit ! Merci du lien !
-- 
Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plauger)


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Daniel via frnog]

Bonjour

Le 07/04/2021 à 10:04, Oliver varenne a écrit :

Oui merci je sais créer un cert letsencrypt ou autres astuces type import de CA 
etc.
J'utilise généralement firefox

Néanmoins, quand tu as besoin de créer 4 ou 5 VM différentes, juste pour 3h de 
test, tu as pas envie de t'emmerder 600 fois dans la journée
Tu utilise les certs autosignés présents dans tes applications de test et voila.
Un certificat DNS-01 qui protège également les sous domaines et le tour 
est joué, non ?

[...]


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de
Vincent Habchi
Envoyé : mardi 6 avril 2021 21:59
À : Vincent Tondellier 
Cc : frnog@frnog.org
Objet : Re: [FRnOG] [MISC] La "backdoor" de Chrome



On 6 Apr 2021, at 21:05, Vincent Tondellier via frnog 

wrote:

Ou utiliser firefox …

Real PHP developers use curl :)

V.

PS : avec certbot, c’est assez facile de se créer des certificats un peu à
volonté et de les rendre quand on n’en veut plus.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/


--
Daniel


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Thomas Schweizer-Bolzonello via frnog]

On Wed, 7 Apr 2021 at 11:05, Oliver varenne  wrote:
>
> Oui merci je sais créer un cert letsencrypt ou autres astuces type import de 
> CA etc.
> J'utilise généralement firefox
>
> Néanmoins, quand tu as besoin de créer 4 ou 5 VM différentes, juste pour 3h 
> de test, tu as pas envie de t'emmerder 600 fois dans la journée
> Tu utilise les certs autosignés présents dans tes applications de test et 
> voila.
>
> Enfin bref, moi ça me gonfle.
>
>
>
> Cordialement,
>
>
>
> Olivier Varenne
> Co-gérant, Commercial & Développeur
> T +33 (0)4 27 04 40 00 | ipconnect.fr
>
> Suivez-nous !
>
>
>
>
> > -Message d'origine-
> > De : frnog-requ...@frnog.org  De la part de
> > Vincent Habchi
> > Envoyé : mardi 6 avril 2021 21:59
> > À : Vincent Tondellier 
> > Cc : frnog@frnog.org
> > Objet : Re: [FRnOG] [MISC] La "backdoor" de Chrome
> >
> >
> > > On 6 Apr 2021, at 21:05, Vincent Tondellier via frnog 
> > wrote:
> > >
> > > Ou utiliser firefox …
> >
> > Real PHP developers use curl :)
> >
> > V.
> >
> > PS : avec certbot, c’est assez facile de se créer des certificats un peu à
> > volonté et de les rendre quand on n’en veut plus.
> >
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

Sous Chrome, il y'a possibilité d'activer la fonction "Allow invalid
certificates for resources loaded from localhost" pour ne pas trop
s'embêter avec les certificates auto-signés et autres imports d'AC
maison tant que les ressources sont locales à la machine:
chrome://flags/#allow-insecure-localhost

-Thomas


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Vincent Bernat]

 ❦  7 avril 2021 08:55 +02, Francois Lesueur:

>> Auto-signé ou pas c'est au moins chiffré, ce qui permet d'éviter
>> l'evedropping passif.
>
> Le but du modèle HTTPS/CA, c'est de chiffrer *avec la bonne personne*.
> L'auto-signé évite certes l'attaque purement passive, mais le but du
> protocole et de son déploiement, c'est de t'assurer que tu échanges bien
> de manière sécurisée avec le bon interlocuteur. Avec l'auto-signé, tu
> chiffres, mais tu n'as aucun moyen de savoir si tu chiffres entre toi et
> l'attaquant (en MitM, qui re-chiffre ensuite pour ta destination mais
> voit le contenu donc) ou entre toi et ta destination (crypto
> bout-en-bout).

L'auto-signé fonctionne désormais en mode "trust on first use", comme
SSH. Cela apporte donc une authentification partielle. Dans Firefox, le
hash du certificat est stocké dans "cert_override.txt" dans le profil de
l'utilisateur.
-- 
A horse!  A horse!  My kingdom for a horse!
-- Wm. Shakespeare, "Richard III"


---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [Tech] Optimisation bascule BGP arista

[Julien OHAYON]

Je confirme, "bgp additional-paths install" c'est magique pour ne pas attendre 
20 min.


Une petite doc pour optimiser le tout : https://eos.arista.com/inet-edge-config/




Arista EOS Central - Configurations and Optimizations for Internet Edge 
Routing
eos.arista.com
ContentsIntroductionA Note on 32 vs. 64 Bit EOSArista Multi-Agent BGP 
ConfigurationArista FlexRoute ConfigurationChanging ACL ImplementationAdjusting 
show tech-support OutputsISP Peering Configurations and OptimizationValidating 
Hardware before AdvertisingEnabling Fast Failure Detection with BFDEnabling 
missing route-map handling (RFC 8212 behavior)Removing Private BGP ASNsEnabling 
BGP CommunitiesAdjusting community processing orderAdjusting BGP Maximum-Routes 
ValueFiltering Extraneous or Malicious RoutesBGP Prefix Independent 
ConvergenceResource Public... Continue reading →




De : frnog-requ...@frnog.org  de la part de Pierre 
LANCASTRE 
Envoyé : mercredi 7 avril 2021 09:56:01
À : Laurent Laurent
Cc : David Ponzone; Clement Cavadore; FRnOG
Objet : Re: [FRnOG] [Tech] Optimisation bascule BGP arista

Hello

Tu peux explorer la piste du pic-edge pour préinstaller en FIB le backup
path

router bgp 
bgp additional-paths install

Tu devrais avoir tes routes comme suit :

* > x.x.x.x/yy 
* b x.x.x.x/yy 

J'ai pas encore testé avec un full feed mais en principe ça fonctionne.

En tout cas en lab ca fait le boulot

++

Pierre


Le mer. 7 avr. 2021 à 09:42, Laurent Laurent 
a écrit :

> Je n'ai pas encore ouvert un ticket chez Arista car on est passé par un
> intégrateur et lui est au courant, ça va être la prochaine étape ;)
>
> Voici le sh ip bgp summary de l'arista 2 :
>
>   Description Neighbor V  AS   MsgRcvd
> MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
>   Operateur 2xx.xx.xx.xx  4  x   17670891
>  53466800   27d23h Estab   833592 833527
>   arista-1 198.18.255.1 4  x   20127835
> 365120500   27d23h Estab   827988 827988
>
> On voit que le arista 2 possède presque toutes les routes via l'ibgp.
>
> Merci encore pour votre aide.
>
> Le mer. 7 avr. 2021 à 09:30, David Ponzone  a
> écrit :
>
> > Tu peux envoyer le sh ip bgp sum de arista2, au cas où.
> >
> > Tu as ouvert un case chez Arista ? C’est peut-être un bug connu chez eux.
> >
> > Le 7 avr. 2021 à 09:25, Laurent Laurent  a
> > écrit :
> >
> > J'ai peur aussi que ce soit le cas, mais pas forcément la partie BGP mais
> > plus la partie hardware.
> >
> >   Description  Neighbor V  AS   MsgRcvd
> > MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
> >   Operateur1   xx.xx.xx.xxx4  X1586
> >  14998200   12:30:04 Estab   827948 827948
> >   Arista2  198.18.255.2   4  X3080607
> >  162422170027d23h Estab   5915   5915
> >
> > Quand on regarde la table de routage, j'apprends en IPv4 environs 830 000
> > routes et je n'ai que 5915 routes via l'iBGP. Si mon opérateur 1 tombe,
> il
> > faut bien 2mns40 à l'arista 1 pour avoir les 830 000 routes, je pense que
> > mon soucis vient de la, mais comment réussir a accélérer ça? Ça se trouve
> > ce n'est pas possible et la seule solution serait de ne plus avoir d'iBGP
> > et d'avoir un lien actif/passif :(
> >
> >
> > Le mer. 7 avr. 2021 à 09:16, David Ponzone  a
> > écrit :
> >
> >> Hmmm comme ça, j’ai envie de dire que le BGP de l’Arista est en mousse,
> >> mais juste parce que sans trop chercher, je vois pas de raison que ça
> mette
> >> tout ce temps.
> >> Ca devrait être 30 sec.
> >>
> >> > Le 7 avr. 2021 à 09:12, Laurent Laurent 
> >> a écrit :
> >> >
> >> > Bonjour Clément, merci pour ta réponse.
> >> >
> >> > La bascule que j'ai mise en place n'est pas pour la partie LAN. Les 2
> >> liens
> >> > opérateur sont actif/actif. Si le lien opérateur 1 tombe (l'interface
> >> passe
> >> > down) sans bascule du vrrp le chemin va bien être : lan arista 1 -->
> >> ibgp
> >> > --> arista 2 --> opérateur 2, sauf que ça met 6 mns avant que le
> >> routage re
> >> > fonctionne.
> >> > En basculant le vrrp je gagne gagne du temps, le temps que l'ibgp de
> >> > l'arista 1 réapprenne toutes les routes via l'ibgp de l'arista 2 et
> >> c'est
> >> > un gain de temps énorme de presque 3 minutes. Je comprends que ça va à
> >> > l'encontre de l'ibgp, car nous devrions pas avoir besoin de le faire,
> >> mais
> >> > nous avons besoin que le routage fonctionne très rapidement si le lien
> >> > opérateur 1 passe down.
> >> >
> >>
> >>
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [MISC] La "backdoor" de Chrome

[Oliver varenne]

Ha merci, vais y jeter un oeil



Cordialement,
 


Olivier Varenne
Co-gérant, Commercial & Développeur
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous ! 




> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Francois Lesueur
> Envoyé : mercredi 7 avril 2021 08:46
> À : frnog@frnog.org
> Objet : Re: [FRnOG] [MISC] La "backdoor" de Chrome
> 
> 
> Bonjour,
> 
> Le 06/04/2021 à 20:19, Oliver varenne a écrit :
> > Ce qui est super chiant quand tu développes (car tu bosses
> > généralement avec de l'auto signé)
> 
> Pour les certificats de dév, il y a mkcert
> (https://github.com/FiloSottile/mkcert) qui est super et exprès pour ça
> : création d'une CA locale et installation sur le système/les browsers en
> une ligne, puis création d'un certif signé par cette CA en une autre ligne,
> et zou !
> 
> Pour aller un poil plus loin, la suite smallstep est top :
> https://smallstep.com/docs/step-ca/getting-started . Ça permet de
> générer une vraie CA, il y aussi une commande pour l'installer proprement
> sur les browsers locaux, puis les certifs. Ça fait même du ACME (protocole
> de Let's Encrypt) :
> https://smallstep.com/docs/tutorials/acme-challenge
> 
> Dans les 2 cas, ça se joue en 2 lignes (plutôt mkcert pour du certif de dév,
> plutôt smallstep pour une CA locale) et, surtout, sans aucun appel/config
> à openssl, ça change un peu la vie côté CA !
> 
> Bonne journée
> François
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [MISC] La "backdoor" de Chrome

[Oliver varenne]

Oui merci je sais créer un cert letsencrypt ou autres astuces type import de CA 
etc.
J'utilise généralement firefox

Néanmoins, quand tu as besoin de créer 4 ou 5 VM différentes, juste pour 3h de 
test, tu as pas envie de t'emmerder 600 fois dans la journée
Tu utilise les certs autosignés présents dans tes applications de test et voila.

Enfin bref, moi ça me gonfle.



Cordialement,
 


Olivier Varenne
Co-gérant, Commercial & Développeur
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous ! 




> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Vincent Habchi
> Envoyé : mardi 6 avril 2021 21:59
> À : Vincent Tondellier 
> Cc : frnog@frnog.org
> Objet : Re: [FRnOG] [MISC] La "backdoor" de Chrome
> 
> 
> > On 6 Apr 2021, at 21:05, Vincent Tondellier via frnog 
> wrote:
> >
> > Ou utiliser firefox …
> 
> Real PHP developers use curl :)
> 
> V.
> 
> PS : avec certbot, c’est assez facile de se créer des certificats un peu à
> volonté et de les rendre quand on n’en veut plus.
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Pierre LANCASTRE]

Hello

Tu peux explorer la piste du pic-edge pour préinstaller en FIB le backup
path

router bgp 
bgp additional-paths install

Tu devrais avoir tes routes comme suit :

* > x.x.x.x/yy 
* b x.x.x.x/yy 

J'ai pas encore testé avec un full feed mais en principe ça fonctionne.

En tout cas en lab ca fait le boulot

++

Pierre


Le mer. 7 avr. 2021 à 09:42, Laurent Laurent 
a écrit :

> Je n'ai pas encore ouvert un ticket chez Arista car on est passé par un
> intégrateur et lui est au courant, ça va être la prochaine étape ;)
>
> Voici le sh ip bgp summary de l'arista 2 :
>
>   Description Neighbor V  AS   MsgRcvd
> MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
>   Operateur 2xx.xx.xx.xx  4  x   17670891
>  53466800   27d23h Estab   833592 833527
>   arista-1 198.18.255.1 4  x   20127835
> 365120500   27d23h Estab   827988 827988
>
> On voit que le arista 2 possède presque toutes les routes via l'ibgp.
>
> Merci encore pour votre aide.
>
> Le mer. 7 avr. 2021 à 09:30, David Ponzone  a
> écrit :
>
> > Tu peux envoyer le sh ip bgp sum de arista2, au cas où.
> >
> > Tu as ouvert un case chez Arista ? C’est peut-être un bug connu chez eux.
> >
> > Le 7 avr. 2021 à 09:25, Laurent Laurent  a
> > écrit :
> >
> > J'ai peur aussi que ce soit le cas, mais pas forcément la partie BGP mais
> > plus la partie hardware.
> >
> >   Description  Neighbor V  AS   MsgRcvd
> > MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
> >   Operateur1   xx.xx.xx.xxx4  X1586
> >  14998200   12:30:04 Estab   827948 827948
> >   Arista2  198.18.255.2   4  X3080607
> >  162422170027d23h Estab   5915   5915
> >
> > Quand on regarde la table de routage, j'apprends en IPv4 environs 830 000
> > routes et je n'ai que 5915 routes via l'iBGP. Si mon opérateur 1 tombe,
> il
> > faut bien 2mns40 à l'arista 1 pour avoir les 830 000 routes, je pense que
> > mon soucis vient de la, mais comment réussir a accélérer ça? Ça se trouve
> > ce n'est pas possible et la seule solution serait de ne plus avoir d'iBGP
> > et d'avoir un lien actif/passif :(
> >
> >
> > Le mer. 7 avr. 2021 à 09:16, David Ponzone  a
> > écrit :
> >
> >> Hmmm comme ça, j’ai envie de dire que le BGP de l’Arista est en mousse,
> >> mais juste parce que sans trop chercher, je vois pas de raison que ça
> mette
> >> tout ce temps.
> >> Ca devrait être 30 sec.
> >>
> >> > Le 7 avr. 2021 à 09:12, Laurent Laurent 
> >> a écrit :
> >> >
> >> > Bonjour Clément, merci pour ta réponse.
> >> >
> >> > La bascule que j'ai mise en place n'est pas pour la partie LAN. Les 2
> >> liens
> >> > opérateur sont actif/actif. Si le lien opérateur 1 tombe (l'interface
> >> passe
> >> > down) sans bascule du vrrp le chemin va bien être : lan arista 1 -->
> >> ibgp
> >> > --> arista 2 --> opérateur 2, sauf que ça met 6 mns avant que le
> >> routage re
> >> > fonctionne.
> >> > En basculant le vrrp je gagne gagne du temps, le temps que l'ibgp de
> >> > l'arista 1 réapprenne toutes les routes via l'ibgp de l'arista 2 et
> >> c'est
> >> > un gain de temps énorme de presque 3 minutes. Je comprends que ça va à
> >> > l'encontre de l'ibgp, car nous devrions pas avoir besoin de le faire,
> >> mais
> >> > nous avons besoin que le routage fonctionne très rapidement si le lien
> >> > opérateur 1 passe down.
> >> >
> >>
> >>
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Jérôme Marteaux]

Si tu es dans un scénario master/backup, au lieu d'apprendre toutes les 
routes tu peux n'apprendre que la default, tu vas converger beaucoup 
beaucoup plus vite.
Libre à toi d'ajouter quelques routes plus spécifiques à cette default 
pour optimiser un peu ton routage (genre par exemple les AS directement 
connectés à tes transitaires) ou en ajoutant un IX.


Jérôme

Le 07/04/2021 à 09:40, Laurent Laurent a écrit :

Je n'ai pas encore ouvert un ticket chez Arista car on est passé par un
intégrateur et lui est au courant, ça va être la prochaine étape ;)

Voici le sh ip bgp summary de l'arista 2 :

   Description Neighbor V  AS   MsgRcvd
MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
   Operateur 2xx.xx.xx.xx  4  x   17670891
  53466800   27d23h Estab   833592 833527
   arista-1 198.18.255.1 4  x   20127835
365120500   27d23h Estab   827988 827988

On voit que le arista 2 possède presque toutes les routes via l'ibgp.

Merci encore pour votre aide.



--
Jérôme Marteaux


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[David Ponzone]

J’ai envie de te proposer de mettre ton arista2 en default gw, comme solution 
tempo :)
Ca te fera un saut de plus en temps normal, mais pas à attendre la convergence 
quand Opérateur1 est HS.

> Le 7 avr. 2021 à 09:40, Laurent Laurent  a écrit 
> :
> 
> Je n'ai pas encore ouvert un ticket chez Arista car on est passé par un 
> intégrateur et lui est au courant, ça va être la prochaine étape ;)
> 
> Voici le sh ip bgp summary de l'arista 2 : 
> 
>   Description Neighbor V  AS   MsgRcvd   
> MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
>   Operateur 2xx.xx.xx.xx  4  x   17670891
> 53466800   27d23h Estab   833592 833527
>   arista-1 198.18.255.1 4  x   20127835   
> 365120500   27d23h Estab   827988 827988
> 
> On voit que le arista 2 possède presque toutes les routes via l'ibgp.
> 
> Merci encore pour votre aide.
> 
> Le mer. 7 avr. 2021 à 09:30, David Ponzone  > a écrit :
> Tu peux envoyer le sh ip bgp sum de arista2, au cas où.
> 
> Tu as ouvert un case chez Arista ? C’est peut-être un bug connu chez eux.
> 
>> Le 7 avr. 2021 à 09:25, Laurent Laurent > > a écrit :
>> 
>> J'ai peur aussi que ce soit le cas, mais pas forcément la partie BGP mais 
>> plus la partie hardware.
>> 
>>   Description  Neighbor V  AS   MsgRcvd   
>> MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
>>   Operateur1   xx.xx.xx.xxx4  X1586
>> 14998200   12:30:04 Estab   827948 827948
>>   Arista2  198.18.255.2   4  X3080607  
>> 162422170027d23h Estab   5915   5915
>> 
>> Quand on regarde la table de routage, j'apprends en IPv4 environs 830 000 
>> routes et je n'ai que 5915 routes via l'iBGP. Si mon opérateur 1 tombe, il 
>> faut bien 2mns40 à l'arista 1 pour avoir les 830 000 routes, je pense que 
>> mon soucis vient de la, mais comment réussir a accélérer ça? Ça se trouve ce 
>> n'est pas possible et la seule solution serait de ne plus avoir d'iBGP et 
>> d'avoir un lien actif/passif :(
>> 
>> 
>> Le mer. 7 avr. 2021 à 09:16, David Ponzone > > a écrit :
>> Hmmm comme ça, j’ai envie de dire que le BGP de l’Arista est en mousse, mais 
>> juste parce que sans trop chercher, je vois pas de raison que ça mette tout 
>> ce temps.
>> Ca devrait être 30 sec.
>> 
>> > Le 7 avr. 2021 à 09:12, Laurent Laurent > > > a écrit :
>> > 
>> > Bonjour Clément, merci pour ta réponse.
>> > 
>> > La bascule que j'ai mise en place n'est pas pour la partie LAN. Les 2 liens
>> > opérateur sont actif/actif. Si le lien opérateur 1 tombe (l'interface passe
>> > down) sans bascule du vrrp le chemin va bien être : lan arista 1 --> ibgp
>> > --> arista 2 --> opérateur 2, sauf que ça met 6 mns avant que le routage re
>> > fonctionne.
>> > En basculant le vrrp je gagne gagne du temps, le temps que l'ibgp de
>> > l'arista 1 réapprenne toutes les routes via l'ibgp de l'arista 2 et c'est
>> > un gain de temps énorme de presque 3 minutes. Je comprends que ça va à
>> > l'encontre de l'ibgp, car nous devrions pas avoir besoin de le faire, mais
>> > nous avons besoin que le routage fonctionne très rapidement si le lien
>> > opérateur 1 passe down.
>> > 
>> 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Laurent Laurent]

Je n'ai pas encore ouvert un ticket chez Arista car on est passé par un
intégrateur et lui est au courant, ça va être la prochaine étape ;)

Voici le sh ip bgp summary de l'arista 2 :

  Description Neighbor V  AS   MsgRcvd
MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  Operateur 2xx.xx.xx.xx  4  x   17670891
 53466800   27d23h Estab   833592 833527
  arista-1 198.18.255.1 4  x   20127835
365120500   27d23h Estab   827988 827988

On voit que le arista 2 possède presque toutes les routes via l'ibgp.

Merci encore pour votre aide.

Le mer. 7 avr. 2021 à 09:30, David Ponzone  a
écrit :

> Tu peux envoyer le sh ip bgp sum de arista2, au cas où.
>
> Tu as ouvert un case chez Arista ? C’est peut-être un bug connu chez eux.
>
> Le 7 avr. 2021 à 09:25, Laurent Laurent  a
> écrit :
>
> J'ai peur aussi que ce soit le cas, mais pas forcément la partie BGP mais
> plus la partie hardware.
>
>   Description  Neighbor V  AS   MsgRcvd
> MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
>   Operateur1   xx.xx.xx.xxx4  X1586
>  14998200   12:30:04 Estab   827948 827948
>   Arista2  198.18.255.2   4  X3080607
>  162422170027d23h Estab   5915   5915
>
> Quand on regarde la table de routage, j'apprends en IPv4 environs 830 000
> routes et je n'ai que 5915 routes via l'iBGP. Si mon opérateur 1 tombe, il
> faut bien 2mns40 à l'arista 1 pour avoir les 830 000 routes, je pense que
> mon soucis vient de la, mais comment réussir a accélérer ça? Ça se trouve
> ce n'est pas possible et la seule solution serait de ne plus avoir d'iBGP
> et d'avoir un lien actif/passif :(
>
>
> Le mer. 7 avr. 2021 à 09:16, David Ponzone  a
> écrit :
>
>> Hmmm comme ça, j’ai envie de dire que le BGP de l’Arista est en mousse,
>> mais juste parce que sans trop chercher, je vois pas de raison que ça mette
>> tout ce temps.
>> Ca devrait être 30 sec.
>>
>> > Le 7 avr. 2021 à 09:12, Laurent Laurent 
>> a écrit :
>> >
>> > Bonjour Clément, merci pour ta réponse.
>> >
>> > La bascule que j'ai mise en place n'est pas pour la partie LAN. Les 2
>> liens
>> > opérateur sont actif/actif. Si le lien opérateur 1 tombe (l'interface
>> passe
>> > down) sans bascule du vrrp le chemin va bien être : lan arista 1 -->
>> ibgp
>> > --> arista 2 --> opérateur 2, sauf que ça met 6 mns avant que le
>> routage re
>> > fonctionne.
>> > En basculant le vrrp je gagne gagne du temps, le temps que l'ibgp de
>> > l'arista 1 réapprenne toutes les routes via l'ibgp de l'arista 2 et
>> c'est
>> > un gain de temps énorme de presque 3 minutes. Je comprends que ça va à
>> > l'encontre de l'ibgp, car nous devrions pas avoir besoin de le faire,
>> mais
>> > nous avons besoin que le routage fonctionne très rapidement si le lien
>> > opérateur 1 passe down.
>> >
>>
>>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[David Ponzone]

Tu peux envoyer le sh ip bgp sum de arista2, au cas où.

Tu as ouvert un case chez Arista ? C’est peut-être un bug connu chez eux.

> Le 7 avr. 2021 à 09:25, Laurent Laurent  a écrit 
> :
> 
> J'ai peur aussi que ce soit le cas, mais pas forcément la partie BGP mais 
> plus la partie hardware.
> 
>   Description  Neighbor V  AS   MsgRcvd   
> MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
>   Operateur1   xx.xx.xx.xxx4  X1586149982 
>00   12:30:04 Estab   827948 827948
>   Arista2  198.18.255.2   4  X3080607  
> 162422170027d23h Estab   5915   5915
> 
> Quand on regarde la table de routage, j'apprends en IPv4 environs 830 000 
> routes et je n'ai que 5915 routes via l'iBGP. Si mon opérateur 1 tombe, il 
> faut bien 2mns40 à l'arista 1 pour avoir les 830 000 routes, je pense que mon 
> soucis vient de la, mais comment réussir a accélérer ça? Ça se trouve ce 
> n'est pas possible et la seule solution serait de ne plus avoir d'iBGP et 
> d'avoir un lien actif/passif :(
> 
> 
> Le mer. 7 avr. 2021 à 09:16, David Ponzone  > a écrit :
> Hmmm comme ça, j’ai envie de dire que le BGP de l’Arista est en mousse, mais 
> juste parce que sans trop chercher, je vois pas de raison que ça mette tout 
> ce temps.
> Ca devrait être 30 sec.
> 
> > Le 7 avr. 2021 à 09:12, Laurent Laurent  > > a écrit :
> > 
> > Bonjour Clément, merci pour ta réponse.
> > 
> > La bascule que j'ai mise en place n'est pas pour la partie LAN. Les 2 liens
> > opérateur sont actif/actif. Si le lien opérateur 1 tombe (l'interface passe
> > down) sans bascule du vrrp le chemin va bien être : lan arista 1 --> ibgp
> > --> arista 2 --> opérateur 2, sauf que ça met 6 mns avant que le routage re
> > fonctionne.
> > En basculant le vrrp je gagne gagne du temps, le temps que l'ibgp de
> > l'arista 1 réapprenne toutes les routes via l'ibgp de l'arista 2 et c'est
> > un gain de temps énorme de presque 3 minutes. Je comprends que ça va à
> > l'encontre de l'ibgp, car nous devrions pas avoir besoin de le faire, mais
> > nous avons besoin que le routage fonctionne très rapidement si le lien
> > opérateur 1 passe down.
> > 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Stéphane Rivière]

Le 07/04/2021 à 08:45, Francois Lesueur a écrit :

Merci François pour ces liens :)

-- 
Be Seeing You
Number Six


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Laurent Laurent]

J'ai peur aussi que ce soit le cas, mais pas forcément la partie BGP mais
plus la partie hardware.

  Description  Neighbor V  AS   MsgRcvd
MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  Operateur1   xx.xx.xx.xxx4  X1586
 14998200   12:30:04 Estab   827948 827948
  Arista2  198.18.255.2   4  X3080607
 162422170027d23h Estab   5915   5915

Quand on regarde la table de routage, j'apprends en IPv4 environs 830 000
routes et je n'ai que 5915 routes via l'iBGP. Si mon opérateur 1 tombe, il
faut bien 2mns40 à l'arista 1 pour avoir les 830 000 routes, je pense que
mon soucis vient de la, mais comment réussir a accélérer ça? Ça se trouve
ce n'est pas possible et la seule solution serait de ne plus avoir d'iBGP
et d'avoir un lien actif/passif :(


Le mer. 7 avr. 2021 à 09:16, David Ponzone  a
écrit :

> Hmmm comme ça, j’ai envie de dire que le BGP de l’Arista est en mousse,
> mais juste parce que sans trop chercher, je vois pas de raison que ça mette
> tout ce temps.
> Ca devrait être 30 sec.
>
> > Le 7 avr. 2021 à 09:12, Laurent Laurent  a
> écrit :
> >
> > Bonjour Clément, merci pour ta réponse.
> >
> > La bascule que j'ai mise en place n'est pas pour la partie LAN. Les 2
> liens
> > opérateur sont actif/actif. Si le lien opérateur 1 tombe (l'interface
> passe
> > down) sans bascule du vrrp le chemin va bien être : lan arista 1 --> ibgp
> > --> arista 2 --> opérateur 2, sauf que ça met 6 mns avant que le routage
> re
> > fonctionne.
> > En basculant le vrrp je gagne gagne du temps, le temps que l'ibgp de
> > l'arista 1 réapprenne toutes les routes via l'ibgp de l'arista 2 et c'est
> > un gain de temps énorme de presque 3 minutes. Je comprends que ça va à
> > l'encontre de l'ibgp, car nous devrions pas avoir besoin de le faire,
> mais
> > nous avons besoin que le routage fonctionne très rapidement si le lien
> > opérateur 1 passe down.
> >
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Stéphane Rivière]

> Et tu le déploie sur tes ILO/iDRAC/CIMC (j'ai cité 3 marques c'est OK
> pour le CSA) ? 

:)))

>Tous les 2 mois et demi...

Regarde dans les tutos... Je ne dis pas que c'est ce qu'il te faut,
c'est juste pour t'informer :)


J'avais tout une gestion de certs auto-gérés, avec une petite applic
maison. C'était il y a plus de 20 ans. LE m'a changé la vie. C'est
beaucoup plus simple désormais, pour mon use-case, sans généraliser.


En fait n'importe quel système avec une communication sécurisée devrait
mettre à jour ses clés régulièrement. Il n'y a que les *** de *** pour
mettre leurs clés radios à jour... tous les deux ans :>

Et c'est vrai manifestement dans plein d'autres secteurs. La gestion des
clés, c'est une horreur. Les militaires ont des systèmes de gestion
dédiés et des procédés d'introductions spécifiques pour ce use-case.


LE n'est pas pénible en soit parce qu'une maj entre le 2e et 3e de
validité est obligatoire. Il faut juste mettre en œuvre la bonne manière
de faire (ça prends du temps à ce moment) et ensuite, ça s'oublie.

En termes de sécurité absolue (face à des états) c'est un leurre mais
pour du commercial et du tout venant c'est au moins l'assurance de ne
pas voir ses mots de passes et autres données s'étaler sur le net.


J'aimerai l'équivalent pour le mail : universel et simple (j'ai du mal
avec les clé GPG et Enigmail ;).


-- 
Be Seeing You
Number Six


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Clement Cavadore]

Je dirais la même chose à vue de nez, ou le BGP du transitaire en
face. 

Après, ca peut vouloir aussi dire que les liens de transit ont un L2
entre les deux routeurs qui portent le BGP, et donc qu'un état de lien
n'est pas actif entre les deux. Voir peut être si tu ne peux pas faire
du BGP BFD avec tes transitaires, ou si lui même ne peut pas baisser
ses timers BGP ?


Clément

Le mercredi 07 avril 2021 à 09:16 +0200, David Ponzone a écrit :
> Hmmm comme ça, j’ai envie de dire que le BGP de l’Arista est en
> mousse, mais juste parce que sans trop chercher, je vois pas de
> raison que ça mette tout ce temps.
> Ca devrait être 30 sec.
> 
> > Le 7 avr. 2021 à 09:12, Laurent Laurent <
> > laurent.lecomt...@gmail.com> a écrit :
> > 
> > Bonjour Clément, merci pour ta réponse.
> > 
> > La bascule que j'ai mise en place n'est pas pour la partie LAN. Les
> > 2 liens
> > opérateur sont actif/actif. Si le lien opérateur 1 tombe
> > (l'interface passe
> > down) sans bascule du vrrp le chemin va bien être : lan arista 1 --
> > > ibgp
> > --> arista 2 --> opérateur 2, sauf que ça met 6 mns avant que le
> > routage re
> > fonctionne.
> > En basculant le vrrp je gagne gagne du temps, le temps que l'ibgp
> > de
> > l'arista 1 réapprenne toutes les routes via l'ibgp de l'arista 2 et
> > c'est
> > un gain de temps énorme de presque 3 minutes. Je comprends que ça
> > va à
> > l'encontre de l'ibgp, car nous devrions pas avoir besoin de le
> > faire, mais
> > nous avons besoin que le routage fonctionne très rapidement si le
> > lien
> > opérateur 1 passe down.
> > 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[David Ponzone]

Hmmm comme ça, j’ai envie de dire que le BGP de l’Arista est en mousse, mais 
juste parce que sans trop chercher, je vois pas de raison que ça mette tout ce 
temps.
Ca devrait être 30 sec.

> Le 7 avr. 2021 à 09:12, Laurent Laurent  a écrit 
> :
> 
> Bonjour Clément, merci pour ta réponse.
> 
> La bascule que j'ai mise en place n'est pas pour la partie LAN. Les 2 liens
> opérateur sont actif/actif. Si le lien opérateur 1 tombe (l'interface passe
> down) sans bascule du vrrp le chemin va bien être : lan arista 1 --> ibgp
> --> arista 2 --> opérateur 2, sauf que ça met 6 mns avant que le routage re
> fonctionne.
> En basculant le vrrp je gagne gagne du temps, le temps que l'ibgp de
> l'arista 1 réapprenne toutes les routes via l'ibgp de l'arista 2 et c'est
> un gain de temps énorme de presque 3 minutes. Je comprends que ça va à
> l'encontre de l'ibgp, car nous devrions pas avoir besoin de le faire, mais
> nous avons besoin que le routage fonctionne très rapidement si le lien
> opérateur 1 passe down.
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Laurent Laurent]

Bonjour Clément, merci pour ta réponse.

La bascule que j'ai mise en place n'est pas pour la partie LAN. Les 2 liens
opérateur sont actif/actif. Si le lien opérateur 1 tombe (l'interface passe
down) sans bascule du vrrp le chemin va bien être : lan arista 1 --> ibgp
--> arista 2 --> opérateur 2, sauf que ça met 6 mns avant que le routage re
fonctionne.
En basculant le vrrp je gagne gagne du temps, le temps que l'ibgp de
l'arista 1 réapprenne toutes les routes via l'ibgp de l'arista 2 et c'est
un gain de temps énorme de presque 3 minutes. Je comprends que ça va à
l'encontre de l'ibgp, car nous devrions pas avoir besoin de le faire, mais
nous avons besoin que le routage fonctionne très rapidement si le lien
opérateur 1 passe down.

J'espère avoir été un peu plus clair :)

Le mer. 7 avr. 2021 à 09:00, Clement Cavadore  a
écrit :

> Bonjour Laurent,
>
> Le mercredi 07 avril 2021 à 08:49 +0200, Laurent Laurent a écrit :
> > Mon contexte : Nous avons nos propre AS v4 et v6. Nous avons un
> > Operateur 1 qui arrive sur mon arista 1, et un opérateur 2 qui arrive
> > sur mon arista 2.
> > Entre les arista il y a un lien pour faire de l'iBGP.
>
> Un setup classique en somme.
>
> > Avant de mettre en place les arista nous avions comme routeur bgp un
> > openbsd avec du bgpd, nous n'avions pas d'ibgp entre les openbsd,
> > nous avions du carp pour la bascule lan. Lorsque nous basculions sur
> > le lien de secours, la bascule bgp se faisait en quelques secondes.
>
> Sans IBGP entre les deux OBSD, on comprend le besoin de bascule BGP.
>
> > Maintenant que nous sommes passés sur arista, la bascule BGP est très
> > longue (dans les 6mns), j'ai modifié les timers bgp en 5 15 et j'ai
> > ajouté un track sur l'interface de connexion de l'opérateur 1 pour si
> > le lien tombe le vrrp bascule, suite à ses 2 modifications ma bascule
> > se fait en 3minutes, c'est mieux mais encore trop long.
> >
> > Mon besoin : Auriez-vous des pistes, d'autres timer à modifier pour
> > accélérer cette bascule? J'ai l'impression que le routage commence à
> > fonctionner lorsque la table de l'iBGP de l'arista 1 a récupérée
> > toutes les routes (car on récupère toute la table bgp, v4 et v6 ).
> > Est-ce que l'iBGP est utile dans mon cas? Dois-je le garder?
>
> En vrai, je ne comprends pas pourquoi tu cherches à faire une bascule
> BGP en cas de bascule LAN ? Pourquoi ne pas laisser tourner les deux
> liaisons BGP en même temps en actif/actif ? Ton IBGP est justement là
> pour que les routes les meilleures, sur chacun des deux transits,
> soient choisies par les routeurs.
>
> Et en cas de bascule VRRP entre Arista1 et Arista2, au pire, les flux
> feront Arista2->Arista1->Operateur1, et vice versa dans le cas ou
> Arista1 est master. Forcer une bascule eBGP en cas de bascule VRRP, ce
> ne me semble pas être une bonne idée.
>
> --
> Clément Cavadore
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Clement Cavadore]

Bonjour Laurent,

Le mercredi 07 avril 2021 à 08:49 +0200, Laurent Laurent a écrit :
> Mon contexte : Nous avons nos propre AS v4 et v6. Nous avons un
> Operateur 1 qui arrive sur mon arista 1, et un opérateur 2 qui arrive
> sur mon arista 2.
> Entre les arista il y a un lien pour faire de l'iBGP.

Un setup classique en somme.

> Avant de mettre en place les arista nous avions comme routeur bgp un
> openbsd avec du bgpd, nous n'avions pas d'ibgp entre les openbsd,
> nous avions du carp pour la bascule lan. Lorsque nous basculions sur
> le lien de secours, la bascule bgp se faisait en quelques secondes.

Sans IBGP entre les deux OBSD, on comprend le besoin de bascule BGP.

> Maintenant que nous sommes passés sur arista, la bascule BGP est très
> longue (dans les 6mns), j'ai modifié les timers bgp en 5 15 et j'ai
> ajouté un track sur l'interface de connexion de l'opérateur 1 pour si
> le lien tombe le vrrp bascule, suite à ses 2 modifications ma bascule
> se fait en 3minutes, c'est mieux mais encore trop long.
> 
> Mon besoin : Auriez-vous des pistes, d'autres timer à modifier pour
> accélérer cette bascule? J'ai l'impression que le routage commence à
> fonctionner lorsque la table de l'iBGP de l'arista 1 a récupérée
> toutes les routes (car on récupère toute la table bgp, v4 et v6 ).
> Est-ce que l'iBGP est utile dans mon cas? Dois-je le garder?

En vrai, je ne comprends pas pourquoi tu cherches à faire une bascule
BGP en cas de bascule LAN ? Pourquoi ne pas laisser tourner les deux
liaisons BGP en même temps en actif/actif ? Ton IBGP est justement là
pour que les routes les meilleures, sur chacun des deux transits,
soient choisies par les routeurs. 

Et en cas de bascule VRRP entre Arista1 et Arista2, au pire, les flux
feront Arista2->Arista1->Operateur1, et vice versa dans le cas ou
Arista1 est master. Forcer une bascule eBGP en cas de bascule VRRP, ce
ne me semble pas être une bonne idée.

-- 
Clément Cavadore


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Francois Lesueur]

Bonjour,

Le 06/04/2021 à 23:05, OB via frnog a écrit :
> Auto-signé ou pas c'est au moins chiffré, ce qui permet d'éviter
> l'evedropping passif.

Le but du modèle HTTPS/CA, c'est de chiffrer *avec la bonne personne*.
L'auto-signé évite certes l'attaque purement passive, mais le but du
protocole et de son déploiement, c'est de t'assurer que tu échanges bien
de manière sécurisée avec le bon interlocuteur. Avec l'auto-signé, tu
chiffres, mais tu n'as aucun moyen de savoir si tu chiffres entre toi et
l'attaquant (en MitM, qui re-chiffre ensuite pour ta destination mais
voit le contenu donc) ou entre toi et ta destination (crypto bout-en-bout).

Donc TLS doit t'apporter l'authentification de ta cible, et ça nécessite
de passer par un mécanisme PKI type CA. Et en effet, ces dernières
années, les contournements côté browser se sont vachement restreints. Je
ne pense pas que c'est pour faire marcher le business (let's encrypt
n'est pas un business), mais plutôt que tant que les contournements sont
faciles (ie, suffit de dire "OK, j'accepte de l'auto-signé" dans un
popup du browser), les attaques sont faciles également (un attaquant qui
présente un faux certificat, si l'utilisateur a l'habitude de dire "ok,
exception acceptée", eh bien ça marchera. Et, donc, dès que tu ne
contrains pas à être dans le "bon" modèle, avec un certif bien signé par
une CA reconnue, tu n'as en fait pas la sécurité attendue pour tous les
sites qui sont, eux, bien signés, car l'utilisateur fera des exceptions
sans se poser de question).

C'est un peu comme le déploiement de DNSSEC ou RPKI, tant que ce n'est
pas contraint côté client, ça ne protège pas vraiment des attaques tel
qu'attendu...

Bonne journée !
François


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [Tech] Optimisation bascule BGP arista

[Laurent Laurent]

Bonjour à tous,

Tout d'abord, merci de me lire.

Ma demande :  optimisation du temps de bascule BGP.

Mon contexte : Nous avons nos propre AS v4 et v6. Nous avons un Operateur 1
qui arrive sur mon arista 1, et un opérateur 2 qui arrive sur mon arista 2.
Entre les arista il y a un lien pour faire de l'iBGP.
Avant de mettre en place les arista nous avions comme routeur bgp un
openbsd avec du bgpd, nous n'avions pas d'ibgp entre les openbsd, nous
avions du carp pour la bascule lan. Lorsque nous basculions sur le lien de
secours, la bascule bgp se faisait en quelques secondes.

Maintenant que nous sommes passés sur arista, la bascule BGP est très
longue (dans les 6mns), j'ai modifié les timers bgp en 5 15 et j'ai ajouté
un track sur l'interface de connexion de l'opérateur 1 pour si le lien
tombe le vrrp bascule, suite à ses 2 modifications ma bascule se fait en
3minutes, c'est mieux mais encore trop long.

Mon besoin : Auriez-vous des pistes, d'autres timer à modifier pour
accélérer cette bascule? J'ai l'impression que le routage commence à
fonctionner lorsque la table de l'iBGP de l'arista 1 a récupérée toutes les
routes (car on récupère toute la table bgp, v4 et v6 ).
Est-ce que l'iBGP est utile dans mon cas? Dois-je le garder?

Merci beaucoup de m'avoir lu, j'espère avoir été assez clair.
Cdt.
Laurent.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Francois Lesueur]

Bonjour,

Le 06/04/2021 à 20:19, Oliver varenne a écrit :
> Ce qui est super chiant quand tu développes (car tu bosses généralement avec 
> de l'auto signé)

Pour les certificats de dév, il y a mkcert
(https://github.com/FiloSottile/mkcert) qui est super et exprès pour ça
: création d'une CA locale et installation sur le système/les browsers
en une ligne, puis création d'un certif signé par cette CA en une autre
ligne, et zou !

Pour aller un poil plus loin, la suite smallstep est top :
https://smallstep.com/docs/step-ca/getting-started . Ça permet de
générer une vraie CA, il y aussi une commande pour l'installer
proprement sur les browsers locaux, puis les certifs. Ça fait même du
ACME (protocole de Let's Encrypt) :
https://smallstep.com/docs/tutorials/acme-challenge

Dans les 2 cas, ça se joue en 2 lignes (plutôt mkcert pour du certif de
dév, plutôt smallstep pour une CA locale) et, surtout, sans aucun
appel/config à openssl, ça change un peu la vie côté CA !

Bonne journée
François


---
Liste de diffusion du FRnOG
http://www.frnog.org/