Se un utente malintenzionato ha la capacità di modificare i dati trasferiti tramite una connessione Internet, può influire su TLS?

Sì, e questo è esattamente ciò che ha fatto l'attacco SSL , mentre si utilizzava la connessione HTTP non protetta che si trasformava in modo trasparente tutti i collegamenti HTTPS ai collegamenti HTTP e proxy la connessione, se non ti sei accorto che non su una connessione HTTPS potresti facilmente inviare dati riservati su una connessione non protetta.

Come amministratore di un sito web puoi contrastarlo impostando Sicurezza di trasporto rigorosa HTTP , ciò che fa è una volta che ti connetti al sito una volta che tutte le future connessioni a quel sito avverranno tramite HTTPS fino alla scadenza dell'intestazione o alla cancellazione della cache del client dei siti HSTS, qualsiasi tentativo di connessione a HTTP verrà automaticamente reindirizzato a HTTPS.

Tuttavia questo non ti protegge se la prima connessione del client al tuo sito è stata intercettata, ma ti aiuta in situazioni come la tua nella domanda in cui il browser tenta HTTP se non hai alcun prefisso aggiunto ¹ , HSTS forzerà automaticamente il collegamento HTTP a un collegamento HTTPS se il sito è memorizzato nella cache HSTS del client.

^{1: Non è il browser che controlla automaticamente HTTPS se non riesce a trovare HTTP. Il modo in cui funziona è che la pagina HTTP sarà semplicemente una pagina di reindirizzamento alla pagina HTTPS se la colpisci.}

Un utente malintenzionato in realtà non ha bisogno di accedere alla "linea Internet" per reindirizzare qualcuno verso una pagina Web fasulla. Se un utente malintenzionato ha accesso al server lui / lei sarebbe in grado di fare un po 'di clonazione e cambiare l'indirizzo I.P di qualsiasi cosa desideri - ma è possibile utilizzare la tecnica del "phishing" per reindirizzare a un altro URL. I computer sono intelligenti solo quanto l'utente, quindi mentre un computer potrebbe fare così tanto per mantenere la sicurezza, è comunque importante che l'utente ne sia consapevole. Internet potrebbe essere tuo amico o nemico.

Potresti leggere gli attacchi dell'omografo IDN o lo spoofing degli script. Poiché ora i caratteri al di fuori del solito a-z (maiuscole / minuscole), 0-9 e - (trattini meno) possono essere utilizzati , le possibilità si sono notevolmente ampliate. Mentre in precedenza, si poteva solo sperare di ingannare gli utenti usando combinazioni come vv per sostituire w , ora è possibile utilizzare qualsiasi omografo Unicode e alcuni di questi omografi sono identici quando vengono resi pixel per pixel! Ecco un esempio di Twitter (con i punti codice Unicode tra parentesi) generati usando un online strumento appositamente per questo scopo :

Original: twitter (74,  77,  69,  74,  74, 65,  72)
Fake:     twіttеr (74,  77,  456, 74,  74, 435, 72)

Il primo è reale, ma il secondo è falso. A seconda del carattere, non tutte le versioni "false" possono sembrare giuste. I caratteri dei blocchi di codice meno supportati possono eseguire il rendering utilizzando un carattere completamente diverso dal resto della stringa e dare la mancia alla vittima.

Tuttavia esiste una semplice difesa contro l'attacco: renda il nome di dominio Unicode come Punycode sottostante (un argomento separato puoi leggerne da solo), o renderizzare selettivamente come Punycode per i nomi di dominio che hanno caratteri da più blocchi Unicode.