Here’s how to use SSL/TLS, S/Mime, certificates and public key cryptography in order to make Web services and email communications safer

Despite several technologies related to SSL/TLS protocols being attacked in the last 3 years, a good sysadmin or IT manager in 2016 can’t tolerate its organization still uses systems that transmit information in clear.
The use of Transport Layer Security (and its predecessor SSL) -it should be clear- it not enough to guarantee confidentiality of transmitted data on the Internet, and a quick bibliographic research shows the vast method of attacks to such protocols (like in this case and this other). TLS represents a first, fundamental security level for transmitted data, both for the access of a Web service of your company and the access to email via Webmail or IMAP/POP3/Exchange.
TLS acts as a tunnel and doesn’t modify the ongoing communication between client and server: it only adds a layer, indeed, that ciphers data between the source and the destination by using some key concepts at the basis of public key cryptography. Who has a server role needs a certificate, released by a certification authority or, in the worst case, self-signed: only who has purchased the certificate owns the private key that allows to encrypt the communication.

Self-signed certificates don’t guarantee the authenticity of the connection, but still guarantee encryption. In practice, if you’re browsing on www.example.com and see a self-signed certificate, that means it’s still signed, but you don’t have any certainty that the site that is replying is actually www.example.com. It could be that someone acting between you and that site and pretending to be www.example.com to steal your credentials, for instance. As long as you are in controlled situations, like when visiting the Web interface of your local NAS or some Intranet service, then this kind of error could be acceptable because you probably don’t use a domain name but an IP address. In such cases you are reasonably sure that who replies is actually who says to be (as per the nature itself of the communication).

On the other hand, it’s unacceptable if it’s a Webmail service or other Web service that uses a self-signed certificate. It doesn’t give you any guarantee at all about who’s on the other part of the connection.

Certificates released by certificate authorities are of three types: they can certify only the domain (ie confirming that the remote site actually is www.example.com), or they can certify the person or organization that replies on the other side. For instance a certification authority could certify that the site is owned by John Doe, or that it’s owned by John Doe Inc.
The price for this certificate is higher as the certification authority didn’t simply verified the domain owners, but also ID cards and documentation related to the person or organization. Such certification is fundamental for banks and financial services Web sites, as it also guarantees upon the organization that purchased the certificate.

The value of a certificate is then determined by additional services that it could provide or by the number of supported mobile devices: for instance some free certificates have relevant problems with older cellphones because these devices aren’t updated and recognize only certain certification authorities.
Who provides an email service should keep these considerations in mind and behave accordingly. The first point is to avoid to provide services that don’t have an SSL option, like an email service with only unencrypted IMAP, POP3 or ActiveSync. The best idea is to close all unencrypted ports and use only the ones with TLS, but this can’t be done with all clients: unfortunately some still use older devices that don’t support more recent protocols.
Who provides any other kind of service shouldn’t offer services with self-signed certificates. Certificates should be at least with domain verification. Some certificate provider even offer free certificates of this kind, albeit with several limitations, therefore there are no valid excuses not to use them.

Those who look for a way to improve confidentiality of emails should think about using S/Mime at least for the contacts exchanging classified or strategic information. This technology, based on public and private keys, can be easily implemented on all modern clients (Outlook, Thunderbird and so forth), including some Android and iOS clients. With this technology not only the transmission is encapsulated in a secure channel, but also email messages can be completely ciphered from sender to receiver, and the signing can guarantee the origin and the fact that nobody modified the message during its transit.

If it’s the first time you’re dealing with certificates, you might experience some difficulties. Here’s a brief handy glossary.

• DER encoding: the extension is DER, CER or CRT and it’s one of the most used formats for the encoding of x.509 v3 certificates.
• PEM encoding: the extension is PEM and it’s used for x.509 v3 certificates stored in (Base64) ASCII with the typical “--- BEGIN…” string at the beginning of the file.
• CRT is the typical extension of certificates on Linux/Unix certificates. For instance for the configuration of Apache on Linux, coupled with the encrypted private key (KEY), of course.
• CER is the Microsoft way of certificates, recognized by Windows and Internet Explorer. Files with this extension are encoded as DER or Base64 and they can be easily imported in Windows, but they include ONLY the certificate, without its key. They might contain a chain of certificates.
• KEY is the extension usually used for PKCS#8 public and private keys, which can be encoded in DER binary format or ASCII PEM, and can be in clear or encrypted.
• PKCS: Public Key Cryptography Standards are specifics of RSA labs for a PKI, a Public Key Infrastructure. Formats are identified by a number, for instance PKCS#15.
• P7B or P7C: Signed Data PKCS#7 structures without data that contain only the certificate (or certificates) and the Certificate Revokation List. They are user to envelope data of a PKI structure.
• P12: PKCS#12 structure that can contain certificates, public and private keys. Private keys are password-protected.
• PFX: PKCS#12 format that includes certificate, public and private key. Private keys can be password protected. It can be created from keys and certificates in other formats using OpenSSL or other specific tools. If you are configuring a Windows system, then probably you will create, or download, this format
• CA stands for Certification Authority.
• CSR (Certificate Signing Request) is a certificate request to send a CA in order to have a signed certificate. The most used format is the one set by the PKCS#10 standard. The request is compiled using a private key, so that the certificate will be usable only with the private key used to create the CSR. The CSR includes the public key of the private key used to sign it.
• OpenSSL: an open source library for the management of all the ciphering options of the SSL and TLS protocols, NOT to be confused with OpenSSH. Its most notable vulnerability among the many found is Heartbleed. On Linux you can easily convert all aforementioned certificate/key formats by using the tools included with the library and available on the command line.