gouttegd a écrit 1805 commentaires

Pour les signatures, c’est une autre histoire.

Ça arrive bientôt dans Poppler, restera ensuite aux applications à s’en servir.

Et rien, juste que ce n’est pas la même chose qu’enregistrer un nom de domaine sous un TLD, comme groumly avait l’air de le croire.

D’un côté, c’est un truc qui coûte une dizaine d’euros et que n’importe quel sous-fifre peut faire en quelques minutes. De l’autre, c’est au moins $185.000 plus le temps passé à monter le dossier et à le défendre devant l’ICANN — potentiellement en pure perte si finalement la demande est rejetée.

Un gTLD comme .bnpparibas, c’est minimum $185.000 juste pour avoir le droit de déposer le dossier de demande à l’ICANN…

Comment tu fais en PHP pour accéder au certificat et au résultat de la validation ?

Ça, je ne sais pas. J’ai déployé le site SPIP, je n’ai pas écrit le code. Mais je ne pense pas que SPIP ait même besoin d’accéder au certificat, c’est l’option FakeBasicAuth du module ssl d’Apache httpd qui fait tout le boulot.

Moi tout ce que j’ai fait, c’est configurer le serveur comme suit :

<Location /ecrire>
  SSLVerifyClient       require
  SSLCACertificateFile  /etc/ssl/private/mysite/client-ca.crt
  SSLOptions            +FakeBasicAuth
  AuthType              basic
  AuthName              "My site private area"
  AuthUserFile          /etc/apache2/private/mysite.passwd
  Require               valid-user
</Location>

où client-ca.crt est le certificat qui doit signer les certificats des clients, et mysite.passwd est un fichier de mot de passe de Apache « classique » (tel que généré par htpasswd) au détail près que le mot de passe associé à un utilisateur dans ce fichier est systématiquement password (c’est un mot de passe bidon qui ne sert à rien).

c'est vraiment vraiment vraiment très complexe.

Bof, pas beaucoup plus selon moi que toutes les technologies d’authentification à deux facteurs (HOTP, TOTP et assimilés) qui elles sont de plus en plus déployées.

Pour l'utilisateur, transférer son identité sur un autre navigateur n'est pas simple.

Exporter un fichier PKCS#12 (contenant le certificat et la clef privée associée), l’importer sur l’autre navigateur. Granted, les interfaces pour ça dans les navigateurs ne sont pas des plus intuitives (je suppose que personne n’a travaillé dessus depuis 1997…), mais ce n’est pas insurmontable.

Et comme dit plus haut il y a la solution des cartes PKCS#11, qui permettent d’avoir son certificat sur soi et non dans le magasin d’un navigateur. Chiant à déployer, de demander à tout le monde d’avoir une smartcard ? Pas plus que de demander à tout le monde d’avoir un token USB comme le propose le standard U2F…

mais tu peux créer ta propre PKI (on avait dit compliqué ?).

Encore une fois, pas plus compliqué que gérer la double authentification par SMS, code TOTP, et tout le toutim. Et ça c’est déployé — et pas seulement par les « gros », même les « p’tits gars » de Framasoft le font.

Le protocole TLS permet ça depuis ses débuts (pas avec une clef SSH mais avec un certificat X.509, qui est en gros une clef avec quelques métadonnées autour et une signature), c’est l’authentification du client.

C’est pris en charge à ma connaissance par la plupart des serveurs web et par la plupart des navigateurs… et c’est complètement inutilisé.

En France, le fisc avait utilisé ça à une époque pour la connexion des télédéclarants, ils ont rapidement fait marche arrière. Trop de gens qui ne comprenaient pas comment ça marchait, et qui ne savaient pas quoi faire de leur certificat. (C’est une leçon à retenir pour ceux qui veulent la mort des mots de passe, au passage : peu importe votre solution, si elle est plus compliquée pour l’utilisateur que « taper un mot de passe dans un champ », ça ne marchera jamais, ou en tout cas pas au-delà d’un public averti.)

Ça reste néanmoins une « super idée », personnellement je m’en sers autant que possible (je m’en suis servi par exemple pour protéger l’accès à l’espace d’administration d’un site SPIP).

S'il s'avère qu'il n'a pas pris les précautions qu'il étant cénsé prendre, alors oui, il doit en assurer la responsabilité. Ceci dit, cette responsabilité n'est pas une responsabilité légale, il n'a commis aucun délit

