Petite piqure de rappel.
En clair : ce qu’on appelle "le cloud", ce sont juste des machines qui appartiennent à d’autres ; et si c’est gratuit, alors vous êtes le produit.

Source directe des CGU (Conditions Générales d’Utilisation) en français : https://policies.google.com/terms?hl=fr

Les monnaies basées sur le “Proof of Work” (PoW) sont une catastrophe du point de vue écologique.
Et cette plaie qu’est le Bitcoin va être traînée pendant de longues décennies, jusqu’en 2140[1] d’après les estimations (oui oui, plus de 120 ans), avec une augmentation de la consommation énergétique que cela entraîne pour être le premier à récolter la maigre récompense.

1: https://bitcoin.stackexchange.com/questions/10486/when-will-the-last-bitcoin-be-mined

EDIT 2017-11-10: voir aussi https://digiconomist.net/bitcoin-energy-consumption

Utiliser le service spamd, qui utilise la méthode de la liste grise pour déterminer le courriel légitime du courriel indésirable, car nu serveur légitime tentera de renvoyer le courriel, alors qu’un spammeur utilisant une machine vulnérable ne le fera pas.

Note à mon moi du futur : à lire plus en détails.

Un nouveau coup dure pour l’anonymat.
Toutefois, je comprends le conseil de l’ANSSI, mais ce n’est pas une solution acceptable.

Pour infos, la liste des nœuds de sortie est disponible ici :
https://check.torproject.org/exit-addresses

À première vue, effectivement, ça semble être une décision regrettable (dans ce que je vais expliquer, ne prenons en compte que les adresses IPv4).
L’une parce que des clients vont être lésés de ne pas avoir de plage complète de ports, et l’autre parce « [qu’]avec environ 11 millions d’adresses IP[v4] pour 6 millions de clients », il y a mathématiquement beaucoup de la place restante. Or, c’est voir le problème par le bout de la lorgnette.

Déjà, commençons par le vif du sujet, le partage de ports : il est de faits que la grande majorité des clients n’utilisent absolument pas de ports ouverts dans leur CPE (les « box ») pour héberger des services chez eux. Du coup, passer de 64ki ports, soient 65 536 ports (1 ki = 1024 unités) pour n’avoir que le quart, soient 16 384, n’empêchent absolument pas de pouvoir naviguer tranquillement sur Facebook, Twitter, Tinder, NetFlix, et d’autres services superflus comme les jeux vidéo, bref, « l’Internet » pour cette majorité de gens. Ces 16 milles ports sont bien plus que suffisant même pour plusieurs utilisateurs derrière la même connexion. De plus, rien n’empêche (si j’ai bien compris) d’ouvrir tout de même quelques ports parmi vos 16ki ports disponibles, pour avoir des services derrière votre CPE grâce au NAPT.

Concernant le nombre théorique d’adresses encore libres, c’est ne pas prendre en compte que les équipements chez Free, comme les routeurs de “backbone” ainsi que les DSLAM, ne peuvent pas prendre une adresse IP parmi les adresses théoriquement disponible : il y a un découpage à respecter, sans parler des adresses qui ne peuvent pas être assignées car elles ont un rôle particulier. Par conséquent, des tas d’adresses IP sont ainsi figées, et redéfinir ces découpages n’est pas chose aisée, surtout que ça voudrait dire que des clients actuels perdraient leur adresse actuellement assignée.

Mais au final, il y a des solutions : si vous faites parti des très rares à 1) avoir besoin d’ouvrir des ports, et 2) dans une plage spécifique (comme c’est le cas pour un service Web qui utilise par défaut les ports 80 et 443, ou pour héberger vos courriels avec les ports 25 et 465), Free a tout de même penser à vous, en fournissant des « adresse IP fixe ». Pour l’instant, pas d’infos sur les modalités d’acquisitions, le prix, etc., mais cette option règle complètement le problème.

De plus, c’est ignorer le fait que ce problème ne concerne qu’IPv4, qui tend à être remplacé par IPv6 ! Sans faire un cours sur IPv6, ce dernier crée des adresses sur 128 bits (dont 64 réservés pour la partie réseau), là où IPv4 ne fonctionne « que » sur 32 bits, ce qui permet d’avoir une quantité immense d’adresses supplémentaires (pas un facteur 4, mais plus !).
Ainsi, chaque client pourra avoir au minimum un /64 pour chaque connexion, ce qui ne permettra plus de problème de partage. Encore une preuve de la très proche pénurie d’adresses en IPv4, et qu’il est temps de fonctionner entièrement en IPv6.

