The growing request for encrypted connections guaranteeing the confidentiality (no one besides the legitimate receiver can learn the contents) of data transmitted over the net, the veracity (electronic signature) and integrity (it is not possible to alter the contents by going between the two end-points of the communications) has led to the spread of asymmetric encrypted algorithms, better known as “public key algorithms”. Unlike symmetrical key encryption, a pair of dual keys are used in the public key encryption: what is encrypted with one can be decrypted only with the other and vice versa. One of the two keys is called the private key and the other the public key. As the names suggest the private key is secret and therefore must be carefully guarded by its owner, instead the public key is distributed to contacts.
If a user A wants to send secret data to a user B, then A must encrypt the data with B’s public key since B is the only possessor of the corresponding private key for decryption. This solves the problem of confidentiality.
Now let’s suppose that user A wants to make sure that the received data are unequivocally from B and that they have not been tampered with along the way: B must calculate a hash of the data to be sent and encrypt it with its private key. When A receives the data and the encrypted hash, it decrypts the latter with B’s public key and compare it with the hash that it itself calculates on the received data. If the two hashes are the same then A can be sure of the identity of B and the integrity of the data. In particular, if the data sent by B to A are an electronic document, then the above procedure is known as “digital signature”.
Asymmetric encryption is as stronger as the higher certainty is that the public key possessed actually belongs to the contact the messages are sent to, or the origin of which needs to be authenticated. The best thing to do is to personally exchange public keys, but in a large organization this is not always possible. This results in the need to equip such organizations with a PKI (Public Key Infrastructure). PKIs are based on the use of certificates, i.e. digital signed documents which contain the identification data of the user (or server), its public key and the identification of the certification authority which signs the certificate. Naturally, the Certification Authority (abbreviated as CA) which signs the certificates must be trusted and its public key distributed in a secure manner.
Zeroshell implements a CA for issuing and managing X509 v3 digital certificates. In particular it makes it possible to:
- generate couples of 512, 1024 and 2048 bit RSA keys;
- generate X509.v3 certificates related to users and servers;
- renew a certificate;
- export a certificate (with or without the related private key) in PEM, DER and PKCS#12 formats;
- revoke a certificate before its expiration;
- manage the CRL (Certificate Revocation List), i.e. the list of revoked certificates signed by the CA;
- generate the private key and the certificate of the Certificate Authority if it is a Root CA or import it if it is an intermediate CA;
With the use of X.509 v3 certificates and the SSL (Secure Socket Layer) protocol, initially developed by Netscape but in the 3.0 version it was standardized by IETF and called TLS 1.0 (Transport Layer Security), it is possible to create end-to-end tunnels based on the TCP transport level and obtain a secure session level. Examples of session protocols encapsulated in SSL tunnels include: https (secure http), imaps (secure IMAP), telnets (secure telnet), smtps (secure SMTP), ldaps (secure LDAP), pop3s (secure pop3) and nntps (secure USENET transport protocol). The TLS protocol is not limited to encrypting the data passing in the tunnels, but when requested, it also guarantees the authenticity of the client and server (mutual authentication). It may then be seen that the asymmetrical algorithms have a much greater computational complexity compared to symmetrical ones. For this reason in the SSL protocol, thanks to an initial exchange of asymmetrically encrypted data, clients and servers agree on a symmetrical algorithm and on the relevant key with which to encrypt the remainder of the conversation.
Zeroshell uses SSL/TLS for the following purposes:
- to create secure sessions with https between the Zeroshell host and the host where the web browser runs used to access the administration interface;
- in the 802.1x protocol via RADIUS to authenticate Wireless connections with EAP-TLS and PEAP;
- to encapsulate Ethernet frames in encrypted tunnels thus creating lan-to-lan VPNs;
- to authenticate IPsec connection in which L2TP tunnels are incapsulated to create L2TP/IPsec host-to-lan Road Warrior VPNs.