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.
- Février 2020 -
Voici un très court RFC, pour résoudre un petit problème
d'interaction entre TLS 1.3 et HTTP/2.
Les anciennes versions du protocole de sécurité TLS avaient un mécanisme
de renégociation des paramètres de la session, permettant de changer
certains paramètres même après que la session ait démarré. C'était
parfois utilisé pour l'authentification du
client TLS, par exempe lorsqu'un serveur HTTP décide de demander ou pas un
certificat client en fonction de la requête
dudit client. Or, dans la version 2 de HTTP, HTTP/2, normalisée dans
le RFC 7540, il peut y avoir plusieurs
requêtes HTTP en parallèle. On ne peut donc plus corréler une
requête HTTP avec une demande de certificat. Le RFC 7540 (section 9.2.1) interdit donc d'utiliser la
renégociation.
Mais la nouvelle version de TLS, la 1.3, spécifiée dans le RFC 8446, a supprimé complètement le mécanisme de
renégociation. À la place, un mécanisme d'authentification
spécifique a été normalisé (section 4.6.2 du RFC 8446.) Or, ce mécanisme pose les mêmes problèmes que la
rénégociation avec le parallélisme que permet HTTP/2. Il fallait
donc l'exclure aussi, ce qui n'avait pas été remarqué tout de
suite. C'est ce que fait notre RFC. Pas d'authentification après la
poignée de main initiale, elle est incompatible avec HTTP/2 (ou avec
le futur HTTP/3, d'ailleurs, qui permet
également des requêtes en parallèle) et elle doit déclencher une
erreur.
À noter que la renégociation était également utilisée pour
dissimuler le vrai certificat serveur, par exemple pour contourner
certaines solutions de censure. Comme TLS 1.3 chiffre désormais le
certificat serveur, la renégociation n'est plus utile pour ce
scénario. En outre, la renégociation avait posé quelques problèmes
de sécurité (cf. une faille fameuse,
et le RFC 7457.)
Outre la renégociation, il y a d'autres messages qui peuvent
survenir après la poignée de main initiale. C'est le cas des
KeyUpdate
(RFC 8446,
sections 4.6.3 et 7.2) mais ils concernent la session TLS entière,
pas juste une requête HTTP, donc ils sont compatibles avec le
parallélisme de HTTP/2. Quant aux
NewSessionTicket
(RFC 8446, section 4.6.1), ils dépendent, eux, de la requête
HTTP, mais leur interaction avec HTTP/2 est prévue et documentée
dans le RFC 8470, et ils sont donc
acceptés.
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 (...)