Re: Plantage bizarre
Daniel Caillibaud a écrit :
> Le 10/04/18 à 23:12, BERTRAND Joël <joel.bertrand@systella.fr> a écrit :
> BJ> Daniel Caillibaud a écrit :
> BJ> > Le 10/04/18 à 15:43, BERTRAND Joël <joel.bertrand@systella.fr> a
> BJ> > écrit :
> BJ> > BJ> Je ne sais pas sur quoi agit l'option -4 (hormis le fait
> BJ> > BJ> s'utiliser IPv4 pour la connexion). Mais je puis t'assurer que
> BJ> > BJ> même interrogés en IPv4, certains DNS renvoient des résolutions
> BJ> > BJ> IPv6 et c'est au soft de faire le tri dans les réponses. Mais
> BJ> > BJ> encore une fois, je ne sais pas si ssh est assez subtil pour
> BJ> > BJ> cela.
> BJ> >
> BJ> > Je pense quand même que même si la requête dns lui renvoyait du AAAA,
> BJ> > il n'utiliserait que les champs A pour se connecter.
> BJ> >
> BJ> > BJ> Peux-tu poster ici un dump réseau complet de quelque
> BJ> > BJ> chose qui fonctionne et d'une transaction qui échoue ? Par
> BJ> > BJ> complet, c'est avec les options -v et -e.
> BJ> >
> BJ> > Avec git on ne peut pas activer -e
> BJ>
> BJ> Je pensais à un tcpdump bien senti.
>
> J'avais mis un résumé dans un mail précédent (04/04/18 à 08:35), pour la
> totale c'est là
>
> - connexion git+ssh qui foire
> https://framadrop.org/r/V20FQ0lVJQ#hUYB/LRdm74/ytm+wl4LllfHIYrIq0QdMsoDY/az4jA=
>
> - connexions du browser qui déconnent aussi
> https://framadrop.org/r/iLXjIVEK69#xiJSfmU3WB7bDZWvO9WUJAqHz5t5lvYyJvdvAEOdRT4=
>
> BJ> > La même commande
> BJ> > env GIT_SSH_COMMAND="ssh -4 -v -o Ciphers=aes256-ctr" git pull
> BJ> > sur le dépôt qui plante (1) et un qui fonctionne (à condition
> BJ> > d'imposer le cipher) (2)
> BJ>
> BJ> Rhohh... Idée ! J'ai eu un truc similaire avec les concetés
> BJ> debianesques. Il y a des chiffrements qui ont disparu de certaines
> BJ> versions récentes d'OpenSSL qui m'empêchaient d'envoyer des mails à
> BJ> certains (gros) domaines. Il m'a fallu patcher sendmail pour contourner
> BJ> le problème !...
> BJ>
> BJ> Peux-tu compiler un OpenSSL officiel (non patché par Debian) ?
>
> Pas la peine, le pb ne peut pas venir de là car
> - en imposant le cipher, on voit que le handshake ssh se passe bien donc
> ils ont trouvé un cipher commun
> - ça fonctionne bien depuis mon portable, qui est aussi sous stretch, avec
> le même ssh/openssl/clé ssh (et la même connexion, j'ai même été jusqu'à
> lui coller même mac, en utilisant le même cable RJ45 sur le même port de
> la même box)
>
> => le pb vient donc de la gestion du réseau par mon desktop vs laptop. Vu
> que les deux ont la même debian, reste
> - le driver de la carte réseau, et je comprends vraiment pas comment ça
> peut influer sur des échanges chiffrés (à priori lui n'agit que sur la
> couche réseau, pas applicative).
> - le (dé)chiffrement AES par le cpu
>
> Y'a moyen de changer des paramètres du kernel pour modifier la gestion AES
> du cpu ?
>
> Vous voyez une autre piste ?
Je sèche. Je n'ai pas quoi ouvrir les fichiers là, tout de suite. Mais
si ce n'est pas une histoire de chiffrement, ça peut ressembler à une
histoire de chemin.
> BJ> Si c'est bien ce à quoi je pense, il faudrait que des gens qui
> BJ> ne comprennent pas les implications de leurs patches arrêtent de les
> BJ> imposer...
>
> Sur la suppression de certains ciphers d'openssl, c'est un choix délibéré
> je suppose, interdire les connexions qui paraissent sécurisées mais ne le
> sont pas car utilisant des ciphers vulnérables.
>
> C'est le choix de firefox & chrome par ex, ils refusent désormais les
> connexions https vers des sites qui ne font pas de TLS ou utilisent des
> ciphers trop faibles.
C'est surtout très bête dans le cas d'une bibliothèque générale.
Lorsque tu ne peux plus envoyer de mails à la moitié du monde, tu es en
général content (d'autant que les gars qui ont patché cela n'ont pas
patché les outils utilisant cette bibliothèque pour leur permettre de
rester isofonctionnels).
Cordialement,
JKB
Reply to: