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

Tech Securité
#1

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

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).

Résultat des candidatures pour la 11ème portée
#2

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.

1 Like
#3

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.

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».

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.

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.

#4

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

Ç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.

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.

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.

#5

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.

#6

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).

#7

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.

#8

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.

#9

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.

#10

Ce sujet Sécurité VS Obsolescence est très intéressant.

Je ne sais pas répondre à la question : «que faut-il proposer comme version de TLS|SSL pour ne pas exclure de fait des utilisateurs|trices ayant un appareil trop récent, et|ou trop anciens ou pas à jour». Mais je sais observer deux approches radicalement différentes de ce sujet. (Je sais le faire parce que j’emploie un logiciel libre que j’ai déjà cité : testssl.sh .) Ci-après, ces deux approches.

Netflix
Ce site propose du contenu servi par un CDN. toutes les versions SSL, toutes les versions TLS, tous les ciphers imaginables sont proposés. Et bien évidemment DNSSEC, ipv6. C’est du numérique inclusif à 100%. Pour ce qui est du modèle de menace, je fais l’hypothèse qu’il est parfaitement analysé et documenté en mode de défaillance et de criticité.

Ce site propose un contenu 100% statique qui n’a aucun intéret à être chiffré. Également servi par un CDN. TLS 1.2 only, pas de DNSSEC, pas d’ipv6. Concrètement, un iphone 6 ne peut pas afficher ce contenu.

Du coup, ma conclusion est que ce n’est pas la sécurité qui crée de l’obsolescence. Et encore moins les tech de la sécurité. Mais plus sûrement des idées reçues.

1 Like
#11

Intéressant d’avoir les deux approches ! Je m’intéresse pas toujours à ce que les autres sites font donc c’est enrichissant.

De mon côté, vu que les navigateurs poussent le HTTPS à fond, je fais comme ceci : TLS 1.2 et 1.3 pour les sites, TLS 1.0 1.1 1.2 pour le mail (sinon Thunderbird fait des siennes).

Pour le DNSSEC, c’est pas évident encore car on doit souvent configurer le truc manuellement et j’ai pas pris le temps de le faire correctement.

Après pour l’iphone 6, je crois que tu peux mettre à jour vers une des dernières versions d’iOS qui supporte du TLS 1.2 (pas sûr, à vérifier), mais je trouve que c’est moins problématique que d’utiliser un téléphone Android où il y a beaucoup d’écarts entre les versions (tout dépend du téléphone).

Pour les PC, tu as une solution éventuelle pour contrer l’obsolescence : utiliser un GNU/Linux léger ou même OpenBSD. J’ai utilisé ce dernier sur du Pentium 4 et ça affichait les pages de mon site. Un peu lentement, mais ça reste acceptable

#12

De mémoire, il me semblait que tu recommandais de désactiver la vérif du certificat par thunderbird. J’espère que tu as résolu cela? :upside_down_face:

C’est en réflexion à hadoly. Pour les mêmes raisons que toi. Du coup, pourquoi ne pas travailler ce sujet entre chaton lyonnais?

En fait, j’ai cité l’iphone 6 parce que curieusement cet appareil s’est trouvé en tête des résultats d’une petite enquête terrain autour des pratiques de jeunes et de l’utilisation du formulaire en ligne proposant l’attestation de déplacement. La plupart des jeunes ont indiqué avoir dû télécharger l’application de contact tracing tousanticovid parce qu’elle permet l’édition d’une attestation et parce que le site ne fonctionnait pas sur leur appareil. La plupart de ces jeunes utilisait un iphone6.

1 Like
#13

J’ai pas retesté récemment, mais je crois que c’est toujours comme ça. Je vais revérifier le truc et corriger ça dans la foulée :slight_smile:
Je ne savais pour l’iPhone 6, mais c’est bon à noter ici, comme ça c’est dans le dur :slight_smile: