Risposte seconda verifica - a.a. 2011-2012

Prima parte

• 1 - Alice estrae due numeri casuali scelti in modo opportuno (un n. primo ed una sua radice primitiva) e da questi deriva due altri numeri (anch'essi un pò a caso) che corrispondono alle proprie chiavi pubblica e privata. Comunica quindi a Bob sia i due numeri iniziali, che la propria chiave pubblica; Bob a sua volta determina (dalla stessa coppia casuale dell'altro) una coppia di chiavi, e comunica quella pubblica ad Alice. Ora sia Bob che Alice possono determinare uno stesso terzo numero, che sarà il segreto condiviso o chiave di sessione da usare nell'ambito di un algoritmo crittografico simmetrico. In realtà, una delle due parti estrae a questo punto una chiave più idonea per l'algoritmo simmetrico, e la trasmettette crittografata con il segreto condiviso ottenuto mediante lo scambio di DH.
• 2 - Salvando le password in forma crittografata ci si tutela dall'eventuale violazione del server e conseguente sottrazione delle password in chiaro. Anche se, per evitare attacchi a forza bruta, il metodo crittografico deve essere sufficientemente robusto. Allo stesso tempo però, ci si obbliga a svolgere l'autenticazione del client mediante la ricezione della password in chiaro, a meno di non replicare la forma crittografata della password, per tutti i possibili metodi crittografici supportati
• 3 - i certificati X.509 contengono l'identità (nel formato common name) del soggetto certificato e certificante, la chiave pubblica del soggetto certificato, e (oltre ad altri dettagli) la firma digitale apposta dalla autorità di certificazione, prodotta mediante la chiave privata della stessa.
  
• 4 - in un certificato auto-firmato il soggetto certificato e certificante è lo stesso, e tipicamente è usato per distribuire la chiave pubblica della autorità di certificazione, che si firma da sola
  
• 5 - il TLS offre un servizio di autenticazione, di confidenzialità, di integrità e di non repudiabilità.
  
• 6 - per ottenere l'autenticazione (e la non repudiabilità) occorre che chi riceve il certificato dell'altra parte possieda il certificato della CA che ha firmato il certificato della controparte
  
• 7 - dato che l'autenticazione si limita all'host, per autenticare un utente questi dovrà fornire le proprie credenziali (password), che possono essere ora trasmesse in chiaro, essendo il collegamente criptato dal TLS
  
• 8 - possiamo citare l'SMTP esteso, qualora faccia uso dell'estensione STARTTLS, che lo avvia dopo una prima fase in chiaro. Inoltre, possiamo citare l'HTTPS, che usa una diversa porta di trasporto, e che inizia l'handshake protocol del TLS non appena la connessione TCP è instaurata

• 9 - un documento HTML consiste in un file contenente un linguaggio di makup interpretato da un web browser, ed utilizzato per descrivere le diverse classi sintattiche (nel campo semantico della tipografia) del contenuto testuale del documento, e che costituisce il modo in cui sono rappresentate le informazioni accessibili tramite il word wide web
• 10 - un elemento <a> (anchor) può contenere un attributo href che indica la URI accessibile cliccando il testo con tag <a>
  
• 11 - un documento CSS consiste in un insieme di selettori a cui sono associate delle regole, attivate per modificare le proprietà di visualizzazione degli elementi HTML descritti mediante la sintassi dei selettori. Ha la funzione di rendere il progetto dell'aspetto indipendente da quello dei contenuti, e facilita l'uniformità di visualizzazione dei diversi contenuti di un sito
• 12 - a livello protocollare, la redirezione è consentita dalla risposta HTTP di tipo 302, nelle cui intestazioni si può trovare l'elemento sintattico Location (espresso come header HTTP) mediante il quale è individuata la nuova URI della risorsa
• 13 - la ricezione della intestazione HTTP di risposta Content-Type determina nello UserAgent l'invocazione della helper application più idonea all'utilizzo (visualizzazione, riproduzione) del body trasportato dalla risposta HTTP, operazione eventualmente espletata dal browser stesso, oppure per il tramite di plugin
• 14 - il Basic Access Authentication dell'HTTP permette al client di autenticarsi mediante un paradigma sfida-risposta, in cui però le credenziali vengo trasmesse in chiaro - o meglio, codificate con una semplice rappresentazione base64
  
• 15 - un programma CGI può ricevere il valore dei parametri formali relativi alla sua invocazione accedendo alle variabili di ambiente, in cui trova la querystring contenuta nella URI referenziata mediante il metodo GET, oppure accedendo al body della richiesta, leggendo da STDIN, se la richiesta adotta il metodo POST. La risposta viene quindi stampata su standard output, preceduta dalla indicazione del Mime Type corretto, e consegnata per il tramite del server web al client nel body della risposta HTTP
• 16 - un cookie HTTP è il valore assegnato mediante un apposito header contenuto nella risposta HTTP, e che viene restituito intatto nelle successive richieste dallo stesso browser verso lo stesso server, in modo che quest'ultimo possa ricevere una chiave che gli permetta di risalire all'ultimo stato della sessione sviluppata dal medesimo utente
• 17 - un feed RSS è un file in formato XML che viene restituito via HTTP in corrispondenza di una determinata URI, ed è utilizzato per descrivere diversi contenuti, mediante un sommario, dei tag che li catalogano, ed una URI per accedere ai diversi documenti. Può essere usato come sommario dei contenuti di un sito ad aggiornamento frequente, come ad esempio un blog, o per includere i contenuti di un sito in un altro
  
• 18 - una Content Delivery Network risolve il problema di dover fornire uno stesso contenuto ad un numero molto elevato di client in contemporanea. E' realizzata mediante una schiera di server-replica (o surrogati) distributi geograficamente in giro per il mondo, che detengono una copia degli oggetti da restituire, e verso i quali viene instradata la richiesta originariamente diretta verso la URI di riferimento per quella risorsa; il surrogato viene scelto in modo da essere il più vicino al client, minimizzando così anche l'uso di risorse trasmissive a lunga distanza
  

• 19 - un Registrar SIP che riceve una richiesta con il metodo REGISTER memorizza l'associazione tra AoR e Contact per una URI SIP; quando in seguito riceve una richiesta con il metodo INVITE, può inoltrare la richiesta stessa allo UA che aveva registrato l'AoR
• 20 - il Registrar SIP di un determinato dominio viene individuato mediante la richiesta al DNS del RR di tipo SRV _sip._proto per quel dominio, in cui proto = udp | tcp
  
• 21 - quando uno UAC riceve una risposta provvisoria 1xx cessa di re-inviare la richiesta UDP a cui la risposta si riferisce. Inoltre, notifica (mediante un callback) l'applicazione dell'evento, in modo che ad es. venga riprodotto un tono di libero
• 22 - i parametri multimediali sono negoziati mediante la sintassi veicolata dal body SDP contenuto nell'offerta, ossia la richiesta INVITE, e nelle risposte associate, e consistono nel tipo di media (audio, video, tasti), nel formato (ossia il codec audio/video), il Payload Type RTP corripondente, e la porta RTP su cui si intende ricevere il media
• 23 - la RFC 3551 Audio Video Profile di RTP descrive il formato di pacchettizzazione dei diversi formati multimediali, definendo la sintassi del bitstream corrispondente e come le ADU sono suddivise nei payload RTP, e fornisce l'indicazione di alcune implementazioni di riferimento, almeno per un insieme di Payload Type di base
  
• 24 - l'RTCP diretto dal destinatario alla sorgente di un flusso RTP veicola essenzialmente le informazioni relative al jitter con cui sono ricevuti pacchetti, e la percentuale di paccheti persi dall'ultimo rapporto
• 25 - l'RTCP con direzione opposta invece fornisce informazioni aggiuntive sulle sorgenti multimediali, individuate dall'SSRC corrispondente, come un nome da sovraimprimere all'immagine ricevuta in videoconferenza, ed una email di riferimento. Inoltre, consente di sincronizzare tra loro più flussi (ad es audio e corrispettivo video) indicando la corrispondenza per ognuno di essi tra timestamp RTP e timestamp NTP
  
• 26 - un server STUN permettere ad un computer nattato di venire a conoscenza dell'IP pubblico del proprio NAT, e della porta che questo usa in corrispondenza ad una determinata porta dell'host nella LAN locale. Viene usato per impostare coerentemente il contact e la porta espressi dall'SDP, in modo che il corrispondente invii il media all'IP pubblico del NAT, e quest'ultimo lo inoltri allo UA corretto. Il tutto funziona purché il NAT NON sia di tipo simmetrico, e l'RTP sia di tipo simmetrico.