Haha j'aime :D Une combinaison de techniques toutes simples, c'est juste beau.

« Selon les statistiques de Google, qui démarrent à partir de début 2014, 69 % du courrier allant de Gmail vers d'autres fournisseurs sont chiffrés pendant leur acheminement. À l'inverse, le courrier entrant (des fournisseurs vers Gmail) est chiffré à 48 %. Google note que "de manière générale, l'utilisation du chiffrement pendant l'acheminement est de plus en plus répandue". »

ÉDIT du 17/07/2014 à 13h27 : cf https://www.google.com/transparencyreport/saferemail/?hl=fr

« Sur un réseau utilisé en dessous de sa capacité, il n’y a aucune attente. Donc, la QoS par priorisation est invendable : elle n’apporte rien, pourquoi payer plus cher ?

Pour que la QoS soit vendable, il faut donc conserver le réseau dans un état à la limite de la saturation.

Mais que nous disent les opérateurs pour justifier l’abandon de la neutralité ? “La gestion de trafic et la facturation de la QoS permettront de motiver les opérateurs à financer l’investissement dans la capacité du réseau.”

Eh bien non, la réalité est exactement contraire. Le but est de passer d’un marché d’abondance (on appelle ça “un marché de la demande”) à un marché de la pénurie (un “marché de l’offre” en termes polis, je cite la Fédération Française des Télécoms). »

Tuto intéressant mais j'apporte les précisions suivantes :
  - Avec ce tuto, les clés crypto se trouvent sur le serveur DNS qui fait autorité sur la zone (sur le master quoi). Attention en cas de compromission de ce frontal, tout ça.

  - NSEC suffit amplement pour les zones au contenu banal et/ou public (comme . ) : un RRset NS, un RR A, un MX, un RR "www", ... Ce type de contenu se devine facilement sans avoir recours au zone walking permis par NSEC. Du coup l'overhead crypto ne se justifie pas. NSEC3 est utile quand le contenu d'une zone ne doit pas être public (exemple : la zone fr.) et/ou n'est pas trivial.

  - Le roulement des clés peut s'automatiser facilement avec OpenDNSSEC. Les timings sont calculés automatiquement en fonction des données des zones (TTL, TTL cache négatif, ...), par exemple. ça diminue drastiquement les prises de tête, les oublis de roulement et les erreurs humaines. Je *recommande vivement* l'usage d'OpenDNSSEC.

  - Je ne comprends pas l'intérêt de révoquer uniquement la KSK. De plus, la révocation des clés n'existe pas vraiment dans DNSSEC. Comme je l'ai écrit dans ce pavé https://www.guiguishow.info/2012/08/21/domain-name-system-attaques-et-securisation/#toc-2827-dlgation-et-chane-de-confiance : « Attention : ce bit permet la révocation uniquement dans le cas d'une clé utilisée comme première trust-anchor par un résolveur. Autrement dit : il ne sert à rien dans le cadre d'une délégation avec un enregistrement DS. ».

(via http://shaarli.cafai.fr/?9wJc_A)

Vu que les RFC relatifs au DNS n'imposent rien à ce sujet, les implémentations de serveurs DNS (qui font autorité ou récursif-cache) peuvent, ou pas, ordonner différemment un RRset (round-robin) pour répondre au demandeur.

Je me garde ici la liste des comportements :
  - BIND. Qu'il agisse en récursif-cache ou en serveur qui fait autorité, BIND fait du round-robin sur les RRset par défaut. La directive « rrset-order » permet de changer ce comportement depuis BIND 9.6. Valeurs possibles : fixed, random, cyclic (round-robin). La granularité va jusqu'à un ordre par classe/type.

  - NSD : ne fait pas de round-robin et retourne dans l'ordre du fichier de zone.

  - Unbound : ne fait pas de round-robin par défaut et retourne le set dans l'ordre dans lequel le serveur qui fait autorité l'a donné. Depuis la version 1.4.17, ce comportement peut être changé avec la directive « rrset-roundrobin » à yes.

  - PowerDNS : recursor fait du round-robin par défaut. La directive de configuration « no-shuffle » semble permettre de désactiver ce comportement.

  - dnsmasq : fait du round-robin par défaut. Je ne sais pas s'il existe une directive de configuration pour changer facilement ce comportement.

La redondance avec OpenVPN a l'air tellement simple quand on lit la doc' mais ça ne l'est pas, comme toujours. Il y a un point problématique et des directives de config qui peuvent entrer en conflit et faire tout foirer.

Contexte : j'utilise un VPN fourni par FDN (https://www.fdn.fr/-VPN-.html). Depuis quelques jours, ils ont monté un deuxième serveur OpenVPN dans l'optique de répartir la charge et surtout, de pouvoir couper un serveur sans impact le temps d'une maintenance. Les RRset A/AAAA vpn.fdn.fr contiennent les IPs des deux serveurs. vpn(1|2).fdn.fr sont des RR qui pointent directement sur un des serveurs OpenVPN. Je n'ai pas la main sur les serveurs OpenVPN : je suis un simple client OpenVPN.


Point problématique : la doc' d'OpenVPN nous dit : « OpenVPN also supports the remote directive referring to a DNS name which has multiple A records in the zone configuration for the domain. In this case, the OpenVPN client will randomly choose one of the A records every time the domain is resolved. »

La deuxième phrase semble au moins partiellement inexacte. J'ai testé avec la version 2.2.1 d'OpenVPN packagée dans Debian stable et avec la version 2.3.2 packagée dans les backports mais rien à faire, dans ce type de setup OpenVPN utilise toujours la première IP du RRset (première s'entend dans l'ordre dans lequel le serveur qui fait autorité sur la zone fdn.fr. et qui a répondu à la requête de mon récursif-cache local a classé les RR de ce set et que le récursif-cache utilisé a mémorisé le set en l'état).

Voici comment je mets ce dysfonctionnement en évidence :
  1) je lance OpenVPN, il se connecte à vpn2
  2) dig vpn.fdn.fr retourne vpn2 puis vpn1. Donc OpenVPN a bien pris la première IP du set. Mais c'est peut-être le résultat du tirage imprévisible.
  3) Sur le routeur de sortie du réseau, je drop tout ce qui vient du client OpenVPN à destination de vpn2.
  4) Je regarde OpenVPN réessayer 5 fois de suite de se reconnecter uniquement à vpn2.
  5) Je flush le cache de mon Unbound local, je résous avec dig/flush le cache jusqu'à obtenir vpn1 en premier dans le RRset.
  6) Au prochain essai, OpenVPN se connecte à vpn1 ...
  7) Sur le routeur de sortie du réseau, je drop tout ce qui vient du client OpenVPN à destination de vpn1 et je débloque vpn2.
  8) OpenVPN persiste à vouloir se connecter aveuglément à vpn1 ...

J'ai testé « remote-random » à tout hasard, même si la doc' indique que c'est uniquement pour choisir de manière imprévisible où commencer dans une liste de plusieurs « remote » indiqués dans la conf': sans succès, of course.

Donc, pour moi, le balancing DNS-based ne fonctionne pas dans l'état actuel. Il dépend du TTL du RRset et de la réponse d'un des serveurs DNS qui font autorité (pour l'ordre dans le RRset). Donc en cas de maintenance sur un serveur, tous ceux qui ont un VPN monté avec ce serveur continueront à s'y connecter pendant *au moins* le TTL restant.

Je n'ai aucune piste pour comprendre ce dysfonctionnement ... Peut-être qu'une simulation avec iptables n'est pas suffisante et qu'OpenVPN change de serveur uniquement pour des erreurs plus graves (pas de route, destination/port unreachable, ...).

ÉDIT du 02/06/2014 à 12h05 : il y a un ticket clôturé à ce sujet sur le bugtracker OpenVPN : https://community.openvpn.net/openvpn/query?status=closed&summary=~Do+not+randomize+resolving+of+IP+addresses+in+getaddr%28%29&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&order=priority .

Vu le type, « FRP - Feature Removal Process », cette fonctionnalité a été retirée. La description indique : « Based on a discussion on the mailing list and in the IRC meeting Feb 18, it was decided to remove get_random() from the getaddr() function as that can conflict with round-robin/randomization done by DNS servers. http://thread.gmane.org/gmane.network.openvpn.devel/3104/ »

La discussion pointée n'aide pas beaucoup. En revanche, on peut retrouver ceci : <http://article.gmane.org/gmane.network.openvpn.devel/3080>; -> « Agreed that this randomization is not probably required in most scenarios and as such should be removed or deprecated. For more thorough discussion see the full chatlog. ».

Le thread de la ML auquel ils font référence : <http://thread.gmane.org/gmane.network.openvpn.devel/3048/>;. Je n'y lis rien d'intéressant.

Le backlog IRC auquel ils font référence : <http://secure-computing.net/logs/%23%23openvpn-discussion.log>; (inaccessible à l'heure actuelle -> solution = cache -> https://webcache.googleusercontent.com/search?q=cache:qtFCxHFX15UJ:secure-computing.net/logs/%2523%2523openvpn-discussion.log+&cd=1&hl=fr&ct=clnk&gl=fr. Chercher « get_random() », la première occurrence est la bonne (discussion du 18 février 2012). Ce backlog est beaucoup plus intéressant.

Donc la motivation de la suppression de cette fonctionnalité c'est "presque tous les serveurs DNS font le taff, pourquoi le refaire au risque de casser ce que le serveur DNS a déjà fait sachant qu'il n'y a que le cas /etc/hosts où cette fonctionnalité est utile".

Évidemment moi j'ai testé avec le seul récursif-cache qui ne fait pas du round robin sur les RRset par défaut (directive « rrset-roundrobin » à positionner à yes depuis la version 1.4.17) ... FIN DE L'ÉDIT


On tente alors d'utiliser le deuxième mode de redondance proposé par la doc' OpenVPN : plusieurs directives « remote » dans le fichier de configuration. On y ajoute les lignes suivantes :
remote vpn2.fdn.fr 1194
remote vpn1.fdn.fr 1194

OpenVPN boucle à l'infini sur cette liste jusqu'à trouver un serveur fonctionnel dans l'ordre donné: vpn2 -> vpn1 -> vpn2 -> vpn1 ... Comportement identique lorsqu'il détecte qu'un serveur ne répond plus (ping-restart). On peut utiliser la directive « remote-random » pour indiquer de commencer le parcours de cette liste de manière imprévisible, sans suivre l'ordre dans le fichier de conf. Ici il n'y a que deux combinaisons : soit vpn2 -> vpn1 -> vpn2 -> vpn1 ... soit vpn1 -> vpn2 -> vpn1 -> vpn2 ...

On notera que cette méthode est moins flexible que celle de la redondance basée sur le DNS : si FDN veut ajouter ou retirer un serveur VPN, il faut adapter la conf' client. Bon, pour le retrait, il y a toujours moyen de faire pointer le nom sur l'IP d'un des serveurs restants mais bon ...

On reload. OpenVPN se connecte à vpn2. Sur la gw du réseau local, on drop tout ce qui vient de la machine qui exécute le client OpenVPN et qui est à destination de vpn2. Après le délai convenu avec ping-restart, le client OpenVPN, conformément à ce qu'indique la doc, tente de se reconnecter à vpn2, échoue puis tente vpn1 ... et échoue ! Voici un extrait de log :
openvpn[16231]: [_.fdn.fr] Peer Connection Initiated with [AF_INET]80.67.169.57:1194
[...]
openvpn[16231]: [_.fdn.fr] Inactivity timeout (--ping-restart), restarting
openvpn[16231]: Re-using SSL/TLS context
openvpn[16231]: UDPv4 link remote: [AF_INET]80.67.169.45:1194            <-- tiens, on ne cause plus avec 80.67.169.57 (vpn2) avec qui on a monté la session ?
openvpn[16231]: [UNDEF] Inactivity timeout (--ping-restart), restarting  <-- tiens, il n'y a pas l'habituel « TLS: Initial packet from »

Le log OpenVPN est trompeur car il laisse croire à un refus de .45 (vpn1) dû à la réutilisation du contexte TLS négocié avec le premier serveur (.57/vpn2) alors qu'il n'en est rien comme nous allons le voir !

Ce problème se produit aussi avec un balancing DNS-based que nous avons vu plus haut. Mais ça n'arrive qu'à deux conditions :
1) expiration du TTL du RRset
2) le nouvel ordre du RRset est différent de l'ancien ordre
OpenVPN part alors dans une boucle infinie de tentative de connexion -> détection d'inactivité -> tentative de connexion -> détection d'inactivité. Le seul moyen de casser la boucle est de restart OpenVPN à la main.

