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.
- Avril 2022 -
Le choix est vaste parmi les algorithmes de
cryptographie. Des protocoles comme
TLS offrent
de l'agilité cryptographique, c'est-à-dire la
possibilité d'avoir différents algorithmes pour un même
protocole. Pour l'administrateur système qui
n'est pas un ou une expert en cryptographie, lesquels choisir ? Pour
l'aider, les agences de sécurité nationales font souvent des
documents synthétisant leur analyse des bons algorithmes du
moment. C'est le cas du RGS en
France, par exemple. Ce RFC définit le profil TLS de
CNSA (Commercial National Security Algorithm),
les bons algorithmes recommandés par la NSA.
C'est d'ailleurs le deuxième RFC écrit par un employé de cette agence
étatsunienne, après le RFC 5903 mais il est
évidemment possible que certains auteurs aient été discrets sur leur
affiliation.
Ce profil CNSA (Commercial National Security
Algorithm) est destiné à être utilisé dans le cadre de
TLS, plus
exactement ses versions 1.2 (RFC 5246) et 1.3
(RFC 8446). Le cadre réglementaire étatsunien
est SP
80059. Un rappel : il s'agit d'un profil, une restriction des
algorithmes possibles, il ne définit pas de nouvel algorithme, il
liste juste ceux à utiliser, par exemple ceux des RFC 5288
et RFC 5289. C'est en effet une de missions de la
NSA que de
conseiller l'État et les entreprises en matière de
cryptographie. (La NSA a également une mission offensive, qui va en
sens inverse, les encourageant par exemple à garder secrètes des vulnérabilités,
pour qu'elle puisse les exploiter.) Cette suite CNSA n'a rien de
très novateur, elle est dans la continuation des précédentes, le
prochain grand changement, estime la NSA, sera le passage aux
algorithmes
post-quantiques. (Notez que l'analyse de la NSA sur les
mesures à prendre en attendant les calculateurs quantiques est très
discutée.)
Après ces préliminaires, la suite CNSA elle-même (section
4). Elle inclut les grands classiques, Diffie-Hellman avec les corps finis, les courbes elliptiques du
NIST et encore RSA, les signatures avec les courbes elliptiques
(ECDSA seulement) et RSA, et l'algorithme de
chiffrement symétrique AES en intègre
avec GCM (ChaCha - RFC 8439, sans doute pas assez officiel, n'est pas
cité). CNSA impose des tailles minimales de clés, par exemple 3 072
bits pour une signature avec RSA. Pour la condensation, c'est
SHA-384 seulement (j'ignore pourquoi
SHA-256 et les autres ne sont pas cités).
Pour la version de TLS, la section 5 de notre RFC impose au
minimum 1.2 (c'est un des points où le blog que vous êtes
en train de lire n'est pas conforme aux recommandations de la
NSA…). Si on utilise une courbe elliptique (cf. RFC 8422), cela doit être la P-384 du NIST. (Saviez-vous d'ailleurs qu'il existe
une courbe elliptique française, « FRP256 », publiée
au Journal officiel ?) Et au passage, les certificats doivent suivre le profil du RFC 8603.
Pour TLS 1.3 (RFC 8446), CNSA impose de
tirer profit de certaines nouveautés de cette version, comme
l'extension signature_algorithms
. Par contre,
il faut refuser early_data
(les raisons sont
dans la section 2.3 du RFC 8446).