Suport technique et veille technologique
Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Avril 2022 -
Ce nouveau RFC
normalise des algorithmes pour le protocole de sécurité TLS, qui ne fournissent
pas de chiffrement
(seulement authentification et
intégrité). C'est évidemment une option très
contestée et l'IETF ne suggère pas d'utiliser ces algorithmes
mais, bon, certaines personnes y voient une utilité.
La section 1 du RFC décrit des scénarios d'usage (souvent tirés
du monde de l'IoT) où cela peut avoir un sens
de ne pas chiffrer. Le
premier exemple est celui d'un bras robotique
commandé via un protocole
TCP/IP. L'authentification
est importante mais la confidentialité ne
l'est peut-être pas, ce qui rendrait acceptable l'absence de
chiffrement. Autre exemple, des rapports
météo, ou bien l'envoi de signaux d'horloges,
qu'il faut évidemment authentifier mais qui ne sont pas secrets. Le
RFC cite aussi des exemples de communication avec des trains ou des
avions, où l'intégrité des données est cruciale, mais pas leur
confidentialité. Mais attention avant de jeter le chiffrement à la
poubelle, le RFC
dit bien qu'il faut faire une analyse soignée de la menace. Pour
reprendre l'exemple du bras robotique, l'écoute des messages
pourrait permettre la rétro-ingénierie, ce
qu'on ne souhaite pas forcément.
Mais pourquoi se passer de chiffrement, d'ailleurs, alors qu'il
est plus simple de l'utiliser systématiquement ? Parce que dans
certains cas, il coûte cher, notamment en latence. En outre, certains équipements,
notamment du genre objets connectés, ont des
capacités de calcul très limitées. Bref, si le chiffrement
systématique et par défaut reste la politique de l'IETF, ce RFC
présente quelques façons de s'en passer, si on sait ce
qu'on fait (si vous ne savez pas, continuez à
chiffrer !).
Les algorithmes sans chiffrement sont présentés dans la section
4. Ils se nomment TLS_SHA256_SHA256
et
TLS_SHA384_SHA384
, et sont évidemment dans
le
registre IANA. Ils utilisent une fonction de
condensation comme SHA-256 pour
faire du HMAC, protégeant ainsi l'intégrité des
communications.
Rappelez-vous bien : aucun chiffrement n'est fourni. Les
certificats client, par exemple, qui sont
normalement chiffrés depuis TLS 1.3, seront envoyés en clair.
Publier un tel RFC n'a pas été facile, la crainte de beaucoup
étant que des gens qui ne comprennent pas bien les conséquences
utilise ces algorithmes sans mesurer les risques. Le RFC demande
(section 9) donc qu'ils ne soient pas utilisés par défaut et qu'ils
requièrent une configuration explicite. Et rappelez-vous que ce RFC
n'est que « pour information » et ne fait pas l'objet d'un consensus
à l'IETF.
RFC 9562: Universally Unique IDentifiers (UUIDs)
- 12 mai -
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec (...)
RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- 9 mai -
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il (...)
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
- 29 avril -
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher (...)
RFC 9567: DNS Error Reporting
- 27 avril -
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et (...)
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 8 avril -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)