TLS Transport Layer SecurityTLSTransport Layer Security – is a communication method (a protocol) defined by the group that standardises Internet communication- the IETF, Internet Engineering Task Force. TLS provides confidentiality and integrity. It is also used for secure identification (authentication) of systems and individuals.

TLS needs to stay up to date with the current world of communication

As with every protocol that handles security, TLS keeps upgrading to keep up with the times. Computers get more powerful, the community (good and bad members) discover issues with the old solutions and new protection schemes are added. A current issue is providing security not only to very powerful servers and desktop computers, but also to all kinds of small connected devices that doesn’t have as much computing power.

That’s a reason why the old standard, SSL, has been replaced with the current one – TLS. All versions of SSL are considered insecure and should no longer be used.

Meeting a server you don’t know

Authentication in TLSMany applications use TLS, it is not only a web protocol. In IP Telephony TLS is used in the SIP protocol. Databases support connections protected by TLS, as do directory services and many of the apps you have on your tablet or smartphone. There are multiple phases in setting up a secure connection, depending on how much security and which kind of security you want.

The first phase is identifying the server. For this, we use a document called a certificate. A certificate for TLS is like a photo ID. You do not trust any paper with a photograph. You look for certain symbols and other markers that tells you about how much you can trust this document. A TLS certificate is digitally signed by a company or an organisation that has validated the content of the certificate. The big question here is “Who do you trust?”. There can be multiple levels too. One company signs a certificate that allows the owner of that certificate to sign new certificates. In TLS that is called a certificate chain of trust. You need to trust all parts of the chain, otherwise it breaks and you have no trust for the server’s certificate at all.

In the real world, if you ask someone for an identification document, you first have to ask yourself if this document is valid. If it is, the next question is – is this the person you really want to do business with? You may have expected another person. This means that even if the certificate and the chain of trust is valid and you trust it, you may still connect to the wrong server.

In the set of tests you will find in the TLS-O-MATIC (this site) there are a number of tests that is about trusting the ID. We have long certificate chains. Evil certificate authorities. Expired certificates. These will hopefully be treated as someone trying to identificate himself with a piece of paper with a child’s drawing on it, some coffee stains and a red blob which is supposed to be a very trustworthy official stamp of the Country of Trust. You will probably not trust that piece of worn paper as you would treat a passport from your country.

Are you dealing with the server you want to communicate with?

tls-validationThis is the second part of the test is trying to find out if you are communicating with a server that is authorised to handle this communication, the server that has the right to fulfil your request. If you look for “” you should not accept a certificate valid for “” for this server. Even if the certificate is valid, it is not the server you want.

The rules for making sure that you are communicating with the proper server depends on the protocol you use. In the web, it’s HTTP. In IP-telephony it’s SIP and in instant communication you may be using XMPP. A client should understand the rules of the protocol used and do proper verification. This is an area where a lot of clients fail. There are programming languages that doesn’t have the ability to verify – like Javascript.

Authentication and validation – required steps for secure communication

Applications and users that require a secure communications channel, like when you connect to your bank over the Internet, trust that the application used – the mobile app or the web browser – perform true authentication and validation. If not, servers on the network path can involve themselves in the communication and listen in or modify communication. It’s what is commonly called a man-in-the-middle attack. If the application can not fully validate and authenticate the server, it should not start a secure communication channel and tell the user so.

Opportunistic Security – better than clear text, but not secure.

Opportunistic SecurityThere are situations where the application can continue anyway. If the user did NOT require a secure channel but there is a possibility to add some level of security to the communication between client and sever, the application may decide to use encryption anyway. This is called Opportunistic Security. Sending all our communication across the network in clear text is proven not to be a good thing. Anyone can listen in. If the client and the server can agree on something that is more protected than clear text, but not fully authenticated and validated, it’s not a secure channel – but a better one than the alternative.

In this case the client says “ok, I can’t trust the certificate and your identity, but we can still encrypt communication“. It will make it harder for anyone that tries to listen to the network traffic in a café, a school or in the office to actually understand what’s going on.

What is the difference? No green bar, no lock

The difference is that in a secure channel, the application will tell the user that it has a secured communication path that the user can trust. If the user trusts the application to be correct, that is. With opportunistic security the application should NOT tell the user anything. Everything happens in the background. The user should not trust this communication path at all.

There are plugins that make your browser select a secure channel if available. Coming generations of the Chrome and Firefox web browsers will always try to set up a secure channel, regardless of the user’s request. If the user request a secure channel, like when you add “HTTPS://” in front of the URL when connecting to your bank, the browser will not accept anything less secure and will perform full authentication and validation.

Learning more

Want to learn about TLS? We have a page with some basic facts about TLS and SSL.

#MoreCryptoYou can also read this presentation as a starting point. We need more crypto and we need better crypto. Start learning more and implementing TLS in your applications today!


Tags: ,