#1 Le 05/03/2020, à 15:42
- DonutMan75
[RESOLU] gpg dans les règles de l'art ?
Bonjour à tous,
je souhaite installer apache2 from scratch et je bloque sur la première étape (que je souhaiterais bien comprendre) : vérifier l'authenticité du .tar.gz que j'ai récupéré.
Pour cela, je peux télécharger trois fichiers sur la page de téléchargement d'Apache :
httpd-2.4.41.tar.gz : les sources du serveur Apache
httpd-2.4.41.tar.gz.asc : le fichier de signature
httpd-2.4.41.tar.gz.sha256 : le checksum
[EDIT] : pas de réponse encore sur ma démarche de validation (n'hésitez pas, je suis preneur de toute remarque constructive !) mais quelques éclaircissements sur le "[User ID not found]" mentionné plus bas et qui m'a assez intrigué
Le checksum me permet de m'assurer que le tar.gz a bien la même empreinte :
$ sha256sum -c httpd-2.4.41.tar.gz.sha256
httpd-2.4.41.tar.gz: RéussiPour aller plus loin, je peux retenter l'expérience avec le fichier de signature. Ce dernier ayant été chiffré avec une clef privée détenue par Apache, c'est une sécurité supplémentaire contre la falsification. Une des étapes importantes de ce test est de s'assurer qu'on dispose bien de la bonne clef publique de vérification. C'est sur ce point que j'ai des doutes sur ma méthodologie.
Je me permets de vous livrer ici mes tests, si quelqu'un d'un peu familier avec gpg pouvait me donner son avis je lui en serai très reconnaissant !
Lorsqu'on tente naïvement un gpg --verify, on tombe sur une erreur mentionnée dans la FAQ d'apache :
$ gpg --verify httpd-2.4.41.tar.gz.asc httpd-2.4.41.tar.gz
gpg: Signature made ven. 09 août 2019 15:36:55 CEST
gpg: using RSA key B9E8213AEFB861AF35A41F2C995E35221AD84DFF
gpg: Can't check signature: Pas de clef publiqueExplication : mon trousseau gpg ne contient pas la clef publique d'Apache, il est donc dans l'incapacité de vérifier ce fichier de signature.
C'est à ce niveau que je bloque pour la suite : il faut trouver et importer la clef publique d'Apache.
Plusieurs choix s'offrent à nous :
contacter directement la personne propriétaire du fichier de signature pour qu'il nous communique la clef publique associée
chercher sur le site d'apache si une clef publique n'est pas disponible en téléchargement (problématique si le site est compromis, un intrus pouvant substituer une fausse clef publique et l'utiliser pour signer le tar.gz)
interroger un serveur de clef (la politique de sécurité diffère selon les serveurs mais d'ordinaire la personne déposant une clef doit valider son dépôt en prouvant qu'elle a bien accès au mail associé à la clef)
C'est cette dernière option qu'a choisi la FAQ d'Apache en proposant une importation depuis le serveur de clef "pgpkeys.mit.edu"
% gpg --keyserver pgpkeys.mit.edu --recv-key 791485A8
gpg: requesting key 791485A8 from HKP keyserver pgpkeys.mit.edu
gpg: trustdb created
gpg: key 791485A8: public key "Jim Jagielski <jim@apache.org>" imported
gpg: key 791485A8: public key "Jim Jagielski <jim@apache.org>" imported
gpg: Total number processed: 2
gpg: imported: 2 (RSA: 2)Ca a une bonne tête, le propriétaire de la clef a un mail en @apache.org
Par contre quand je tente de reproduire l'expérience de mon côté c'est tout de suite moins beau :
$ gpg --keyserver pgpkeys.mit.edu --recv-key B9E8213AEFB861AF35A41F2C995E35221AD84DFF
gpg: Note: signatures using the SHA1 algorithm are rejected
gpg: key 0x995E35221AD84DFF: 65 signatures not checked due to missing keys
gpg: key 0x995E35221AD84DFF: 5 bad signatures
gpg: key 0x995E35221AD84DFF: public key "[User ID not found]" imported
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: Total number processed: 1
gpg: imported: 1Alors déjà le public key "[User ID not found]" me paraît très bizarre.
De plus, je ne sais pas interpréter cette ligne :
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2ula classification -qnmfu suit ce formalisme :
- No ownertrust assigned / not yet calculated
e Trust calculation has failed; probably due to an expired key
q Not enough information for calculation
n Never trust this key
m Marginally trusted
f Fully trusted
u Ultimately trusted
Je suppute que les deux clefs ultimate (u) sont deux clefs déjà présentes dans mon trousseau et qui m'appartiennent car si je liste les signatures de la clef apache, j'obtiens ce résultat :
$ gpg --list-sigs 0x995E35221AD84DFF
pub rsa2048/0x995E35221AD84DFF 2011-06-16 [SCA] [expires: 2021-03-04]
Key fingerprint = B9E8 213A EFB8 61AF 35A4 1F2C 995E 3522 1AD8 4DFF
uid [ unknown] [jpeg image of size 18442]
sig 0x03C296949C1750C5 2017-05-26 [User ID not found]
sig 3 0x995E35221AD84DFF 2016-03-05 [User ID not found]
sig 3 0x995E35221AD84DFF 2016-03-05 [User ID not found]
sig 0xED3873F5D3262722 2016-05-15 [User ID not found]
sig 0x3F902C276ED9BE21 2017-01-10 [User ID not found]
sig 0x0A9DAF6713B86349 2017-05-18 [User ID not found]
sig 0x193F180AB55D9977 2018-03-13 [User ID not found]
sig 0x94D336A36D15930A 2016-05-23 [User ID not found]
sig 0xE4032DC4EF0CF38A 2017-05-17 [User ID not found]
sig 0x3FAAD2CD5ECBB314 2017-05-17 [User ID not found]
sig 0x62D48FAD16A0DE01 2016-05-24 [User ID not found]
sig 0x6F0CDAE700B6899D 2017-05-17 [User ID not found]
sig 0xA2AB081F26518FEE 2017-05-18 [User ID not found]
sig 0x9C49F42147085518 2017-05-26 [User ID not found]
sig 3 0xFF1F407C0D3C2430 2016-05-13 [User ID not found]
sig 3 0xF3AD5C94A67F707E 2017-05-30 [User ID not found]
sig 3 0xC1EDBB9CA400FD50 2017-05-16 [User ID not found]
sig 3 0x03E2BF1E0FB52BC6 2017-05-24 [User ID not found]
sig 0xEC99EE267EB5F61A 2018-03-25 [User ID not found]Si je regarde les infos de cette clef, je vois enfin qu'elle dispose d'une photo :
$ gpg --list-keys
/home/donut/.gnupg/pubring.kbx
---------------------------------
pub rsa2048/0x995E35221AD84DFF 2011-06-16 [SCA] [expires: 2021-03-04]
Key fingerprint = B9E8 213A EFB8 61AF 35A4 1F2C 995E 3522 1AD8 4DFF
uid [ unknown] [jpeg image of size 18442]Je peux l'extraire avec -showphoto et j'obtiens alors ça :
La clef récupérée est toutefois conforme au fichier de signature car cette fois-ci :
$ gpg --verify httpd-2.4.41.tar.gz.asc httpd-2.4.41.tar.gz
gpg: Signature made ven. 09 août 2019 15:36:55 CEST
gpg: using RSA key B9E8213AEFB861AF35A41F2C995E35221AD84DFF
gpg: Good signature from "[jpeg image of size 18442]" [uncertain]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: B9E8 213A EFB8 61AF 35A4 1F2C 995E 3522 1AD8 4DFFMais au final, comment puis-je m'assuser que cette clef est bien la bonne ? Qu'en pensez-vous ?
Merci d'avance 
Dernière modification par DonutMan75 (Le 06/03/2020, à 08:46)
Hors ligne
#2 Le 05/03/2020, à 17:28
- DonutMan75
Re : [RESOLU] gpg dans les règles de l'art ?
Quelques apports :
1) pour rechercher une clef a posteriori, on peut utiliser l'option --search-keys.
Il est étonnant de ne trouver aucune clef associée à apache.org non ? (en comparaison, je trouve 7 clefs associées à ldlc.com)
$ gpg --search-keys "apache.org"
gpg: error searching keyserver: Pas de données
gpg: keyserver search failed: Pas de données
$ gpg --search-keys "ldlc.com"
gpg: data source: http://192.146.137.98:11371
(1) Olivier JEAN <o.jean@ldlc.com>
2048 bit RSA key 0xDFC1CE19211D10ED, created: 2013-12-30, expires: 2017-12-30 (expired)
(2) olivier de la clergerie <olivier@ldlc.com>
olivier de la clergerie <o.delaclergerie@ldlc.com>
2048 bit RSA key 0x7215775B84225F03, created: 2013-12-18
(etc...)
Keys 1-7 of 7 for "ldlc.com". Enter number(s), N)ext, or Q)uit > Q
gpg: error searching keyserver: Opération annulée
gpg: keyserver search failed: Opération annulée2) Concernant le "[User ID not found]", ce dernier n'apparaît pas lorsqu'on recherche la clef directement via l'interface web du serveur de clef ?!!
En revanche, si on copie cette clef publique dans un fichier pubkey et qu'on tente un import le "[User ID not found]" revient !
$ gpg --import pubkey
gpg: Note: signatures using the SHA1 algorithm are rejected
gpg: key 0x995E35221AD84DFF: 65 signatures not checked due to missing keys
gpg: key 0x995E35221AD84DFF: 5 bad signatures
gpg: key 0x995E35221AD84DFF: public key "[User ID not found]" imported
gpg: Total number processed: 1
gpg: imported: 1
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2uCe fil (de 2004 !) semble mentionner un bug... Mais il est probable que j'ai loupé quelque chose à un moment..
Ce fil de discussion est à peine plus récent (2013) et suggère d'importer chaque clef publique associée à une signature via un petit script bash/perl. Ca marchouille vaguemment.
3) Concernant la liste des signatures de la clef apache
La doc indique que le chiffre (optionnel) qui suit sig indique le niveau de vérification effectué par la personne ayant signé la clef publique
0 means you make no particular claim as to how carefully you verified the key.
1 means you believe the key is owned by the person who claims to own it but you could not, or did not verify the key at all. This is
useful for a "persona" verification, where you sign the key of a pseudonymous user.2 means you did SPAM verification of the key. For example, this could mean that you verified the key fingerprint and checked the
user ID on the key against a photo ID.3 means you did extensive verification of the key. For example, this could mean that you verified the key fingerprint with the owner
of the key in person, and that you checked, by means of a hard to forge document with a photo ID (such as a passport) that the name
of the key owner matches the name in the user ID on the key, and finally that you verified (by exchange of email) that the email
address on the key belongs to the key owner.
N'affichons que les signatures qui se définissent elle-mêmes comme "super vérifiées" (cert-level à 3)
$ gpg --with-fingerprint --keyid-format 0xlong --list-sigs 0xB9E8213AEFB861AF35A41F2C995E35221AD84DFF | grep "sig 3"
sig 3 0x995E35221AD84DFF 2016-03-05 [User ID not found]
sig 3 0x995E35221AD84DFF 2016-03-05 [User ID not found]
sig 3 0xFF1F407C0D3C2430 2016-05-13 [User ID not found]
sig 3 0xF3AD5C94A67F707E 2017-05-30 [User ID not found]
sig 3 0xC1EDBB9CA400FD50 2017-05-16 [User ID not found]
sig 3 0x03E2BF1E0FB52BC6 2017-05-24 [User ID not found]Les options "--with-fingerprint --keyid-format 0xlong" imposent l'affichage des empreintes complète ainsi qu'il est détaillé sur riseup. En pratique, ça ne change rien à l'affichage..
Faisons abstraction du récurrent User ID not found et comparons ces empreintes à celles des signataires apache.
Les empreintes des signataires sont systématiquement deux fois plus longues que celles que j'obtiens avec --list-sigs !
Je remarque toutefois une correspondance avec la partie droites des empreintes des signataires.
Cette vérification est-elle suffisante ? J'ignore s'il est possible de vérifier la signature des clefs publiques qu'on récupère et/ou si gpg s'en occupe tout seul ??
Je ne comprends pas pourquoi les empreintes sont deux fois plus longues sur le site d'apache..
Bon j'ignore s'il y a des experts de gpg ici mais je suis un peu surpris de me retrouver dans cette situation.. Je m'attendais à une vérification fiable et rapide (surtout qu'on parle d'apache quand même pas d'un obscur projet trouvé au fond du net..). Je vous remercie par avance pour ton commentaires ou aide
D.
Dernière modification par DonutMan75 (Le 05/03/2020, à 17:45)
Hors ligne
#3 Le 05/03/2020, à 20:19
- DonutMan75
Re : [RESOLU] gpg dans les règles de l'art ?
Concernant le "[User ID not found]", une piste intéressante sur superuser.
En gros certains serveurs de clefs masquent l'user-id ?
$ gpg --recv-keys 0xB9E8213AEFB861AF35A41F2C995E35221AD84DFF
gpg: key 995E35221AD84DFF: new key but contains no user ID - skipped
gpg: Quantité totale traitée : 1
gpg: sans identité : 1
$ gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 0xB9E8213AEFB861AF35A41F2C995E35221AD84DFF
gpg: clef 995E35221AD84DFF : clef publique « Daniel Ruggeri (http://home.apache.org/~druggeri/) <druggeri@apache.org> » importée
gpg: Quantité totale traitée : 1
gpg: importées : 1Je creuserai ça demain
Bonne soirée à tous !
D.
Hors ligne
#4 Le 06/03/2020, à 08:43
- DonutMan75
Re : [RESOLU] gpg dans les règles de l'art ?
Bonjour à tous,
quelques précisions supplémentaires.
Je n'ai pas réussi à trouver d'info sur la politique du serveur de clef mentionné par la doc d'Apache (http://pgpkeys.mit.edu/). En revanche, gpg (qui se base sur dirmngr pour tout ce qui concerne l'interrogation de serveur de clef) se base sur keys.openpgp.org sauf mention explicite contraire de l'utilisateur.
If no keyserver is explicitly configured, dirmngr will use the built-in default of hkps://keys.openpgp.org.
Or le serveur de clef keys.openpgp.com ne diffuse pas les informations personnelles des clefs
Une clé OpenPGP comprend deux sortes de renseignements :
Les renseignements d’identité sont les parties d’une clé qui donne l’identité de son propriétaire, aussi désignés « ID utilisateur ». Un ID utilisateur comprend habituellement un nom et une adresse courriel.
Les renseignements qui ne permettent pas de vous identifier sont de nature technique, au sujet de la clé même. Ils comprennent les grands nombres utilisés pour confirmer les signatures et chiffrer les messages. Ils comprennent aussi des métadonnées telles que la date de création, des dates d’expiration et l’état de révocation.
Traditionnellement, ces renseignements ont toujours été distribués ensemble. Sur keys.openpgp.org, ils sont traités différemment. Bien que quelqu’un puisse téléverser toutes les parties d’une clé OpenPGP vers keys.openpgp.org, notre serveur de clés ne conservera et ne publiera que certaines parties, sous certaines conditions :Tout renseignement qui ne permet pas de vous identifier sera enregistré et distribué librement s’il passe un contrôle cryptographique d’intégrité. N’importe qui peut télécharger ces parties n’importe quand, car elles ne comprennent que des données techniques qui ne peuvent pas être utilisées pour identifier quelqu’un directement. Les logiciels OpenPGP de qualité peuvent utiliser keys.openpgp.org pour garder ces renseignements à jour pour n’importe quelle clé qu’il connaît. Cela permet aux utilisateurs d’OpenPGP d’assurer des communications sécurisées et fiables.
Les renseignements d’identité d’une clé OpenPGP ne sont distribués qu’avec consentement. Ils comprennent des données personnelles et ne sont pas strictement nécessaires pour qu’une clé soit utilisée pour le chiffrement ou la confirmation par signature. Une fois que le propriétaire donne son consentement en confirmant son adresse courriel, la clé peut être trouvée en cherchant son adresse courriel.
Donc il est attendu qu'on récupère certaines clefs SANS les informations personnelles permettant de l'identifier. Je suppose que ce choix permet de limiter le spam ? (spam soit du côté du propriétaire de la clef, qui expose son email au net; soit du côté du serveur de clef qui reçoit des clefs sans pouvoir s'assurer que le mail est valide et que le propriétaire de la clef y a bien accès)
Au passage la FAQ d'Apache est obsolète puisque l'option --keyserver l'est aussi. En gros tout ce qui concerne les serveurs de clef devrait désormais être défini directement dans dirmngr.
--receive-keys keyIDs
--recv-keys keyIDs
Import the keys with the given keyIDs from a keyserver. Option --keyserver must be used to give the name of this keyserver.(...)
--keyserver name
This option is deprecated - please use the --keyserver in ‘dirmngr.conf’ instead.Use name as your keyserver. This is the server that --receive-keys, --send-keys, and --search-keys will
communicate with to receive keys from, send keys to, and search for keys on. The format of the name is
a URI: `scheme:[//]keyservername[:port]' The scheme is the type of keyserver: "hkp" for the HTTP (or
compatible) keyservers, "ldap" for the LDAP keyservers, or "mailto" for the Graff email keyserver. Note
that your particular installation of GnuPG may have other keyserver types available as well. Keyserver
schemes are case-insensitive. After the keyserver name, optional keyserver configuration options may be
provided. These are the same as the global --keyserver-options from below, but apply only to this par‐
ticular keyserver.Most keyservers synchronize with each other, so there is generally no need to send keys to more than
one server. The keyserver hkp://keys.gnupg.net uses round robin DNS to give a different keyserver each
time you use it.
Bon je crois avoir compris ce qu'il se passe au final. Cette politique complexifie un peu la tâche de la personne qui souhaite vérifier l'authenticité d'un fichier non ?
Au passage et au fil de mes lectures, j'ai remarqué que certains serveurs interdisent ou limitent désormais la signature de clefs publiques par des tiers, ceci en réaction à une vague de "hack" des serveurs SKS en juillet dernier. Pas mal de choses sont en train de changer j'ai l'impression.
Bon, je vais passer le fil en résolu. J'espère que mes pérégrinations pourront aider une personne qui se trouverait dans le même cas que moi ^^
Bonne journée à tous !
Hors ligne