I provider reindirizzano gli speedtest sui propri server?

nanomad E poi negli sniff vedo il traffico catturato su un PC windows tra un PC asus e un device Huawei... E no, non c'è nemmeno tzsp prima che mi dici "ho usato il PC come remote target del packet sniffer di mikrotik"

questo l'ho fatto da casa dove ho un setup diverso e non ho a disposizione un Mikrotik, puoi usare o tshark.exe da riga di comando, che è molto simile al tcpdump, per evitare di scomodare la GUI di Wireshark che pianta tutto a causa del fatto che elabora il traffico in realtime, oppure puoi usare direttamente Windows:

netsh trace start capture=yes captureinterface=N maxsize=50 tracefile=c:\sniff.etl

dove N è l'ordinale dell'interfaccia (netsh trace show interfaces), poi esiste un meraviglioso etl2pcapng che lo converte nel formato leggibile a Wireshark, ma dal momento che tshark.exe usa direttamente npcap puoi evitare tutto sto giro. Il risultato è identico.

eutampieri Perché si parte da una sessione HTTP(S) preesistente facendo una richiesta 101 Switching Protocols, la parte di autenticazione è stata fatta prima (da specifiche, non ho guardato il pcap)

No, la sessione TCP è appena iniziata, il primo pacchetto dopo TCP SYN, TCP SYN-ACK, TCP ACK è un TLS 1.3 Client Hello.

C'è una precedente sessione sempre TLS all'ordinale 2071, con uno scambio di chiavi praticamente identico, ma avvenuta prima che lanciassi lo speedtest. Presumo sia una specie di discovery. Ma quello che si dicono l'applet e la servlet non è del tutto rilevante ai fini della comprensione se sia possibile nattare la destinazione e ottenere uno speedtest falsato.

Effettivamente sbagliavo io a usare Wireshark, anche se trovo strano che l'euristica nel momento in cui togli l'associazione alla porta TCP non lo riconosca, ma questo è un altro discorso. Non ci ho dedicato che pochi minuti (e la fretta mi ha effettivamente fuorviato), però se dissezioni la sessione TLS vedi che fa un banale scambio di chiavi.

Il che non esclude appunto che se fai un dnat verso un diverso IP dove c'è in ascolto una servlet Ookla non possa salire comunque una sessione TLS diversa e che l'applet non se ne accorga e faccia comunque tutto lo speedtest.

simonebortolin Cioè tu stai implicitamente dicendo che tutto ciò che usa wss è insicuro perché a tuo dire non c'è uno scambio di chiavi

Mai detto niente di simile:

lo scambio di chiavi c'è altrimenti non andrebbe su la sessione TLS, però un conto è se io e te ci scambiamo delle chiavi e cifriamo la connessione. Questo rende la connessione difficile da decifrare per terzi, ma non dice niente su me e te.

Il motivo per cui c'è una differenza sostanziale tra un semplice scambio di chiavi, dei certificati self-signed e dei certificati trusted da una certification authority è proprio che se tu semplicemente cifri una connessione con uno scambio di chiavi non hai la certezza di parlare con l'interlocutore giusto.

Lo stesso dicasi per i certificati self-signed: tu dichiari di essere tu e io dichiaro di essere io.

Mentre se usi dei certificati emessi da una CA entrambi gli interlocutori possono verificare se c'è corrispondenza tra i nomi DNS dell'host con cui parli e il certificato che dichiarano di avere. Peraltro esistono anche diversi tipi di certificati: i wildcard sono meno sicuri, ma puoi addirittura trustare un certificato che punta ad un FQDN ed una porta precisa (ma non lo fa nessuno perché poi la cosa va gestita ed è una delle cose più antipatiche da gestire in assoluto).

La sessione TLS dove avviene uno scambio di certificati è più complessa di questa (vedi che ho reso pubblico il capture dei dati se non ti fidi), in questa sessione avviene unicamente uno scambio di chiavi DH e viene negoziata la cifratura TLS_AES_128_GCM_SHA256

Questo non garantisce all'applet di sapere se sta veramente parlando con test.eolo.it, si deve fidare della chiave che questi gli manda perché non c'è scambio di certificati.

Poi se a livello applicativo avvengano ulteriori controlli questo non lo possiamo sapere salvo fare una retroingegneria del protocollo, ma a quanto pare è a sorgenti aperti, serve qualcuno che sappia leggere del Java e ne abbia voglia.

nanomad La servlet ookla è in grado di generare un certificato TLS valido a nome di un dominio qualiasi? (test.eolo.it nel nostro caso). Perchè se così fosse è un baco di sicurezza bello grosso lato OOKLA. Hai prove al riguardo?

La sessione TLS con scambio certificati è diversa (più complessa) di quella che si vede nel capture, se hai voglia leggiti la RFC 8446, ma dal capture è evidente che la applet Ookla si accontenta di un banale scambio chiavi.

A questo punto bisogna provare che la applet fa ulteriori controlli perché dalla sessione catturata non c'è evidenza che li faccia.

simonebortolin peccato che un browser non ammetta certificati self-signed senza dare un bel messaggio di errore

evidentemente c'è modo di forzare il trust di un host a monte prima di aprire la connessione, probabilmente quando il browser parla con https://www.speedtest.net gli viene fornita una applet scritta in qualche modo che contiene dei dati specifici per trustare tutti gli host ufficiali.

La prima sessione breve la fa quando selezioni il server dalla lista. Sembra una specie di discovery o di esistenza in vita. Non ho spulciato tutto il cap, però di default era selezionato Fastweb Milano (la linea da cui ho fatto il test è una linea Fastweb), probabile che ci sia la stessa breve sessione verso lo speedtest di Fastweb e forse in tutto quel traffico che fa ci sono una serie di prove che fa fare al browser per capire il contesto.

Onestamente non ho voglia di mettermi a retroingegnerizzare tutto il flusso che fa.