The browser-trusted WoSign authority intentionally back-dated certificates it has issued over the past nine months to avoid an industry-mandated ban on the use of the SHA-1 hashing algorithm

[...]

hey also accused WoSign of improperly concealing its acquisition of Israeli certificate authority StartCom, which was used to issue at least one of the improperly issued certificates.

[...]

"Taking into account all the issues listed above, Mozilla's CA team has lost confidence in the ability of WoSign/StartCom to faithfully and competently discharge the functions of a CA," Monday's report stated. "Therefore we propose that, starting on a date to be determined in the near future, Mozilla products will no longer trust newly issued certificates issued by either of these two CA brands."

WoSign's practices came under scrutiny after an IT administrator for the University of Central Florida used the service to obtain a certificate for med.ucf.edu. He soon discovered that he mistakenly got one for www.ucf.edu. To verify that the error wasn't isolated, the admin then used his control over the github subdomains schrauger.github.com and schrauger.github.io to get certificates for github.com, github.io, and www.github.io. When the admin finally succeeded in alerting WoSign to the improperly issued Github certificates, WoSign still didn't catch the improperly issued www.ucf.edu certificate and allowed it to remain valid for more than a year. For reasons that aren't clear, Mozilla's final report makes no explicit mention the certificates involving the Github or UCF domains, which were documented here in August.

[...]

WoSign built a system where applicants could add extra arbitrary domains to their certificates before issuance. Even when mis-issuances happened they did not determine the root cause and eliminated the flaw only in an unrelated system upgrade.

[...]

WoSign has an “issue first, validate later” process where it is acceptable to detect mis-issued certificates during validation the next working day and revoke them at that point.

[...]

The level of understanding of the certificate system by their engineers, and the level of quality control and testing exercised over changes to their systems, leaves a great deal to be desired. It does not seem they have the appropriate cultural practices to develop secure and robust software.

[...]

For reasons which still remain unclear, WoSign appeared determined to hide the fact that they had purchased StartCom, actively misleading Mozilla and the public about the situation.

[...]

WoSign’s auditors, Ernst & Young (Hong Kong), have failed to detect multiple issues they should have detected. (Issue J, Issue X)

Mozilla envisage de ne plus faire confiance aux nouveaux certificats émis par l'AC chinoise WoSign (qui a racheté StartCom) au-delà d'une date qui n'est pas encore fixée. La mesure vaudra pour un an minimum avant que cette AC soit autorisée à repasser la certification de Mozilla si elle a procédé à des changements drastiques dans ses process.

Le monde des autorités de certification x509 est toujours aussi sérieux… :'( Certificats x509 auto-signés + DNSSEC + DANE partout et basta.

Via FRsAG.

Cela fait un peu plus de 3 ans que j'autohéberge mes mails et ma messagerie instantanée chez moi, principalement. J'avais envie de faire un retour des bonnes et des mauvaises idées. Si ça peut guider des gens…

Bon, j'dois avouer que l'expérience auto-hébergement s'est interrompue temporairement depuis juillet 2016 puisque les deux ordinateurs monocarte dans lesquels j'avais investi au départ sont HS : un des circuits de l'OLinuXino a cramé en pleine nuit. Le RPi a terminé en miettes après un bon gros coup de sang bien stupide. :S Je voudrais refaire un comparatif des cartes existantes mais je ne veux pas prendre le temps de faire ça maintenant, on verra plus tard.

Ordinateur de bureau ou ordinateur monocarte ?

Le choix dépend vraiment de votre profil.

En faveur des ordinateurs monocartes, on a les arguments suivants (liste non ordonnée) :

