oinkoink_daotter a écrit 1695 commentaires

ca commence a devenir vraiment puissant ces carte usb ! voir compiler avec gcc en 1 minutes sur Pi un nouveau noyau ?

Sauf erreur, ce genre de machins est câblé en dur (ou en presque dur ?) pour faire un certain nombre d'opération de façon tout ce qu'il y a de plus bourrine. C'est bien pour ça que ça s'appelle "Application Specific Integrated Circuits", et ce n'est pas du tout généraliste. Donc pour miner du bit coin, tu achètes ça, mais pour compiler plus vite, tu t'achètes un Pi plus puissant (ça tombe bien, le Pi 2 est sorti aujourd'hui et il est 6 fois plus rapide), ou tu crosses compiles depuis un vrai gros machin avec des e-cojones.

Yep, mais même si ça été dit 42 fois icitte, startssl, c'est aussi ça.

Il y a du 1984cloud, dans la page, est-ce normal (une fois en clair et une fois en base64, avec un mdp d'ailleurs) ?

Point de détail : la puce TPM ne stocke pas les hash de fichiers. De mémoire dans ce cas, les hashs sont stockés dans un fichier et c'est le hash de ce fichier dont l'intégrité est mesurée par le TPM (via signature ou scellement via l'état des PCR).

Un système Unix digne de ce nom lève une alerte quand un binaire système est modifié

Je t'invite à tenter l'opération sur n'importe quel linux après installation. Tu vas être très déçu.

Peut-être […] s'agit-il plutôt d'une vulnérabilité potentielle que d'une porte dérobée, ou que celle-ci, si elle existe, n'est pas dans le programme d'origine tel que distribué par OpenSSH, mais dans un binaire que l'on essaie de faire installer par sa cible…

Ce que dit le doc en question, c'est qu'un gars en bricolant le code d'OpenSSH a réussi à hardcoder une clef publique pour donner lui les droits root si elle se présente, et de discourir sur les avantages d'une telle solution par rapport à l'approche traditionnelle australienne qui était d'ajouter des clefs publiques dans un .authorized_keys2.
A ce niveau, la, ce n'est plus vraiment une vulnérabilité, mais une métavulnérabilité tout ce qu'il y a de plus triviale/générique. Si j'arrive à avoir suffisamment de droits sur le système pour remplacer le binaire d'OpenSSH, est-bien une vulnérabilité d'OpenSSH ?
Contre ce genre de menace, il n'y a pas vraiment d'autre solution que de s'assurer qu'on connait les binaires qui tournent sur la machine (signature numérique des binaires, tripwire ou équivalent, etc).

Dans l'absolu, oui. Mais ce genre de discours ne passe pas vraiment dans les structures "institutionnelles" dont il est question dans le journal. La plupart des grosses boîtes ont outsourcé leurs dev, même sur site à des SSII au forfait. Donc les devs qui se barrent c'est le problème de la SSII, pas du donneur d'ordre.

J'ai connu quelques personnes poser leur démission (pas chercher à récupérer du fric en négociant, juste partir et demander à le faire le plus vite possible) du fait d'un "environnement de merde, non merci, j'ai une estime de moi"

C'était quand ça ? On est en 2015, et en France, le marché du travail est un petit peu sinistré, donc les gens restent à leur poste.

Les politiques bien strictes des annes 90/2000, la plupart en reviennent, a raison.

Pas en France, et pas pour ce genre de clients.
L'OP dit :

J'ai commencé une mission chez un client institutionnel pour développer

Dans ces structures, tu n'as quasi plus de dev, tout le soft est sous-traité à des SSII.
Donc, dans ce climat, c'est un peu chaud de se faire entendre.

700 personnes, c'est en gros 70 M€ de chiffres d'affaire en moyenne, voir 3x plus pour une banque. Donc bon… il faut savoir relativiser.

Alors, comme tu le dis plus bas, la DSI est un centre de coûts. Donc 700k que tu peux économiser, c'est 700k qui seront dépensés ailleurs. Le but de la DSI c'est de te fournir le juste matériel pour ton travail en prenant compte de tout un tas de paramètres (pécuniers, politique, amortissement comptable - très important, ça, l'amortissement comptable -), pas de filer la dernière machine de guerre à la mode. Vu la politique actuelle largement déployée dans les grandes structures pour la chasse aux coûts, c'est un peu compliqué de tenir ce genre de discours.

tu devrait un peu te rappeler que le service IT est un productif,

Elle est belle, celle-là :)

autre possibilité : demande à ton fournisseur de mission de te fournir un PC portable (il y en a des pas cher avec une bonne config, sous Linux), sinon il aura une mauvaise réputation auprès du client et ça lui coûte peu aussi d'améliorer la situation.

Dans la plupart des grandes boîtes, il est interdit :
1/ de brancher du matériel qui ne vient pas de la boîte sur le réseau
2/ de manipuler les données de la boîte sur du matériel extérieur.

Donc il faut bien se renseigner avant de proposer ça car ça peut coûter des points de karma.

Aucune idée. Il avait fait opposition sur le prélèvement et c'était parti en contentieux. Je n'ai pas eu de nouvelles après.

A noter que comme ça peut te coûter du vrai pognon, faut faire krèkrè attention. Ca a manqué coûter pas loin de 1000€ à un collègue.

Mais concernant tout le domaine de l'informatique industrielle et militaire, c'est SSII à gogo et irresponsabilité totale, et c'est de ça dont on parle.

Concernant le domaine de la défense, c'est un fantasme. Soit tu l'as vu et auquel cas il y a un problème, soit c'est du "on dit". Je ne m'exprimerai pas sur l'informatique industrielle.

Attention, on ne parle pas de la même chose. Ce que je dis, c'est que la non ouverture du code est quelque chose qui est pris en compte au moment de la conception du système au global par la maîtrise d’œuvre et la maîtrise d'ouvrage, de façon à ce que le risque sur le système soit considéré comme acceptable. On ne parle pas (ici) de ce que fait l'éditeur de la brique lui-même.

C'est dommage que tu penses ça, parce que c'est pourtant le cas.

Ce que j'essaie d'expliquer, c'est justement que la sécurité par l'obscurité est une erreur, surtout dans les secteurs sensibles, y compris la Défense nationale

Et qu'est ce qui te fait croire que la non ouverture de certaines briques n'est pas un risque pris en compte et pallié par d'autres mesures lors de la conception de ces systèmes ?

Et les derniers accidents montrent que les commandes électroniques sont souvent perturbées par les orages.

A ma connaissance, jamais personne n'a écrit cela.

sur un raspberry pi B+ :

pi2:~$ cat /proc/cpuinfo
processor   : 0
model name  : ARMv6-compatible processor rev 7 (v6l)
Features    : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part    : 0xb76
CPU revision    : 7

Hardware    : BCM2708
Revision    : 0010

pi2:~$ openssl speed aes
Doing aes-128 cbc for 3s on 16 size blocks: 2562542 aes-128 cbc's in 2.99s
Doing aes-128 cbc for 3s on 64 size blocks: 709587 aes-128 cbc's in 2.98s
Doing aes-128 cbc for 3s on 256 size blocks: 182806 aes-128 cbc's in 2.97s
Doing aes-128 cbc for 3s on 1024 size blocks: 45954 aes-128 cbc's in 2.96s
Doing aes-128 cbc for 3s on 8192 size blocks: 5758 aes-128 cbc's in 2.98s
Doing aes-192 cbc for 3s on 16 size blocks: 2260315 aes-192 cbc's in 2.99s
Doing aes-192 cbc for 3s on 64 size blocks: 617059 aes-192 cbc's in 2.99s
Doing aes-192 cbc for 3s on 256 size blocks: 158048 aes-192 cbc's in 2.99s
Doing aes-192 cbc for 3s on 1024 size blocks: 39784 aes-192 cbc's in 3.00s
Doing aes-192 cbc for 3s on 8192 size blocks: 4979 aes-192 cbc's in 2.99s
Doing aes-256 cbc for 3s on 16 size blocks: 2017243 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 64 size blocks: 545751 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 256 size blocks: 139332 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 35088 aes-256 cbc's in 2.98s
Doing aes-256 cbc for 3s on 8192 size blocks: 4391 aes-256 cbc's in 2.99s
OpenSSL 1.0.1j 15 Oct 2014
built on: Tue Oct 21 05:35:53 UTC 2014
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      13712.60k    15239.45k    15757.02k    15897.60k    15828.70k
aes-192 cbc      12095.33k    13207.95k    13531.87k    13579.61k    13641.46k
aes-256 cbc      10794.61k    11681.63k    11889.66k    12057.08k    12030.46k

Cela a aussi a quelques inconvénients, au minium
- le bricolage du path,
- mais aussi le ld.so.conf puis ldconfig et/ou l'équivalent en variable d'environnement (?),
- et enfin, la séparation totale du système, donc les fichiers pour etc, var, run, arrivent dans des endroits bizarres dont il faut tenir compte, par exemple pour logrotate si besoin.

Je dis pas que c'est mal, hein. Juste que c'est rapidement très chiant.

[…] ZRR pour des labo de recherche, […].

Oulah, du PSTN. Alors, même en interne, c'est peu probable que la politique locale autorise l'échange en clair de données rentrant dans le cadre de l'arrêté, dans la mesure où toutes les boîtes mail doivent arriver dans un gros serveur accédé de partout. Donc l'infogérence/cloudification de ces boîtes via Outlook365 ne devrait pas poser de problème de ce point de vue (ça en pose d'autres).
Ou alors, personne ne s'est posé la question (ce qui est possible aussi).

et tout ce qui tourne autour : synchronisation etc…)

Et dans les extensions. Style genre le minimum pour pouvoir survivre dans ce monde hostile : adblock, disconnect.me

Ça, je ne sais pas comment ça coucherait avec un FF mobile sur iOS utilisant le contrôle webkit.

Tout le monde n'est pas dans une infrastructure d'entreprise. Et puis meme dans ce cas, en quoi est ce qu'il n'y aurait pas besoin de chiffrer ?

Je ne suis pas persuadé de comprendre l'intérêt du chiffrement pour la confidentialité ici :
- soit tu n'as pas confiance dans l'infrastructure de déploiement, le chiffrement ne te protégera pas contre une lecture bourrine de la mémoire depuis l'extérieur du contenu. Mémoire dans laquelle il y a peu près tout ce que tu cherches à protéger.
- soit tu as confiance (ou tu considères que le risque est maîtrisé), mais de toute façon ton chiffrement de conteneur ne te protège pas des intrusions par le réseau (ici c'est un gros risque). Une fois à l'intérieur du conteneur le chiffrement est transparent, donc on peut tout récupérer sans même se rendre compte que c'est chiffré sur disque.

En fait, le conteneur chiffré ne te protège que d'une seule chose, le vol de l'information, machine (ou conteneur) arrêtée.

Pourquoi ?
Certification CC sur un périmètre pas débile et boîte française, j'ai raté un truc ?

Euh non.
C'est le fait qu'il ait commis des actes répréhensibles punis par le code pénal. En France, un des fondements du code pénal français c'est la précision, c'est pour ça que le tipiakage du dernier Taylor Swift n'est pas du vol, mais de la contrefaçon, car la définition du vol impose la disparition d'un objet physique. Même si, intuitivement, on aurait tendance à penser "on s'en fout, dans l'idée, c'est pareil".
L'immoralité est subjective, et donc on matière pénale, on essaie d'éviter, car dans ce cas, autant rétablir les lettres de cachet.

Finalement la façon la plus simple pour partager ses photos reste encore de mettre ce bout de disque dur disponible via le web avec son accès Adsl.

Oula, non. Le plus simple c'est bien de les balancer sur un dropbox ou autre. La faut quand même se farcir l'installation du serveur web en question. Le meilleur pour la privacy, probablement, par contre (encore faut-il que le serveur en question ne soit pas une passoire à gros grain)

Cela dit, je voulais surtout réagir pour les photos, car pour l'avoir fait, l’hébergement de photos via l'ADSL, c'est le pire truc contre l'auto hébergement @home. La ligne est très vite saturée en upload (car on a classiquement 1MBit) et il n'y a plus rien qui marche, y compris l'utilisation normale de la ligne depuis chez toi en consultation web. Autant une ligne ADSL saturée en download, ça se comporte à peu près bien, autant en upload, ça ne marche pas du tout.
Du coup, il faut mette un shaper, et la on sombre dans le lourdingue.

Entre autre pour cette raison, je m'autohéberge maintenant chez moi et Tatave dans la Roubaix Valley (le kimsufi premier prix au moment ou c'était vraiment vraiment pas cher).