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 -
Un très court RFC, juste pour ajouter au protocole
SSH les algorithmes de
signature Ed25519 et
Ed448. Ces algorithmes sont déjà disponibles
dans OpenSSH.
Ce protocole SSH est
normalisé dans le RFC 4251, et a de nombreuses
mises en œuvre, par exemple dans le logiciel libre
OpenSSH. Pour authentifier le serveur, SSH
dispose de plusieurs algorithmes de
signature. Ce nouveau RFC en ajoute deux, dont
Ed25519, qui avait été normalisé dans le RFC 8032. (En toute rigueur, l'algorithme se nomme
EdDSA et Ed25519 est une des
courbes elliptiques possibles avec cet
algorithme. Mais je reprends la terminologie du RFC.) À noter que
les courbes
elliptiques sous-jacentes peuvent également être
utilisées pour l'échange de clés de
chiffrement, ce que décrit le RFC 8731.
La section 3 de notre RFC donne les détails techniques, suivant
le RFC 4253. L'algorithme se nomme
ssh-ed25519
. Son copain avec la courbe
elliptique Ed448 est ssh-ed448
. Ils sont tous
les deux enregistrés à l'IANA.
Le format de la clé publique est la chaîne "ssh-ed25519" suivie
de la clé, telle que décrite dans le RFC 8032,
section 5.1.5 (et 5.2.5 pour Ed448). Avec OpenSSH, vous pouvez la
voir dans ~/.ssh/id_ed25519.pub
. Les signatures
sont faites selon la technique du RFC 8032,
sections 5.1.6 et 5.2.6. Leur format est décrit en section 6, et la
vérification de ces signatures en section 7, en suivant la procédure
des sections 5.1.7 et 5.2.7 du RFC 8032.
La façon la plus courante de vérifier la clé publique du serveur
SSH auquel on se connecte est le TOFU. Si on
préfère une vérification plus sérieuse, on peut utiliser les clés
SSH publiées dans le DNS, méthode décrite dans le RFC 4255, utilisant des enregistrements de type SSHFP. Cela
fait longtemps que ces enregistrements peuvent utiliser Ed25519
(cf. RFC 7479) et notre RFC ajoute le cas de
Ed448, par exemple :
example.net. IN SSHFP 6 2 ( a87f1b687ac0e57d2a081a2f282672334d90ed316d2b818ca9580ea384d924 01 )
(Il est
enregistré
à l'IANA.)
Ed25519 a été ajouté à OpenSSH en janvier 2014
(donc bien avant la publication de ce RFC.) C'est l'option
-t
de ssh-keygen
qui
permet de sélectionner cet algorithme :
% ssh-keygen -t ed25519 -f /tmp/ed25519
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /tmp/ed25519.
Your public key has been saved in /tmp/ed25519.pub.
The key fingerprint is:
SHA256:VEN6HVM0CXq+TIflAHWCOQ88tfR35WXQZ675mLIhIIs stephane@godin
The key's randomart image is:
+--[ED25519 256]--+
| o==O+*++|
| oB* B.+*|
| o o== oo=|
| . . o.= .o|
| . S + oo |
| . o . o oo |
| E . . + + |
| ...o .|
| .o |
+----[SHA256]-----+
À noter que OpenSSH 7.6 n'a pas ed448. D'une manière générale,
ed25519 a été beaucoup plus souvent mise en œuvre dans les clients
et serveurs SSH.
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 (...)