ZeroShell    Forum
   Feed Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Zeroshell on LinkedIn LinkedIn       Facebook      Twitter ZeroTruth una interfaccia per il Captive Portal

      Cosa è?
      Screenshots
      Licenza
      Annunci
      Mailing List
      Forum
      English Forum
      Documentazione
      FAQ
      Hardware
      Download
      Update On-line
      Kerberos Tutorial  
      Note Legali
      Contattami


  Più in dettaglio:
      Hotspot Router
      Accounting
      Shibboleth SP
      Grafici e Prestazioni
      Net Balancer
      Router UMTS
      Proxy con Antivirus
      Filtri Web
      WiFi Access Point
      OpenVPN Client
      OpenVPN Server
      QoS
      OpenDNS
      Kerberos 5
      NIS e LDAP
      Certificati X.509
      RADIUS
      VPN
      Firewall


Valid HTML 4.01 Transitional




Certificati X.509 e Certification Authority

La crescente richiesta di connessioni crittografate che garantiscano per i dati trasmessi in rete la confidenzialità (nessuno oltre il legittimo destinatario può conoscerne il contenuto), la veridicità (firma elettronica) e l'integrità (non è possibile alterarne il contenuto ponendosi nel mezzo dei due end-point della comunicazione) ha portato alla diffusione di algoritmi crittografici asimmetrici meglio noti come "algoritmi a chiave pubblica". Contrariamente alla crittografia a chiave simmetrica, in quella a chiave pubblica viene utilizzata una coppia di chiavi duali: ciò che è criptato con una può essere decriptato solo e soltanto con l'altra e viceversa. Una delle due chiavi prende il nome di chiave privata e l'altra di chiave pubblica. Così come i nomi stessi suggeriscono, la chiave privata è segreta e pertanto va custodita gelosamente dal proprietario, quella pubblica invece va distribuita agli interlocutori.

Se un utente A vuole mandare dei dati segreti a un utente B, allora A dovrà criptare i dati con la chiave pubblica di B che essendo l'unico possessore della chiave privata corrispondente potrà decriptarli. È così risolto il problema della confidenzialità.

Supponiamo ora che l'utente A voglia essere sicuro che i dati ricevuti siano inequivocabilmente provenienti da B e che non siano stati manomessi durante il tragitto: B deve calcolare un hash dei dati da spedire e criptarlo con la sua chiave privata. Quando A riceve i dati e l'hash criptato, decripta quest'ultimo con la chiave pubblica di B e lo confronta con l'hash che calcola lui stesso sui dati giunti. Se i due hash sono uguali allora A può essere sicuro dell'identità di B e dell'integrità dei dati. In particolare, se i dati spediti da B ad A sono un documento elettronico il suddetto procedimento prende il nome di "firma digitale".

La crittografia asimmetrica è tanto più forte quanto maggiore è la certezza che la chiave pubblica che si possiede appartenga realmente all'interlocutore a cui i messaggi sono destinati o di cui si vuole accertare la provenienza. La cosa migliore da fare sarebbe scambiarsi personalmente le chiavi pubbliche, ma in una grande organizzazione non sempre ciò è possibile. Nasce pertanto l'esigenza di dotare tali strutture di una PKI (Public Key Infrastructure). Le PKI si basano sull'uso dei certificati, cioè di attestati firmati digitalmente che contengono i dati di identificazione dell'utente (o del server), la sua chiave pubblica e l'identificazione dell'autorità di certificazione che firma il certificato. Naturalmente la Certification Authority (più in breve CA) che firma i certificati deve essere fidata e la sua chiave pubblica distribuita in maniera sicura.

Zeroshell implementa una CA per l'emissione e la gestione di certificati digitali X.509 v3. In particolare permette di:

  • generare coppie di chiavi RSA da 512, 1024 e 2048 bit;
  • generare certificati X509.v3 relativi a utenti e server;
  • rinnovare un certificato;
  • esportare un certificato (con o senza la relativa chiave privata) nei formati PEM, DER, e PKCS#12;
  • revocare un certificato prima della scadenza;
  • gestire la CRL (Certificate Revocation List) ovvero l'elenco dei certificati revocati firmato dalla CA;
  • generare la chiave privata e il certificato della Certification Authority se si tratta di una Root CA o importarli se si tratta di una CA intermedia;

Con l'uso dei certificati X509 v3 e del protocollo SSL (Secure Socket Layer), sviluppato inizialmente da Netscape ma che nella versione 3.0 è stato standardizzato dalla IETF e ha preso il nome di TLS 1.0 (Transport Layer Security), è possibile creare dei tunnel end-to-end poggiati sul livello di trasporto TCP ed ottenere un livello di sessione sicuro. Esempi di protocolli di sessione incapsulati in tunnel SSL sono: https (secure http), imaps (secure IMAP), telnets (secure telnet), smtps (secure SMTP), ldaps (secure LDAP), pop3s (secure pop3) e nntps (secure USENET transport protocol). Il protocollo TLS non si limita a criptare i dati che passano nel tunnel, ma, quando richiesto, garantisce anche l'autenticità del client e del server (mutua autenticazione). Si noti poi, che gli algoritmi asimmetrici hanno una complessità computazionale molto maggiore di quelli simmetrici. Per questo motivo nel protocollo SSL, grazie a un primo scambio di dati crittografati asimmetricamente, client e server si accordano su un algoritmo simmetrico e sulla relativa chiave di sessione con cui criptare simmetricamente il resto della conversazione.

Zeroshell utilizza SSL/TLS per i seguenti scopi:

  • creare con https delle sessioni sicure tra l'host Zeroshell e l'host su cui gira il web browser da cui si accede all'interfaccia amministrativa;
  • nel protocollo 802.1x tramite RADIUS per l'autenticazione di connessioni Wireless con EAP-TLS e PEAP;
  • per incapsulare trame Ethernet in tunnel crittografati creando così delle VPN lan-to-lan;
  • per autenticare connessioni IPsec in cui incapsulare tunnel L2TP creando VPN L2TP/IPsec di tipo Road Warrior.



    Copyright (C) 2005-2016 by Fulvio Ricciardi