ZeroShell    Forum
   Feed RSS Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Facebook      Twitter

Valid HTML 4.01 Transitional


      Qu'est ce que c'est?
      Screenshots
      Licence
      Annonces
      Liste de diffusion
      Forum
      Documentation  
      FAQ
      Hardware
      Download
      On-line Updates
      Kerberos Tutorial  
      Conditions d'utilisation
      Contactez-moi


  Dans plus de détails:
      Performances
      Net Balancer
      UMTS Routeur
      Proxy avec Antivirus
      Point d'accès WiFi
      OpenVPN Client
      OpenVPN Server
      QoS
      OpenDNS
      Kerberos 5
      NIS et LDAP
      Certificats X.509
      RADIUS
      Captive Portal
      VPN
      Firewall


Certificats X.509 et l'autorité de certification

La demande croissante pour les connexions cryptées garantissant la confidentialité (personne d'autre que le destinataire légitime peut connaître le contenu) des données transmises sur le net, la véracité (signature électronique) et de l'intégrité (il n'est pas possible de modifier le contenu en allant entre les deux extrémités de la communication) a conduit à la propagation de l'asymétrie des algorithmes cryptés, mieux connu comme "algorithmes à clé publique". Contrairement à la clé de chiffrement symétrique, une paire de bi-clés sont utilisés dans le chiffrement à clé publique: ce qui est chiffré avec une peut être déchiffré qu'avec l'autre et vice versa. Une des deux clés est appelé la clé privée et l'autre la clé publique. Comme le nom l'indique la clé privée est secrète et doit donc être soigneusement gardé par son propriétaire, au lieu de la clé publique est distribuée aux contacts.

Si un utilisateur A veut envoyer des données secrètes à un utilisateur B, alors A doit chiffrer les données avec la clé publique de B puisque B est le seul possesseur de la clé privée correspondante pour le décryptage. Cela résout le problème de la confidentialité.

Maintenant supposons que l'utilisateur A veut s'assurer que les données reçues sont sans équivoque de la B et qu'ils n'ont pas été altérés avec le long du chemin: B doit calculer un hachage des données à envoyer et le chiffrer avec ses privée clés. Lorsque A reçoit les données et le hachage chiffré, il déchiffre celui-ci avec la clé publique de B et de la comparer avec le hachage qu'elle se calcule sur les données reçues. Si les deux hachages sont les mêmes alors A peut être certain de l'identité de B et de l'intégrité des données. En particulier, si les données envoyées par B à A sont un document électronique, la procédure ci-dessus est connue sous le nom "signature numérique".

Chiffrement asymétrique est aussi forte que la plus grande certitude, c'est que la clé publique appartient réellement possédé au contact les messages sont envoyés ou dont l'origine doit être authentifié. La meilleure chose à faire est d'échanger des clés publiques personnellement, mais dans une grande organisation ce n'est pas toujours possible. Il en résulte la nécessité de doter ces organisations d'une PKI (Public Key Infrastructure). PKI sont basées sur l'utilisation des certificats, soit numérique des documents signés qui contiennent les données d'identification de l'utilisateur (ou serveur), sa clé publique et l'identification de l'autorité de certification qui signe le certificat. Naturellement, l'autorité de certification (CA en abrégé) qui signe les certificats doivent être dignes de confiance et sa clé publique distribuée de manière sécurisée.

Zeroshell met en œuvre une CA pour la délivrance et la gestion des certificats X509 v3 numérique. En particulier, il permet de:

  • générer des couples publique et privée de 512, 1024 et 2048 bit RSA;
  • générer des certificats X509.v3 liées aux utilisateurs et des serveurs;
  • renouveler un certificat;
  • exporter un certificat (avec ou sans la clé privée liée) dans PEM, DER et PKCS # 12 formats;
  • révoquer un certificat avant son expiration;
  • gérer la CRL (Certificate Revocation List), c'est à dire la liste des certificats révoqués signé par la CA;
  • générer la clé privée et le certificat de l'autorité de certification si elle est une autorité de certification racine ou l'importer si elle est un intermédiaire ;

Avec l'utilisation de certificats X.509 v3 et le protocole SSL (Secure Socket Layer), initialement développé par Netscape, mais dans la version 3.0, il a été standardisé par l'IETF et a appelé TLS 1.0 (Transport Layer Security), il est possible de créer des tunnels de bout en bout basée sur le niveau de transport TCP et d'obtenir un niveau de session sécurisée. Exemples de protocoles de session encapsulé dans des tunnels SSL comprennent: https (http sécurisé), imaps (IMAP sécurisé), smtps (SMTP sécurisé), ldaps (LDAP sécurisé), pop3s (POP3 sécurisé) et nntps (sécurisé USENET protocole de transport). Le protocole TLS ne se limite pas à chiffrer les données qui circulent dans les tunnels, mais à la demande, il garantit également l'authenticité du client et le serveur (authentification mutuelle). Il peut alors être vu que les algorithmes asymétriques ont une complexité beaucoup plus de calcul par rapport à ceux symétrique. Pour cette raison, dans le protocole SSL, grâce à un premier échange de données crypté asymétriquement, les clients et les serveurs d'accord sur un algorithme symétrique et sur la touche correspondante avec qui pour chiffrer le reste de la conversation.

Zeroshell utilise le protocole SSL/TLS pour les fins suivantes:

  • de créer des sessions sécurisées avec https entre l'hôte et Zeroshell l'hôte sur lequel le navigateur web fonctionne utilisés pour accéder à l'interface d'administration;
  • dans le protocole 802.1x via RADIUS pour authentifier les connexions sans fil avec EAP-TLS et PEAP;
  • pour encapsuler des trames Ethernet dans les tunnels cryptés créant ainsi VPN LAN-to-LAN;
  • pour authentifier connexion IPsec dans lequel tunnels L2TP sont encapsulé pour créer L2TP/IPsec host-to-LAN Road Warrior VPN;



    Copyright (C) 2005-2012 by Fulvio Ricciardi