Come posso essere sicuro di ottenere una risposta autentica di un indirizzo IP richiesto?

Normalmente si esegue un accesso al proprio ISP utilizzando le credenziali utente fornite. Ti viene quindi assegnato un indirizzo IP e ottieni l'accesso ai loro server dei nomi interni, in modo da poter chiedere un determinato nome di dominio e ottenere un indirizzo IP in risposta.

Ma come posso essere sicuro di recuperare l'attuale sito che sto chiedendo? Come posso essere sicuro che il mio ISP non stia fingendo IP o che non mi stia reindirizzando verso "server interni falsi" (con o senza un indirizzo IP identico)? Ad esempio: se chiedo example.com, ottengo il suo IP e mi mostrano un semplice clone di quel sito ..

Come si assicura che un IP esista una sola volta? È possibile cambiare l'IP di localhost in qualcos'altro, quindi cosa garantisce che ciò non accada con gli indirizzi web?

Naturalmente: se l'ISP falsificasse la destinazione, anche gli altri utenti ne risentirebbero se richiedessero lo stesso risultato. Ma anche in questo caso: non sarebbe possibile filtrare gli utenti in base alle loro credenziali ISP e dirottarli?

Probabilmente c'è una sorta di contropiede nel mio modo di intendere. Ma non capisco quello che mi manca.

— NgwVLHUeang
fonte

Se il tuo ISP è dannoso, probabilmente c'è molto poco che puoi fare: non puoi parlare con nessun altro senza passarci attraverso, quindi sei alla loro mercé. Ma finché hai a che fare con un ISP importante e rispettabile, questo non sembra probabile. (Anche se il tribunale ordina loro di scherzare con te, potrebbero.) Gli attacchi di terze parti rappresentano una minaccia maggiore; vedi le risposte.

— Scott,

Quindi tutto ciò che possiamo fare è fidarci. beh .. non sono sicuro che una connessione Internet decentralizzata o una sorta di crittografia IP risolva questo difetto di sicurezza.

— NgwVLHUg

Risposte:

Sì, il DNS non è sicuro. Se vuoi davvero sapere che stai parlando con il server che desideri, devi autenticare il server. Quindi è quello che facciamo. Non crediamo che il DNS sia sicuro e implementiamo la sicurezza di cui abbiamo bisogno altrove, come TLS (Transport-Layer Security).

TLS (il moderno livello di sicurezza di HTTPS) lo fa obbligando il server a inviare al client un certificato che indica il nome del server e la chiave pubblica. Questo certificato è crittografato in modo crittografico da una terza parte attendibile denominata Autorità di certificazione (CA). La firma della CA garantisce che il certificato mostra la chiave pubblica corretta per il server indicato.

Per dimostrare che il server è il legittimo proprietario del certificato (e non un impostore che ha rubato un certificato valido), l'handshake TLS lo dimostra che conosce la chiave privata segreta che forma un set abbinato con la chiave pubblica nel certificato. Questo viene fatto senza rivelare la chiave privata stessa, ovviamente.

C'è una proposta per proteggere il DNS chiamato DNSsec, ma è stato in giro per anni e sembra non andare mai da nessuna parte. Potrebbe non essere mai ampiamente diffuso. Esiste ora una proposta per "DNS su HTTP" (DoH, pronunciato "D'oh!") Che potrebbe proteggere il DNS eseguendolo su HTTPS.

— spiff
fonte

Sto parlando di OSI livello 3, non di livello 5. Controlla il mio commento a mshafer. Non è controllabile come l'ISP instrada la tua richiesta, vero? en.wikipedia.org/wiki/IP_routing

— NgwVLHUeang

@NgwVLHUeang, hai ragione che l'ISP potrebbe indirizzarti dove vogliono. Ecco perché usiamo cose come TLS per verificare la destinazione piuttosto che il percorso, come dice la risposta.

— uccide il

Molte domande lì. Proverò ad affrontare un paio.

Ma come posso essere sicuro di recuperare l'attuale sito che sto chiedendo? Come posso essere sicuro che il mio ISP non stia fingendo IP o che non mi stia reindirizzando verso "server interni falsi" (con o senza un indirizzo IP identico)? Ad esempio: se chiedo example.com, ottengo il suo IP e mi mostrano un semplice clone di quel sito ..

Quindi, questo si chiama attacco man-in-the-middle ( https://en.wikipedia.org/wiki/Man-in-the-middle_attack ). La cattiva notizia è che sono abbastanza comuni (almeno su hotel e altri luoghi con wifi aperto, anche se anche un po 'difficile da dimostrare, - https://www.theregister.co.uk/2016/06/01/teamviewer_mass_breach_report/ ). Ma un modo per proteggersi è di non utilizzare il server DNS dell'hotel (o nel tuo caso il tuo ISP). Ce ne sono alcuni buoni là fuori: https://www.howtogeek.com/122845/htg-explains-what-is-dns/

Sarei sorpreso se un ISP affidabile lo fa (e viene catturato), ma è una buona idea usare il proprio DNS (di nuovo fidarsi di qualcuno) e / o una VPN ogni volta che non si è sulla rete domestica.

— mshafer
fonte

@Spiff - Non ho abbastanza punti credito per votare la tua risposta, ma: thumbs_up:

— mshafer

Mi riferivo maggiormente alla configurazione degli indirizzi IP, anziché all'attuale sistema di nomi di dominio. In luoghi non sicuri come hotel, aeroporti, ecc. So che non è sicuro navigare senza HTTPS o una connessione protetta come VPN, per proteggere password e privacy. Cosa sto pensando: non è mai sicuro accedere a "8.8.8.8" dalla tua rete domestica, in quanto non puoi mai essere sicuro di ottenere una risposta autentica di Google. Devi fidarti del tuo ISP per ottenere la pagina reale e non un clone con mirroring. Non è possibile convalidare ciò che significa 8.8.8.8. Come da decisione del proprio ISP, quale percorso di dati sceglie.

— NgwVLHUg

E HTTPS non ti salva da questo. Poiché l'ISP potrebbe creare la propria CA per ottenere un lucchetto verde per un sito Web clonato.

— NgwVLHUg

@NgwVLHUeang Sembra https potrebbe salvare da questo, dal momento che si suppone di andare al sito originale che corrisponde al certificato attendibile dalla CA di fiducia - un sito clone di spoofing fallirebbe il controllo di CA.

— Xen2050,

@NgwVLHUeang Non parli mai con la CA, quindi un ISP malvagio non può farcela. Il certificato CA (e quindi la sua chiave pubblica) era preinstallato nel sistema operativo o nel browser. Non viene scaricato dal vivo. Utilizzi la chiave pubblica della CA che già conosci e di cui ti fidi per verificare la firma crittografica preesistente della CA sul certificato del server a cui ti stai connettendo.

— Spiff,