Turn SSL ON: Your Own Certificate Authority - or simply use "Let's Encrypt". Ovidiu CICAL

1. Turn SSL ON: Your Own Certificate Authority - Or simply
use “Let's Encrypt”
Presenter: Ovidiu CICAL
Senior Software and Security Engineer
Cluj-Napoca - Romania

2. 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).

3. 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.

4. 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;

5. 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).

6. Your own CA - Certificate Authority

7. 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).

8. 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;

9. 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.

10. Let's Encrypt

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. Thank you, and OWASP Foundation!
Ovidiu CICAL