IPsec: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Bot: passaggio degli url da HTTP a HTTPS |
mNessun oggetto della modifica |
||
Riga 72:
'''Authentication Header''' (abbreviato '''AH'''), è un protocollo che fa parte della suite IPsec. Il suo compito è quello di fornire un controllo di integrità pacchetto per pacchetto, verifica dell'autenticità del mittente e protezione contro i [[replay attack]]. AH non garantisce in alcun modo la confidenzialità del messaggio.
L'autenticità è garantita tramite funzioni di
Il ''peer'' remoto riceve il messaggio; dato che questo è in chiaro, lo può leggere, combinare con la chiave di cui è a conoscenza e calcolare il checksum. Se il checksum corrisponde a quello inviato, il messaggio è autentico e viene accettato altrimenti viene scartato in quanto è stato modificato in un modo non consentito dallo standard.
Riga 145:
La linea azzurra indica le zone del pacchetto che sono autenticate. Dal punto di vista della protezione, in entrambi i casi, i pacchetti vengono protetti completamente. Notiamo che nell'header IP, alcuni campi variano durante il transito nella rete, ad esempio il [[Time to live|TTL]].
Questi campi vengono posti a '''0''' prima di calcolare la [[funzione di
===Encapsulating Security Payload (ESP)===
Riga 228:
Le linee azzurre sottendono la parte di pacchetto che viene sottoposta a controllo di autenticità e integrità; le zone verdi indicano le zone di pacchetto che vengono protette tramite algoritmi crittografici. Per quanto riguarda gli algoritmi di cifratura possono essere utilizzati [[Data Encryption Standard]] (DES), [[3DES]], [[Advanced Encryption Standard|AES]] e [[Blowfish]].
Il controllo di integrità e autenticità viene eseguito tramite [[HMAC]] (funzioni di
l'hash viene calcolato tramite una funzione di hash ([[MD5]] o [[SHA1]]), utilizzando una chiave condivisa; l'hash ottenuto viene allegato al messaggio e inviato. In ricezione viene controllata l'integrità del messaggio. Come illustrato negli schemi, l'indirizzo IP più esterno non viene coperto dal controllo di integrità. Tale opzioni rende il protocollo ESP adatto ad essere utilizzato in alcuni tipi di [[Network address translation|NAT]], in particolare in quelli statici. Tuttavia esistono soluzioni ''ad-hoc'' per il funzionamento congiunto di IPsec e NAT, come il NAT traversal.
Riga 242:
In genere, nei dispositivi preposti alla gestione dei tunnel IPsec e nei client VPN, il NAT-T non è abilitato di default ma deve essere impostato a mano; tuttavia il suo utilizzo rimane opzionale: difatti durante la creazione della '''security association''', i peer determinano se uno dei due subisce operazioni di NAT e solo in questo caso viene usato il NAT-T; questa operazione viene fatta durante la prima fase della negoziazione '''IKE'''.
In prima battuta, i ''peer'' verificano che entrambi siano in grado di supportare in NAT-T; questa verifica è eseguita nella primissima fase del protocollo IKE, per mezzo di un pacchetto con un campo ''Vendor-ID'', che contiene un valore
Una volta stabilito che entrambi supportano il NAT-T, vengono inviate delle frame "NAT-Discovery" (NAT-D), in modo da verificare chi dei due subisca il NAT, o al limite se lo subiscano entrambi.<br />
Una volta stabilito chi subisce il NAT, la comunicazione si sposta su una nuova coppia di porte UDP e l'entità "''nat-tata''" comincia a inviare delle frame '''keepalive'''; queste frame servono a mantenere fisse le porte di comunicazione sul router e ad impedirgli di riassegnarle ad una nuova comunicazione.
| |||