Lien CURL : Implement secure gopher protocol
20
déc.
2020
Journal Pourquoi j'ai été obligé de désactiver TLS dans Postfix
7
déc.
2020
Hier soir, la tristesse m'a envahie. La tristesse de l'administrateur système, hein, pas celui qui vient de voir un de ses proches succomber au Covid-19. Ça empêche donc de dormir 10 à 15 minutes, et ça permet de faire de l'humour dans un journal.
Reprenons.
Je suis donc en quête de la création d'un espace client patient sur le site d'une clinique locale afin de faire la pré-admission en ligne de l'un de mes enfants en vue d'une intervention chirurgicale (…)
Forum Linux.général TLS et Postfix
27
sept.
2020
Bonjour à tous,
j'ai mis en place un petit serveur mail auto-hébergé fonctionnel en utilisant postfix et dovecot et me demande comment sécuriser correctement la connexion entre le client (moi) et le serveur et entre les différents MTA.
J'ai cru comprendre que la directive "smtp_tls_security_level = may" (entre autres) permet d'activer un mode chiffrement opportuniste nommé STARTTLS et donc que ce dernier est vulnérable aux attaques en MITM.
J'ai donc quelques questions qui me viennent naturellement à l'esprit:
Est-il possible (…)
Journal ovh.fr , exemple de ce qu'il ne faut pas faire avec un certificat
29
août
2020
Je suis actuellement au Québec, donc quand je vais sur ovh.com je suis redirigé sur la version canadienne du site (avec tarifs en dollars &co). Naïvement je me suis dit qu'en tapant ovh.fr j'arriverais sur la version destinée à la France. Surprise !
Warning: Potential Security Risk Ahead
Firefox detected an issue and did not continue to ovh.fr. The website is either misconfigured or your computer clock is set to the wrong time.
En fait http://ovh.fr redirige vers https://www.ovhtelecom.fr/ mais (…)
HTTPS, Tor, VPN : de quoi est‐ce que ça protège exactement ?
6
nov.
2019
La dépêche « Protéger sa vie privée sur le Web, exemple avec Firefox » (février 2018) a ouvert des questions sur la protection par HTTPS, Tor et VPN. Ces techniques protègent, mais contre quoi et dans quelles limites ? Cet article essaie de l’expliquer plus en détails. N’ayez pas l’illusion d’être totalement protégés en utilisant l’une d’elles : soit, elle ne permet pas vraiment ce que vous croyez, soit il faut l’utiliser d’une certaine façon ou la compléter d’autres précautions pour avoir le résultat attendu.
En effet, pour bien dissimuler votre navigation il faut tenir compte des limites techniques. C’est comparable au chiffrement de vos courriels (même de bout en bout) qui peut être insuffisant pour dissimuler entièrement votre message à un espion. Par exemple, si vous chiffrez votre courriel, mais que celui-ci a pour objet « j’ai des morpions » ou que vous l’adressez à sos-morpions@sante.gouv.fr, le contenu et les pièces jointes de votre message ont beau être chiffrés, un espion peut quand même en avoir une relativement bonne idée, car les métadonnées et l’objet ne sont pas chiffrés.
Lien TLS1.3 apporte davantage de sécurité
14
août
2018
Forum Linux.général Squid : Certains sites TLS ne traversent pas
3
juil.
2018
Bonjour,
Je rencontre un problème avec mon serveur Squid pour afficher quelques sites en HTTPS.
Je n'arrive pas à comprendre la logique car la plupart passent bien et d'autre me retournent une erreur type "Échec de la connexion sécurisée".
Quelques exemples de sites qui ne traversent pas le proxy : https://bitly.com, https://www.velomacchi.com, https://www.raise3d.com/
J'imagine que leur configuration TLS est différente d'autres sites mais je ne sais pas en quoi.
Je remarque des différences avec Wget et openssl connect.
Lien HPKP est (bientôt) mort
12
juin
2018
Post‐mortem de l’incident du 3 juin 2018
5
juin
2018
Beaucoup d’entre‐vous s’en sont rendus compte, le certificat X.509 utilisé par LinuxFr.org a expiré ce 3 juin 2018. Retour sur cet incident et sur le renouvellement de ce certificat dans la seconde partie de cette dépêche.
Journal DLFP hacké
3
juin
2018
Pendant plusieurs heures ce matin le certificat TLS de linuxfr.org s'est trouvé invalide. Moult moules ont fait fi de l'avertissement de sécurité de leur navigateur et ont malgré tout accédé au site soit en utilisant un protocole insécurisé soit en acceptant le certificat obsolète. Bien évidemment cela a mis en péril la vie privée de nombre d'utilisateurs de ce site.
Cette situation insoutenable exige des administrateurs du site un compte rendu détaillé des événements qui ont conduit à une telle (…)
Journal Vérification des certificats X.509 sur le point d'expirer
3
jan.
2018
Comme beaucoup, j'utilise Let's Encrypt.
J'ai pas mal automatisé le renouvellement avec acme-tiny, mais il me manque surtout le petit truc qui me dit quand le certificat n'est plus valide. Et si possible, avant que ça arrive.
C'est là : https://framagit.org/Glandos/lets_check
C'est simple. Éditez le script pour y mettre votre délai en jours, et vos noms d'hôtes, et lancez-le. S'il y a un problème, ça l'écrit. Si tout va bien, rien n'est écrit. C'est donc tout à fait (…)
Quad9, résolveur DNS public, et sécurisé par TLS
17
nov.
2017
Le résolveur DNS Quad9 (prononcer « quoi de neuf » en français) a été annoncé aujourd’hui. C’est un résolveur DNS public, mais dont l’originalité est d’être accessible de manière sécurisée, avec TLS (DNS sur TLS est décrit dans le RFC 7858).
Alors, le lectorat de LinuxFr.org, étant très au fait du sujet, va dire « mais des résolveurs DNS publics, il y en a plein ! Pourquoi un de plus ? ». Le plus connu est Google Public DNS, mais il en existe beaucoup d’autres, avec des politiques et des caractéristiques techniques diverses. Notamment, tous (à l’exception de Cisco OpenDNS) sont non sécurisés : le lien entre vous et le résolveur est en clair, tout le monde peut écouter, et il n’est pas authentifié, donc vous croyez parler à Google Public DNS mais, en fait, vous parlez au tricheur que votre FAI a annoncé dans ses réseaux locaux.
Journal Quad9, résolveur DNS public, et sécurisé par TLS
16
nov.
2017
Ce journal a été promu en dépêche : Quad9, résolveur DNS public, et sécurisé par TLS.
Le résolveur DNS Quad9 (prononcer « quoi de neuf » en français) a été annoncé aujourd'hui. C'est un résolveur DNS public, mais dont l'originalité est d'être accessible de manière sécurisée, avec TLS (DNS sur TLS est décrit dans le RFC 7858).
Alors, l·e·a lect·eur·rice de LinuxFr.org, étant super au courant, va dire « mais des résolveurs DNS publics, il y en a plein ! Pourquoi un de plus ? ». Le plus connu est Google Public DNS mais il en existe beaucoup d'autres, avec des (…)
Wiki [Tuto/HowTo] [Ubuntu/Debian] Chiffrer ses volumes Glusterfs
25
sept.
2017
/!\ suite à une erreur lors de la création de l'article, le titre n'est pas bon. Cet article traite du chiffrement des communications entre les machines. Pas du chiffrement sur les disques.
Chiffrer les communications de GlusterFS
Introduction
Par défaut les communications de glusterfs-server et de glusterfs-client ne sont pas chiffrées. Glusterfs peut néanmoins utiliser TLS (ex SLL) pour chiffrer les communications et casser ainsi toute tentative de MITM.
Ensemble, nous allons voir comment.
Note : Pour une raison (…)
Journal À quand l'HTTPS par défaut sur LinuxFR ?
14
fév.
2017
Bonjour'nal
Jusqu'à présent pour mouler sur LinuxFR de manière sécurisée avec mon copain TLS on est obligé d'utiliser les services de l'EFF, on est maintenant en 2k17 et ça nous déçois un peu…
Administrateurs, si vous nous lisez ne voulez-vous pas déposer une petite redirection 301 de http://linuxfr.org vers https://linuxfr.org ?
Si non, voulez-vous bien éclairer ma lanterne fort cabossée ? Qu'est-ce qui serait limitant pour forcer HTTPS aujourd'hui ?
La bise.