[ITNOG] BGP Man In The Middle attack / RPKI - ROA - BGP Origin Certification

Gioanola, Marco mgioanola@arbor.net
Dom 16 Feb 2014 15:01:09 CET


Mi intrometto sul tema RPKI anche se non sono un operatore ma un vendor
che con gli operatori e i carrier ci lavora. L'intrinseca fragilitā del
BGP č uno dei campi di cui ci occupiamo, e coi colleghi abbiamo discusso
pių volte di RPKI. Nella mia vita precedente mi sono occupato di
crittografia e certificate authorities.

Fatta questa premessa, mi permetto un commento un po' perentorio e
provocatorio: il concetto di Public Key Infrastructure E' FALLITO, e
dovremmo metterci il cuore in pace e smettere di pensare che possa
risolvere problemi di autenticazione e autorizzazione in larga scala. Il
rischio maggiore di adottare sistemi come RPKI non č quello di "censure"
ordinate da questo o quel tribunale, ma la debolezza intrinseca di un
sistema che si basa su 1) strutture come le Certificate Authorities e le
Registration Authorities che per essere utilizzabili in maniera efficace e
"scalabile" si espongono a notevoli rischi di compromissione, e 2)
meccanismi di controllo delle informazioni (le Certificate Revocation
List) che in realtā non sono utilizzati da nessuno.

Prendiamo ad esempio la debacle Diginotar di qualche anno fa
(https://isc.sans.edu/diary/DigiNotar+breach+-+the+story+so+far/11500),
anche se nel frattempo i casi simili si sono moltiplicati.
Primo problema: la certificate authority č stata compromessa, e sono stati
creati certificati digitali "falsi", che poi sono stati distribuiti e
utilizzati in giro per il mondo per chissā quali scopi. Pensiamo a cosa
succederebbe se (anzi, quando) un caso del genere accadesse con
certificati che garantiscono la bontā di certi annunci BGP
(ipersemplificando).
Secondo: cosa fu fatto per temponare il problema Diginotar? i vendor di
browser http produssero (nemmeno troppo tempestivamente) aggiornamenti
software per rimuovere Diginotar dalle liste dei certificati "trusted"
incluse di default nei browser. Sbagliatissimo. La PKI si basa sul fatto
che per ogni certificato deve esistere una Certificate Revocation List
consultabile in tempo reale: il meccanismo č stato pensato appunto per
evitare procedure demenziali come quella di dover rimuovere il certificato
della CA compromessa da tutti i software che lo utilizzano. Peccato che
nessuno utilizzi le CRL. Il controllo č sempre disabilitato di default;
provate ad abilitarlo e poi mi dite com'č l'esperienza di navigazione
https. Ora, una RPKI che funzionasse *come si deve* dovrebbe controllare
la relativa CRL *ogni volta* che utilizza un certificato di chiave
pubblica di terzi per validare una qualsiasi informazione; vi pare una
cosa realisticamente fattibile? Nel momento in cui si "sorvola"
sull'utilizzo delle CRL, tutto il castello della PKI cade.

Per queste ragioni, RPKI mi sembra soltanto, nel migliore dei casi,
un'illusione.

saluti e scusate per il comizio.


--
Marco Gioanola
Consulting Engineer, EMEA
Arbor Networks
mgioanola@arbor.net
+39 339 7584747 (m)

--> Arbor is at Mobile World Congress, 24-27 February <--

Please be advised that this email may contain confidential information. If
you are not the intended recipient, please notify us by email by replying
to the sender and delete this message. The sender disclaims that the
content of this email constitutes an offer to enter into, or the
acceptance of, any agreement; provided that the foregoing does not
invalidate the binding effect of any digital or other electronic
reproduction of a manual signature that is included in any attachment.





-----Original Message-----
From: Alberto <alberf@gmail.com>
Date: Thursday, February 13, 2014 10:50 PM
To: ITNOG <itnog@lists.itnog.it>
Subject: Re: [ITNOG] BGP Man In The Middle attack / RPKI - ROA - BGP
Origin Certification

[...]
>
>Assolutamente in linea con il tuo pensiero..
>anche se č sempre da tener ben presente l'osservazione di Marco in
>merito al potenziale rischio (di questi tempi.. assolutamente reale)
>di abuso di controllo della rete da parte di burocrati..
>
>Siamo dunque all'interno di un problema np-difficile..
>
>Grazie per il tuo utilissimo contributo Antonio ;)
>
>Alberto
>
>-- 
>Mailing list info: http://lists.itnog.it/listinfo/itnog



Maggiori informazioni sulla lista itnog