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 ACME,
surtout connu via son utilisation par l'AC
Let's Encrypt, permet de prouver la
« possession » d'un nom de
domaine, pour avoir un certificat
comprenant ce nom. Ce court RFC spécifie une extension à ACME qui permet
de prouver la « possession » d'une adresse IP, ce qui permettra d'obtenir via ACME des
certificats utilisant une adresse.
Le protocole ACME
est normalisé dans le RFC 8555. Son principe
est qu'on demande un certificat pour un identificateur (à l'heure
actuelle, forcément un nom de domaine) et que le serveur ACME va
alors vous défier de prouver que vous contrôlez bien ce nom, par
exemple en publiant une chaîne de caractères choisie par le serveur
dans un serveur HTTP accessible via ce nom de domaine. Or, les
identificateurs dans les certificats
PKIX ne sont pas forcément des noms de
domaine. Les adresses IP,
par exemple, sont prévues. Examinons les certificats du résolveur
DNS public Quad9 :
% openssl s_client -connect 9.9.9.9:853 -showcerts | openssl x509 -text
...
X509v3 Subject Alternative Name:
DNS:*.quad9.net, DNS:quad9.net, IP Address:9.9.9.9, IP Address:9.9.9.10, IP Address:9.9.9.11, IP Address:9.9.9.12, IP Address:9.9.9.13, IP Address:9.9.9.14, IP Address:9.9.9.15, IP Address:149.112.112.9, IP Address:149.112.112.10, IP Address:149.112.112.11, IP Address:149.112.112.12, IP Address:149.112.112.13, IP Address:149.112.112.14, IP Address:149.112.112.15, IP Address:149.112.112.112, IP Address:2620:FE:0:0:0:0:0:9, IP Address:2620:FE:0:0:0:0:0:10, IP Address:2620:FE:0:0:0:0:0:11, IP Address:2620:FE:0:0:0:0:0:12, IP Address:2620:FE:0:0:0:0:0:13, IP Address:2620:FE:0:0:0:0:0:14, IP Address:2620:FE:0:0:0:0:0:15, IP Address:2620:FE:0:0:0:0:0:FE, IP Address:2620:FE:0:0:0:0:FE:9, IP Address:2620:FE:0:0:0:0:FE:10, IP Address:2620:FE:0:0:0:0:FE:11, IP Address:2620:FE:0:0:0:0:FE:12, IP Address:2620:FE:0:0:0:0:FE:13, IP Address:2620:FE:0:0:0:0:FE:14, IP Address:2620:FE:0:0:0:0:FE:15
...
On voit qu'outre des noms comme
quad9.net
, ce
certificat inclut aussi des adresses IP comme
9.9.9.9
et
2620:fe::9
. Mais un tel certificat ne pouvait
pas s'obtenir automatiquement via ACME.
Notre RFC
résout ce problème en ajoutant un nouveau type d'identificateur
ACME, ip
(section 3 du RFC). Les types
d'identificateurs ACME sont décrits dans la section 9.7.7 du RFC 8555. Le nouveau type ip
a
été placé dans le
registre IANA des types d'identificateur. La valeur doit être
une adresse IP sous forme texte (normalisée très sommairement dans
la section 2.1 du RFC 1123 pour
IPv4, et dans la section 4 du RFC 5952 pour IPv6.)
Comme il s'agit d'authentifier des adresses IP, le défi ACME de
type dns-01
n'est pas pertinent et ne doit pas
être utilisé (section 7). Par contre, on peut (section 4 du RFC)
utiliser les défis http-01
(RFC 8555, section 8.3) et le récent
tls-alpn-01
(RFC 8737.)
Pour le défi HTTP, le serveur ACME va se connecter en
HTTP à l'adresse IP indiquée, en mettant
cette adresse dans le champ Host:
. Pour le défi
TLS avec ALPN, le certificat doit contenir un
subjectAltName
de type
iPAddress
. Un piège : contrairement au champ
Host:
de HTTP, l'adresse IP nue ne peut pas
être utilisée dans le SNI (RFC 6066, « Currently, the only server names
supported are DNS hostnames »). Il faut donc utiliser un
nom dérivé de l'adresse, en in-addr.arpa
ou
ip6.arpa
. Par exemple, si on veut un certificat
pour 2001:db8::1
, il faudra mettre
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
dans le SNI.
Un défi utilisant la « résolution inverse » (via une requête DNS
dans in-addr.arpa
ou
ip6.arpa
) avait été envisagé mais n'a pas été
retenu (les domaines de la « résolution inverse » sont en général
mal maintenus et il est difficile d'obtenir des entrées dans ces
domaines.)
La section 9 de notre RFC étudie les conséquences de cette
extension pour la sécurité. Le principal point à noter est que ce
RFC ne spécifie qu'un mécanisme. L'AC a toute
liberté pour définir une politique, elle peut par exemple refuser
par principe les adresses IP dans les certificats, comme elle peut
les accepter avec des restrictions ou des contrôles
supplémentaires. Par exemple, il ne serait pas raisonnable d'allouer
de tels certificats pour des adresses IP appartenant à des plages
très dynamiques, pouvant changer d'utilisateur très souvent.
Côté mise en œuvre, pour le serveur Boulder (celui
utilisé par Let's Encrypt), la discussion
est
ici.
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 (...)