Turn SSL ON: Your Own Certificate Authority - Or simply use “Let's Encrypt”

Presenter: Ovidiu CICAL

Senior Software and Security Engineer

Cluj-Napoca - Romania

SSL (or TLS to be more correct since is the

most recent and secured one) is a

cryptographic protocol designed to provide

secured communications. It ensures:

Privacy (data not sent in plain);

Integrity (data has not been altered in

motion);

Trust (data belongs to the trusted source).

Short history (OpenSSL & Wikipedia):

SSL 1.0, 2.0 and 3.0

Developed by Netscape's engineers, SSL 1.0 never saw the

light of day due to security flows.

SSL 2.0 - Released 1995 - lasted just about one year, again

from serious security flows. In was replaced by SSL 3.0 in

1996.

In 2014, SSL 3.0 was found to be vulnerable to the

POODLE attack that affects all block ciphers in SSL; and

RC4, the only non-block cipher supported by SSL 3.0, is also

feasibly broken as used in SSL 3.0.

TLS 1.0, 1.1, 1.2 and 1.3 (draft)

TLS 1.0 - Released 1999 - an upgrade from SSL 3.0. The differences are significant enough that SSL

3.0 and TLS 1.0 don't inter-operate Some of the major differences between them are:

- MACs are different - SSL 3.0 uses a modification of an early HMAC while TLS 1.0 uses HMAC;

TLS 1.1 - Released 2006 - is an update to TLS 1.0. The major change is (along with many more):

- The Implicit Initialization Vector (IV) is replaced with an explicit IV to protect against Cipher

block chaining (CBC) attacks.

TLS 1.2 - Released 2008 - based on TLS 1.1 - contains improved flexibility and lots of security fixes.

TLS 1.3 (draft) - As of October 2015, TLS 1.3 is a working draft. Major differences from TLS 1.2 include:

- Dropped support for many insecure or obsolete features including, compression, renegotiation,

static RSA and DH key exchange, Change Cipher Spec protocol, Hello message UNIX time etc;

- Prohibition of SSL or RC4 negotiation for backwards compatibility;

- Removed support for MD5 and SHA-224 hashes with signatures;

TLS Implementations:

There are several TLS implementations which are free

software and open source. The most notable ones are:

OpenSSL – most common one;

LibreSSL;

MatrixSSL;

GnuTLS;

cryptlib (used in C);

Java Secure Socket Extension (JSSE from Oracle);

PolarSSL (changed name recently);

CyaSSL (changed name recently).

Your own CA - Certificate Authority

A certificate authority (CA) is an entity that signs digital

certificates. Many websites need to let their customers know

that the connection is secure, so they pay an internationally

trusted CA (eg, VeriSign, DigiCert) to sign a certificate for

their domain.

In some cases it may make more sense to act as your own

CA, rather than paying a CA like DigiCert. Common cases

include securing an intranet website, or for issuing

certificates to clients to allow them to authenticate to a

server (eg, Apache, nginx or OpenVPN).

Example of creating your Certificate Authority:

I will use OpenSSL for this example. The steps are really easy and the result is amazing. I have the

OpenSSL commands available for each step, if some of your are interested in implementing own CA,

just ask for them and I'll email them to you (I will append them anyway at this presentation and make it

public on the Wiki).

1. Configuration file - This is very important as you will be acting as a CA from now on, so you will do a

lot o repetitive work when generating certificates. There are lots of options in this file, documentation

from OpenSSL is very generous;

2. Create the root key - Create the root key and keep it absolutely secure. The root key can issue

trusted certificates. Encrypt the root key with AES 256-bit encryption and a strong password. Also, use

4096 for root and intermediate authority keys;

3. Create the root certificate - Use the root key to create a root certificate. Give the root certificate a long

expiry date, such as 10 or 20 years. Once the root certificate expires, all certificates signed by the CA

become invalid. Also, specify the path to your OpenSSL configuration file, otherwise will default to the

systems' one;

4. A very good practice is to issue an Intermediate CA, which will be later used in different branches of

your application(s). This way, you can keep the root key privatelly and in case of loosing the intermediate

key, you can revoke it and create a new intermediate CA. The steps to create this CA are the same as

above except that you will use root key for this;

5. Create a Certificate Chain by combining the root certificate with the intermediate certificate

concatenating them;

Next steps:

The next obvious step is sign server or client certificates.

This is not the purpose of this presentation, but the main

idea is that you will act as a third-party to the root CA from

now on and you will need to create your own private key and

certificate signing request (CSR).

After you have the two resources above, you will present

the CSR to the root CA generated above which will return a

signed certificate that works only with your private key and

you must add the key and signed certificate, along with the

Chain certificate to the Web Server of your choice.

Let's Encrypt

I proposed the subject for this presentation a couple of weeks ago. A few

days ago I received from our colleague Luke a forwarded email from a

friend of ours, an OWASP Global Board member, Jim Manico.

Jim is very found of OWASP and he strongly believes we are doing the

right thing by joining OWASP and raising Information Security Awareness

I cannot agree more with him and I hope everyone joining OWASP

(either boards or meetings) thinks the same and will help spread the

word. OWASP has lots of tools to help you secure the products you

develop and the processes aside.

The subject raised in his email is about my second part of the

presentation, namely "Let's Encrypt" Service. For those of you who are

not familiar with this service, I will shortly describe it, then play a video

from their official Youtube channel.

Let's Encrypt is a service run by Internet Security Research Group (ISRG), a California

public benefit corporation, aiming to provide a free, automated and open certificate

authority (CA), run for the public's benefit.

The main goals of the service are:

Free: Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted

certificate at zero cost.

Automatic: Software running on a web server can interact with Let’s Encrypt to painlessly

obtain a certificate, securely configure it for use, and automatically take care of renewal.

Secure: Let’s Encrypt will serve as a platform for advancing TLS security best practices,

both on the CA side and by helping site operators properly secure their servers.

Transparent: All certificates issued or revoked will be publicly recorded and available for

anyone to inspect.

Open: The automatic issuance and renewal protocol will be published as an open

standard that others can adopt.

Cooperative: Much like the underlying Internet protocols themselves, Let’s Encrypt is a

joint effort to benefit the community, beyond the control of any one organization.

So how it works?

There are two steps to this process.

1. Domain Validation - First, the agent proves to the CA that the web server controls a

domain. The main idea here is like with other services, to validate that you're in control of

the domain. You can do this with a DNS record or by providing an URI over HTTP (you

don't have HTTPS yet, do you? :) ).

After the domain is validated, the agent identifies itself by the public key provided before.

So how it works?

2. Certificate Issuance (& Revocation) - Once the agent has an authorized key pair,

requesting, renewing, and revoking certificates is simple - just send certificate management

messages and sign them with the authorized key pair.

To get the certificate for your domain, the agent will create the CSR (Certificate Signing

Request). The CSR includes a signature by the private key corresponding to the public key

in the CSR.

The agent also signs the whole CSR with the authorized key for your domain so that the

Let’s Encrypt CA knows it’s authorized.

If everything looks good when Let's Encrypt receives the request and verifies both

signatures, it issues a certificate for your domain with the public key from the CSR and

returns it to the agent.

So how it works?

I've added this 2min video for a better understanding:

https://www.youtube.com/watch?v=Gas_sSB-5SU

Looking at what Let's Encrypt wants to achieve and tying that with the

presentation I had before, about your own CA, you can imagine what a massive

work that is and how many resources are needed, both human and machine.

So please, look into this, recognize the importance and benefit this can offer to

you, to your websites, applications or company and help as much as possible

with the project.

Write some tools or agents for other web servers, join the community they have

in place, spread the word. Even Global CAs won't go away soon, which is not the

goal of Let's Encrypt, they will reconsider the prices for what they offer so that

people can afford security.

Thank you, and OWASP Foundation!

Ovidiu CICAL