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.
Le protocole EPP d'avitaillement de ressources (par exemple
de noms de domaine) a
un mécanisme de sécurité très simple, à base de mots de passe indiqués lors de la
connexion. Ce mécanisme avait plein de limitations ennuyeuses, dans
le RFC original,
et ce nouveau RFC vise à les réduire.
L'authentification dans EPP est décrite
dans le RFC 5730, section 2.9.1.1 (voir
aussi sa section 7). Le client EPP envoie un mot de passe, qui doit
faire entre 6 et 16 caractères (cf. le type
pwType dans le schéma
XSD du RFC 5730, section 4.1). Le
client peut changer son mot de passe en indiquant un nouveau mot via le
protocole
EPP, sans avoir à passer par un autre service. En outre, la session EPP est typiquement portée sur TLS, ce qui assure la
confidentialité du mot de passe, et la
possibilité d'ajouter une authentification par le biais d'un
certificat client. Mais c'est tout. Le RFC 5730 ne permet pas de mot de passe plus long,
ne permet pas au client de savoir combien de tentatives erronées
ont eu lieu, ne permet pas d'indiquer l'expiration d'un mot de passe
(si ceux-ci ont une durée de vie limitée) et ne permet pas au
serveur EPP d'indiquer, s'il refuse un nouveau mot de passe,
pourquoi il le juge inacceptable.
Cette extension à EPP figure désormais dans le registre
des extensions, créé par le RFC 7451.
Notre RFC
ajoute donc plusieurs nouveaux éléments XML qui peuvent apparaitre en EPP
(section 3). D'abord, la notion d'évènement. Un évènement permet
d'indiquer, dans un élément
- l'expiration d'un mot de passe,
- l'expiration du certificat client,
- la faiblesse d'un algorithme
cryptographique,
- la version de TLS, par exemple pour rejeter une version
trop basse,
- les raisons du rejet d'un nouveau mot de passe (« le mot de
passe doit comporter au moins une majuscule, une minuscule, un
chiffre arabe, un
chiffre
romain, une rune et un
hiéroglyphe », et autres
règles absurdes mais fréquentes),
- des statistiques de sécurité, comme le nombre de connexions
refusées suite à un mot de passe incorrect.
En utilisant
loginSec comme abréviation pour
l'espace de noms de l'extension EPP de ce
RFC,
urn:ietf:params:xml:ns:epp:loginSec-1.0,
voici un exemple d'évènement, indiquant qu'il faudra bientôt changer
de mot de passe :
Le mot de passe va bientôt expirer.
On pourrait voir aussi cet évènement indiquant le nombre de
connexions ratées, ce qui peut alerter sur une tentative de
découverte du mot de passe par force brute :
Trop de connexions ratées.
Si on utilise des mots de passe qui suivent les nouvelles règles,
il faut l'indiquer en mettant dans l'ancien élément
[LOGIN-SECURITY]. Si elle est présente, c'est
qu'il faut aller chercher le mot de passe dans le nouvel élément
La section 4 du RFC donne les changements pour les différentes
commandes EPP. Seule OpaqueString).
Voici un exemple d'une commande
ClientX
[LOGIN-SECURITY]
...
EPP SDK 1.0.0
Vendor Java 11.0.6
x86_64 Mac OS X 10.15.2
this is a long password not accepted before
...
Et une réponse positive du serveur EPP à cette connexion, mais qui
avertit que le mot de passe va expirer le 1er juillet :
Command completed successfully
Password expiring in a week
...
Et, ici, lorsqu'un client a voulu changer son mot de passe expiré,
avec
, mais que le nouveau
mot de passe était trop simple (cf. les
recommandations
de l'ANSSI) :
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
Authentication error
Password has expired
Mot de passe vraiment trop trivial.
...
Le schéma complet figure dans la section 5
du RFC.
Un changement plus radical aurait été de passer à un cadre
d'authentification plus général comme SASL (RFC 4422) mais l'IETF a choisi une évolution plus en
douceur.
À l'heure actuelle, je ne connais que deux mises en œuvre de ce
RFC, dans le SDK
de Verisign, en https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks
