Donc, on revient au problème d'implémentation du HTTPS dans cette configuration...
Petite réflexion rapide (et sûrement foireuse, mais merci pour l’exercice).
Première solution : un certificat auto-signé par périphérique, avec sur le périphérique lui-même une étiquette mentionnant l’empreinte du certificat. À charge pour l’utilisateur, lorsque son navigateur tente de lui faire peur en lui criant que la connexion n’est pas authentifiée et qu’il va mourir, de vérifier que l’empreinte affichée par la navigateur correspond à celle collée sur le périphérique.
Éventuellement faire en sorte que le serveur web serve un en-tête HPKP dans l’espoir que le navigateur se souvienne du certificat et n’affiche pas l’avertissement à chaque fois (aucune garantie que ça marche cela dit, la spécification HPKP est muette sur le cas des certificats auto-signés).
Avantage : assez simple à mettre en place, a priori très sûr.
Inconvénients : suppose que le périphérique soit à proximité de l’utilisateur, et surtout que ce dernier prendra la peine de réellement vérifier l’empreinte (je dirais que tu as de la chance si 0.01% des utilisateurs le font) — à défaut tu auras du chiffrement opportuniste sans authentification.
Deuxième solution, plus coûteuse, plus facile pour les utilisateurs mais pas plus sécurisée (plutôt moins en fait) : la société qui produit le périphérique obtient, de la part d’une autorité de certification reconnue, un certificat habilité à signer d’autres certificats (certificat intermédiaire) — attention, il faut payer cher pour ça. Ensuite, on utilise ce certificat pour signer les certificats de chaque périphérique.
Avantage : plus aucune alerte effrayante pour l’utilisateur, puisque le certificat du périphérique a une chaîne de confiance remontant jusqu’à une autorité connue.
Inconvénients :
(beaucoup) plus cher ;
entraîne la création de fait d’une nouvelle sous-CA dans la nature, comme s’il n’y en avait pas déjà assez ;
problèmes à prévoir si les périphériques ont une durée de vie supérieure à la période de validité du certificat intermédiaire du fabricant ;
et surtout, il n’y a plus réellement d’authentification — le client n’a aucunement l’assurance qu’il se connecte bel et bien au bon périphérique, il pourrait être en train de se connecter à n’importe quel serveur ayant un certificat valide.
[^] # Re: authent vs crypt
Posté par gouttegd . En réponse au message Authentification sécurisée sur un serveur en IP dynamique. Évalué à 2. Dernière modification le 20 août 2015 à 12:47.
Petite réflexion rapide (et sûrement foireuse, mais merci pour l’exercice).
Première solution : un certificat auto-signé par périphérique, avec sur le périphérique lui-même une étiquette mentionnant l’empreinte du certificat. À charge pour l’utilisateur, lorsque son navigateur tente de lui faire peur en lui criant que la connexion n’est pas authentifiée et qu’il va mourir, de vérifier que l’empreinte affichée par la navigateur correspond à celle collée sur le périphérique.
Éventuellement faire en sorte que le serveur web serve un en-tête HPKP dans l’espoir que le navigateur se souvienne du certificat et n’affiche pas l’avertissement à chaque fois (aucune garantie que ça marche cela dit, la spécification HPKP est muette sur le cas des certificats auto-signés).
Avantage : assez simple à mettre en place, a priori très sûr.
Inconvénients : suppose que le périphérique soit à proximité de l’utilisateur, et surtout que ce dernier prendra la peine de réellement vérifier l’empreinte (je dirais que tu as de la chance si 0.01% des utilisateurs le font) — à défaut tu auras du chiffrement opportuniste sans authentification.
Deuxième solution, plus coûteuse, plus facile pour les utilisateurs mais pas plus sécurisée (plutôt moins en fait) : la société qui produit le périphérique obtient, de la part d’une autorité de certification reconnue, un certificat habilité à signer d’autres certificats (certificat intermédiaire) — attention, il faut payer cher pour ça. Ensuite, on utilise ce certificat pour signer les certificats de chaque périphérique.
Avantage : plus aucune alerte effrayante pour l’utilisateur, puisque le certificat du périphérique a une chaîne de confiance remontant jusqu’à une autorité connue.
Inconvénients :