Alberto Bartoli - Blog

Ho scritto delle dispense per il corso di "Reti di Calcolatori" ed ho deciso di renderle pubbliche. Sono consultabili da smartphone  e sono in inglese. Gli argomenti sono più o meno i seguenti: Introduzione : Applicazioni, protocolli, client e server DNS : funzionalità ed implementazione Email : funzionalità ed implementazione Web : pagine, sessioni, autenticazione, analytics Web - The Big Brother : tracking e profiling degli utenti IP : assegnazione dei network number, routing, ARP, firewall Security : proprietà di sicurezza con network attacker, distribuzione delle chiavi, certificati, TLS/HTTPS E' stato un grosso impegno, spero siano utili. Apprezzerò molto commenti, critiche e segnalazioni di imprecisioni. https://bartoli.inginf.units.it/didattica/dispense-reti-di-calcolatori

Nella lezione di "reti di calcolatori" di ieri mi sono reso conto che devo insistere maggiormente per sottolineare un aspetto di SSL (quindi di HTTPS) che a me pareva banale ma che evidentemente banale non è. SSL fornisce garanzie di sicurezza (autenticazione, integrità, riservatezza) tra le due estremità della connessione TCP. Fornisce cioè garanzie relative allo spostamento di dati tra un punto ed un altro. SSL non fornisce nessunissima garanzia di sicurezza "nei calcolatori" alle due estremità della connessione. Esempio semplicissimo: un attaccante può modificare un documento statico sul server; oppure può modificare i programmi sul server che generano i documenti dinamici. SSL continua a fornire le proprie garanzie: i dati sono autentici, riservati ed integri da una estremità all'altra della connessione. Ma i dati che viaggiano nella connessione non sono quelli che il server "avrebbe voluto inviare". Da un altro punto di vista, il dato sul ...

Ieri a lezione abbiamo detto che se un client CX genera (in modo fraudolento) una request RX contenente l'identifier di una sessione di un altro client C, allora RX viene elaborata dal server come se fosse stata generata da C. Ciò è evidentemente molto spiacevole. Specialmente se la sessione è "autenticata", cioè l'utente che sta controllando C ha dimostrato la propria identità al server (con meccanismi che vedremo nella prossima lezione) ed il server ha quindi inserito nello stato della sessione informazioni quali "sessione autenticata, username rettore ateneo" . In questo modo, infatti, CX può accedere in lettura e scrittura a dati privati dell'utente che sta controllando C. Superfluo evidenziare le implicazioni. Ho anche detto che queste cose, fino a pochissimi anni fa, erano talmente facili da fare che erano stati sviluppati software gratuiti in grado di farlo in modo automatico. In pratica, bastava osservare il traffico in una rete WiFi per racc...

Nella lezione di ieri abbiamo descritto HTTPS, il protocollo utilizzato comunemente per accedere a servizi autenticati (GMail, Facebook, banche, acquisti on line, etc). Abbiamo evidenziato che di norma il web server espone il form nel quale inserire le credenziali attraverso HTTPS. Ciò sembra inutile, in quanto non c'è nessun vantaggio nell'imporre che la richiesta di prelievo del form e lo stesso form viaggino con garanzia di riservatezza. La riservatezza è necessaria solo per la richiesta inviata subito dopo avere prelevato il form, cioè per la richiesta che contiene le credenziali. Questa slide sintetizza il motivo per il quale prelevare il form su HTTPS sembra inutile ma non lo è: Secondo molti esperti, nel 2011 il governo della Tunisia ha forzato tutti gli Internet provider del paese a modificare i form esposti su HTTP dai servizi "importanti" (GMail, Facebook etc). Nelle pagine contenenti i form venivano aggiunte, durante il transito dal server al browser,...

La visualizzazione di ogni singola "pagina web" non è il risultato del prelievo di un documento HTML ed una manciata di file JPG. E' il risultato del prelievo di molti documenti da più server, e dell' elaborazione nel browser di molti programmi Javascript prelevati da più server. In un post di un pò di tempo fa ho anche riportato statistiche molto interessanti calcolate da Google: in media, la visualizzazione di una pagina richiede il prelievo di più di 40 documenti da 7 server diversi. Ho trovato un servizio web molto interessante per evidenziare questo fenomeno. Si tratta di urlquery.net . E' stato sviluppato per fare analisi relative al malware diffuso via web, ma è molto interessante anche per capire com'è realizzata una pagina "vera". Gli ho chiesto di analizzare www.gazzetta.it . Dopo qualche decina di secondi ha fornito un report molto dettagliato, con alcuni aspetti di non facile interpretazione ma molto istruttivo: Eseguiti 194 (...

Nelle lezioni di Reti di Calcolatori ho insistito molto, per la prima volta, sul fatto che clickare su di un link può essere sufficiente per prendere un virus. Da ciò discende, tra le altre cose, che prima di clickare su link contenuti in email ricevuti è bene pensarci molto, ma molto, ma molto bene. E se possibile è meglio evitare di farlo. Non avevo mai insistito su questo punto perché mi sembrava ovvio, ma ho cominciato a pensare che sia meglio dirlo esplicitamente. Ne abbiamo parlato pochi giorni fa. Proprio oggi la Polizia Slovena ha arrestato 5 persone coinvolte in una truffa basata proprio su meccanismi di questo genere e che ha coinvolto trasferimento di denaro su conti bancari per circa due milioni di euro (forse questa tempistica vi sembra sospetta...comunque no, non sono coinvolto...). Alcune frasi di questa notizia riportano esattamente quanto ho detto:  ... shows how damaging clicking on links that appear in spoofed messages can be... When in doubt, don't click....

Il funzionamento del Web dietro le quinte---a livello HTTP---è cambiato molto negli ultimi anni. Una delle componenti più importanti di questo cambiamento è il protocollo SPDY ("speedy"). L'articolo indicato più sotto descrive molto, molto bene la faccenda. E' molto tecnico, ma è scritto in modo chiaro e (abbastanza) facile da seguire. Consiglio caldissimamente la lettura a chiunque abbia interesse a capire il funzionamento e l'evoluzione di Internet a livello HTTP-e-simili. In particolare l'ultima sezione, Future SPDY Gateways, contiene considerazioni molto interessanti sulle forze in gioco, anche a livello economico e di incentivi, e sulle ulteriori (radicali) evoluzioni possibili. an experimental low-latency application-layer protocol  designed by Google and introduced in 2009 as a drop-in replacement for HTTP on clients and servers. SPDY retains the semantics of HTTP, allowing content to remain unchanged on servers while adding request multiplex...

Il capitale cresce di 16 (sedici) volte . Ovviamente il metodo è  illegale . Ho letto proprio oggi una ricerca molto interessante sugli aspetti tecnici ed economici della pornografia su Internet. Per inciso, qualche anno fa uno degli autori della ricerca ha ospitato nel proprio laboratorio per qualche mese il peggior calciatore  del nostro laboratorio . La ricerca descrive, oltre a molte altre cose, una tecnica che permette di incassare circa 2600$ a fronte di un investimento di soli 160$. In estrema sintesi il tutto funziona in questo modo. Si mette su un sito web, ad un URL U. Si contatta un traffic broker specializzato in pornografia. In pratica, si paga il broker per inviarci richieste HTTP. Il traffic broker è un sito web specializzato nell'attrarre traffico di utenti interessati alla pornografia. Pagando il broker ed indicandogli un nostro URL U, il broker garantisce di inviarci utenti all'url U da noi indicato.  Quando un utente contatta il broker, quest...

E' ben noto, come sottolineo spesso a "Reti di Calcolatori I", che: una pagina web è composta da molti documenti; questi documenti possono essere prelevati da molti host; gli host spesso non hanno nulla a che vedere con il sito dal quale si sta prelevando la pagina. L'immagine seguente mostra questo fenomeno in modo interessante. Il server DNS del nostro lab ogni tanto "perde" le richieste (ne stiamo installando uno nuovo) il che, ogni tanto, impedisce il prelievo di qualche documento web. Quando ciò succede, Chrome visualizza un avviso nello spazio in cui avrebbe dovuto visualizzare il documento (clickare per ingrandire e vedi colonna di destra): uno crede di contattare solo www.corriere.it  ma in realtà contatta anche rcspfm.simply.com . Questo meccanismo è utilizzato per molti motivi leciti, ad esempio la delega della gestione delle pubblicità, del conteggio delle visite etc. E' utilizzato anche per motivi meno leciti, quali la diffusione d...

Il testo della provetta chiedeva di svolgere l'esercizio sulla autenticazione HTTP mantenendo le sessioni con i cookie, non con URL rewriting (basta leggere il testo), ma ho considerato corretti anche gli svolgimenti fatti con URL rewriting. Alcuni hanno però introdotto un errore molto grave. Il client chiede un documento protetto, con una request appartenente ad una sessione; il server risponde con un form; Il client invia una request con le credenziali; il server risponde con il documento protetto richiesto in precedenza Segue il traffico corrispondente al punto 2: Domanda: come fa il server a sapere che quando riceve una richiesta verso credenziali.asp deve rispondere con il documento i3.gif ? Telepatia ? (l'errore è che la request POST deve contenere l'identificatore della sessione utilizzata al punto 1; qui non c'è nessun identificatore)

Ho ripetuto a lezione non so quante volte che svolgere esercizi sull'URL rewriting utilizzando la notazione indicata qui sotto è sbagliato: Come devo interpretare l'ultima riga ? La sequenza di caratteri "index.html ? 393939" ( esattamente come la prima riga e la seconda riga ) "Questa risposta HTTP trasporta, dopo la linea vuota, il  nome  del documento di URL relativo index.html?393939" "Questa risposta HTTP trasporta, dopo la linea vuota, il  contenuto  del documento di URL relativo index.html?393939" "Questa risposta HTTP trasporta, dopo la linea vuota, il contenuto del documento di URL relativo index.html seguito dalla sequenza di caratteri ?393939" "Questa risposta HTTP trasporta, dopo la linea vuota, il contenuto del documento di URL relativo index.html con tutti gli URL modificati appendendo in coda la sequenza di caratteri ?393939" (questa è la risposta corretta). ... In nessuna lingua, dialetto, notazio...

Domanda Non mi è chiaro se quando desidero accedere a immagini protette e il server mantiente la sessione tramite url rewriting, l'url delle immagini verrà modificato o meno. Il problema è che mi autentico tramite basic authentication. Da quello che ho capito, la basic non ha bisogno della sessione, quindi io chiederò l'immagine (senza appendere il session id) inviando le mie credenziali.   Ma se il sistema mantiene la sessione, la response conterrà l'URL modificato o meno? Risposta Non mi è chiaro cosa intenda per "url delle immagini". Se U è l'URL che identifica una immagine I e U è contenuto in un documento D generato dal server, allora il server modifica il contenuto di D in modo che U contenga l'identificatore della sessione (es: U?id=8749837098) Il contenuto dell'immagine identificata da U non è mai modificato (perché una immagine non contiene URL)

Uno strumento gratuito per "infilarsi" in una sessione. Sembra incredibile, ma le cose funzionano veramente così... HTTP session hijacking (sometimes called "sidejacking") is when an attacker gets a hold of a user's cookie, allowing them to do anything the user can do on a particular website. On an open wireless network, cookies are basically shouted through the air, making these attacks extremely easy.  http://codebutler.com/firesheep (segnalazione di Maurizio Pozzobon) Vedi anche questo post . Update (Novembre 2010) Altri link molto interessanti sul tema: Online services security report card Even Forced SSL is broken for Facebook Google Twitter

Uno studente di Reti I (Alfredo Canziani) mi ha inviato una "sniffata" di traffico HTTP ottenuto quando si autenticava da casa al servizio webmail di ateneo. Ha provato con Internet Explorer, senza riuscire ad autenticarsi, e con Firefox, riuscendo ad autenticarsi. La cosa è interessante anche perché il lato server sembra Microsoft. Il traffico (lungo e prolisso) si trova qui . Ci sono alcuni aspetti interessanti per Reti II, tra i quali: Firefox supporta veramente NTLM; il valore "Negotiate" per lo header "WWW-Authenticate" non significa " mettiamoci d'accordo ed usiamo uno dei valori dei WWW-Authenticate seguenti " (il significato che avevo detto a lezione); significa invece " mettiamoci d'accordo, se scegli questo valore ti elenco i meccanismi che supporto in aggiunta a quelli che ho già elencato nei WWW-Authenticate seguenti ". E' stato proposto da Microsoft per l'interazione con i propri web server. Tipicament...

Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP(S) traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language. Fiddler is freeware and can debug traffic from virtually any application, including Internet Explorer, Mozilla Firefox, Opera, and thousands more. http://www.fiddler2.com/fiddler2/ (segnalatomi da Alfredo Canziani 2009/2010)

HttpFox: An HTTP analyzer addon for Firefox HttpFox monitors and analyzes all incoming and outgoing HTTP traffic between the browser and the web servers. It aims to bring the functionality known from tools like HttpWatch or IEInspector to the Firefox browser. Information available per request includes: - Request and response headers - Sent and received cookies - Querystring parameters - POST parameters - Response body ALTRI FIREFOX PLUGIN SIMILI: Live HTTP Headers 0.14 View HTTP headers of a page and while browsing. Tamper Data 10.1.0 Use tamperdata to view and modify HTTP/HTTPS headers and post parameters. Trace and time http response/requests. Security test web applications by modifying POST parameters.

TinySSL is a Secure Sockets Layer (SSL v2/v3) and Transport Layer Security Web Server Daemon based on TinyWeb. TinySSL comes under the same licence as for TinyWEB and is FREE for commercial and non-commercial use. NOTA: SSL è trattato nella seconda parte del corso; TinySSL è utile, anche senza SSL, per "giocare" con la BASIC authentication (che non è supportata da TinyWeb); se non interessa SSL, saltare tutto e andare direttamente alla: Access Authentication TinySSL supports Basic Access Authentication (rfc-2068), which is configured in realms.cfg file. There are MD5/DES-hybrid hashes (also may be called digests) that allow avoiding cleartext reusable passwords to be stored in realms.cfg file. Each line of the file describes a single realm and has the following format: ListOfURLs RealmName User1 User2 User3 User4 .... ListOfURLs is a list of URLs (pipe-seperated) belonging to specified realm, RealmName is name of the realm as per rfc-2068 and Use...

(Carlo Tauraso 2008/2009) http://docs.google.com/Doc?id=dfkrns54_747jn84gmfq

Sidejacking is a form of “HTTP session hijacking” that works with “passive” eavesdropping. HTTP session hijacking is where the hacker grabs your “session cookies”. Your session with the web server is identified with a unique cookie. This cookie is sent to your browser at the start of the session, and your browser echos it back from that point forward. There are many forms of session hijacking. Some use cross-site scripting to grab them from your browser. Some use “man-in-the-middle” attacks to intercept the connection then resend it. The sidejacking method uses passive eavesdropping of cookies. Users collect cookies using a packet-sniffer, then import them into the browser. Unlike other methods of session hijacking, there is nothing the user can possibly see that would tell them their session is being hijacked. They can’t “View source” to find errant JavaScript (as they could with cross-site-scripting attacks). They can’t sniff their own traffic is see that it’s being ...