L'ensemble de mes textes étant sous licence CC BY SA, on peut donc les redistribuer, les copier et en faire un peu ce que l'on veut. J'écris pour le plaisir d'écrire et pour le plaisir d'être lu. Comme il arrive parfois que ce site ne marche pas, que ce site pourrait disparaitre (je fais des sauvegardes mais on ne sait jamais), j'ai pensé, à la suite de mes deux articles L'effet Streisand et les sites miroirs et Faire un miroir d'un site SPIP, réfléchis à comment mettre en place un autoblog...

autoblog.png

Les autoblogs du blog de Genma

Différentes personnes ont mis en place des fermes d'autoblogs. Ils contiennent les derniers articles (depuis la mise en place de ces autblogs) et les futurs à venir, ce n'est donc pas la totalité de ce site. Mais si le site était censuré, vous pourrez toujours lire les textes ailleurs ;-)

Liste mise à jour le 03/12/2014
http://kaelsitoo.fr/autoblog/autoblogs/genmafreefr_b3fbe64910770582d9e51b56601ff3e6c0a41b76/
https://pierreghz.legtux.org/streisand/autoblogs/genmafreefr_b3fbe64910770582d9e51b56601ff3e6c0a41b76/
https://pierreghz.legtux.org/streisand/autoblogs/genmafreefr_b3fbe64910770582d9e51b56601ff3e6c0a41b76/
https://autoblog.galex-713.eu/autoblogs/genmafreefr_b3fbe64910770582d9e51b56601ff3e6c0a41b76/
https://ecirtam.net/autoblogs/autoblogs/genmafreefr_b3fbe64910770582d9e51b56601ff3e6c0a41b76/
http://arche.depotoi.re/autoblogs/genmafreefr_b3fbe64910770582d9e51b56601ff3e6c0a41b76/
http://autoblog.leslibres.org/autoblogs/genmafreefr_b3fbe64910770582d9e51b56601ff3e6c0a41b76/
http://autoblog.tiger-222.fr/autoblogs/genmafreefr_b3fbe64910770582d9e51b56601ff3e6c0a41b76/
http://dotkaya.org/autoblog/autoblogs/genmafreefr_b3fbe64910770582d9e51b56601ff3e6c0a41b76/

En savoir plus

Et n'oubliez pas de creuser un peu le sujet de L'effet Streisand et les sites miroirs et autblogs, ça peut toujours être utile de connaitre ça.

Ce texte est une traduction du texte Tor Browser Launcher Security Design, du projet torbrowser-launcher.

Ce texte me semblait important à partager pour apprendre et mieux comprendre des notions de sécurité en informatique. Je ne peux pas tout expliquer en détail mais j'ai essayé de mettre quelques Notes explicatives liée à la traduction pour essayer de vulgariser et d'expliquer (de ce que j'ai pu comprendre) un peu plus en détail.

Voir également mes articles Le TorBrowser Bundle est un bundle et Tor Browser dans lequel je parle du Tor Launcher.

Début de traduction

Ce document est améliorable. Pour le moment, c'est un copier-coller d'un message poster sur le bug tracker de debian.

La sécurité de TLS/x.509

Le torbrowser-launcher ne repose pas sur l'infrastructure du Certificate Authority (CA). Le seul TLS qu'il fait et de faire une requête HTTPS vers check.torproject.org et (si vous n'avez pas choisi un miroir) le site www.torproject.org. Quand il se connecte à ces noms de domaines, il utilise un certificat en dur. Ainsi plus aucune TLS PKI ne se fait/ne s'applique ensuite.

(Et je ai pris des mesures supplémentaires afin de s'assurer que le .pem inclus avec torbrowser-lanceur est valable. J'ai téléchargé le CERT de différentes connexions internet / FAI et les ai comparés, et quand j'en ai eu un que je pensais correcte, j'ai échangé avec les développeurs de Tor pour vérifier c'était le bon et non un corrompu/malicieux).

Downgrade attacks - Les attaques par régression

Les attaques par régression ne devraient pas être possibles, à moins qu'elles ne soient liées à des commit des développeurs de Tor eux-mêmes. Si un attaquant récupère une ancienne demande valide au serveur https://check.torproject.org/RecommendedTBBVersions, le résultat indiquerait que la version actuelle est plus ancienne que la version actuellement installée, et le torbrowser-launcher n'effectuerait pas l'installation de cette version. (Par installer, j'entends extraire le contenu du zip dans le dossier home de l'utilisateur).

Note explicative liée à la traduction : le but d'une attaque par régression est de faire retour à une version antérieure contenant des bugs/failles de sécurité. Là, l'idée est que l'on remplace la version déjà installée du tor-browser (qui est dézippé dans le dossier /home/login/torbrowser-launcher/ par une version plus ancienne)

Toutefois, il y a le scénario où l'utilisateur a défini un miroir tierce comme site de téléchargement au lieu du site par défaut. Le site miroir peut très bien fournir un zip et un fichier de signature qui ont les noms de la dernière version, mais qui correspondent en réalité à une version de fichier d'une version antérieure. Ce type d'attaque est limitée du fait que tous les miroirs utilisent l'HTTPS — et si aucun des certificats de miroir n'est "connu", dans ce cas, c'est sur l'infrastructure du Certificate Authority (CA) que cela reposera. C'est là un cas limite, et qui ne fonctionne que contre les utilisateurs qui utilisent un site miroir , et qui nécessitent accès aux clefs de signature du CA.

Note explicative liée à la traduction : sur la vérification et la signature voir mon article Comment vérifier l'intégrité du TorBrowser quand on le télécharge ?

Installation du Tor Browser au niveau du système (system-wide)

Vous ne pouvez pas installer le Tor-Browser au sein du système (et non pour un utilisateur uniquement). Le logiciel est fourni en tant que bundle par le Tor Project. Il y un certains nombres de lignes de codes qui préviennent du fait que le logiciel modifiera des fichiers en dehors de son propre répertoire dans lequel il se trouve. Chaque fichier a pour propriétaire (note de traduction au sens permission unix) l'utilisateur courant, et cela a été pensé pour que le logiciel puisse être lancé depuis une clef USB. Il y a longtemps, j'ai travaillé pour que le Tor-Browser bundle soit bundle indépendant et puisse être installé au niveau du système (note de traduction : et donc utilisable par tous les utilisateurs) et suit arrivé à la conclusion que ce n'était pas faisable si les développeurs de Tor ne délivrait pas une version "non bundle". Si vous pouviez installer le Tor-Browser au sein du système en lui-même, il n'y aurait pas de raison à l'existence du torbrowser-launcher — il y aurait un paquet Debian (note de traduction : qui serait donc géré en tant que tel, apportant les mises à jour du Tor-browser comme n'importe quel autre logiciel).

De quels clef secrète/accès les attaquants ont-ils besoins ?

Oui, les attaquants qui 1) ont accès aux clefs de confiances fournies avec le torbrowser-launcher et 2) ont la possibilité de modifier des fichiers sur https://www.torproject.org/ ou ont accès aux clefs TLS sont en mesure de faire exécuter du code de leur choix en tant que l'utilisateur courant quand ce dernier lance le Tor Browser. Cela est valable (ou pas) pour les développeurs Tor dont les clefs son inclues (Note de traduction : dans le Tor Browser).

