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

[Julien Escario]

Le 08/04/2021 à 16:48, Michel Py via frnog a écrit :
>> l...@51514.fr a écrit :
>> Pour les bons, il y aura toujours curl.
> Et ça sert à quoi ? pour configurer un machin sans certificat ?

Ca sert à tout curl : il y a deux jours, j'ai diagnostiqué un soucis de
certificat LDAPS sur un service avec (voir la liste des protocoles
supportés par curl).

Julien




OpenPGP_signature
Description: OpenPGP digital signature

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

[Michel Py via frnog]

> l...@51514.fr a écrit :
> Pour les bons, il y aura toujours curl.

Et ça sert à quoi ? pour configurer un machin sans certificat ?

Michel.

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

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

[l]

Le 2021-04-07 19:11, Michel Py via frnog a écrit :

Oliver varenne a écrit :


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



Pour les bons, il y aura toujours curl.


Michel.


---
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

[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/

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/

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/

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/

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] [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] [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] [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] [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/

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/

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

[Willy Manga]

Bonjour,

On 07/04/2021 02:22, N R wrote:
> Bonsoir,
>[...]
> 
> Le fond de tout ça c'est la confiance qu'on peut accorder à ce à quoi
> on se connecte et comme Michel Py l'a bien dit, c'est un marché comme
> un autre.

C'est pour ça qu'il y a DANE où (en gros) la confiance ne repose pas sur
des Autorités de Certification mais sur les enregistrements fournis dans
le fichier de zone signé (donc DNSSEC) par son gestionnaire. Ce qui, 
à
mon humble avis, devrait avoir plus de crédit étant donné qu'il n y  a
plus d'intermédiaire dans la chaîne de confiance entre le demandeur de
la ressource et le propriétaire de la ressource.


-- 
Willy Manga
@ongolaboy
https://ongola.blogspot.com/



OpenPGP_signature
Description: OpenPGP digital signature

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

[Michel Py via frnog]

> David Ponzone a écrit :
> 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, donc de plus en plus difficile à bloquer sur un 
> FW qui fait du MITM.

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 au lieu de faire confiance uniquement à l'anti-virus 
installé sur le client. Et ici, pareil en entreprise; on n'inspecte pas le 
trafic qui va sur les banques, mais le reste si.

Ceci étant dit, même problème qu'avec les certificats SSL à validité étendue 
(le machin qui devenait vert dans la barre d'url), ce n'est qu'une question de 
temps avant que les malfrats enregistrent des domaines qu'ils vont sans grand 
effort faire classifier comme "bancaire", que les pare-feu d'entreprise ne vont 
pas inspecter pour raisons de vie privée, et on en est revenu à la case départ. 
Et il y en a qui se sont fait des c.. en or, avec ces certificats verts.

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.

> Nick Rand a écrit :
> 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.

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.

Michel.


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

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

[N R]

Bonsoir,

Le 06/04/2021, OB via frnog a écrit :
> Une question que je me suis toujours posé à ce propos:
>
> A quoi servent ces restrictions sur les certificats de la part des
> navigateurs ?
>
> Je sais qu'il existe, en entreprise, des dispositifs pour intercepter -
> légalement - de l'HTTPS , mais du coup ça va marcher pour tout
> certificat (pas juste auto-signés) via notamment l'intégration dans l'OS
> (ou celui du navigateur dans le cas de Firefox).
> Des anti-virus sur les postes font ça aussi.
>
>
> 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 ?
>
...
>
> Auto-signé ou pas c'est au moins chiffré, ce qui permet d'éviter
> l'evedropping passif.
>
> Il y a un truc que je saisi pas ?
>
> Julien
>
>

L'argument "technique" c'est que si c'est un certificat auto-signé, en
cas de perte ou de vol de la clé privée associée, il n'y a pas moyen
de révoquer le certificat et il est par conséquent complètement
"perdu".

L'autorité de certification est là comme une assurance pour ce genre
de cas et comme garant de la validité du certificat auprès du public.

Un parallèle avait été donné (je sais plus la ref exact, peut-être le
livre Cyberstructure de Bortzmeyer) avec une carte d'identité,
certifiée valide par l'état qui l'émet, pour une durée limitée,
renouvelable et révocable.

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.

Le fond de tout ça c'est la confiance qu'on peut accorder à ce à quoi
on se connecte et comme Michel Py l'a bien dit, c'est un marché comme
un autre.

Cheers
Nick Rand


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

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

[David Ponzone]

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, donc de plus en plus 
difficile à bloquer sur un FW qui fait du MITM.
Et qui a intérêt à ne pas être bloquable ?

> Le 6 avr. 2021 à 23:54, Michel Py via frnog  a écrit :
> 
>> Julien a écrit :
>> Une question que je me suis toujours posé à ce propos: A quoi servent 
>> ces restrictions sur les certificats de la part des navigateurs ?
> 
> Comme la plupart des choses qui sont reliées à l'obsolescence planifiée : à 
> faire marcher le commerce.
> Ca essaie de te forcer à acheter un truc dont tu n'as aucun besoin. 
> L'industrie entière marche comme ça : tu passes ton temps à te tenir à jour.
> Sécurité de l'emploi.
> 
> Michel.
> 
> 
> ---
> 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

[Michel Py via frnog]

> Julien a écrit :
> Une question que je me suis toujours posé à ce propos: A quoi servent 
> ces restrictions sur les certificats de la part des navigateurs ?

Comme la plupart des choses qui sont reliées à l'obsolescence planifiée : à 
faire marcher le commerce.
Ca essaie de te forcer à acheter un truc dont tu n'as aucun besoin. L'industrie 
entière marche comme ça : tu passes ton temps à te tenir à jour.
Sécurité de l'emploi.

Michel.


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

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

[OB via frnog]

Une question que je me suis toujours posé à ce propos:

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


Je sais qu'il existe, en entreprise, des dispositifs pour intercepter - 
légalement - de l'HTTPS , mais du coup ça va marcher pour tout 
certificat (pas juste auto-signés) via notamment l'intégration dans l'OS

(ou celui du navigateur dans le cas de Firefox).
Des anti-virus sur les postes font ça aussi.


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 ?


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. Ces histoires de certificats compliquent largement aussi 
l'utilisation de vieux matériel, genre des cartes RILOE2 , des APC, des 
KVM Aten, et j'en passe, et je ne vois aucun bénéfice sur la sécurité.



Auto-signé ou pas c'est au moins chiffré, ce qui permet d'éviter 
l'evedropping passif.


Il y a un truc que je saisi pas ?

Julien


Le 06/04/2021 à 20:19, Oliver varenne a écrit :

Oui, google adore petita petit restreindre les possibilités vis-à-vis des 
certificats...
Ce qui est super chiant quand tu développes (car tu bosses généralement avec de 
l'auto signé)



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
David Ponzone
Envoyé : mardi 6 avril 2021 20:03
À : frnog-misc 
Objet : [FRnOG] [MISC] La "backdoor" de Chrome

Des semaines que je lutte avec Chrome qui empêche maintenant
totalement d’aller sur un site dont le certificat est autosigné.
Avant, on pouvait forcer en cliquant sur Advanced, mais plus depuis
quelques temps.

J’ai enfin trouvé la parade (j’admets que j’avais pas trop cherché):
Quand on est sur la page de bloquage, il faut taper au clavier:
thisisunsafe

Magique.


---
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

[Vincent Habchi]

> 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/

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

[Vincent Tondellier via frnog]

Le Tuesday 06 April 2021 21:00:15 Erwan David a écrit :
> Le 06/04/2021 à 20:42, Stéphane Rivière a écrit :
> > Le 06/04/2021 à 20:19, Oliver varenne a écrit :
> >> Oui, google adore petita petit restreindre les possibilités vis-à-vis des
> >> certificats... Ce qui est super chiant quand tu développes (car tu
> >> bosses généralement avec de l'auto signé)> 
> > Y'a pas mal de tutos sur le net pour utiliser des certifs LE dans un
> > intranet. Mais bon...
> 
> 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...

Sinon se créer une CA interne et l'importer dans chrom(e|ium). Pas très 
compliqué.

Ou utiliser firefox ...


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

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

[Erwan David]

Le 06/04/2021 à 20:42, Stéphane Rivière a écrit :
> Le 06/04/2021 à 20:19, Oliver varenne a écrit :
>> Oui, google adore petita petit restreindre les possibilités vis-à-vis des 
>> certificats...
>> Ce qui est super chiant quand tu développes (car tu bosses généralement avec 
>> de l'auto signé)
> Y'a pas mal de tutos sur le net pour utiliser des certifs LE dans un
> intranet. Mais bon...
>
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...



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

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

[Stéphane Rivière]

Le 06/04/2021 à 20:19, Oliver varenne a écrit :
> Oui, google adore petita petit restreindre les possibilités vis-à-vis des 
> certificats...
> Ce qui est super chiant quand tu développes (car tu bosses généralement avec 
> de l'auto signé)

Y'a pas mal de tutos sur le net pour utiliser des certifs LE dans un
intranet. Mais bon...

-- 
Be Seeing You
Number Six


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

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

[Oliver varenne]

Oui, google adore petita petit restreindre les possibilités vis-à-vis des 
certificats...
Ce qui est super chiant quand tu développes (car tu bosses généralement avec de 
l'auto signé)



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
> David Ponzone
> Envoyé : mardi 6 avril 2021 20:03
> À : frnog-misc 
> Objet : [FRnOG] [MISC] La "backdoor" de Chrome
> 
> Des semaines que je lutte avec Chrome qui empêche maintenant
> totalement d’aller sur un site dont le certificat est autosigné.
> Avant, on pouvait forcer en cliquant sur Advanced, mais plus depuis
> quelques temps.
> 
> J’ai enfin trouvé la parade (j’admets que j’avais pas trop cherché):
> Quand on est sur la page de bloquage, il faut taper au clavier:
> thisisunsafe
> 
> Magique.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

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

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

[David Ponzone]

Des semaines que je lutte avec Chrome qui empêche maintenant totalement d’aller 
sur un site dont le certificat est autosigné.
Avant, on pouvait forcer en cliquant sur Advanced, mais plus depuis quelques 
temps.

J’ai enfin trouvé la parade (j’admets que j’avais pas trop cherché):
Quand on est sur la page de bloquage, il faut taper au clavier: thisisunsafe

Magique.


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