Sei sulla pagina 1di 35

Sicurezza delle applicazioni di rete 

Situazione standard 

Oggi si considera la situazione standard, ovvero il modo in cui gli sviluppatori creano le applicazioni di 
rete, una situazione abbastanza negativa, questo per i seguenti motivi : 
¾ autenticazione ed autorizzazione basate su username e password 
¾ ne  deriva  un  problema  legato  principalmente  alle  reti  e  al  modo  in  cui  esse  sono 
organizzate, infatti quei dati sono potenzialmente sniffabili in rete: password snooping 
 
¾ autenticazione  basata  su  indirizzo  IP  (  questa  è  possibile  farla  ad  esempio  nel  caso  dei  server 
web, o anche nel caso della suite di comandi R come rsh, rlogin, rcp, ...) 
¾ in questo caso il problema sarebbe comunque l’IP spoofing 
 
¾ Anche  a  voler  implementare  il  meccanismo  più  sicuro,  rimangono  sicuramente  problemi  di 
carattere generale, come: 
¾ data snooping / forging 
¾ shadow server / MITM 
 
Per cercare di risolvere i problemi appena citati, presentiamo alcuni approcci possibili. 

Sicurezza di canale 

Questo  approccio  consiste  nel  proteggere  i  dati  nel  momento  in  cui  transitano  all’interno  del  canale. 
Come  vediamo  i  due  nodi  che  vogliono  comunicare  dei  dati  che  sono  indicati  in  rosso  (quindi  dati 
sensibili e che devono essere opportunamente protetti) decidono di comunicare tra loro attraverso un 
canale  protetto.  In  questo  senso  notiamo  che  non  solo  vengono  solo  protetti  i  dati  in  rosso,  ovvero 
quelli che i due nodi intendevano scambiarsi, ma anche i dati che casualmente si trovano a transitare su 
quel canale, perché la proprietà di sicurezza non è un attributo dei dati bensì un attributo del canale di 
trasmissione.  Notiamo  anche  che  essendo  la  sicurezza  una  proprietà  del  canale,  una  volta  che  i  dati 
escono e arrivano al nodo destinazione ritornano ad essere dei dati non protetti e quindi con tutte le 
problematiche che conosciamo. In una situazione di questo tipo,abbiamo le seguenti possibilità: 

9 autenticazione  (singola  o  mutua,  perché  il  canale  si  crea  prima  di  trasmettere  i  dati  quindi  se 
una delle due parti non si autentica noi ci possiamo anche rifiutare di aprire il canale), integrità e 
segretezza solo durante il transito nel canale 
9 nessuna  possibilità  di  non  ripudio,  infatti  il  non  ripudio  è  di  solito  qualcosa  di  inerente  i  dati. 
Notiamo  che  nel  momento  in  cui  il  destinatario  estrae  i  dati  dal  canale,  avrà  la  certezza  che 
arrivino dalla controparte, che siano integri ma non lo può provare a terzi!  
9 richiede poca (o nulla) modifica alle applicazioni 

 
Sicurezza di messaggio (o dei dati) 

Questo approccio consiste nel prendere i dati  che  intendiamo proteggere ed incapsularli  all’interno di 


una  busta  sicura.  A  voler  dare  un’idea  pratica  di  quanto  stiamo  dicendo,  potremmo  dire  che  la  prima 
soluzione vista la possiamo realizzare con un tunnel sicuro (quindi IPsec) mentre la soluzione corrente 
potrebbe essere realizzata sfruttando il formato PKCS‐7 che per l’appunto ci permette di realizzare una 
busta sicura. Il concetto che deve essere chiaro è che ogni singolo dato che deve essere protetto viene 
protetto  singolarmente  e  deve  essere  protetto  dal  mittente.  Quindi  visto  che  il  mittente  opera  in 
completa  autonomia,  andiamo  a  perdere  l’autenticazione  eventuale,  cioè  non  è  possibile  alcuna 
negoziazione preventiva prima di iniziare la trasmissione. Abbiamo un vantaggio derivante dal fatto che 
proteggiamo solo quello che veramente ci interessa proteggere. A questo punto è veramente possibile il 
non ripudio, in quanto il mittente avrà preso i dati di partenza e li avrà trasformati applicando ad essi 
tutta una serie di attibuti sulla base delle esigenza che aveva (es. voleva riservatezza e li ha cifrati, voleva 
autenticazione ed integrità e avrà messo un keyed‐digest, voleva il non ripudio allora avrà apposto una 
firma  digitale  con  tanto  di  certificato  emesso  da  una  CA  ufficialmente  riconosciuta).  In  questo  senso  i 
dati  che  arrivano  al  destinatario  sono  dei  dati  diversi  rispetto  a  quelli  di  origine.  Quindi  volendo 
riassumere: 

9 autenticazione (singola), integrità e segretezza auto‐contenute nel messaggio 
9 possibilità di non ripudio 
9 richiede  modifica  alle  applicazioni  :  in  quanto  o  modifichiamo  l’applicazione  in  modo  che 
applichi le misure di sicurezza che vogliamo o dovremo realizzare un applicativo che a partire dai 
dati di origine li incapsuli in una busta sicura seguendo il formato PKCS‐7 ad esempio 

L’ultimo motivo, ovvero il fatto che richiede modifica alle applicazioni, è anche la motivazione base per 
cui  questa  soluzione  non  è  quella  diffusamente  adottata.  Ad  oggi  infatti,  la  tendenza  diffusa  delle 
aziende  è  quella  di  delegare  la  sicurezza  ai  livelli  bassi,  ovvero  alla  rete,  quindi  nonostante  la  prima 
soluzione  on  sia  proprio  quella  ottimale  in  quanto  non  mi  permette  di  avere  il  non  ripudio,  non  mi 
permette  di  sapere  se  i  dati  sono  stati  protetti  al  livello  applicativo,  è  comunque  quella  più  usata. 
Ovviamente è anche possibile fare un mix delle due soluzioni appena viste. 

Sicurezza interna alle applicazioni 

Quindi  in  origine  il  problema  ricadeva  nelle  mani  degli  sviluppatori,  ovvero 
ogni  sviluppatore  che  volesse  integrare  la  sicurezza  nell’applicazione  che  si 
accingeva  a  creare,  doveva  crearsi  le  proprie  routine  o  le  proprie  classi  per 
cifrare  i  dati  e  garantire  determinate  proprietà  di  sicurezza.  Ovviamente, 
questa situazione veniva ad essere replicata per ogni sviluppatore, quindi la 
parte  in  comune  che  rimaneva  era  quella  di  rete,  in  quanto  nessuno  si 
sfruttavano i socket che costituiscono un’astrazione logica, e questo faceva sì 
che  ci  fosse  qualcosa  che  venisse  messo  a  fattor  comune.  Quindi  tante 
persone  si  sono  messe  a  cercar  di  risolvere  questo  problema  pensando  alla 
loro singola applicazione e per qualche anno, gli sviluppatori delle singole applicazioni hanno pensato a 
dei  metodi  ad  hoc  per  rendere  sicura  la  loro  applicazione.  In  questa  situazione  in  cui  la  sicurezza  è 
selezionata internamente ad ogni singola applicazione, abbiamo vantaggi e svantaggi. Il vantaggio è che 
ogni  applicazione  pensa  da  sé  a  realizzare  la  sicurezza  e  quindi  il  problema  se  così  si  può  dire  è 
demandato all’applicazione e quindi la parte comune è relativa a sua volta alla parte bassa dello stack di 
rete,  ma  fare  sicurezza  non  è  semplice  e  quindi  sono  possibili  tantissimi  errori  di  implementazione: 
infatti è possibile anche che qualcuno capisca la funzione ma sbagli a realizzarla. Altro grosso problema 
che  per  anni  è  stata  una  macchia  nera  nel  campo  della  sicurezza  è  che  questa  strada  non  garantisce 
l’interoperabilità (a meno che non fosse stato lo stesso sviluppatore a realizzare entrambe le entità che 
dovevano  comunicare  tra  loro).  Quindi  volendo  riassumere  in  modo  molto  sintetico,  per  questa 
soluzione i seguenti punti sono fondamentali: 

¾ ogni applicazione implementa la sicurezza al proprio interno 
¾ la parte in comune si limita ai canali di comunicazione (socket) 
¾ possibili errori di implementazione (inventare protocolli di sicurezza non è semplice!) 
¾ non garantisce l’interoperabilità 
 
Si è quindi pensato di estendere il concetto di socket in modo da realizzare un canale logico sicuro.   
 
Sicurezza esterna alle applicazioni 
 
La situazione è cambiata quando qualcuno ha avuto l’idea di seguire il concetto 
logico  dei  socket  estendendoli  in  modo  da  realizzare  un  canale  logico,  ma 
sicuro.  Quindi  quelle  applicazioni  che  vogliono  dare  un  vero  valore  alla 
sicurezza  e  che  riconoscono  che  ralizzare  pratiche  di  sicurezza  è  un  lavoro 
estremamente  difficile,  usano  i  socket  sicuri.  Ma  a  questo  punto  sorge  un 
problema  di  carattere  esistenziale:  nel  TCP/IP  non  esiste  il  livello  sessione, 
infatti sono distinti il livelli fino al 4 (ricordiamo sono fisico (1), datalink (2), rete 
(3), trasporto (4) ) dopodiché il 5,6 e 7 sono fusi in un tutt’uno che poi è quello 
che  viene  trattato  dalle  applicazioni.  Se  uno  esaminasse  in  dettaglio  la  pila 
ISO/OSI si accorgerebbe infatti che il livello sessione è quello in cui andrebbero 
concentrate  la  maggior  parte  delle  funzionalità  di  sicurezza  canale  in  quanto 
una sessione altro non è che un canale logico! Quindi si è posto riparo a questo problema inventando un 
livello  sessione  sicura  (perché  di  fatto  la  sessione  non  sicura  non  esiste)  ed  è  una  piccola  estensione 
sopra i socket. Ovviamente, da questa scelta di proporre un livello “sessione sicura” derivano una serie 
di vantaggi:  
 
9 abbiamo  semplificato  il  lavoro  degli  sviluppatori  applicativi  (infatti  cambia  che  nella  fase  di 
apertura  del  canale  dovremo  fornire  alle  primitive  dei  parametri  aggiuntivi  per  dire  quali 
funzionalità di sicurezza vengano aggiunte alla nostra applicazione, ma una volta fatto questo le 
write e le read funzioneranno in modo del tutto trasparente) 
9 evitiamo possibili errori di implementazione 
9 poiché  non  abbiamo  modificato  lo  stack  (infatti  quello  che  è  stato  fatto  è  creare  un  piccolo 
strato  che  copra  il  socket  solo  parzialmente),  esiste  ancora  la  flessibilità,  in  quanto  la  strada 
proposta  non  è  detto  che  debba  necessariamente  essere  scelta:  la  scelta  è  a  discrezione 
dell’applicazione. Se qualcuno pensa infatti che la libreria che lui ha sviluppato in proprio per la 
sua  applicazione  è  sicuramente  migliore,  potrà  continuare  ad  usarla  (caso  dell’applicazione  a 
destra in figura) 
 
Questa ad oggi è la soluzione che va per la maggiore, e in particolare sono state sviluppate tre librerie o 
protocolli per implementare questo tipo di soluzione. 
 
Protocolli di sicurezza orientati al canale di comunicazione 
 
Queste tre soluzioni le elenchiamo qui di seguito: 
 
1. SSL / TLS 
o SSL,  che  è  stato  successivamente  rinominato  in  TLS,  è  sicuramente  il  più  diffuso  al 
mondo 
2. SSH 
o Il principale competitor di SSL è stato proprio questo, e ha avuto un momento di gloria 
soprattutto per quei problemi di politiche di esportazione che erano state imposte dagli 
USA. Infatti SSH è stato sviluppato in Finlandia, mentre SSL non si riusciva ad averlo in 
versione  “forte”.  Da  quando  le  limitazioni  sull’esportazione  di  materiale  crittografico 
sono state rimosse, e anche SSL è stato liberalizzato, SSH è diventato una soluzione di 
nicchia 
3. PCT 
o È stato proposto da Microsoft come alternativa a SSL 
o nessuno lo ha implementato tranne Microsoft stessa, quindi Microsoft stessa a partire 
da Explorer 5 lo ha cancellato dai propri prodotti 
 
Di queste tre, iniziamo con SSL in quanto come già detto è la soluzione più diffusa al mondo. 
 
SSL (Secure Socket Layer) 

Lo troviamo nella maggior parte delle applicazioni, e in tutte le salse, non soltanto collegato con il web. 
Come  vediamo  è  stato  proposto  da  Netscape  Communications,  ed  implementa  un  protocollo  di 
trasporto sicuro (circa livello sessione, non è infatti né un livello 4 né propriamente un livello 5 in quanto 
come già detto nella realizzazione dello stack TCP/IP non esiste, quindi siccome è comunque utile, sta lì, 
da qualhe parte).  Quando apriamo un canale SSL o TLS quello che otteniamo sono le seguenti proprietà: 

o autenticazione : va intesa come peer autentication, autenticazione delle parti che instaurano il 
canale.  Infatti  di  default  l’autenticazione  è  del  server,  mentre  è  opzionale  che  il  server  chieda 
l’autenticazione al client. Questo se ci pensiamo bene è qualcosa molto strano, in quanto le cose 
al  livello  logico  dovrebbero  essere  invertite.  In  realtà,  SSL  è  stato  inventato  per  proteggere  il 
commercio  elettronico  dove  la  cosa  più  importante  è  autenticare  il  server.  E’  per  questo  che 
l’opzione di default è quella ed è irremovibile : non si può configurare SSL per non autenticare il 
server,  in  quanto  quello  è  il  default.  Opzionalmente  si  può  richiedere  anche  al  client  di 
autenticarsi 
 
o riservatezza  dei  messaggi  :  tutti  i  canali  che  vengono  trasmessi  su  un  canale  SSL  sono  cifrati. 
Nelle  versioni  più  recenti  la  riservatezza  può  anche  essere  di  soli  zero  bit,  quindi  è  anche 
possibile  NON  AVERE  RISERVATEZZA.  Questo  dipende  dalla  configurazione  del  cliente  e  del 
server,  ed  è  stato  fatto  principalmente  perché  la  parte  di  cifratura  simmetrica  è  comunque 
pesante quindi per tutte le applicazioni che non necessitano di questa proprietà di sicurezza è 
anche possibile rimuoverla richiedendo di fare riservatezza usando l’algoritmo NUL che richiede 
una chiave da zero bit 
 
o autenticazione ed integrità dei messaggi : questa è ancora una volta una proprietà inamovibile, 
e  sottolinea  il  fatto  che  autenticazione  e  integrità  sono  molto  più  importanti  in  generale  della 
riservatezza (ricordiamoci quanto detto dai militari secondo i quali solo il 10%‐20% dei messaggi 
che  loro  trasmettono  hanno  bisogno  si  riservatezza,  mentre  il  100%  hanno  bisogno  di 
autenticazione e integrità) 
 
o protezione  da  replay  e  da  filtering  :  trattandosi  di  un  ambiente  di  rete  e  quindi 
fondamentalmente  insicuro,    si  applica  anche  la  protezione  da  replay  (ritrasmissione  di 
pacchetti) e da filtering (ovvero cancellazione dei pacchetti). Degno di nota è che nel caso venga 
rilevato  un  attacco  di  replay  o  di  filtering,  la  reazione  è  quella  di  chiudere  il  canale  con 
conseguente blocco dell’applicazione. Questo significa che chi ci fa un attacco di quel tipo non 
riesce a farci fare qualcosa che non prevedevamo, ma riesce sicuramente a farci un Denial‐of‐
Service. Questa non è da considerare una nota di demerito di SSL, ma è un problema generale 
delle  comunicazioni  in  rete:  in  ogni  caso  infatti  chi  gestisce  l’infrastruttura  di  comunicazione 
potrebbe impedire le comunicazioni se solo lo volesse. 
 
SSL essendo collocato a questo livello “4 e mezzo”, non dipende da una specifica applicazione. E’ stato 
pensato  così  bene  che  si  adatta  facilmente  ad  un  qualunque  protocollo  applicativo  che  si  basi  su  un 
canale  affidabile.  Notiamo  che  non  c’è  niente  dentro  SSL  che  dice  che  SSL  si  usa  con  TCP  :  se  noi 
avessimo  un  altro  protocollo  al  livello  di  trasporto  affidabile  lo  potremmo  usare  anche  con  quello. 
Ovviamente oggi TCP va per la maggiore, quindi alla fine SSL è applicabile facilmente a tutti i protocolli 
applicativi basati su TCP, come ad esempio HTTP, SMTP, NNTP, FTP, TELNET. Ad es. famoso HTTP sicuro 
(https non è un protocollo, ma è una URL, una abbreviazione per dire che vogliamo http sopra SSL!!!), 
che opera alla porta 443/TCP. 

Porte ufficiali per applicazioni SSL 
 
Qui vedete l’elenco di tutte le porte ufficiali che sono state riservate per l’uso delle versioni protette con 
SSL dei maggiori protocolli, quindi esattamente come si ha per https 443/tcp, abbiamo smtps 465/tcp a 
posto della classica porta 25. Questo perché c’è differenza tra usare la versione normale e la versione 
sicura. 

SSL ‐ autenticazione e integrità 

Vediamo come SSL realizza le funzioni che abbiamo presentato.  All’atto dell’apertura del canale viene 
fatta la peer authentication. Il server si presenta con un proprio certificato X.509 valido perché il client lo 
sottoporrà ad una sfida di tipo asimmetrico. Per quanto riguarda l’autenticazione e l’integrità, dobbiamo 
distinguere la peer authentication dalla data authentication: 

1. Per  la  peer  authentication  siccome  si  deve  autenticare  prima  il  server,  il  server  si  autentica 
presentando la propria chiave pubblica all’interno di un certificato X.509:  
o un  server  per  essere  un  server  SSL  deve  possedere  chiave  privata  e  chiave  pubblica  e 
deve avere la chiave pubblica certificata (le chiavi pubbliche non si possono mandare in  
giro così e devono essere all’interno di un certificato).  
o Ovviamente al server non basta mandare il certificato per dimostrare la propria identità 
ƒ quando qualcuno manda ad un utente il proprio certificato, l’utente gli manda 
una  sfida  asimmetrica  per  vedere  che  lui  possiede  la  chiave  privata 
corrispondente alla pubblica che gli ha fornito.  
2. Il server una volta autenticatosi ha la possibilità di chiedere al client di autenticarsi: 
o questo  step  è  opzionale  ed  è  controllato  dal  server,  infatti  l’unico  schema  di 
autenticazione  supportato  da  SSL  è  quello  dei  certificati  quindi  può  anche  darsi  che  il 
client  non  possieda  un  certificato  X.509,  nel  qual  caso  non  sarebbe  possibile  per  lui 
collegarsi al server. 
ƒ quando  ci  colleghiamo  al  portale  della  didattica  il  server  ci  chiede  di  dargli  il 
nostro certificato 
ƒ noi non ce l’abbiamo e gli diciamo di andare avanti lo stesso e di conseguenza il 
server ci chiede username e password 
ƒ per  alcuni  docenti  che  hanno  il  certificato  è  possibile  entrare  direttamente 
senza digitare username  e password, poiché si viene riconosciuti direttamente 
dal certificato.  
ƒ Quello del portale della didattica è un server web con client authentication.  
• Esso chiede se il client ha un certificato e se ha questo certificato gli fa la 
sfida e se viene superata correttamente il client può entrare.  
• Questa  fase  è  opzionale  poiché  la  diffusione  di  certificati  non  è  così 
grande poiché vi sono problemi nell’utilizzarli. La gente ha difficoltà nel 
gestire correttamente le password, figuriamoci con le chiavi private che 
sono anche solo concettualmente più complicate.  
o Una  volta  che  un  canale  SSL  è  stato  instaurato,  abbiamo  detto  che  altre  due  funzioni 
irremovibili  sono  autenticazione  e  integrità,  quindi  tutti  i  dati  vengono  protetti  per 
autenticazione  ed  integrità  tramite  keyed  digest.  In  particolare  lo  standard  definisce 
MD5 o SHA1 come algoritmi di hash di base con una chiave simmetrica concordata tra 
server  e  client.  In  più  per  evitare  la  cancellazione  e  il  replay  ogni  segmento  SSL  viene 
numerato  tramite  un  MID,  message  identifier  (quindi  in  questo  modo  non  è  possibile 
duplicare  o  cancellare  i  dati),  un  numero  progressivo.  Qui  a  differenza  di  quanto 
avevamo  detto  con  IPsec  in  cui  avevamo  precisato  che  poiché  IPsec  lavora  con  IP 
(servizio best‐effort senza garanzie di consegna né sull’ordine) non aveva la necessità di 
andare a numerare i pacchetti con 1,2,3 … ma li potevamo anche chiamare pippo,pluto, 
paperino…, qui invece sfruttando un protocollo di trasporto affidabile che mi garantisce 
consegna e ordine di consegna ha importanza che siano numeri e che siano progressivi! 
 
SSL – Riservatezza  
 
Per quanto riguarda la riservatezza, il client genera una session key quindi una chiave generata al volo 
possibilmente  mai  più  riutilizzata.  La  chiave  può  essere  comunicata  al  server  cifrandola  con  la  chiave 
pubblica  del  server  e  il  server,  che  ha  la  chiave  privata,  provvederà  a  decifrarla  e  da  lì  in  poi  client  e 
server  useranno  quella  chiave  per  la  cifratura  simmetrica  dei  dati  con  uno  degli  algoritmi  ammessi  da 
SSL (RC2, RC4, DES, 3DES o IDEA). Lo  scambio di  chiavi può anche essere  concordata sfruttando Diffie 
Hellman oppure Fortezza‐KEA  (il sistema proprietario dei militari americani ed è una variante di Diffie 
Hellman).  
 
SSL 
 

 
 
A questo punto vediamo come opera SSL, e l’esempio di applicazione pratica che si è deciso di usare è 
quello di un browser che desidera parlare con un server. In generale, vediamo a destra un client SSL e a 
sinistra un server SSL. Seguiamo a questo punto le interazioni: 
 
1. Innanzitutto bisogna che il client dica al server che desidera parlare SSL; questo viene fatto con 
la url https. 
2. Una volta che il client ha avvisato il server e sta parlando SSL, la prima operazione svolta dai due 
nodi è quella di scambiarsi la loro configurazione di sicurezza :  
o Per configurazione di sicurezza si intende che ognuno dei due dichiara gli algoritmi che è 
in grado di supportare. Si tratta di una negoziazione: lo standard prevede che i due nodi 
scelgano l’algoritmo più forte in comune tra di loro (sia che si parli di riservatezza a sia 
che si parli di autenticazione e integrità). Quindi gli algoritmi sono stati messi in scala di 
preferenza.  
o Può  capitare  che  in  questa  fase  i  due  nodi  non  trovino  niente  in  comune  fra  di  loro, 
quindi il collegamento si può interrompere già a questo livello.  
3. Una  volta  che  i  sistemi  hanno  trovato  una  configurazione  comune  il  primo  passo  è  quello 
dell’autenticazione  del  server.  Il  server  manda  il  proprio  certificato  che  deve  contenere  come 
common name (CN) o come subject alternative name di tipo DNSname lo stesso identificativo 
dell’applicazione a cui mi sto collegando. Poiché mandare il certificato come detto non serve a 
niente perché essendo un dato pubblico chiunque può copiarlo, il client gli invia una sfida a cui 
deve  rispondere  correttamente.  Se  il  server  non  risponde  correttamente,  il  collegamento  può 
essere interrotto a questo punto. 
4. Opzionalmente  (ecco  il  motivo  della  linea  tratteggiata  rappresentata  in  figura),  il  server  può 
chiedere  anche  al  client  di  mandare  il  certificato  X.509  e  di  rispondere  ad  una  sfida.  Anche  in 
questo caso se la sfida fallisce il collegamento viene interrotto. 
5. Se tutti questi passi hanno avuto successo il client e il server sono in grado di crearsi un canale 
sicuro sul quale gli attacchi  (frecce rosse) rimbalzeranno 
 
Esistono varie versioni di  SSL  (SSL‐2,  SSL‐3, TLS 1.0, TLS 1.1). Dal punto di vista architetturale il  grosso 
cambiamento  è  stato  introdotto  quando  si  è  passati  da  SSL‐2  a  SSL‐3.  Infatti  SSL‐2  era    un  protocollo 
molto  basilare,  mentre  SSL‐3  cominciava  a  diventare  un  protocollo  strutturato,  ben  fatto.  Infine  il  TLS 
aggiunge soltanto delle piccole modifiche e non cambia l’impianto.  
 
Architettura di SSL‐3 
 

 
SSL‐3, come vediamo, è stratificato sopra un protocollo di rete affidabile, quindi sopra questo (che ad 
esempio, come detto non è un vincolo, può essere TCP) vediamo il cosiddetto SSL Record Protocol, ossia 
un formato per trasportare dati da un capo all’altro del canale. Questo Record Protocol di SSL serve per 
“imbustare” i dati applicativi una volta che il canale è stato creato, ma viene anche utilizzato dal 
protocollo SSL nella prima fase, che è anche detta fase di handshake che viene quindi veicolata sopra il 
Record Protocol di SSL: l’ SSL Handshake Protocol è il protocollo con il quale ci si mette d’accordo su 
quali algoritmi andare ad usare. Quando capita che si verifichi un attacco SSL prevede un piccolo 
protocollo che serve per comunicare che si è verificato un errore. Questo protocollo prende il nome di  
SSL  Alert Protocol con cui client e server si scambiano gli allarmi. E’ anche possibile dirante una 
sessione SSL decidere di cambiare o gli algoritmi o le chiavi o entrambi, e questo lo si fa con l’SSL Change 
Cipher Spec Protocol. 
 
Architettura di SSL‐2 
 
SSL‐2  come  già  detto  è  un  protocollo  estremamente  più  semplice  in  quanto  non  prevede  gli  allarmi  e 
non prevede di cambiare in corso di trasmissione i parametri o gli algoritmi decisi in fase di scambi della 
configurazione di sicurezza. 
Session‐id 

Adesso  consideriamo  un  piccolo  problema.  L’introduzione  di  SSL  complica  non  poco  una  transazione 
Web.  

¾ 1. open, 2. GET page.htm, 3. page.htm, 4. close 
¾ 1. open, 2. GET home.gif, 3. home.gif, 4. close 
¾ 1. open, 2. GET logo.gif, 3. logo.gif, 4. close 
¾ 1. open, 2. GET back.jpg, 3. back.jpg, 4. close 
¾ 1. open, 2. GET music.mid, 3. music.mid, 4. close 
 
Infatti  tipicamente  aprendo  con  il  server  web  una  connessione  alla  porta  80  per  ottenere  la  pagina 
page.htm, quello che viene fatto è che il server ci trasmette la pagina,  e chiude (a meno di uso di http 
v1.1 che come sappiamo permette le connessioni persistenti). Nel momento in cui prova a visualizzare la 
pagina  si  accorge  che  manca  l’oggetto  home.gif,  quindi  aprirà  una  nuova  connessione  e  richiederà 
l’oggetto  home.gif,  e  anche  lì  una  volta  che  il  server  ci  ha  fornito  l’oggetto  chiuderà  la  connessione. 
Questo  discorso  vale  per  ogni  oggetto  che  compone  la  pagina.  Ma  se  per  ogni  oggetto  si  devono 
rinegoziare  parametri  crittografici  per  SSL  il  collegamento  si  appesantisce  molto.  Infatti,  la  fase  di 
negoziazione è l’unica in cui si utilizzano gli algoritmi asimmetrici che sono quelli più pesanti dal punto di 
vista computazionale, quindi andiamo a ripetere proprio la parte più pesante. Per evitare di rinegoziare 
ogni  volta  i  parametri  e  rifare  l’autenticazione,  e  quindi  appesantire  troppo  i  collegamenti,  è  stato 
introdotto il concetto di SSL Session Identifier. Si può cioè dire che ogni collegamento fa parte di una 
medesima sessione logica, ossia: 

• quando mi presento il server mi fornirà un numero, che sarà il Session Identifier, sottolineando 
il fatto che ha concluso con successo la transazione con noi  
• il  client  la  volta  successiva  il  client  potrà  fornire  questo  numero  identificativo  al  server  per 
sottolineare il fatto che già una volta hanno negoziato i parametri e si sono autenticati. Questa 
cosa  è  opzionale,  nel  senso  che  il  server  numera  sempre  tutte  le  sessioni,ma  se  vuole  può 
rifiutare  l’uso  del  Session  Identifier.  In  particolare  lo  può  rifiutare  in  assoluto,  quindi  rifiutarlo 
sempre,  oppure  anche  nel  caso  di  server  che  accetti  di  continuare  la  sessione  precedente 
potrebbe  non  accettare  il  Session  Identifier  dopo  un  certo  lasso  di  tempo.  Infatti,  i  Session 
Identifier  devono  essere  sempre  mantenuti  all’interno  di  una  tabella,  e  questa  potrebbe 
crescere  molto  in  dimensioni  qualora  il  server  ricevesse  tante  richieste  al  secondo.  Quindi  il 
suggerimento  è  accettare  il  Session  Identifier  ma  limitarne  la  validità  nel  tempo  in  modo  da 
avere anche  un meccanismo per poter sfoltire quella tabella. Lo  scopo non è  quello di evitare 
l’handshake nell’arco di giorni, o di un lungo periodo di tempo, bensì quando io mi presento a 
raffica come nel caso di una pagina web. Infatti quello che viene detto è che la vita di un session 
identifier dovrebbe essere limitata a qualche minuto. 

Qui di seguito riportiamo la figura che mostra il modo in cui cambia la fase di handshake nel caso in cui il 
server accetti l’uso del Session Identifier: 

 
SSL con session‐ID 

Notiamo che i passi sono i seguenti: 

1. Come sempre bisogna che il client dica al server che desidera parlare SSL; questo viene fatto con 
la url https. 
2. A  questo  punto,  ancora  prima  che  inizi  la  fase  di  scambio  della  configurazione  di  sicurezza,  il 
client fornisce al server il Session Identifier.  
3. Il  server  a  questo  punto  dirà  che  il  client  dichiara  di  avere  il  “lasciapassare”,  ma  potrebbe 
benissimo essere un impostore, che quindi ha scelto un numero a caso e ha indovinato, quindi 
se il client conosceva veramente il Session Identifier, e di fatto non ha solo avuto fortuna, allora 
puoi  farmi  le  tue  domande,  ma  me  le  dovrai  fare  su  un  canale  sicuro!  Il  che  significa  che  le 
domande devono contenere il keyed‐digest fatto con l’algoritmo giusto, con la chiave giusta, e i 
dati dovranno essere cifrati con l’algoritmo giusto e così via. Se il client era un impostore, allora 
non riuscirà a mettere i codici di protezione giusti e verrà quindi rifiutato.  
 
Quindi ancora una volta questa cosa mi permette al più di fare un DoS, ovvero terrò temporaneamente 
impegnato  il  server  per  controllare  i  dati.  Ma  poiché  il  keyed‐digest  è  la  prima  cosa  che  viene 
controllata, ed è anche quello più veloce da calcolare e quindi verificare, non appena quello non torna si 
chiude! 
 
Una piccola nota riguarda il fatto che lo scambio della configurazione di sicurezza avviene in chiaro, in 
quanto ancora non è stato creato il canale SSL, ma anche a voler conoscere gli algoritmi, non si sapranno 
comunque le chiavi da usare che verranno invece scambiate o concordate con uno degli algoritmi visti 
prima (RSA, DH o Fortezza‐KEA).  
 
SSL‐3 record protocol 
 
Una volta  che viene creato il canale, abbiamo detto che i  dati verranno automaticamente protetti  nel 
momento in cui l’applicazione farà una write su questo socket sicuro. Quindi a partire da uno stream di 
dati applicativi, io provvederò a scriverli sul canale senza alcuna particolare preparazione. Quello che SSL 
o  TLS  fa  è  prendere  i  dati  applicativi  e  creare  i  cosiddetti  fragment,  ovvero  i  frammenti.  SSL  può 
trasmettere in un colpo solo fino ad un massimo di 214  byte, può anche trasmetterne di meno: quella è 
quindi la dimensione massima di un frammento. E’ importante notare che i frammenti SSL non hanno 
niente a che fare con i frammenti delle reti TCP‐IP. 
Ognuno di questi frammenti può essere opzionalmente compresso; la compressione non è obbligatoria 
ma è utile sia perché riduce la quantità di dati da trasmettere quindi migliora la velocità di trasmissione , 
sia perché tende a togliere le similitudini che ci sono all’interno dei dati ( e come già detto in passato 
cifrare dei dati compressi è meglio che cifrare i dati normali, non soltanto per una minore quantità ma 
anche perché si è già tolta una ridondanza nei dati di partenza e quindi si complica la vita agli eventuali 
attaccanti).  
Sul frammento, normale o compresso, viene calcolato un MAC tramite un keyed‐digest, e questo codice 
con  doppia  funzione  di  autenticazione  e  integrità  viene  aggiunto  in  coda.  A  questo  punto  se  stiamo 
usando  un  algoritmo  di  cifratura  a  blocchi,  viene  fatto  il  padding  ,  in  modo  da  renderlo  di  dimensioni 
opportune perché l’algoritmo possa cifrarlo, e questo viene cifrato, e gli si aggiunge un piccolo header 
(che dichiara che questo è un frammento SSL).  
 

 
 
Questo viene consegnato al livello sottostante, tipicamente il TCP, perché possa essere trasmesso.  

TLS‐1.0 record format 
 
Questo  pacchetto  costituito  da  header  insieme  al  payload  cifrato  corrisponde  esattamente  a  questo 
formato. 

 
Analizzandolo nel dettaglio, notiamo che l’header è costituito dai seguenti campi: 

¾ [uint8]  type  :  può  assumere  i  seguenti  valori  a  seconda  di  quello  che  sta  trasportando  : 
change_cipher_spec (20), alert (21), handshake (22), application_data (23) 
¾ [uint16]  version  =  major  number[uint8]  +  minor  number[uint8]  ,  intesi  come  major  e  minor 
number di SSL, quindi vedremo una cosa curiosa che quando si è passati a TLS si è continuata la 
numerazione quindi nel TLS v1.0 in realtà noi troveremo 3.1 per dire che è il successore di SSL 
3.0 
¾ [uint16]  length:  mi  dicono  quanti  sono  i  dati  che  seguono.  Anche  se  sono  16  bit,  la  lunghezza 
scritta qua dentro non può mai superare 214 . Notiamo che nel caso in cui si stia trattando un 
record compresso, allora al massimo la compressione può aggiungere 1024 byte al blocco base. 
In ogni caso, una volta decompresso, la quantità di dati DEVE STARE ALL’INTERNO DI UN BUFFER 
DA 214 BYTE. Quindi, per il campo length, i valori possibili sono: 
¾ <= 214 (record non compressi) per compatibilità con SSL‐2 
¾ <= 214 + 1024 byte (record compressi) 

TLS ‐ calcolo del MAC 
 
Il calcolo del MAC viene fatto nel seguente modo. Si usa un algoritmo di digest (MD5 o SHA‐1), e viene 
usato nel seguente modo: 
 
MAC = message_digest( key, seq_number || type || version || length ||
fragment ) 
 
¾ message_digest
¾ dipende dall’algoritmo scelto 
¾ key
¾ vengono  negoziate  due  chiavi  che  risponde  alla  direzionalità  in  cui  sta  avvenendo  lo 
scambio dati, una dal client al server, l’altra dal server al client. Quindi bisogna usare la 
chiave giusta per la direzione a cui corrisponde questo flusso di dati 
¾ seq_number
¾ intero a 32 bit 
 

Quindi  il  keyed‐digest  viene  calcolato  sulla  chiave  e  anche  su  tutto  il  pacchetto  (header  più  payload) 
quindi non mi protegge solo i dati, ma anche tutti i campi dell’header. Viene protetto nella sua interezza 
tutto il record TLS. Notiamo inoltre che il campo dedicato al numero di sequenza è un campo a 32 bit, 
questo significa che una volta che quel campo arriva al suo valore limite 232  frammenti, il canale verrà 
automaticamente  chiuso  perché  altrimenti  potrebbe  verificarsi  un  overflow  su  questo  campo  e  non  si 
riuscirebbe più a riconoscere correttamente il replay. E’ da notare inoltre che nelle ultime versioni sia di 
Firefox  che  di  Internet  Explorer,  è  stato  rimosso  SSL‐2  dall’elenco  dei  protocolli  di  sicurezza  abilitati  e 
questo perché SSL‐2 conteneva dei bachi di sicurezza. 

SSL‐3: novità rispetto a SSL‐2 
 
Vediamo quali novità ha introdotto SSL‐3 rispetto ad SSL‐2: 

¾ compressione dei dati: 
¾ opzionale 
¾ viene fatta prima della cifratura (in quanto se fatta dopo non servirebbe!! ) 
¾ opzionalità della cifratura dei dati: 
¾ per avere solo autenticazione e integrità 
¾ possibilità di rinegoziare la connessione: 
¾ cambio periodico delle chiavi 
¾ cambio degli algoritmi 
 
SSL‐3 handshake protocol 
 
Concentriamoci a questo punto sull’Handshake Protocol. Questo è uno degli elementi caratterizzanti di 
SSL  e  lo  usiamo  come  esempio  per  capire  come  operando  su  un  canale  insicuro  si  possa  creare 
un’associazione sicura tra due nodi. In particolare l’Handshake Protocol assolve le seguenti funzioni: 

¾ concordare una coppia di algoritmi per confidenzialità ed integrità dei dati  
¾ stabilire una chiave simmetrica tramite operazioni a chiave pubblica (RSA, DH o Fortezza‐KEA) 
¾ scambiare  dei  numeri  casuali  tra  client  e  server  per  la  successiva  generazione  le  chiavi  che 
serviranno per confidenzialità ed integrità 
¾ negoziare il session‐id 
¾ scambiare i certificati necessari 
 
Confidenzialità dei dati 

Ci  sono  un  numero  troppo  elevato  di  chiavi.  Infatti 


uno  potrebbe  essere  portato  a  pensare  che  questo 
problema  non  sussista  in  quanto  il  client  potrebbe 
inventare una chiave, comunicarla al server e il gioco 
è  fatto.  In  realtà  vengono  messe  dentro  tantissime 
chiavi: ad esempio per il MAC usiamo la chiave e poi 
tutto  il  record  costituito  da  header  più  payload.  Il 
MAC  lo  mettiamo  in  coda  al  pacchetto,  e  tutto 
questo  viene  cifrato  con  un  algoritmo  simmetrico  che  di  solito  richiede  non  solo  un  IV  (ovviamente  è 
necessario un vettore di inizializzazione se è stato scelto un algoritmo di tipo a blocchi) ma anche una 
chiave simmetrica che è diversa da quella che abbiamo utilizzato per calcolare il MAC.  

Rapporto tra chiavi e sessioni 

Ad  ogni  connessione  (che  è  una  cosa  diversa  dalla 


sessione  ,infatti  una  sessione  quella  a  cui  fa 
riferimento  il  session‐id  è  costituita  da  più 
connessioni,  mentre  una  connessione  è  un 
collegamento, un canale, un socket aperto e chiuso) 
il  client  e  anche  il  server  generano  un  numero 
casuale.  Questi  numeri  serviranno  per  alterare  in 
qualche  modo  quei  segreti  che  invece  saranno 
comuni  a  più  connessioni.  In  particolare  quello  che 
viene stabilito attraverso la crittografia asimmetrica (PKC) non è  direttamente una chiave  bensì il pre‐
master  secret,  ovvero  un  segreto  comune  a  client  e  server,  quindi  la  prima  volta  se  io  non  ho  già  un 
session‐id  quello  che  viene  scambiato  è  questo  pre‐master  secret:  è  questo  quello  che  si  mantiene 
quando viene riutilizzato un certo session‐id.  

Dall’unione  del  pre‐master  secret  e  dei  numeri  random  viene  generato  un  master  secret.  I  numeri 
random (client random e server random) sono generati tra client e server ad ogni connessione: 
 
¾ la  prima  volta  questi  random  sono  usati  per  creare  il  master  secret  (solo  la  prima  volta;  per 
questo motivo la freccia è tratteggiata) 
¾ invece, ad ogni connessione, questi numeri random assieme al master secret vengono usati per 
una  serie  di  algoritmi  per  generare  le  chiavi  per  il  MAC,  le  chiavi  per  cifrare  e  il  vettore  di 
inizializzazione  (IV)  per  cifrare.  Queste  chiavi  qui  sono  diverse  per  ogni  singola  connessione, 
quindi  ciò  che  un  server  si  va  a  tenere  in  memoria  assieme  al  session‐id  quando  accetta  un 
session  identifier  è  gli  algoritmi  che  abbiamo  scelto,  il  pre‐master  secret  ed  anche  il  master 
secret. Quindi come chiavi sono queste due quelle che lui si tiene, le altre sono calcolate di volta 
in volta. 
 
Le  operazioni  di  chiave  pubblica  sono  fatte  solo  quando  si  genera  un  master  secret,  e  sono  in  questo 
modo ridotte.I meccanismi possono essere di due tipi: permanenti ed effimeri. 

Meccanismi permanenti 
 
Il client decide una chiave simmetrica e la spedisce al server cifrandola con la chiave pubblica del server. 
Se qualcuno scopre la chiave privata del server è in grado di leggere tutte le informazioni generate (se si 
usa sempre la stessa chiave pubblica). 

Meccanismi “effimeri” 
 
Si chiama meccanismo effimero un meccanismo che usa delle chiavi che non verranno mai più utilizzate. 
Quindi delle chiavi cosiddette usa e getta generate al volo.  
Al posto di avere delle chiavi asimmetriche permanenti può creare le chiavi al volo (e generando al volo 
la chiave pubblica vuol dire che non la potrò fare certificare dalla CA perché la procedura è troppo lunga, 
quindi il server si genera al volo la chiave pubblica e la chiave privata e se la autocertifica attraverso un 
certificato  X.509.  Inoltre  se  uso  DH  allora  sarà  adatto  in  quanto  DH  è  veloce  nella  generazione  delle 
chiavi, mentre RSA è lento, quindi se voglio usare RSA come compromesso dovrò riusare la stessa chiave 
N volte (genererò una nuova chiave per il server dopo un certo lasso di tempo o dopo un certo numero 
di volte). Perché può essere utile il meccanismo usa e getta? Perché attraverso questo meccanismo si 
può  garantire  la  perfect  forward  secrecy  :  noi  sappiamo  che  il  server  ha  una  chiave  pubblica  e  una 
chiave  private.  Immaginiamo  di  non  usare  la  soluzione  di  cui  abbiamo  appena  parlato,  ma  di  usare 
sempre  la  stessa  coppia  chiave  pubblica,  chiave  private.  Vuol  dire  che  il  client  inventerà  questo  pre‐
master  secret    e    lo  manderà  al  server  cifrato  con  la  chiave  pubblica  del  server.  Tutti  i  client  faranno 
questa operazione. In mezzo c’è un cattivo che sta facendo sniffing, e registra tutti i pacchetti e anche 
l’handshake. Se prima o poi nel future riesce a catturare la chiave private del server, allora sarà in grado 
di  andare  a  cifrare  tutti  quei  pacchetti.  Viceversa,  se  la  coppia  chiave  pubblica,  chiave  private  viene 
cambiata  frequentemente,  allora  il  cattivom  sarà  in  grado  di  decrifrare  solo  i  pacchetti  scambiati  per 
quell’istante di tempo, non i pacchetti precedenti e nemmeno quelli futuri. Con i meccanismi effimeri la 
chiave  privata  del  server  viene  usata  non  per  ricevere  il  segreto  cifrato  bensì  solo  per  la  firma  della 
chiave pubblica che verrà poi usata per lo scambio dei dati. 

Il server SSL ha nel suo certificato essenzialmente 2 cose: 

1. il  bit  di  key  usage  che  indica  Digital  Signature,  per  indicare  che  questo  certificato  può  essere 
usato  per  fare  firma  digitale  perché  altrimenti  lui  non  riuscirebbe  a  rispondere  alla  sfida 
asimmetrica 
2. ha anche il bit di KeyEncipherment per poter ricevere il pre‐master secret crifrato dal client 

Queste  sono  logicamente  due  funzioni  diverse.  Il  discorso  dei  meccanismi  effimeri  è  relativo  alla 
seconda di queste, perché se io sto facendo sniffing di traffico cifrato non sono in grado di leggerlo ma 
se riuscissi a conoscere la chiave privata allora potrei ricostruire tutte le sessioni. In particolare, con la 
chiave usata per KeyEncipherment posso non solo ricostruire tutte le sessioni ma potrò avere in chiaro 
le  sessioni  future.  Il  meccanismo  si  chiama  di  perfect  forward  secrecy  perché  viceversa  se  io  non  ho 
usato la chiave del server per fare entrambe le cose ma io ho usato la chiave privata del server solo per 
digital  Signature  per  firmare  una  seconda  chiave  che  è  quella  con  cui  viene  fatto  lo  scambio  chiavi:  è 
questa  qui  la  chiave  effimera  che  viene  generata  ad  ogni  connessione.  In  questo  modo  anche  se 
qualcuno ne viene a conoscenza quella chiave sarà valida solo per quella connessione per cui non inficia 
la sicurezza delle prossime connessioni (per questo si chiama “forward” secrecy, sicurezza in avanti). 

Questi  sono  esattamente  i  messaggi  che  vengono  scambiati  tra  client  e  server  durante  la  fase  di 
handshake. Le linee in nero rappresentano i messaggi obbligatori ovvero quelli che vengono scambiati 
sempre a prescindere da quale siano gli algoritmi usati, quelle tratteggiate sono tipicamente delle cose 
opzionali. Vediamole in sequenza:  

¾ Innanzitutto il client manda il cosiddetto “client hello” a cui il server risponde con il suo “server 
hello”.  
¾ Se necessario il server invia il proprio certificato ed eventualmente una richiesta di un certificato 
al client  
¾ Segue una parte opzionale di scambio chiave  
¾ Il client può mandare il suo certificato se ce l’ha 
¾ l’unico passo obbligatorio è il “client key exchange”;  
¾ il client deve promettere la verifica del certificato.  
¾ Lo  scambio  termina    sempre  con  un  doppio  handashake  di  basso  livello,  nel  senso  che  sia  il 
client  sia  il  server  mandano  un  comando  “change  cipher  spec”  (fino  a  questo  punto  tutto  lo 
scambio è avvenuto in chiaro);  
¾ I messaggi di handshake vengono protetti  a posteriori;  
¾ col  “change  cipher  spec”  ci  si  accorda  su  come  proteggere  i  dati  da  quel  momento  in 
poi;  
¾ col  messaggio  di  finished  sia  in  una  direzione  sia  nell’altra  viene  mandato  in  modo 
protetto un digest di tutti i dati che ci si è scambiati.  
¾ quindi se qualcuno in mezzo (l’attaccante) aveva cambiato, per esempio, le dichiarazioni 
degli algoritmi del client viene fregato, dal momento che il server che riceve questi dati 
in  modo  sicuro  (perché  è  stata  già  attivata  la  protezione),  è  in  grado  di  confrontare  il 
digest  calcolato  su  tutti  i  dati  che  ha  ricevuto  con  quello  inserito  all’interno  del 
“finished”.  
¾ Quindi dentro il finished c’è un digest che non è un digest del singolo messaggio ma di 
tutta la sequenza di handshake.  
 

Client hello 
 
Il client con questo messaggio dichiara le seguenti cose : 
 
¾ La massima versione di SSL che lui è in grado di supportare, quindi si assume che il client sia in 
gradi di usare anche le versioni precedenti. Questa sarà la versione preferita dal client 
¾ 28 byte generati in modo pseudo‐casuale per la generazione delle chiavi con il server 
¾ un identificatore di sessione (session‐id) 
¾ 0 per iniziare una nuova sessione o se non lo vuole usare 
¾ diverso da 0 per chiedere di riesumare una sessione precedente 
¾ elenco  delle  “cipher  suite”  (insieme  degli  algoritmi  di  cifratura,  algoritmo  di  scambio  chiavi  e 
algoritmo per autenticazione e per integrità dei dati) supportate dal client 
¾ elenco dei metodi di compressione supportati dal client 
 
Quindi con questo messaggio il client sta dichiarando le proprie capabilities. 

Server hello 
 
Il  server  risponde  anche  lui  con  un  messaggio  di  “server  hello”,  ma  senza  dichiarare  nulla  bensì 
effettuando direttamente le scelte. Quindi quelle che seguono, sono le scelte fatte dal server: 

¾ versione di SSL scelta dal server : il server dovrebbe scegliere sempre gli algoritmi più forti tra 
quelli in comune tra lui e il client 
¾ 28 byte generati in modo pseudo‐casuale 
¾ un identificatore di sessione (session‐id) 
¾ nuovo session‐id se session‐id=0 nel client‐hello oppure gli manda un nuovo session‐id 
se rifiuta il session‐id proposto dal client 
¾ rimanda  indietro  il  session‐id  proposto  dal  client  se  il  server  accetta  di  riesumare  la 
sessione 
¾ “cipher suite” scelta dal server 
¾ dovrebbe essere la più forte in comune col client 
¾ metodo di compressione scelto dal server 
 
Cipher suite 
 
Come già detto, la cipher suite altro non è che un nome per identificare la triade costituita da : 
 
¾ algoritmo di scambio chiavi 
¾ algoritmo di cifratura simmetrico 
¾ algoritmo di hash (per il MAC) 
 
Le cipher suite sono definite negli standard e tipicamente hanno dei nomi come quelli riportati sopra: 
 
¾ SSL_NULL_WITH_NULL_NULL: cioè non viene protetto lo scambio delle  scambio chiavi, la 
cifratura simmetrica con 0 bit, e l’hash non viene fatto  
¾ SSL_RSA_WITH_NULL_SHA:  
¾ scambio chiavi con RSA, ma cifratura 0 e algoritmo di hash SHA.  
¾ A  cosa  serve  l’algoritmo  di  scambio  delle  chiavi  se  la  cifratura  è  nulla?  Anche  se  la 
cifratura è nulla la chiave simmetrica serve anche al digest quindi è necessario avere un 
algoritmo di scambio chiavi.  
¾ SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5: questo  è  un  esempio  di  algoritmi  che  si 
usavano quando c’erano dei limiti di esportazione 
¾ RSA versione export (RSA versione export: si hanno delle chiavi limitate a 512 bit se si 
usano  per  cifrare  dei  dati;  in  questo  caso  RSA  è  per  scambio  chiavi  e  quindi  si  deve 
cifrare la chiave; quindi al massimo la chiave sarà da 512 bit) 
¾ RC2 tagliato a 40 bit (perché più di questo non si poteva esportare).  
¾ SSL_RSA_WITH_3DES_EDE_CBC_SHA:  
¾ scambio  chiavi  con  RSA  (pieno,  non  versione  export),  cifratura  con    3DES  in  modalità 
EDE CBC,  algoritmo di hash SHA che è SHA‐1 (in quanto SSL non ha ancora recepito le 
versioni successive di SSL).  
 

Certificate (server) 

Il  messaggio  certificate  del  server  manda  il  certificato  per  la  server  authentication.  Come  già  detto  in 
precedenza, bisogna prestare attenzione al fatto che il campo subject o il campo subjectAltName deve 
coincidere con l’identità del server. Se abbiamo usato come URL l’indirizzo IP allora nel certificato deve 
esserci l’indirizzo IP. Inoltre il certificato può essere solo di firma o anche per la cifratura: 
 
¾ il  certificato  ha  un  campo  particolare  che  si  chiama  keyUsage  che  dice  per  quali  scopi  il 
certificato può essere utilizzato 
¾ se  in  questo  campo  c’è  scritto  che  è  usato  solo  per  la  firma  allora  poi  è  necessaria  la  fase  di 
server‐key  Exchange,  perché  se  è  solo  di  firma  allora  vuol  dire  che  questo  certificato  non  può 
essere usato dal client al fine di inviare al server il pre‐master secret 
 
Certificate request 
 
E’  quello  con  cui  il  server  richiede  l’autenticazione  del  client  e  nel  richiedere  l’autenticazione  il  server 
manda al client anche la lista delle CA che il server ritiene fidate : questo è importante in quanto il client 
può anche avere dei certificati, ma il server dichiara quali sono le CA che lui ritiene fidate quindi il client 
dovrà mandare il certificato solo se emesso da una delle CA che compare in quella lista. Qualora non ne 
abbia uno allora potrà fare a meno di inviarglielo. 

Server key exchange 

Come già detto questa fase è fondamentale se il certificato del server non è valido per fare la cifratura, 
quindi se il server ha un certificato RSA valido solo per fare la digital signature. Inoltre, è richiesto questo 
messaggio anche nei seguenti casi: 
 
¾ server ha certificato RSA solo per firma 
¾ si usa DH anonimo o effimero per stabilire il master‐secret 
¾ ci sono problemi di export e si devono usare chiavi RSA/DH temporanee 
¾ Fortezza 
 
Questo è l’unico messaggio con firma esplicita da parte del server , ovvero il server manda o i parametri 
Diffie  Hellman  o  la  chiave  che  ha  generato  al  volo  e  la  manda  firmata  con  la  chiave  presentata 
precedentemente. Questo è l’unico messaggio che richiede la firma da parte del server. Inoltre notiamo 
che in termini di prestazioni usare meccanismi effimeri richiede maggio tempo nella fase di handshake 
perché  richiede  una  firma  esplicita  da  parte  del  server  :  ricordiamo  infatti  che  le  verifiche  RSA  sono 
veloci, mentre le firme RSA sono lente. 
 
Certificate (client) 

Come già detto, questo messaggio trasporta il certificato per la client authentication, e deve essere stato 
emesso da una delle CA fidate elencate dal server nel messaggio Certificate Request. 
 
Client key exchange 
 
Questo messaggio assume varie forme a seconda di quello che abbiamo scelto di fare. Può essere: 
 
¾ pre‐master secret cifrato con la chiave pubblica RSA del server (temporanea o dal certificato) 
¾ parte pubblica di DH 
¾ Fortezza 
 
Per quanto riguarda lo scambio di chiavi può capitare che:  
¾ il client mandi un pre‐master secret cifrato con la chiave pubblica RSA del server (se si tratta di 
una  chiave  RSA  temporanea  oppure  se  il  certificato  permette  crittografia  con  la  chiave 
crittografica) 
¾ oppure se il server accetta una scambio Diffie Hellman allora il client gli manda la parte pubblica 
di Diffie Hellaman o i parametri di fortezza che sono analoghi ai parametri pubblici di DH.  
 

Certificate verify 
 
Nella fase di certificate verify si fa la prova esplicita di firma; in particolare il client firma con la propria 
chiave privata l’hash calcolato su tutti i messaggi che precedono questo. Quindi questa è la parte di sfida 
nei confronti del client. Inoltre questa  parte viene fatta solo se il client alla richiesta del certificato ha 
risposto con un certificato valido rispetto alla lista delle CA fidate che gli è stata comunicata dal server. 
 
Change cipher spec 
 
Questo  messaggio  provoca  l’aggiornamento  degli  algoritmi  da  usare  per  la  protezione,  e  permette  di 
passare  dai  messaggi  precedenti  in  chiaro  all’uso  nei  messaggi  successivi  degli  algoritmi  appena 
negoziati. A rigore come visto prima fa parte di un protocollo specifico e non dell’handshake. Secondo 
varie analisi potrebbe anche essere eliminato, ma al momento questo resta. 
 
Finished 
 
Il finished è il primo messaggio protetto con gli algoritmi negoziati, ed è fondamentale per autenticare 
tutto lo scambio. Ricordiamo infatti che i messaggi scambiati prima sono in chiaro, e qualcuno potrebbe 
essersi messo in mezzo e quando si negoziavano gli algoritmi potrebbe aver forzato il client all’utilizzo di 
algoritmi  poco  efficaci.  Il  messaggio  di  finished  evita  che  si  vengano  a  creare  queste  situazioni  perché 
contiene  il  MAC  calcolato  su  tutti  i  messaggi  di  handshake  precedenti  (tranne  il  change  cipher  spec) 
tramite  l’uso  del  master  secret.  Permette  di  evitare  attacchi  man‐in‐the‐middle  di  tipo  rollback  (  i 
rollback  sono  quelli  che  fanno  scendere  il  livello  di  protezione  che  si  è  scelto).  Sono  necessari  due 
messaggi di finished. Il messaggio di finished è ovviamente diverso per il client e per il server visto che 
conterrà il MAC calcolato sui messaggi che il client ha mandato al server, e che il server ha mandato al 
client, e poiché questi sono diversi anche i finished saranno diversi. 
 
TLS 
 
Quando  si  decise  di  standardizzare  SSL  e  quindi  quando  SSL  è  stato  aperto  all’IETF,  ne  fu  cambiato  il 
nome in TLS (Transport Layer Security): il cambio del nome è stato politico, poiché Microsoft non voleva 
accettare di implementare una  cosa con un nome creato da un  concorrente.Esistono due versioni TLS 
1.0 del gennaio 99 e il nuovissimo TLS 1.1 (dell’aprile 2006).  
 
Al  99%  TLS‐1.0  coincide  con  SSL‐3.  Una  cosa  su  cui  si  è  messo  particolare  accento  è  stata  la  scelta  di 
algoritmi non proprietari, quindi algoritmi su cui non fosse necessario pagare le royalty. La cipher suite 
che è stata scelta è stata la seguente: 
 
¾ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA : quindi scambio chiami con DH effimero, firma DSS e 
cifratura 3‐DES EDE CBC con SHA per integrità. 
 
L’unica  differenza  sostanziosa  è  che  il  key  digest  non  è  più  un  keyed  digest  generico,  inventato  da 
Netscape, ma un digest HMAC.  
 
TLS‐1.1 
 
In realtà il TLS 1.1 coincide dal 99% con la versione 1, ma corregge soltanto un paio di piccoli bachi che 
permettevano degli attacchi contro le varie versioni di TLS. In particolare c’erano alcuni attacchi contro il 
CBC. Quindi l’IV implicito è stato rimpiazzato da IV esplicito il che ha comportato che la dimensione dei 
pacchetti sia un pochettino cresciuta. Inoltre in caso di errori di padding ora usano il messaggio di alert  
bad_record_mac  (invece  di  decryption_failed):  può  sembrare  un  dettaglio,  ma  questo  forniva  dei 
dettagli all’attaccante attraverso cui quest’ultimo poteva risalire alla chiave. Infine: 
 
1. In  più  sono  stati  definiti  dei  registri  che  tiene  l’organizzazione  IANA  per  definire  quali  sono  i 
numeri di protocollo 
2. Se  si  chiude  il  canale  prima  che  la  sessione  sia  conclusa,  il  session‐id  non  viene  cancellato; 
questo viene fatto per  migliorare le performance 
3. Poi  ci  sono  tutta  una  serie  di  note  che  spiegano  l’interpretazione  di  TLS  nei  confronti  di  vari 
attacchi possibili 
 
Evoluzione di TLS 
 
TLS continua ad evolversi e ci sono delle RFC che documentano delle aggiunte 
 
¾ Kerberos si può usare per la parte di autenticazione 
¾ Si possono usare anche AES o algoritmi a curva ellittica  
¾ qualcuno ha anche inventato algoritmi tipo Camelia (che è un altro algoritmo simmetrico) 
¾ oppure è possibile avere una chiave cifrata a mano e precondivisa. 
 
Queste  diversità  sono  dovute  al  fatto  che  si  possono  avere  ambienti  con  capacità  computazionali 
differenti  e  quindi  si  deve  avere  il  massimo  della  flessibilità.  Si    hanno  anche  diversi  metodi  di 
compressione, infatti in SSL‐3 era stata definita la possibilità di negoziare gli algoritmi di compressione 
ma non era stata fatta menzione di quali algoritmi di compressione specificare. E’ stato quindi inserito 
LSZ  che  è  l’algoritmo  di  compressione  alla  base  dello  ZIP,  e  inoltre  sono  state  aggiunte  anche  delle 
estensioni application‐specific. 
 
DTLS (Datagram Transport Layer Security) 
 
TLS ha avuto un così positivo impatto nell’ambito della sicurezza che si è deciso di sviluppare anche una 
versione  per  datagrammi.  Notiamo  che  come  già  detto  per  SSL/TLS  è  necessario  che  il  protocollo  di 
trasporto sia affidabile, quindi si può applicare solo a TCP, però ci sono tantissimi protocollo applicativi 
che vengono veicolati su UDP. Ovviamente non si può trasporre direttamente SSL/TLS su UDP, perché 
vengono a cadere tutta una serie di fattori, e allora è stato sviluppato appositamente il DTLS ovvero il 
Transport  Layer  Security  orientato  ai  datagrammi,  riconoscendo  che  alcuni  servizi  di  sicurezza  non 
possono  essere  offerti.  Il  DTLS  è  una  versione  che  cerca  di  applicare  gli  stessi  concetti  del  TLS  alla 
sicurezza dei datagrammi, quindi per esempio UDP, ma non offre tutti i servizi di sicurezza di TLS. 
Il DTLS è attualmente in competizione con altre due soluzioni : se noi abbiamo un’applicazione basata su 
UDP abbiamo due scelte: 
 
¾ IPsec : uso IPsec, quindi faccio sicurezza al livello sottostante rispetto a UDP 
¾ TLS : fare sicurezza applicativa (dei messaggi o dei dati securizzando il payload) 
¾ DTLS : securizzare UDP stesso 
 
Se ad esempio trattiamo SIP, abbiamo 4 scelte possibili :  
 
1. con IPsec 
2. con TLS (solo per SIP_over_TCP) 
3. con DTLS (solo per SIP_over_UDP) 
4. con secure SIP 
 
notiamo che se scelgo IPsec o secure SIP sono indipendente dal livello di trasporto che è stato scelto per 
SIP. 
 
Detto  questo,  andremo  ad  analizzare  alcuni  problemi  applicativi  per  securizzare  le  applicazioni  e  in 
particolare  visto  che  oggi  la  maggior  parte  delle  applicazioni  sono  veicolate  sopra  http,  cominceremo 
proprio da questo protocollo. 
 
All’interno di HTTP‐1.0 sono già definiti dei meccanismi di sicurezza, e sono i seguenti: 
 
¾ “address‐based” = il server controlla l’accesso in base all’indirizzo IP del client 
¾ “password‐based” (o Basic Authentication Scheme) = accesso limitato da username e password, 
che  vengono  trasmessi  codificati  con  Base64,  quindi  NON  SONO  CIFRATI,  infatti  Base64  è  una 
funzione perfettamente invertibile 
 
Ovviamente  entrambi  gli  schemi  sono  altamente  insicuri  ,  ma  è  da  notare  che  nell’RFC  dell’HTTP  si 
dichiara di usare HTTP solo su canali sicuri. HTTP/1.1 migliora un po’ la situazione in quanto introduce la  
“digest  authentication”  con  cui  si  continua  ad  usare  la  password  ma  la  si  utilizza  per  una  sfida 
simmetrica,  quindi  la  fase  di  autenticazione  è  diventata  un  po’  più  robusta.  Nell’RFC‐2617  “HTTP 
authentication: basic and digest access authentication”, vengono riassunti entrambi i meccanismi. 
 
HTTP ‐ basic authentication scheme 
 

 
 
Consideriamo adesso il meccanismo di Basic Authentication. Abbiamo aperto un canale HTTP e stiamo 
facendo una domanda al server, quindi la GET di una pagina. Questa pagina che stiamo richiedendo è 
protetta, ma di fatto non c’è alcun modo per saperlo, infatti non esiste un meccanismo per dichiarare 
nella URL che una pagina sia protetta. Quello che ci capita, è beccarci una errore 401, che è l’unico caso 
in cui anche nella versione HTTP 1.0 il server non ci chiude la connessione, in quanto lui sa benissimo 
che  l’utente  fosse  ignaro  che  la  pagina  richiedesse  autenticazione.  Quindi,  gli  da  il  suggerimento,  se 
veramente  l’utente  vuole  accedere  a  quella  pagina,  di  autenticarsi,  e  lo  richiede  facendo  seguire 
all’errore HTTP anche l’header: 
 
WWW‐Authenticate: Basic realm="RealmName" 
   
dove  richiede  di  autenticarsi  in  questo  caso  con  il  meccanismo  Basic  Authentication  per  il  dominio 
“RealmName”.  Non  bisogna  fare  tra  questo  reame  e  il  reame  di  Kerberos,  infatti  mentre  il  reame  di 
Kerberos è costituito da tutte le macchine che si sottomettono al sistema di autenticazione di Kerberos, 
questo qui invece è solo un nome di fantasia, ed è quello che viene usato dal Pop‐Up per dire all’utente 
che  deve  immettere  Username  e  Password  per  il  reame  specificato  (altrimenti  l’utente  non  capirebbe 
quail credenziali usare se solo non sapesse il reame nei confronti del quale è richiesta l’autenticazione). 
Il  popup  non  è  applicativo,  e  quindi  non  è  bloccante,  ed  è  una  reazione  automatic  del  browser  non 
disabilitabile.  Inviando  le  credenziali,  riceviamo  un  altro  header  che  dice  che  sta  provando  ad 
autenticarsi con quell meccanismo (Basic) seguito da username e password codificati in Base64: quindi 
chi  fa  sniffing  sulla  rete  li  può  leggere  e  ottenerli,  inoltre  poichè  il  server  dovrà  autenticare  l’utente 
dovrà conoscere username e password in chiaro, e se il calcolo fatto dal server va a buon fine, visto che 
il  canale  è  ancora  aperto  ci  manderà  header  e  body  della  pagina  HTTP.  Ovviamente  fare  queste 
operazioni su un canale non cifrato mette a serio rischio di intercettazione di username e password, ed 
ecco quindi l’interesse ad usare HTTP sopra un canale SSL o TLS dirsi voglia.  
 
HTTP e SSL/TLS 
 
Abbiamo due alternative in questo caso: 
 
¾ “TLS then HTTP” (RFC‐2818 – HTTP over TLS) – url https : implica che io prima apro un canale 
sicuro e poi sopra questo veicolo il protocollo HTTP 
¾ “HTTP then TLS” (RFC‐2817 – upgrading to TLS within HTTP/1.1) : apro il canale HTTP non sicuro, 
ed esiste un commando dentro il protocollo HTTP per richiedere di securizzare il canale 
 
Notiamo che “SSL then HTTP” è largamente usato, ma in realtà coincide con la prima solo che si usa SSL 
e non TLS, ma non è documentato. Inoltre, la prima soluzione è ad oggi quella largamente usata, ma si 
assiste  a  continue  pressioni  da  parte  di  IETF  e  W3C  al  fine  di  usare  la  seconda  soluzione  :  PER  QUALE 
MOTIVO?  A  loro  non  piace  il  fatto  che  esistano  due  URL  diverse,  ovvero  l’http  e  l’https.  Qualcuno 
obbietta al fatto che http non sia sicuro, infatti se stiamo usando http su IPsec allora è sicuro, mentre 
altri obbiettano al fatto che https sia sicuro infatti data l’esistenza delle ciphersuite con algoritmi NUL in 
quel caso di sicurezza ce n’è ben poca. Quindi la tendenza è quella di avere http e poi se si vuole rendere 
sicuro il canale allora lo si rende sicuro. 
Come  è  chiaro,  le  due  forme  non  sono  assolutamente  equivalenti  ed  hanno  un  grosso  impatto  sulle 
applicazioni  finale,  sul  firewall  ed  in  generale  sull’IDS.  Infatti  se  io  ho  fatto  TLS  then  HTTP,  quando  un 
firewall  si  vede  arrivare  un  traffico  cifrato  non  può  più  decidere  in  base  al  protocollo  applicativo  se 
lasciarlo passare o meno, infatti può anche darsi che sulla porta TCP 443 sia stato installato un servizio 
diverso e il firewall lo lasci passare. Stessa cosa con l’IDS. Viceversa se io ho HTTP e poi TLS, il firewall 
può vedere se quello è un canale HTTP , può vedere quando viene richiesto di rendere sicuro il canale. 
Anche  sull’applicazione  c’è  un  notevole  impatto,  infatti  se  io  faccio  TLS  then  HTTP  allora  il  mio  server 
può  ignorare  il  fatto  che  ci  sia  SSL,  mentre  se  faccio  http  then  TLS  allora  il  server  dovrà  riconoscere  il 
comando per richiedere di securizzare il canale e poi implementare le dovute misure di sicurezza.  E’ da 
notare che più in generale si può estendere il discorso anche ad altri protocolli applicativi,non solo ad 
http,  quindi  sebbene  l’RFC  faccia  riferimento  ad  http  di  fatto  il  discorso  che  stiamo  facendo  risulta 
estendibile anche ad altri protocolli applicativi. 
 
 
 
Sicurezza del WWW 
 
Conviene usare il canale SSL, per i seguenti motivi: 
 
¾ protegge le transazioni 
¾ protegge le password applicative  
 
Notiamo che la password per Basic/Digest Authentication non è ancora la password che io uso dentro 
un  form,  perchè  questa  autenticazione  è  fatta  prima  ancora  che  sul  browser  mi  arrive  la  pagina  web. 
Quindi come discuteremo meglio dopo con il web io ho almeno tre livelli di autenticazione: 
 
1. Posso mettere le password applicative (dentro i form) 
2. Posso avere la password al livello di Basic Authentication 
3. Posso avere autenticazione al livello SSL con la Client Authentication 
 
Se abbiamo scelto di usare password per la Basic o la Digest Authentication abbiamo due scelte: 
 
¾ Creare delle password apposite del servizio http, ovvero delle password per accedere al servizio 
http 
¾ il server starà su un certo S.O. e l’utente dovrà pure essersi loggato sul sistema operativo, quindi 
si può anche richiedere la password del S.O. che ospita il server (es. NT o UNIX). Questo è molto 
comodo  soprattutto  quando  abbiamo  un  dominio  perché  ho  un  dominio  e  uso  la  password  di 
dominio anche per questi scopi, ma non è una bella cosa, perché se per caso viene intercettata 
sul  canale  la  coppia  username  e  password,  quella  non  servirà  solo  per  loggarsi  col  server  ma 
conterrà delle credenziali valide per il dominio.  
 
Quindi anche se è più comoda la seconda strada, si consiglia sempre di seguire la prima creando delle 
password  apposite  per  il  servizio  http.  Esisteranno  inoltre  delle  ACL  che  determineranno  in  funzione 
dell’autenticazione  che  diritti  si  hanno  sulle  varie  risorse  ,  quindi  sono  utili  per  regolare  l’accesso  ai 
documenti. 
 
Client authentication SSL a livello applicativo 
 
Abbiamo  detto  che  usando  SSL  è  anche  possibile  chiedere  la  Client  Authentication,  quindi  esiste  la 
possibilità che il server chieda al client di mostrargli un certificato valido per autenticarsi nei confronti 
del  server.  Questo  viene  fatto  al  livello  SSL,  quindi  prima  ancora  che  venga  creato  il  canale  HTTP.  In 
realtà  qualcuno  dice  anche  che  questa  cosa  non  ha  molto  senso,  in  quanto  comunque  al  livello 
applicativo si dovranno comunque richiedere username e password per poter capire quale utente è, ma 
in realtà non è così : infatti SSL esporta al livello applicativo alcuni paramteri caratteristici tra cui anche i 
dati  con  cui  l’utente  si  è  autenticato.  Quindi  con  questa  soluzione  c’é  la  possibilità  di  fare  mapping 
automatici o semi‐automatici tra la credenziale estratta dal certificato e quella fornita ai livelli superiori. 
Il fatto che l’autenticazione sia stata fatta ad un livello più basso non preclude che questa rimanga nota 
al  livello  applicativo,  inoltre  è  completamente  trasparente  per  l’utente  ma  non  gli  permette  di  fare 
“giochetti strani”.  
 
Autenticazione nelle applicazioni web 
 
Quindi riassumendo abbiamo 3 scelte : 
 
1. autenticazione al livello di canale SSL  
2. autenticazione al livello di canale http (Basic/Digest Authetication) 
3. autenticazione applicativa 
 
Queste  tre  soluzioni  non  sono  equivalenti.  In  figura  sono  stati  forniti  dettagli  su  quale  sia  il  software 
responsabile dell’autenticazione: 
 
¾ canale SSL : ci sarà un’apposita libreria che permette di fare SSL 
¾ canale http : è compito del software server web (Apache o IIS) 
¾ applicazione : sarà l’application server o le pagine che abbiamo scritto 
 
tipicamente queste tre cose sono organizzate a piramide, infatti SSL è una quantità di sotware piccola in 
quanto deve occuparsi solo di fare SSL, mentre il demone http deve fare tutto http. Infine l’applicazione 
sarà  qualcosa  di  ancora  più  grosso.  Il  concetto  è  quindi  prima  si  fa  l’autenticazione  e  meno  software 
stiamo  esponendo  agli  attacchi,  quindi  “più  in  basso  si  fa  il  controllo  e  meno  parti  si  espongono  agli 
attacchi”  .  Questo  si  correla  con  un  concetto  che  fa  parte  di  quei  tentativi  di  misurare  quando  un 
sistema sia sicuro o insicuro, che si chiama ATTACK SURFACE : dato un attaccante, qual è la superficie di 
attacco che lui ha a disposizione? Infatti più ristretta sarà la superficie, più bassa sarà la probabilità che 
l’attaccante trovi un attacco efficace.  
 

 
 
Quindi se possiamo, facciamo la Client Authentication, ma anche se non possiamo farla è sempre meglio 
fare la Basic/Digest Authentication piuttosto che ritardare il controllo fino al livello applicativo facendo 
quindi l’autenticazione applicativa, perché c’è molta più probabilità di aver commesso errori nella parte 
applicativa piuttosto che nel demone del server web. Notiamo che le frecce in blu indicano il mapping, 
ovvero l’autenticazione fatta ad un certo livello può essere trasferita come minimo con delle variabili di 
ambiente,ma molto spesso esiste la possibilità di fare dei mapping automatici.  
 
Come introdurre username e password 
 
Vediamo di toccare con mano la situazione che si viene a creare. Supponiamo di trovarci su un sito di 
Internet Banking, e di dover introdurre le credenziali di accesso, ovvero username e password. A questo 
punto guardiamo il form di login, e vediamo che in fondo alla pagina stessa c’è un lucchetto aperto. A 
questo  punto  l’utente  si  incuriosisce  :  ma  il  lucchetto  non  dovrebbe  essere  chiuso  per  fornirmi 
sicurezza? La risposta che gli viene fornita è che in realtà metterlo chiuso prima o dopo è la stessa cosa. 
In realtà i conti non tornano, perché scegliendo questa strada username e password verranno trasmessi 
in modo INSICURO! Ma questa cosa è vera? No, in quanto tutto dipende da cosa viene fatto dopo che si 
clicca sul bottone “GO”, che corrisponderà ad una certa action e sarà la ACTION a dire se andiamo su 
http o https. Ma così è un casino : perché l’unico modo per sapere come veramente verranno trattate le 
mie credenziali di accesso al servizio è andare a guardare la URI, e se nella URI c’è https per trasmettere 
i dati. Quindi la sicurezza effettiva dipende dalla URI del metodo usato per inviare username e password 
al server : 
  
¾ tecnicamente, non importa la sicurezza della pagina in cui si introducono i dati 
¾ ma psicologicamente  è importante la sicurezza della pagina in  cui si introducono i dati perché 
pochi utenti hanno le conoscenze tecniche necessarie a verificare la URI del metodo usato per 
l’invio 
 
Quindi,  seguendo  la  strada  dell’esempio  che  abbiamo  posto,  noi  stiamo  disabituando  gli  utenti,  e  gli 
stiamo dando un cattivo esempio perchè così facendo apriamo la strada per degli shadow server. Quindi 
l’utente dovrebbe essere abituato a vedersi richiedere le credenziali per autenticarsi solo su una pagina 
con un bel lucchetto. 

S‐HTTP 

Non  è  https,  bensì  una  modifica  del  protocollo  HTTP  1.0  sviluppata  da  EIT‐Terisa.  Ogni  commando  ed 
ogni risposta (quindi request e response) vengono incapsulate in una busta sicura, che può essere di vari 
tipi : PEM, PGP o PKCS‐7.  E’ obsoleta, e non dobbiamo lasciarci ingannare dal fatto che ci siano delle RFC 
che  documentano  questo  protocollo  in  quanto  sono  delle  RFC  experimental  che  sono  stati  scritti  a 
futura memoria per documentare una cosa che per un certo periodo di tempo è esistita. S‐HTTP è stata 
la  contromossa  di  IBM,  infatti  Netscape  ha  avuto  l’idea  di  SSL,  Microsoft  ha  inventato  PCT,  IBM  ha 
inventato S‐HTTP ma anche questo è naufragato. 

Coesistenza di SSL con altri protocolli 
 
SSL estende ad un livello inferiore gli altri protocolli di sicurezza, e può coesistere con altri protocolli di 
sicurezza  che  possono  essere  collocati  a  livelli  diversi  anche.  Con  la  stratificazione  è  possibile  avere 
misure  di  sicurezza  addizionali  una  sopra  l’altra,  nel  senso  che  sopra  TCP‐IP  è  possibile  decidere  di 
implementare SSL, il quale può essere usato o non usato da un protocollo che di per sé sarebbe insicuro:  

¾ Per esempio si può usare telnet sicuro con SSL o telnet normale,  
¾ oppure  SMTP  con  SSL  o  normale  (perché  la  posta  è  già  sicura  se  si  è  ad  esempio  adottato  lo 
standard di posta  S/MIME).  
 
Quindi attenzione a come SSL si combina con la sicurezza applicativa:  
 
¾ la sicurezza applicativa sta a livello 7 e magari anche 7 e mezzo,  
¾ l’SSL è più a livello 4‐5 e quindi si può combinare con la sicurezza applicativa. 
 

SSH (Secure SHell) 

Per  un  certo  periodo  di  tempo  una  delle  alternative  a  SSL  è  stato  SSH.  SSH  è  stato  sviluppato  da  uno 
studente  finlandese  che  nell’ambito  di  un  corso  di  sicurezza  ha  sviluppato  come  tesina  la  riscrittura 
completa dei comandi R (rsh, rlogin, rcp) per renderlo sicuro. Lui ha sviluppato una soluzione che poi fu 
fondamentalmente utile anche in ambiti diversi da quello per cui fu sviluppato. Che cosa ci fornisce SSH? 
Vediamo:  
 
¾ crittografia del canale 
 
¾ utilizza DES, triplo DES, RC4, IDEA oppure ISS (algoritmo specifico finlandese) 
¾ la chiave di cifratura è una chiave di sessione scambiata in fase di connessione 
 
¾ vari tipi di autenticazione: 
 
¾ indirizzi IP (= rlogin + crypto) : questo vuol dire avere lo stesso tipo di autenticazione di 
rlogin con in più la parte di protezione dei dati trasmessi 
¾ chiave  RSA  di  host  :  sfida  asimmetrica  con  chiave  assegnata  a  ciascun  host  della  rete, 
quindi ciò che viene identificato è l’host, ma non l’utente 
¾ chiave RSA di utente : è possibile assegnare chiavi RSA anche ai singoli utenti e quindi 
fare anche una sorta di client authentication 
 
Per quanto riguarda le implementazioni, è public‐domain per UNIX, mentre è commerciale per Windows 
anche  se  è  in  corso  di  sviluppo  anche  un’implementazione  public  domain  per  Windows.  Infine,  il 
protocollo in corso di pubblicazione come RFC. 
 

SSH – certificazione 
 
Abbiamo detto che SSH usa ampiamente le chiavi RSA, il maggior problema è che SSH usa nella sessione 
base  chiavi  RSA  ma  non  usa  certificati  di  alcun  tipo!  Usare  le  chiavi  pubbliche  senza  certificati  induce 
problemi  per  la  sostituzione  delle  chiavi  pubbliche  :  ovvero  se  qualcuno  riesce  a  sostituirmi  la  chiave 
pubblica io non ho alcun modo di accorgermi di questa sostituzione in quanto la chiave pubblica non è 
certificata  in  alcun  modo.  La  certificazione  o  la  garanzia  delle  chiavi  è  affidata  interamente  al  File 
System, quindi si assume che il file system sia adeguatamente protetto da intrusioni. In particolare : 

¾ la  chiave  pubblica,  non  essendo  associata  ad  un  certificato  di  una  CA,  deve  essere  nota  alla 
controparte per poter essere verificata: 
 
¾ i client tengono la chiave pubblica dei server in: 
ƒ ~/.ssh/known_hosts 
 
¾ i server tengono le chiavi pubbliche dei client in: 
ƒ ~/.ssh/authorized_keys 
 
Il server manda la propria chiave pubblica, e a quell punto se era un server sconosciuto SSH avverte che 
è  stata  ricevuta  una  nuova  chiave,  nel  qual  caso  ci  chiede  se  la  vogliamo  memorizzare.  Però  già  solo 
averla  ricevuta  così  pone  molti  dubbi.  Viceversa  i  server  tengono  le  chiavi  pubbliche  dei  client  nel  file 
authorized_keys, quindi la sicurezza di queste chiavi pubbliche è affidata interamente alla sicurezza del 
File System e al fatto che nessuno possa manipolare queste cartelle e questi file. 
 

SSH ‐ protezione delle chiavi private 
 
La chiave privata del server è conservata in chiaro in un file, e come sappiamo la cosa è estremamente 
pericolosa.  Anche  in  questo  caso  ci  si  affida  pienamente  alla  protezione  del  file  System  lato  server.  Si 
suggerisce anche di tenere nascosto questo file (quindi un po’ di security through obscurity), e bisogna 
anche ricordarsi di cancellare il file di configurazione che dice qual è il file in questione. 
La chiave privata del client è conservata crittografata con un passphrase P. La passphrase viene richiesta 
all’utente  quando  occorre,  ed  esiste  un  programmino    (infatti  SSH  è  costituito  da  una  miriade  di 
programmini)  che  si  chiama  ssh‐agent  e  che  è  una  sorta  di  proxy,  al  quale  noi  comunichiamo  la 
password  che  rimuove  la  protezione  della  chiave  privata,  e  ci  penserà  lui  a  dialogare  con  tutti  gli  altri 
programmi della suite SSH trasmettendola quando necessario. 
 

SSH ‐ autenticazione dei client 
 
Per  l’autenticazione  dei  client  abbiamo  detto  che  uno  dei  meccanismi  è  quello  dell’autenticazione 
basata sull’indirizzo IP, quindi il server  va a controllare quali sono gli IP autorizzati. Nello standard dei 
comandi  “r”,  questi  definiscono  degli  host  che  sono  equivalenti,  ovvero  se  si  fa  il  login  su  una  certa 
macchina  allora  è  possibile  collegarsi  a  tutte  le  altre  senza  dover  più  fare  login.  Questo  è  definito  al 
livello  di  sistema  globale  se  questi  host  vengono  elencati  nel  file  /etc/hosts.equiv,  oppure  al  livello 
individuale  (di  singolo  utente)  se  nella  nostra  home  abbiamo  messo  questi  altri  calcolatori  nel  file 
denominato ~/.rhosts. 
Come già ditto è anche possible fare autenticazione standard + RSA challenge: 
 
¾ il  client  deve  rispondere  ad  una  sfida  crittografica  di  tipo  asimmetrico  (verificabile  dal  server 
perché conosce le chiavi pubbliche dei client) 
¾ il server verifica comunque ~/.rhosts e /etc/hosts.equiv 
 
SSH ‐ autenticazione dei client 
 
Per autenticare i client ho diverse possibilità: 
 
¾ uso di login+password Unix all’interno di un canale crittografato 
¾ challenge RSA puro, ossia senza controllo dell’indirizzo IP 
 
SSH ‐ autenticazione dei server 
 
Viene fatta solo ed esclusivamente mediante challenge RSA. 
 

K‐commands 
 
In  quei  sistemi  in  cui  è  implementato  Kerberos  può  essere  interessante  utilizzare  i  cosiddetti  k‐
commands,    ossia  tutte  quelle  applicazioni  che  sono  state  modificate  per  utilizzare  Kerberos.  Questi 
comandi sono: 

¾ K‐telnet, K‐ftp, Klogin, Kcp, Ksh, K‐POP 
 

Notiamo che Kerberos serve in due sensi: 

1. serve  innanzitutto  nella  fase  di  autenticazione  in  cui  Kerberos  è  in  grado  di  fornire  mutua 
autenticazione del client e del server 
2. visto che tra client e server Kerberos stabilisce un segreto condiviso, questo segreto condiviso 
può  essere  usato  per  la  cifratura  simmetrica  e  il  keyed‐digest,  e  quindi  per  proteggere 
successivamente l’applicazione 

La parte di crittografia del canale con DES è opzionale. Non dobbiamo farci fuorviare nei k‐commands 
dal fatto che si usi Kerberos e che questo sia usato solo per autenticazione, in quanto come visto può 
anche essere utilizzato per scambio chiavi. Di solito non si mette in piedi Kerberos per utilizzare questi 
comandi, al più si va nel viceversa, ovvero se ho già Kerberos allora posso prendere in considerazione 
l’idea di usare questi comandi.  

SSL‐telnet, SSL‐ftp, SSL‐rsh 
 
Allo  stesso  modo,  se  abbiamo  usato  servizi  come  telnet,  ftp  ed  rsh  con  SSL    allora  possiamo  ripiegare 
sull’uso di SSL‐telnet, SSL‐ftp, SSL‐rsh. Si tratta di applicazioni standard modificate con trasporto SSL, e si 
appoggia  sulla  libreria  OpenSSL.  Ovviamente  usa  certificati  X.509.  E  permette  anche  la  modalità  di 
funzionamento fall‐back, ovvero se l’autenticazione SSL fallisce si può: 

¾ rifiutare la connessione 
¾ ricadere all’indietro (fall back) , e collegarsi col protocollo standard 

SSL‐x: autenticazione 
In tutti questi programmi tipicamente l’autenticazione consiste nel: 

¾ il server è sempre autenticato: 
 
¾ chiave privata in chiaro in un file 
¾ chiave privata conservata in un file cifrato con l’uso di una passphrase, che sarà richiesta 
all’avvio per aprire il file che contiene la chiave privata 
 
¾ per default, il client è autenticato tramite login+password Unix ma su un canale crittografato 
 
¾ opzionalmente  si  può  usare  la  client  authentication  di  SSL;  in  questo  caso  la  passphrase  che 
protegge la chiave privata è richiesta all’utente 
 

Uno  dei  più  comuni  modi  di  usare  SSH  (di  tunnellizzare  un’applicazione),  è  per  la  protezione  di  X‐
Windows, quindi adesso spendiamo due paroline su X‐Windows. 

Il sistema X‐windows (X11) 

X‐Windows è il sistema grafico del mondo Unix e possiamo vederlo come una applicazione, con i suoi 
requisiti  di  sicurezza  (e  sono  dei  forti  requisiti  di  sicurezza).  Notiamo  innanzitutto  l’inversione  di 
terminologia, infatti: 
 
¾ client  :  sono  i  nodi  di  rete  che  svolgono  l’elaborazione,  perché  il  sistema  X‐Windows  è  un 
sistema  Client/Server  che  serve  a  fornire  il  servizio  di  Input  e  Output  grafico  a  dei  programmi 
che  stanno  svolgendo  elaborazione.  Quindi  i  client  sono  dei  programmi  che  stanno  svolgendo 
elaborazione e che hanno bisogno di dialogare con degli utenti in rete 
 
¾ Quindi  la  nostra  macchina  è  un  X‐server,  perché  offre  i  servizi  di  video,  tastiera  e  mouse  ad 
un’applicazione che gira da qualche parte in rete 
 
Si  tratta  di  sistemi  eterogenei,  come  messo  in  luce  dal  fatto  che  sull’X‐Server  abbiamo  due  finestre 
corrispondenti a due sistemi diversi tra loro. 
La sicurezza intrinseca di X‐Windows è molto bassa. Al livello di autenticazione tipicamente si basa sugli 
indirizzi IP. Vediamo tutti i meccanismi possibili di autenticazione: 
 
¾ indirizzi IP ( xhost +host ) 
¾ cookie : a partire da X11R4 è possibile usare i cookie, che sono un segreto condiviso con 
i quali è possibile poter fare una sfida di tipo simmetrico 
¾ Kerberos V5 : a partire da X11R6 
 
Notiamo  che  queste  sono  opzioni,  ovvero,  come  già  detto  il  default  è  l’indirizzo  IP,  ma  avere 
autenticazione debole significa che con le primitive di X11 (es. xwindump) posso catturare tutto l’I/O del 
terminale grafico (sia parte grafica che parte testuale) senza bisogno di fare sniffing! Per questo motivo 
ad oggi si tende a non usare più X‐windows senza i dovuti meccanismi di protezione al livello inferiore, 
ma lo si appoggia a IPsec o come minimo su SSH (la cui caratteristica è quella di creare un tunnel su cui 
veicolare protocolli di livello superiore). 
 
Protezione della chiave private 

Il problema della protezione della chiave private l’abbiamo già citato prima, ma adesso lo riesaminiamo 
in questo contesto.  Tipicamente il problema della protezione della chiave private è grosso quando deve 
essere usata automaticamente da un qualche processo come ad esempio capita nel caso dei server. Il 
modo  più  facile  è  quello  di  lasciarla  in  chiaro  dentro  un  file  :  è  molto  facile  ma  richiede  la  protezione 
complete  del  server.  La  seconda  possibilità  è  lasciare  questa  chiave  in  un  file  criptato  con  una 
poassword, vuol dire che nel momento in cui si f ail boot del server deve essere presente una persona 
per  l’immissione  da  console  una  passphrase  che  permetta  di  decifrare  questo  file  e  di  mettere  la 
versione decifrata non su disco, bensì in RAM. La cosa è un pochettino meglio, ma se qualcuno riesce ad 
avere  i  privilegi  di  sistema  può  esaminare  tutta  la  memoria  RAM  (non  solo quella  del  suo  processo)  e 
quindi andarsi a leggere la chiave.  In particolare ci sono dei piccolo programmi che analizzano tutto il 
contenuto  della  RAM  e  beccano  a  colpo  sicuro  dove  sono  le  chiavi.  La  cosa  può  sembrare  strana  in 
quanto  in  RAM  non  c’è  un’indicazione  esplicita  di  dove  si  trovino  le  chiavi.  In  realtà  le  chavi  sono 
random,  mentre  tutto  il  resto  che  si  trova  in  RAM  ha  una  sua  regolarità,  quindi  semplicemente 
analizzando la distribuzione casual e facendo un raffronto si può andare a reperire in RAM la chiave. La 
soluzione migliore è che le chiavi non vengano date ma vengano memorizzate su un dspositivo sicuro e 
poi sarà lui ad occuparsi di fare le dovute operazioni crittografiche (ovvero il concetto di SMART‐CARD 
che abbiamo già visto). 

Sicurezza degli accessi remoti a DBMS 

Dipende fortemente da come noi andiamo a sviluppare la nostra applicazione. Quindi:  

¾ Se  usiamo  ancora  il  vecchio  stile,  ovvero  collegarci  in  emulazione  di  terminale,  cosa  che  chi 
sviluppa un sistema modern non usa più ma che in realtà è ancora presente in tantissimi sistemi 
per eredità dei vecchi sistemi, allora faremo emulazione di terminale su canale protetto (quindi 
SSL‐telnet, SSH, e così via) 
¾ Se accediamo al DB tramite interfaccia WWW, anche qui la soluzione è abbastanza semplice in 
quanto  dovremo  applicare  la  protezione  del  Web  (SSL),  più  sarà  un  nostro  pensiero  vedere 
come il server web si college al database 
¾ Il  vero  problema  degli  accessi  a  database  è  in  modalità  client‐server.  Ossia  quando  al  client  è 
permesso fare direttamente via rete delle query al server, come ad esempio si fa sfuttando JDBC 
o ODBC. Qui la soluzione non è banale infatti JDBC o ODBC sono API, non sono un protocollo di 
rete, perchè non esiste l’SQL via rete. Non esistendo un protocollo via rete, non esiste nemmeno 
un  metodo  standard  per  renderlo  sicuro.  Ecco  quindi  che  in  questa  situazione  ci  sono  due 
approcci: 
ƒ Approccio  Microsoft  :  facciamo  sicurezza  ad  un  livello  inferiore,  quindi  si  usa 
IPsec su qualunque canale verso un database. In questo modo qualunque cosa 
ci passi sopra sarà sicuro 
ƒ Chi  controlla  l’applicazione,  dirà  di  usare  le  estensioni  che  rendano  sicuro  il 
dialogo  client‐server  indipendentemente  dalla  rete  su  cui  il  dialogo  sta 
avvenendo 
Entrambe le cose hanno una loro validità. Nell’approccio di Microsoft si vede l’ottica di chi ha il 
controllo forte e sistemistico dell’intera struttura, che quindi vuole potersene fregare di quello 
che fanno le applicazioni in quanto Microsoft ha l’Active Directory con cui lui stabilisce le policy, 
e tutti i nodi della rete andranno su IPsec . Invece nell’approccio dello sviluppatore applicativo 
che  è  responsabile  solo  dell’applicazione,  ma  non  sella  configurazione  sistemistica,  risente 
tantissimo  di  quell’ottica,  e  quindi  tende  ad  una  sicurezza  auto‐consistente  all’interno 
dell’applicazione.  Entrambe  le  strade  hanno  dei  pro  e  dei  contro.  Sulla  parte  IPsec  in  questo 
momento  non  ci  soffermiamo,  consideriamo  invece  ina  delle  soluzioni  proposte  da  Oracle  per 
rendere sicuri i propri dialoghi. Questa è ovviamente una soluzione custom. 

Oracle SNS 

Oracle offre un servizio che si chiama SNS, che è un add‐on per la sua parte di rete. E’ da notare infatti 
che ogni fornitore di database ha anche un suo sistema per veicolare l’SQL di rete, quindi Oracle ha il 
suo sistema SQL*NET e sopra questo ci può anche metter sopra SNS. Permette di autenticare client  e 
server e protegge i dati (query, update, risposte) da intercettazione (data encryption), modifiche (data 
integrity) , cancellazione (data filtering). L’SNS come soluzione di sicurezza risulta applicabile a: 

¾ DB Oracle centralizzato/distribuito 
¾ DB federato con parti non Oracle : ricordiamo che un DB federato è un DB distribuito tra nodi di 
diversi produttori 
 
Alcuni vantaggi insiti nell’uso di SNS sono: 
 
¾ non richiede modifiche alle applicazioni esistenti 
¾ non richiede dispositivi hardware 
 
Quindi è un po’ il concetto di SSL applicato al mondo dei database. 

SNS ‐ schema funzionale 

Noi abbiamo la nostra applicazione che già usa SQL*NET, e quello che facciamo è introdurre tra lo strato 
SQL*NET e la rete lo strato SNS. Notiamo che questa parte SNS ha due interfacce: 

¾ da un lato verso SQL*NET, quindi la libreria applicativa 
¾ dall’altra  parte  verso  Oracle  NPA,  network  protocol  adapter,  l’altro  strato  di  libreria  di  Oracle 
per permettere di fare query su qualunque tipo di rete 

Nel passaggio da sopra a sotto i dati diventano da non protetti a protetti. Ovviamente in ricezione ci sarà 
il  duale.  Se  vogliamo  applicarlo  anche  elementi  non  Oracle  il  vincolo  è  che  bisogna  avere  SQL*NET: 
quindi io posso anche avere un PC Windows con Foxpro o Access, ma devo avere la libreria SQL*NET e 
anche SNS. Analogamente potrei anche avere un mainframe IBM con sistema operativo MVS e un certo 
database,  in  questo  caso  dovrò  avere  un  modulo  aggiuntivo  chiamato  “Oracle  Open  Gateway”  per 
permettere al database con formato diverso da quello standard Oracle di parlare con SNS, quindi anche 
qui sono richiesti SNS e SQL*NET, quindi questo è quello che serve per le parti federate. 

SNS ‐ supporto cross‐protocollo 
 

 
SNS  non  è  specifico  per  un  protocollo  di  rete.  Visto  che  SNS  si  appoggia  su  NPA,  analogamente  può 
essere  usato  su  qualunque  tipo  di  rete.  NPA  supporta  quasi  50  tipi  di  rete  diversi.  Grazie  a  questa 
proprietà, SNS funziona anche cross‐protocollo. Notiamo i due tipi di rete che sono diversi. Nel qual caso 
SNS  creerà  un  canale  logico  sicuro,  ma  di  fatto  poiché  in  termini  di  pacchetti  di  rete  ci  saranno  due 
formati  diversi,  ci  dovrà  pur  essere  in  mezzo  tra  queste  due  reti  un  modulo  che  faccia  le  dovute 
conversioni tra i due formati di rete diversi. Questo modulo lo si indica in figura con il nome di Oracle 
Multiprotocol Interchange.  SNS è integrato in Oracle MultiProtocol Interchange, che fa da gateway. SNS 
lavora  quindi  al  livello  di  payload  applicativo  ed  è  per  questo  che  è  indipendente  dal  livello  rete 
sottostante.  Oracle  MultiProtocol  Interchange  permette  di  avere  un  cambio  di  protocollo  senza 
rimettere i dati in chiaro, il che si traduce in velocità e soprattutto inattaccabilità. 

Crittografia in SNS 
 
Per la parte di crittografia, viene negoziato l’algoritmo all’apertura della connessione tra client e server: 

¾ ce n’è uno di default 
¾ nel caso in cui il default sia diverso tra client e server, allora si ricorre alla negoziazione 
¾ possibile  rifiuto  della  connessione,nel  caso  in  cui  il  livello  di  sicurezza  non  sia  ritenuto 
sufficiente 
 
Si può richiedere l’attivazione automatica della sicurezza ma bisogna fare attenzione in quanto il campo 
dei database è il campo in cui si presta attenzione alle prestazioni fino al centesimo di secondo, quindi 
avere  tutta  la  parte  di  sicurezza  produce  un  calo  di  prestazioni.  Ecco  perché  l’attivazione  automatica 
della sicurezza: 
 
¾ per default può essere disattivata 
¾ attivazione automatica e trasparente quando ci si collega ad un server che la richiede 
 
Vantaggi di SNS 
 
Già a partire da Oracle 7 non venivano mica trasmessi in chiaro username e password ma si usava un 
sistema  a  sfida,  però  c’è  un  problema.  Infatti  molti  server  lasciano  in  chiaro  i  cambiamenti  di 
password,perché il server deve conoscere la password in chiaro, e in ogni caso viene lasciato in chiaro la 
trasmissione dei dati quindi abbiamo bisogno di un qualche meccanismo per proteggere le trasmissioni. 
SNS crittografa tutta la sessione e quindi elimina questi problemi 

 
 
 
SNS ‐ identificazione ed autenticazione degli utenti 
 
Per quanto riguarda l’ identificazione e l’autenticazione degli utenti, SNS è neutrale e supporta tantissimi 
sistemi di autenticazione tramite accordi esclusivi , questa è una delle potenze quando uno è veramente 
leader  di  mercato,  perché  io  accetto  il  tuo  sistema  ma  tu  non  puoi  darlo  a  nessun  altro  venditore  di 
database. Ecco le soluzioni: 
 
¾ Banyan ‐ Universal StreetTalk 
¾ login singolo di rete 
¾ Bull ‐ Integrated System Management 
¾ SESAME 
¾ identificazione basata su token 
¾ CyberSAFE – Challenger 
¾ Kerberos V5 (V4, DCE) 
¾ applicativi kerberizzati 
¾ GSS‐API 
¾ ICL – AccessManager 
¾ login singolo di rete 
¾ A: RACF, ACF2, TopSecret, DCE, Kerberos 
¾ I: SDI SecurID, PCSL StopLockV, RACF Passticket 
¾ Identix – TouchSafeII 
¾ verifica delle impronte digitali 
¾ interfaccia ISA 
¾ Security Dynamics Technologies – SecurID 
¾ autenticatore hardware 
¾ PIN + numero casuale (cambia ogni minuto) 
 

SNS ‐ integrità dei dati 

Per  garantire  integrità  (e  quindi  anche  autenticazione)  dei  dati,  SNS  usa  MD5  come  checksum  (basata 
anche  sulla  chiave),  checksum  che  normalmente  non  è  inserita  ed  è  inseribile  a  richiesta.  SNS 
opzionalmente: 
 
¾ numera i pacchetti 
¾ controlla che non ne manchino e non ci siano duplicati 
¾ arresta il sistema in caso di attacco 
 
Per la protezione del canale invece si utilizzano algoritmi standard. 

Sistemi di pagamento elettronico 

Si  intende  quindi  il  modo  in  cui  noi  possiamo  sviluppare  delle  applicazioni  che  permettano  di  pagare 
merce che noi abbiamo acquistato su Internet. Inizialmente era stato proposto un tentativo di creazione 
della  moneta  elettronica,  tentativo  fatto  da  DigiCash  e  che  si  è  tradotto  in  un  fallimento  forzato  per 
problemi tecnici e normativi , perché c’erano molte paure sul fatto che con la moneta elettronica fosse 
più  semplice  fare  riciclaggio  di  denaro  sporco.  Quindi  nonostante  il  sistema  dal  punto  di  vista  tecnico 
fosse valido, è stato distrutto.  Attualmente il metodo più usato è trasmissione del numero di carta di 
credito  su  canale  SSL,  che  però  non  garantisce  contro  le  frodi:  VISA  Europa  dichiara  che  il  50%  dei 
tentativi  di  frode  nascono  da  transazioni  Internet,  che  però  sono  solo  il  2%  del  suo  volume  d’affari! 
Questo non perché Internet è il posto in cui si rubano le carte di credito, ma perché Internet è il posto 
dove più facilmente posso utilizzare le carte di credito che ho rubato, perché se vado in un negozio devo 
avere  con  me  la  carta  di  credito,ma  se  io  ho  sbirciato  i  numeri  allora  posso  usarli  più  facilmente  su 
Internet.  

Sicurezza delle transazioni basate su carta di credito 

Inizialmente c’erano due standard in competizione tra loro: 

¾ STT (Secure Transaction Technology) 
¾ VISA + Microsoft 
¾ SEPP (Secure Electronic Payment Protocol) 
¾ Mastercard, IBM, Netscape, GTE, CyberCash 
¾ SET = STT + SEPP (Secure Electronic Transaction) 
 
Poi era stato creato uno standard comune chiamato SET. Lo standard SET è un bellissimo caso di studio 
per far vedere come non si realizza una soluzione di sicurezza. E’ un protocollo che è morto e sepolto. La 
sua  sperimentazione  fu  fatta  per  la  prima  volta  alle  Olimpiadi  di  Atlanta  e  da  allora  non  ha  più  avuto 
alcuna applicazione pratica. Non si tratta di problem tecnici, quanto più di problem organizzativi. 

SET (Secure Electronic Transaction) 

SET non è un sistema di pagamento ma un insieme di protocolli per usare in rete aperta in modo sicuro 
un’infrastruttura  esistente  basata  su  carte  di  credito.  SET  usava  certificati  X.509v3  dedicati 
esclusivamente  alle  transazioni  SET,  quindi  avevano  dei  key  usage  per  indicare  che  quel  certificato 
poteva essere usato specificatamente con SET. Era stato pensato bene dal punto di vista tecnico, perché 
assicurava  la  privacy  degli  utenti  perché  mostra  a  ciascuna  parte  solo  i  dati  che  le  competono,  senza 
permettere a chi intercettava i dati di leggere né i dati del certificato né i dati della carta di credito. 
 
Caratteristiche di SET 
¾ versione 1.0 (maggio 1997) 
¾ digest: SHA‐1 
¾ crittografia simmetrica: DES 
¾ scambio chiavi: RSA 
¾ firma digitale: RSA con SHA‐1 
¾ www.setco.org : fino all’anno scorso esisteva questo sito, adesso non esiste più 
 
Architettura di SET  

Dal punto di vista architetturale, SET era fatto nel seguente modo. Innanzitutto, quando noi ci rechiamo 
in un negozio e vogliamo pagare con carta di credito ,esiste già la rete che verrà usata per effettuare il 
pagamento e mettersi quindi in contatto con chi ha emesso la carta. I vari fornitori (Visa, Mastercard..) si 
chiamano Issuer. Però tipicamente non si chiede direttamente all’issuer, bensì all’acquirer (es. la banca), 
ovvero colui che procaccia clienti per conto dell’Issuer, e l’acquirer sarà il mediatore tra il negoziante e 
gli issuer, perché il negoziante ospita o direttamente nelle linee telefoniche o nell’architettura di SET IL 
payment  gateway,  ovvero  il  punto  di  scalo  tra  la  rete  non  protetta  e  la  rete  protetta  per  pagare.  Il 
merchant deve essere dotato del software SET, e dall’altra parte c’è invece un card holder ovvero colui 
che possiede una carta di credito e vuole effettuare il pagamento. 

Attori in SET 

¾ cardholder 
¾ legittimo possessore di una carta di credito aderente a SET, e deve quindi possedere il 
SET wallet (borsellino SET). Questo è un software particolare che deve essere installato 
sulla macchina da cui il card holder sta effettuando il pagamento 
¾ merchant 
¾ venditore di un prodotto via Internet (Web o email), sul suo sito web ci deve essere il 
software SET  
¾ issuer 
¾ istituto finanziario che ha emesso la carta di credito dell’utente 
¾ acquirer 
¾ organizzazione  finanziaria  che  stabilisce  un  rapporto  col  mercante  e  lo  interfaccia  con 
uno o più circuiti di pagamento. Devono generare certificati X.509 per il merchant,per il 
card  holder,  e  per  il  payment  gateway,  quindi  deve  esistere  tutta  l’insfrastruttura  di 
certificazione che distribuisce i certificati a questi attori 
¾ payment gateway 
¾ sistema  che  traduce  transazioni  SET  nel  formato  richiesto  dal  circuito  di  pagamento 
dell’acquirer 
¾ certification authority 
¾ emette certificati X.509v3 e CRL X.509v2 per tutti gli altri attori di SET 
 
Doppia firma SET 

Il  punto  che  protegge  la  privacy  è  la  cosiddetta  doppia  firma.  In  questo  modo,  quando  io  faccio  un 
acquisto al merchant non vengono fatti sapere gli estremi del pagamento, quindi il negoziante non verrà 
mai  a  sapere  qual  è  il  mio  numero  di  carta  di  credito  (quindi  la  situazione  è  completamente  diversa 
rispetto ai pagamenti fatti con SSL). Alla banca non viene mai fatto sapere quale merce si è acquistata.  
Ecco quindi come si implementa questo concetto di doppia firma : 
 
¾ al merchant non vengono fatti sapere gli estremi del pagamento 
¾ alla banca non viene fatto sapere quale merce si è acquistata 
¾ solo l’utente può dimostrare l’associazione tra merce e pagamento in caso di contestazione 
 
Ma  come  si  realizza  l’ultimo  punto?  Come  può  l’utente  dimostrare  l’associazione  tra  merce  e 
pagamento?  

Doppia firma SET: dettagli 

Indichiamo  con  PI  (Purchase  Information)  i  dati  di  pagamento,  e  con  OI  (Order  Information)  le 
informazioni relative alla merce che sto acquistando. La firma digitale SET è fatta nel seguente modo: 

¾ io calcolo l’hash dei dati di pagamento, e l’hash dei dati relativi alla merce che sto acquistando 
 
¾ queste due cose le concateno e ne calcolo ancora l’hash, e di questo hash ne faccio la cifratura 
con la mia chiave privata 
o DS = E ( H( H(PI),H(OI) ), Ukpri) 
 
¾ A
Al  merchant  comunico  la  firma  digitale  appe ena  calcolata  e  l’hash  dei  dati  di  pagamento o  
(DS+H(PI)), o
ovvero PI (il mmerchant no on ha i dati d
di pagamento o PI, ma conosce l’OI e può calcolaree 
H(H(PI),H(OI)) verificando che corrisp ponda al valoore estratto dalla firma) 
 
¾ Allo stesso m
A modo, all’acq quirer comunico la firmaa digitale e l’’hash delle informazioni  sulla mercee 
(DS+H(OI)),  ovvero  OI  (l’’acquirer  no
on  conosce  i  dati  riguard
do  la merce  che  sto  acquistando  OI,, 
ma conosce  PI e può calcolare H(H(P PI),H(OI)) verrificando chee corrispondaa al valore estratto dallaa 
f
firma) 

Soltantoo chi ha fatto
o questa firmma, può far vvedere che ii dati PI e OI collimano ee vanno insieme. Questii 
dati  ven
ngono  manteenuti  all’inteerno  del  SETT  wallet,  quindi  sul  nosttro  PC:  noi  ssaremo  gli  unici 
u a  poterr 
dimostraare l’associazzione tra meerce e pagam mento, come già detto. 

Problem
mi di SET 

A questo o punto vediamo di capirre perché SETT è fallito.  
Innanzitutto  il  softtware  neceessario  era molto  carro,  ma  la  cosa  più  p particolare  è  che  eraa 
immotivvatamente  molto m caro:  siccome  neel  1996‐97  c’era  la  fid ducia  nel  business  del  commercio o 
elettronico, si chiedeevano cifre aassurde per  iniziare a lavvorare con il commercio o elettronico : questo haa 
frenato m molto la parttenza di queesto sistema. 
Altro  pro oblema  è  chhe  le  banchee  dovevano  fungere 
f da  CA, 
C perché  dovevano 
d mettersi  loro  a  certificaree 
tutti quaanti i loro clieenti, e le bannche non aveevano nessun na intenzione di fare queesto lavoro.  
Poi  l’altrro  incubo  erra  nel  SET  wallet, 
w un  so
oftware  da  in nstallare  a  casa 
c del  cliente:  è  un  in
ncubo  per  laa 
compatibilità  sia  al  livello  di  S.O
O.  che  degli  applicativi  trra  loro.  Inolttre  chi  inseggnava  all’uteente  a  fare  ill 
backup d del SET walleet per evitaree di perderlaa traccia di tu utti gli acquissti fatti.  
Ecco  quindi  la  grand de  lezione  che 
c stiamo  imparando: 
i qualunque  soluzione 
s di  sicurezza  che 
c dica  chee 
l’utente  deve installaare un softw ware specifico o diventa un n incubo se n non è in amb bito aziendale! Perché in n 
ambito aaziendale posso ancora ssperare nell’o omogeneità di configurazione delle p postazioni di lavoro. 
Con la seconda verssione (2.0) hanno cercato di risolvere questi pro oblemi e rendere SET più ù appetibile,, 
facendo  a meno del SET wallet ee rimpiazzan ndolo con un n browser. O Ossia i wallett venivano virtualizzati ee 
messi  su u  un  wallet  server,  e  l’’utente  si  coollegava  col  browser  :  ma  a  questto  punto  c’e era  un  altroo 
problem ma… chi contrrolla il wallett server? Risposta: nessu uno voleva assumersi questo onere, e quindi SETT 
2.0 non ha mai visto la luce ed è stato definittivamente so oppiantato.

 
Architettura di pagamento via Web 

Abbiamo  detto  che  l’alternativa  è  il  pagamento  via  web.  Vediamo  ora  uno  schema  di  cosa  avviene 
all’interno di un’architettura di pagamento via web: 

¾ Il  cliente  ha  selezionato  la  merce,  e  l’ha  messa  in  uno  shopping  chart  (carrello  virtuale)  e  a 
questo  punto  fa  il  check‐out.  Facendo  il  check‐out  il  merchant  ci  invia  un’offerta  (1)  che  è  il 
riassunto della merce che vogliamo acquistare, alla quale il cliente (cardholder) risponde con un 
ordine (2) 
¾ In teoria se il merchant è un tipo che fa le cose per bene, non dovrebbe chiedermi lui i dati della 
carta di credito, ma dovrebbe reindirizzarmi verso un payment gateway con cui lui ha fatto un 
accordo. Il payment gateway attiverà un canale SSL verso di me per chiedermi i dati della carta 
di credito (4 e 5), garantendoci rispetto ad eventuali buchi di sicurezza del mercante 
¾ Il payment gateway attiverà su di sé un software noto come POS virtuale che a partire dai dati 
della carta di credito mi ricrea tutti quei dati che effettivamente verrebbero prodotti se solo si 
strisciasse la carta di credito in un vero e proprio POS. Inoltre il POS virtuale dialogherà con la 
rete di pagamento usando i protocolli propri del mondo finanziario, non è detto che sia TCP/IP, 
ottenendo un OK (6 e 7) 
¾ Solo se tutto va a buon fine invierà un feedback al merchant per indicare la buona riuscita del 
pagamento (8) e il mercante può spedire l’oggetto. 
 
Notiamo  che  questa  soluzione  si  presta  ad  una  serie  di  problemi:  innanzitutto  non  mi  garantisce  la 
privacy, perché il payment gateway tipicamente fa un brutto lavoro di tenere traccia di quali sono le mie 
preferenze di acquisto (e rivende questi dati a terzi). La seconda cosa è che nel momento in cui faccio 
l’acquisto ci sono dei merchant che chiedono loro la carta di credito, la memorizzano localmente e poi 
provvedono a trasmetterla via FAX o altro. Quindi c’è un grosso problema  di come viene gestito il dato 
della carta di credito. Quindi di per sé l’architettura va bene, il vero problema è come sono gestiti i dati 
della carta di credito.  

Pagamento con carta di credito via Web 

Quindi in caso di pagamento con carta di credito via web, le ipotesi base sono: 

¾ l’acquirente possiede una carta di credito 
¾ l’acquirente ha un browser con SSL 
 
in base a quanto abbiamo detto oggi, la sicurezza effettiva dipende dalla configurazione sia del server sia 
del client perché in SSL c’è una negoziazione, quindi il lucchetto scatta anche quando abbiamo negoziato 
la cifratura a zero bit quindi c’è un problema di educazione degli utenti. Non deve bastare la sola visione 
del lucchetto, ma bisogna vedere innanzitutto chi ha autenticato il server, e poi qual è il livello effettivo 
di cifratura in termini di bit. Inoltre, l’utente non gode di privacy. 
Requisiti di sicurezza per SI di e‐commerce 

Questo problema del fatto che sempre più spesso oggi viene attaccato non il canale SSL, ma il payment 
gateway, nel caso che questo conservi in modo insicuro i dati delle carte di credito, ha fatto sì che Visa 
per  prima  e  poi  tutti  gli  altri  grossi  produttori  di  carte  di  credito  abbiano  attivato    dei  programmi  di 
certificazione per tutti coloro che vogliono attivare dei payment gateway. Quindi Visa non permette di 
attivare  un  payment  gateway  se  non  dopo  il  conseguimento  di  una  certificazione.  Ogni  issuer  però 
faceva la sua certificazione, quindi stava per diventare un casino:  
 
¾ Visa: 
¾ (2000)  Account  Information  Security  (AIS)  program  for  EU  and  the  Cardholder 
Information Security Program (CISP) for USA 
¾ (2001) programs mandatory for all members, merchants and service providers  
¾ other security programs: 
¾ MasterCard requires Site Data Protection (SDP) 
¾ American Express requires DSOP 
¾ Discover requires DISC 
¾ … 
 

ecco perché alla fine si sono accordati ed esiste uno standard molto importante che si chiama PCI‐DSS 
(Payment Card Industry – Data Security Standard). Oggi è richiesto da tutte le carte di credito per tutte 
le  transazioni  in  Internet,  quindi  chiunque  voglia  mettere  in  piedi  un  payment  gateway  deve  avere 
questa certificazione altrimenti non potrà collegarsi alla rete finanziaria. 

PCI DSS 

Rispetto  ad  altri  standard  che  esistono  in  giro  e  che  dicono  come  implementare  la  sicurezza  nel  SI, 
questo standard è molto più prescrittivo, ovvero indica proprio quali sono le soluzioni da adottare.  

Requisiti PCI DSS 

Al fine di far capire cosa si intenda per “standard prescrittivo”, vediamo quali sono le regole 

¾ costruire e mantenere una rete protetta: 
o R1  =  installare  e  mantenere  una  configurazione  con  firewall  per  proteggere  i  dati  dei 
titolari delle carte (non ci limita sul produttore, ma ci dice che ci deve essere!) 
o R2 = non usare password di sistema predefinite o altri parametri di sicurezza impostati 
dai  fornitori  (in  passato  con  Oracle  erano  state  mantenute  all’atto  dell’installazione  le 
password di default…alla fine tutti si facevano le copie dei database) 
¾ proteggere i dati dei titolari delle carte: 
o R3 = proteggere i dati dei titolari delle carte memorizzati (quindi se li manteniamo noi, 
dobbiamo  garantire  che  il  File  System  sia  sicuro  o  che  i  sistemi  che  mantengono  quei 
dati non siano manipolabili) 
o R4  =  cifrare  i  dati  dei  titolari  delle  carte  quando  trasmessi  attraverso  reti  pubbliche 
aperte (incluse qualunque rete wireless, qualunque cosa vada su onde radio!) 
¾ rispettare un programma per la gestione delle vulnerabilità 
o R5 = usare e aggiornare con regolarità l’antivirus 
o R6 = sviluppare e mantenere applicazioni e sistemi protetti 
¾ implementare misure forti per il controllo accessi 
oR7 = limitare l’accesso ai dati dei titolari delle carte solo se effettivamente indispensabili 
per lo svolgimento dell’attività commerciale (principio del need to know: un operatore 
dovrebbe avere accesso alla minima quantità di dati necessaria per lo svolgimento delle 
sue mansioni. Purtroppo per semplicità sempre più spesso a seguito dell’autenticazione 
si da accesso al database direttamente.) 
o R8  =  dare  un  ID  univoco  ad  ogni  utente  del  SI  (quindi  NO  AGLI  ACCOUNT  DI  GRUPPO, 
ognuno deve essere responsabile delle proprie azioni) 
o R9 = limitare la possibilità di accesso fisico ai dati dei titolari delle carte 
¾ monitorare e testare le reti con regolarità 
o R10 = monitorare e tenere traccia di tutti gli accessi effettuati alle risorse della rete e ai 
dati dei titolari delle carte (vogliono un elenco di chi sta facendo cosa sulla rete) 
o R11 = eseguire test periodici dei processi e dei sistemi di protezione 
¾ adottare una Politica di Sicurezza 
o R12 = adottare una Politica di Sicurezza (documentata, perché questa è anche una cosa 
che vedranno all’atto della verifica per ottenere la certificazione) 

Questi punti vanno rispettati tutti e 12, non in parte!