Perché non inserire il certificato TLS nelle risposte DNS?

-1

La sicurezza di una connessione TLS si basa sulla fiducia nel certificato della CA, che a sua volta è in realtà una prova della proprietà della voce del DNS. Anche se l'operatore del server può richiedere un certificato per suo conto, quando l'operatore del server e il proprietario del dominio non si fidano l'uno dell'altro, il proprietario del dominio vince.

SSL e TLS sono generalmente associati al nome di dominio e al client non interessa l'IP reale del server. Tuttavia, il client chiede sempre al server un certificato. Ciò si traduce in un altro RTT, rendendo HTTPS una volta più lento di HTTP, non tenendo conto dello scambio di chiavi che aggiunge da 1 a 2 RTT. L'intestazione Keep-Alive e TLS 1.3 rendono meno problematico il problema, ma non è possibile salvare RTT alla prima stretta di mano. Perché non lasciare che il server DNS restituisca l'IP del server insieme al certificato e alle informazioni sullo scambio di chiavi, salvando un RTT?

L'unico vantaggio che vedo qui è che più server possono utilizzare più certificati. Ciò consente di revocare uno dei certificati senza influenzare gli altri. Tuttavia, se uno di questi server è compromesso, non rende più facile il rilevamento dei compromessi. Con qualsiasi chiave privata, gli attacchi MITM possono già essere abbastanza trasparenti, ed è altrettanto difficile notare l'attacco.

    
posta He WenYang 12.08.2018 - 17:11
fonte

1 risposta

3

Se desideri perfetta segretezza avanzata , devi negoziare una chiave di sessione separata per ogni connessione (o gruppo di breve durata) di connessioni, a seconda dell'implementazione). Non è possibile negoziare una chiave di sessione effimera con un server dei nomi DNS "stupido" (infatti, il protocollo DNS non fornisce nemmeno le primitive necessarie senza un sacco di piegature e mutilazioni). Inoltre, anche supponendo che il server dei nomi DNS stia in qualche modo negoziando una chiave di sessione con l'utente finale, tale chiave deve ancora essere propagata al server dei contenuti effettivo per eseguire la terminazione TLS. Le chiavi effimere sono pensate per essere effimere; non dovrebbero lasciare la RAM, per non parlare di attraversare la rete in questo modo.

I round trip di keying sono inevitabili, a meno che tu non sia disposto a rinunciare alla segretezza. Rinunciare alla segretezza è gravemente indesiderabile, date le rivelazioni di Snowden (che mostravano tra l'altro che la NSA aveva una pratica effettiva di immagazzinare comunicazioni crittografate nella speranza di decifrarle alla fine) e la probabilità di comportamenti simili da parte di altri avversari.

Questo ci lascia solo con il salvataggio del certificato. Ma la realtà è che servire un certificato (o qualsiasi file abbastanza grande) su TCP (il livello di trasporto utilizzato da HTTP (S)) è probabilmente più veloce ed efficiente rispetto a servire su UDP (il trasporto utilizzato dal DNS). UDP richiede all'applicazione di re-inviare manualmente i blocchi persi e di correggere manualmente il riordino o la duplicazione dei pacchetti. UDP richiede inoltre all'applicazione di suddividere manualmente i file in pacchetti (che potrebbero dover essere estremamente piccoli a seconda della rete) e rimontarli. TCP esegue tutte queste cose automaticamente e le tipiche implementazioni TCP sono strongmente ottimizzate per il trasferimento di file (ad esempio, TCP ridimensiona automaticamente i pacchetti per adattarsi al meglio al congestionamento del collegamento di rete sottostante). UDP ha ancora senso per trasferimenti best-effort di messaggi molto brevi come le query DNS, ma il trasferimento di un intero certificato firmato sarebbe probabilmente più lento su DNS rispetto a HTTP / HTTPS.

Naturalmente, c'è anche il problema del caching e dell'indirizzamento indiretto. È estremamente comune per gli utenti comunicare con nameserver DNS non autorevoli (ad esempio, quelli forniti dal proprio ISP). In teoria, questi nameserver dovrebbero restituire gli stessi risultati delle loro autorevoli controparti, o interrogandoli direttamente ( in modo ricorsivo se necessario) o memorizzando nella cache i risultati delle query precedenti fino a un time-to-live (TTL) configurabile. In pratica, spesso si discostano dallo standard, ad esempio in uno o in tutti questi modi:

  1. Dirottamento di NXDOMAIN (restituendo un indirizzo IP "falso" invece di un errore per ricerche di domini inesistenti, che di solito portano all'utente a visualizzare annunci vagamente correlati al nome di dominio).
  2. Non rispettando il TTL (memorizzazione nella cache per un periodo di tempo superiore a quello previsto)
  3. Ignorare, rilasciare o pubblicare errori per richieste che non sono comunemente emesse da normali browser Web (es. richieste di record TXT ).
  4. Il supporto e l'uso effettivo di DNSSEC varia sostanzialmente per ISP e per regione .

È difficile mettere in pratica qualsiasi "furbo DNS" quando metà dello standard non è implementato correttamente da una parte sostanziale dei tuoi clienti.

    
risposta data 12.08.2018 - 23:27
fonte

Leggi altre domande sui tag