Jerome Herman a écrit 1870 commentaires

Attention on va essayer (c'est pas gagné) d'éviter que le troll ne se découvre une pilosité hors du commun.

Mon point est : a investissement égal on peut faire en OpenBSD/x86 a peu près tout ce que fait Cisco au niveau routeur/switch.
Est-ce que c'est intelligent ? Pas toujours, mais la plupart du temps ca va bien.

Par contre si on commence à parler ATM, OpenBSD est d'office dans les choux (du moins sur archi x86).

et ça commute/route/filtre à 72 Mpps, avec des ACLs.

Effectivement OpenBSD ets totalement incapable de faire celà, mais on arrive sur le problème des DSPs. 72mpps c'est quand tous les paquets se "ressemblent" et ce prennent les mêmes règles sur le coin de la gueule. Quand on comemnce à avoir des paquets un poil bizarre les perfs tombent. Les paquets fragmentés que l'on fait remonter jusqu'au niveau (layer) 4 sont redoutables par exemple. Pour résumer il faut présenter les choses comem çà un ruteur Cisco est capable de faire 72 millions de fois la même opération par seconde. Quand les opérations sont variés et qu'il y a des étapes intermédiaires les perfs tombent. (N.B : il y a des cas ou les opérations sont identiques (flux en broadcast à autoriser/refuser par domaine) là on est dans des conditions proches d'un commutateur pur et OpenBSD se fait mettre en pièces )

Par contre niveau routage statefull (on fait la vérif une fois et après on match les motifs) sur un réseau sur lequel les paquest sont très différents (genre IPv4 natif, IPv6 natif, IPv6 encapsulé, taille des paquets variable, réécriture de paquest dynamique, routage vituel conditionnel etc.) pf prend l'avantage dde façon assez nette.

Pour les alimentations, ce sont des alimentations de 1900W
ou 2500W (de mémoire). Par rapport à une 20aine de PC avec
des alims à 400/500W, le compte est vite fait.

il faut compter sur cisco à peu près 20 watts/port en pleine charge (approximation grossière mais qui donne une idée) contre environ 5 watts par port sur PC (+150-200 watts par machine). Un serveur avec une carte graphique minimaliste, et un support de données "stable" (ie pas un disque dur mais de la flash ou un chargement mémoire au boot) ne consomme pas grand chose.

Les chiffres sont grosso-modo équivalent.

Comparer un cluster de PC à un 6500, ça ne rime à rien.

Je suis d'accord (encore que mes PCs ne soient pas en cluster, masi bon). il faudrait un cas d'étude. Il est malheureusement assez faciel de choisir des cas ou l'une ou l'autre des solutions brillera alors que l'autre pédalera.

Sauf qu'il faut compter la conso clim et electrique de tout cet ensemble,

Ca ne sera pas nettement supérieur à la solution Cisco. Les boitiers 6500 consomment pas mal et chauffent aussi.

Sauf qu'il faut compter aussi le supplement de temps pour installer la bete et la configurer, le delta d'effort pour la maintenir en vie, la documenter, ... alors que la solution Cisco est prete a l'emploi.

OpenBSD basique : installation 15 minutes chrono en main pour la première machine, compter 5 à 10 minutes par réplication suivant les disques.
Doccumentation basique : déjà disponible et très détaillée sur le site OpenBSD.org.
Installation/configuration/maintenance des règles de routages - gestion de paquets : nettement plus simple sous OpenBSD que sous Cisco.
Le plus dur est de trouver une personne connaissant un peu OpenBSD, mais après ca roule tout seul.

Sauf que pour passer de 48 a 96 ports va falloir reinvestir lourdement au lieu d'ajouter une carte a chaud dans le cassis,

Si tu prend un chassis 6503 avec un superviseur, un carte 48 10/100 et une carte Firewall (ce qui est l'hypothèse que j'ai prise plus haut et la solution "basique" fournie par Cisco), tu vas le sentir passer aussi le passage en 96 ports, parceque le 6506 en chassis il est pas vraiment donné non plus.
Ensuite tous mes PCs sont en redondance complète. Je peux donc en arréter un et lui coller une ou deux cartes supplémentaires dans les gencives avant de passer au suivant. Certes ca risque d'être assez long (compter 10 minutes par poste en physique et 5 minutes pour la réplication des règles).

Ceci étant effectivement ca reste un des gros avantages de Cisco (ca et la possibilité de mettre un commut ATM dans le bastringue). A condition bien sur de ne pas avoir vu trop juste lors de l'achat du chassis (parceque le trimballage de cartes du chassis (a) vers le chassis (b) c'est un bonheur)

Sauf que l'aggregation de lien ne sera pas possible

Euh... Si sans problèmes. pf+Carp+pfsync permet de faire celà assez facilement. C'est pas full compatible IEEE 802.3ad. mais ca marche très bien quand même. On peut faire de la répartition de charge et/ou de la tolérance au décablage.

De plus HSRP c'est bien mais faudrait plutot faire tourner OSPF qui va consommer aussi des ressources

Je vois pas trop le rapport entre un système de redondance et un protocole de calcul des routes. Le protocole OSPF a de bons cotés, mais il a aussi des défauts. Le premier étant qu'il n'est pas finalisé (ca sent les batchs d'upgrades par flot de 500) et le second est que la gestion des liens extérieurs et des virtual link est à mourrir de rire. Et le protocole a encore pas mal de problèmes avec les selecteurs/commuts/relais (ce qui est un peu con parceque quand on a 8500 routeurs chez soi, donc besoin d'OSPF, on a le plus souvent une des trois bestioles au millieu).

les exemples s'accumulent comme ça par dizaines.

Envoi la suite. J'attend.

maintenant que les brevet sur les logiciels ne sont pas légale,

Perdu, le parlement a préféré ne pas aller au clash face au conseil en procédure de conciliation (ce qui était la seule chose à faire vu le point de vue du conseil et de la commission). Les brevets sont donc toujours soumis à l'appréciation des nations. L'OEB continue à faire ce qu'il veut.

je vous encourage à chercher des brevets logiciels qui ont été déposé à l'OEB

Il s'agit ici de faire un travail de lobying + juriste qui n'est pas du tout à la portée de tout le monde. De plus la plupart des brevets sont encore à l'étude pour validation. Le mieux que l'on puisse obtenir c'est que l'OEB les garde sous le coude en attendant une loi qui leur donne raison.

puis de leur ecrire une lettre concernant le brevet comme quoi, traité de rome, parlement europeen, convention de munich etc...toussa, le brevet untel ne peut pas etre validé.

Ils te répondront que TCE, jurisprudence nationales allemandes et anglaise, consultation européenne et conseil + commission etc. toussa et que le brevet est soumis à l'appréciation des différents tribunaux nationaux.

On a pas gagné la guerre. On a juste évité une défaite cuisante dès la première bataille.

Pour la version à 576 ports, c'est en effet pas gagné.
Parcontre pour le "bas de gamme" à 48 ports avec controlleur ca va assez bien

Pour ce prix là on a sans problème
- 1 armoire 42u
- 20 PC server en 2u
- 20 cartes double fibre optique 1gb/s (premier port pour le cluster, deuxième port libre ou en back up du port cluster)
- 40 cartes ethernet quadruple

en partant du principe de double redondance (redondance routes + hardware) ca fait

10 PC full redondants + 10x8 ports maitres +10x8 ports virtuels maitres + 10 ports maitres gigabits

Niveau fiabilité hardware on est assez tranquille. Niveau controle pf est largement au dessus de ce que fait Cisco sur ses switchs. Niveau vitesse de commut, on est très légèrement en dessous si on reste sur le même node, par contre d'un node à l'autre on rajoute une latence de l'ordre de la milliseconde (soit un facteur 10 pour les règles de routage par rapport à un cisco - facteur 3/4 pour les règles complexe avec altération dynamique des paquets)
Pour la fiabilité et la redondance du routage CARP vaut très largement HSRP/VRRP.
Pour la place on prend a peu près deux/trois fois plus de place.

Pour faire une vraie comparaison il faudrait un cas pratique et pas mal d'argent, ou un gentil boss qui nous laisse faire mumuse avec son matos critique (hautement improbable) et deux pros un pour Cisco et un pour OpenBSD.

Il y a des cas ou hors matériel dédié point de salut (les commuts ATM par exemple) mais le nombre de fois ou Cisco n'est pas la seule et unique solution est bien plus grand qu'on ne pourrait le penser.

On est loin de remplacer les routeurs CISCO par des boites linux si tu veux mon avis, sauf dans les cas de charge ridicules.

Pour les anneries très évoluées ou sous forte charge je ne saurais trop recommander l'utilisation d'OpenBSD. Niveau traitement de paquets il enfonce Cisco quelque chose de violent (à budget équivalent s'entend). Au niveau table de routages adaptives ca se vaut, Cisco est un peu plus rapide en commutation, OpenBSD est plus flexible.

Reste le problème des "switchs" intelligents. La cisco a encore la main haute (notamment dans les applis de multicasting et autres joyeusetés IPV6), mais on peut remplacer par des boitiers Sous Open/FreeBSD dans la plupart des cas (vous en connaissez beaucoup des boite sui utilisent le multicasting mulitmasque IPV6 en forte charge ?)

Pour information j'ai un bi-PII400 avec 1Go de ram qui traite sans broncher 10000 transactions/seconde avec OpenBSD 3.3 (en charge simulée certes).
Pour le prix d'un 6500 il y a largement de quoi faire l'équivalent au niveau des besoins en OpenBSD + x86.

Faire bosser une machine pendant 5 secondes (a tourner en rond ou autre) est une forme de paiement par exemple(et c'est un exemple au hasard).

Heureusement que ce n'est qu'un exempel au hasard, parceque limiter l'ensemble des serveurs mails à maximum de 17280 mails par jour ca serait une catastrophe.

Kha

Le paiper dont tu donnes le lien. http://66.102.9.104/search?q=cache:hMRNHAVJ3BwJ:byte.csc.lsu.edu/~d(...)
Lit-le.
On y apprend pleins de choses sur comment créer des listes de mesures entretenues dynamiquement. Comment vérifier qu'elles n'ont pas été corompus. Comment se réassurer qu'un système déjà vérifier est toujours non compromis, quasiment en temps réel.

C'est passionant. C'est ce module et cette architecture que j'ai monté dans mes x31, ca permet de savoir à la demande si tu as eu un inode, un programme ou quoi que ce soit d'autre de modifié.

Maintenant TCPA ne comprend pas les "bugs", mais si ca modifie un truc que tu lui as demandé de surveiller il te le dira.

C'est très puissant.

Ceci étant ce troll ne m'interresse plus, j'ai même commencé à devenir agressif avec des personnes qui ne le méritaient pas, donc à mon sens le débat est clos.

Je te laisse libre de croire que l'on peut grace à un hash envoyé par une puce TCPA deviner l'OS et en profiter pour bloquer l'ordinateur. Je pense que tu n'es pas là pour un débat mais pour affirmer ton point de vue le plus violament possible.

Ca ne m'interresse pas.

Cordialement.

La encore tu fais exprès d'oublier que pour accéder aux informations issues d'une configuration (OS, etc), il faut booter dans cette configuration.

Les metrics sont toujours disponibles, ce sont les measurements qui changent. La seule différence sera de voir si l'identité ou la zone protégée est accessible ou non.

On en revient toujours au problème de l'OS... Il est impossible de deviner l'OS. La seule chose que va savoir le provider est que
a) le TPM a certifié l'identité
b) l'identité certifié est basée sur les mesures de l'OS

Et c'est fini. Il ne saura rien de plus.

donc tu est en train de me dire que si tu de-assemble un programme tu
ne vas pas retrouver les codes asm donnes dans les references? Bizarres j'ai quelques mal a te croire...

Le code asm n'est pas le code executé par le processeur. Il est d'abord converti en bytecode. Lequel bytecode est très différent du code langage machine correspondant à l'asm. Déjà il est en risc....


A l'heure actuelle les puces reseau , dans leurs documentation tout du moins , ne permettent pas de stocker des cles cryptographique, de faire des operation de cryptographie forte ou du "remote attestation".

Ben voilà, dans la doc tout va bien, impossible de savoir ce qu'il y a après a moins de pouvoir fondre ou analyser les puces. On peut mettre des fonctions de pistage, d'espionnage de prise de main à distance etc. dans n'importe quelle puce. Celle qui aura le plus de facilité à propager l'information c'est la puce de la carte réseau sortante de mon routeur/firewall. Ma puce TCPA aura beaucoup plus de mal à me "trahir" sans que je la vois.

Pas besoin de rebooter pour exploiter la grand majorité des failles ! Donc TCPA ne sert à rien du tout dans cette grande majorité des failles. Point.

Pas besoin de rebooter non plus pour que TCPA choppe des changements dans les measurements. Si tu corromps mon kernel je vais m'en rendre compte quasi-instantanément. Et en plus les coffres à clefs se refermeront immédiatement.

Désolé mais le hash d'un OS drm non modifié est le meme tout le temps.

Sauf que
a) Le hash ne sors jamais de la puce
b) Chaque TPM est différent et chaque lot de measuring agent est différent.