• Facilement transportable (même sans véhicule) chez un-e ami-e ou de la famille pour les vacs, en cas de coupure durable de votre accès à Internet, etc. Même chose pour les étudiant-e-s et les personnes qui commencent leur carrière et qui bougent beaucoup : ça ne prend pas de place lors d'un déménagement.
  
  
• Cela permet de tester l'auto-hébergement sans trop investir : je n'ai jamais vu un ordinateur au format bureau au même prix qu'un ordinateur monocarte (en dessous de 80 €). Pas besoin d'un écran ni d'un adaptateur SATA <-> USB pour installer et configurer un ordi monocarte, un lecteur de carte SD suffit, alors qu'il faut au moins un adaptateur SATA <-> USB pour écrire sur le disque dur d'un autre ordi quand on n'a pas d'écran à portée de main.
  
  
• Ça ne consomme rien au niveau électrique, ce qui est bien pour ceux-celles qui ont des besoins contraints genre chambre universitaire du CROUS ou maison autonome en électricité (certains ordinateurs monocarte comme les OLinuXino proposent une batterie pour moins de 10€ supplémentaires alors qu'un ordinateur de bureau nécessite l'investissement dans un onduleur à plusieurs dizaines d'euros pour obtenir le même résultat). En cas de déplacement chez un-e ami-e ou de la famille, il n'est même pas nécessaire de le-la convaincre que ça consommera que dalle (oui, il y a vraiment des gens chatouilleux sur ce sujet).

En faveur d'un ordinateur de bureau, on a les arguments suivants (liste non ordonnée) :

• C'est des architectures x86 et amd64 standard alors que certains logiciels ne sont pas disponibles ou plantent dans leur version arm64 ou armhf. Exemple : http://www.guiguishow.info/2013/08/08/auto-hebergement-sur-raspberry-pi/#toc-3876-opendnssecsofthsm
  
  
• C'est adapté à tous les usages alors qu'un Owncloud sur un OLinuXino, ça pédale un peu. Même chose pour un Tiny-Tiny RSS bien peuplé. Bref, ça dépend du nombre de logiciels gourmands que vous voulez utiliser.
  
  
• C'est évolutif, extensible et polyvalent genre je désire une nouvelle fonctionnalité gourmande en RAM ? Hop, une barrette à pas chère et c'est fait. Envie que votre machine serve désormais de routeur & pare-feu pour votre réseau local ? Hop, une carte réseau en plus.
  
  
• Pas besoin d'un PC pour joueur, n'importe quel PC premier prix est sur-qualifié pour faire office de serveur personnel. Le point bloquant est souvent la quantité de RAM.

Brique Internet ?

Le concept de la Brique Internet est génial et les efforts accomplis sont colossaux mais, pour en avoir debug 2-3 fin 2015, je pense que ce n'est pas encore utilisable par tout le monde et qu'il y a encore plein de bugs parfois bloquants à résoudre. Du coup, je ne la recommande pas encore à des novices. Si tu t'y connais et que t'as le temps de debug : juste go et contribue à l'améliorer. Si tu t'y connais mais que t'as pas le temps, installe ton propre serveur, t'iras plus vite.

Pensez à vérifier que les logiciels qui vous intéressent sont bien disponibles dans YunoHost (l'interface au-dessus de Debian pour administrer facilement la Brique). Dans le cas contraire, ce n'est pas bloquant, y'a moyen de les installer à la main mais ça perd de son charme "plug and forget".

Toujours utiliser un VPN

Un VPN avec une IP publique statique et aucun port bloqué, genre ceux fournis par les membres de la FFDN, dédié à votre serveur, c'est juste royal pour l'autohébergement (liste non ordonnée) :

• Là encore, le déplacement du serveur est facilité : pas besoin de changer d'IP donc pas besoin de modifier votre zone DNS et d'atteindre que les caches se vident. Le VPN est vraiment ce qui rend l'autohébergement "plug and forget".
  
  
• Pas besoin de configurer le DNAT / l'ouverture de port sur la box. Pas besoin d'uPnP et autres saloperies dans le réseau. Installez et configurez le service désiré sur votre serveur et basta.
  
  
• Pas de blocage de ports comme le 25 (ce qui empêche d'envoyer des mails).
  
  
• De même, pas besoin de faire de DDNS auprès de services externes qui fermeront un jour et qui forcent à ne pas héberger vous-même toute votre infra DNS (c'qui est quand même un peu en contradiction avec l'envie de s'auto-héberger).
  
  
• De l'IPv6 même si votre FAI n'en fournit pas.

Bref, je n'envisage pas l'auto-hébergement sans VPN tellement ça simplifie la vie.

Redondance = boarf

Quand on débute, on se dit qu'on doit avoir une autre machine quelque part, qui tourne en permanence et qui agit en secondaire de notre serveur. Pour quand on a plus d'Internet. Pour quand on n'a plus d'électricité. Pour les orages qui nous obligent à débrancher le matos.

La redondance a un coût : il faut synchroniser la base de données ou les fichiers statiques qui alimentent votre site web entre vos deux serveurs, il faut synchroniser votre roster Jabber, il faut synchroniser vos mails et tout ce qui va avec (états du logiciel de greylisting, états de l'antispam, etc.), etc. Tout cela entraîne de la maintenance humaine et créer de la conf pas forcément triviale à mettre en production et à entretenir dans le temps.

Tout ça pour quoi ? On a quand même de l'électricité 99,9999 % du temps et de l'Internet 95 % du temps. Il n'y a pas non plus un orage par jour. Bref, les interruptions de service se produisent beaucoup moins souvent que ce que l'on psychotise quand on débute. Vraiment. De plus, durant un orage ou une coupure de courant ou d'Internet, vous n'utiliserez pas votre serveur secondaire… Quel intérêt d'en avoir un ?

Sans compter que les serveurs de courrier électronique doivent garder les mails qui vous sont destinés. La durée standard est de 5 jours. Bien sûr, il y a des gens qui ne respectent pas l'esprit des normes (le mail n'est pas synchrone !) mais c'est quand même rare. C'est généralement des marchands genre agence de voyage & co avec qui vous ne communiquez pas en permanence donc la probabilité de perdre un mail est faible. Les personnes qui visitent votre site web perso et qui vous causent sur Jabber peuvent bien tolérer quelques heures d'indisponibilité, non ?

Bref, monter un MX secondaire, un NS secondaire, un HTTPd secondaire, etc. m'apparaît très clairement overkill. Je n'ai pas de temps à consacrer à cela par rapport aux faibles avantages que cela va m'apporter. Je préfère réagir en cas de panne et m'adapter plutôt que d'essayer de prévoir toutes les pannes qui, au final, n'arriveront pas et laisseront place à une panne imprévue.

En revanche, je m'assurais d'avoir du matos de rechange à la maison. Genre des supports de stockage neufs (carte SD pour ordi monocarte, disque dur / SSD pour ordinateur de bureau). Genre un ordinateur monocarte de secours (et encore… ça se commande & livre vite, ces bestioles) Genre un adaptateur secteur <-> USB de secours dans le cas d'un ordi monocarte (voir http://shaarli.guiguishow.info/?gEtikA ). Pas la peine d'avoir des pièces de rechange pour un ordi de bureau sauf si votre ville et alentours n'a pas un vendeur de matos informatique.

Stéphane Bortzmeyer a aussi écrit un article centré sur l'absence de besoin vital de redonder le mail.

Y-a-t-il une différence entre héberger chez moi ou dans l'asso du coin ?

Ça dépend. Si l'asso héberge toute son infra chez un gros hébergeur style OVH ou Online ou derrière une ligne xDSL style Completel ou Orange, boarf, on ne gagne pas grand'chose, on n'a pas acentré les usages d'Internet, le contenu est toujours centralisé chez de gros prestataires. Certes, ce n'est plus Google et Facebook mais still. Si l'asso locale dispose de sa propre infrastructure Internet ou dépend d'un FAI ou d'un hébergeur associatif, alors là, l'autohébergement peut être avantageusement remplacé par une machine virtuelle dans cette asso.

Il y a aussi une question de confiance que l'on accorde mais c'est bien pareil pour votre FAI.

L'asso du coin a quand même des avantages : une machine virtuelle louée évite d'avoir à s'occuper des problématiques de pannes matérielles. L'asso du coin peut parfois gérer toute la partie technique, vous laissant ainsi l'opportunité de vous former petit à petit.

Détails techniques

Je me concentre sur le DNS car une fois que votre nom pointe sur votre serveur, tous les services fonctionnent d'eux-mêmes et il n'y a pas de délais auxquels il faut prêter attention.

Cas d'une installation simple

Pour migrer votre serveur en panne : soit vous utilisez un VPN avec une IP statique et il n'y a rien à faire. Soit vous changez d'IP et il faut modifier cette information dans votre zone parente via votre bureau d'enregistrement et ça prend du temps (la garantie que la migration sera totalement effective, pour tout le monde vient du TTL de la zone parente). Soit vous avez la main sur votre serveur de noms secondaire (parce que vous l'hébergez ou parce qu'il est hébergé chez un-e ami-e) et vous pouvez le passer temporairement en master sur votre zone et ainsi modifier et diffuser un nouveau fichier de zone. Le délai avant que la migration soit totalement effective dépend du TTL de votre zone, je vais y revenir.

Cas d'une installation redondante

Pensez bien à configurer le délai d'expiration de votre zone DNS. En effet, en l'absence de contact avec le serveur primaire, le secondaire conservera votre zone uniquement durant un certain temps, celui défini dans le champ « expire » du SOA de votre zone. Adaptez ce délai à vos prévisions. Genre des vacances durent en moyenne 2-3 semaines. Un retour SAV d'un PC, c'est 2-4 semaines. Même chose pour une ouverture de ligne ADSL / câble. Si c'est cas vous concernent, prévoir un délai d'expiration d'un mois soit 2592000 secondes n'est pas idiot.

Pour les mails, si vous ne synchronisez pas vos mails (avec Dovecot, par exemple, voir http://jonathan.michalon.eu/shaarli/?76Smjg), mais que votre secondaire se contente simplement de les mettre en queue, pensez à augmenter la durée de rétention de votre secondaire. Voir https://wiki.arn-fai.net/technique:emails#configurer_un_serveur_de_mails_secondaire_simpliste

Dans tous les cas

Mettez des TTL courts dans vos zones. Genre 30 minutes (1800 secondes) ou 1 heure (3600 secondes). Ainsi, les caches seront vidés automatiquement après cet intervalle, vous apportant de la flexibilité : ajouter une info de votre zone et en supprimer une se devient rapidement effectif pour tout le monde. Attention également à changer le TTL négatif aka le dernier champ du SOA. Ce TTL indique combien de temps un récursif gardera en mémoire le fait qu'une information n'existe pas dans votre zone avant de reposer la question. Des TTL courts ne sont clairement pas un problème sur les réseaux et machines d'aujourd'hui, surtout pour un domaine peu fréquenté ce qui est le cas de l'autohébergement, normalement.

Soyez quand même conscients que cela apporte de la flexibilité uniquement tant que vous restez dans votre zone. Exemple : si vous voulez changer l'IP de votre serveur de noms, vous dépendez forcément des TTL de votre zone parente pour changer les glue records genre 172800 secondes (2 jours) dans fr. Si pas de glue record parce que vos NS ont des noms d'une autre zone, vous dépendez bien entendu du TTL de cette autre zone.

Si vous utilisez DNSSEC, n'oubliez pas que les clés n'ont pas de durée de vie (donc on peut manquer une rotation sans problèmes) mais que les signatures ont une durée de vie. Autrement dit : choisissez bien la durée de vie de vos signatures car votre signeur devra être en état de marche avant l'expiration de vos signatures. Là encore, les vacs c'est 2-3 semaines, un retour SAV c'est 2-4 semaines, etc. donc partir sur une durée de vie d'un mois pour les signatures, c'est tout sauf idiot. :)

Tellement vrai : un fix en entraîne toujours un autre. :)

J'ai déjà parlé des tracas et des changements induits par le passage de Debian Wheezy à Jessie, voir http://shaarli.guiguishow.info/?fMCWbQ , mais je n'ai pas encore parlé de toutes les nouvelles fonctionnalités apportées par les nouvelles versions de logiciels packagés que j'ai remarquées. Liste non exhaustive, forcément.

• Grub : même si ce n'est pas pris en charge de manière native par Debian-Installer, il est possible de chiffrer totalement son système, y compris la partition /boot. Voir http://shaarli.guiguishow.info/?SKMhQA
  
  
• dnssec-trigger, qui permet, sur un laptop, d'activer une validation DNSSEC locale tout en tenant compte des spécificités de chaque réseau (blocage de ports, absence de prise en charge de DNSSEC, etc.), est désormais packagé dans Debian. Voir http://www.bortzmeyer.org/dnssec-trigger.html
  
  
• openssh-client prend désormais en charge les condensats SHA256 dans les enregistrements SSHFP. Voir http://shaarli.guiguishow.info/?QWcOtQ
  
  
• Le correcteur grammatical Grammalecte fonctionne désormais parfaitement. Je suis incapable de me souvenir de ce qui n'allait pas du temps de Wheezy, juste que ça n'allait pas. Voir http://linuxfr.org/news/grammalecte-correcteur-grammatical
  
  
• Le noyau prend désormais en charge le NAT IPv6 (NAT66). C'est utile quand on veut faire de la redirection de port genre tous les ports pointent sur le port du serveur VPN.
  
  
• Dovecot implémente la fonctionnalité NOTIFY d'IMAP qui permet au serveur de notifier immédiatement l'arrivée de nouveaux mails au client mail sans avoir besoin d'ouvrir une connexion par dossier stocké dans la boîte de messagerie comme le fait la fonctionnalité IDLE d'IMAP. Malheureusement, ce n'est toujours pas au programme de Thunderbird : rien de neuf depuis mi-2014 sur le bugtracker de Mozilla ( https://bugzilla.mozilla.org/show_bug.cgi?id=479133 ).
  
  
• Netfilter récupère désormais les contre-mesures à l'usurpation d'adresses IP, en IPv4 comme en IPv6 dont la partie IPv4 était auparavant gérée par une autre partie du noyau et des sysctl. Voir https://wiki.arn-fai.net/technique:bcp38
  
  
• La libc supporte désormais la résolution des noms totalement en TCP. Pour l'activer, il faut ajouter « options use-vc » dans /etc/resolv.conf
  
  
• La version packagée de hplip prend nativement en charge l'imprimante-scanner HP OfficeJet 2620 . Voir http://shaarli.guiguishow.info/?8C_v0Q
  
  
• Il devient possible de renforcer la configuration TLS de plusieurs logiciels serveur comme dovecot, ejabberd et apache httpd. Voir http://shaarli.guiguishow.info/?vjODJw
  
  
• Même chose pour openssh-client qui prend en charge de nouveaux algos cryptographiques : ed25519, curve25519, chacha20-poly1305, aes128-gcm, aes256-gcm, hmac-sha2-256-etm, hmac-sha2-512-etm . Voir http://shaarli.guiguishow.info/?qQJoJQ
  
  
• La fonctionnalité RRL, limitation du trafic pourri destiné à un serveur DNS faisant autorité, est désormais implémenté dans la version packagée de BIND et de nsd. Voir http://www.guiguishow.info/2014/08/23/comment-mettre-en-place-un-serveur-dns-recursif-cache-ouvert-dans-de-bonnes-conditions/#toc-5206-rrl
  
  
• On peut désormais utiliser les I/O adapters d'OpenDNSSEC donc on peut se monter un serveur master furtif, en charge de signer les zones. Voir http://www.guiguishow.info/2012/08/21/domain-name-system-attaques-et-securisation/#toc-2827-gestion-des-cls . De plus, ldns, la librairie utilisée par OpenDNSSEC prend désormais en charge les enregistrements TLSA introduit par DANE.
  
  
• Postfix prend désormais en charge DANE.

J'ai déjà commencé ma liste de ce que la prochaine version stable de Debian, nommée Stretch, devrait apporter :

• La qname minimisation sera disponible dans Unbound. Voir http://shaarli.guiguishow.info/?CBki4Q
  
  
• OpenVPN prendra en charge TLS v1.2. Voir http://shaarli.guiguishow.info/?r6npkg