Le 11/04/18 à 09:34, BERTRAND Joël <[email protected]> a écrit : […] BJ> > - ça fonctionne bien depuis mon portable, qui est aussi sous stretch, BJ> > avec le même ssh/openssl/clé ssh (et la même connexion, j'ai même été BJ> > jusqu'à lui coller même mac, en utilisant le même cable RJ45 sur le BJ> > même port de la même box) BJ> > BJ> > => le pb vient donc de la gestion du réseau par mon desktop vs BJ> > laptop. Vu que les deux ont la même debian, reste BJ> > - le driver de la carte réseau, et je comprends vraiment pas comment BJ> > ça peut influer sur des échanges chiffrés (à priori lui n'agit que BJ> > sur la couche réseau, pas applicative). BJ> > - le (dé)chiffrement AES par le cpu BJ> > BJ> > Y'a moyen de changer des paramètres du kernel pour modifier la BJ> > gestion AES du cpu ? BJ> > BJ> > Vous voyez une autre piste ? BJ> BJ> Je sèche. Je n'ai pas quoi ouvrir les fichiers là, tout de BJ> suite. Mais si ce n'est pas une histoire de chiffrement, ça peut BJ> ressembler à une histoire de chemin.
Ça pourrait, mais ici ip route me donne la même chose depuis desktop et laptop, ça passe par la même box donc les mêmes routes (j'ai vérifié avec un traceroute). BJ> > BJ> Si c'est bien ce à quoi je pense, il faudrait que des BJ> > BJ> gens qui ne comprennent pas les implications de leurs patches BJ> > BJ> arrêtent de les imposer... BJ> > BJ> > Sur la suppression de certains ciphers d'openssl, c'est un choix BJ> > délibéré je suppose, interdire les connexions qui paraissent BJ> > sécurisées mais ne le sont pas car utilisant des ciphers vulnérables. BJ> > BJ> > C'est le choix de firefox & chrome par ex, ils refusent désormais les BJ> > connexions https vers des sites qui ne font pas de TLS ou utilisent BJ> > des ciphers trop faibles. BJ> BJ> C'est surtout très bête dans le cas d'une bibliothèque générale. BJ> Lorsque tu ne peux plus envoyer de mails à la moitié du monde, tu es en BJ> général content (d'autant que les gars qui ont patché cela n'ont pas BJ> patché les outils utilisant cette bibliothèque pour leur permettre de BJ> rester isofonctionnels). Ça je suis d'accord, si on élimine des cipher dans openssl, faut aussi virer leur usage dans les paquets qui l'utilisent (mais y'en a bcp), et ça ne devrait se faire que d'une debian à la suivante (mais ça je suppose que c'était le cas). Mais à priori tous les outils qui utilisent openssl commencent par lui demander quels sont les ciphers dispos, donc ça devrait pas poser pb. Mais dans ton cas, ton sendmail devait utiliser les cipher mis à dispo par openssl, ce sont les smtp en face qui devaient pas savoir les gérer. Ou alors un pb de conf perso, qui indique une suite de cipher préférés, liste qui n'aurait pas été mise à jour suite à l'évolution des ciphers disponibles dans openssl. Du coup tu annonces des ciphers que tu ne peux pas gérer ensuite. Je dis ça parce que j'ai des smtp qui causent avec pas mal d'autres et j'ai pas eu ce pb lors des ≠ upgrades (depuis sarge ou etch). -- Daniel Pour marcher au pas d'une musique militaire, il n'y a pas besoin de cerveau, une moelle epiniere suffit. Albert Enstein.