Euh, si. Du moment qu’il y a des données personnelles en jeu (il suffit de stocker des adresses e-mail par exemple), tu es légalement « tenu de prendre toutes précautions utiles […] pour préserver la sécurité des données et, notamment, empêcher […] que des tiers non autorisés y aient accès. »

Ce n’est pas la loi HADOPI (« débile, inapplicable et inappliquée ») qui dit ça, mais la loi « informatique et libertés » du 6 janvier 1978 (article 34).

Manquer à cette obligation est un délit, passible de cinq ans d’emprisonnement et 300 000 euros d’amende (article 226-17 du code pénal).

Et la loi ne semble pas faire de différence en fonction du caractère professionnel ou amateur du sysadmin : si tu gères un STAD stockant des données personnelles, tu en es responsable, que tu sois payé à le faire ou pas.

Si je comprend bien c'est justement comme cela que fonctionne let's encrypt […] J'ai bon ?

Oui.

Mais j'imagine que d'obtenir ce type de certificat est hors de prix ?

Il n’y a généralement pas de prix affiché. Et pour cause, les CA ne sont pas supposées délivrer ce genre de certificats intermédiaire à la légère. Ça doit se négocier au cas par cas, ce n’est pas le genre de certificats que tu commandes en passant par un simple formulaire web.

Pour paraphraser je ne sais plus qui : « si tu dois demander le prix, c’est que tu ne peux pas te le payer ».

une adresse IP peut être utilisé à la place d'un hostname (RFC 2818)

Il faut distinguer plusieurs choses :

• ce que permet techniquement la norme des certificats X.509, et le profil restreint utilisé par le protocole TLS ;
• ce que les CA ont le droit de faire (les consignes du CA/Browser Forum) ;
• ce que la CA à laquelle tu t’adresses (Let’s Encrypt par exemple) décide de faire.

En l’espèce, un certificat X.509 peut parfaitement être associé à n’importe quelle adresse IP (privée ou non). Mais le CA/Browser Forum interdit aux CA d’émettre des certificats associés à des adresses privées, et Let’s Encrypt va plus loin en décidant de n’émettre que des certificats associés à des noms de machine.

Quand tu transmets un email chiffré, ça correspondant à quel besoin derrière ? envoyer un document confidentiel ? avoir un échange sur un sujet confidentiel ?

Ça correspond au besoin d’avoir une conversation privée, tout bêtement.

Ça n’a pas besoin d’être confidentiel, sensible, illégal, secret-défense, for-your-eyes-only ou je ne sais quoi. Simplement, le détail de ce que je raconte dans un mail chiffré ne te regarde pas (ni toi ni personne d’autre), c’est pour ça que je le chiffre.

Quant aux signatures (en pratique je signe beaucoup plus souvent que je ne chiffre, mes correspondants ayant une clef OpenPGP n’étant pas nombreux — même s’il y a des progrès de ce côté), je les utilise dans le même sens qu’une signature manuscrite : pour assumer la responsabilité de ce que j’ai écrit.

Hum, en fait j’ai ajouté ces custom actions sans les avoir jamais réellement utilisées (parce que je n’utilise quasiment jamais de gestionnaire de fichiers…), et je me rends compte qu’elles ne sont pas tout-à-fait au point, mea culpa.

Dans le fichier decrypt.desktop, le type MIME permettant d’identifier les fichiers chiffrés est apparemment application/pgp-encrypted, et non application/pgp.

Ensuite, il serait intéressant de n’afficher la commande de chiffrement que sur les fichiers qui ne sont pas déjà chiffrés, plutôt que sur tous les fichiers. D’après la spécification DES-EMA, il devrait être possible de faire quelque chose comme ça :

# Activer sur tous les types de fichier,
# *sauf* les fichiers déjà chiffrés
MimeTypes = all/allfiles; !application/pgp-encrypted;

… mais ça n’a pas l’air de fonctionner avec PCManFM qui affiche la commande sur tous les fichiers, même ceux dont le type MIME est application/pgp-encrypted.

Looks like a bug to me, parce que la spec dit bien :

Mimetypes may be negated (e.g. "audio/*; !audio/mpeg;").

Contournement (sale) possible :

ShowIfTrue = file --mime-type %f | grep -v -q application/pgp && echo true

(Oui, file renvoie application/pgp et non application/pgp-encrypted, ne me demandez pas pourquoi…)

C’est un cas d’utilisation réel ça, ou un cas d’utilisation que tu imagines ?

Dans les cas réels, moi je citerais plutôt les échanges :

• entre un journaliste et sa source (p. ex. entre Edouard Snowden et Glenn Greenwald et Laura Poitras) ;
• entre un avocat et son client (lire par exemple l’appel aux armes de Maître Eolas (vers la fin du billet)) ;
• entre un développeur et quelqu’un qui lui rapporte une vulnérabilité exploitable dans son logiciel.

S’il s’agit uniquement de chiffrer des fichiers depuis un gestionnaire de fichiers, ça peut se faire très facilement avec le standard (proposé) DES-EMA.

Chez moi, j’ai les fichiers suivants dans $XDG_DATA_HOME/file-managers/actions :

• decrypt.desktop:

[Desktop Entry]
Name = Decrypt
Name[fr] = Déchiffrer
Tooltip = Decrypt the file with GnuPG
Tooltip[fr] = Déchiffrer le fichier avec GnuPG
Profiles = on_pgp_file

[X-Action-Profile on_pgp_file]
Name = Decrypt
MimeTypes = application/pgp;
SelectionCount = 1
Exec = gpg2 --decrypt %f

• encrypt.desktop:

[Desktop Entry]
Name = Encrypt
Name[fr] = Chiffrer
Tooltip = Encrypt the file with GnuPG
Tooltip[fr] = Chiffrer le fichier avec GnuPG
Profiles = on_file

[X-Action-Profile on_file]
Name = Encrypt
MimeTypes = all/allfiles
SelectionCount = 1
Exec = gpg2 --armor --encrypt %f

• sign.desktop:

[Desktop Entry]
Name = Sign
Name[fr] = Signer
Tooltip = Sign the file with GnuPG
Tooltip[fr] = Signer le fichier avec GnuPG
Profiles = on_file

[X-Action-Profile on_file]
Name = Encrypt
MimeTypes = all/allfiles
SelectionCount = 1
Exec = gpg2 --armor --detach-sign %f

Ce qui ajoute automatiquement les commandes Encrypt, Decrypt, et Sign dans le menu contextuel de tous les gestionnaires de fichier compatibles.

Quelle solution reste-t-il alors pour que tout le monde puisse accéder au chiffrement GPG en graphique?

La même solution que celle que je viens de présenter, mais mise en place par défaut par les distributions ?

tu cherches à te protéger de quoi en chiffrant tes emails avec GPG ?

Tu cherches à te protéger de quoi en mettant ton courrier dans des enveloppes ? Pourquoi ne pas utiliser des cartes postales ?

Ce n’est pas parce que je n’ai rien à cacher que je dois tout faire au grand jour.

où est-ce les banques qui raisonnent mal ?

C’est surtout qu’apparemment, les banques traitent la sécurité informatique par-dessus la jambe…

L’accès à mon compte Google, qui ne me sert guère qu’à télécharger une application sur le PlayStore tous les 36 du mois, est protégé par un système d’authentification à deux facteurs (mot de passe fort + code TOTP généré par un token). Pour l’accès IMAP au compte GMail associé (si je m’en servais), je peux générer un mot de passe spécifique utilisable seulement par un client mail désigné par moi.

Mon compte Facebook, qui ne me sert guère qu’à voir des messages non-privés venant de quelques amis, pareil : mot de passe fort + code TOTP.

Mon compte sur Framagit, où deux malheureux dépôts de code se battent en duel, pareil.

Mon compte sur le site de ma banque, où se trouve mon argent : « protégé » par un unique « mot de passe » de 6 chiffres …

Les mails envoyés par Facebook ou Google sont systématiquement authentifiés par DKIM, l’expéditeur est validé par SPF, et le message transite à travers une connexion TLS entre les serveurs de Facebook ou Google et le mien (et comme déjà noté, Facebook chiffre aussi le mail lui-même avec OpenPGP).

Les mails envoyés par ma banque, mon agence immobilière, mon assurance, etc, ? Pas de signature DKIM, pas d’enregistrement SPF, pas de TLS…

