Il 04 settembre 2015 13:30:30 CEST, Daniele Nicolodi <daniele@xxxxxxxxxx> ha
scritto:
On 03/09/15 23:32, Marco Ciampa (Redacted sender ciampix@xxxxxxxxx for
DMARC) wrote:
On Thu, Sep 03, 2015 at 11:02:10PM +0200, Daniele Nicolodi wrote:tu
Il problema è l'associare un utente ad una certa chiave. A meno che
Ilnon abbia un canale indipendente per verificare che una certa chiave
appartiene ad un certo utente, ti devi fidare del server Telegram.
tramiteserver Telegram, può impersonare chiunque.
Se voglio intercettare i messaggi che Alice e Bob si scambiano
Aliceil server Ted, che controllo, quando Alice mi chiede la chiave
crittografica di Bob, le mando una chiave fasulla, che controllo.
chiavepuò parlare solo con me, quindi non ha modo di verificare che la
asia quella giusta. Cifra i messaggi che vuole spedire a Bob con la
chiave di che le ho fornito e li invia al server, diretti a Bob. Sul
server decifro i messaggi, li cifro con la chiave di Bob e li mando
Bob. Faccio la stessa cosa con i messaggi di Bob.
Insomma il classico man-in-the-middle, giusto?
Solitamente per MITM si intende qualcosa di un po' diverso: interporsi
"illecitamente" nella comunicazione tra due punti. In questo caso non
c'è bisogno di nessun accorgimento particolare (come imbrogliare i DNS,
alterare le routing tables, od altro) per interporsi nella
comunicazione: il protocollo prevede che il server faccia da relay per
tutti i messagi (e non è facilmente evitabile se si vuole avere la
possibilità di mandare messaggi a client potenzialmente disconnessi).
La cosa è del tutto equivalente ad altri protocolli, e ci sono diversi
sistemi per risolvere il problema: per HTTPS si usano certificati
associati ad un certo identificativo (host name) da un ente terzo di
cui
le due parti si fidano (le certification authorities); per PGP ci si
fida della web of trust, etc...
Ciao,
Daniele
