In particolare, il provider tedesco che offriva l'infrastruttura "cloud" con la quale veniva gestito il relativo "server" (parliamo di "jabber.ru" e di "xmpp.ru"), si è adoperato per "riorganizzare" il collegamento Internet del server in esame (isolandolo dal resto dell'infrastruttura e lasciandolo connesso, in disparte dal resto) e poi "aggiungere" un livello di gestione lato TLS (ossia, mettendosi in mezzo fra i client sparsi su Internet, ed il server che era li in casa) facendo in modo che entrambi (client e server) parlassero TLS, senza rendersi conto che lui, pero', era nel mezzo (a guardare e potenzialmente alterare il relativo traffico). E' interessante osservare che il tutto è emerso alla luce del sole, solo a causa di una "distrazione" di un qualche tecnico... che si è "dimenticato" di rinnovare un certificato TLS ( che quindi è scaduto, portanto i client a.. innervosirsi... e cosi' innescando l'analisi tecnica degli admin).
Che io sappia, è la prima volta che vedo "documentato" uno schema del genere.
I dettagli, sono qui: https://notes.valdikss.org.ru/jabber.ru-mitm/Ne è nato un piccolo thread (ancora piu' tecnico) sulla community ITNOG [1] dove provavo a riflettere su come "detectare" tali situazioni e, ove necessario, "impedirle".
Saluti, DV [1] https://t.me/IT_NOG/99331/115800 -- Damiano Verzulli e-mail: dami...@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
