Newsgroup: it.comp.sicurezza.varie
Titolo: Domanda ...

Mi sto' documentando sui vari metodi di sicurezza (Virtual Private
Network), e mi sono imbattuto in qualcosa di strano. Parlando di dati
crittografati, il manualetto cita come esempio il "Encrypted Tunnel Mode":
Il pacchetto IP completo (Header + Payload) viene crittato e "inserito"
(Tunneling) in un'altro pacchetto IP.
La mia domanda e': Dato che un Header IP ha piu' o meno sempre la stessa
struttura, comparando l'header crittato e quello che immaginiamo possa
essere l'header originale, non si puo' in qualche modo ricavare
informazioni sulla chiave usata ?
Probabilmente avrete intuito che quel poco che so' di criptologia l'ho
letto 10 minuti fa' su 3-4 pagine striminzite :-) ...
 __                                                              _  ///
| _        Student in Computer Science, Swiss Federal Institute  \\///
|__|iambo      of Technology - mailto:
ggia...@iiic.ethz.ch
       \X/

informazioni sulla chiave usata ?
Forse ti e' sfuggito che la implementazione di una VPN, mediante IPSec o chi
per essa, fa in modo che l'header che viene incapsulato e criptato NON sia lo
stesso che rimane in chiaro ed e' preposto ai dati criptati. Altrimenti come
potremmo giocare in termini di reti WAN virtuali se i due header fossero gli
stessi ? :)
Immagina che i due router di due LAN ad una distanza qualsiasi da loro, 
manipolino i pacchetti in uscita verso la LAN opposta incapsulandoli in altri 
pacchetti. Con questo tunnel avremo gli header in chiaro con gli indirizzi e
dati dei due router, e magari criptati header IP con opzioni od altro ma con
indirizzi diversi, anche di IP privati ad esempio, o magari con un altro tunnel
e magari, usando IPSec, con strati multipli mediante ESP e AH .... a quel
punto derivare la chiave confrontando un cypher ed un clear-text CHE NON SONO
LO STESSO DOCUMENTO :) e' dura risalire ad alcunche' .....
Oltretutto in una tua applicazione per VPN non e' detto che tu debba inserire
dei pacchetti IP in IP .... potresti mettere solo l'header TCP dopo i due ip di
src e dest, ma senza il resto e far lavorare i router per riassemblare a
dovere .....
invy 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GSS/TW/O>AT d?(dx) s+:+, s: a-->a- C++(C+++) UL+++>UL++++ P+ L+++>L++++
E-- W(W-) N++ K? w-- O- M- V- PS++ PE Y+ PGP++ t++@ 5 X+ R+(R++) tv b+++
DI+++@ D+ G>G++ e++ h r+(r-) y++*
------END GEEK CODE BLOCK------

informazioni sulla chiave usata ?
Se il protocollo e` scritto da persone competenti questa cosa viene
considerata e non e` un problema.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

dato che sul loro sito sventolano il metodo a destra e a sinistra :-) ...
Un RFC, quello deputato a ESP, o encapsulating security payload, necessario
per le VPN sotto IPSec si preoccupa anche di questo. In teoria dopo l'header
IP in chiaro che viaggia, c'e' questo ESP che precede un header TCP e dati
che sono entrambi criptati. Interessante notare la possibilita' di usare un
padding all'interno di ESP che possa essere deciso a priori dai router, ma
non noto ad uno snooper esterno in modo da aumentare la confidenzialita' dei
dati non sapendo infatti dove sia il cypher del clear che hai in mano.
Aggiungerei il fatto che ad ogni iterazione del security number di ESP tu
magari debba per forza negoziare una seconda chiave. Questo renderebbe piu'
ostico il processo di derivazione di una chiave che non sia piu' usata
immediatamente nella connessione seguente.


 riassemblare a dovere .....
Ma in linea di massima so' cosa usa la ditta produttrice del soft per VPN,
dato che sul loro sito sventolano il metodo a destra e a sinistra :-) ...
                                                                     __


 considerata e non e` un problema.
Allora la ditta che sta' per comperare il soft e' a rischio :-) ... Per
curiosita', come si fa' ad evitare la situazione ? 


curiosita', come si fa' ad evitare la situazione ? 
Si usa una implementazione di IPSEC (ce ne sono?) o di altri protocolli
non proprietari.
PPTP e` da scartare. :-)


 PPTP e` da scartare. :-)
Bah, ormai la comanda e' partita, i soldi sono stati versati e non si puo'
piu' fare niente :-) ... E poi mi vedi, pivellino appena arrivato in
ditta, a consogliare i Vecchi Guru ? E poi, chissenefrega, che fra 3
settimane me ne vado via dalla ditta :-) ?