Le hash est le même au sein d'une même puce, mais il va être complètement différent de celui de la puce d'à coté. Comment faire de la remote attestation si toutes les puces confrontées au même environnement renvoient les mêmes infos ?

Et au passage pour le post du dessus, metrics ca veut oujours dire "méthodes de mesures" et non pas mesures.

Et tu accord ta confiance seulement au niveau des specs pour un logiciel?

Non je fais tout moi même à la mimine dans mon garage. Y compris a ma modeste mesur eun audit du code des progs sensibles. Pour les puce je ne peux rien faire au delà de l'HDL. Donc je ne peux pas valider l'HDL.

Si tu n'utilise que les fonction documentes ; et que tu utilise un analyseur de spectre et un champmetre si tu peut eviter un quelconque traceur/pisteur.

Les fonctions doccumentés, par exemple en archi x86, sont très différentes du bytcode sous jacent. Que fait le bytecode ? Mystère.
Je peux bosser dans une cage de faraday à l'écart de toute connection réseau. Je pense déjà faire partie des rares personnes à avoir des antennes alu autour de mes écrans pour éviter de me faire espionner mes écrans par rayonnement. Aller plus loin serait déraisonable et relèverait du cas clinique (encore que je ne suis pas complètement sur d'être hors du dit cas)

Parce que tu crois que ca va se faire brutalement? Il vont commencer a referemer une fonction mettons. Tu va dire c'est pas grave je vais plus l'utiliser; bien entendu tu vas oublier de pas l'utilsier uen fois sur deux.

Si ils changent les specs dans uen direction qui ne me plait pas je me casse. La limite de ce que je suis prèt à accepter est très claire dans ma tête. Au delà c'est niet. Si il y a faille je serais le premier à hurler. A l'heure actuelle je considère la puce TCPA beaucoup moins dangereuse que la puce de ma carte réseau. Donc je la garde. C'est aussi simple que celà.

Pour faire court. Un tripewire compromis peut compromettre l'OS, un OS compromis peut compromettre tripewire.
Un TCPA compromis ne peut pas compromettre l'OS, un OS compromis ne peut pas compromettre TCPA.
Il y a un mieux. Pas forcément un grand mieux, mais un mieux.

Ah enfin, tu admets que TCPA fait bien cela. Je te signales que tu as bien du poster + de 10 messages dans ce thread pour dire le contraire !


Mais je n'ai JAMAIS dit le contraire. J'ai même dit dès le départ que c'était identique au fonctionement des certificats. Tu n'as pas ton certificat tu ne rentre pas.

D'autant plus que cela a déja été évoqué dans ce thread aussi: l'OS qu'on t'oblige à utiliser sera évidemment un OS qui va t'empecher de faire ce que tu veux avec ce contenu. Ce qui est la définition exacte de Digital Rights Management.

Mais le provider NE PEUT PAS savoir quel OS j'ai. A moins d'être physiquement présent sur ma machne et de faire les manips avec moi.
La seule chose qu'il puisse savoir c'est si j'ai le MEME os que celui utilisé une fois précédente.

dans ce cas tcpa peut etre compromis avant d'aller a la fonderie.

Tout à fait. Mais TCPA est indépendant de l'OS et incapable d'interagir avec lui autrement que par un canal bein spécifique par le biais de challenge response. Donc même avec une puce compromise, il faudrait encore que la personne désireuse de piquer mes clefs réussisse à usurper l'identité d'un challenger que j'ai envie de contacter.
Alors que si mon OS ou si tripewire sont compromis ils peuvent aller d'eux même sur le ternet faire leur raport e ouvrir ma machine en grand.

La différence n'est pas ennorme, mais c'est quand même un bon cran de plus en faveur de TCPA.

si les tpm se généralise; je suis vraiment pas sur que les choix par defaut vont rester identiques.

Le jour ou le TCG se referme, et sort de nouvelles puces sans en publier les specs et sans permettre à des fondeurs nouveau de créer leurs propres puces, je pars en courant.

Donc tu es en train de me dire que n'importe qui peut avoir acces aux cles?

Personne ne peut avoir accès au clefs, mais l'admin du TCPA peut déplacer/copier/migrer n'importe quelle clef.

Tant que tu n'as pas vu le hdl (donc le "code" de la puce) tu ne peux pas savoir.

Non tant que je n'ai pas fondu la puce moi même (et je veux dire avec mes petites mains dans mon garage) je ne peux pas savoir. Dans tous les autres cas je suis obligé de faire confiance à quelqu'un. Chacn met la limite ou il veut. Etant incapable de fonder les puces ou d'analyser une puce après fonderie je considère le HDL comme m'étant inutile. Rien ne me permettra jamais de vérifier que le papier que l'on m'a doné correspond à la puce que j'ai sous les yeux. Donc j'accorde ma confiance au niveau des specs.
Rien ne me prouve non plus qu'il n'y ait pas un traceur/pisteur dans mon CPU. Tant pis j'aime trop l'informatique pour m'arreter.

Le meilleur moyen de ne pas être victime d'un "méchant", c'est d'être paranoïaque.

Vend ton PC alors. Si tu penses sincèrement que les gros, ou même seulement Microsoft (qui est super pote avec IBM c'est connu) vont taguer toutes les propriétés de ton PC pour ouvoir te suivre tu es foutu.
Il y a un moment il faut savoir se donner une limite raisonable ou alors on sombre dans la folie.
Non Microsoft ne va pas passer 3 mois/homme de travail à relever toutes les mesures possible et imaginable de ma TPM pour stoquer ca sur plusieurs To de données.
Non mon vendeur de PC ne va pas accepté de devoir réenvoyer mon PC en usine pour reréengistrement de l'ensemble des données à chaque fois qu'il me prend l'envie de flasher un firmware ou de mettre à jour un driver.
Non Microsoft ne va pas payer de sa poche le retour en usine de 400 millions de PCs à chaque mise à jour de sécurité du windows média player.
Les chances de me faire enlever par des Antariens sont nettement plus élevées. La manip est techniquement possible, mas également complètement absurde. On aurai déjà rien qu'en terme de marketing beaucoup de mal à vendre ce genre de technos...

En ce qui concerne TCPA les hash s'apellent les hashs, la partie de TCPA qui fait les hashs s'apelle les measurement agents et les measurements sont ensuite validées par le TPM puis transmis à la demande de l'attestation service sous forme de hash.
L'attestation agent prend ces hashs et s'en sert pour créer une signature.
Les metrics sont le règles utilisés pour assurer les measurements. Ils désignent aussi bien les méthodes utilisés pour obtenir ces measurements que les ségments mesurés.

Bref quand le système fait un "report" des "metrics", c'es ce qui est mesuré et les méthodes de mesure qui sont renvoyés...

Cela veut dire que les metrics sont envoyés au remote challenger qui décide en fonction de ces metrics.

PERDU !
Bien essayé note, mais c'est pas ca du tout.
Reporting the metrics veut dire que lors d'une première authentification tu donne l'ensemble des metrics prise en compte par une identification.

Comment ca marche ?

a) Tu créé une identité qui possède un PCR (par exemple tu dis que tu prend le bios, le disque dur, le boot OS, et le lancement de l'appli TOTO)
b) Tu donne à un profl les droits sur cette identité
c) Tu te connectes au provider
d) Lors du remote authentification tu choisis ton identité
e) La puce TCPA renvoit les metrics utilisés par l'idendité (genre bonjour cette identité a été créé avec des metrics sur le bios, le disque dur, le boot OS, et le lancement de l'appli TOTO), en voici la clef publique.
f) Le provider décide si les metrics lui convienne, et si c'est le cas identifie ta macine à l'aide de la clef publique transmise, sinon il t'envoie bouler.

La encore c'est clair pour tous sauf pour ceux qui préfèrent rester aveugle.

Lire la doc aide....

could be used to prevent play unless a trusted operating system and application were in use

Ca peut être utilisé pour empecher la lecture a moins qu'un OS et une application de confiance ne soient utilisés.

J'ai prétendu le contraire ? Je dis juste que ca n'a rien a voir avec DRM. Tu te connectes à un site ou un service et pour afficher le contenu tu dois prouver que tu utilises bien l'OS et l'appli qui sont connus de ce service (Par exemple le même que celui qui a été utilisé pour payer par carte bleue l'abonement au site).

Et je ne vois vraiment pas le rapport avec DRM, qui consiste à prévenir la copie ou la diffusion de fichiers existant en local sur la machine du client.

Ok je ne pourrais pas lire le contenu si je ne suis pas authentifié. Et alors ? Ca m'empêche de booter ? Ca 'empêche de ripper mes CDs ? Ca m'oblige à utiliser windows ? Non
La seule chose que ca m'oblige à faire c'est à revenir sur le site de la même façon que celle que j'ai utilisé au moment ou j'ai été authentifié.

C'est clair et net !

De quoi que c'est un système d'authentification/certification et non un système d'identification ? Ca fait longtemps que c'est clair et net.
Que c'est un système challenge-response et ou le fournisseur de contenu joue le rôle de challenger, et non pas un envoi en masse de données ? Ca fait longtemps que c'est clair aussi.


ce qui est clair aussi c'est que tu lis la doc de façon tellement en diagonale à la recherche de la phrase qui sortie du contexte et coupée savament permettra d'augmenter ton FUD que tu oublies le principal.
Lors d'un metric report
a) les hash sortent-ils de la machine ?
b) les hashs sont-ils liés spécifiquemtn à un matériel ou globalement à une gamme de matériel
c) est-il possible de faire la relation hash vers matériel + logiciel
d) Par trustworthy faut-il comprendre "conforme à une norme DRM définie ailleurs au gout du client" ou "conforme à un système TPM valide" ?

Prend le temsp de lire la doc et de répondre à ces questions simples.

Et que l'OS soit read-only l'empêche d'être compromis ?
Il peut avoir été compromis à priori, avant le gravage. Et tripwire est toujours obligé de lui faire confiance.

Et la conséquence la plus importante est clairement la possibilité d'obliger le grand public à utiliser des OS DRM et du matériel DRM pour pouvoir se connecter. Dans un pays comme la France.

C'est typiquement ce que l'on apelle du FUD.
Comme les hash TPM sont imprévisibles (aléas vrai), la seule façon de faire du DRM via TPM c'est de
a) retirer les droits admin sur la puce à l'utilisateur final
b) à l'installation de la machine, faire générer à la puce TCPA toutes les signatures de PCR "interressante" (ie considérée comme valide pour le fournisseur) et les stoquer quelquepart.
c) Prier pour qu'il n'y ait jamais besoin de remplacer un disque, une carte graphique ou de mettre à jour le bios ou le système d'exploitation sinon la seule solution est de faire revenir la machine en usine et de faire recertifier toutes les configs valides.

IBM considère que du simple point de vue du stockage des données par utilisateur c'est une abération.

Maintenant libre à toi de penser que les "méchants" sont pret à sacrifier des To entiers de stockage par utilisateur. Mais ca tient de la conviction religieuse et pas du raisonnement logique.

On peut authentifier la plateforme en utilisant le système d'authentification via challenge response lequel s'appuie sur les metrics. Un challenge signé PCR, c'est comme une clef GPG. Si je te donnes ma clef tu vas avoir du mal a savoir quelle taille je fais. C'est ici la même chose !

Tu nies l'évidence, c'est pathétique.

Moins pathétique que de modifier le sens à son avantage.
Comment a ton avis le matériel et le logiciel deviennent-ils "trusted" ? Surtout vu que la puce ne peut pas contenir de clefs préchargés autre que la vendor key qui ne peut authentifier que la puce elle-mêrme ?

Sans manipulation préalable de l'utilisateur c'est impossible. On a donc pas un système "out of the box." Ensuite le fournisseur a-t-il moyen de s'assurer de quelque façon que ce soit que la clef reste dans la zone dans laquelle il l'a mise ? Non...