D’abord, la minute « sodomie de diptère » : ce n’est pas une clef « GPG », c’est une clef « OpenPGP » (OpenPGP est le standard, GnuPG en est une implémentation). Je précise cela parce que les problèmes que tu soulèves sont en fait davantage lié au protocole plutôt qu’à une implémentation précise (tu aurais les mêmes problèmes si tu utilisais Symantec PGP).

Là ça peut éventuellement être utile, bien que GPG soit très limité, puisqu'il faudra que la personne ait une clé GPG, ce qui est pratiquement jamais le cas.

Oui, OpenPGP n’est utile que si les gens s’en servent. C’est le cas de tous les protocoles. (Pour info, j’ai plus de contacts qui utilisent OpenPGP que de contacts qui utilisent OTR — je n’en conclus pas pour autant qu’OTR ne sert à rien).

Prends S/MIME par exemple, l’autre grand standard de chiffrement et signature des e-mails. Connaît-il un meilleur sort que OpenPGP ? Pas vraiment. Obtiens un certificat X.509, tu te poseras exactement les mêmes questions qu’avec ta clef OpenPGP. Tu ne trouveras pas plus de banques envoyant des messages signés par S/MIME que de banques envoyant des messages signés par OpenPGP.

Là encore GPG me semble peu adapté.

Tout-à-fait, et c’est un point sur lequel je tente d’insister dans les crypto- ou keysigning-parties. Trop de débutants se tournent vers GnuPG en pensant que ça va automagiquement protéger leur vie privée, alors que ① OpenPGP ne peut pas grand’chose contre l’analyse de traffic (« à qui il parle », ce qui est souvent plus intéressant que « qu’est-ce qu’il dit »), et ② l’utilisation même d’OpenPGP et surtout de la toile de confiance implique en fait de divulguer certaines informations.

Se créer son trousseau de clés et le diffuser est un cauchemar (j'en veux pour preuve les tutos "Comment se créer une clé pgp parfaite en 723 étapes")

For the record, ces tutos, qui sont souvent le fruit de personnes qui croient certainement bien faire, sont largement déconseillés par les développeurs de GnuPG (dernier exemple en date).

La recommendation officielle pour les débutants qui veulent se créer une paire de clefs est : stick to the defaults!

Et pour les utilisateurs de GnuPG 2.1, c’est concrètement gpg --quick-gen-key mon.adresse@example.com, qui génère une paire de clefs « standard » (avec les fameux réglages par défaut) sans rien demander à l’utilisateur.

Les clés doivent être diffuses via DNS, sur le domaine de l'utilisateur, de manière a ce qu'un correspondant éventuel puisse les récupérer facilement

L’enregistrement OPENPGPKEY pour ça est en cours de standardisation à l’IETF. Il est déjà pris en charge par Bind 9.9.7 (ce qui signifie que Bind peut lire un fichier de zone contenant un tel enregistrement, mais il est aussi utilisable avec n’importe quel autre serveur DNS en passant par la syntaxe du RFC 3597) et par GnuPG depuis sa version 2.1.9.

Un logiciel qui fait du pgp doit faire le maximum pour récupérer les clés pgp des correspondants, ou qu'elles soient, et chiffrer avec.

--auto-key-locate. Peut retrouver une clef dans le DNS (dans des enregistrements CERT (RFC 4398), OPENPGPKEY (cf. point précédent), ou PKA (bidouillage non-standard spécifique à GnuPG, en passe d’être remplacé par OPENPGPKEY)), dans des serveurs LDAP, dans des serveurs de clefs. D’autres mécanismes de lookup sont encore envisageables.

Un logiciel qui fait du pgp doit partir du principe qu'une clé est bonne a partir du moment ou c'est la première qui a été vue pour le contact en question;

Modèle trust-on-first-use, Introduit à partir de GnuPG 2.1.10, sorti en décembre dernier. Ce n’est pas encore le modèle de confiance par défaut (c’est toujours la toile de confiance PGP pour l’instant), mais je pense qu’il est amené à le devenir.

réduire l'impact des métadonnées

Il y a des discussions en cours à l’IETF sur la question. Le problème est que la réduction de la fuite de métadonnées ne peut guère se faire sans modification du protocole (changement du contenu et/ou du format des paquets OpenPGP), donc ça ne peut se faire unilatéralement par GnuPG seul (contrairement à l’introduction d’un nouveau modèle de confiance, parce que le standard laisse explicitement le champ libre aux implémentations de ce côté).

Il nous faut créer des outils qui utilisent ça et fournissent l’utilisabilité qui permettront a gpg d'avoir de nouvelles utilisations un peu plus modernes et un peu plus utiles,

Tout-à-fait d’accord. GnuPG lui-même est loin d’être obsolète, et progresse constamment. Ce sont les front-ends qui pêchent encore.

Y a t'il une solution existante pour avoir du https transparent pour l'utilisateur (pas de message de certificat inconnu) pour ce cas d’utilisation ? J'ai l'impression que non, mais à tout hasard mieux poser cette question d'abord.

À part obtenir, de la part d’une CA reconnue, un certificat intermédiaire autorisé à signer des certificats finaux sans limitation, je ne vois pas.

Du coup vu que let's encrypt à l'air automatisable c'est peut être un bon candidat pour intégration direct dans mon dispositif (arrêtez moi si je me trompe) ce qui serait peut être encore plus simple pour l'utilisateur.

Seulement si le dispositif en question est accessible depuis l’Internet (pour qu’il puisse répondre aux défis d’authentification posés par le serveur ACME).

Question subsidiaire : peut on faire un certificat pour une adresse IP (voire adresse IP locale) et non un DNS ?

Pas avec Let’s Encrypt. Et en théorie, pour une adresse IP locale (je suppose que tu veux dire par là une adresse privée au sens du RFC 1918), ce n’est possible avec aucune autorité de certification : les consignes du CA/Browser Forum leur interdisent d’émettre des certificats pour des adresses privées (mais il y a déjà eu des CA qui ne se sont pas privées de le faire…).

si quelqu'un sait comment ceci est géré sur les switch configurable avec interface web (genre les CISCO d'entreprise ou autre truc bien sérieux/chère) ?

