On Thu, Jul 24, 2008 at 09:36:44AM +0200, magnus wrote: > > heu... à quelle moment est-il obligatoire d'acheter des clés pour > utiliser Ipsec? A partir du moment ou tu veux créer un processus semi-public qui autoriserai n'importe qui à s'autentifier de manière ``sûre''...
> On m'aurait menti? :-) probablement une question d'interprétation... > > De fait, la gestion et la maintenance des clefs pour l'ensemble > > du processus de confiance est complexe et tend à la sous-traitance. > > De fait égallement la confiance partagée et gérée par des organismes > > tiers, souvent basé hors de nos frontières, est tâchée d'erreures > > d'enregistrement (par laxisme, bien souvent, les abus, fausses > > déclarations etc sont très faciles.) > > de quoi est-il question ici? je ne comprends pas la référence. En gros, il y a deux écoles: - L'autonomie absolue qui permet à un organisme de gérer lui-même ou avec des tiers de confiance reconnus (identifiés physiquement, rencontrés de visu, etc.) - La diligence à des autorités délégués (pyramidale) dépendante de structures étasuniènnes essentiellement. Hors le système ``centralisé'' à déjà été l'objet de plusieurs ``affaires'' liées au sérieux et à l'éthique des acteurs situés au sommet de ladite pyramide. (dépot de domaine ``*.com'' par verisign, dépot de domaine du type police-de-geneve.ch avec réalisation de clef de signatures autentifiées par la pyramide, correspondante au site, avec des adresses civiles valables et vendues à des individus totalement étrangers aux organismes officiels) > > Par conséquent le niveau de confiance que JE concède à ce système > > est nettement inférieur à ce que je peux comprendre et apréhender > > de manière autonome et reconnue au sein d'un groupe d'utilisateur > > donné. > > Encore une fois, je ne comprends pas ce qui est moins obscure dans IPSec ou > dans OpenVPN? IPSec n'est pas obscure par lui-même, mais complexe à mettre en oeuvre. La gestion des clefs est elle-même d'une complexité redoutable. Mais ce sont les implémentations propriétaires qui en sont faites qui sont obscures (accès aux codes source des routeurs CISCO, p.ex) (Pour la petite histoire, à chaque observation de réseau TCP gérée par des routeurs CISCO, avec des outils comme tcpdump, je me trouve avec un traffic de l'ordre de 1 à 15% de la bande passante, que je ne peux pas expliquer.) > On compare ici, il me semble, un logiciel et un protocole (qui n'est pas > propriétaire mais implémenté différemment par nombre de fabriquant, > comme TCP :-) ). > ... Hem oui, sauf que TCP est nettement plus facile à comprendre qu'IPSec, d'une part et d'autre part, les divergence entre constructeurs sont ``lisibles'', ce qui pour IPSec n'est par définition pas le cas. ... > > > > Si le but est d'obtenir la même fonctionnalité, alors > > ma recommendation est de firewaller, natter, tunneliser > > et même tunner avec linux (ou bsd;-)... > > Les gens qui achètent des "appliances" de sécurité le font pour se > simplifier la vie car ils n'ont pas envie de faire une gestion comme tu la > décris et pour la sensation de confort qu'elles amènent. > Par contre, à partir du moment où on a qqch qui sort de la norme, on se > retrouve seul. OpenVPN ne ``sort'' pas de la norme. Il tend à devenir une norme par lui-même... De plus, je préfères la perspective de planter un jeune ingénieur seul sur OpenVPN (~24 heures d'apprentissage/ 1 à 2 semaine) que sur IPSec. (~120 heures / 2 à 4 mois)** > > Nettement plus accessible à court terme et plus viable > > à long terme. > oui et non, car cela implique des connaissances qui ne sont pas forcément > nécessaires dans le cas de l'"appliances" (tant qu'on a le mot de passe et > on sait qu'il existe, mais c'est le même problème pour toute les > solutions). Dans le cas de petites structures, où une méthode ``user-only'' est nécessaire, la réalisation d'un réseau de tunnels sécurisé peut être confiée à un prestataire de service contacté localement (c.f. gull-commercial), pour une implémentation idoine. Le final ne sera pas forcement moins cher qu'une solution CISCO, mais maitrisée dans son ensemble et réalisée sur-mesure pour répondre à des besoins précis, elle sera nettement plus sûr et plus souple pour son évolution. (pas de limite de connexions simultanées ou de tunnels définis). ** Apréciation toute personnelle à ne pas considérer comme référence absolue. Dépend des capacités personnelles de l'ingénieur à l'ouvrage. -- Félix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch _______________________________________________ gull mailing list [email protected] http://forum.linux-gull.ch/mailman/listinfo/gull
