La sécurité qui crée de l'obsolescence

[ljf]

Dans un autre sujet, il est proposé aux nouveaux chatons de renforcer leurs versions de TLS.

@stephane

Peut-être monter la version de yunohost devrait mettre tout le monde à «good».

J’interviens juste là dessus pour partager le fond du débat qui a animé YunoHost à une époque où nous avions de nombreuses PR proposant tels ou tels réglages de sécurité. Parce qu’« il parait » c’est mieux etc. PR qui par ailleurs sont chronophages du fait du débat qu’elles génèrent avant leurs intégrations (ou pas).

La conclusion c’est que YunoHost propose par défaut pour les serveurs web et smtp un réglage avec les recommandations « intermediate » de mozilla. Ceci dans le but d’éviter que les utilisateurs et utilisatrices finales ne soient contraintes de jeter leurs smartphones alors que le matériel fonctionne encore. A priori, les recommandations « intermediate » n’incluent pas de protocoles troués.

Une option permet de forcer en moderne, mais elle est peu connue et activable uniquement avec la CLI. Elle sera un jour proposée dans la webadmin avec un warning d’avertissement sur les conséquences de ce réglage.

Les PR fermées ou intégrées sont toujours listées sur github, donc il est possible de relire les débats en entier.

Je trouve que la question de fond est intéressante, dans quelle mesure le non support d’ancien protocole (toujours pas troués) implique la création d’une obsolescence qui pourrait être évitée. Je pense que globalement les tech en sécurité n’ont pas assez cette question en tête. Et évidement en tant que tech au sein de chatons nous sommes concerné⋅es.

A une autre échelle, Let’s Encrypt avait annoncé en octobre ne plus supporter par défaut android <7.1 à partir de janvier 2021, et heureusement ils et elles ont trouvés une solution (sinon vous imaginez le désastre).

[aselkim]

Je pense que tu positionnes le problème au mauvais endroit, en tout cas, si on se réfère aux exemples que tu as donné.

Le problème ne provient pas des plateformes qui essaient de garantir un niveau de sécurité le plus optimal possible au détriment de certains clients qui sont sur des OS plus maintenus. Le problème provient des entreprises qui fournissent des OS jetables, surtout dans le monde du smartphone où généralement les fabricants se contentent au mieux d’une seule montée en version de l’OS avant de laisser tomber le support.

D’ailleurs ce problème n’est pas spécifique la sécurité, il concerne aussi les frameworks natifs de développement sur ses plateformes qui ne s’encombrent pas du support des vieilles versions de l’OS.

La solution à mon avis serait que l’Europe impose aux industriels un support d’au moins X années des OS embarqués, un peu comme on a dans électroménager la disponibilité garantie des pièces détachées pendant 7 à 10 ans.

[stephane]

@ljf

Dans un autre sujet, il est proposé aux nouveaux chatons de renforcer leurs versions de TLS.

C’est pas toutafé mon propos. Mais merci pour ce nouveau fil et tes informations. Je ne connais pas du tout yunohost. Du coup, je suis moins bête.
Je constate que beaucoup de chatons ou de candidat chaton l’utilise. Je trouve cela vraiment chouette. Ça montre la qualité du projet et les ambitions que cela permet de réaliser.

@ljf

Une option permet de forcer en moderne, mais elle est peu connue et activable uniquement avec la CLI. Elle sera un jour proposée dans la webadmin avec un warning d’avertissement sur les conséquences de ce réglage.

Ceci dit, dans le tableau du fil précédent que je ne recopierait pas ici… il y a des nouveaux chatons utilisant ynh mais qui sont en «modern» d’autre utilisant également ynh mais qui sont en «intermediate».

@ljf

Je trouve que la question de fond est intéressante, dans quelle mesure le non support d’ancien protocole (toujours pas troués) implique la création d’une obsolescence qui pourrait être évitée.

Franchement, je suis pas certain que cette préoccupation, de fond, est animée le choix entre modern et intermediate chez les chatons cités précédemment. Mais je souhaite me tromper et si c’est le cas, ça me donnerait beaucoup d’enthousiasme.

@ljf

Je pense que globalement les tech en sécurité n’ont pas assez cette question en tête.

Tu connais la fable de la fontaine «Les animaux malades de la Peste»? Parce que là tu es en train de désigner le baudet.

[ljf]

@aselkim

La solution à mon avis serait que l’Europe impose aux industriels un support d’au moins X années des OS embarqués, un peu comme on a dans électroménager la disponibilité garantie des pièces détachées pendant 7 à 10 ans.