Pour conclure, ce problème n’en est pas un. Le problème de base reste être la pénurie d’adresses en IPv4, et que le déploiement en IPv6 doit être obligatoire. Free est conscient d’un réel soucis et est juste pragmatique vis-à-vis de ses clients.
Certes, d’autres problèmes subsistent (comme les pings en ICMP, ou globalement les protocoles au dessus de la couche IP qui fonctionnent sans port), mais encore une fois, ces cas particuliers car rares ne devraient pas être les fonctionnements par défaut.

Haha, tiens, je ne connaissez pas. Un indicateur clair si le discours est sincère ou parodique.

En français : https://fr.wikipedia.org/wiki/Loi_de_Poe

Un site qui regroupe une liste de configurations concernant le chiffrement (SSL/TLS) pour différents services.

Ce petit billet me sert principalement de garde-mémoire, je ne vais donc pas détailler ce qu'est le champ TLSA et son but ; ceci est détaillé dans la RFC6698 “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA” (https://tools.ietf.org/html/rfc6698)

Principalement, ce qui nous intéresse, c’est de fournir soit l’empreinte de la clef, soit l’empreinte du certificat ; c’est ce que définit le champ "Selector" (section 2.1.2).
Remarque : j’ai considéré par défaut que nous sommes dans le cas d’un "DANE-EE: Domain Issued Certificate", valeur "3" du champ "Certificate Usage" (section 2.1.1).
 * Si vous souhaitez uniquement donner l’empreinte de votre clef (valeur "1" dans le "Selector Field"), utilisez les valeurs "3 1 1" et "3 1 2" respectivement pour les hashs SHA256 et SHA512 ;
Ensuite, vous pouvez au choix déterminer les hashs (SHA256 et SHA512) à partir de la clef privée (n’oubliez pas l’option -pubout, voir openssl pkey(1))
openssl pkey -outform DER -pubout -in "/path/to/private.key" | openssl dgst -sha256
openssl pkey -outform DER -pubout -in "/path/to/private.key" | openssl dgst -sha512
OU, en alternative, déterminer les hashs (SHA256 et SHA512) à partir d'un certificat (c’est ainsi de cette façon qu’un tiers peut vérifier)
openssl x509 -noout -pubkey -in "/path/to/certificat_file.pem" | openssl pkey -outform DER -pubin | openssl dgst -sha256
openssl x509 -noout -pubkey -in "/path/to/certificat_file.pem" | openssl pkey -outform DER -pubin | openssl dgst -sha512

 * Par contre, si vous souhaitez fournir l’empreinte complète du certificat, utilisez les valeurs "3 0 1" et "3 0 2" respectivement, et exécutez :
openssl x509 -noout -fingerprint -in "/path/to/certificat_file.pem" -sha256
openssl x509 -noout -fingerprint -in "/path/to/certificat_file.pem" -sha512

Ensuite, créer une entrée DNS dans votre zone, en suivant la sémantique suivante :
_<port>._<protocole>.<nomdedomaine> IN TLSA <X Y Z> <hash>

Par exemple, pour avoir le hash du certificat pour le service HTTPS, donc le protocole TCP qui répond au port 443, sur la machine foo.example.com, le résultat est "_443._tcp.foo.example.com." (ne pas oublier le dernier point à la fin).
Et pour les valeurs <X Y Z> :
X → https://tools.ietf.org/html/rfc6698#section-2.1.1 : la valeur "3" indique que ce sont des informations avec le certificat le plus proche.
Y → https://tools.ietf.org/html/rfc6698#section-2.1.2 : exporter la clef est plus simple, de ce que j’ai compris.
Z → https://tools.ietf.org/html/rfc6698#section-2.1.3 : "1" pour le hash SHA256, "2" pour le hash SHA512.
Concernant le hash, n'oubliez pas de supprimer les doubles-points (par exemple : echo $hash | tr -d ':')

Sources :
- https://www.ietf.org/mail-archive/web/dane/current/msg07210.html
- https://tools.ietf.org/html/rfc6698

Un outil du site web de l'AFNIC (registar français pour les TLD en .fr) pour analyser les erreurs possibles contenu dans une zone. Très pratique, car il permet aussi de vérifier les plages de temps de l'entrée SOA.

Pour info concernant le SOA, voici les règles de l'AFNIC :
- Le numéro de série suit la forme AAAAMMJJnn.
- Le champ 'refresh' du SOA est entre 1H et 2D.
- Le champ 'retry' du SOA est entre 15M et 1D.
- Le champ 'expire' du SOA est entre 1W et 100W.
- Le champ 'minimum' du SOA est entre 3M et 1W.
tout en vérifiant :
- Le champ 'retry' du SOA inférieur à celui du 'refresh'.
- Le champ 'expire' est au moins 7 fois celui du 'refresh'.