ZeroShell    Forum
   Feed Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Facebook      Twitter

Valid HTML 4.01 Transitional


      ¿Qué es esto?
      Imágenes
      Licencia
      Anuncios
      Lista de correo
      Forum
      Documentación
      FAQ
      Hardware
      Download
      Actualización on-line
      Kerberos Tutorial  
      Aviso legal
      Contacto


  Más detalladamente:
      Gráficos
      Net Balancer
      Router UMTS
      Antivirus proxy
      Punto de acceso WiFi
      OpenVPN cliente
      Servidor OpenVPN
      QoS
      OpenDNS
      Kerberos 5
      NIS y LDAP
      Certificados X.509
      RADIUS
      Portal Cautivo
      VPN
      Firewall





Certificados X.509 y la autoridad de certificación

La creciente demanda para las conexiones encriptadas que garantiza la confidencialidad (nadie más que el receptor legítimo puede aprender los contenidos) de los datos transmitidos sobre la red, la veracidad (firma electrónica) e integridad (no es posible modificar el contenido yendo entre los dos puntos finales de las comunicaciones) ha dado lugar a la propagación de los algoritmos de cifrado asimétricos, más conocido como "algoritmos de clave pública". A diferencia de cifrado de clave simétrica, un par de claves duales se utilizan en el cifrado de clave pública: lo que se cifra con una sólo se puede descifrar con la otra y viceversa. Una de las dos llaves se llama la clave privada y la otra la clave pública. Como el nombre sugiere la clave privada es secreta y por lo tanto deben ser cuidadosamente vigilado por su propietario, en lugar de la clave pública se distribuye a los contactos.

Si un usuario A quiere enviar información secreta a un usuario B, entonces A debe cifrar los datos con la clave pública de B desde B es el único poseedor de la clave privada correspondiente para el descifrado. Esto resuelve el problema de la confidencialidad.

Ahora supongamos que el usuario A quiere asegurarse de que los datos recibidos son inequívocamente de B y que no se han alterado en el camino: B debe calcular el hash de los datos que se envíen y cifrar con la privada clave. Cuando A recibe los datos y el hash cifrado, descifra esta última con la clave pública de B y compararlo con el hash que se calcula sobre los datos recibidos. Si los dos valores hash son iguales entonces A puede estar seguro de la identidad de la B y la integridad de los datos. En particular, si los datos enviados por B a A es un documento electrónico, a continuación, el procedimiento anterior se conoce como "firma digital".

Cifrado asimétrico es tan fuerte como la mayor certeza es que la clave pública pertenece realmente a possessed el contacto de los mensajes son enviados, o cuyo origen debe ser autenticada. Lo mejor que puedes hacer es intercambiar personalmente las claves públicas, pero en una organización grande no siempre es posible. Esto resulta en la necesidad de dotar a estas organizaciones con una PKI (Public Key Infrastructure). PKI se basa en el uso de certificados, es decir, los documentos digitales firmados que contienen los datos de identificación del usuario (o servidor), su clave pública y la identificación de la autoridad de certificación que firma el certificado. Naturalmente, la Autoridad de Certificación (abreviado como CA), que firma el certificado debe ser de confianza y su clave pública distribuidos de una manera segura.

Zeroshell implementa una CA para la emisión y gestión de certificados digitales X.509 v3. En particular, hace que sea posible:

  • Generar parejas de claves RSA de 512, 1024 y 2048 bits;
  • Generar certificados X509.V3 relacionados con los usuarios y servidores;
  • Renovar un certificado;
  • Exportar un certificado (con o sin la clave privada relacionada) en el PEM, DER y en formato PKCS#12;
  • Revocar un certificado antes de su vencimiento;
  • Gestión de la CRL (lista de certificados revocados), es decir, la lista de certificados revocados firmada por la autoridad competente;
  • Generar la clave privada y el certificado de la entidad emisora ​​de certificados, si se trata de una CA raíz o importar si se trata de una CA intermedia;

Con el uso de certificados X.509 v3 y el protocolo SSL (Secure Socket Layer), inicialmente desarrollado por Netscape, pero en la versión 3.0 que fue estandarizado por el IETF y pidió TLS 1.0 (Transport Layer Security), es posible crear túneles de extremo a extremo basado en el nivel de transporte TCP y obtener un nivel de sesión seguro. Ejemplos de protocolos de sesión encapsulado en los túneles SSL incluyen: https (http seguro), imaps (IMAP seguro ), telnet (telnet seguro), SMTPS (SMTP seguro), ldaps (LDAP seguro), pop3s (seguro pop3) y nntps (seguro USENET protocolo de transporte). El protocolo TLS no se limita a cifrar los datos que pasan en los túneles, pero cuando se le solicite, sino que también garantiza la autenticidad del cliente y el servidor (autenticación mutua). A continuación, se puede observar que los algoritmos asimétricos tienen una complejidad computacional mucho mayor en comparación con las simétricas. Por esta razón en el protocolo SSL, gracias a un primer intercambio de datos cifrados asimétrico, clientes y servidores están de acuerdo en un algoritmo simétrico y la tecla correspondiente con la que cifrar el resto de la conversación.

Zeroshell utiliza SSL/TLS para los siguientes fines:

  • Para crear sesiones seguras con https entre el huésped y el anfitrión Zeroshell donde se ejecuta utiliza el navegador web para acceder a la interfaz de administración;
  • En el protocolo 802.1x mediante RADIUS para autenticar las conexiones inalámbricas con EAP-TLS y PEAP;
  • Para encapsular las tramas Ethernet en los túneles cifrados, creando así redes VPN de LAN a LAN;
  • Para autenticar la conexión IPsec en el que los túneles L2TP son encapsulado para crear L2TP/IPsec Host-to-LAN VPN Road Warrior;



    Copyright (C) 2005-2012 by Fulvio Ricciardi