+1 (et d’ailleurs c’était notre conclusion aussi quand on avait reçu l’annonce de LE par mail)

@aselkim

Le problème ne provient pas des plateformes qui essaient de garantir un niveau de sécurité le plus optimal possible au détriment de certains clients qui sont sur des OS plus maintenus.

Ça se discute à mon avis. Même si je suis totalement d’accord pour le rôle des fabricants, il y a réellement une marge de manœuvre côté serveur aussi. Et donc une responsabilité. Par ailleurs, il est plus facile d’avoir un sentiment d’infrastructure sécurisée en évoquant la belle crypto qu’on a choisi (et qui est facilement testable), alors qu’en réalité c’est peut être l’arbre qui cache la forêt.

@stephane

Ceci dit, dans le tableau du fil précédent que je ne recopierait pas ici… il y a des nouveaux chatons utilisant ynh mais qui sont en «modern» d’autre utilisant également ynh mais qui sont en «intermediate».

Si ils sont en 4.x+, ils ont soit TLS1.2&TLS1.3 (intermediate) soit TLS1.3 only (modern). Si il y a du TLS < 1.2, soit l’OS est pas à jour, soit la config a été modifiée manuellement, soit il y a un reverse proxy devant.

@stephane

Franchement, je suis pas certain que cette préoccupation, de fond, est animée le choix entre modern et intermediate chez les chatons cités précédemment.

Je ne sais pas, probablement que la plupart des chatons n’ont pas conscience de cette dimension. D’où ce post pour en parler un peu et faire connaître la problématique.

[stephane]

@ljf

Si ils sont en 4.x+, ils ont soit TLS1.2&TLS1.3 (intermediate) soit TLS1.3 only (modern). Si il y a du TLS < 1.2, soit l’OS est pas à jour, soit la config a été modifiée manuellement, soit il y a un reverse proxy devant.

Bah merci pour lever toute forme de confusion. Du coup sur huit nouveaux chatons 5 sont à intermediate et 3 proposent 1.2, 1.1, 1.0.

[aselkim]

@ljf

Ça se discute à mon avis. Même si je suis totalement d’accord pour le rôle des fabricants, il y a réellement une marge de manœuvre côté serveur aussi. Et donc une responsabilité. Par ailleurs, il est plus facile d’avoir un sentiment d’infrastructure sécurisée en évoquant la belle crypto qu’on a choisi (et qui est facilement testable), alors qu’en réalité c’est peut être l’arbre qui cache la forêt.

Il ne fait pas de doute que le chiffrage TLS n’est qu’un élément parmi beaucoup d’autres lorsqu’on sécurise un système informatique.

Mais pour en revenir à l’allégation d’obsolescence programmée, je tiens tout de même à préciser que le protocole TLS 1.2 comporte un réel risque en terme de sécurité car il peut être vulnérable aux attaques de type POODLE et GOLDENDOODLE. En plus de cela, le TLS 1.2 pose des problèmes de performance et de confidentialité.

Le protocole TLS 1.3 a été repensé depuis zéro avec un nouveau design de sécurité répondant aux problèmes de sécurité, de performance et de confidentialité des protocoles précédents. Il y a donc une certaine légitimité a avoir un paramétrage renforcé (ce que vous appelez moderne).

[cquest]

Il y a de bonnes et mauvaises raisons de pousser à n’utiliser que les toutes dernières versions de TLS.

Bonnes: lorsqu’il y a un réel enjeu de sécurité, sur l’authentification ou ce genre de choses

Mauvaises: lorsque https pourrait sans problème être du http

Je gère les serveurs de fond de carte d’OpenStreetMap France, et fournir du https y est plus une histoire de confort que de sécurité. Rien de sensible n’est transmis… donc même du TLS 1.0 ou 1.1 (voire du SSL !) suffit pour accéder à des bouts de PNG.
Par contre, sur d’autres services, oui, ça se justifient et pas que pour avoir un beau A+ de SSLlabs.

[linuxmario]

Assez d’accord avec toi, mais il y a une raison pour laquelle laisser en HTTP peut poser problème : si on utilises des règles CSP. Par défaut, CSP se limite à soi-même uniquement, mais si on veut autoriser des ressources externes (images notamment), c’est mieux de passer par un site en HTTPS.

Après, je suis du genre à proposer du HTTPS partout, même sur un site ne demandant pas authentification, donc bon, c’est un avis personnel.

[cquest]

Oui, moi aussi je propose du https partout (sauf oubli), uniquement du https quand il y a un enjeu de sécurité, et que des versions TLS « modernes » quand c’est vraiment sensible.