Re: Plantage bizarre
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 ?
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.
--
Daniel
Le philosophe cherche des solutions aux problèmes et
ne trouve que des problèmes sans solutions.
Sim
Reply to: