Un correctif est en cours de déploiement pour résoudre les erreurs rencontrées sur certains Chromecast. Cependant, ceux qui ont tenté une réinitialisation pourraient rester bloqués plus longtemps.
Je confirme, ça ne marche toujours pas chez moi, j’ai reçu hier un mail d’excuse de Google me disant que les corrections sont en cours.
Pas de réinitialisation, juste redémarré. Wait and see (c’est chiant d’allumer son TV avec une télécommande :))
La date d’expiration des certificats est une plaie pour l’humanité. L’idée même de mettre une date d’expiration virtuelle est une idiotie sans nom. Ça n’apporte aucune sécurité, et ça ajoute une contrainte énorme sur la maintenance et l’obsolescence des produits.
Un produit livré 5 ans plus tôt, tu dois continuer à le maintenir à cause de ses fichus certificats, donc ça a un coût pour l’entreprise (de dette technique) et pour le client si tu ne le fais pas, car son produit => poubelle.
En gros, c’est comme mettre une bombe dans un produit, lorsque le minuteur est atteint le produit devient une presse à papier, ça devrait être interdit, c’est un vol indirect.
3 « J'aime »
Oui c’est casse-bonbons, mais contrairement à ce que tu penses, c’est un élément essentiel à la sécurité comme à la sûreté. Je ne vais pas te faire un cours ici mais il y a assez de littérature disponible sur le sujet pour que tu approfondisses.
Par contre je suis d’accord avec toi, cela engendre de fait une obsolescence programmée. 
3 « J'aime »
Ça n’apporte aucune sécurité
Du coup ils devraient être illimités dans le temps ? Du coup quand ils sont crackés, quid ?
ça ajoute une contrainte énorme sur la maintenance
Il me semble que ça peut s’automatiser 
3 « J'aime »
+1.
Il ne faut pas interdire l’expiration des certificats, par contre il faudrait interdire les appareils qui n’offrent pas un mode secours permettant de mettre à jour les certificats même si le constructeur ne le fait plus.
Les certificats sont un format de fichier standard, donc ça pourrait par exemple se faire en offrant simplement la possibilité de configurer une source de téléchargement des certificats (avec ben sûr d’énormes warnings dans l’interface pour dire de faire très attention avec ça !), et en proposant un service indépendant des constructeurs pour faire ça (ça pourrait par exemple être un truc confié à l’ANSSI).
On pourrait même envisager des sécurités ne reposant pas sur les certificats pour pouvoir authentifier la source de téléchargement même quand les certificats de l’appareil sont déjà expirés. Par exemple, après le téléchargement des certificats, l’appareil pourrait afficher une série de mots dérivée du hash des certificats et que l’utilisateur pourrait aller vérifier depuis un autre appareil directement sur le site du fournisseur des certificats.
En théorie, un certificat qui a été cassé peut-être révoqué.
En pratique, ce n’est évidemment pas aussi simple, puisque pour révoquer, il faut déjà savoir que ça a été cassé, ce qui n’est pas forcément toujours le cas…
D’où la sécurité supplémentaire apportée par l’expiration, qui fait qu’un certificat volé finira par ne plus marcher.
Côté serveur, ça fait effectivement longtemps qu’il y a des outils pour automatiser les renouvellements de certificats avant leur expiration.
Le problème c’est du côté des clients, avec des constructeurs qui abandonnent leurs produits et ne proposent plus les mises à jour.
2 « J'aime »
C’est un enfer, je le confirme et j’en veux à Apple qui a empêché que les certificats durent jusqu’à trois ans comme dans le passé, maintenant c’est un an et certains voudraient raccourcir encore cela. Je viens d’installer le petit logiciel opensource Uptime Kuma qui m’envoie des alertes quand un serveur ne répond pas et m’indique la durée restante des certificats.
L’autre problème concerne les cyphers dépréciés sur les vieux navigateurs et vieux sites.
Il y a de grosses sociétés allemandes qui obligent leurs clients à utiliser un très vieux navigateur pour aller sur un portail valider des licences pour des appareils médicaux tous les trois mois. Ils sont vraiment nuls, car on peut sécuriser facilement un vieux site pourri qui serait même entièrement http grâce à un reverse-proxy en amont.
2 « J'aime »
C’est une histoire d’argent, si c’était à vie ça ne rapporterait qu’une seule fois.
3 « J'aime »
Et c’est pour ça que Let’s Encrypt, qui est gratuit, et qui est l’autorité de certification la plus utilisée pour le web (plus de 50% des sites en HTTPS utilisent Let’s Encrypt) doit être à peu près le seul à ne pas délivrer de certificats valides plus de 3 mois, parce qu’ils veulent que ça rapporte plusieurs fois 
5 « J'aime »
Méfiance quand même, combien de sociétés, comme LastPass par exemple, ont fait du gratuit pour appâter et finalement dire faut payer.
LastPass a toujours été développé par une société commerciale, avec une offre gratuite et une offre payante.
Let’s Encrypt appartient à une société à but non lucratif, qui n’a clairement pas l’intention de lancer des produits payants (ça a plus de dix ans, et y a depuis le départ aucune offre payante à côté de l’offre gratuite).
Si leur intention en réduisant la durée de validité était de vendre plus, ils seraient particulièrement mauvais dans l’exécution
2 « J'aime »
Bah. Le temps est vraiment relatif. Si ton appareil n’est pas connecté au réseau ou que tu as la main sur son horloge, tu peux tricher sur le temps puisque la date d’expiration est comparé avec l’horloge système. Donc ça n’apporte rien côté sécurité. La plupart des systèmes utilisent un serveur NTP pour récupérer le temps après leur boot, serveur qui n’est pas sécurisé et peut donc être MITM. Tu ne peux pas sécuriser le serveur NTP car ce n’est pas du TCP et donc pas de SSL/TLS.
Sachant qu’un certificat peut être craqué même s’il est en vie, ce n’est pas la date qui fournit la sécurité, c’est le fait de pouvoir révoquer un certificat, ce qui paradoxalement, est super mal supporté de nos jours.
Le seul cas où la date d’expiration est utile est dans le modèle où on considère que la puissance de calcul double tous les X ans et donc qu’une attaque brute force deviendrait possible dans Y années. Si le certificat expire avant Y, le système reste sécurisé.
Cependant, dans la pratique, nous n’avons jamais pu observer ce cas. En d’autres termes, les normes et protocoles évoluent plus vite que la puissance de calcul, et donc un certificat utilisant un RSA 512 bits émit en 1999 (et qui pourrait être cassé maintenant) est de toute façon obsolète aujourd’hui car un système de 1999 ne peut plus communiquer avec les protocoles actuels.
Tout à fait. Ce qui implique donc une maintenance, cf mon post au dessus.
Oui, ce serait clairement mieux. Tant qu’à faire, une loi plus simple et plus large: un arrêt du support d’un produit connecté implique la libération du code source du produit pour la maintenance tiers.
Par contre je ne te suis pas pour l’implémentation que tu proposes. Déjà, Mme Michu ne comprends pas ce que c’est qu’un certificat, on peut donc lui faire faire n’importe quoi sans qu’elle s’en apperçoive, c’est donc une faille de sécurité.
Ensuite, parce que ce que tu proposes, ce n’est ni plus ni moins qu’une backdoor de certificat. Si l’appareil est sécurisé avec un certificat émis/validé/signé par Google, et que tu peux remplacer par un certificat émis par EvilCorp, alors rien n’empêche plus EvilCorp de MITM la communication.
Oui, comme un hybride TLS/SSH en fait, lors de la première connection, le certificat permet de valider la source (type TLS), puis le fingerprint et les clés du serveur sont sauvegardées. Le certificat pourrait alors ne plus être valide, du moment que le fingerprint est bon, c’est OK.
Il y a plein de projet pour essayer de décentraliser le CoT sur le web, histoire de ne plus être dépendant d’un nombre limité de CA. Imagine demain, Let’s Encrypt tombe, et c’est la moitié d’internet qui est en panne. Mais ça a pas l’air de gêner les gens plus que ça.
En fait, le principe même du CA est vraiment nul et périmé, mais bon, visiblement, ça rapporte de l’argent facilement aux autorités de certification…
On pourrait avoir une blockchain décentralisée (P2P) qui stocke les fingerprints des serveurs et ne plus avoir besoin du merdier des certificats. Si la clé privé d’un serveur est corrompue, l’administrateur publie la nouvelle clé publique sur la blockchain et zou, problème résolu. Avec les certificats, il faut attendre que ton navigateur expire son cache (ce qui n’a rien à voir avec la date d’expiration du certificat), avant qu’il le redemande et qu’il se rende compte qu’il a été changé. Donc techniquement, ça peut durer des jours voire des semaines où tu peux avoir un MITM invisible qui écoute toutes tes conversations.
Au final, j’attends avec impatience que le merdier du CA trust disparaisse.
2 « J'aime »