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.
- Mars 2022 -
Ce RFC ajoute au protocole de sécurité DTLS 1.2 la possibilité
d'identificateurs de connexion (connection ID),
permettant de relier entre eux des paquets d'une même session DTLS,
même si l'adresse IP source change. C'est une solution simple et
minimale, DTLS 1.3 (RFC 9147) l'utilise (avec
quelques ajouts).
Dans le DTLS habituel, version de TLS qui tourne sur UDP et qui est normalisée dans le
RFC 6347, lorsqu'un paquet arrive à une
machine, celle-ci trouve l'association de sécurité appropriée (ce
qui permet de trouver le matériel crptographique qui permettra de
déchiffrer et de vérifier les signatures) en regardant le tuple
{protocole, adresse IP source, adresse IP destination, port source,
port destination}. Mais si la machine avec qui on correspond a
changé d'adresse IP, par
exemple parce qu'il s'agit d'un malinphone
qui est passé de WiFi à 4G ? Ou
bien si elle a changé de port car un routeur
NAT a
trouvé intelligent de considérer la session terminée, effaçant une entrée
dans sa table de correspondance ? Dans ce cas, le paquet entrant va
être considéré comme une nouvelle session, il faudra reprendre la
négociation TLS, et c'est du temps perdu (la poignée de main
cryptographique est coûteuse, et on souhaite amortir ce coût sur la
plus longue durée possible).
Le RFC note que le problème est particulièrement sérieux pour les
déploiements type Internet des Objets, où les
objets peuvent se mettre souvent en sommeil pour économiser leur
batterie, amenant le routeur NAT à oublier la session en cours.
Notez aussi qu'outre l'identificateur de connexion, notre RFC
apporte quelques changements supplémentaires, notamment pour
permettre le remplissage.
La section 3 du RFC spécifie l'extension DTLS
connection_id
(numéro 54 dans le
registre IANA) qui permet de spécifier des identifiants des
connexions DTLS, et donc ainsi de construire une connexion qui
résistera aux changements d'adresses IP et de ports. Dans son
ClientHello
, le client DTLS indiquera
l'identifiant qu'il utilisera (idem pour le serveur DTLS dans son
ServerHello
). Par contre, on ne peut pas
changer d'identifiant de connexion en cours de connexion
(contrairement à ce que permettent, par exemple, QUIC ou, tout simplement, DTLS 1.3). Une fois
l'utilisation de connection IDs négociée, les
données sont envoyées dans une nouvelle structure, de type
tls12_cid
(numéro 25 dans le
registre IANA). (Pour DTLS 1.3, il faudra regarder le RFC qui
lui sera consacré.) On peut
ajouter des zéros avant le chiffrement, à des
fins de remplissage. Voici la structure de
données avant le chiffrement :
struct {
opaque content[length];
ContentType real_type;
uint8 zeros[length_of_padding];
} DTLSInnerPlaintext;
Et une fois chiffrée, on envoie ça sur le réseau :
struct {
ContentType outer_type = tls12_cid;
ProtocolVersion version;
uint16 epoch;
uint48 sequence_number;
opaque cid[cid_length]; // L'identifiant de
// connexion est là.
uint16 length;
opaque enc_content[DTLSCiphertext.length];
} DTLSCiphertext;
Que se passe-t-il quand on reçoit un message pour un identifiant
de connexion connu mais une nouvelle adresse IP ? Il ne faut pas lui
faire une confiance aveugle (des méchants ont pu usurper l'adresse
IP) et envoyer immédiatement des réponses à
la nouvelle adresse IP. Il faut d'abord vérifier que le message est
correctement signé, qu'il a une epoch
plus
récente que le précédent message (dans certains cas, comme l'ordre
des messages n'est pas garanti, cela peut mener à ignorer un message
valide), et l'application doit tester que le pair est toujours
d'accord (la méthode dépend de l'application).
Les identifiants de connexion posent évidemment des questions de
vie privée (section 8 du RFC). Ils doivent être en clair
(puisqu'ils servent au récepteur à découvrir le matériel
cryptographique de la connexion, qui servira au déchiffrement) et
sont donc observables par quiconque est situé sur le trajet, ce qui
améliore la traçabilité (ce qui est mauvais pour la vie privée). Et,
contrairement à QUIC, on n'a qu'un
identifiant, on ne peut pas en changer (c'est mieux en DTLS
1.3).