Visualizzazione post con etichetta Errori. Mostra tutti i post
Visualizzazione post con etichetta Errori. Mostra tutti i post

venerdì 18 novembre 2016

Provetta: Errori


  1. Prima richiesta GET per il primo documento: contiene Content-Type e Content-Length (quindi un messaggio HTTP che non trasporta nessun documento ha uno header che descrive tipo e lunghezza...di che cosa?). Errore fatto da uno che ha sbagliato nettamente l'esercizio zero.
  2. Get di un documento a spritz.it, risposta contiene un cookie. Get di una immagine a conta.org e gli invia il cookie ricevuto da spritz.it (quante volte abbiamo detto che gli identificatori di sessione per un sito X non sono MAI inviati a siti diversi da X? quante volte abbiamo detto che questo non è un dettaglio irrilevante perché, ad esempio, se il browser inviasse al sito Y l'identificatore della sessione che ha sul sito X allora Y potrebbe inviare a X richieste che sarebbero elaborate come se provenissero dal browser?). Errore fatto da uno che ha sbagliato nettamente l'esercizio zero.
  3. DNS request "www.spritz.it A ?" DNS response "www.spritz.it NS ns.spritz.it". Traduzione della DNS response: "caro Browser, esiste una zona di nome www.spritz.it il cui name server ha nome ns.spritz.it". Possibile non essere in grado di distinguere tra web server (cane) e zona (gatto)? Entrambe sono entità che hanno un nome ma sono di tipo radicalmente diverso.
  4. Valore contatori: "per la pagina X, 1". Se il testo dice che per ogni pagina ci sono DUE contatori, perché si torna UN valore per ogni pagina?. Questo ed il precedente sono stati fatti da uno che ha sbagliato nettamente l'esercizio zero.
  5. "il numero di porta del welcoming socket è scelto dal sistema operativo". Ma quando mai? E come farebbe il client a conoscere quel numero di porta? Quando un client si collega la sua richiesta va verso il welcoming socket: se il  numero di porta fosse scelto dal s.o. allora il client non potrebbe conoscerlo, ergo nessun client potrebbe collegarsi,
  6. "dipende se il browser sta effettuando o meno traffico SMTP o POP". "I numeri di porta sul server sono inferiori a 1024 (25 o 110)".  Non so come potere commentare. Affermazioni di questo genere dimostrano l'assenza di ogni minima idea su che cosa accada fisicamente.
  7. "su pc1 c'è 1 socket con numero di porta 53". Idem
  8. DNS request "www.spritz.it A ?" DNS response "ns.it A IP-x". Traduzione: "Il browser chiede al name server che ore sono e il name server gli risponde che piove". Cioè il browser fa una domanda (traducimi il nome pippo) e riceve una risposta che non ha nulla a che vedere con la domanda (ecco la traduzione per il nome luigi). Da un altro punto di vista, come caspita fa il browser a capire che ns.it è il nome di un name server? La stringa "ns" non ha alcun significato per il protocollo DNS. Un name server potrebbe chiamarsi anche "xy" oppure "luigi". La risposta avrebbe dovuto essere "ns.it NS somename.it, somename.it A IP-x".
  9. "sul nodo in cui esecuzione gmail esiste un solo socket il cui numero di porta viene scelto dal s.o. ed è superiore a 1024". Stessi commenti di 6.
  10. "Ogni PC ha un socket con numero di porta superiore a 1024". Se il browser è collegato a due server, come fa ad essere collegato con un solo socket?
  11. "Sul nodo in cui è in esecuzione GMail ci sono...un welcoming socket (il cui numero di porta sarà inferiore a 1024 e diverso da 25, 80 o 110)". Stessi commenti di 6 e di 5.
  12. "Su ogni PC esistono 3 socket con numero di porta 25, 80 e 110". Stessi commenti di 6.
  13. "Il name server di IP-NB chiede al name server della zona .it che gli indica di contattare spritz.it che può risolvere la richiesta: www.spritz.it A IP-s". Consegnare uno svolgimento del genere significa perdere tempo e fare perdere tempo. Il testo diceva chiaramente che consegnare senza avere svolto tutto è inutile. Se uno ritiene in buona fede che questo possa essere uno svolgimento allora significa che non ha neanche letto il documento di preparazione alla provetta ("consigli", numero 6) (e neanche i post di questo blog, vedi ad esempio questo: https://reti-units.blogspot.it/2016/04/risposte-narrative.html; post che non scrivo per divertimento, ma per cercare di aiutare chi ha difficoltà).
  14. "Totale accessi a spritz.it:2, totale client che visitano spritz.it: 1; totale accessi a engine.org e numero client: 1". Questo significa non avere neanche letto il testo dell'esame. Siamo al terzo anno di università. Stessi commenti di 13. 
  15. "suppongo che si colleghi sia al mail server di gmail che al web server di corriere tramite un browser e quindi su una connessione TCP con protocollo HTTP": a parte il fatto che GMail è un sito web, questa ipotesi non ha il minimo senso; come si fa a collegarsi ad un mail server con protocollo HTTP?
  16. "su PC1 esiste un socket che apre una connessione con il proxy che ha numero di porta 8080": a parte l'ambiguità (il "che" si riferisce al proxy o al socket?), la domanda chiedeva il numero di porta locale su PC1, non quello remoto. Quindi la risposta è gravemente incompleta nella interpretazione migliore (manca il numero di porta locale) o gravemente errata nella interpretazione peggiore (il numero di porta locale è 8080 oppure il numero di porta locale non esiste). Da un paragrafo successivo è evidente che l'interpretazione deve essere la peggiore.
  17. "sappiamo che su un calcolatore non ci possono essere più socket che parlano con lo stesso socket che ha stesso numero di porta" Chi l'ha mai detto o scritto?
  18. "Conosce i seguenti RR: it IP-NS, com IP-NS, org IP-NS..." Questi NON sono RR! Ogni RR ha un tipo. Ed il procedimento di risoluzione, ricorsiva o iterativa, richiede DUE RR per ogni zona, uno di tipo NS ed uno di tipo A.
  19. DNS Request "www.spritz.com A ?", DNS Response "mi risponde dicendo di contattare il name server ns.com". Ormai davvero non so più come dirlo. Ho detto decine di volte che le risposte narrative non vanno bene, non perché io sono fissato ma perché è impossibile da una risposta narrativa capire se chi scrive ha capito. Come gli dice di contattare il name server ns.com? In inglese? in italiano? Inviandogli un RR? o inviandogli un codice di errore? L'ho anche scritto: in questo blog e nel documento con gli esercizi. Se una persona che ha già ripetuto questo esame molte volte continua a fornire risposte narrative io davvero non so cosa posso fare.
  20. Posso arrivare a capire la logica che ha portato a fare il ragionamento (sbagliatissimo) "browser collegato con GMail; GMail ha a che fare con la email; ci sono socket che hanno a che fare con SMTP e/o POP". Ma per quanti sforzi faccia non riesco a capire come si possa dire che sul nodo del corriere della sera ci siano 3 socket con numero di porta 110 (peraltro, dopo avere scritto che non ci sono connessioni POP). L'unica ipotesi che posso fare è che sia stato scritto un numero a caso sperando di indovinare la risposta corretta. Questa è una strategia di approccio all'esame che sconsiglio: l'evento sfavorevole ha probabilità molto elevata, perché il numero delle risposte possibili è altissimo; il costo dell'evento sfavorevole può essere enorme (quando la risposta che si sceglie non ha il minimo senso, come in questo caso).
  21. "su PC1 ci sono socket con numero di porta 80". No comment.
  22. Almeno due persone hanno interpretato l'esercizio DNS assumendo che gli RR fossero nella cache del browser. Leggere il testo. Non ci sono ambiguità possibili, gli RR erano nella cache del name server (ovviamente ciò non significa che io non scrivo mai in modo ambiguo; può succedere; ma in questo caso non è successo).
  23. Svolgimento dell'esercizio 8: un romanzo breve che conclude con "dunque il conteggio finale è 2". Quando dico e ripeto che bisogna imparare a leggere risulto antipatico, lo so, ma un motivo c'è. Il testo dell'esercizio era chiarissimo: erano richiesti due contatori per ognuna delle 3 pagine. Immaginiamo un imbianchino; gli viene chiesto di pitturare tre stanze di bianco con strisce gialle e lui ne pittura solo una di blu. Immaginiamo il primo impiego in azienda: vi viene chiesto di fare una cosa e voi ne fate un'altra.
  24. Che caspita è lo header "Encoding: 6 Febbraio" che accompagna i cookie a lunga scadenza?
  25. Ancora sull'esercizio 8: perché fornire conteggi per sito quando i conteggi sono chiesti per pagina? Vedi commento #23.
  26. "PC1 ha un solo socket ed il suo numero di porta viene definito dall'applicativo client". Viene definito dal s.o. 
  27. Molti prelevano documenti in cui la terza parte dell'URL è "/" inviando GET index.html. Ma perché? GET index.html si invia quando la terza parte dell'URL è index.html.
  28. I link (cioè i documenti il cui URL è il valore di HREF di un A) NON sono prelevati automaticamente. Sono prelevati solo clickandi sul link.
  29. La presenza di www in testa ai nomi di server in molti casi è un processo random. Presente o assente in modo non predicibile. Uno stesso nome compare con o senza www in punti diversi del traffico http. Poi non si capisce perché per trovare l'indirizzo IP di www.spritz.it e di www.engine.org le DNS request siano spritz.it A ? e engine.org A ?. Mah.
  30. Su GMail c'è un welcoming socket ed un communication socket per ogni client. I numeri di porta dei communication socket diversi tra loro. Ma quando mai??? Valori numerici dei numeri di porta non indicati. Possibile che non si legga il testo? (in questo caso penso che il testo sia stato letto ma, astutamente, schivato...). "Si suppone che i PC siano autenticati in GMail" e per cosa serve questa ipotesi???
  31. "PC3 ha un solo socket perché connesso a un solo server". PC3 aveva Chrome connesso al corriere della sera e Firefox connesso al corriere della sera, Su PC3, quindi, ci sono due processi connessi allo stesso server. Ogni connessione è privata di un processo, non può essere condivisa tra più processi. Questo punto non lo abbiamo approfondito molto, quindi non considero questo come un errore grave.
  32. "Ogni PC ha due socket su porta 80". Il numero di porta lato client non ha nulla a che vedere con il numero di porta lato server.
  33. Il welcoming socket NON è duplicato per ogni client. Mettere su un server due socket per ogni client, di cui uno è un welcoming e l'altro un communication non ha il minimo senso.
  34. DNS request "www.spritz.it A ?" DNS response "www.spritz.it NS ...". Quindi esiste una zona di nome www.spritz.it?
  35. DNS request "flickr.com A ?" DNS response "flickr.com NS ...". Il testo diceva che il name server conosceva i RR sufficienti per contattare il name server della zona com. Qui invece si assume che conosca i RR per contattare il name server della zona flickr.com.
  36. Esercizio Zero: Non riesco minimamente a capire la logica che porti a mettere un mail server collegato con il server web del Corriere della Sera. Neanche la logica di una risposta "zero connessioni SMTP...su GMail ci sono 5 socket (1 welcoming e 4 communication) tutti con porta numero 25". Neanche la logica di fornire due svolgimenti per l'esercizio Zero, uno per il "caso in cui gli utenti stanno inviando una mail" ed un altro per il "caso in cui vengano prelevate le mail".
  37. Esercizio Zero: "avremo 3 connessioni SMTP". Tralasciando il fatto che questa affermazione sia sbagliatissima, non riesco minimamente a capire la logica che porti a dire che "avremo 1 connessione POP perché tutti gli utenti sono collegati". Poi che su GMail ci sono 4 socket con numeri di porta "da 110 in su, perché sono dei client". Poi che sui PC il numero di porta è 53. Consegnare uno svolgimento di questo genere significa perdere tempo e fare perdere tempo.
  38. Esercizio Zero: cosa caspita c'entrano i web server dell'organizzazione? In numero variabile grosso modo uguale al numero dei client? con collegamenti che sono tra web server dell'organizzazione e GMail/Corriere in un esercizio e tra PC e GMail/Corriere nell'esercizio successivo?
  39. Esercizio Zero: come si fa ad essere collegati con due server usando un solo socket? (siamo senza proxy; anche con proxy sono due, ma dire che con proxy è uno solo può essere considerato corretto).
  40. Qual'è il senso di "GET /www.spritz.it" e di "GET /www.engine.org"?
  41. Il "Content-Type: iframe" dovevo ancora vederlo. Così come "Accept: iframe/formato iframe".
  42. Il numero di persone che hanno sbagliato l'esercizio zero per me è veramente una causa di depressione. Ma quando vi siete collegati a GMail da PC avete mai dovuto installare un mail client???
  43. Qual'è il senso di mettere un punto interrogativo in testa ad ogni URL richiesto (Get ?/, Get ?i.htm,...)?
  44. Se sono chiesti gli accessi ai documenti www.spritz.it/ e www.spritz.it/i1.html, che senso ha fornire conteggi "spritz.it 3" e "spritz.it/i1.htm 1". Non ha alcun senso. Se uno conta (erroneamente) gli accessi al sito invece che alla pagina allora deve fornire www.spritz.it. Inoltre, il contatore deve contare gli accessi al documento: non al documento e alle immagini o script che contiene quel documento.

mercoledì 1 giugno 2016

Lista di errori (provetta 2)


Lista di errori. Anche senza il testo dell'esame, la lettura è istruttiva.
  1. Se una network può contenere 32 nodi allora occorre un range da 64 indirizzi (gli host number composti da tutti 0 e da tutti 1 non si possono usare). Quindi il network number deve essere lungo 32-6=26 bit. Se fosse lungo 27 bit allora avrei 32 host number quindi potrei collegare al massimo 30 nodi.
  2. causalmente != casualmente
  3. Un messaggio applicativo m in una connessione SSL è crittato a chiave privata E accompagnato dal MAC calcolato con la stessa chiave; nessuno dei due implica automaticamente la presenza dell'altro.
  4. Regole di firewall IP-src=IP-proxy AND port-dst=8080 (e regola duale) non hanno alcun senso; queste regole considerano il caso in cui il proxy si comporta da client; quando il proxy si comporta da client, la porta di destinazione deve essere 80, perché si sta collegando verso i web server del mondo esterno;
  5. Regole di firewall IP-dst=IP-proxy AND port-dst=8080 (e regola duale) non hanno alcun senso; queste regole considerano il caso in cui il proxy si comporta da server; l'esercizio non richiedeva di permettere il traffico tra client esterni e proxy interno;
  6. Azioni del server durante la creazione del collegamento SSL: "verifica il certificato inviato dal client (emesso da CAX); inserisce nel suo keyset e trustset il certificato autofirmato di CAX". Dove caspita prende il certificato autofirmato di CAX? Inoltre, se prima verifica il certificato e poi inserisce nel keyset e trustet le info dello Issuer, come fa a verificare il certificato? L'ordine di esecuzione delle operazioni è importante. Non è che uno prima accende l'auto e poi inserisce la chiave. O prima butta la pasta e poi accende il gas.
  7. Regole di firewall IP-src=IP-mail AND port-dst=110 (e regola duale) non hanno alcun senso; queste regole considerano il caso in cui il mail server si comporta da client usando il protocollo POP; quando mai un mail server si comporta da client usando il protocollo POP???
  8. Frame inviato da C2 con payload "DHCP discover" e subito sopra un disegnino che inserisce subito all'inizio del payload la coppia "IP-DHCP,IP-C2". Una cosa di questo genere implica (implicherebbe) bocciatura immediata ed automatica. Se invia un dhcp discover è perché non ha ancora indirizzo IP.
  9. Frame inviato da C2 con payload "gratuitous ARP" (senza descrivere la quadrupla ARP) e subito sopra un disegnino che inserisce subito all'inizio del payload la coppia "tutti, IP-C2". Una cosa di questo genere implica (implicherebbe) bocciatura immediata ed automatica. "tutti" significa inequivocabilmente che si vuole specificare un indirizzamento; e in un messaggio ARP specifico un indirizzamento a livello IP?
  10. Frame con payload "ICMP echo request, TTL=2"; dove viene specificato il TTL? nel payload ICMP? o dove?
  11. "bella copia" == "svolgimento comprensibile"; "brutta copia" == "tutto ciò che è stato fatto per generare la bella copia". Queste definizioni sembrano ovvie, ma in alcuni casi vedo che "bella copia" == "numero finale senza svolgimento"; se il numero è errato, come si fa a capire se l'errore è solo una svista oppure è il risultato di una cappellata gigantesca? se il numero è corretto come si fa ad escludere che sia stato ricevuto da qualche vicino?
  12. Come valutare una subnet mask lunga 3 byte? Come valutare una colonna "indirizzo IP" con valori quali "131.116.129.226/29"?
  13. Regole di firewall IP-dst=IP-proxy AND port-dst=80 (e regola duale) non hanno alcun senso; queste regole considerano il caso in cui il proxy si comporta da server (sulla porta 80 invece che sulla porta 8080, ma lasciamo perdere); l'esercizio non richiedeva di permettere il traffico tra client esterni e proxy interno;
  14. Inviare e Ricevere email significa SMTP che opera da client e SMTP che opera da server. POP non c'entra nulla. Anche se uno usasse POP per "ricevere" (invece che per "prelevare"), mettere regole per POP che opera da server e SMTP che opera da server non avrebbe alcun senso (ricevere e ricevere?)
  15. Molti non hanno fornito le info di configurazione dei server DHCP. Perché? Il testo diceva "ogni server". Posso capire, entro certi limiti, che non si forniscano le info per il proxy, ma non capisco perché non si forniscano quelle per i server DHCP.
  16. Come valutare un frame con tipo ICMP?
  17. Svolgimento del ping: "(frame con tipo ICMP)" e poi "saranno una serie di richieste che mi permetteranno di capire se esiste RB. L'ultima infatti sarà una echo reply di RB che attesterà la sua esistenza". Non elenco gli errori perché ci vorrebbe troppo tempo. Sottolineo solo che nel testo era scritto chiaramente che occorreva elencare ogni frame; e che per ogni frame occorreva descrivere header, protocollo e payload; e che consegnare senza svolgere un esercizio implica insufficiente. Che senso ha consegnare uno svolgimento di questo genere? Tirare a indovinare? Oppure uno non si rende neanche conto di cosa era richiesto nel testo?
  18. "pacchetto contenente al suo interno "ping IP-RB-DOWN": che significa "al suo interno"? dove, nello header o nel payload? è sbagliato, perché è sia nello header (indicazione che il protocollo è ICMP) sia nel payload (messaggio ICMP); oltretutto il testo chiedeva chiaramente di indicare i protocolli trasportati da ogni frame e pacchetto (cosa peraltro ovvia).
  19. "payload frame: "IPC3: delivered"": che significa? protocollo? mittente? etc etc etc
  20. Due switch collegati tra loro: come si possono attribuire a network diverse, separate dal collegamento tra gli switch ???
  21. Le tabelle di routing hanno colonne range-action; le action sono direct nome-interfaccia oppure instrada indirizzo-IP; come fa una action a contenere "direct 192.168.0.66/27"?
  22. come fa l'esecuzione di ping a terminare con "RB non sa chi indirizzare i pacchetti quindi manda un messaggio di notifica a C2"??? inoltre, a quali pacchetti ci si riferisce? inoltre, come fa a mandare un messaggio? casomai manda un pacchetto. inoltre, cosa contiene questa fantomatica notifica? in quale protocollo?
  23. 192.168.0.0/27 e 192.168.0.0/26 sono range evidentemente sovrapposti
  24. Le regole di firewall da inserire erano due per ogni tipologia di traffico: mail server che opera da server SMTP; mail server che opera da client SMTP; proxy che opera da client; name server che opera da server (per permettere al resto del mondo di trovare il mail server); name server che opera da client (per permettergli di trovare i mail server del resto del mondo)
  25. Il keyset del client non occorre che contenga la kpub del server; deve contenere la kpub della CA che ha emesso il certificato del server; non è un dettaglio, è una differenza enorme; se il keyset del client contenesse già la kpub del server allora non servirebbero neanche i certificati.
  26. "Le porzioni di messaggio crittate sono solo quelle nel messaggio che sono crittate con la chiave...". Tautologia interessante: "le parti crittate sono solo quelle crittate"; non è sorprendente...ma quali sono???; 
  27. Con riferimento al punto 1: qualcuno ha scritto esplicitamente che anche se gli switch hanno 16 porte, gli indirizzi IP da prevedere non sono 16 perché alcune porte sono già usate per collegarsi ad altri switch. Giustissimo, non me ne ero reso conto. E' possibile che quelli che hanno previsto un range da 32 per due switch abbiano fatto questo ragionamento pur non avendolo scritto. Vedrò come valutare (tanto questo esercizio è di quelli che contano poco o nulla se fatti bene e contano meno infinito in caso di errori gravi).
  28. Esecuzione di traceroute da RB verso IP-C3: "RB riceve IPC3", che caspita vuol dire??? perché, quando, come???; "capisce dalla propria tabella di routing che la route passa per RC", si, e poi dopo RC quanti router ci sono??? inoltre, se viene chiesto di svolgere X, non si deve svolgere (male) Y.
  29. SWA collegato ad AP1: una network contenente solo SWA ed un'altra contenente solo AP1; SWB collegato ad AP2 ed AP3: 3 network, una per dispositivo. Come valutare??? Quante volte abbiamo ripetuto a lezione che se due nodi possono comunicare via frame allora sono nella stessa network?
  30. Se un nodo ha la propria kpub certificata da CAX, allora il keyset ed il trustset di quel nodo devono contenere CAX. Posso capire, entro certi limiti, che non lo si metta in keyset; non posso capire che non lo si metta in trustset: dovrò fidarmi di chi mi certifica.
  31. Davvero non riesco a capire come si sia potuto svolgere l'esercizio 3 senza iniziare con l'interazione DHCP. Il testo diceva chiaramente "alloca indirizzi dinamicamente in ogni nodo" e l'esercizio 3 diceva "dall'accensione". Come si può sperare di svolgere correttamente un esame se non si legge il testo?
  32. "Elencare i messaggi che si scambiano nella connessione TCP". Che caspita significa "open connection"? Primo, non sappiamo come si aprono le connessioni TCP (occorrono 3 pacchetti, per la cronaca); secondo, se sono richiesti i messaggi nella connessione perché elencare qualcosa che ha a che fare con l'apertura?
  33. SSL: "genera mezza chiave, la critta con KPUB del partner e la spedisce con il suo certificato+ il MAC"; "il suo" di chi? il proprio o quello del partner?; a parte questo, "il MAC"???? il MAC di cosa? calcolato con quale chiave? a parte il fatto che il MAC non si usa in questa parte di SSL, questo è un altro esempio del perché le descrizioni narrative sono pericolose. Difficilissimo essere esaurienti e non ambigui (dire tutto e in modo da non lasciare spazio a più interpretazioni).
  34. Possibile che per identificare il penultimo range in una sequenza di 32 range si scrivano TUTTI i range???? Basta scrivere l'ultimo e sostituire 11110 a 11111. Se invece di 32 range fossero stati 128 o 2048? Li avrebbe elencati tutti?
  35. Se il testo chiede di elencare "le porzioni di pacchetto crittate" e uno scrive "frame non sono criptati; pacchetti sono criptati" come si deve interpretare? l'unica interpretazione possibile è che l'intero pacchetto sia criptato; poi magari uno in testa ha che è criptato solo il payload (tralasciando che è crittata solo parte del payload in alcuni pacchetti), ma se uno scrive una cosa diversa da quella che pensa c'è poco da fare.
  36. "Messaggio è criptato con MAC e K". Che significa criptare "con MAC"? Inoltre, come si fa a criptare con due entità?
  37. Con riferimento ai punti 30, 15, 27: non li ho segnalati esplicitamente in tutti i compiti; il "peso" sarà comunque minimo o nullo (subordinato al resto dello svolgimento);
  38. Alcuni hanno svolto traceroute come se fosse un ping (il che implica non avere letto il testo o essersi inventati un esercizio Y in quanto incapaci di svolgere l'esercizio richiesto X); altri come se fosse un ping ma in cui il TTL è il minimo necessario per arrivare a destinazione: che senso ha? primo, non si ottiene l'obbiettivo di traceroute (scoprire i router che sono lungo il path verso la destinazione); secondo, come fa il mittente a conoscere quel TTL minimo?
  39. Con riferimento al punto 3: molti hanno scritto solo la prima parte, senza esplicitare la presenza del MAC
  40. "Elencare i frame trasmessi e ricevuti da C2": cosa c'entrano i frame nella network successiva, tra il primo router e la destinazione? "Elencare i messaggi che C3 ed M si scambiano nella connessione TCP": cosa c'entra il traffico DNS??? perché perdere tempo mettendo cose che non c'entrano nulla con quello che è stato chiesto? leggere il testo non è un optional.
  41. Perché mettere informazioni di configurazione come "indirizzo IP 131.116.158.80/25, subnet mask 255.255.255.128, indirizzo IP gateway 131.116.158.1/25"? Se si deve indicare un indirizzo IP, non si può rispondere con una coppia indirizzo IP, range della network; provate a mettere in un qualsiasi calcolatore quella roba nello spazio in cui si deve mettere un indirizzo IP. Ancora peggio, se poi si aggiunge "indirizzo IP DNS " con lo stessa notazione: il server DNS può trovarsi in una network diversa: come si fa a conoscere il range di una network diversa dalla propria? Non si può.
  42. Con riferimento al punto precedente: mettere la coppia indirizzo IP-range anche nei messaggi DHCP e nei messaggi ARP non ha il minimo senso.

venerdì 27 maggio 2016

Leggere il testo di un esame

Leggere il testo di un esame è importantissimo, non solo perché io sono pignolo; non solo perché in questo modo uno evita di perdere tempo fornendo informazioni non richieste (quindi inutili nel migliore dei casi e dannose nel peggiore); non solo perché leggere ciò che è scritto in un documento e distinguerlo da ciò che uno crede ci sia scritto è fondamentale in ogni settore (dalle istruzioni per la dichiarazione dei redditi alle norme regionali, alle leggi a qualsiasi cosa).

E' importantissimo anche e soprattutto perché è una delle capacità necessarie ad una persona che deve lavorare in un gruppo.

L'ho visto decine e decine di volte con i miei collaboratori ed i miei tesisti. Passiamo del tempo a discutere, decidiamo di fare una cosa, la persona investe giorni del proprio tempo per fare quella cosa ed alla fine si scopre che ne ha fatta un'altra. Quasi sempre una cosa inutile, perché nella tecnologia i dettagli sono importanti. In moltissimi contesti basta modificare un minimo dettaglio per ottenere un risultato inutile, fuorviante o sbagliato.

L'effetto è che tutti hanno sprecato tempo, risorse ed energie.

Inoltre, spesso il problema non lo si scopre subito. Lo si scopre solo se emerge qualche risultato od azione strana e si ha il tempo e la possibilità di approfondire. Pertanto quando emerge un problema si mettono in dubbio anche tutte le altre cose fatte in precedenza da quella persona: avrà fatto veramente ciò che avrebbe dovuto fare? oppure ha cambiato qualcosa?

Un effetto aggiuntivo, ancora più importante, è che la persona non ha fornito ai propri collaboratori una prova positiva delle proprie capacità.


lunedì 16 maggio 2016

Crittare - Codificare

Sono due verbi dal significato completamente diverso.

Non si devono usare come se fossero sinonimi.

In entrambi i casi si traduce una informazione da un formato ad un altro formato.

La differenza fondamentale è che se si "codifica" allora la trasformazione inversa può essere effettuata da chiunque, mentre se si "critta" (o "cripta") allora la trasformazione inversa può essere effettuata solo da chi conosce il parametro (chiave) necessario ad eseguire tale trasformazione.

ma se la decodifica puo' essere fatta da chiunque (al contrario della decrittazione), a cosa serve codificare?.Per guadagnare in termini di tempo, spazio in memoria?

Quello è uno dei motivi.

Il motivo di gran lunga più comune è quando l'informazione è rappresentata in un formato che non è adatto per il dispositivo che la deve elaborare.

Ad esempio, una immagine non è adatta per un calcolatore. Un calcolatore può elaborare solo sequenze di byte. Quindi l'immagine deve essere codificata in un formato che consiste di sequenze di byte. 

Idem per i caratteri. Esiste la codifica ASCII che permette di tradurre tra i disegnini che a noi fanno pensare ai caratteri ed i byte.

Idem per i video, le canzoni, etc. Sono concetti che uno dovrebbe conoscere da "fondamenti di informatica".

giovedì 28 aprile 2016

Socket: processi server su uno stesso nodo

Si considerino 4 nodi diversi NSA, NSB, NX, NY.

Il processo server SA in esecuzione su NSA esegue il codice seguente:
int t; t=socket(…); bind(t,25,…); listen(t,…); ... interazione con processi client...

Il processo server SB in esecuzione su NSB esegue il codice seguente:
int t; t=socket(…); bind(t,110,…); listen(t,…); ... interazione con processi client...
Su NX sono in esecuzione processi client X1,X2,X3 e su NY sono in esecuzione processi client Y1,Y2,Y3.

All’istante t0 SA ha due connessioni aperte, una con X1 ed una con X2; SB ne ha aperte quattro: con X3, Y1, Y2, Y3.
1.       ....
2.       Si assuma adesso che SA ed SB siano in esecuzione sullo stesso nodo NSA invece che su due nodi diversi. Se lo scenario descritto è ancora possibile, allora elencare i numeri di porta delle due estremità di ogni connessione. Altrimenti spiegare perché lo scenario descritto non è realizzabile.

  • "Non realizzabile perché da come è scritto il codice i due processi server dovrebbero condividere lo stesso welcoming socket t su porte diverse, il che non è possibile". Questo non ha il minimo senso. "t" è il nome di una variabile. Non è il nome di un socket (nozione che peraltro non abbiamo mai definito: quando mai abbiamo parlato di nome di un socket?). Come certamente dovete sapere dai corsi precedenti, processi nello stesso nodo possono usare variabili con lo stesso nome, poiché le variabili di un processo sono visibili solo a quel processo (a meno di casi particolari che non avete visto in nessun corso). Staremmo freschi se quando si lancia un programma P dovessimo sempre incrociare le dita sperando che P non sia stato scritto usando nomi di variabile usati anche in altri programmi che in quel momento sono già in esecuzione.
  • "Non realizzabile perché due server non possono essere in esecuzione sullo stesso nodo". Per quale motivo? Chi l'ha mai detto? Non ha il minimo senso.
  • Non è uno scenario possibile in quanto ci può essere una o più richieste tra un dato client e un dato server". Testuale. A parte la sintassi traballante, qual'è la logica in questa affermazione?
  • "Lo scenario descritto non è più possibile: non ci possono essere due processi server con numeri di porta diversi su un unico nodo". E perché?
  • "Non realizzabile perché avrei due processi server su uno stesso nodo e i processi client possono invece connettersi con un unico server istante per istante" Qual'è la logica? In entrambi gli scenari ogni processo client è collegato con un solo processo server. Se avesse confuso "processo" con "nodo", allora il secondo scenario sarebbe stato con un solo (nodo) server invece che con due (nodi) server, per cui in base a quella spiegazione sarebbe stato realizzabile solo il secondo. A parte la logica che mi sfugge, il ragionamento è comunque sbagliato. Quando mai abbiamo detto che un client si può collegare con un unico server istante per istante? Abbiamo detto, nelle primissime slide del corso per fare una introduzione, che quello è il caso comune. Comune non significa l'unico che può esistere. Inoltre, quando un browser visualizza una pagina si collega a solo un server per volta? Abbiamo anche detto infinite volte che un browser esegue tante azioni parallele. E un browser può avere tanti tab aperti, per cui può avere tante connessioni aperte.
  • "Non realizzabile perché su un nodo tutti gli N+1 socket del server devono essere associati allo stesso numero di porta" Tralasciamo cosa sia N. Risposte di questo genere mi sorprendono completamente. Posso capire che uno non abbia capito un concetto, anche se si tratta di un concetto base. Ma faccio fatica a capire l'apparente assenza di logica (il che mi pare molto più grave). Se invece di un nodo si hanno più nodi allora gli N+1 socket del server non devono essere associati allo stesso numero di porta?
  •  "SA avrà impegnate due porte diverse tra di loro con port number maggior di 1024". Il testo dice che SA è un processo server. Quella affermazione, quindi, non ha il minimo senso. "mentre X1 e X2 avranno la connessione su un PN maggiore di 1024 ma non necessariamente diverso". Diverso rispetto a chi? X1 diverso da X2? o cosa? "Discorso simile per SB, avrà la connessione su 4 porte diverse tra loro (con PN>1024) mentre X3,Y1,Y2,Y3, avranno una connessione su una PN >1024". Evidentemente su questa parte di programma c'è il buio completo.
  • "Non è possibile in quanto su un nodo devo avere in esecuzione un (sottolineato un) processo server". Quando mai abbiamo fatto questa affermazione? Non è una domanda polemica, davvero non capisco da dove possa sorgere questo dubbio. Anche se fosse così, comunque, la frase sarebbe imprecisa: "devo" andrebbe sostituito da "posso" o qualcosa del genere. C'è poi un'apparente assenza di logica che non riesco a comprendere e che mi preoccupa (vedi anche il punto 24); la frase infatti termina con "è infatti il processo server a determinare il numero di porta del server". Come fa una delle due affermazioni a motivare l'altra?

Risposte narrative



Questo è un esempio da manuale del perché dico che non si devono dare risposte narrative ma si devono dare descrizioni schematiche esaurienti.

Che significa "nel server di webhosting ci sarà un record di tipo CNAME"?

Il record si trova in un name server, non nel server di web hosting. Inoltre, quali sono name e value di quel record? La frase indica solo il tipo. Inoltre, di record CNAME ce ne sarà uno, come indicato nella narrazione, o ce ne saranno due (come deve essere)? Inoltre, il fatto che il record CNAME "sarà" nel server, non c'entra nulla con le request e le response DNS richieste dall'esercizio: un RR può essere in un name server e non essere mai tornato in nessuna risposta. Inoltre, quel RR viene tornato come response a quale request? A una request CNAME? o a una request NS? o a una request A? E qual'è il nome in quella request? E quando è tornato un record CNAME, cosa se ne fa il browser di quel record, cioè quali request invia successivamente (se ne invia)?

Notate, qui non si tratta (solo) di mia pignoleria, si tratta di leggere il compito. Il compito contiene una descrizione ambigua di una minima parte delle informazioni necessarie. Che ipotesi deve fare chi legge sulle informazioni non scritte nel compito? Sono presenti nella testa di chi ha scritto o no? Purtroppo non si possono assegnare voti per via telepatica.

Altro esempio. "Karl, da PC, invia un GET per http://bayern.de/index.html la request non appartiene a nessuna sessione lui è configurato per generarla ed utilizza la tecnica dei cookie. Il server manda la risposta con un 200 ok, se tutto è andato bene, e dopo la linea vuota sopra il documento richiesto. Il browser di Karl riceve la risposta e se la memorizza nella sua cache. Nella home page c'è un documento htm che il server non vuole che sia memorizzato e si realizza con un response header del tipo cache-control no store e due jpg che il server vuole che si memorizzino".

Solo in queste due frasi il lettore si pone un numero altissimo di domande:
  • "lui è configurato...". chi è "lui"?
  • "utilizza la tecnica dei cookie". cioè? come funziona questa tecnica? chi la realizza e come?
  • "manda la risposta con un 200 ok". che significa "con un 200 ok"? 200 ok è la parte iniziale della risposta, non è un non meglio definito qualcosa che viaggia "con" la risposta.
  • "dopo la linea vuota sopra il documento richiesto". "dopo" che cosa? dopo il 200 ok? e non ci sono header? e che significa "sopra"? casomai sarà prima, non sopra.
  • "non vuole che sia memorizzato e si realizza con un response header..." response header inserito dove? in quale response?
  • "e due jpg che vuole che si memorizzino" dove sono quei jpg? come descrive la sua volontà di memorizzarli e dove? nel documento html? come fa il browser a capire se sta ricevendo un documento html o un documento jpg?
  • "nella home page c'è un documento html"; la home page E' un documento html.

Lista di errori (provetta 1)


Lista di errori. Anche senza il testo dell'esame, la lettura è istruttiva.

  • L'URL relativo sports/newIndex.html contenuto in www.org.com/sports/index.html equivale a www.org.com/sports/sports/newIndex.html; non equivale a www.org.com/sports/newIndex.html.
  • Qualcuno ha inserito nel conteggio delle connessioni TCP anche quelle che il browser apre con il server DNS. Ho considerato queste risposte corrette, anche se non avrei dovuto. Le interazioni DNS avvengono praticamente sempre su UDP, le interazioni TCP sono usate solo per (alcune) interazioni primario-secondario. Inoltre, noi non abbiamo visto come DNS usa TCP: non abbiamo cioè detto che DNS usi una connessione TCP per ogni coppia request-response.
  • Request "www.org.com A ?", Response "www.org.com NS ns.org.com"+"ns.org.com A IP1". Bene, adesso con chi si collega il browser? Con IP1? Uno svolgimento di questo genere, specialmente con la premessa "suppongo che il server supporti risposta ricorsiva" (cioè, il server trova il RR che mi occorre), significa non avere capito nulla del DNS.
  • Testo: "Per ogni pagina menzionata nell'esercizio, fornire il conteggio al termine dell'interazione". Svolgimento "Riceve 5 HTTP request, una per ogni documento html visualizzato". Ma quanti caspita sono questi documenti? 1? 2? o 5? E' evidente che la risposta non contiene questa informazione, richiesta nel testo. Inoltre, se ad esempio i documenti fossero 3, il conteggio è 3+1+1 oppure 1+3+1 oppure 1+1+3? Quando dico che è fondamentale leggere il testo probabilmente risulto pedante e antipatico, ma se lo dico un motivo c'è.
  • Testo "Descrivere tutta la sequenza di richieste e risposte DNS inviate e ricevute dal browser". Svolgimento: 


Ora, tralasciamo pure il fatto che se si chiede una sequenza allora si vuole vedere l'ordine dei messaggi e in questo disegno questa informazione è completamente assente; tralasciamo anche che abbiamo detto e ripetuto una infinità di volte che in questi esercizi occorre fornire i RR e in questo disegno questa informazione è completamente assente. Facciamo l'interpretazione più plausibile: browser invia una request di tipo A a www.org.com per trovare l'indirizzo di quest'ultimo (?????): ma se dovete chiedere il numero telefonico a un amico telefonate a quell'amico????
  • "Suppongo main.gif sia un URL relativo al server www.org.com". Esempio di confusione tra mele e scarpe: Un URL relativo a un server? Un URL relativo è relativo ad un altro URL. 
  • Non so quante volte l'ho ripetuto: se devo trovare l'indirizzo associato al nome sgddhshfk allora faccio una domanda " sgddhshfk  A ?". NON faccio la domanda "sgddhshfk NS ?". Non ha alcun senso. Peggio ancora, qui termino con l'indirizzo del name server della zona a cui appartiene sgddhshfk, NON termino con l'indirizzo di sgddhshfk. Con chi si collega adesso il browser?
  • Lo header Referrer deve essere presente anche nelle richieste inviate a causa della pressione di un link. Non solo in quelle inviate per prelevare immagini o iframe.
  • "Non realizzabile perché due server non possono essere in esecuzione sullo stesso nodo". Per quale motivo? Chi l'ha mai detto? Non ha il minimo senso. Devo ancora decidere come valutare questo caso. Correggerò il resto del compito e poi deciderò.
  • Se il sito adclick.com è sul sito di web hosting catchit.net, perché mai il browser deve di sua spontanea iniziativa inviare la DNS request "catchit A ?" ? Come fa il browser a sapere che adesso c'è di mezzo catchit.net? Inoltre, perché mai il valore dello header Host adesso dovrebbe essere catchit.net? Se così fosse allora tutti gli URL cambierebbero (il sito non potrebbe cioè chiamarsi adclick.com).
  • Web hosting, custom domain: se un sito di nome N1 viene ospitato dal servizio di web hosting di nome N2, nel DNS viene inserito il record N1 CNAME N2. Ma gli header Host continuano ad avere N1. Non hanno N2. Se avessero N2 allora gli URL assoluti non avrebbero nulla a che vedere con N1.
  • Request per URL main.gif?ID=3456abc e response contiene l'immagine richiesta. "Qui la sessione scade perché si trasporta un documento senza link da modificare" E perché mai? Una sessione scade se l'applicazione decide di farla scadere oppure se non si ricevono request con l'id di quella sessione per un intervallo di tempo predefinito. Non scade perché non si è avuta l'opportunità di scrivere l'id di quella sessione nel documento. Inoltre, ammettiamo pure che la sessione scada; le richieste successive inviate dal browser seguendo link già presenti sul browser, conterranno comunque l'id della sessione. Non è che il browser modifica gli URL che si trovano nei documenti che sta visualizzando (oltretutto in base a funzionalità telepatiche: come farebbe il browser a sapere che il server ha deciso di fare scadere la sessione?)
  • Set-Cookie nelle request e non nelle response lo dovevo ancora vedere.
  • Response con header, LV e poi "documento che dice al browser che la cache è validated quindi non necessita di reinviarlo". Quando mai abbiamo visto un documento che fornisce informazioni al browser? Sono i response header che forniscono informazioni al browser, e possono farlo perché hanno nomi predefiniti, valori predefiniti, significato predefinito. Come fa un documento ad informare il browser di qualcosa? In quale lingua dovrebbe essere scritto? Che parole dovrebbe usare?
  • Come fa una response ad avere Content-type: "Img" e a trasportare un documento "<iframe SRC="...">"? E perché mai poi non viene prelevato il documento riferito dall'attributo SRC dell'iframe?
  • "La BASIC authentication non permette il mantenimento delle sessioni con URL rewriting". Perché mai? L'unica cosa di cui abbiamo parlato e che gli assomiglia lontanamente è questa: la BASIC authentication si può usare con o senza sessioni (non perché lo dico io, ma perché è così); e che negli esami deve essere usata con le sessioni, a meno che sia impossibile (perché lo dico io). Cosa c'entra questo con la impossibilità di mantenere le sessioni con URL rewriting?
  • Si scrive cache. Non cash. Si pronunciano più o meno nello stesso modo (io non sono in grado di pronunciarli in modo diverso). Ma sono cose molto diverse. Ai fini degli esami faccio finta di nulla, ma scrivere una cosa del genere in un documento tecnico importante può avere effetti spiacevoli (= farsi ridere dietro; le cache sono un concetto usato in moltissimi settori dell'informatica radicalmente diversi tra loro; noi ne abbiamo visti solo due ma sono tanti, date un'occhiata a Wikipedia).
  • Stime per il numero di connessioni TCP che hanno solo il minimo o solo il massimo sono da considerarsi, nel migliore dei casi, solo parzialmente corrette.

  • Come interpretare questo disegno? Mi pare ci sia una sola interpretazione possibile: per trovare il numero di telefono di un amico devo telefonare a quell'amico. (www.org.com era disegnato nello stesso modo).
  • Una quantità incredibile di persone ha scritto la response alla get della home page con solo uno dei due header necessari: Cache-control: must-revalidate; Etag: qualche-id; Capisco che uno non li metta tutti, ma metterne solo uno dei due ha davvero poco senso.

Lista di errori (provetta 2)


  1. Se un nodo ha configurazione IP dinamica, come fa ad inviare il gratuitous ARP prima della DHCP discover? nel gratuitous ARP quale indirizzo dichiara di avere?
  2. Che significa mettere come payload di IP scritte come "traceroute", "traceroute reply" (senza specificare il protocollo del payload; e addirittura scrivendo DOPO queste stringhe "TTL=2": dove si trova il TTL? nel payload o nello header? oppure IP ha un trailer?)
  3. Se il testo dell'esercizio dice che un nodo è stato appena acceso, che senso ha ipotizzare che la sua cache arp contenga già l'indirizzo fisico del router? ci sono 3 opzioni per interpretare:
    • è stato assegnato l'esercizio X ma lo studente ha deciso di inventarsi un esercizio Y diverso da X e di risolvere Y 
    • il nodo ha capacità telepatiche
    • il nodo ha configurazione arp statica (questa opzione potrebbe essere corretta ma se uno non ha scritto che siamo in questo caso allora lo svolgimento non è credibile...le altre due opzioni sono molto più credibili)
  4. Mettere come azione "instrada 140.140.100.7/27" non ha senso. Si instrada verso un indirizzo IP. Non verso un indirizzo IP ed un network number (il network number del destinatario in questo caso è noto, ma ciò è irrilevante).
  5. Il collegamento tra ISP1 e ISP2 è "evidentemente" un collegamento PPP, non Ethernet. Non l'ho considerato come errore "grave".
  6. Che senso ha inviare una ARP request per trovare l'indirizzo fisico di un nodo in un'altra network? E che senso ha inviarla all'indirizzo fisico del router?
  7. Che senso ha fare un traceroute in cui i messaggi ICMP di request sono diretti ai router intermedi? a parte il fatto che sarebbe bello sapere come faccio a conoscerne l'indirizzo IP, ma se ne conosco l'indirizzo allora a che serve traceroute?
  8. "R1 non può eseguire traceroute perché non sa com'è ORG è organizzata al proprio interno" cosa c'entra? per inviare un pacchetto verso una destinazione devo conoscere com'è organizzata la org. a cui appartiene la destinazione?????
  9. Un frame Ethernet non può trasportare il protocollo ICMP. Deve trasportare sempre IP (che a sua volta trasporta IP). Se un frame Ethernet traspostasse ICMP allora ICMP coinvolgere solo nodi nella stessa network.
  10. Una ARP request contiene l'indirizzo IP da trovare (esempio: 140.140.100.62). NON contiene l'indirizzo IP e la subnet mask (esempio: 140.140.100.62/27). A parte il fatto che sarebbe una info inutile, dove sarebbe memorizzata visto che i messaggi ARP contengono delle quadruple (e non delle sestuple)?

Lista di errori (provetta 2)


  1. mettere nelle regole di firewall "IPdst = ISP" merita poco più di -infinito
  2. "decrittare la firma" ovviamente non significa nulla. la firma si verifica. non si decritta.
  3. dire che C1 non invia pacchetti verso IP-R1-right perché C1 ha indirizzo privato quindi non può comunicare con l'esterno, non ha senso. 1) il livello IP di un nodo non sa quali sono gli indirizzi IP della propria organizzazione di quel nodo; quindi non può sapere se tra sé stesso e la destinazione c'è un router di frontiera; IP-R1-right potrebbe stare "dentro" o "fuori", lui non può saperlo; quindi trasmette; 2) inoltre, il livello IP di un nodo non sa quanti dispositivi NAT ci sono tra sé stesso ed una data destinazione; il suo comportamento non dipende dalla presenza di un NAT altrove; quindi, C1 non può sapere che "non c'è NAT" e quindi non può contattare R1
  4. dire che l'affermazione "non contiene virus" è "vera, assumendo che il malintenzionato non lavori per Apple" denota un grande ottimismo. Apple potrebbe avere inserito malware senza esserne consapevole. Apple potrebbe anche inserire malware volutamente. La crittografia a chiave pubblica non ci fornisce nessuno strumento per escludere questa eventualità
  5. regole della forma "IP-dst \in org AND port-src=25" sono eccessivamente permissive; permettono il colloquio con qualsiasi indirizzo IP al quale ci sia un mail server; qui si vuole permettere solo il MS dell'organizzazione, è evidente che l'amministratore del firewall conosce l'indirizzo IP corrispondente (e quindi lo può inserire nelle regole)
  6. "per effettuare la verifica della firma occorre la chiave pubblica compagna della chiave privata usata per la firma". Falso, la verifica si può effettuare con qualsiasi chiave pubblica; se la chiave pubblica non è la compagna della chiave privata usata per la firma allora la verifica ha esito negativo; e comunque occorre chiarire dove si trova la chiave (in un certificato, che quindi ha uno issuer, che quindi deve stare in keyset e trustset)
  7. N1 usa indirizzi privati. Non metterla nelle tabelle di routing non ha alcun senso. Avere indirizzi privati permette di comunicare con i nodi interni all'organizzazione; se N1 non è nelle tabelle di routing i pacchetti diretti a network diverse da N1, ma interne all'organizzazione, sono scartati.
  8. i frame che trasportano messaggi DHCP non possono avere tipo IP. hanno tipo DHCP. se avessero tipo IP allora il codice che elabora quel frame interpreterebbe la sequenza di byte contenuta nel payload del frame come pacchetto IP, cioè header IP seguito da un payload
  9. un nodo che ha indirizzo privato può comunicare con i nodi della propria organizzazione. anche se si trovano in altre network. i pacchetti con src o dst privato sono scartati solo quando cercano di uscire dall'organizzazione; non sono scartati da ogni router, solo dai router di frontiera.
  10. come fa un nodo con configurazione IP dinamica ad inviare prima un gratuitous ARP e poi la richiesta DHCP ? quando invia il gratuitous ARP quale indirizzo IP dichiara di possedere ?
  11. se un nodo ha configurazione statica allora possiede indirizzo IP, subnet mask, indirizzo IP del gw non appena viene acceso. che senso ha contattare il server DHCP ? a quale scopo ? per farsi rispondere "dhcp non previsto per te" ? inoltre, visto che in N3 gli indirizzi sono allocati staticamente, perché mai dovrebbe esserci un server DHCP in quella network ?
  12. "per verificare la firma digitale abbiamo bisogno della CA che ha firmato il documento e ci dobbiamo fidare di essa". chi ha detto che il documento è stato firmato da una CA ? chi ha detto che per verificare una firma mi devo fidare di chi lo ha firmato ?
  13. "quando C1 viene acceso il server DHCP gli invierà automaticamente tutte le informazioni per ottenere connettività IP...": come fa il server a sapere che C1 è stato acceso ?
  14. quando mai abbiamo parlato di una coppia KPRIV-KPUB associata ad un file ? osservazione puramente didattica: questo è uno degli infiniti esempi che spiegano perché all'inizio del corso ho detto che la cosa più importante è imparare ad associare un tipo ad ogni entità; le coppie di chiavi sono associate a subject (scarpa) non a file (pera)
  15. "a N1 non posso assegnare indirizzi /26 perché usa indirizzi privati, quindi /16 o /8" non ha alcun senso. la dimensione di un range non ha nulla a che vedere con il fatto che gli indirizzi in quel range siano pubblici o privati.
  16. network number: 131.114.191.252/30; poi come azione instrada in una tabella di routing si mette l'indirizzo 131.114.191.252. è ovvio che il primo indirizzo di un range non deve mai essere utilizzato, perché ha host number 0
  17. come fa un messaggio DHCP discover inviato da C1 ad avere la forma "IP-C1, IP-server DHCP, DHCP, DHCP discover" ? come fa C1 ad indicare il proprio indirizzo IP ? invia questo messaggio proprio per acquisirne uno, se ce lo avesse già non lo invierebbe. Il fatto poi che quel messaggio sia indicato come "pacchetto IP" non so proprio come commentarlo.
  18. "per la verifica della firma sono necessari...e la coppia subject-KPUB corrispondente al subject che ha firmato il documento. quest'ultima informazione, perché la verifica abbia esito positivo, viene recuperata dal trustset" non ha senso: il fatto che un subject abbia firmato un documento non ha assolutamente nulla a che vedere con la presenza di quel subject in un trustset.
  19. "per poter verificare la firma...ha bisogno di un certificato generato da una CA che appartenga al suo trustset e keyset, che attesti l'attendibilità del signer apple.com"..." a parte che il concetto di "attendibilità del signer" non è mai stato definito, una CA attesta solo la verità di una associazione subject-KPUB; non attesta nessuna "qualità" o "caratteristica" del subject. se il subject è Stalin o Papa Francesco (intesi come esempi di "inattendibile" e "attendibile") per la CA è irrilevante.
  20. I messaggi ICMP sono uno dei numerosi protocolli trasportati da IP. Lo header IP permette ai nodi di cooperare per recapitare il payload ovunque, senza necessità di conoscere la struttura interna del payload. In questo caso IP ha un payload ICMP. Fare il contrario (messaggio ICMP il cui payload è un pacchetto IP) non ha il minimo senso; lo header IP è ciò che serve ai nodi e ai router per recapitare il payload IP; non per recapitare il messaggio in cui è contenuto l'intero pacchetto IP (!). Ethernet che trasporta ICMP non ha senso. ICMP che trasporta IP ne ha ancora meno.
  21. Un server DHCP non è necessariamente anche un router. Può esserlo e può non esserlo, dipende. L'unico caso in cui deve esserlo è quando in una network punto-punto uno dei due nodi ha indirizzo allocato dinamicamente. Ma in altre network, ad esempio Ethernet, il server DHCP può non essere un router.

Lista di errori (provetta 1)

Lista di errori. Anche senza il testo dell'esame, la lettura è istruttiva.
  1. I documenti il cui URL è negli attributi HREF dei tag A NON sono prelevati automaticamente (in parole più semplici: "i documenti linkati sono prelevati solo se qualcuno ci clicka sopra, non sono prelevati automaticamente"). Questo è vero anche quando il docmento è una immagine. <A HREF="url di immagine"> non è prelevato automaticamente. <IMG SRC="url di immagine"> è prelevato automaticamente.
  2. Risposte HTTP contenenti "immagine con URL modificati" non hanno alcun senso.
  3. Traffico HTTP con 1 request alla quale corrispondono 4 response non ha alcun senso
  4. Request HTTP della forma "GET *.gif, jpg, html" non hanno alcun senso
  5. Quando un browser preleva risorse da 2 server è impossibile che il numero di connessioni TCP sia al minimo 1.
  6. Se D1 contiene un IFRAME che linka D2 e D2 contiene una immagine, il prelievo della immagine ha come Referer D2. Non c'è motivo per cui il Referer dell'immagine sia D1 (notare che D1 potrebbe avere linkato D2 senza che il sito di D2 lo abbia autorizzato a farlo; pertanto se il Referer dell'immagine fosse D1 è come se D1 avesse "rubato" traffico a D2).
  7. Se una risposta contiene un documento HTML "con URL modificati" e una request successiva preleva dallo stesso server una immagine contenuta nel documento HTML, allora l'URL dell'immagine deve avere l'URL "modificato".
  8. (ancora sul punto 9)....mettere come Referer la concatenazione di D1 e (la terza parte di) D2 non ha alcun senso.
  9. Sia D l'URL del documento richiesto dalla request R; il Referrer contenuto in R ha come valore l'URL del documento in cui è stato trovato D; NON ha come valore D (che senso avrebbe "ripetere per intero" l'URL del documento che stiamo richiedendo ?)
  10. Mettere un Referer nella prima request, quella con la quale si richiede il documento il cui URL è stato inserito dall'utente, non ha senso
  11. Mettere come attributo ACTION di un FORM un URL che termina in HTML non ha senso (le credenziali vanno inviate ad un programma; in teoria il nome del programma potrebbe avere qualsiasi estensione, ma metterci HTM o HTML implica, con altissima probabilità, non avere capito).
  12. Il valore di Host è un nome di server. Quindi non deve iniziare con "http://"
  13. Il valore di Referer è un URL. Quindi deve iniziare con http:// e deve comprendere la terza parte (posso chiudere un occhio se manca la prima parte, ma non se manca la terza parte)

Liste di errori (provetta 1)

Lista di errori. Anche senza il testo dell'esame, la lettura è istruttiva.

  1. Più studenti hanno creato una sessione per pagina invece che una sessione per sito. Che senso ha?
  2. DNS request "www.bayern.de A?" (= qual'è l'indirizzo IP associato al nome www.bayern.de?). DNS response "www.bayern.de NS ns.bayern.de, ns.bayern.de A IP1" (= www.bayern.de è un nome di zona; il nome del name server di quella zona è ns.bayern.de; l'indirizzo di quel server è IP1). Che senso ha???
  3. Che senso ha inviare una richiesta GET index.html contenente un request header "header cache con must-revalidate...max-age..."???
  4. Realizzare il conteggio "inserendo un link a track.com" non ha senso: un link viene prelevato solo se l'utente esegue un click sul corrispondente elemento; per fare un conteggio occorre l'invio di una request in modo automatico, che non richiede azioni dell'utente.
  5. Molti considerano le nozioni A) "documento" (o "pagina") e B) "server" (o "sito") del tutto equivalenti. Il valore dello header Host deve essere di tipo B. Il valore dello header Referer deve essere di tipo A. Non è una differenza trascurabile. Sono entità di tipo completamente diverso.
  6. Molti hanno fornito valori separati per i contatori di visite e di visite da smartphone (com'è giusto) ma non fornito nessuna indicazione su come può track.com capire se la request proviene da un pc o da uno smartphone. in assenza di tali indicazioni non si può che ipotizzare il possesso, da parte di track.com, di capacità telepatiche
  7. Ho detto più e più volte a lezione che le risposte narrative non sono accettabili in quanto non permettono di capire se uno ha capito. Riporto qui un esempio (mi dispiace veramente, ma uno svolgimento "romanzato" è proprio incomprensibile): "Karl, da PC, invia un GET per http://bayern.de/index.html la request non appartiene a nessuna sessione lui è configurato per generarla ed utilizza la tecnica dei cookie. Il server manda la risposta con un 200 ok, se tutto è andato bene, e dopo la linea vuota sopra il documento richiesto. Il browser di Karl riceve la risposta e se la memorizza nella sua cache. Nella home page c'è un documento htm che il server non vuole che sia memorizzato e si realizza con un response header del tipo cache-control no store e due jpg che il server vuole che si memorizzino". Solo in queste due frasi il lettore si pone un numero altissimo di domande:
    • "lui è configurato...". chi è "lui"?
    • "utilizza la tecnica dei cookie". cioè? come funziona questa tecnica? chi la realizza e come?
    • "manda la risposta con un 200 ok". che significa "con un 200 ok"? 200 ok è la parte iniziale della risposta, non è un non meglio definito qualcosa che viaggia "con" la risposta.
    • "dopo la linea vuota sopra il documento richiesto". "dopo" che cosa? dopo il 200 ok? e non ci sono header? e che significa "sopra"? casomai sarà prima, non sopra.
    • "non vuole che sia memorizzato e si realizza con un response header..." response header inserito dove? in quale response?
    • "e due jpg che vuole che si memorizzino" dove sono quei jpg? come descrive la sua volontà di memorizzarli e dove? nel documento html? e, per inciso, come fa il browser a capire se sta ricevendo un documento html o un documento jpg?
    • "nella home page c'è un documento html"; la home page E' un documento html.
    • mi dispiace veramente ma davvero uno svolgimento di questo genere non è accettabile
  8. Server che mantiene sessioni con URL rewriting: in ogni documento tornato dal server, gli URL delle immagini su quel server è modificato. Credo di averlo ripetuto dieci volte. Il contenuto delle immagini non si modifica, il nome (URL) si.
  9. Quando mai abbiamo visto una http response contenente uno header user-agent?
  10. "Il minimo numero di connessioni è 2 perché sono state aperte 2 sessioni". A parte il fatto che le sessioni sono 3, ma la giustificazione è sbagliata. Si può aprire una connessione senza aprire una sessione (in generale anche se non in questo caso). E si potrebbe aprire e chiudere più sessioni in una stessa connessione (in generale anche se non in questo caso). Il tempo di vita di una connessione non c'entra nulla con il tempo di vita di una sessione.
  11. Questi 3 contatori sono mantenuti in modo separato per ogni singola pagina ("pagina=documento html")". "Elencare i contatori e fornirne il valore". Perché uno risponde a questa domanda scrivendo un racconto in cui descrive cosa fa ogni utente? Racconto dal quale, peraltro, non si riesce a ricostruire l'elenco dei contatori e dei valori corrispondenti? Non è chiesto il contributo di ogni utente al valore finale di ogni contatore (che può eventualmente essere una informazione aggiuntiva)
  12. "Descrivere il traffico DNS trasmesso e ricevuto".
    1. Un elenco di RR è una descrizione di traffico DNS trasmesso e ricevuto?
    2. Una tabella con le colonne nome, tipo, indirizzo IP è ...?
    3. Un elenco di indirizzi IP è ...?
  13. Per quale caspita di motivo una DNS request contiene oltre al nome ed al tipo anche "port 80"????
  14. Per quale caspita di motivo un browser che deve localizzare il server su cui si trova http://bayern.de/index.html invia una DNS request "bayern.de NS ?" e, se possibile ancora peggio, perché si ritiene soddisfatto dalla coppia NS/A che riceve in risposta???
  15. Inserire in ogni pagina un documento di track.com diverso è una soluzione corretta, ma molto più complicata da realizzare praticamente della "vera" soluzione: lo stesso documento di track.com è inserito in tutte le pagine di uno stesso sito (nel qual caso la distinzione tra pagine diverse dello stesso sito si ottiene con lo header Referer)
    • ed usando opportunamente il valore di Referer si potrebbe anche usare lo stesso documento per tutti i siti...basterebbe isolare la seconda componente dell'URL contenuto nel Referer per capire da quale sito proviene la request...
  16. Scrivere un segmento HTML "<....link a server >" è inaccettabile: va bene non ricordarsi la sintassi esatta di ogni singolo costrutto html, ma almeno un link html bisogna saperlo scrivere; specialmente se uno, oltre a non sapere scrivere un link, descrive le immagini come "<IFRAME src: img2.jpg>".
  17. Nessuno pretende che uno si ricordi a memoria tutti gli header http. Ma è troppo chiedere che lo header "set-cookie:" non sia chiamato "id-set:"??? Ed è troppo chiedere che se proprio uno non si ricorda "Host:" usi un nome diverso da "Location:" (che significa tutt'altro)???
  18. Che senso ha fornire come stima del numero di connessioni ">=14"??? 87432 è un numero possibile? ammesso e non concesso che uno si sia confuso con il verso della disuguaglianza, allora 0 o 1 sarebbero stime possibili?
  19. Ogni anno, invariabilmente, c'è qualcuno che crea sessioni con URL rewriting scrivendo response contenenti header "SID=12150". Ormai non so più cosa fare. Esiste una slide con un response header di nome "SID"? Esiste una slide che dica che l'URL rewriting è realizzato inserendo un apposito response header?
  20. Per quale motivo se la home page di bayern.de contiene "<IFRAME src="wid">" il browser dovrebbe inviare una richiesta ad un server diverso da bayern.de per prelevare l'URL wid?
  21. Varie persone hanno fatto ragionamenti più o meno comprensibili per giustificare l'affermazione che quando si usa il proxy cambia il conteggio fatto da track.com in quanto cambia l'indirizzo IP di provenienza. I conteggi richiesti nell'esame sono fatti in base solo al contenuto delle request http (Referer, User-Agent, Cookie o altro, ci sono varie implementazioni possibili). Gli indirizzi IP non c'entrano nulla.