[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Plantage bizarre



Le 11/04/18 à 09:34, BERTRAND Joël <joel.bertrand@systella.fr> 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.


Reply to: