Reti di Calcolatori

---

---

Introduzione
Il seguente capitolo tratterà uno dei campi più nuovi ed emozionanti dell'informatica: le Reti di Computer (Computer Networking) ed in modo approfondito e specifico Internet. Internet è ormai una realta con milioni di computer connessi tra loro in una struttura di comunicazione globale che, recentemente, sta implementando tecnologie wireless e mobili con le quali usufruire di nuove applicazioni. Il Computer Networking è nato negli anni 60 ed è solamente agli inizi della sua fase di crescita.
In questo capitolo daremo un'occhiata generale alle Reti ed a Internet, spiegnado sommariamente la maggior parte di grandi e piccoli componenti che formano Internet, chiamata non a caso "una rete di reti". Esamineremo i dettagli dei livelli (applicazione, trasporto, rete, link, fisico) utilizzati nei vari "pezzi" di internet e spiegheremo in dettaglio le tecnolgie ed i protocolli usati. Infine parleremo brevemente della storia del computer networking.
Per la sua struttura questo primo capitolo può anche essere usato per un mini-corso di introduzione ad internet ed alle sue funzionalità.

Lezione 1 - Che cosa è Internet?
Definire univocamente cosa è Internet può risultare problematico perchè Internet è una realtà molto complessa, sia in termini di hardware sia di software. Noi vogliamo invece provare a darne una definizione semplice che possa essere "capita" da tutti.

Una descrizione Dadi-&-Bulloni
Prima di dare una definizione in termini descrittivi, proviamo a dare una descrizione dell'hardware e del software che fanno esistere Internet. Internet collega circa 150-200 milioni di host (o end system) che possono essere computer, PDA, TV, portatili, automobili, elettodomestici ecc. ed il numero cresce esponenzialmente nel tempo.
Questi host sono collegati attraverso dei link di comunicazione fisici che comprendono cavi coassiali, cavi in rame (come quello del telefono), fibra ottica ed onde radio, i quali possono trasmettere dati a differenti velocità. La velocità di trasmissione viene comunemente chiamata banda (o larghezza di banda o bandwith) ed é espressa in bit/secondo.
Gli host non sono collegati tra loro direttamente ma attraverso dei router il cui compito è solamente (solamente ???) di prendere i dati da un link di ingresso ed indirizzarli correttamente ad un link di uscita; nel jargon [http://tuxedo.org/jargon] i dati trasmessi vengono chiamati pacchetti (o packet) e seguono un percorso chiamato route attraverso una tecnica di condivisione dei percorsi chiamata packet switching.
Gli host accedono ad Internet attraverso gli Internet Service Provider (ISP) che possono essere per l'utenza domestica (Tiscali, Libero ecc.) per l'università (Serra) o per le compagnie; ogni ISP è una rete di router e link che possono fornire accessi con modem 56K, ADSL, Lan 100 Mbit, Fibra ottica, Satellite o Sistemi Wireless.
Gli ISP inoltre forniscono l'accesso ai provider che permettono la pubblicazione dei siti Internet.



Per far funzionare internet i piccoli ISP si appoggiano a ISP più grandi (cha hanno linee ad altissima velocità); ogni ISP fa girare il protocollo IP ed è conforme ad alcune regole riguardo alle convenzioni da usare per i nomi e gli indirizzi.
In Internet i vari "pezzi" eseguono vari protocolli tra cui i due fondamentali di Internet, il TCP/IP (Transmission Control Protocol "over" Internet Protocol).
Tutto ciò che è pubblico e fa parte di una rete viene comunemente chiamato Internet, ma esistono anche reti private indipendenti (a volte sparse su tutto il globo terrestre) che prendono il nome di Intranet e spesso usano lo stesso hardware e software di Internet.
Si può ben capire come in una moltitudine di invenzioni a livello hardware e software per far fronte alle varie esigenze nell'interesse di un miglior funzionamento della rete, sia necessario definire degli standard; a questo ci pensa l'IETF (Internet Engineering Task Force) con la stesura di RFC (Request for Comments) per far fronte ai vari problemi (basti pensare che per definire gli standard TCP, IP, HTTP, SMTP ecc. ci sono circa 3000 RFC differenti). Una lista completa delle RFC è accessibile [cliccando qui].

Una descrizione per Servizi
Addesso proviamo a guardare cosa è Internet dal punto di vista dei servizi:

• Applicazioni distribuite: Le applicazioni distribuite girano sugli host per permettere lo scambio di dati. Tra queste applicazioni ci sono login remoto, email, navigazione web, programmi di messaggistica, audio e video in streming, telefonate attraverso Internet, giochi distribuiti, P2P (Peer-to-Peer) e moltissimo altro.
• Servizio affidabile e non affidabile: Internet offre dei servizi che possono essere affidabili (reliable), i quali garantiscono la trasmissione dei dati, o non affidabili (unreliable). Generalmente le applicazioni distribuite fanno uso dell'uno o dell'altro servizio, ma non di tutti e due insieme (:D).
• Nessuna garanzia: I servizi Internet non danno nessuna garanzia sul tempo necessario a far arrivare un dato a destinazione, e non vale la regola assoluta per cui pagando di più si hanno servizi più rapidi.

Cos'è un protocollo?
Per capire correttamente cos'è un protocollo è possibile dire che un protocollo di rete è simile ai "protocolli umani", eccetto per le unità coinvolte nella comunicazione. Tutte le azioni che coinvolgono due o più entità remote utilizzano un protocollo per comunicare.
Si pensi a quando facciamo una richiesta ad un server Web: Il browser invia al server una richiesta di connessione, il server risponde in modo positivo alla richiesta, a quel punto il browser richiede il file ed il server glielo invia. Un protocollo può quindi essere definito come segue:

Un Protocollo definisce il formato e l'ordine dei messaggi scambiati
tra due o più entità comunicanti, come le azioni prese nella trasmissione
e/o ricezione di un messaggio od un altro evento.

Lezione 2 - Il perimetro di Internet

host = end system

Servizio affidabile (orientato alla connessione) - TCP
- Handshaking (indispensabile)
- Reliable Data Transfer
- Flow Control (controllo del flusso)
- Congestion Control

Servizio non affidabile (non orientato alla connessione) - UDP
- Invia i file senza garanzia
- Utilizzato in ambito multimediale

Lezione 3 - Il cuore di Internet

Circuit Switching
- FDM (Frequency-Division Multiplexing) - Telefonia, 4 KHz
- TDM (Time-Division Multiplexing)

Packet Switching
- ROUTER (Packet Switches)
- Store-and-Forward Transmission
- Output Queue (coda) -> Queuing delays -> Packet Loss
- Statical Multiplexing
- Permette di sopportare almeno il triplo del numero di utenti che sopporterebbe il Circui Switching


Lezione 4 - Invio dei pacchetti nelle reti

Reti Virtual Circuit
Mantiene le informazioni dello stato della connessione

Reti Datagram Packet
- E' gerarchico come il servizio postale
- End-to-End routing (come guidatore che chiede per direzioni)
- Non mantiene necessariamente le informazioni dello stato della connessione

Lezione 5 - Accesso alla Rete e Dispositivi Fisici

Accesso alla Rete

• Accesso domestico


• Accesso aziendale


• Accesso mobile

Dispositivi Fisici

• Doppino di rame


• Cavo Coassiale


• Fibra Ottica


• Canali Radio Terrestri


• Canali Radio Satellitari

Lezione 6 - Ritardi e perdite nelle reti Packet-Switch
- PROCESSING DELAY (per leggere l'header) - microsecondi o meno
- QUEUING DELAY (ritardo nel buffer) - da microsecondi a millisecondi
- TRANSMISSION DELAY (L bits / R bits/sec) - da microsecondi a millisecondi
- PROPAGATION DELAY (~ 3*10^-8) - millisecondi

Lezione 7 - I livelli (o strati) dei protocolli

Funzioni

- Controllo degli errori
- Controllo del flusso
- Segmentazione e riassemblamento
- Multiplexing
- Setup connessione (handshaking)

Internet Protocol Stack

- APPLICAZIONE (HTTP, SMTP, FTP ecc.)
- TRASPORTO (TCP connessione, UDP no-connessione)
- RETE (IP layer)
- LINK (Routing - Ethernet, PPP, ATM)
- FISICO (muovere i bit)

Lezione 8 - Futuri sviluppi

• DSL e CABLE
• WIRELESS
• P2P

---

---

Lezione 1 - Introduzione
Le applicazioni di rete sono la "ragione di esistere" di una rete. Nel nostro studio su Internet dobbiamo innanzitutto pensare a diversi HOST, sui quali girano dei PROCESSI che si scambiano (attraverso la Rete) dei MESSAGGI. Come avviene ciò? Avviene grazie ai protocolli del livello applicazione che costituiscono una parte (grande) dei programmi di rete; pensiamo ad esempio ad un browser che utilizza l'HTTP (ma non solo) o ad un programma di posta che usa l'SMTP (ma non solo).
Un protocollo del livello applicazione definisce come i processi di un applicazione, che girano su diversi host, si possono passare dei messaggi; in particolare definisce:

• Il tipo di messaggi scambiati (es. richieste o risposte);
• La sintassi dei vari tipi di messaggi, come i campi di un messaggio;
• La semantica dei campi, ovvero il significato dei campi stessi;
• Le regole per determinare quando e come un processo invia un messaggio o risponde ad un messaggio.

Bisogna fare, prima di procedere, una distinzione tra lato client (es. browser) e lato server (es. webserver) di un'applicazione di rete, che potrebbero essere in esecuzione anche sulla stessa macchina; generalmente l'host che inizia la sessione viene chiamato client.

Affinchè due processi possano comunicare, è necessario utilizzare dei socket, come delle porte in cui si immettono o si leggono dei dati; un socket è l'interfaccia tra il livello applicazione ed il livello trasporto, conosciuto anche come API (Application Programmers'Interface) tra l'applicazione e la rete. Il socket opera soprattutto a livello di trasporto e un programmatore che usa tale tecnica è limitato dalle implementazioni.



Per far comunicare i due host deve esserci un modo per identificare univocamente, sia i due host, sia i processi in esecuzione su ciascun host. Per identificare l'host viene usato l'indirizzo IP (a 32-bit), mentre per l'identificazione dei processi viene usato un numero di porta, ad esempio il protocollo HTTP usa la porta 80, mentre l'SMTP la 25.

Uno user agent è un'interfaccia tra l'utente e l'applicazione di rete, ad esempio un browser è uno user agent per l'applicazione che implementa l'HTTP, mentre un client di posta (come Eudora) è uno user agent per l'applicazione che implementa l'SMTP.

Di cosa necessita un'applicazione?
Per sviluppare un'applicazione bisogna conoscere i protocolli che vengono forniti dal livello di trasporto, i più famosi sono il TCP e l'UDP ognuno con propri pregi e difetti riguardo a tre proprietà: perdita di dati, larghezza di banda e la temporizzazione.

• Trasferimento affidabile dei dati
  Alcune applicazioni, come messenger, programmi posta ecc. richiedono che la trasmissione dei dati avvenga senza perdita di dati; altre applicazioni, come quelle multimediali, invece, possono permettersi piccoli errori accettabili;
• Larghezza di banda
  Ci sono applicazioni, come quelle per telefonare, che richiedono una banda minima di trasmissione e vengono chiamate applicazioni sensibili alla banda; ci sono poi anche applicazioni elastiche che, invece, possono lavorare anche con pochissima banda disponibile, stiamo parlando di email, trasferimento di file o il download di una pagina web;
• Temporizzazione
  Come per la banda (e spesso il concetto è legato) esistono applicazioni che hanno bisogno di ricevere i dati con una certa frequenza, come applicazioni telefoniche, giochi multiplayer o videoconferenze; analogamente ci sono applicazioni che non fanno assunzione sul tempo di trasmissione.

Servizi del TCP

• Orientato alla connessione - la connessione TCP consiste in una fase di handshacking;
• Trasporto affidabile - arrivano tutti i dati senza errori e nel giusto ordine;
• Controllo della congestione - sistema di gestione automatico per non intasare la Rete;
• Non garantisce una velocità minima di trasmissione;
• Non fa nessuna assunzione sul tempo che impiega per compiere una trasmissione.

Servizi dell'UDP

• Nessuna connessione - nessuna fase di handshacking;
• Trasporto non affidabile - nessuna garanzia sull'avvenuta ricezione;
• Nessun controllo della congestione;
• Possibilità di inviare i dati alla velocità di trasmissione desiderata;
• Nessuna assunzione sul tempo di trasmissione (come il TCP).

Lezione 2 - HTTP

• Pagina Web consiste di oggetti, come file HTML, immagini GIF e JPG, Applet Java, file audio;
• URL - esempio www.sito.it/percorso/file.html - la prima parte identifica l'host, la seconda il percorso al quale ricercare il file;
• Browser - programma che implementa la parte client dell'HTTP, serve per navigare attraverso i siti web;
• Web server - programma che implementa la parte server dell'HTTP e che soddisfa una o più richieste da parte dei browser, inviando i file tramite il protocollo TCP;
• HTTP definisce come i browser richiedono le pagine web dal Web server e come le pagine vengono trasferite al client. Esistono due versioni dell'HTTP, la versione 1.0 che non mantiene la connessione (leggasi un file alla volta) e la versione 1.1 che mantiene la connessione che è retrocompatibile con la 1.0. Inoltre, poichè il server non mantiene nessuna informazione sul client, viene chiamato protocollo senza stato.

• Connessioni non persistenti - caratteristiche dell'HTTP/1.0, ogni volta che vogliamo richiedere un oggetto deve essere stabilita una connessione con relativa fase di handshacking, il tutto porta a "consumare" due RTT (round-trip time - tempo per andare e tornare), uno per la connessione TCP ed uno per la richiesta del file;
• Connessioni persistenti - tipiche dell'HTTP/1.1, permettono di avere una sola fase di handshacking in cui fare svariate richieste per più oggetti, con evidente risparmio di RTT (e quindi di tempo). Inoltre le richieste possono essere fatte con o senza pipelining; nel primo caso le richieste vengono fatte una di seguito all'altra, nel secondo bisogna aspettare il responso della prima richiesta per poterne fare un'altra.


E' evidente che tra una connessione non persistente ed una persistente con pipelining, per la richiesta, ad esempio, di una pagina web più quattro immagini (quindi cinque oggetti), si può arrivare da 10 RTT fino a 2 RTT (con un aumento di prestazioni del 500%).

Formato di un messaggio di richiesta HTTP
Ecco la formattazione standard di un messaggio di richiesta:


La prima linea viene chiamata request line, le seguenti header lines; la request line può avare il valore GET (richiesta semplice), POST (richiesta con variabili), HEAD (solo intestazione per debug), PUT (per caricare file), DELETE (per eliminare file), tutti che agiscono su un percorso passato come parametro dell'host di riferimento e che dicono il tipo di protocollo HTTP usato (1.0 o 1.1).
Le linea successiva identifica l'host su cui risiede l'oggetto richiesto; il "Connection: close" identifica che non si vuole usare una connessione permanente; lo "User-agent" identifica il tipo di browser che stiamo utilizzando; "Accept-language", invece dichiara la lingua preferita per la pagina (nel nostro caso l'italiano :D).



Formato di un messaggio di risposta HTTP
Ovviamente ad una richiesta corrisponde una risposta da parte del server:


Qui abbiamo la prima linea (status line) che dice se la connessione è stata accettata o meno, poi le linee dell'header in cui si identifica la data dell'ultima modifica, la data di accesso alla pagina, il tipo di Web server che ci ha risposto, la lunghezza del messaggio e il tipo di formato del messaggio contenuto del body; infatti nel body sarà presente la risposta del server che può essere un file di testo/html, un'immagine od altro.



Per dovere di cronaca segnialiamo alcuni codici alternativi nella risposta:

• 200 OK - Richiesta accettata, le informazioni sono nel corpo del messaggio;
• 301 Moved Permanently - La pagina richiesta è stata spostata; il nuovo URL è specificato nel campo Location della risposta;
• 400 Bad Request - Errore generico che informa che la richiesta non può essere accettata;
• 404 Not found - La pagina richiesta non è presente sul server;
• 505 HTTP Version Not Supported - La versione del protocollo HTTP non è supportata dal server.

Autorizzazione
A volte navigando in un sito, il server potrebbe richiedere un'accesso autorizzato; spesso accade che alla prima richiesta di un browser, il server risponda con un messaggio 401 Authorization Required, a questo punto il browser chiede, tramite un prompt, i dati all'utente e li invia ad ogni richiesta TCP in un campo Authorization.

I Cookie

1. Quando un browser accede ad un sito che utilizza i cookie, il sito genera un numero identificativo dell'utente e lo registra, generalmente, in un database;
2. A questo punto il server risponde al browser con un Set-cookie: -numero- che ha l'effetto di far creare al browser un file speciale con i dati del cookie;
3. Mentre il browser continua a navigare, invia il proprio codice con il comando nell'header Cookie: -numero- e permette al sito di tracciare tutte le attività di quel browser;
4. Parallelamente nel cookie possono essere registrare informazioni personali, come preferenze per la navigazione o i dati di accesso ad un sito.

Il GET condizionale
Per risparmiare risorse viene usata la tecnica di caching, che permette di navigare senza dover obbligatoriamente aggiornare le pagine che magari sono già state visitate e non hanno subito modifiche.
Per fare questo si usa il GET condizionale, ovvero si usa lo statement "If-Modified-Since" in questo modo:

PRIMA RICHIESTA

GET /pippo/pluto.jpg HTTP/1.0


PRIMA RISPOSTA

HTTP/1.0 200 OK
Last-Modified: Mon, 22 Jun 1998 09:23:24


RICHIESTE SUCCESSIVE

GET /pippo/pluto.jpg HTTP/1.0
If-modified-since: Mon, 22 Jun 1998 09:23:24

POSSIBILE RISPOSTA (altrimenti invia la pagina aggiornata)

HTTP/1.0 304 Not Modified

Lezione 3 - FTP
Permette di trasferire i file da un host ad un altro:

PORTA 21: Connessione di controllo
PORTA 20: Connessione per i dati

Il server FTP mantiene lo stato dell'utente; ecco i comandi usati:

• USER username: Usato per inviare il nome utente al server;
• PASS password: Usato per inivare la password al server;
• LIST: Usato per chiedere al server la lista dei file attraverso una connessione dati;
• RETR filename: Usato per chiedere al server un file dall'host remoto;
• STOR filename: Usato per inviare al server un file in locale all'host remoto.

ed alcuni messaggi di risposta:

• 331 Username OK, password required
• 125 Data connection already open; transfer starting
• 425 Can't open data connection
• 452 Error writing file

Lezione 4 - Email e SMTP
La posta elettronica (email) esiste dagli albori della nascita di internet, ed è composta da tre componenti principali: user agent, mail server e l'SMTP (Simple Mail Transfer Protocol). Grazie ai programmi di posta è possibili leggere, scrivere, inviare, ricevere, salvare email (si pensi ad Outlook); un mail server al quale siamo iscritti ci mette a disposizione una mailbox, che amministra e mantiene i messaggi che riceve. Il tragitto comunemente seguito da un messaggio di posta è del tipo:

user agent sender -> mail server sender -> altri mail server -> mail server receiver -> user agent receiver

Se chi invia il messaggio non ci riesce per momentanea indisponibilità del server del ricevente, il messaggio viene messo in una coda (queue) e poi il server proverà ad inviarlo, ad esempio, ogni 30 minuti.

Protocollo SMTP
Il protocollo SMTP, definito nell'RFC 2821, è il cuore delle posta elettronica e definisce il modo di comunicare tra il programma di posta ed il server e tra i vari server; è molto più vecchio dell'HTTP ed ha molte qualità interessanti ma anche alcune caratteristiche "arcaiche" che si sta trascinando dietro, come la codifica ASCII a 7bit.
Ecco le operazioni di base per l'invio di un messaggio di posta:

1. Il mittente esegue il programma di posta, inserisce l'email del destinatario, scrive il messaggio e lo invia;
2. Il programma di posta invia il messaggio al server, dove viene messo in una coda per l'invio;
3. Il lato Client dell'SMTP sul server del mittente, vede il messaggio in coda e stabilisce una connessione TCP ad un Server SMTP sul server del ricevente;
4. Il lato Client dell'SMTP invia il messaggio su quella connessione TCP;
5. Il Server del ricevente riceve il messaggio e mette il messaggio nella mailbox del ricevente;
6. Il ricevente esegue il propria programma di posta per leggere il messaggio.

Per inviare un messaggio, un programma di posta, o semplicemente un client SMTP (quindi anche il nostro server di posta), fanno una connessione sulla porta 25 (es. telnet nomeServer 25) e comunicano con l'altro server i dati necessari a trasferire il messaggio, come riportato di seguito:

S: 200 receiver.it C: HELO sender.com S: 250 Hello sender.com, pleased to meet you C: MAIL FROM: S: 250 pippo@sender.com ... Sender OK C: RCPT TO: S: 250 pluto@receiver.it ... Recipient OK C: DATA S: 354 Enter mail, end with "." on a line by itself C: Email di prova C: Testo del messaggio C: . S: 250 Messagge accepted for delivery C: QUIT S: 221 receiver.it closing connection

Si possono notare alcune differenze sostanziali tra l'HTTP e l'SMTP; prima di tutto l'HTTP è un pull protocol, in cui la connessione viene cominciata da chi vuole ricevere il file, mentre l'SMTP è un push protocol, in cui, contrariamente, è chi invia i dati che comincia la connessione.
Secondariamente l'SMTP codifica tutto in un ASCII a 7bit, mentre l'HTTP può mandare i dati sia in ASCII che in binario. Terzo, l'SMTP mette testo ed oggetti in un unico messaggio, mentre l'HTTP invia un oggetto separatamente da un altro.

Formato dei messaggi delle Mail

• Testo semplice

  From: pippo@sender.com To: pluto@receiver.it Subject: Info su topolinia

• Mime semplice
  
  

  From: pippo@sender.com To: pluto@receiver.it Subject: Foto di topolinia MIME-Version: 1.0 Content-Trasnfer-Encoding: base64 Content-Type: image/jpeg (base64 econded data ... ... ... ... ... ... ... ... base64 econded data)

  
  "Content-Type": text/plain, text/html, image/gif, image/jpeg, application/msword, application/pdf ecc.
• Mime multipart
  
  

  From: pippo@sender.com To: pluto@receiver.it Subject: Foto di topolinia con commento MIME-Version: 1.0 Content-Type: multipart/mixed; Boundary=StartOfNextPart --StartOfNextPart Content-Trasnfer-Encoding: base64 Content-Type: image/jpeg (base64 econded data ... ... ... ... ... ... ... ... base64 econded data) --StartOfNextPart Ecco le foto che mi avevi richiesto.

  
  
• Il campo Received
  
  

  Received: from receiver.it by host.it; 3 Jul 01 15:30.01 GMT Received: from sender.com by receiver.it; 3 Jul 01 15:17.39 GMT

  
  

Protocolli di Accesso alla Mail
Come può, un ricevente, leggere un messaggio? Abbiamo volutamente sorvolato su questa questione, perchè necessita di una nota di riguardo. L'SMTP è utile solamente quando il destinatario è sempre connesso, altrimenti non può ricevere il file; però il computer di una persona normale non è sempre connesso, ma il suo server di posta si (IMHO esiste per quello), è sempre acceso e sempre connesso ad internet.
E' per questo che c'è bisogno di un protocollo che permetta ad un utente di autenticarsi presso il proprio server di posta e di leggere/scaricare i messaggi. I protocolli in questione sono il POP3 (Post Office Protocol - v3), IMAP (Internet Mail Access Protocol) e l'HTTP (webmail).

• POP3
  Nell'RFC 1939 è definito il protocollo POP, un protocollo molto semplice che ha, per questo, delle funzionalità abbastanza limitate. Il POP3 inizia quando un client (user agent) apre una connessione TCP con il server di posta sulla porta 110, a questo punto procede a tre fasi distinte: autorizzazione, transazione ed aggiornamento.
  Durante la prima parte l'utente fornisce il nome utente e la password per autenticarsi; nella seconda fase l'utente legge, o meglio, scarica l'email; nella terza fase, quella di aggiornamento, occorre quando l'utente digita QUIT e chiude la sessione POP3, a questo punto il server di posta elimina i messaggi che sono marcati per essere eliminati.
  Ecco una sessione tipica per una comunicazione POP:
  
  

  telnet MailServer 110 S: +OK POP3 server ready C: user pluto S: +OK C: pass topolino S: +OK user successfully logged on C: list S: 1 384 S: 2 739 S: . C: retr 1 S: (blah blah ... S: ... ... ... S: ... blah blah) C: dele 1 C: retr 2 S: (blah blah ... S: ... ... ... S: ... blah blah) C: quit S: +OK POP3 server signing off

  
  Una piccola nota riguardo al fatto che un utente può lasciare i messaggi sul server, per leggerli su più computer, per questo è possibile scegliere tra l'opzione di cancellare i messaggi o di lasciare i messaggi sul server.
• IMAP
  Come il POP3, anche l'IMAP è un protocollo che permette di leggere le email, ma a differenza di esso, permette un'organizzazione in cartelle per l'archiviziano, permettendo così di sincronizzare la posta scaricata con quella sul server, avendola a disposizione anche quando non siamo al nostro computer. Infatti se il nostro server supporta l'IMAP, è possibile loggarsi e gestire (creare, rinominare, cancellare) le cartelle ed i messaggi all'interno delle cartelle. Inoltre l'IMAP permette di cercare un messaggio nelle proprie cartelle e, cosa più importante, di gestire gli oggetti dell'email, è infatti possibile (per risparmiare la banda) visualizzare solo l'header, o solo un oggetto (un allegato) di un determinato messaggio, senza doverlo "scaricare" tutto.
• HTTP
  L'HTTP viene usato soprattutto perchè permette di leggere la posta attraverso un comunissimo browser web; in questo modo si ovvia a molti problemi, innanzitutto è difficilissimo prendere i famosi virus per computer, secondo è possibile leggere i messaggi senza doverli scaricare completamente (pensate ad un amico che vi invia 10 foto e a voi interessa solamente il testo della mail), terzo, in questo modo è possibile sia leggere che scrivere nuovi messaggi; non a caso è possibile fare ciò grazie ai linguaggi di scripting server side (come ASP, PHP o JSP) perchè implementano i protocolli di invio (SMTP) e di ricezione (POP o IMAP), prediligendo per la ricezione il protocollo IMAP che permette un'organizzazione in cartelle per archiviare le email (Hotmail docet).

Lezione 5 - DNS (Domain Name System)
Corrispondenza tra nomi simbolici ed indirizzi IP (v.4 o v.6). IP definisce il formato degli indirizzi delle macchine e la versione 4 rappresenta, appunto, gli indirizzi con un intero di 4 byte. Dato un indirizzo con un nome simbolico, il browser interroga un DNS, che tiene in piedi un DB con la corrispondenza tra nomi simbolici, nomi fisici e indirizzi IP, ottiene l'indirizzo IP e vi fa la propria richiesta.

Name Server
I Name Server si dividono in Root NS, Authorative NS e Local NS; questi server differiscono per le funzionalità. L'idea è quella di avere un albero non perfettamente bilanciato dove le "foglie" conoscono l'indirizzo dei predecessori e dei vicini.

• Root NS - Stanno nella radice. All'incirca ci sono una decina di radici sparse per il mondo. La radice è l'ultima macchina alla quale chiedo l'indirizzo, la chiedo a lei perchè le altre macchine non lo conoscono.
• Authorative NS - Questo è registrato presso il root. Se il root non conosce l'indirizzo, di sicuro conosce l'authorative NS che lo conosce.
• Local NS - Sta nelle foglie ed è una macchina che si mantiene nella cache una serie di NOMI-VALORI, generalmente quelli più visitati.

Perchè non si usa una tabella locale? perchè gli indirizzi sono molti e cambiano continuamente.
Per ricercare gli indirizzi si usano due metodi:

- iterativo: che mi restituisce, se il mio LNS non sa l'indirizzo, il nome dell'LNS che lo conosce.
- ricorsivo: Un po' più lento ma restituisce l'indirizzo cercato.

Nella cache locale gli indirizzi vengono salvati per un tempo prestabilito (ca 5 min) definito dal TTL (Time To Live), poi dobbiamo richiedere l'indirizzo all'authorative NS. Ogni riga della cache è formattata nel modo seguente:


Il nome ed il value dipendono dal Tipo, ecco qui di seguito spiegato:

• Tipo = A - Il Nome identifica il nome dell'host e il Value l'indirizzo IP relativo.
• Tipo = NS - Il Nome è un domino (es. pippo.it) e Value è il nome dell'host di un server NS authorative che conosce l'IP del dominio (es. dns.pippo.it).
• Tipo = CNAME - Il valore è nome convenzionale sostutivo per il nome in Nome.
• Tipo = MX - Il Value è un nome convenzionale di un server mail per il nome in Nome; questo serve per assegnare molteplici e più semplici nomi ai server di posta.

Messaggi DNS


Lezione 6 - Web Caching
Un proxy server (o web cache) è una macchina dedicata a soddisfare le richieste dell'utente senza andarle a chiedere al destinatario (vedere il GET condizionale). Si passa prima dal proxy, se l'oggetto c'è viene restituito immediatamente al cliente, altrimenti viene chiesta al server, salvata nella cache ed inviata al cliene. I vantaggi indiscutibili sono:

- I tempi di risposta più brevi;
- Diminuzione del traffico verso server distanti;
- Maggiore sicurezza.

Generalmente si predilige una struttura gerarchica del caching per ottimizzare la ricerca di oggetti; ad esempio, prima si passa dalla cache della rete locale, poi da quella del nostro ISP, poi da quella del backbone italiano e così via.

CDN: Content Distribution Network
Negli anni 90 si sono fatti strada i CDN, strutture professionali di Web-caching che non si rivolgono agli ISP, ma piuttosto ai Content-provider (come Yahoo) per rendere l'accesso a tali siti più veloce. Generalmente una compagnia CDN fornisce i seguenti servizi:

1. La compagnia installa centinaia di server CDN attraverso Internet.
2. Generalmente tali server vengono messi negli Internet hosting server, strutture che raccolgono centinaia di host.
3. La compagnia replica il contenuto del cliente in tutti i server CDN e aggiorna i contenuti automaticamente.
4. La compagnia prevede un meccanismo per cui un utente che richiede un contenuto passa direttamente attraverso il CDN più vicino o il più veloce.

Per poter accedere al CDN, il cliente sostiuisce ad ogni URL, l'URL della compagnia cdn, esempio www.cdn.com/www.pippo.it/pluto.htm; in questo modo quando viene fatta la richiesta HTTP al sito del cliente, il browser vede il prefisso della compagnia CDN, fa una query DNS per sapere l'indirizzo IP, quindi chiede al CDN il file, il CDN calcola il server CDN più vicino con quel contenuto e, se esiste, lo invia al browser. Tale procedura, che può sembrare complessa e dispendiosa, offre spesso notevoli aumenti di velocità nell'accesso a siti di grosse dimensioni.

---

---

Lezione 1 - Introduzione

Proprietà di una comunicazione sicura:

• Riservatezza: Soltanto chi manda e chi riceve deve essere in grado di capire il contenuto del messaggio; generalmente questa operazione viene fatta criptando/decriptando il messaggio con una chiave (key).
  
• Autenticazione: La possibilità di identificare in maniera univoca il proprietario di un messaggio.
  
• Integrità del messaggio: La possibilità che un messaggio arrivi integro, ovvero non modificato, dal mittente al destinatario.
  
• Disponibilità e controllo di accesso: Evitare che le strumentazioni vengano attacchate (es. attacchi DoS) o che qualcuno possa usare le risorse in modo illeggittimo (uso di Firewall).
  

Lezione 2 - Principi di crittografia

Terminologia usata:

• Testo in chiaro (plaintext o cleartext): Il messaggio originale leggibile.


• Algoritmo di codifica: Un algoritmo (semplice o complesso) che trasforma il testo in chiaro in un testo cifrato e quindi difficilmente leggibile.


• Algoritmo di decodifica: Un algoritmo che trasforma un testo criptato nel testo in chiaro originale.


• Chiave (key): Una stringa di numeri o lettere (K_A) che viene data come input insieme al messaggio (m) ad un algoritmo di codifica che produce un messaggio cifrato, il quale, a sua volta, dovrà essere decifrato con un algoritmo di decodifica e una opprtuna chiave (K_B) tale che K_B(K_A(m)) = m.
  In un sistema a chiavi simmetriche le chiavi usate sono uguali, K_A = K_B, e sono conosciute sia dal mittente sia dal destinatario.
  In un sistema a chiavi pubbliche viene usata una coppia di chiavi, una pubblica (conosciuta da mittente e destinatario) e l'altra conosciuta solamente dal rispettivo proprietario.

Cifratura a chiave simmetrica
L'algoritmo più semplice (e vecchio) a chiave simmetrica è il famoso cifrario di Giulio Cesare in cui ad ogni lettera viene associata una lettera alla k-ma posizione rispetto a quella presa in considerazione; esempio con k=3, la lettera 'a' diventa 'd', la 'b' diventa 'e' e così via; tuttavia questo metodo è di facile soluzione avendo la possibilità di usare solo 25 chiavi.
Una variante migliorata consiste nel cifrario monoalfabetico in cui si crea una tabella di corrispondenza tra l'alfabeto originale e quello personalizzato, senza nessun collegamento logico tra le lettere; in questo modo le combinazioni salgono a 10²⁶, anche se in realtà si possono decifrare parole di uso comune ed arrivare (tramite varie sostituzioni o con un brute-force) alla lettura del testo in chiaro.
Esistono infatti tre metodi usati per decifrare un testo:

• Attacco al testo cifrato: Un intruso potrebbe accedere al testo cifrato e potrebbe risalire al testo in chiaro con un attacco brute-force.
• Attacco al testo in chiaro conosciuto: Se l'intruso riesce a conoscere una parte del testo in chiaro ed ha a disposizione il testo cifrato, potrebbe risalire, tramite sostituzione, al testo in chiaro completo.
• Attacco al testo in chiaro scelto: In questo tipo di attacco un intruso potrebbe, tramite la scelta di un possibile testo in chiaro, risalire al cifrario e, quindi, al testo in chiaro; non è comunque detto che in questo genere di attacchi l'intruso riesca a rompere il cifrario.

Solamente cinque anni fa è stato inventato il cifrario polialfabetico che, come si presume, utilizza due o più cifrari monoalfabetici (Cesare o sua evoluzione), con la particolarità di assegnare uno schema ripetitivo che identifica con quale cifrario deve essere cifrata/decifrata la x-ma lettera. Supponiamo di usare il cifrario di Cesare con k=9, chiamiamo questo cifrario C₁, e un cifrario monoalfabetico C₂; definito lo schema ripetitivo C₁C₂C₁C₂C₂ è possibile cifrare un testo con un buon margine di sicurezza, perchè la stessa parola potrebbe essere cifrata in modo diverso a seconda della sua posizione nel testo.

Il DES (Data Encryption Standard) e l'AES (Advanced Encryption Standard)
Uno degli algoritmi più usati negli ultimi anni è il DES (Data Encryption Standard) che esegue queste operazioni:

La funzione f(32bit, 32bit, key)->32bit esegue un espansione da 4 a 6 bit, per poi applicare un OR esclusivo con la chiave da 48-bi, una sostituzione, ed un altro OR esclusivo con i 32 bit di input più a sinistra.
In realtà questo accade per ogni blocco di 64 bit, e nel caso il messaggio sia più lungo di 64 bit (leggi SEMPRE) si usa la tecnica del concatenamento dei blocchi cifrati in cui il j-mo blocco cifrato fa uno XOR con il j-mo+1 blocco in chiaro.
Siccome in realtà il DES usa 56 bit reali (invece di 64 bit) per alcuni viene considerato troppo insicuro, quindi è stato pensato di usare il triple-DES (3DES) che, in pratica, consiste nell'applicare tre volte il DES usando l'output come input.
Nel novembre 2001 è stato annunciato il successore del DES, l'Advanced Encryption Standard (AES), conosciuto anche come l'algoritmo di Rijndael che usa una chiave simmetrica da 128, 192 o 256 bit su un blocchi da 128 bit; E' stato calcolato che se esistesse un computer in grado di decifrare il DES in un secondo, ci metterebbe 129 trilioni di anni per decifrare una chiave AES a 128 bit.

Cifratura a chiave pubblica
La cifratura a chiave pubblica è abbastanza complicata, poichè cambia radicalmente il concetto della chiave simmetrica, in cui la solita chiave viene usata sia per cifrare sia per decifrare, ma come è possibile trasmettere in modo sicuro la chiave? La cifratura a chiave pubblica ci viene in aiuto con due chiavi, una pubblica (K_B⁺) per cifrare ed una privata (K_B^-) per decifrare, diverse tra loro, ma che applicate al messaggio danno il testo cifrato/chiaro, poichè K_B^-(K_B⁺(m)) = K_B⁺(K_B^-(m)) = m.
LA procedura dell'algoritmo RSA è abbastanza complicata, ma prima di procedere alcune considerazione sul suo uso; innanzitutto la chiave privata può essere usata per cifrare un testo, generalmente una firma o una chiave simmetrica, per poi essere decifrata con la chiave pubblicata; questo perchè l'uso di chiavi pubbliche permette di inviare messaggi fasulli (contrariamente alle chiavi simmetriche) e perchè l'atto di codifica/decodifica richiede molto più tempo rispetto, ad esempio, all'uso del DES.
Procediamo ora, spiegando per punti, la procedura di cifratura e la dimostrazione del perchè essa funziona.

1. Scegliere due numeri primi p e q abbastanza grandi il cui prodotto sia compreso tra 768 e 1024;
2. Calcolare n=pq e z=(p-1)(q-1);
3. Scegliere un numero e, minore di n, che non abbia fattori in comune con z (in questo caso e & z sono detti primi relativi);
4. Trovare un numero d tale che ed-1 sia esattamente divisibile per z;
5. La chiave pubblica K_B⁺ è formata dai numeri (n,e) e la chiave privata K_B⁺ da (n,d).

Ecco dimostrato perchè l'algoritmo RSA funziona:

• Per cifrare il messaggio si esegue C = m^e mod n; mentre per tornare al messaggio originale basta eseguire m = C^d mod n;
• Questo accade perchè (m^e)^d mod n = m^ed mod n;
• Quindi (m^e)^d mod n = m^{(ed mod (p-1)(q-1))} mod n;
• Da cui (m^e)^d mod n = m¹ mod n = m;
• Ed anche (m^e)^d mod n = m = (m^d)^e mod n.

Lezione 3 - Autenticazione
Autenticazione è una procedura per provare la nostra identità ad un'altra persona. Nel mondo reale ciò può essere fatto facilmente, mentre nel mondo virtuale c'è bisogno di un firma digitale e di un protocollo di autenticazione che vieti a degli intrusi di spacciarsi per noi o farsi spacciare per altri. Vediamo lo sviluppo progressivo di un protocollo, che chiameremo ap (authentication protocol), per ovviare ai problemi riscontrati.

AP v1.0
Questo protocollo base consiste nel dichiarare in un messaggio la propria identità; ovviamente, senza nessun riscontro tangibile, chiunque potrebbe spacciarsi per noi.

AP v2.0
Una miglioria potrebbe essere quella di identificare(si) attraverso l'uso dell'indirizzo IP, ma anche questa tecnica risulta errata, perchè un utente malintenzionato potrebbe creare un pacchetto IP con un indirizzo falso ed ottenere l'accesso. Questa tecnica viene comunemente chiamata IP-spoofing.

AP v3.0
L'autenticazione potrebbe avvenire aggiungendo l'invio di una password; in questo caso il nostro solito utente malintenzionato potrebbe avere accesso al server della LAN o ad un terminale e potrebbe sniffare (leggere e salvare) la password inviata durante la comunicazione.

AP v3.1
Per correggere l'ap v3.0 è possibile cifrare la password con un algoritmo di cifratura. In questo modo per Trudy sarebbe difficile trovare la password originale; ma è possibile comunque registrare la password e mandarla criptata per farsi autenticare. In questo caso il problema dello sniffing non è stato ancora risolto.

AP v4.0
Per ovviare ai problemi precedenti si può introdurre un sistema che consenta a Bob di verificare, non solo che l'interlocutore è chi dice di essere, ma anche di capire se l'utente è attivo o si tratta di qualcuno che lo sta emulando. Chiamiamo le due parti Host A (noi) e Host B (interlocutore):

1. L'host B invia all'host A un messaggio in chiaro identificandosi;
2. L'host A invia un messaggio, a caso, R all'host B;
3. L'host B usa la chiave simmetrica K_A-B per cifrare R e rimandarlo ad A;
4. L'host A decifra il messaggio ricevuto ed autentica l'host B.

AP v5.0
Il funzionamento dell'AP v5.0 è molto simile al 4.0 tranne per il fatto che vengono usate le chiavi pubbliche invece della chiave simmetrica:

1. L'host B invia all'host A un messaggio in chiaro identificandosi;
2. L'host A invia un messaggio, a caso, R all'host B;
3. L'host B usa la chiave privata K_B^- per cifrare R e rimandarlo ad A;
4. L'host A decifra il messaggio ricevuto uted autentica l'host B.

Il problema in questo scenario è dovuto al fatto che è possibile che avvenga un attacco chiamato attacco dell'uomo-in-mezzo, in cui un utente malintenzionato potrebbe interporsi tra l'host A e l'host B, falsificando i messaggi in modo tale da rendere trasparente l'operazione agli host stessi.

Lezione 4 - Integrità
Contrariamente al mondo reale, dove possiamo apporre la nostra firma a qualsiasi forma di documento, per certificare determinati messaggi elettronici dobbiamo usare una firma elettronica, una tecnica di crittografia per raggiungere l'autenticazione nel mondo digitale.
Le caratteristiche principali di una firma devono essere la verificabilità, la non falsificabilità e la non repudiabilità. Questo sta a significare che bisogna provare che un documento è stato firmato da quella persona e solamente da quella.

Generare Firme Digitali
Usando delle chiavi pubbliche, per generare firme digitali in grado di certificare un documento è possibile usare la propria chiave privata K_B^- (generalmente usata per decifrare i messaggi ricevuti) per firmare un documento, + in modo tale che l'utente che lo riceve possa applicare la chiave pubblica per verificare in modo univoco il mittente, questo perchè K_B⁺(K_B^-(m)) = m; questo ovviamente supposto di tenere segreta la propria chiave privata e la possibilità per il destinatario di recuperare la chiave pubblica.

Il Digest di un messaggio
Cifrare un messaggio per intero potrebbe essere molto dispendioso in termini di risorse, ed è per questo che si preferisce creare un digest (simile al Checksum o al CRC) che poi sarà sottoposto all'operazione di firma con la nostra chiave privata. Questo accade perchè un digest non è altro che una funzione hash H(m) che genera un risultato, di lunghezza finitia, che identifica univocamente (o quasi) il contenuto del messaggio. Accade quindi che, se qualcono volesse modificare il messaggio m in un messaggio m^I, dovrebbe far si che K_B^-(H(m)) = K_B^-(H(m')), cosa molto difficile, anzi quasi impossibile considerando tempi utili all'intruso per fare la modifica senza che una delle due parti (mittente o destinatario) si insospettiscano riguardo al messaggio.

Algoritmi di funzioni Hash
Come detto, un digest non è altro che una funzione Hash che da un messaggio genera una stringa alfanumerica di lunghezza finita identificativa del messaggio. Il problema sta appunto nella possibilità che esistano due messaggi (IMHO di senso compiuto) che generino lo stesso risultato quando applicata la stessa funzione hash; sarebbe falso dire che ciò non può accadere, ma è altrettanto vero che accade raramente e solamente con alcuni funzioni hash di semplice risoluzione.
In ambito informatico è molto famoso (e sta prendendo piede) una funzione hash a 128-bit chiamata MD5 (aggiunta di zero padding, aggiunta di un valore a 64-bit identificativo della lunghezza del messaggio, l'inizializzazione di un accumulatore e una procedura ripetitiva che esegue quattro operazioni su blocchi di 16-bit) con una possibilità di operazioni di 2⁶⁴ ed una possibilità che due messaggi con lo stesso digest abbiano senso compiuto di 2¹²⁸.
Famoso è anche l'SHA-1 (variante dell'MD4) che produce un digest di almeno 160-bit e, quindi, apparentemente più sicuro dell'MD5.

Ecco quindi uno dei metodi più sicuri per certificare e cifrare un messaggio di posta, ammesso che mittente e destinatario conoscano le proprie chiavi private e le rispettive chiavi pubbliche.



Lezione 5 - Distribuzione e certificazione delle chiavi
Come abbiamo esposto fino ad ora, usando le chiavi simmetriche e quelle pubbliche si è quasi assolutamente sicuri di poter autenticare e cifrare un messaggio; il problema sta, quindi, nella distribuzione delle chiavi, ovvero, chi assegna le chiavi? dove sono reperibili le chiavi pubbliche? è possibile falsificare i propri dati durante la registrazione? Queste sono tutte problematiche che possono essere risolte grazie a degli intermediari certificati; Per le chiavi simmetriche gli intermediari sono chiamati Key Distribution Center (KDC), per le chiavi pubbliche ci si avvale delle Certification Authority (CA).

KDC
Il KDC è un server che condivide una chiave simmetrica differente per ogni utente; il KDC conosce la chiave di ogni utente ed ogni utente comunica in modo sicuro con il KDC. Ammettiamo che L'utente A conosca la propria chiave K_A-KDC e l'utente B la chiave K_B-KDC rispettivamente. Ecco come si procede nella comunicazione:

1. L'utente A comunica in modo sicuro con il KDC e dice di voler comunicare con l'utente B;
2. Il KDC, conoscendo K_A-KDC decifra K_A-KDC(A, B) e genera un numero casuale R1. Questo valore sarà la chiave simmetrica delle future comunicazioni, generalmente chiamata chiave a sessione unica. Il KDC invia ad A, non solo il valore R1, ma anche una coppia di valori X e R1 cifrati con la K_B-KDC, ovviamente cifrando il tutto con la chiave K_A-KDC;
3. L'utente A riceve il messaggio dal KDC, decifra, ed estrae R1 dal messaggio, inoltre l'utente A estrae K_B-KDC(X, R1) e lo invia all'utente B;
4. L'utente B riceve il messaggio da l'utente A e lo decifra con la propria chiave K_B-KDC ed estrae X e R1; adesso conosce la chiave simmetrica e può procedere alla comunicazione con l'utente A, eventualmente usando R1 per autenticare l'utente A.

CA
Il problema nell'uso di chiavi pubbliche è che bisogna essere sicuri che la chiave pubblica che si sta usando sia solo e solamente di quel determinato utente, e che nessuno possa, anche volendo, spacciarsi per esso. Per questo esisto le certification authority (CA), il cui lavoro è quello di validare l'identità usando dei certificati; ecco le regole principali di un CA:

1. Un CA verifica che un utente è chi dice di essere; ciò può essere fatto in molti modi, in modo professionale oppure meno professionale. Ovviamente per un'azienda che lavora nel campo, la fiducia degli utenti è molto importante, e più è "professionale" il CA (magari a livello di istituzione statale), maggiore fiducia vi ripongono gli utenti.
2. Una volta verificata l'identità il CA crea un certificato che contiene informazioni riguardo alla chiave pubblica ed ai dati personali dell'utente.

A questo punto più sicuro e più è pubblicizzato l'ente che rilascia tali chiavi, maggiori sono le possibilità che qualcuno confidi nella nostra identità; una volta in possesso della chiave pubblica, l'utente può inviare/ricevere messaggi con esso sicuro del fatto che sta parlando in modo univoco con quell'utente.
Per dovere di cronaca segnialiamo la formattazione di un messaggio secondo la RFC 1422 ratificata dall'ITU (International Telecommunication Union) e dall'IETF e conosciuta come X.509.

Nome del Campo	Descrizione
Versione	numero della versione delle specifiche dell'X.509
Numero di serie	identificatore unico per un certificato
Firma	specifica l'algoritmo usato dal CA per firmare il certificato
Emittente del nome	Identità del CA che pubblica il certificato (in formato DN)
Periodo di validità	Inizio e fine del periodo di validità del certificato
Nome del soggetto	Identità la cui chiave è associata con il certificato (formato DN)
Chiave pubblica	La chiave pubblica del soggetto e l'algoritmo da usare con essa

Lezione 6 - Email Sicure
con questo tecnica viene mantenuta la riservatezza, l'autenticazione e l'integrità del messaggio.

PGP (Pretty Good Privacy)
Il PGP, inventato da Phil Zimmermann nel 1991, esegue le stesse operazioni dello schema soprastante, usando MD5 o SHA per il digest, CAST, 3DES o IDEA per la chiave simmetrica e l'RSA per la chiave pubblica; inoltre il PGP esegue la compressione dei messaggi. La differenza sostanziale è che le chiavi pubbliche non sono soggette a particolare regolamentazione, anzi sono gli altri utenti che certificano le chiavi pubbliche di conoscenti con le proprie chiavi private, oppure pubblicando direttamente la propria chiave su un sito o su un Server di chiavi pubbliche PGP.