Note: For brevity, this document will say "SSL" when we mean SSL/TLS.

The NetBurner SSL/TLS library makes SSL as easy as possible. However, if this is your first experience with SSL, some outside reading on how public key cryptography works is extremely helpful.

When you use SSL to connect to http://www.amazon.com (for example) with a normal web browser, you will not need to know anything about certificates. This is because Amazon purchased a certificate from Verisign, and your browser vendor preinstalled the Verisign Certificate Authority as a trusted entity that can issue certificates for organizations like Amazon, which are then trusted by association in what's called a "chain of trust" or "certificate chain."

Above is a picture of a perfectly normal TCP or SSL connection; the client (most often a browser) has connected through the network to a server. If we do not have any entities doing bad things on our network then there is no need for SSL. However, if the data we are sending is worth stealing, we might have a very different network picture:

If our connection is routed through a third party (a normal TCP connection), we have no guarantee that this third party is not an attacker trying to steal or modify our data. The SSL protocol was designed to eliminate this man in the middle attack. SSL is designed not only to make sure that the data we send over the network is hidden from snooping eyes, but it is also designed to make sure we are connected to the proper server without any "attackers" in the middle. This verification is done with Public Key (PK) Cryptography and a hierarchy of trust.

Why do we trust a doctor when we go to the emergency room? We trust the doctor we have never met because we trust the hospital to employ qualified doctors. The hospital vouches for their skills and we trust the hospital. Their medical school also vouches for them by giving them a diploma with their name and the school's seal or signature. We trust the school, we trust the hospital, and thus we trust the doctor. We also don't generally ask for private details like the doctor's birthday or fingerprints or government ID, because if your hospital is letting unauthorized people walk in and put fake credentials on the wall you have much bigger problems.

SSL works in a very similar way. When a client connects to the server sends the client a certificate. This certificate has three major elements:

A name (i.e. who is this server)
A public key (e.g. think of an open padlock)
A signature (by a trusted third party that vouches for the name and the public key)

A doctor's diploma is very similar; it also has three major elements: The doctor's name, the type of degree and the medical school (that vouches for the doctor). For example, Bob and George both graduate from Harvard Medical School. They both have Harvard diplomas. However, the diplomas are unique to each doctor. The diplomas are not interchangeable. Bob's diploma would be of no use to George and vice versa.

Note: Each unique SSL server must have a certificate issued for it. You cannot usually reuse an SSL server certificate between servers of a different domain name, because the certificates are distinguished by the "common name" or "CN" on the certificate which in the case of web servers is usually "example.com".; It is possible to buy multi-subdomain, wildcard-subdomain, or multiple-domain certificates to allow the same certificate to work for "www.example.com", "mail.example.com", "*.example.com" or even "example.org" by using the Subject Alternative Name, SAN, or "alt name" certificate field, however this needs to be set up in advance, you can't simply copy-paste a certificate issued for one domain name and use it on some other domain.

If you went into a new doctor's office and saw a diploma from Harvard medical school, you would feel comfortable with the doctor's skills. You trust Harvard and Harvard will vouch for this doctor. If instead, the diploma were from the Medical School of Antarctica, you might be more skeptical. We do not have the same inherent trust of this unrecognized school as we did with Harvard.

So in setting up our SSL client, we have to decide who we will trust to sign our certificates. This list of trusted certificate authorities needs to be explicitly configured into the client, otherwise the client will be forced to choose between failing to connect or operating in an insecure mode (like choosing "Proceed (unsafe)" or "Accept the Risk and Continue" on a browser security warning page). When the web browser or OS was installed on your PC, it probably installed a list of trusted certificate authorities. With the NetBurner SSL/TLS library, we should explicitly decide whom we are going to trust to sign server certificates.

Note: An SSL client should be be pre-configured with a list of Certificate Authorities (CAs) that it will trust to sign server certificates. This list can be common across all the clients and does not have to be unique. Failing to install a list of trusted CAs will cause the client to either fail or operate insecurely.

Finally, SSL can be used to validate not just the server ("doctor") but client ("patient") also. This is like presenting your health plan ID card or government ID to the hospital when you walk in. The client will need some kind of name or identifier (hopefully something more stable than an IP Address) and they will also need a private key and certificate (which of course includes a public key and signature.)

What do I need to do to make SSL work?

You should configure SSL clients with a list of certificate authorities it should trust.
If creating new SSL certificates, you must create or choose a certificate authority to issue them.
Note
Creating a certificate authority involves creating a CA certificate and key, usually separate from any other certificates and keys.
You must create a private key for each SSL server and have it signed by the certificate authority you have chosen. The signing process creates a certificate from the key via a Certificate Signing Request (CSR).
If using client-side validation (using SSL to validate clients, not just servers) then you must create a key and certificate for the client to use.

How do I find or create a certificate authority?

Using the medical school example, you can go to Harvard pay lots of $$$ and get a diploma that is trusted by everyone. You can also choose to start your own medical school and issue diplomas. Almost everyone in the world would trust a Harvard diploma. Almost no one will trust a "Bob's Medical School" diploma, unless you spend the time convincing them that it is a quality medical school. In the end, you will likely only be able to convince your family, and then only for non-life threatening needs.

SSL certificates are a lot like medical schools; you can go and purchase server certificates. To see what a certificate looks like, open your web browser (e.g. Internet Explorer), and connect to https://www.NetBurner.com (notice the s on the end of https). On Internet Explorer's menu, choose File then Properties. Now, click the Certificates button, and look at all the tabs shown in this section.

How do I know whom my browser trusts?