On remarque qu'utiliser les directives « remap-usr1 SIGHUP » et « remote-random » fait que ça fonctionne (ping-restart -> sigusr1 -> sighup) ... Donc il y a quelque chose qui cloche avec le restart soft (sigusr1) comparé au restart hard (sighup). C'est ce qui m'a mis la puce à l'oreille ... Qu'est-ce qui n'est pas fait lors d'un restart soft ? persist-tun/key bien sûr puisqu'on le lui demande dans la conf !

Le problème vient du cumul des directives « redirect-gateway def1 » et « persist-tun » dans la conf' client. En effet, « redirect-gateway def1 » crée une route /32 vers le serveur VPN actuel via la default gw déjà en place ainsi que deux routes /1 afin de rediriger tout le trafic v4 dans le VPN. « persist-tun » indique à OpenVPN de ne pas détruire la tun lors d'un ping-restart donc le noyau ne flush pas les routes associées à cette interface comme il le ferait sinon. Donc quand OpenVPN essaie le serveur suivant dans la liste des « remote » ... les paquets sont envoyés sur la tun (à cause des 2 * /1 et l'absence de route plus spécifique) et sont donc perdus. D'où l'échec de la tentative de connexion.

Solution pour que le balancing entre plusieurs serveurs indiqués par plusieurs « remote » fonctionne dans ce cas de figure : soit on n'utilise pas la directive « persist-tun », soit on configure OpenVPN pour ajouter autant de routes qu'il y a de serveurs définis (« route 80.67.169.57 255.255.255.255 192.168.1.254 » et « route 80.67.169.45 255.255.255.255 192.168.1.254 » dans le cas de FDN). Testé et approuvé dans les deux cas.

ÉDIT du 02/06/2014 à 12h05 : ticket ouvert par un adminsys de FDN dans le bugtracker OpenVPN : https://community.openvpn.net/openvpn/ticket/412 . Affaire à suivre. FIN DE L'ÉDIT

Quelques rappels sur rsync pour ceux qui ont la mémoire courte, comme moi quoi :
  - Utiliser ssh : « -e ssh ». Le reste de la commande ressemble alors à un scp.

  - Pour transférer un seul fichier, il suffit tout simplement d'indiquer uniquement ledit fichier dans la source et le dossier de destination ... Voir : https://stackoverflow.com/questions/14888012/how-to-rsync-a-single-file

  - S'il y a un seul fichier à transférer, rsync n'affiche pas la barre de progression par défaut. Il faut utiliser « -P »

  - Pendant le transfert, rsync crée un fichier temporaire nommé de la forme : .<nomd'origine>.<nimportequoi>. Donc c'est un fichier caché. Donc pour le voir ls -a

Merci à johndescs pour les deux derniers points.

Un bon guide même s'il faut adapter certaines recommandations (risques juridiques, registry/registrar lock par exemple) à l'importance de vos noms de domaine et à la disponibilité des fonctionnalités dans les versions stables et packagées des logiciels serveurs DNS (je pense à RRL).

Je recommande *vivement* la visualisation du schéma « Synthèse des relations entre les acteurs du DNS » de la page 9. Très bien fait.

La recommandation numéro 6 n'est pas assez complète àmha. Avoir deux serveurs distincts n'aide pas en cas de panne. Même s'ils sont dans deux préfixes différents. Il faut que les préfixes en question ne soient pas annoncés par le même AS. Pour un particulier, cet objectif me semble facilement atteignable dès lors que tout bon registrar inclus aussi une prestation d'hébergement d'un slave. Pour une entreprise/administration, je veux bien admettre que c'est moins simple (exemple : deux universités entrecroisent leurs noms sur leurs serveurs respectifs ... la probabilité est forte que leurs préfixes soient annoncés par le même AS (RENATER), ou, si elles annoncent elles-mêmes leur préfixe, que le transitaire unique commun soit RENATER).

Bonus : « Document mis en page à l’aide de LATEX. Figures réalisées avec les outils TikZ et PGFPlots. ». Sympa. :D

Via http://seenthis.net/messages/261155

Un rappel de la difficulté (stupidité ?) d'envisager de la QoS à l'échelle de l'Internet.

« L'Internet a toujours fonctionné sur le principe du « fais au mieux » (best effort), c'est-à-dire que les applications qui l'utilisent n'ont aucune garantie sur les caractéristiques quantitatives du réseau qui sera à leur disposition.


[...] intserv (RFC 1633) ou bien diffserv (RFC 2475). En pratique, ces mécanismes ont été très peu déployés, ce qui relativise la soi-disant demande de QoS. [et ils n'ont jamais atteint la granumarité que certains souhaitaient, NDLR]


La section 2 expose les propriétés de ce service simple best effort. En 2.1, les auteurs listent les forces de ce service :

    - Il ne demande pas trop d'efforts de la part de l'infrastructure réseau : les routeurs, par exemple, ont ainsi le minimum de travail. Ce service libère ainsi des ressources pour, par exemple, augmenter la capacité (les réseaux télécoms traditionnels passaient tellement de temps à gérer la QoS que leur débit total était sérieusement réduit).

    - Il ne demande pas trop de mécanismes économiques entre les opérateurs. Une des principales raisons du très faible déploiement de diffserv est qu'il nécessite des mécanismes de compensation entre opérateurs. Autrement, tout le monde enverrait ses paquets avec la classe la plus favorisée ! Ces compensations sont complexes et nécessitent des accords entre opérateurs qui vont plus loin que les mécanismes actuels entre opérateurs, ou entre un opérateur et son client.

    - Et, surtout, ce service « fais au mieux » est utile dans le monde réel. Il marche, pour une grande variété d'applications, et il propulse l'Internet depuis trente ans, malgré les affirmations (qu'on trouve par exemple dans la quasi-totalité des ouvrages universitaires sur les réseaux informatiques publiés en France) comme quoi un réseau sans QoS ne servait à rien.


Évidemment, tout n'est jamais uniformément rose. Le service « fais au mieux » a aussi des limites, que détaille la section 2.2.

    -  Ensuite, les services avec QoS peuvent interférer avec la « transparence du réseau ». En effet, il n'est pas difficile d'imaginer des cas où, pour certaines applications, celui qui ne paierait pas le surcoût de la QoS serait, en pratique, exclu du réseau. Mais le débat est loin d'être clos sur la question de savoir quel niveau de QoS reste compatible avec cette transparence du réseau.

    -  Une autre faiblesse du « fais au mieux » est sa sensibilité aux incivilités (section 2.2.2). Si un certain nombre d'utilisateurs ne jouent pas le jeu, le réseau peut s'effondrer puisqu'il n'y a pas de limites à l'allocation de ressources. Dans cette optique, les services différenciés ne seraient pas tant un moyen de « donner plus à ceux qui paient plus » qu'un mécanisme de contrôle de la congestion, même en présence d'implémentations « agressives » de TCP/IP, qui ne respecteraient pas les règles énoncées dans le RFC 2914.

    - Enfin, la dernière faiblesse (section 2.2.3) est le cas de « pics » de trafic brutaux (suite à une DoS ou tout simplement en cas de grand succès d'un site Web), pour lesquels le mécanisme « fais au mieux » mène en général à ce que personne ne soit servi...

[...]

Une deuxième question est qu'il n'existe pas de définition claire et consensuelle de ce qu'est l'équité entre les flux. Tout le monde est pour l'équité, c'est lorsqu'on essaie de la définir que les ennuis commencent (section 3.2.2). D'abord, « flux » (flow) n'est pas bien défini (cf. RFC 2309, RFC 2914, RFC 3124 et bien d'autres). Est-ce par connexion ? (Un concept qui n'existe pas pour tous les protocoles, par exemple UDP.) Ou bien pour tout trafic entre deux machines ? Ou bien, à une granularité intermédiaire, faut-il mettre toutes les connexions TCP démarrées par le même navigateur Web ou bien le même client BitTorrent dans le même flux ? Et l'équité doit-elle se mesurer en nombre de paquets ou en octets/seconde ? (Les protocoles interactifs comme SSH préféreraient certainement la première solution.) Et que faire avec les protocoles où le trafic tend à être très irrégulier ? Faut-il une équité « en moyenne » ? Si oui, sur quelle période ? Bref, si l'objectif politique est clair, le traduire en chiffres précis semble très difficile. »

Il se trouve que la mise à jour du paquet sympa dans Debian stable du 27/04/2014 (oui oui, monitoring incomplet spotted) a refait buguer sympa/wwsympa ...

Dans les logs d'erreur d'Apache :
(104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
Premature end of script headers: wwsympa-wrapper.fcgi

Déjà vécu lors de la migration Squeeze -> Wheezy ... Voir : http://www.guiguishow.info/2013/05/19/de-debian-gnulinux-squeeze-a-wheezy/#toc-3696-sympa-plus-prcisment-wwwsympa-linterface-web

La solution est toujours la même : si vous utilisez mod-fcgid, alors il faut avoir « use_fast_cgi  1 » dans /etc/sympa/wwsympa.conf . Mais attention ! C'était mon cas. Mais il semble que la mise à jour ait ajouté « use_fast_cgi  0 » à la fin du fichier et que la dernière occurrence d'un paramètre gagne ... Oui, il faut le voir ...

Mais ce n'est pas fini ... En effet, cette mise à jour a aussi reset les paramètres « domain » et « listmaster » dans /etc/sympa/sympa.conf ... Remettez les bonnes valeurs ...

On peut enfin service sympa restart.

De mon côté, cette nouvelle expérience vaudra un apt-mark hold sympa (on fige la version). Pour avoir vu du mailman en action depuis, je déconseille désormais sympa ...

En temps normal, le roulement d'une KSK se passe bien et en douceur avec OpenDNSSEC. Ici, on va s'attarder sur le cas spécial (et inutile) où un roulement de KSK approche et que l'on souhaite quitter un modèle arborescence pour les données + arborescence séparée pour les délégations signées (DLV) pour le modèle normal et classique de DNSSEC : une seule arborescence unifiée.

Des rappels salvateurs sur TLS.

Rien d'innovant, juste des rappels essentiels de choses trop souvent oubliées :
  - Écouter les communications qui passent sur un réseau, c'est facile, quelles que soient les technos utilisées à tous les niveaux (physique, logique, logiciels, ...) ;

  - Attaques passives/actives ;

  - Confidentialité implique authentification *surtout* si l'attaquant est actif ;

  - TLS protège en transit mais ne protège pas contre des extrémités corrompues. Exemples : malwares, PRISM ;
 
  - Le modèle de sécurité x509 est vaseux. Exemples : n'importe quelle AC peut signer n'importe quelle clé publique qui revendique tel nom ; Vague de piratages en 2011 ;

  - Fonctions des librairies standards de certains langages mal conçues qui débrayent la sécurité (authentification) par défaut. Exemples : python, php/curl ;

- API complexes, documentation mal fichue. Les premières aides qu'on trouve (sur SO par exemple) expliquent systématiquement comment débrayer la sécurité sans l'indiquer clairement. Comment le dev' dont la sécurité n'est pas le domaine de compétence peut-il s'en rendre compte ?

  - Mauvaises pratiques côté développeurs :
    - Les tests valident uniquement les cas normaux donc la sécurité fonctionne forcément. Il faut tester des scénarios d'attaque et vérifier que la sécurité fonctionne toujours. C'est pas simple à mon avis : quels cas teste-t-on ? Quels sont ceux qui se produisent le plus en situation réelle ? Comment intégrer ça dans les délais de coding/intégration déjà serrés au maximum ?

    - Débrayer la sécurité en phase de développement pour ne pas se prendre la tête ... et oublier de réactiver ladite sécurité dans la version finale livrée.

   - Plutôt que de chercher à protéger des énormes volumes de données, pourquoi ne pas plutôt collecter que le strict minimum nécessaire à la fourniture de la prestation ?

Renesys produit de bon rapports post-incident. J'espère que ça va pas changer avec les nouveaux proprios ... Dommage de voir où Renesys va atterrir. :'(

Les slides de la présentation de Bob Beck à propos de LibreSSL. Pour la vidéo, c'est ici : https://www.youtube.com/watch?v=GnBbhXBDmwU

Je n'ai pas regardé la vidéo mais voici ce que je retiens d'OpenSSL :
- Un code horrible : une gestion non saine de la mémoire, une volonté de compatibilité avec tout et n'importe quoi (plate-forme logiciel+matériel, "normes", pratiques), mauvaises pratiques (ce n'est pas à la lib de s'occuper de l'entropie et de la génération imprévisible mais à l'OS, API totalement ouverte suite à un include, tableau de taille fixe et fonctions insecures, ).

- D'où un déficit en volontaire pour toucher à ça. Perso, je pense que ce n'est pas aussi simple, j'vais y revenir.

- Une équipe plus attachée à ajouter de nouvelles fonctionnalités et à se faire valider FIPS qu'à maintenir/debug l'existant.


Perso, je suis sceptique sur la réussite de LibreSSL :
- La crypto c'est difficile donc une implémentation crypto n'est *jamais* simple.

- La crypto c'est difficile, coder avec style aussi ... Double ou même triple compétences réquises ... Il faut de solides bagages. Du coup forcément que le nombre de volontaires est faible ...

- Lourd passif ... ASN.1 et x509 sont de vrais merdiers ... Union Internationale des Télécommunications style quoi. On restreint même les usages possibles de x509 à travers des profils à l'IETF (PKIX pour TLS, PKIX Resource Certificates pour RPKI+ROA), c'est dire. Il y aura forcément des failles avec un tel merdier à parser. Je ne sais pas ce que vaut la norme TLS mais je pense pas que ça puisse être pire (entre faire confiance à l'UIT ou à l'IETF, mon choix est fait)

- https://xkcd.com/927/

- Lire aussi : http://insanecoding.blogspot.gr/2014/04/libressl-good-and-bad.html

Un bon tuto pour débuter et installer Postfix, Dovecot (avec prise en charge de Sieve), SquirrelMail et SpamAssasin pour un usage personnel (auto-hébergement).

Via http://seenthis.net/messages/256141

Intéressant.

« Almost two-thirds of the involved probes use DNS resolvers which allow them to perform validation (proxies) or which perform validation on their own (validating resolvers), largely thanks to local configurations based on open public projects implementing DNSSEC.

If we exclude from the computation the number of probes using resolvers from “big DNS projects”, the number of probes that use “private” validating resolvers represents only a small subset of the total. 12 of the 114 validating resolvers are on private IP addresses; from the remaining pool of 102 public resolvers, 64 are from the Google Public DNS project, 10 are from the Comcast DNS and 28 are “privately managed” server.

Moreover, 15% of probes can’t use their resolvers on TCP connection but only via UDP. »

Par contre, de mes petites expériences avec Atlas, 500 sondes au niveau mondial, c'est pas ce qu'il y a de plus pertinent notamment à cause de la disparité. 500 sondes par "régions" et autant de mesures que de "régions" me sembleraient plus adéquat pour valider ces mesures.

Wow !

(via http://lehollandaisvolant.net/?id=20140519201456)

« To find files in the /nas/images directory tree that are newer than the file /tmp/foo file, enter:

find /etc -newer /tmp/foo

You can use the touch command to set date timestamp you would like to search for, and then use -newer option as follows

touch --date "2010-01-05" /tmp/foo
# Find files newer than 2010/Jan/05, in /data/images
find /data/images -newer /tmp/foo »

Et donc, pour trouver des fichiers entre deux dates (ici entre janvier 2014 et avril 2014 inclus) :
touch --date "2014-04-30" /tmp/older
touch --date "2014-01-01" /tmp/newer
find . -newer /tmp/newer ! -newer /tmp/older