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.
Blog de Stéphane Bortzmeyer
- Octobre 2015 -
L'état actuel de la sécurisation de SMTP par TLS n'est pas très satisfaisant : la grande majorité des certificats est auto-signée (pour éviter les prix et les délais des Autorités de certification) et, souvent, expirée. Conséquence logique, les serveurs SMTP ne vérifient pas les certificats : s'ils le faisaient, ils ne pourraient plus envoyer de courrier, ou bien ils se rabattraient sur du SMTP en (...)
- Octobre 2015 -
On a beaucoup parlé des attaques DoS par réflexion + amplification en les présentant souvent comme spécifiques à UDP. Mais un article récent (mais passé curieusement inaperçu) montre qu'on peut en faire également avec TCP.Petit rappel du principe de cette attaque : il y a trois parties, l'attaquant A, la victime V et le réflecteur R. Ce dernier est innocent (il n'a rien contre la victime) mais souvent (...)
- Octobre 2015 -
Dans les techniques d'authentification normalisées pour un client HTTP, la plus connue et la plus simple est le mécanisme Basic du RFC 7617. Mais elle a plusieurs failles de sécurité, comme le transmission explicite du mot de passe (et qui se fait en clair si on n'utilise pas HTTPS). D'où cette technique alternative, que je crois peu répandue, car plus complexe (et pas forcément plus sûre) : le (...)
- Octobre 2015 -
Un très court RFC, probablement un des derniers du groupe de travail IETF qui a fait la réécriture de la norme HTTP 1.1. Il normalise l'en-tête HTTP Authentication-Info:, qui était précédemment dans le RFC 2617.Cet en-tête, et son équivalent pour les relais, Proxy-Authentication-Info:, sert au serveur HTTP à communiquer des informations après une authentification réussie.Dans la nouvelle rédaction de (...)
- Octobre 2015 -
Ce court RFC (re-)définit le mécanisme d'authentification « de base » (basic authentication scheme) de HTTP : un mécanisme trivial, où un nom d'utilisateur et un mot de passe sont transmis en Base64 au serveur HTTP. Ce RFC (et ses copains) annule et remplace l'ancien RFC 2617.Depuis la réécriture générale des RFC sur HTTP, le cadre de l'authentification est décrit dans le RFC 7235. Chaque mécanisme (...)
- Juillet 2015 -
Le protocole de sécurité TLS permet différents types d'autorisation et ce RFC en ajoute un nouveau, par la présentation d'un certificat DTCP. DTCP est un mécanisme de menottes numériques, et cette extension à TLS permet désormais « TLS pour les ayant-droits ».DTCP, également connu sous le nom de 5C, est un système fermé. À l'heure actuelle, une version apparemment à jour de la spécification est (...)
- Juillet 2015 -
La plaie de DNSSEC, comme celle de tous les systèmes de cryptographie, est la gestion des clés. Avec DNSSEC, la clé de signature des autres clés, la KSK (Key Signing Key) est censée être remplacée (rolled over) régulièrement. Si un résolveur a une KSK dans sa configuration, cela oblige l'administrateur du résolveur à effectuer le remplacement à la main, ce qui peut être contraignant. Notre RFC 5011 (...)
- Juillet 2015 -
Ce RFC enregistre officiellement deux nouveaux codes de retour SMTP (qui étaient déjà largement utilisés), 521 (« I do not accept mail ») et 556 (« The remote domain does not accept mail »). Tous les deux sont prévus pour le cas où un serveur ou un domaine n'acceptent jamais de courrier, en aucune circonstance (par opposition aux codes de rejet plus généraux comme 554).Petit rappel au passage : les (...)
- Juillet 2015 -
Comment indiquer qu'un domaine ne reçoit jamais de courrier ? Jusqu'à présent, il n'existait pas de mécanisme standard, permettant d'indiquer aux clients de ne pas perdre de temps à essayer d'écrire. Ce nouveau RFC indique une méthode, le « MX nul » qui consiste à mettre un point en partie droite de l'enregistrement MX.Normalement, un logiciel de messagerie qui veut envoyer du courrier à (...)
- Juin 2015 -
Le problème de passage à l'échelle de protocoles de recherche d'adresse MAC des voisins, les protocoles comme ARP, sont connus depuis un certain temps, et documentés dans le RFC 6820. Résumé en deux mots, dans un grand centre de données non partitionné en sous-réseaux IP, le trafic ARP peut représenter une partie significative du travail à effectuer par les machines. Ce nouveau RFC expose une des (...)
