Sur la page ulule tu évoques l'utilisation de grammatical dans l'administration, est-ce que tu en sais plus ? À quelle échelle ? As-tu des retours de leur part ?
Ce qui me fait d'ailleurs pensé que j'apprécierai que mes impôts financent de tels projets (d'intérêt public) plutôt que des produits privés qui ne profiterons pas aux contribuables.
En ce qui concerne l'implémentation des tests, je pense qu'il est déjà possible de créer quelques cas unitaires qui se focalisent sur des fonctions élémentaires (c'est d'ailleurs une bonne pratique dans le domaine de commencer ainsi,) puis sur des fonctions un peu plus évolués et ainsi de suite (par exemple, les deux premières phases du préprocesseur ne font, a priori, pas appel au correcteur orthographique.
Enfin, une autre technique serait le bouchonnage, pour simuler les appels au correcteur orthographique et renvoyer les valeurs attendues pour une petite liste de terme.
J'entends bien que ce n'est pas la solution idéal, mais c'est un premier pas qui t'aidera un peu dans l'immédiat et qui te permettra également de développer plus rapidement tes tests lorsque tu sera en mesure d'utiliser une implémentation complète.
Toujours dans le même sujet, tu utilise un corpus d'erreurs grammaticales, est-ce toi qui l'a créé ? Car il en existe quelques-uns qui ont été créés dans le but justement de tester des outils de vérification grammaticale. ;)
PS : vu l'heure, j'affirme, sans trop prendre de risque que, oui, j'aurai bien besoin d'une intégration de grammalecte dans Firefox. :°
Pendant la période de transition, on contacte des serveurs avec l'un ou l'autre des certificats, mais pas les deux. On peut pas utiliser l'ancien.
En apparence, les deux phrases se contredisent ; mais je comprends ce que tu entends par là : une partie des instances présentent l'ancien une autre le nouveau.
Si il est toujours possible de présenter l'ancien, on peux utiliser la méthode que je décris précédemment : utilisation de l'ancien certificat pendant le premier handshake puis, après l'établissement du canal sécurisé, demande de renégociation [1] en présentant un nouveau certificat.
Par contre, la fausse alerte apparaît s'il n'est, réellement, plus possible de présenter l'ancien (typiquement par perte de la clé privée) et qu'il n'est pas encore révoqué par la CA.
De plus, cette solution souffre du problème dont je parle précédemment puisque le serveur doit être configuré de manière à permettre l'épinglage.
pendant la période de transition vers le nouveau certif
Le serveur demanderai une renégociation avec le nouveau certificat après l'établissement avec l'ancien.
Bien évidemment c'est plus lourd, mais c'est une possibilité. Il y en a peut-être d'autres.
Quoiqu'il en soit, c'est effectivement une problématique qui donne un intérêt à ces nouveaux en-tête, ce qui est dommage car l'épinglage devrait être un choix de client non dépendant de celui du serveur quitte à être moins user-friendly.
S'il arrive à ajouter une entête ou voir le trafic qui part sur une URL donnée, c'est qu'il fait déjà du MitM qui fonctionne.
Quelque chose m'avait échappé : le fait que le PKP-RO doit être envoyé après l'établissement du canal sécurisé ce qui ne permet pas à l'attaquant de demander les infos.
Du coup l'attaque nécessiterai une configuration très précise, où notamment, l'accès à la report-uri se ferait en clair et le client ne contacterai pas le serveur entre le moment du report et la date d'expiration de son épinglage.
Ce ne serait pas user-friendly, la plupart des sites changes avant la date d'expiration du certificat.
En fait, cela n'impacterait pas, dans la mesure où je parlai de révocation et non pas d'expiration.
Ceci étant dit, ta remarque sur les certificats différents pour chaque instance d'un même service met, effectivement, le point sur un problème. Même si je ne suis pas, a priori, convaincu de l'intérêt de ce genre de configuration.
Tout comme je ne le suis pas d'avoir un certificat wildcard doublé d'un certificat nominatif et de manière générale : d'avoir plusieurs certificats matchant les mêmes cibles.
Quant à la directive report-uri, elle me fait l'effet d'une une issue de secours mitoyenne de la porte équipée des derniers modèles de serrure tip-top inviolable qui doit toujours être fermée.
Je ne comprend pas non plus. […]
Effectivement, cela mérite précision : j'imagine un MITM qui souhaite s'interposer, sans report-uri il n'a aucun moyen de connaitre la situation du client et il a le choix de tenter d'imposer ses certificats (quitte à les annoncer avant dans un PKP) et donc de, potentiellement, lever une alerte ou d'abandonner.
Par contre, avec la directive et l'en-tête PKP-RO, il peut demander, sans lever d'alerte, le moment précis pour lancer une attaque qui réussira.
En même temps, le navigateur pourrait tout aussi bien épingler par défaut les certificats serveur et alerter l'utilisateur dans le cas où le certificat a changé et qu'il n'a pas été révoqué.
La directive includeSubDomains me semble être un brin doublon avec le champ SubjectAltName des certificats.
Quant à la directive report-uri, elle me fait l'effet d'une issue de secours mitoyenne de la porte équipée des derniers modèles de serrure tip-top inviolable qui doit toujours être fermée.
# Édition d'attestation en ligne
Posté par ealprr . En réponse au journal Confinement Covid-19 et attestations, mise à jour. Évalué à -1.
https://vik.io/sortie/#
Je n'ai pas réussi à faire fonctionner la signature cependant.
[^] # Re: De la qualification correcte du problème
Posté par ealprr . En réponse au journal miniurl ki pu. Évalué à 1.
Si.
Un peu vieux — le CDN a changé — mais le principe est toujours le même.
# Utilisation dans l'administration
Posté par ealprr . En réponse à la dépêche Grammalecte, correcteur grammatical. Évalué à 4.
Sur la page ulule tu évoques l'utilisation de grammatical dans l'administration, est-ce que tu en sais plus ? À quelle échelle ? As-tu des retours de leur part ?
Ce qui me fait d'ailleurs pensé que j'apprécierai que mes impôts financent de tels projets (d'intérêt public) plutôt que des produits privés qui ne profiterons pas aux contribuables.
En ce qui concerne l'implémentation des tests, je pense qu'il est déjà possible de créer quelques cas unitaires qui se focalisent sur des fonctions élémentaires (c'est d'ailleurs une bonne pratique dans le domaine de commencer ainsi,) puis sur des fonctions un peu plus évolués et ainsi de suite (par exemple, les deux premières phases du préprocesseur ne font, a priori, pas appel au correcteur orthographique.
Enfin, une autre technique serait le bouchonnage, pour simuler les appels au correcteur orthographique et renvoyer les valeurs attendues pour une petite liste de terme.
J'entends bien que ce n'est pas la solution idéal, mais c'est un premier pas qui t'aidera un peu dans l'immédiat et qui te permettra également de développer plus rapidement tes tests lorsque tu sera en mesure d'utiliser une implémentation complète.
Toujours dans le même sujet, tu utilise un corpus d'erreurs grammaticales, est-ce toi qui l'a créé ? Car il en existe quelques-uns qui ont été créés dans le but justement de tester des outils de vérification grammaticale. ;)
PS : vu l'heure, j'affirme, sans trop prendre de risque que, oui, j'aurai bien besoin d'une intégration de grammalecte dans Firefox. :°
[^] # Re: Politique de confiance client
Posté par ealprr . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 0. Dernière modification le 19 avril 2015 à 17:12.
En apparence, les deux phrases se contredisent ; mais je comprends ce que tu entends par là : une partie des instances présentent l'ancien une autre le nouveau.
Si il est toujours possible de présenter l'ancien, on peux utiliser la méthode que je décris précédemment : utilisation de l'ancien certificat pendant le premier handshake puis, après l'établissement du canal sécurisé, demande de renégociation [1] en présentant un nouveau certificat.
Par contre, la fausse alerte apparaît s'il n'est, réellement, plus possible de présenter l'ancien (typiquement par perte de la clé privée) et qu'il n'est pas encore révoqué par la CA.
De plus, cette solution souffre du problème dont je parle précédemment puisque le serveur doit être configuré de manière à permettre l'épinglage.
[1]: rfc5246 section-7.4.1.1 The HelloRequest message MAY be sent by the server at any time.
[^] # Re: Politique de confiance client
Posté par ealprr . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 0.
Le serveur demanderai une renégociation avec le nouveau certificat après l'établissement avec l'ancien.
Bien évidemment c'est plus lourd, mais c'est une possibilité. Il y en a peut-être d'autres.
Quoiqu'il en soit, c'est effectivement une problématique qui donne un intérêt à ces nouveaux en-tête, ce qui est dommage car l'épinglage devrait être un choix de client non dépendant de celui du serveur quitte à être moins user-friendly.
Quelque chose m'avait échappé : le fait que le PKP-RO doit être envoyé après l'établissement du canal sécurisé ce qui ne permet pas à l'attaquant de demander les infos.
Du coup l'attaque nécessiterai une configuration très précise, où notamment, l'accès à la report-uri se ferait en clair et le client ne contacterai pas le serveur entre le moment du report et la date d'expiration de son épinglage.
[^] # Re: Politique de confiance client
Posté par ealprr . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 1.
En fait, cela n'impacterait pas, dans la mesure où je parlai de révocation et non pas d'expiration.
Ceci étant dit, ta remarque sur les certificats différents pour chaque instance d'un même service met, effectivement, le point sur un problème. Même si je ne suis pas, a priori, convaincu de l'intérêt de ce genre de configuration.
Tout comme je ne le suis pas d'avoir un certificat wildcard doublé d'un certificat nominatif et de manière générale : d'avoir plusieurs certificats matchant les mêmes cibles.
Effectivement, cela mérite précision : j'imagine un MITM qui souhaite s'interposer, sans report-uri il n'a aucun moyen de connaitre la situation du client et il a le choix de tenter d'imposer ses certificats (quitte à les annoncer avant dans un PKP) et donc de, potentiellement, lever une alerte ou d'abandonner.
Par contre, avec la directive et l'en-tête PKP-RO, il peut demander, sans lever d'alerte, le moment précis pour lancer une attaque qui réussira.
# Politique de confiance client
Posté par ealprr . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 1. Dernière modification le 18 avril 2015 à 23:16.
En même temps, le navigateur pourrait tout aussi bien épingler par défaut les certificats serveur et alerter l'utilisateur dans le cas où le certificat a changé et qu'il n'a pas été révoqué.
La directive includeSubDomains me semble être un brin doublon avec le champ SubjectAltName des certificats.
Quant à la directive report-uri, elle me fait l'effet d'une issue de secours mitoyenne de la porte équipée des derniers modèles de serrure tip-top
inviolablequi doit toujours être fermée.