Petite séance photos portraits en famille sur la place principale de Sopo.
(traitement rapide sur le téléphone)
Connexion à internet mobile en Colombie
Cette année, pas de bidouillage nécessaire d’une obscure clé 3G Chinoise pour accéder à internet en Colombie. Les années précédentes, j’avais dû faire :
– Modem USB 3G MOVISTAR sous Ubuntu
-Â Modem USB 3G ZTE sous Ubuntu
– Modem USB 3G HUAWEI sous Ubuntu
- Modem USB 3G HUAWEI sous Ubuntu – suite
Non, rien de tout ça. Il faut dire, jusque là , impossible de trouver un abonnement data (même en partie filtré) pour un seul mois. Le minimum d’abonnement est de un an. Tant pis pour les voyageurs. Et ça ressemble fortement à de l’entente anti-concurentiel entre opérateurs…
Et bien cette année, on a trouvé par hasard un opérateur qui fait des abonnements sur un mois ou plus : Virgin Mobile. Oui, la boîte qui a fait faillite en France!
C’est un opérateur virtuel, c’est à dire qu’il n’a pas d’infrastructure, il loue à d’autres opérateurs.
J’ai opté pour le forfait 1 mois et 2Go de data, 25000 pesos (~10€).
Donc, cette année, pas de bidouillage. Une puce de téléphone mobile est fournie, tout ce qu’il y a de plus normal. Une fois dans mon téléphone, Android permet naturellement le partage de connexion en wifi pour le téléphone de Diana et le portable. Et ça marche pas trop mal (sauf certains jours en soirée, comme les autres opérateurs). Bref, pas besoin de louer une clé 3G à un voisin (ça se fait beaucoup), tout se passe pour le mieux :-)
Lac de Guatavita
Aujourd’hui, balade au lac de Guatavita. Celui-ci servait au Muiscas pour des rites religieux depuis 600 avant JC.
La grosse entaille dans les falaises est le fait des espagnols qui ont dépensés une grande énergie à essayer de vider le lac pour récupérer l’or jeté en offrande. C’est le départ de la légende de l’Eldorado.
Aujourd’hui, c’est un site touristique bien balisé et accompagné d’un guide. On vous recommande le guide descendant des Muiscas plutôt que les autres.
Citation du jour
« Il y a des entreprises qui offrent des copies gratuites ou pas chères des programmes privateurs aux écoles, comme il existe des marchands de drogue qui t’offrent ta première dose de drogue gratuite pour t’habituer, te rendre addict et dépendant. »
Richard Stallman
(http://www.pcinpact.com/news/82508-30-ans-gnu-interview-richard-stallman.htm)
Baptême de Gabriela
How to Remain Secure Against the NSA – traduction
En visitant le blog de Bruce Schneier, je suis tombé sur un long et intéressant article : How to Remain Secure Against the NSA
Le contenu de cet article me semble important par rapport à toutes sortes de spéculations sur le cassage d’algorithmes cryptographiques suite aux révélations d’Edward Snowden. Je vais me concentrer sur les 5 points, traduits ici :
- Caché dans le réseau. Implémentez des services cachés. Utilisez TOR pour protéger votre anonymat. Oui, la NSA cible les utilisateurs de TOR, mais cela est efficace sur eux. Moins vous serez à découvert, plus vous serez en sécurité.
- Chiffrez vous communications. Utilisez TLS. Utilisez IPsec. Encore une fois, bien qu’il soit vrai que la NSA cible les communications chiffées (et ils connaissent peut-être des failles spécifiques contre ces protocoles), vous serez bien mieux protégés que si vous communiquez en clair.
- Prenez pour acquis que, bien que votre ordinateur puisse être compromis, cela nécessite du travail et représente un risque pour la NSA (donc il ne l’est probablement pas). Si vous avez quelque chose de vraiment important, utilisez un transfert par un moyen déconnecté. Depuis que j’ai commencé à travailler avec les documents de Mr Snowden, j’ai acheté un nouvel ordinateur qui n’a jamais été connecté à internet. Si je veux transfèrer un fichier, je chiffre le fichier sur l’ordinateur sécurisé puis l’emène à pied jusqu’à mon ordinateur sur internet, sur une clé USB. Pour déchiffre quelque chose, j’inverse le processus. Cela ne doit pas être infaible, mais suffisement bon.
- Soyez méfiants envers les logiciels de chiffrement commerciaux, spécialement des grands éditeurs. Mon avis, c’est que la plupart des produits de chiffrement des grandes entreprises US ont des portes dérobées pour la NSA, et il est probable que les entreprises étrangères fassent de même. Il est prudent de considérer que les équipements étrangers aient aussi des portes dérobées pour une puissance étrangère. Il est plus facile pour la NSA de placer une porte dérobée dans un logiciel à sources fermées que dans un autre aux sources ouvertes. Les systèmes reposants sur un important secret sont vulnérables à la NSA, que ce soit pour leurs activités légales ou plus clandestines.
- Essayez d’utiliser des algorithmes de chiffrements dans le domaine public qui nécessitent d’être compatibles avec d’autres implémentations. Par exemple, il est plus difficile pour la NSA de placer une porte dérobée dans TLS que dans BitLocker. Parce que tous les implémentations de TLS doivent être compatibles entre elles alors que BitLocker ne doit être compatible qu’avec lui-même, donnant à la NSA plus de libertés pour aporter des changements. Et parce que BitLocker est propriétaire, il est beaucoup moins probable que ces changements soient découverts. Préférez la cryptographie symétrique plutôt que la cryptographie à clé publique. Préférez les systèmes conventionnels à logarithmes discrets plutôt que les systèmes à courbes elliptiques. Ces derniers ont des constantes que la NSA influence dès qu’elle le peut.
Petite remarque sur ce qui semble une incohérence. Il cite au point 4 d’essayer d’utiliser des logiciels à sources ouvertes. Et il dit utiliser plus bas un ordinateur sous M$ Windows : « And I’m still primarily on Windows, unfortunately. Linux would be safer. »
L’aveu est franc. Je pense que l’explication est simple, il se sent plus à même de sécuriser un système qu’il connaît bien plutôt qu’un système inconnu. Ça se défend.
D’autres développements sont fait plus spécifiquement sur le blog de nebule…
Liens :
– https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html
– http://blog.nebule.org/?p=1206
Musée de l’Or
Balade au centre de Bogotá
Sous la pluie
Villa de Leyva
Hier, balade toute la journée à Villa de Leyva, Boyaca. C’est un village de type colonial, très bien entretenu et très touristique.
Ce village accueil notamment la maison muséum du Capitán Antonio Ricaurte, héros de l’indépendance de la Colombie et du Venezuela.
On a visité la maison muséum de Antonio Nariño. Ce fut un intellectuel idéologue, homme politique et militaire précurseur du mouvement d’indépendance. Il avait en son temps traduit en espagnol la déclaration des droits de l’homme.
On a visité aussi le muséum paléontologique et un fossile de 12m de long, un kronosaurus.
On a pris l’orage en fin d’après midi (photo de Diana) :
Bref, une bonne journée :-)
Concert
Nid suspendu
Villapinzon de nuit
Rio Bogotá, la source
Villapinzon
El Dorado
Embarquement
Debian from scratch sous Xen
J’ai mis en place une machine pour me permettre de tunneliser un certain nombre de choses depuis la Colombie. La messagerie par exemple…
Cette machine est une machine virtuelle hébergée par une vraie machine qui tourne dans le placard. Le tout animé par xen.
Il existe déjà des tutoriels sur le net pour installer la machine hôte Debian avec xen et pour créer des machines virtuelles notamment avec l’outil xen-create-image.
Mais… les choses ne seraient pas assez simple sinon… je veux plutôt installer une machine virtuelle Debian 7 en utilisant le DVD d’installation et non en passant par debootstrap ou tout autre méthode similaire…
FreeBSD, IPv6 et OVH
Je bataille depuis un moment avec un serveur Kimsufi de chez OVH. Ce serveur a une adresse IPv4 et une grande plage d’adresses IPv6. Chouette!
Mais…
Si s’adresse IPv4 et la plage IPv6 sont bien disponibles et fonctionnels, je galère sous FreeBSD v9.0. En l’état, la route par défaut en IPv6 tombe sans prévenir au bout d’une demi-heure après le reboot de la machine…
Donc ce n’est pas bien utilisable en l’état (l’IPv6 bien sûr).
J’ai essayé par tous les moyens depuis le fichier de configuration /etc/rc.conf de changer cette route par défaut. J’ai même modifié /etc/sysctl.conf. Rien n’y fait, le système attribue automatiquement par défaut une adresse de lien local. Cette adresse marche, mais elle n’est pas configurée comme STATIC… donc elle disparaît au bout d’un certain temps.
Je n’ai pas trouvé quel script de démarrage force cette route sur une adresse de lien local (rtsol par exemple). Donc je choisi une autre solution moins élégante mais efficace : je supprime puis force ma route par défaut en fin de démarrage.
Il faut créer le fichier /etc/rc.local avec :
route del -inet6 default
route add -inet6 default 2001:XXXX:XXXX:eaff:ff:ff:ff:ff -static
Changer les droits du fichier (chmod 755 /etc/rc.local).
Et voila, on a notre route par défaut au démarrage, et elle ne tombe pas !
Ref :
– http://www.freebsd.org/doc/handbook/network-ipv6.html
– http://forum.ovh.com/showthread.php?t=85332
– http://help.ovh.com/Ipv4Ipv6#link10
– http://forums.freebsd.org/showthread.php?t=21804
TOR et le PRISM
Les divulgations autour du programme PRISM font se poser des questions à beaucoup de monde. Une des solutions préconisée est d’utiliser des outils de chiffrement et/ou d’anonymisation.
On savait déjà que l’anonymisation de données avait des limites. Des études au USA ont permit de retrouver les identités de personnes à partir de données anonymisées de la sécurité sociale. Le big data présente toutes les caractéristiques pour permettre des corrélations aboutissant au rattachement de données isolées à des personnes.
Mais intéressons-nous au réseau TOR. Ce réseau de re-routage et d’anonymisation a été conçu aux USA. Il est aujourd’hui encore maintenu par une fondation américaine.
La page de Wikipédia sur TOR parle d’une possibilité d’attaque dite Time Pattern, c’est à dire une attaque sur l’empreinte temporel des flux réseaux passants par des nÅ“uds TOR. En effet, un nÅ“ud qui reçoit un paquet réseau TOR essaye comme un routeur de le renvoyer au plus vite vers le nÅ“ud suivant, et ainsi de suite jusqu’au serveur destinataire. La façon (temporel) qu’une machine a de « parler » sur le réseau est donc assez bien retransmise jusqu’au serveur destinataire.
Il faut, me direz-vous, pouvoir sniffer le serveur destinataire et le poste client (si il est connu), mais sûrement aussi tous les relais TOR intermédiaires pour pouvoir remonter du serveur au client. Cette méthode permet de lever l’anonymisation.
Si il semble facile, au moins pour un gouvernement, de capturer le trafic réseau d’un serveur en particulier, il semble difficile de pouvoir faire la même chose pour tous les nÅ“uds TOR et encore moins tous les postes clients du monde, même pour un gouvernement. La robustesse du réseau TOR repose sur cette propriété.
Le réseau TOR repose aussi sur de la cryptographie, mais uniquement pour les échanges « proches ». Et cela ne protège pas du Time Pattern.
Or, que fait PRISM ?
Et bien il fait justement cette chose qui semble difficile à faire : capturer le trafic réseau d’une grande partie des ordinateurs de l’Internet, voir peut-être tous. Et cela comprend les serveurs, les nÅ“uds TOR et les postes clients…