10 commentaires
salut ! la révocation TLS ça marche pas tout seul. le client doit activement vérifier la révocation. tes clients implémentent la vérification de la CRL (Certificate Revocation List) ou de l'OCSP (Online Certificate Status Protocol) ? si non, ils vont accepter le certif tant qu'il est valide au niveau de sa date d'expiration.
ah ok je pige. j'ai bien activé la génération de CRL sur mon backend pki vault et j'ai des endpoints pour la crl et l'ocsp mais non, mes clients sont des services go/python maisons et j'ai rien implémenté pour vérifier les CRLs/OCSP. je pensais que c'était plus "automagique" au niveau du handshake TLS.
non pas du tout. le TLS est par nature stateless. quand un client reçoit un certif, il vérifie la chaîne de confiance et la date. pour la révocation, il doit faire une requête spécifique (HTTP pour CRL, OCSP pour son service dédié) pour voir si le certif est sur liste noire. tu dois soit modifier tes clients pour qu'ils fassent cette vérif, soit mettre un proxy devant qui le fera.
si tu pars sur OCSP, assure-toi que ton ocsp_url dans la config du backend pki de vault est accessible par tes clients et que vault lui-même peut signer les réponses OCSP. et surtout, les certificats générés doivent inclure l'extension OCSP pour indiquer où trouver le répondeur.
pour CRL, le plus simple est de publier la CRL sur un endpoint HTTP accessible publiquement (ou au moins par tes clients). vault peut le faire automatiquement avec crl_distribution_points. tes clients doivent alors télécharger cette CRL régulièrement et la mettre à jour pour savoir quels certifs sont révoqués.
attention, la révocation par CRL peut avoir un délai si la CRL n'est pas rafraîchie souvent. OCSP est beaucoup plus en temps réel, mais ça rajoute une requête réseau supplémentaire au handshake TLS. souvent, on utilise OCSP stapling avec un proxy pour éviter cette requête client.
et n'oublie pas le cache OCSP/CRL sur tes proxys ou clients pour pas submerger vault de requêtes de vérification. des caches bien configurés peuvent réduire drastiquement la latence et la charge.
ok je pige beaucoup mieux maintenant ! c'est clairement un manque d'implémentation côté client. on va partir sur un reverse proxy (probablement envoy) qui fera la validation OCSP stapling et la gestion des CRLs. ça me semble le plus robuste pour notre infra. merci pour toutes ces explications détaillées les gars !
Laisser une réponse
Vous devez être connecté pour poster un message !
hello à tous ! on utilise vault pour gérer notre pki interne. on génère des certificats dynamiquement pour nos microservices. le souci c'est que quand je révoque un certif via vault (genre
vault write pki/revoke serial_number=...), les clients qui ont ce certif continuent à l'accepter sans problème. je m'attendais à ce qu'il soit invalide direct. j'ai loupé un truc évident sur le fonctionnement de la révocation TLS avec Vault ?