On your (Internet Explorer) browser's menu - choose Tools then Internet Options. Open the Content tab, click the Certificates button, and open the Trusted Root Certificate Authorities tab. Add Verisign or Thawte and every browser in the world will trust your certificate and your server.

If you want to save some money and create your own certificate authority then you can do so. However, none of the clients will accept your certificate until you convince them to add "Bob's Certificate Authority" to their list of trusted certificate authorities. If, the users using the embedded SSL system you are deploying are all in one business entity, then it is relatively simple to add your own certificate authority to the list of trusted authorities. If you are responsible for both the client and server end of the connection, it is even easier; you can configure the clients to accept a single server authority - yours.

SSL is based on Public Key Cryptography (PK) and a little bit of background on PK is necessary in order to deploy a secure SSL solution. Public Key Cryptography is different from Symmetric Key Cryptography. In PK, the keys used for encryption are broken into two parts, much like a padlock (the public part) and a key (the private part). If you give someone an open padlock and a steel box, they can put things into the box, close the lid, and lock the lock. Unless they have the key to the lock, they cannot open the box. They can be confident that if they mail you the box, none of the mailmen along the way can look inside. Only the person who holds the (private) key to the padlock can open the box. For additional information on Public Key Cryptography, please read the Cryptography FAQ (http://isc.faqs.org/faqs/cryptography-faq).

When the SSL client connects to a server, the server sends back a certificate with a public key (open padlock). This certificate also includes the name of the server and a signature vouching for both the public key and the name. If any part of the certificate is changed, the signature will compute to be invalid.

So, if we have an attacker in the middle, they can watch the padlock going from the server to the client. But, when the client puts their secret information into the box and locks it, the attacker cannot see inside. They only know that the client sent something in the box to the server. The secrets in the box are safe from the prying eyes of the attacker. This safety only exists if the server has done a good job of protecting the private key. If the attacker sneaks into the server room, logs on the server console, and makes a copy of the private key, they can intercept all of the traffic. They can also change the content at will.

Note: When using Public Key Cryptography (as SSL does), the system is only as secure as the security of the private key. Since a server needs access to the private key to unlock the data from the client, the private key must exist on the server.; Also: If the private key exists on the server, then the system is only as secure as the physical security of the server. If the server is not physically secure, then someone (i.e. the attacker) can attach an emulator or other hardware to the server and read out the private key. This applies to Certificate Authority private keys also: an insecure CA could issue certificates for anyone, even attackers.; Conversely: The CA certificate and any client or server certificates can and should be publicized freely. The more widely known and trusted a certificate is, the easier it is for everyone to verify its trustworthiness.

For example, suppose the attacker wants to intercept your credit card number when you send it to Amazon to order a book. We have already shown that they cannot read the data unless they have Amazon's private key. However, they have one other option - they can pretend to be Amazon and offer their own certificate to you, the client. If this certificate is properly signed by a Certificate Authority the client trusts, then client will accept the connection. If any "Certificate Authority" in the list of trusted authorities is compromised, then the system is insecure. If the attacker has the ability to add a new "Certificate Authority" to the client, then they can completely compromise the system.

Note: If the ability to add a "Certificate Authority" to the client's list of trusted authorities is not secure, then system is not secure.; Also: If the list of trusted "Certificate Authorities" exists on the client, then the system is only as secure as the physical security of the client. If the client is not physically secure, then someone (i.e. the attacker) can attach an emulator or other hardware to the client and add a "trusted" authority.

So, this implies that it is not possible to build a system that is more secure than the physical security of the device being secured.

Attention: All the cryptography in the world will not help if someone can gain access to your computer and hide a bug inside the keyboard; or even easier, add or modify a system file to record your keystrokes and periodically send them over the internet to some nefarious foe.

Self-signed vs CA-signed, trusted vs untrusted

For development, testing, or internal-only purposes it may be faster or cheaper to install self-signed certificates on your device. This is the default behavior in many NetBurner examples since it requires nearly zero configuration, third parties, or cost. In this arrangement the device acts as its own CA, creating a new certificate that is its own CA.

The downside of this is that by default no browser or client will trust that certificate, so browsers will pop up scary SSL warning messages meant to discourage most users from accessing the server. These warnings can usually be ignored by the user or bypassed by choosing insecure or no-validation client configuration options, but obviously that makes it hard to trust the resulting connection's security.

The NNDK also ships with CreateCerts scripts which can create a private CA and certificates for your devices with just a few SSL commands, but that CA still won't be trusted by browsers by default. You would need to install the self-signed certificate or private CA certificate into every browser that accesses your NetBurner devices in order to properly resolve the browser warnings.

So, for public-facing, deployment and production purposes it's preferable to obtain certificates that are issued by a trusted Certificate Authority like Verisign, Comodo, GoDaddy, etc. You can do this easily by using our new ACME feature introduced in NNDK 3.5.0, which uses the Let's Encrypt CA by default but also supports the BuyPass CA out of the box, both of which are generally trusted. The downside of ACME is that the CA (Let's Encrypt) needs to verify that the device's domain name is actually controlled by that device, so devices that aren't accessible via a public DNS name can't use this method.

You can also manually generate and send a Certificate Signing Request to a CA of your choice and install the resulting certificate and key onto your device. The downside of this is that the keypair is compiled into the program, so the same manual steps will need to be repeated prior to the certificate's expiration (usually just over 1 year.)

Enterprise customers may also choose to configure and host their own ACME server for automatically issuing and renewing certificates: this is also supported via our ACME feature, contact Support if more information is required.

What do I need to do to make SSL work?

How do I find or create a certificate authority?

How do I know whom my browser trusts?

Self-signed vs CA-signed, trusted vs untrusted

Recommended Reading