Mais comme le dit Holger, c'est une fonctionnalité , pas un bug (this is a feature, not a bug)C'est là le but du torbrowser-launcher, afin que les utilisateurs puissent installer automatiquement les mises à jour du Tor-Browser Bundle qui sont signés par développeurs Tor.

Fin de traduction

Il existe différentes façons de sauvegarder son Raspberry Pi. Il y a la sauvegarde des "données" (si on l'utilise comme serveur multimédia ou autre) et la sauvegarde du système en lui-même. La stratégie de sauvegarde ne sera guère différente de celle que l'on adoptera dans le cas d'un PC.

Sauvegarde classique

On peut faire un script basé sur rsync, qui sera mis en tâche cron par exemple, et qui sauvegardera/copiera les données modifiées de façon régulière sur un disque externe. Vu la taille, une clef USB branché sur le Raspberry pi peut suffire. Attention, cela ne protègera pas contre un problème du Raspberry pi. Vu que la clef est branchée dessus, elle peut-être corrompue (par un problème matériel, logiciel). Idéalement, on fera une copie/sauvegarde supplémentaire sur un emplacement autre (disque dur réseau par exemple).

Sauvegarde de type dump

La taille de la carte SD étant assez petite, on peut envisager de faire un dump (via dd) régulier de la carte SD sur un disque dur autre. Dans ce cas, il faut éteindre le Raspberry, sortir la carte SD, la mettre dans un autre ordinateur et on en fait un dump complet. Là aussi, on pourra faire un script pour automatiser le dump (avec la date dans le nom par exemple). L'avantage est que l'on a une vraie sauvegarde/copie, mais l'inconvénient majeur est que le Raspberry est indisponible le temps du dump. Et que l'on n'aura pas une sauvegarde temps réel.

Conclusion

Idéalement, on combinera les deux : une sauvegarde dump par semaine et une sauvegarde classique quotidienne, sur les données changeantes (à définir selon l'usage que l'on fait de son Raspberry Pi).

A lire sur le même sujet
Les articles tagués Sauvegarde
Les articles tagués Raspberry Pi

Ce texte est une traduction de la page On Digital Signatures and Key Verification du projet Qubes (Présentation du Qubes OS Project).

Ce texte est un complément à mon tutoriel Comment vérifier l'intégrité d'un fichier que l'on télécharge ?

Début de traduction

Ce que les signatures numériques peuvent et ne peuvent pas prouver

La plupart des personnes - même les développeurs - sont confus sur les concepts de base que sous-tendent les signatures numériques. Par conséquent, la plupart des gens devraient lire cet article, même si cela semble trivial à première vue.

Les signatures numériques peuvent à la fois prouver l'authenticité et l'intégrité à un degré raisonnable de certitude. L'authenticité garantit qu'un fichier donné a bien été créée par la personne qui l'a signé (c'est à dire, qu'il n'a pas été modifié par un tiers). L'intégrité garantit que le contenu du dossier n'a pas été falsifiés (par exemple, qu'un tiers n'a pas modifié de façon indétectable son contenu en cours de route).

Les signatures numériques ne peuvent pas prouver autre chose, par exemple, que le fichier signé n'est pas malveillant. En fait, il n'y a rien qui pourrait empêcher quelqu'un de signer un programme malveillant (et cela arrive de temps en temps dans la réalité).

Le point est, bien sûr, que les gens doivent choisir en qui ils auront confiance (par exemple, Linus Torvalds, Microsoft, le projet Qubes, etc) et supposer que si un fichier donné a été signé par un tiers de confiance, alors il ne devrait pas être malveillant ou des contenir des erreurs énormes. Mais la décision de faire confiance à un tier donné est au-delà de la portée des signatures numériques. Il s'agit plus d'une décision politique et sociologique.

Une fois que nous prenons la décision de faire confiance à certains tiers/personnes, les signatures numériques sont utiles, car elles permettent que nous limitons notre confiance uniquement aux quelques tiers que nous choisissons et nous n'avons donc pas à nous soucier de toutes les "mauvaises choses qui peuvent arriver en cours de route" entre nous et le tiers, par exemple, avec des cas de compromission de serveur (Qubes-os.org va sûrement être compromise un jour), via un membre malveillant au sein de la société d'hébergement, du fournisseur d'accès, dans le cadre du piratage du Wifi... etc

En vérifiant tous les fichiers que nous téléchargeons et qui prétendent avoir été émis par le tiers auquel nous avons choisi de faire confiance, nous éliminons toutes préoccupations liées aux mauvaises choses évoquées ci-dessus, car nous pouvons facilement détecter si des fichiers ont été falsifiés (et par la suite choisir de s'abstenir de l'exécution, de l'installation ou de l'ouverture de ces fichiers corrompus).

Toutefois, pour les signatures numériques aient sens, nous devons nous assurer que les clés publiques que nous utilisons pour la vérification de signature sont en effet celles d'origine. N'importe qui peut générer une paire de clés GPG en prétendant qu'elles appartiennent au "Le projet Qubes," mais bien évidemment, seule la paire de clés que nous (c'est à dire, les développeurs Qubes) avons généré est légitime. La section suivante explique comment vérifier la validité des clés de signature de Qubes.

Importation Qubes clés de signature

Chaque fichier publié par le projet Qubes (rpm, tgz, dépôts git) est signé numériquement par l'une des clés de développeur ou de livraison de version. Chacune de ces clés est signé par la clé de signature du Qubes Master (0x36879494).

La clé publique principale peut être téléchargé à partir d'un serveur de clés, par exemple :

Maintenant, vous pouvez facilement télécharger l'une des clefs d'un développeurs ou de livraison de version, qui aura été utilisé pour signer un fichier particulier de type rpm, tgz, ou tag git. Par exemple :

$ Gpg - recv-keys AC1BF9B3
$ gpg --recv-keys AC1BF9B3
gpg: requesting key AC1BF9B3 from hkp server keys.gnupg.net
gpg: key AC1BF9B3: public key "Qubes OS Release 1 Signing Key" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)


Vous pouvez également télécharger toutes les clefs des développeurs actuellement utilisées (et aussi une copie de la clé maîtresse) à partir du répertoire des clefs sur notre serveur:
http://keys.qubes-os.org/keys/

Les clés des développeur sont configurés pour n'être valable qu'1 an seulement, alors que la clef Master Qubes n'a pas de date d'expiration. Cette dernière clé a été générée et est conservée dans une machine dédiée, déconnectée et isolée, et la partie privé (espérons-le) ne quittera jamais cette machine isolée.

Vous pouvez maintenant vérifier l'ISO correspond à sa signature:

$ gpg --verify Qubes-R2-rc1-x86_64-DVD.iso{.asc,}
gpg: Signature made Sun 20 Apr 2014 10:06:13 BST using RSA key ID 0A40E458
gpg: Good signature from "Qubes OS Release 2 Signing Key"

La clé utilisée pour signer ce ISO doit être signé par la clé principale Qubes :

$ gpg --list-sig 0A40E458
pub 4096R/0A40E458 2012-11-15
uid Qubes OS Release 2 Signing Key
sig 26CA2CD7 2013-02-26 [User ID not found]
sig C55BCFE3 2014-02-20 [User ID not found]
sig 36879494 2012-11-15 Qubes Master Signing Key
sig 3 0A40E458 2012-11-15 Qubes OS Release 2 Signing Key

Vérifier le code source de Qubes

Les développeurs qui récupèrent le code de notre serveur Git doivent toujours vérifier les tags sur la dernière validation. Toutes les commits qui ne sont pas suivis par une étiquette signée ne devraient pas être de confiance !

Pour vérifier une signature sur une étiquette de git, vous pouvez utiliser la commande :

$ Git tag-v

Fin de traduction

A lire également :
Présentation du Qubes OS Project).
Comment vérifier l'intégrité d'un fichier que l'on télécharge ?