Aucune idée. Si je devais deviner, je serais enclin à dire que c’est géré comme suit : « on s’en fout, c’est prévu pour être utilisé sur le réseau local donc pas d’HTTPS et puis ça ira. » Mais je suis (sûrement) mauvaise langue, aucune entreprise n’oserait se moquer de ses clients comme ça…

• "--certonly" n'est pas une option valide, c'est d'ailleurs une commande, donc sans le "--"

Exact, c’est une commande et non une option, autant pour moi. Si un modérateur pouvait modifier la section correspondante pour enlever les deux tirets devant…

• "--csr" n'est pas une option valide chez moi

Elle existe pourtant bel et bien, mais elle ne fonctionne qu’avec la commande certonly.

comment est-ce qu'on trouve les options disponibles ?

letsencrypt -h all

la limitation des certificats à 90 jours

Il y a au moins deux raisons techniques à cela :

• réduire la durée pendant laquelle Let’s Encrypt doit répondre à des requêtes OCSP (d’après des membres du projet, ce serait le principal facteur limitant la capacité d’émission de Let’s Encrypt — “Let’s Encrypt’s total capacity is bound by its OCSP signing capacity”) ;
• compenser la fait que la révocation des certificats X.509 (ou plus exactement, la communication de la révocation aux clients) ne fonctionne pas en pratique.

la limitation des challenges ACME aux ports 80 et 443

La liste des défis n’est pas définitive. Par exemple, le défi DNS (« prouve-moi que tu contrôles ce domaine en publiant cette valeur dans la zone correspondante »), que beaucoup d’utilisateurs réclamaient depuis le début, est disponible depuis fin janvier (du côté de Let’s Encrypt, pas encore dans le client officiel).

Le fait de devoir laisser la clef privée Let's Encrypt sur le serveur (ce qui peut être contourné)

Hein?

Ce n’est pas clair, mais je pense qu’il parle de la clef privée de ton compte ACME.

Cette clef est générée automatiquement par le client à la première invocation, et stockée sous CONFIGDIR/accounts/. Elle est utilisée ensuite lors des échanges entre le serveur ACME et le client (ce dernier signe la demande de certificat avec sa clef privée avant de l’envoyer au serveur ACME).

Cette clef ne sert qu’à obtenir le certificat et n’a, en principe, rien à faire sur le serveur (ne pas confondre avec la clef privée du certificat, qui bien sûr doit être à disposition du logiciel serveur).

Si cette clef est sur le serveur, c’est parce que le client Letsencrypt lui-même est supposé fonctionner sur le serveur, au nom de l’automatisation.

C'est encore en travaux, et en plus, j'ai à peine le temps de bosser dessus. Mais c'est clairement quelque chose dont j'ai besoin, donc je ne vais pas l'abandonner.

Tu en es probablement déjà conscient, mais je pense que le plus urgent à corriger est le fait que l’option --selector est ignorée : même avec --selector 1, ton script génère une empreinte sur le certificat entier et non sur la clef publique.

Après, autoriser les noms du RFC 7218 à la place des valeurs numériques (par exemple --selector Cert au lieu de --selector 0, --usage DANE-TA au lieu de --usage 2, etc.) serait plus user-friendly.

---

Pour l’intégration dans un fichier de zone, mon approche est la suivante : j’utilise un script qui se contente d’écrire l’empreinte sur sa sortie standard, et j’appelle ce script dans une macro M4 depuis mon fichier de zone. En quelque sorte c’est le fichier de zone qui va chercher la valeur dont il a besoin, plutôt que le script qui vient modifier le fichier de zone.

Concrètement, j’ai ça dans mon fichier de zone :

m4_define(SPKI_DIGEST, `m4_esyscmd(tls-key-mgmt spki-dgst -h $1)')

[…]

_443._tcp.www.example.com.  IN  TLSA  3 1 1 SPKI_DIGEST(ee-web)
                            IN  TLSA  3 1 1 SPKI_DIGEST(ee-web-next)

où tls-key-mgmt est mon script de gestion de clefs (appelé avec l’option spki-dgst, il renvoie l’empreinte de la clef publique spécifiée).

J’utilise une approche similaire pour les enregistrements DKIM et OPENPGPKEY.

Le fichier de zone est traité par M4 juste avant d’être envoyé à dnssec-signzone pour être signé.

Ce que j’apprécie dans cette approche est que le script gérant les clefs et calculant les empreintes n’a pas besoin de savoir quoi que ce soit à propos du fichier de zone, son seul rôle est de sortir les empreintes sans se soucier de ce qu’elles deviennent ensuite.

Cette indépendance me permet de réutiliser le même script pour insérer les empreintes dans le fichier de configuration d’Apache, pour la génération des en-têtes HPKP.

Le truc qu'il manque à letsencrypt c'est la possibilité d'avoir la clée en avance de phase (ou alors je ne l'ai pas vu de façon simple). La clé actuelle + la clée future (valide que dans le future).

C’est possible à condition de gérer soi-même les clefs au lieu de laisser Letsencrypt en générer une nouvelle à chaque renouvellement.

Ça implique de renoncer en partie à l’automatisation fournie par Let’s Encrypt, mais ça n’interdit pas d’automatiser soi-même. :)

Surtout si il y a un script qui fait tout tout seul :)

Un exemple à LA RACHE ? Un premier script new-key.sh pour gérer les rotations de clefs :

#!/bin/bash

keydir=keys

if [ -f $keydir/server-key-next.pem ]; then
    # La prochaine clef existe déjà, on la promeut
    mv $keydir/server-key-next.pem $keydir/server-key.pem
else
    # Pas de prochaine clef (première invocation?),
    # on génère une active
    openssl genrsa -out $keydir/server-key.pem 2048
fi

# On génère la nouvelle prochaine clef
openssl genrsa -out $keydir/server-key-next.pem 2048

# On génère les empreintes
for key in $keydir/server-key{,-next}.pem ; do
    hpkp_pin=$(openssl rsa -in $key -pubout -outform DER 2>/dev/null | \
        openssl dgst -sha256 -binary | \
        openssl enc -base64)
    tlsa_pin=$(openssl rsa -in $key -pubout -outform DER 2>/dev/null | \
        openssl dgst -sha256 | cut -d' ' -f2)
    echo "HPKP: pin-sha256=\"$hpkp_pin\""
    echo "TLSA: 3 1 1 $tlsa_pin"
done

# On génère la demande de certificat
# (cert.cfg contient les subjectAlternativeName)
openssl req -new -key $keydir/server-key.pem \
    -config cert.cfg -outform DER -out cert.csr

Un second script new-cert.sh demande un nouveau certificat :

#!/bin/sh

if [ ! -f cert.csr ]; then
    ./new-key.sh
fi

letsencrypt \
    certonly \
    --config ~/.config/letsencrypt/letsencrypt.conf \
    --csr cert.csr \
    --cert-path cert.pem \
    --chain-path chain.pem \
    --fullchain-path cert+chain.pem \
    --authenticator letsencrypt-ssh:ssh \
    --letsencrypt-ssh:ssh-server root@server.example.com \
    --domains $(openssl req -inform DER -in cert.xsr -noout -text | sed -nre 's/ +DNS://gp')

Appeler le second script chaque fois qu’il faut renouveler le certificat ; appeler préalablement le premier script chaque fois qu’on veut changer de clef.

Évidemment, le premier script peut faire quelque chose de plus intéressant que de simplement afficher les épingles. Par exemple, aller mettre à jour un fichier de zone.

Le problème évident avec cette solution, c’est son caractère manuel

Alors que ça n'a rien à voir avec la validation manuelle.

La solution à laquelle je fais référence dans cette phrase est celle qui consiste à utiliser à la fois la commande certonly et l’option --manual.

Je rappelle que le premier but recherché, dans cette section, était non pas tant d’éviter de lancer le client avec les privilèges du super-utilisateur (pour ça, --manual n’est en effet pas forcément nécessaire), mais surtout d’éviter de lancer le client sur le serveur (peu importe ses privilèges).

Et pour ça, avec le client officiel l’option --manual est indispensable, toutes les autres méthodes d’authentification (standalone ou webroot) supposent que le client est sur le serveur — sauf à utiliser la méthode sshfs proposée par ɹǝıʌıʃO (méthode très élégante d’ailleurs, je m’en veux de ne pas y avoir pensé).

Donc, le premier tronçon (mon ordi jusqu'au serveur webmail de Google) est sécurisé si je suis en https, c'est ça ?

Oui.

(En réalité mon explication partait du principe que tu utilisais un client lourd, mais le principe reste grosso modo le même si tu utilises le webmail — c’est du HTTP et non plus du SMTP, mais c’est chiffré quand même.)

Néanmoins, c'est chiffré par Google, mais Google conserve bien la possibilité de lire le contenu de mon message, n'est-ce pas ?

Oui. C’est du chiffrement de point à point : le message est en clair chez toi, il est transmis chiffré jusqu’à Google qui le déchiffre, le rechiffre à nouveau pour l’envoyer au serveur du destinataire qui le re-déchiffre et le stocke (en clair) jusqu’à ce que le destinataire le réclame, à ce moment-là il est re-chiffré encore une fois et finalement déchiffré sur l’ordinateur du destinataire.

Tu dis que c'est la connexion au serveur SMTP de Google qui est chiffré (dans le cas où le cadenas est vert) ? Ce n'est pas normalement ce que j'ai lorsque je me connecte sur mail.google.com ?

La connexion est chiffrée lorsque ton client mail se connecte au serveur SMTP d’expédition de Google pour soumettre un mail à envoyer à un correspondant. Mais ça ne concerne que le premier tronçon du trajet (entre ton ordinateur et Google).

Sur le tronçon suivant, lorsque le serveur de Google établit une connexion avec le serveur du destinataire, la connexion n’est pas nécessairement chiffrée. Elle ne peut l’être que si les deux extrémités du tronçon permettent le chiffrement. Google le permet de son côté, mais si le destinataire ne le permet pas, alors Google envoie le mail en clair (pas trop le choix…).

Or, si tu peux facilement vérifier que la connexion entre ton ordinateur et le serveur d’envoi est chiffrée, tu n’as en revanche aucun moyen de savoir si la connexion du tronçon suivant le sera (ça se passe uniquement entre Google et le fournisseur de messagerie du destinataire)… sauf à ce que Google t’en informe spécifiquement, ce qui est précisément ce dont il est question ici.

(Historiquement, l’énorme majorité des connexions de serveur à serveur étaient non chiffrées, parce que les serveurs supportant le chiffrement étaient rares — et donc le cas où à la fois le serveur émetteur et le serveur destinataire supportaient le chiffrement étaient encore plus rares. C’est en train de changer depuis quelques années, en partie sous la poussée de Google justement.)