I provider reindirizzano gli speedtest sui propri server?

aternopae · 2022-08-10T13:32:21+00:00

Messaggi spostati da: https://forum.fibra.click/d/32447 Nick1997 Prova a seguire questa guida: https://fibra.click/speedtest/ Scusate se mi permetto ma que...

LATIITAY

handymenny ora è un binario

Vedo, scritto in C++, integra staticamente anche OpenSSL... 🤔

handymenny ah ecco. Ok ho guardato meglio e la differenza e' proprio questa, in url ci sta sempre il dominio del servizio, mentre in host no, ad esempio:

[
  {
    "url": "http://spd-pub-mi-01-01.fastwebnet.it:8080/speedtest/upload.php",
    "lat": "45.4640",
    "lon": "9.1916",
    "distance": 521,
    "name": "Milan",
    "country": "Italy",
    "cc": "IT",
    "sponsor": "Fastweb SpA",
    "id": "7839",
    "preferred": 0,
    "https_functional": 1,
    "host": "spd-pub-mi-01-01.fastwebnet.it:8080"
  },
  {
    "url": "http://spd-pub-rm-01-01.fastwebnet.it:8080/speedtest/upload.php",
    "lat": "41.9000",
    "lon": "12.5000",
    "distance": 813,
    "name": "Rome",
    "country": "Italy",
    "cc": "IT",
    "sponsor": "Fastweb SpA",
    "id": "7898",
    "preferred": 0,
    "https_functional": 1,
    "host": "spd-pub-rm-01-01.fastwebnet.it:8080"
  },
  {
    "url": "http://test.eolo.it:8080/speedtest/upload.php",
    "lat": "45.4640",
    "lon": "9.1916",
    "distance": 521,
    "name": "Milan",
    "country": "Italy",
    "cc": "IT",
    "sponsor": "EOLO",
    "id": "11427",
    "preferred": 0,
    "https_functional": 1,
    "host": "test.eolo.it:8080"
  }
]

contro

[
  {
    "url": "http://speedtest.melita.it:8080/speedtest/upload.php",
    "lat": "45.4654",
    "lon": "9.1859",
    "distance": 521,
    "name": "Milan",
    "country": "Italy",
    "cc": "IT",
    "sponsor": "Melita",
    "id": "25609",
    "preferred": 0,
    "https_functional": 1,
    "host": "speedtest.melita.it.prod.hosts.ooklaserver.net:8080"
  }
]

aternopae

LATIITAY

non so dove hai preso quel codice però da come ho visto che funziona direi che l'URL è quello dove viene fatto l'upload del risultato, mentre l'HOST è dove è pubblicata la servlet.

L'app che sia immersa nella pagina web, che sia standalone per desktop o per android/ios si collega all'host alla porta 8080/TCP e non fa una sessione SSL, non fa nemmeno una sessione HTTP secondo me ma parla una lingua tutta sua.

handymenny

LATIITAY In un browser moderno NON puoi aprire socket a caso come si faceva 10 e piu' anni fa con applet Java o plugin Flash.

Proof:

LATIITAY url ci sta sempre il dominio del servizio, mentre in host no, ad esempio:

Interessante, non ci avevo fatto caso. Modificando la risposta dns per *.prod.hosts.ooklaserver.net ora il "trucco" funziona per tutti i server ookla.
Ho riprovato giusto per scrupolo, su tutti i client diversi dal browser (su MacOS, Android, Linux e Windows) non viene effettuato alcun controllo.
Chissà se con un server "malevolo" non si possa prendere il controllo dell'APP ookla...

aternopae

LATIITAY Il certificato da web lo controlla sicuramente solo il browser, e usa sicuramente HTTPS; forse da app banalmente non usa HTTPS ma HTTP o magari nemmeno quello... Ed evidentemente non controlla per nulla l'ID nella configurazione (o magari piu' probabilmente Ookla viene a saperlo ma fino ad oggi se ne frega).

Chi ti dice che l'app per fare la misurazione faccia una sessione HTTP o HTTPS verso la servlet?

Io non ho polso di ciò, ricordo di avere analizzato il traffico per curisità ma appunto sono passati alcuni anni e non che me ne fregasse più di tanto visto che è puro fumo negli occhi per tenere buoni gli utenti.

LATIITAY

aternopae da web fa websocket HTTPS con fallback a richieste normali sempre HTTPS. Non puo' fare altro cioe'... Al limite potrebbe fare anche magari WebRTC per testare in UDP. Sicuramente non richieste in chiaro.

Le app proprietarie non ne ho idea e non avrei dove eseguirle al momento 😅

aternopae

LATIITAY prova a pingare a fare tracert verso test.eolo.it o spd-pub-rm-01-01.fastwebnet.it e vedrai che sono gli host reali dove ci sono le servlet Ookla.

Io ho telnettato alla 8080 e risponde.

Se io sono il provider posso prendere tutti quegli host, compilare una lista, fare un destination nat verso il mio server Speedtest ufficiale, che ha in pancia un certificato SSL valido. Così tutti i miei utenti, convinti di collegarsi a EOLO, si collegano al mio, convinti di collegarsi a Fastweb si collegano al mio, ecc. ecc.

LATIITAY

aternopae ripeto che da browser non e' piu' come ~10 anni fa dove con Flash o Java potevi usare qualunque protocollo. Oggi sei limitato ad usare HTTPS, WebSocket (over HTTPS) e WebRTC (UDP con limitazioni). E la verifica dei certificati la fa il browser a monte, il codice JavaScript del sito non puo' bypassarla.

Che poi tutto il resto (app CLI, app mobili, app Windows, etc) possa invece usare, e usi effettivamente un protocollo proprietario, ci sta, e anzi me lo aspetto che sia cosi' visto che e' piu' efficiente se lo scopo e' trasferire quanti piu' dati possibili nel minor tempo possibile...

aternopae il tuo server speedtest ufficiale ha un certificato TLS valido per il tuo server, e solo per quello. Non ha una wildcard. Se si potesse fare quello che dici tu il "lucchetto verde" non servirebbe a nulla.

Certo poi c'e' CloudFlare che invece mettendosi tra il server e i client, fa proprio questo, Man-in-the-Middle come se non ci fosse un domani. Ma e' il proprietario del dominio che deve volerlo fare, attivarlo e configurare il tutto per farsi rompere la connessione sicura da CloudFlare "volontariamente".

Se invece gestisci la rete tra server e client come "soggetto terzo", e provi a fare una cosa del genere, ovviamente non puo' funzionare; e' proprio uno degli scopi di TLS bloccare questa cosa.

Che poi le app proprietarie di Ookla diverse dal test nel browser non usino proprio HTTPS o TLS, ok...

simonebortolin

aternopae che ha in pancia un certificato SSL valido

Come lo crei se non hai la proprietà del dominio😅

aternopae

LATIITAY Che poi le app proprietarie di Ookla diverse dal test nel browser non usino proprio HTTPS o TLS, ok...

ma infatti vedo che si fa confusione tra aprire https://www.speedtest.net il quale ovviamente ha il suo certificato ecc. e avviare lo speedtest vero e proprio che avviene tra il tuo browser e la servlet del provider con un protocollo proprietario.

Lo speedtest vero e proprio non è https, non è nemmeno http, non c'è nessun certificato di mezzo, il provider può barare su sta cosa tranquillamente ed è talmente facile che invoglia a farlo.

Un certo $ISPdimerda lo fa ... 🙄 ... e dalle latenze direi che lo fanno anche i grossi. Anche perché salvo farlo alle 5 della mattina è quasi impossibile che uno speedtest fatto verso un server fuori dalla rete del tuo provider saturi la banda.

Ve li immaginate gli utenti che frignano perché hanno mezzo bit in meno su un gigabit a piagnucolare col servizio clienti? E' tutta fuffa per tenerli buoni.

Se vuoi fare speedtest seri magari non usi Ookla.

LATIITAY

aternopae la confusione la stai facendo tu.

Per l'ennesima volta:

In un browser moderno NON puoi aprire socket a caso come si faceva 10 e piu' anni fa con applet Java o plugin Flash.

Semplicemente non hai modo di aprirle le connessioni con protocollo proprietario!

Puoi usare "workaround" come appunto WebSocket, ma da una pagina https puoi farlo sempre e solo in https (protocollo wss://). E il browser i certificati te li verifica e basta, punto, il sito non puo' decidere di non farlo...

aternopae Anche perché salvo farlo alle 5 della mattina è quasi impossibile che uno speedtest fatto verso un server fuori dalla rete del tuo provider saturi la banda.

Nah, evidentemente il tuo ISP doveva essere proprio molto dell'aggettivo come lo definisci tu, fidati che un ISP degno di questo nome, di banda su peering o transiti ne ha per reggere bene il traffico degli utenti...

Non ti credere che l'uso medio della rete sia anche solo minimamente vicino alla banda di picco offerta. Per lo stesso motivo non avrai mai centinaia o migliaia di utenti tutti a fare speedtest allo stesso momento... Il server interno tuo di speedtest mica aveva uplink da 100 Gbps, no? Se era a 10 Gbps era gia' tanto mi sa. Bene, vuoi che almeno un uplink da 10 Gbps un ISP che oggi vende fibre con banda di picco a 1 Gbps non lo abbia? Suvvia...

LATIITAY

handymenny Proof:

Tra l'altro, appunto, il client web ha provato sia con WebSocket in HTTPS che direttamente in HTTPS, fallendo appunto per via del certificato 🤣

handymenny Interessante, non ci avevo fatto caso. Modificando la risposta dns per *.prod.hosts.ooklaserver.net ora il "trucco" funziona per tutti i server ookla.
Ho riprovato giusto per scrupolo, su tutti i clienti diversi dal browser su MacOS, Android, Linux e Windows, non viene effettuato alcun controllo.
Chissà se con un server "malevolo" non si possa prendere il controllo dell'APP ookla...

Oh beh. Bisogna vedere quanto bene sia implementato il protocollo proprietario...

... o magari il controllo del server... C++, binario non strippato... Hmmm... 😇

matteocontrini

aternopae Scusate se mi permetto ma questa guida è un totale nonsense.

Scrivila meglio! E poi vediamo 🙂

simonebortolin

aternopae l'ONT è un dispositivo di livello 2, quindi è una comunicazione sincrona con l'OLT che risponde allo standard G.984, se diversi ONT avessero framerate diverse non negozierebbero con l'OLT.

Il link fisico di un canale ovviamente dipende esclusivamente dallo standard utilizzato per instaurare il canale, però il GPON a differenza di un cavo ethernet che è un mezzo P2P, dove se c'è link fisico con autosenting il throughput rispecchia il phy rate fisico dato che il cavo ha un determinato SNR da garantire la velocità decisa dall'autosenting non ci dovrebbero essere più di tanti errori che abbassano la velocità, in un mezzo condiviso come il GPON le performance dipendono da come viene gestito il mezzo condiviso e quindi la coppia OLT-ONT. Dato che nonostante tutti gli ONT rispecchiano lo standard G.984 possono essere ampiamente configurati in maniera diversa la cosa più facile che mi viene in mente da spiegare è la limitazione dell'upload viene fatta via OLT. L'OLT fa si che l'ONT non possa avere troppi pacchetti ethernet da inviare all'interno dei frame GEM e questo garantisce il limite dell'upload. Questo fa si che nell'ONT ci devono essere delle code, e le code non sono standardarizzate nel G.984, ma a discrezione del vendor e del manufacter, e proprio per questo il throughput dipende anche dal tipo di ONT.

In maniera analoga si può generalizzare in questo modo: il problema di diverse performance di diversi ONT sono le code dei frame GEM: ogni frame GEM contiene 20-30 pacchetti ethernet, e per creare e leggere questi frame serve avere dei buffer dove si incapsulano i pacchetti ethernet, ricordo che un frame GPON è di 38880 byte, 38 di overhead statico e 5 byte*numero di ont, in upload tu hai diritto ad alcuni slot di questi (con un numero massimo pari alla tua velocità di upload. Avere code configurate male non permette di usare al massimo questi frame GPON facendo sì che alcuni ne vengono sprecati.

Questo fa si che anche l'ONT è responsabile di performance inadeguate, però c'è un ma, essendo lo stesso ONT le performance inadeguate devono essere le stesse dal day0 al day1000000 e/o diventano inadeguate dopo aggiornamenti SW/HW dell'OLT.

aternopae Per potere testare il throughput, e quello magari può essere il router a fare la differenza, dovresti fare un altro tipo di test con il tuo next-hop, ma non è detto che questi abbia il necessario per poterlo fare.

Dato che è già stato chiesto di adeguare la guida allo speedtest a cosa, pensi, in questo messaggio:

matteocontrini Scrivila meglio! E poi vediamo 🙂

Perché al posto di scrivere "hint" a caso non la fai così vediamo oppure, perché non evitiamo di dire certe cose nosense.
Mi spieghi come si fa a testare la velocità sul next-hop, che poi che perché il next-hop? Cioè semmai il dispositivo di confine della rete dell'OLO, ma non il next-hop, perché il next-hop potrebbe sotto casa (in un grande ISP) oppure un utik messo nel seminterrato di Caldera, è una indicazione forviante, non avrebbe senso, dato che nel percorso tra il tuo router e il next-hop, cioè il bras, a meno di tue reinvenzioni della routa, potrebbe essere connesso da una matrioska di kit vula, nga o rv fw, ponti radio, rfc1149, ethernet over coax, atm, .... incapsulati in altri pacchetti, MPLS, chi più ne ha più ne metta, e questo da una misura del throughput tra due device, ma non è confrontabile a nulla, perché ogni altro utente potrebbe avere configurazioni diverse della rete in mezzo e questo test fornisce come già detto il throughput all'interno di matrioske a caso senza nessuna possibilità di confronto con altri utenti. Mentre se lo si fa sul dispositivo di confine della rete dell'ISP avrebbe già più senso, ma anche quì tutti gli utenti dello stesso ISP potrebbero raggiungerne di diversi in load balancing, come succede nei grandi ISP, però questo è già più sensato di una misura che guarda solamente quanto throughput c'è in un L2 dal tuo router di casa a non si sa dove.

Però questo misura il throughput all'interno della rete dell'ISP, dopo di che bisogna misurare il throughput tra l'ISP e per esempio un OTT, cosa facciamo anche quì un next-hop alla volta?
Ma allora abbiamo che il 1/throughput = 1/throughput1 + 1/throughput2 + ... 1/throughputN che si può dire uguale a throughput = min(throughput1,throughput2, throughputN), che guarda caso è lo stesso risultato che da lo speedtest.

LucaTheHacker

Avendo smanettato parecchio con i server Ookla, faccio un recap

APP desktop e mobili non controllano i certificati, la CLI ogni tanto lo fa, ogni tanto no, non c'ho mai ben capito. Da browser è impossibile falsificare il server
Ookla usa un CNAME da *.prod.hosts.ooklaserver.net per indirizzare sul giusto server
Ookla ti consente di avere più server con lo stesso IP e/o lo stesso certificato, vedasi i server di Cloudflare, ma non puoi falsificare i server di altri, quello viene bloccato tramite il certificato SSL

LATIITAY

LucaTheHacker in realta' per Cloudflare hanno fatto un'eccezione alla policy generale, perche' non sono permessi server duplicati: https://support.ookla.com/hc/en-us/articles/360060609971-Speedtest-Server-Network-Acceptance-Policy

Poi vabeh Cloudflare lo hosta in Anycast quindi anche li' la citta' indicata da Ookla lascia il tempo che trova.

E cmq i server di Cloudflare sono spariti in questo momento...

I CNAME non li usano tutti i server ufficiali, come admin puoi scegliere di usarlo oppure no.

Poi c'e' Planetel che falsifica la location con piu' IP adiacenti con latenza identica... 👀

Adesso ne hanno lasciati solo due, localizzati a Brescia e a Napoli... Ma prima c'erano anche Bergamo, Milano, Verona, Vicenza, Vicenza 2 (IPCompany) e Brescia 2 (Servizi Internet)... 🤦

PING speedtest.planetel.it (185.4.142.38): 56 data bytes
64 bytes from 185.4.142.38: seq=0 ttl=58 time=3.704 ms

PING mi-speedtest.planetel.it (185.4.142.110): 56 data bytes
64 bytes from 185.4.142.110: seq=0 ttl=58 time=3.603 ms

PING bs-speedtest.planetel.it (185.4.142.111): 56 data bytes
64 bytes from 185.4.142.111: seq=0 ttl=58 time=3.740 ms

PING vi-speedtest.planetel.it (185.4.142.112): 56 data bytes
64 bytes from 185.4.142.112: seq=0 ttl=58 time=3.661 ms

PING vr-speedtest.planetel.it (185.4.142.113): 56 data bytes
64 bytes from 185.4.142.113: seq=0 ttl=58 time=3.801 ms

PING ipc-speedtest.planetel.it (185.4.142.114): 56 data bytes
64 bytes from 185.4.142.114: seq=0 ttl=58 time=3.573 ms

PING si-speedtest.planetel.it (185.4.142.115): 56 data bytes
64 bytes from 185.4.142.115: seq=0 ttl=58 time=3.154 ms

PING na-speedtest.planetel.it (185.4.142.116): 56 data bytes
64 bytes from 185.4.142.116: seq=0 ttl=58 time=3.676 ms

[
  {
    "url": "http://speedtest.planetel.it:8080/speedtest/upload.php",
    "lat": "45.6983",
    "lon": "9.6773",
    "name": "Bergamo",
    "country": "Italy",
    "cc": "IT",
    "sponsor": "Planetel",
    "id": "23925",
    "host": "speedtest.planetel.it:8080"
  },
  {
    "url": "http://mi-speedtest.planetel.it:8080/speedtest/upload.php",
    "lat": "45.4654",
    "lon": "9.1859",
    "name": "Milano",
    "country": "Italy",
    "cc": "IT",
    "sponsor": "Planetel",
    "id": "34117",
    "host": "mi-speedtest.planetel.it:8080"
  },
  {
    "url": "http://bs-speedtest.planetel.it:8080/speedtest/upload.php",
    "lat": "45.5417",
    "lon": "10.2167",
    "name": "Brescia",
    "country": "Italy",
    "cc": "IT",
    "sponsor": "Planetel",
    "id": "34118",
    "host": "bs-speedtest.planetel.it:8080"
  },
  {
    "url": "http://vr-speedtest.planetel.it:8080/speedtest/upload.php",
    "lat": "45.4333",
    "lon": "10.9833",
    "name": "Verona",
    "country": "Italy",
    "cc": "IT",
    "sponsor": "Planetel",
    "id": "34132",
    "host": "vr-speedtest.planetel.it:8080"
  },
  {
    "url": "http://vi-speedtest.planetel.it:8080/speedtest/upload.php",
    "lat": "45.5500",
    "lon": "11.5500",
    "name": "Vicenza",
    "country": "Italy",
    "cc": "IT",
    "sponsor": "Planetel",
    "id": "34133",
    "host": "vi-speedtest.planetel.it:8080"
  },
  {
    "url": "http://na-speedtest.planetel.it:8080/speedtest/upload.php",
    "lat": "40.8518",
    "lon": "14.2681",
    "name": "Napoli",
    "country": "Italy",
    "cc": "IT",
    "sponsor": "Planetel",
    "id": "34134",
    "host": "na-speedtest.planetel.it:8080"
  },
  {
    "url": "http://ipc-speedtest.planetel.it:8080/speedtest/upload.php",
    "lat": "45.5500",
    "lon": "11.5500",
    "name": "Vicenza",
    "country": "Italy",
    "cc": "IT",
    "sponsor": "IPCompany",
    "id": "34135",
    "host": "ipc-speedtest.planetel.it:8080"
  },
  {
    "url": "http://si-speedtest.planetel.it:8080/speedtest/upload.php",
    "lat": "45.5417",
    "lon": "10.2167",
    "name": "Brescia",
    "country": "Italy",
    "cc": "IT",
    "sponsor": "Servizi Internet",
    "id": "34136",
    "host": "si-speedtest.planetel.it:8080"
  }
]

aternopae

Dunque per aggirare tutti i dubbi ho fatto quanto segue:

aperto speedtest.net dentro al browser (Chrome)
selezionato come destinazione EOLO
aperto Wireshark, avviata cattura pacchetti
avviato speedtest
attesa fine speedtest
fermata cattura
individuata la sessione
fatto screenshot
incollato sul forum 😅

concluso che l'applet "frega" i limiti del browser facendo una sessione fasulla http (non chiedetemi come, se mi chiedete di networking ho 24 anni di esperienza professionale, ma non sono uno sviluppatore di app). Probabilmente nel DOM del browser c'è modo di prendere controllo della sessione HTTP ad un livello RAW.

Se il mio provider nattasse 88.149.202.248 su un qualunque altro IP, a patto che questi corrisponda ad un host con la servlet Ookla aperta, l'unico controllo che viene fatto a mio avviso è "formale" del traffico che gira nella sessione, che è qualcosa di proprietario Ookla, ma se risponde qualcosa che parla "quella lingua" allora inizia una sessione speedtest, che però non avviene verso 88.149.202.248 e quindi fa un giro diverso che ha misure diverse.

P.S. a riprova che la sessione HTTP è "fasulla" se su Wireshark clicchi "Segui HTTP" non trova la sessione, perché appunto non è correttamente formata. Se segui il flusso TCP invece vedi tutta la sessione che in apparenza è ciarpame, in realtà è "lingua Ookla". Probabilmente è una cavolata, ma sarà cifrata in qualche modo per evitare che gli facciano retroingegneria.

nanomad

aternopae
Boh non so cosa stai guardando, magari wireshark ti ha troncato il buffer ... considera che il protocollo di speedtest via browser è abbastanza semplice.

Si apre un connessione websocket sicura (TLS) verso wss://test.eolo.it:8080/ws?
Il browser manda i seguenti messaggi WSS, in ordine:
- HI {GUID}
- GETIP
- CAPABILITIES
A cui il server risponde con
- HELLO 2.9 (2.9.2) 2021-11-30.2159.ffae0e0
- YOURIP 151.21.xxx.xxx
- CAPABILITIES SERVER_HOST_AUTH UPLOAD_STATS
  Dopodichè inizia il flusso di PING/PONG tra server e client a mo di keepalive via WS
In parallelo il client si annuncia anche via GET HTTPS con delle chiamate di hello
GET https://test.eolo.it:8080/hello?nocache={XXX}&guid={GUID}
Poi inizia il test di download, con dei flussi GET HTTPS classici:
GET https://test.eolo.it:8080/download?nocache={}&size=25000000&guid={GUID}
Finito il test di download parte quello di upload, fatto via websocket. Il payload è binario/cifrato ma ha sempre l'intestazione UPLOAD all'inizio dei messaggi
Infine il client fa un POST verso l'endpoint di ookla per l'upload dei risultati

Tutto il flusso avviene via HTTPS/WSS quindi TLS. Per il provider è impossibile ridirigere il traffico a meno di non poter emettere un certificato per test.eolo.it:8080

Questo via browser. Fatto guardando banalmente l'inspeector di edge, altro che wireshark 😵

LATIITAY

aternopae oh sei de coccio eh... Sta facendo HTTPS sulla porta 8080. Se non mi credi apri entrambi e vedi: http://test.eolo.it:8080/ https://test.eolo.it:8080/

Inoltre se vuoi prova a far riconoscere a Wireshark la 8080 come HTTPS e non HTTP e vedi che te lo riconosce...

nanomad HI {GUID}
GETIP
CAPABILITIES

A cui il server risponde con
HELLO 2.9 (2.9.2) 2021-11-30.2159.ffae0e0
YOURIP 151.21.xxx.xxx
CAPABILITIES SERVER_HOST_AUTH UPLOAD_STATS
Dopodichè inizia il flusso di PING/PONG tra server e client a mo di keepalive via WS

Ecco, non mi sono messo a fare reverse engineering del protocollo, pensavo fosse chissa' cosa di binario, e invece, LOL

Chissa' cosa e' quel SERVER_HOST_AUTH piuttosto... 🤔

nanomad wireshark

Semplicemente Wireshark si aspetta che sulla 8080 ci sia HTTP e non HTTPS 😅 ma l'OoklaServer accetta entrambi i protocolli sulla 8080... E forse anche un terzo protocollo proprietario delle app (che i browser moderni senza flash e senza java NON possono usare).

LucaTheHacker

nanomad Tutto il flusso avviene via HTTPS/WSS quindi TLS. Per il provider è impossibile ridirigere il traffico a meno di non poter emettere un certificato per test.eolo.it:8080

C'è solo un ulteriore caso: hai il certificato installato sul PC da cui esegui il test.
In tal caso il browser non dovrebbe fare storie, perché letteralmente gli stai dicendo "fidati a forza".

Qualche versione della CLI presenta SSL Pinning comunque, ed in quei casi non risolvi manco installandoti il certificato.

aternopae

LATIITAY Semplicemente Wireshark si aspetta che sulla 8080 ci sia HTTP e non HTTPS

No, Wireshark non si aspetta proprio un bel niente ed è per questo che è uno strumento prezioso a livello professionale: si tratta di un tool che è in grado di fare un'inspection approfondita di ogni singolo pacchetto e si usa proprio per fare troubleshooting complessi in apparati di rete perché è in grado di rilevare la tipologia di traffico in base al traffico stesso e non solo guardando alle porte TCP.

Conosce praticamente tutti i protocolli noti, anche esotici.

Nela schermata che vedi si può anche vedere che è capace di scomporre i singoli pacchetti di traffico a più livelli dividendo il frame ethernet, il quale contiene un frame IPv4, il quale a sua volta contiene un frame TCP che a sua volta contiene un frame HTTP malformato.

Ti consente poi di esplodere i singoli valori di pacchetto in una struttura gerarchica (anch'essa visibile nello screenshot) e facile da percorrere. Infine se passi col mouse su uno dei campi te lo evidenzia in blu e lo mette in relazione con il dump esadecimale che sta in basso nella schermata (non visibile nello screenshot).

Se fosse HTTPS nella sessione sarebbero visibili i pacchetti SSL/TLS in principio di sessione con lo scambio certificati ben in evidenza, mentre la sessione HTTP intunnellata dentro il tunnel SSL/TLS sarebbe invisibile in quanto cifrata.

Nel test che ho fatto e di cui lo screenshot è allegato sopra HTTPS non era da nessuna parte, si vede anzi la connessione TCP andare su alla porta 8080 e poi immediatamente dopo un ACK parte un "Malformed http" che probabilmente è quel qualcosa che "inganna" il motore del browser per aggirare limiti vari.

Come vedi dallo screenshot il pacchetto viene riconosciuto da Wireshark perché la prima metà è conforme all'HTTP (vedi parte evidenziata in giallo) e corrisponde ad un header HTTP correttamente formato ma poi prosegue con cose strane sue (parte evidenziata in rosso) che è la "lingua Ookla" che l'applet parla con la servlet.

Come regola generale in networking la porta TCP a cui ci si collega è un dato di marginale rilievo: un server HTTP tipicamente ascolta alla 80/TCP ma nessuno ti vieta di metterlo alla 81 o 150 o 15000, un server HTTPS tipicamente ascolta alla 443/TCP ma non significa niente. Anche la 8080/TCP è tipicamente usata per i proxy, ma ci sono proxy alla 9000, 9001 o saiilciufolodove in base a quanto hanno fumato male i sysadmin quel giorno ecc. perché non c'è nessun obbligo a riguardo, solo raccomandazioni.

« Pagina precedente Pagina successiva »

Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈 🇵🇸
P.I. IT16712091004 - info@fibraclick.it

♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile