Esercizio Zero Provetta 2 - Errori frequenti

Quando un nodo si sposta da una network ad un'altra network occorre riconfigurare le tabelle di routing nei suoi due gateway di default (quello precedente e quello successivo allo spostamento)

La risposta corretta è Falso. Quando mai una tabella di routing dipende dalla posizione di un nodo? La tabella di routing descrive i network number, non i singoli nodi. Inoltre noi abbiamo visto il routing statico, in cui le tabelle sono immutabili.

Un nodo con indirizzo IP privato può comunicare con nodi di altre network solo se almeno un router dai quali passano i pacchetti ha un modulo NAT

La risposta corretta è Falso. Nodi con indirizzo privato all'interno di una stessa organizzazione comunicano "tranquillamente" tra di loro, senza necessità di NAT. Indirizzi IP privati e pubblici sono, all'interno di una stessa organizzazione, indistinguibili tra loro.

131.114.9.128/25 può indicare sia un network number sia una coppia indirizzo IP-network number a cui appartiene quell'indirizzo IP

La risposta corretta è falso. /25 significa che la suddivisione è nel quarto byte; 128 in binario è 1000 0000; quindi la suddivisione lascia 0 come host number; quindi non può essere un indirizzo IP.

Un nodo che si collega ad Internet invia un frame "ARP Request" sia che abbia configurazione IP statica sia che abbia configurazione IP dinamica

La risposta corretta è vero. Viene inviata sempre una ARP Request in cui il nodo chiede quale sia l'indirizzo Ethernet associato al proprio indirizzo IP (Gratuitous ARP), indipendente da come sia stato acquisito l'indirizzo IP.

Condizione necessaria per potere verificare la firma digitale su un documento è che il Subject che ha firmato il documento sia compreso nell'elenco dei Subject dei certificati contenuti nel KeySet

La risposta corretta è Falso. Tutto il marchingegno di certificati, certification authority, keyset e trustset serve proprio per evitare di dovere avere già disponibile la chiave pubblica dei Subject. I Subject dei certificati contenuti nel KeySet sono solo le certification authorities.

Condizione necessaria per potere utilizzare un certificato è che il Subject del certificato sia compreso nell'elenco dei Subject dei certificati contenuti nel TrustSet

La risposta corretta è Falso, per gli stessi motivi di cui sopra.

Approfondimenti su privacy e sorveglianza

https://www.schneier.com/blog/archives/2013/11/surveillance_as_1.html

https://bartoli-alberto.blogspot.com/search?q=cambridge

http://crackedlabs.org/en/corporate-surveillance

https://www.newyorker.com/magazine/2018/09/17/can-mark-zuckerberg-fix-facebook-before-it-breaks-democracy 

Cookie con scadenza nel passato (!)

per curiosità stavo analizzando gli header della response che si riceve con questo link amazon:

https://www.amazon.it/gp/goldbox

E mi sono accorto che c'è un set-cookie con expiry date nel passato. Come è possibile ? Si tratta di un errore del server amazon?

Penso proprio che sia un errore nel codice del server amazon.

Errori di questo genere sono descritti, ad esempio, qui:

http://stackoverflow.com/questions/24351257/expires-attribute-points-to-a-date-in-the-past

(non occorre approfondire: l'idea è che, per quanto ne so io, non può essere una situazione voluta dal server).

Ho analizzato il traffico in dettaglio (con lo strumento Fiddler: potente ma non banalissimo da usare con i siti HTTPS per motivi che capiremo alla fine del corso). Ho visto che la situazione è ancora più intricata perché non solo ci sono tanti cookie ma addirittura ci sono più cookie con lo stesso id ma date di scadenza diverse; in particolare (per i valori delle coppie name-value: XXXX l'ho messo io per oscurare i valori veri; - è il valore vero: anche questo è un forte indizio di errore nel codice):

Ci sono 4 cookie con data di scadenza nell'anno 2036:

• Set-cookie: ubid-acbit=XXXXXXXXXXX; path=/; domain=.amazon.it; expires=Tue, 01-Jan-2036 00:00:01 GMT
• Set-cookie: lc-acbit=it_IT; path=/; domain=.amazon.it; expires=Tue, 01-Jan-2036 00:00:01 GMT
• Set-cookie: session-id-time=XXXXXXXXXXX; path=/; domain=.amazon.it; expires=Tue, 01-Jan-2036 00:00:01 GMT
• Set-cookie: session-id=XXXXXXXX; path=/; domain=.amazon.it; expires=Tue, 01-Jan-2036 00:00:01 GMT

Altri 4 cookie con stesso id e data di scadenza nel 2004,

• Set-Cookie: ubid-acbit=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: lc-acbit=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: session-id-time=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: session-id=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT

Più altri 7 o 8 che scadono nel 2004; 

• Set-Cookie: session-token=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: at-acbit=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: x-acbit=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: x-wl-uid=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: sess-at-acbit=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT
• Set-Cookie: UserPref=-; path=/; domain=.www.amazon.it; expires=Tue, 16-Nov-2004 07:28:28 GMT

I cookie del terzo gruppo sono scartati dal browser (già scaduti; non ho verificato nella tabella dei cookie del browser ma penso proprio che sia così).

Per gli altri due gruppi bisognerebbe vedere cosa dice esattamente il protocollo HTTP circa il comportamento da tenere in casi come questo; quale che sia la specifica http, comunque, il browser considera solo il cookie con data di scadenza più avanti nel tempo. Ho verificato questa affermazione ispezionando il contenuto della prima richiesta successiva verso amazon:

Cookie: session-token=YYYYY; x-wl-uid=YYYYY; ubid-acbit=XXXXX; lc-acbit=it_IT; session-id-time=XXXXX; session-id=XXXX

I 2 valori indicati con YYYY dovevano essere già presenti nel mio browser in precedenza. Gli altri 4 valori sono esattamente quelli con scadenza nel 2036, quelli del primo gruppo.

Riflessione

La domanda sorge spontanea: "ma com'è possibile che ci siano errori di questo genere?". La risposta è questa:

1) gli errori che non provocano problemi di funzionalità o sicurezza possono rimanere latenti per molto tempo (= nessuno se ne accorge);

1-bis) anche se qualcuno li scopre, si può decidere di non correggerli o di dare loro una priorità talmente bassa che in pratica non saranno mai corretti (proprio perché non causano problemi di funzionalità o sicurezza);

Riflessione ancora più importante

Questo esempio dovrebbe aiutare a capire ancora meglio il significato di "Come organizzo lo studio di Internet":

...Analizzare gli argomenti di Internet esattamente come si verificano nella realtà sarebbe didatticamente disastroso.

In ogni argomento si mescolano infatti:

1. elementi necessari per il funzionamento e fondamentali per la comprensione dell'argomento;
2. elementi non necessari per il funzionamento e/o non fondamentali per la comprensione;

Gli elementi 2 purtroppo sono tantissimi....

Invio dati a web server

ho un dubbio per quanto riguarda l’invio di dati al Web Server. Abbiamo detto che a seconda del valore di METHOD il browser fa una richiesta di tipo GET oppure POST. 

Se la richiesta è di tipo GET sarà del tipo: 

GET / script?QueryString 

….

linea vuota 

Non mi è ben chiaro perché, se usiamo GET per richiedere dei dati al server, aggiungiamo in coda allo script la QueryString. 

Perché il mondo reale è fatto di cose brutte e fatte male. Ormai dovrebbe essere chiaro. GET in inglese ha centomila significati, moltissimi legati al concetto di "prendere". Le richieste GET si usano per prendere documenti da un server. Purtroppo si usano anche per inviare dati ad un server, usando quel meccanismo ignobile (query string appesa in coda all'URL; il programma eseguito dal server estrae i dati dalla query string).

Non c'è quindi un motivo logico. E' così.

Anche in questo caso stiamo trasmettendo dei dati al server? 

Si, vedi sopra.

E' il caso di quando inseriamo dei dati nel motore di ricerca? 

Quando si inseriscono dati in un motore di ricerca, questi possono essere trasmessi con GET oppure con POST. Dipende da come è fatto il documento che ha inviato il motore di ricerca e da come è strutturato il programma del motore di ricerca.

Google invia dati tramite GET. Lo si può capire con i developer tools di chrome, o con un qualsiasi software in grado di mostrare il traffico HTTP. Lo si può capire anche analizzando la home page di google:

Lo si può capire indirettamente anche in questo modo: https://www.google.it/search?q=trieste

Clickando su quel link il browser esegue le stesse operazioni che esegue per ogni altro link, cioè invia una richiesta GET verso l'URL visualizzato (ho costruito il link in modo che il testo visualizzato coincida con l'URL). Il documento che si ottiene come risposta è la risposta standard di Google. Pertanto, Google è predisposto per ricevere dati via GET.

Inviando i dati a Google nel modo "canonico" (cioè nel form di google.it) si ottiene un documento di risposta il cui URL ha una query string con più coppie nome=valore (sopra ce n'era solo una). Ad esempio:

https://www.google.it/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=grande%20kaka

Clickando su questo link si ottiene ancora lo stesso documento di risposta (o lo si dovrebbe ottenere). Soprattutto, si osservano cose buone e giuste.

Prezzi variabili e sessioni di lunga durata

Un sito web con offerte commerciali può presentare ad uno stesso utente non autenticato informazioni diverse in momenti diversi.

Ad esempio, l'utente vede un prezzo P1 per il bene B in un certo giorno e vede un prezzo P2 per lo stesso bene B qualche giorno dopo. Oppure, l'utente vede che sono disponibili K1 copie del bene B un certo giorno e K2 copie dopo qualche giorno.

Il sito può mostrare informazioni "vere" (cioè le stesse informazioni per tutti gli utenti) ma può anche mostrare informazioni scelte appositamente per tentare di massimizzare un qualche obbiettivo commerciale (spingere l'utente ad acquistare il prima possibile). In questo secondo caso il sito può decidere di mostrare informazioni diverse ad utenti diversi, scelte tenendo conto di visite precedenti da parte dello stesso utente (ad esempio per mettergli fretta).

Il problema è questo: come fa il sito a capire se una richiesta fatta in un giorno ed una richiesta identica fatta qualche giorno dopo sono state fatte dallo stesso utente? (si considera il caso di utenti non autenticati; se l'utente è autenticato allora il problema non si pone).

La soluzione banale è basata sui cookie. Il sito invia nelle risposte un cookie con durata di molte settimane.

L'utente ha a disposizione un modo banale per neutralizzare questa tecnica: cancellare i cookie; oppure utilizzare la cosiddetta "navigazione in incognito", disponibile in ogni browser. Nel secondo caso il browser cancella tutti i cookie creati nella finestra "in incognito" indipendentemente dalla loro durata (quindi ogni visita successiva allo stesso sito con lo stesso browser non utilizzerà i cookie ricevuti in passato da quel sito).

Il sito ha la possibilità di neutralizzare queste difese da parte degli utenti. Il sito può ottenere molte informazioni sull'utente che ha inviato una data request combinando queste informazioni:

1. cookie (se presente);
2. zona geografica dell'indirizzo IP lato client;
3. browser fingerprint (informazioni di configurazione del browser e del sistema su cui si trova);

Combinando queste informazioni opportunamente, il sito è in grado di identificare ogni singolo utente con ottima approssimazione (ad eccezione dei siti che hanno centinaia di milioni di utenti; descrizione intuitiva, approssimata e semplificata).

Non è detto che un sito applichi questi metodi, ma tecnicamente può farlo.

L'utente può neutralizzare il punto 1; ha difficoltà a neutralizzare il punto 2 (dovrebbe viaggiare a molte centinaia di km di distanza ogni volta); ha forti difficoltà a neutralizzare il punto 3 (dovrebbe usare coppie browser-dispositivo diverse ogni volta).

HTTPS e crittografia a chiave pubblica: cosa può andare male

https://bartoli-alberto.blogspot.it/2016/05/https-e-crittografia-chiave-pubblica.html

Il link qui sopra discute casi in cui le ipotesi alla base dell'uso della crittografia non sono verificate.

Le cose possono andare male, nel senso che l'effetto è diverso da quello che uno si attenderebbe intuitivamente o ragionevolmente, anche se le ipotesi sono verificate:

se l'attaccante riesce ad ottenere un certificato valido da Verisign del tipo S = VenditaVino KPUB = numero ISSUER = Verisign FIRMA e nel trust set e key set di WC-A c'è Verisign allora WC-A riconosce valido quel certificato e l'attaccante può inviare anche pagine che non hanno nulla a che vedere con la vendita del vino.

questo vuol dire che se WC-A non legge il certificato allora qualsiasi attaccante che si sia fatto certificare da una CA che sta nel trust set e keyset di WC-A può ingannare WC-A ! O sbaglio?

​non sbaglia, ho evidenziato esempi del genere a lezione.​

Quindi se WC-A non legge il certificato l'autenticazione di fatto non c'è? Perchè se NON legge il certificato all'altra estremità potrebbe avere uno qualsiasi che si è fatto certificare da CA di cui si fida

​bisogna stare attenti al significato delle parole.

autenticazione ssl significa "partner conosce la kpriv associata alla kpub nel certificato; inoltre, se la CA dice la verità e le chiavi private sono davvero private, allora partner è quello indicato nel campo subject del certificato"

NON significa "partner è quello che io mi aspetto che sia, in base al contenuto delle pagine web che mi sta inviando"

HTTP: Autenticazione su webmail di ateneo

ATTENZIONE: informazioni del 2010

Le riporto il traffico HTTP effettuato con il browser IE e con FIREFOX inerente l'accesso alla casella di posta universitaria sul web.

(riportati qui sotto, dopo la mia risposta)

qui purtroppo intervengono aspetti che a lezione non vediamo; si fanno a Reti II.

Il server risponde dicendo: ti devi autenticare, io supporto 3 meccanismi: "mettiamoci d'accordo" (negotiate), NTLM, Basic;

Firefox sceglie NTLM (che a reti non facciamo) e dopo uno scambio un pò intricato riesce ad autenticarsi

IE sceglie invece il "mettiamoci d'accordo" e non riescono a mettersi d'accordo (!). Il che è singolare perché il server è Microsoft ed il browser è Microsoft, pertanto dovrebbero essere in grado di mettersi d'accordo. Non so perché non riescano a mettersi d'accordo, sospetto che il motivo sia questo:

*) il client (per come è configurato) se gli viene proposto negotiate allora lo sceglie; 

*) il server è stato configurato in modo che quando il client chiede "negotiate", allora il server accetta solo un terzo meccanismo che a reti non si fa e che si chiama Kerberos;

*) questo particolare client non supporta Kerberos e quindi non si mettono d'accordo.

altro esempio di quello che dico spesso: per capire le reti bisogna sforzarsi di guardare alla realtà con molta elasiticità. altrimenti non si capisce nulla di nulla...la realtà è troppo complicata per la presenza di molti dettagli concettualmente irrilevanti.

INTERNET EXPLORER

GET http://webmail.ing.units.it/exchange HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Accept-Language: it-IT
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: webmail.ing.units.it
Cookie: __utma=21185279.591501303.1269296037.1269303459.1269457175.3; __utmz=21185279.1269296037.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.4.10.1269457175; __utmc=21185279

 

HTTP/1.1 401 UnauthorizedContent-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="webmail.ing.units.it"
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:00:23 GMT
Proxy-Support: Session-Based-Authentication

 

<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>

 

GET http://webmail.ing.units.it/exchange HTTP/1.1Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Accept-Language: it-IT
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: __utma=21185279.591501303.1269296037.1269303459.1269457175.3; __utmz=21185279.1269296037.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.4.10.1269457175; __utmc=21185279
Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==
Host: webmail.ing.units.it

 

HTTP/1.1 401 UnauthorizedContent-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate TlRMTVNTUAACAAAABAAEADgAAAAVgonieK1Rw6d8At8AAAAAAAAAAIAAgAA8AAAABQLODgAAAA9EAFMAAgAEAEQAUwABABAAUwBFAFIAVgBJAE4ARwA1AAQAFgBkAHMALgB1AG4AaQB0AHMALgBpAHQAAwAoAHMAZQByAHYAaQBuAGcANQAuAGQAcwAuAHUAbgBpAHQAcwAuAGkAdAAFABYAZABzAC4AdQBuAGkAdABzAC4AaQB0AAAAAAA=
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:00:49 GMT
Proxy-Support: Session-Based-Authentication

 

<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>

 

GET http://webmail.ing.units.it/exchange HTTP/1.1Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Accept-Language: it-IT
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: __utma=21185279.591501303.1269296037.1269303459.1269457175.3; __utmz=21185279.1269296037.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.4.10.1269457175; __utmc=21185279
Host: webmail.ing.units.it
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAIoAAAAoASgBogAAABIAEgBYAAAADgAOAGoAAAASABIAeAAAABAAEADKAQAAFYKI4gYBsB0AAAAPIsy0u8P/lxYEmbDGLaL7gEEAVABDAE8ATABEAC0AUABDAFMAMQA2ADQAOAA5ADkAQQBUAEMATwBMAEQALQBQAEMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANCk2viZwkvSHk8AbOtkAUgEBAAAAAAAAZuwxU4TLygFtPP91tzPSFAAAAAACAAQARABTAAEAEABTAEUAUgBWAEkATgBHADUABAAWAGQAcwAuAHUAbgBpAHQAcwAuAGkAdAADACgAcwBlAHIAdgBpAG4AZwA1AC4AZABzAC4AdQBuAGkAdABzAC4AaQB0AAUAFgBkAHMALgB1AG4AaQB0AHMALgBpAHQACAAwADAAAAAAAAAAAQAAAAAQAAA+miYJ4qikKJ0o7U6X5Ryt52Zp6HPnj1joaoPJKowOzwoAEAAAAAAAAAAAAAAAAAAAAAAACQAsAEgAVABUAFAALwBzAGUAcgB2AGkAbgBnADUALgB1AG4AaQB0AHMALgBpAHQAAAAAAAAAAACb9zENiofg6F4C/UqLme4C

 

HTTP/1.1 401 Unauthorized
Content-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="webmail.ing.units.it"
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:00:49 GMT
Proxy-Support: Session-Based-Authentication

 

<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>

FIREFOX

GET http://webmail.ing.units.it/exchange HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279

 

HTTP/1.1 401 UnauthorizedContent-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="webmail.ing.units.it"
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:07:10 GMT
Proxy-Support: Session-Based-Authentication

 

<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>

 

GET http://webmail.ing.units.it/exchange HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279
Authorization: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==

 

HTTP/1.1 401 Unauthorized
Content-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: NTLM TlRMTVNTUAACAAAABAAEADgAAAAFgomik7/eomb8S4kAAAAAAAAAAIAAgAA8AAAABQLODgAAAA9EAFMAAgAEAEQAUwABABAAUwBFAFIAVgBJAE4ARwA1AAQAFgBkAHMALgB1AG4AaQB0AHMALgBpAHQAAwAoAHMAZQByAHYAaQBuAGcANQAuAGQAcwAuAHUAbgBpAHQAcwAuAGkAdAAFABYAZABzAC4AdQBuAGkAdABzAC4AaQB0AAAAAAA=
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:07:10 GMT
Proxy-Support: Session-Based-Authentication

 

<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>

 

GET http://webmail.ing.units.it/exchange HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279
Authorization: NTLM TlRMTVNTUAADAAAAGAAYAHgAAAAuAS4BkAAAAAAAAABYAAAADgAOAFgAAAASABIAZgAAAAAAAAC+AQAABYKIogYBsB0AAAAPtdAL6R8OtcOJ2I7rO8AwzVMAMQA2ADQAOAA5ADkAQQBUAEMATwBMAEQALQBQAEMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgJ4MAUjYi3OHIWebOJCt/wEBAAAAAAAAZSUYNoXLygFx/gJjFIX+AAAAAAACAAQARABTAAEAEABTAEUAUgBWAEkATgBHADUABAAWAGQAcwAuAHUAbgBpAHQAcwAuAGkAdAADACgAcwBlAHIAdgBpAG4AZwA1AC4AZABzAC4AdQBuAGkAdABzAC4AaQB0AAUAFgBkAHMALgB1AG4AaQB0AHMALgBpAHQACAAwADAAAAAAAAAAAQAAAAAgAAA+miYJ4qikKJ0o7U6X5Ryt52Zp6HPnj1joaoPJKowOzwoAEAAAAAAAAAAAAAAAAAAAAAAACQAyAEgAVABUAFAALwB3AGUAYgBtAGEAaQBsAC4AaQBuAGcALgB1AG4AaQB0AHMALgBpAHQAAAAAAAAAAAA=

 

HTTP/1.1 302 Object MovedContent-Length: 160
Content-Type: text/html
Location: http://webmail.ing.units.it/exchange/
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:07:10 GMT

 

<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="http://webmail.ing.units.it/exchange/">here</a></body>

 

GET http://webmail.ing.units.it/exchange/ HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.units.it/studenti/mailservers/index.php/from/studenti?posta=studenti
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279

 

HTTP/1.1 200 OKDate: Wed, 24 Mar 2010 19:07:10 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Content-Type: text/html
Content-Length: 1168
MS-WebStorage: 6.5.7638
Cache-Control: no-cache

 

<!--Copyright (c) 2000-2003 Microsoft Corporation. All rights reserved.-->
<!--CURRENT FILE== "NON-IE5" "NON-WIN32" frameset -->
<!--CURRENT TEMPLATE == frameset.00000000 -->
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<TITLE>Microsoft Outlook Web Access</TITLE>
<BASE href="http://webmail.ing.units.it/exchange/s164899/">
</HEAD>
<SCRIPT language="JavaScript">
var g_iNewWindowWidth = 700;
var g_iNewWindowHeight = 500;
var g_fWarnOnLogOff=false;
function WarnOnLogOff()
{
if (g_fWarnOnLogOff)
alert("Per evitare che utenti non autorizzati accedano alla cassetta postale, chiudere tutte le finestre del browser dopo aver utilizzato Outlook Web Access.");
}
</SCRIPT>
<FRAMESET OnUnload="WarnOnLogOff()" framespacing="3" cols="190,*"><FRAME bordercolor="#3D5FA3" name="navbar" title="Esplorazione" src="./?Cmd=navbar" marginheight="0" marginwidth="0" scrolling="auto" border="1"><FRAME name="viewer" title="Sommario" src="Posta%20in%20arrivo/?Cmd=contents" scrolling="auto">
<NOFRAMES>
<BODY><P>This page uses frames, but your browser doesn't support them.</P></BODY>
</NOFRAMES>
</FRAMESET>
</HTML>

 

GET http://webmail.ing.units.it/exchange/s164899/?Cmd=navbar HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://webmail.ing.units.it/exchange/
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279

 

HTTP/1.1 401 UnauthorizedContent-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="webmail.ing.units.it"
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Date: Wed, 24 Mar 2010 19:07:10 GMT
Proxy-Support: Session-Based-Authentication

 

<html><head><title>Error</title></head><body>Error: Access is Denied.</body></html>

 

GET http://webmail.ing.units.it/exchange/s164899/Posta%20in%20arrivo/?Cmd=contents HTTP/1.1Host: webmail.ing.units.it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2) Gecko/20100115 Firefox/3.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://webmail.ing.units.it/exchange/
Cookie: sessionid=2d706f6f-f849-4ef2-ae26-8a6e5c54d29c:0x410; __utma=21185279.667825429.1264723981.1269291767.1269457521.8; __utmz=21185279.1264723981.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=21185279.6.10.1269457521; __utmc=21185279

 

HTTP/1.1 200 OKDate: Wed, 24 Mar 2010 19:07:10 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Content-Type: text/html
Content-Length: 64948
MS-WebStorage: 6.5.7638
Cache-Control: no-cache

 

// SEGUE DOCUMENTO HTML

DNS: tool per interrogare name server

Forse qualcuno di voi lo avrà già notato, ma vi segnalo che esistono alcuni servizi web che replicano le funzionalità dello strumento "dig"; alcuni quasi esattamente, altri con ottima approssimazione.

http://www.geektools.com/digtool.php sembra sostanzialmente identico a dig, sospetto che abbiano messo sul web server un dig e la pagina sia solo una sorta di intermediario grafico verso quello strumento. Pertanto si tratta di un client DNS in esecuzione sul server www.geektools.com; il client riceve input dal nostro browser e fornisce output sul nostro browser. Questo sarebbe molto utile per fare le prove che vi avevo suggerito alla fine dell'ultima lezione, aggirando quindi le limitazioni che gli Internet provider implementano sul traffico DNS uscente, normalmente autorizzato se originato dal solo name server dell'organizzazione. Solo che non mi sembra molto affidabile (dopo un pò ha smesso di rispondermi).

http://www.digwebinterface.com/ è simile da molti punti di vista ma anche molto diverso. Può collegarsi solo ad un insieme di name server predefiniti. Ha una funzionalità che chiama "trace" ed è molto interessante, ma non banale da descrivere. Se ho capito bene, selezionare "trace" significa "esegui risoluzione iterativa e mostrami tutte le risposte che hai ricevuto, indicandomi l'indirizzo IP da cui le hai ricevute".

Da notare che non mostra le request (mostra solo la prima) e non mostra il nome del name server che ha contattato ad ogni step (mostra solo il suo indirizzo IP; si può determinare il name server corrispondente facendo su qualche altro sito un whois: se la risposta al passo K è stata ricevuta dall'indirizzo IP-K, si fa il whois di IP-K e si scopre un nome che, nella risposta al passo K-1 era il nome di un name server; sembra intricato ma non lo è). Inoltre, la funzionalità trace usa delle cache senza dirlo: pertanto si vedono risposte che contengono una sfilza di record NS senza nessun record A, ma la procedura prosegue comunque; il motivo è che il record A "mancante" si trova nella cache del web server, oppure viene reperito con delle request (e response) che non sono mostrate.

Suggerisco di fare queste prove:

1) risolvere google.com A?

2) ripetere inviando la request ad un name server "lontano" dal precedente; quasi certamente si vedranno risposte diverse (aspetto che non vi ho detto a lezione: le grosse organizzazioni distribuiscono il carico tra i propri server in molti modi; uno è quello di tradurre uno stesso nome in modo diverso a seconda dell'indirizzo IP da cui proviene la request; per cui chi interroga il DNS dall'Europa di norma riceve risposte diverse da chi esegue la stessa query dalla Nuova Zelanda).

3) ripetere 1 selezionando "trace" e cercando di capire cosa è successo...

DNS: units.it

Mi sono state fatte domande su units.it, che effettivamente è una "brutta bestia" nel senso che può confondere molto le idee.

Su http://www.digwebinterface.com/ si vede infatti che:

units.it ANY ? (cioè "dammi qualsiasi RR trovi con questo nome") torna

units.it. 299 IN A 140.105.48.2 (quindi quel nome è un nome di host)

però:

units.it NS ? torna 3 record NS che non c'entrano con l'altro:

units.it.  21599 IN NS ns1.units.it.
units.it.  21599 IN NS ns2.units.it. 

units.it.21599 IN NS afs.ts.infn.it.

questa è una "dimostrazione empirica" che possono esistere più RR di tipo diverso per lo stesso nome. Inoltre, che un nome può essere nome di zona ma anche nome di host.

Non solo. La domanda: units.it MX ? torna

units.it.  20762 IN MX 10 mx.univ.trieste.it.

quindi un nome può essere nome di zona, di host o di dominio email. Non è colpa mia (e forse il mio blog post adesso è ancora più comprensibile)

Ad aggiungere ulteriore confusione c'è il fatto che scrivendo nella barra del browser "units.it" ci si collega in realtà a "www.units.it". In generale, cioè per altri siti, questo può accadere per molti motivi:

1) il DNS contiene un A per entrambi i nomi ed un web server ad entrambi gli indirizzi IP; il browser si collega al server senza www e questo risponde con una "redirection HTTP" verso il server con www (vedremo le redirection HTTP più avanti).

2) il browser inserisce automaticamente "www" nel nome (quindi invia al DNS una richiesta www.units.it)

3) il DNS contiene un CNAME tra il nome senza www ed il nome con www

nel caso di units.it CREDO che si verifichi il caso 1 (infatti c'è un record di tipo A anche per il nome www.units.it, associato ad un indirizzo IP diverso da quello visto sopra associato a units.it) ma che alcuni browser, ad esempio Opera, si comportino come nel caso 3.

Un bel caos. Per rispondere con certezza nel caso di units.it occorrerebbe un network sniffer, in questi giorni non ho tempo....