The odd-musings of Jared, the Director of Network Security for IAPS Security Services.

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide security and data integrity for communications over networks such as the Internet. TLS and SSL encrypt the segments of network connections at the Transport Layer end-to-end.

Several versions of the protocols are in wide-spread use in applications like web browsing, electronic mail, Internet faxing, instant messaging and voice-over-IP (VoIP).

The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping, tampering, and message forgery. TLS provides endpoint authentication and communications confidentiality over the Internet using cryptography.

In typical end-user/browser usage, TLS authentication is unilateral: only the server is authenticated (the client knows the server’s identity), but not vice versa (the client remains unauthenticated or anonymous). More strictly speaking, server authentication means different things to the browser (software) and to the end-user (human). At the browser level, it only means that the browser has validated the server’s certificate, i.e. checked the digital signatures of the server certificate’s issuing CA-chain (chain of Certification Authorities that guarantee bindings of identification information to public keys; see public key infrastructure (PKI)). Once validated, the browser is justified in displaying a security icon (such as “closed padlock”). But mere validation does NOT “identify” the server to the end-user. For true identification, it is incumbent on the end-user to be diligent in scrutinizing the identification information contained in the server’s certificate (and indeed its whole issuing CA-chain). This is the only way for the end-user to know the “identity” of the server. In particular: the “locked padlock” icon has no relationship to the URL, DNS name or IP address of the server – thinking otherwise is a common misconception. Such a binding can only be securely established if the URL, name or address is specified in the server’s certificate itself. Malicious websites can’t use the valid certificate of another website because they have no means to encrypt the transmission such that it can be decrypted with the valid certificate. Since only a trusted CA can embed a URL in the certificate, this ensures that checking the apparent URL with the URL specified in the certificate is a valid way of identifying the true site. Misunderstanding this subtlety makes it very difficult for end-users to properly assess the security of web browsing (though this is not a shortcoming of the TLS protocol itself — it’s a shortcoming of PKI).

TLS also supports the more secure bilateral connection mode (typically used in enterprise applications), in which both ends of the “conversation” can be assured with whom they are communicating (provided they diligently scrutinize the identity information in the other party’s certificate). This is known as mutual authentication. Mutual authentication requires that the TLS client-side also hold a certificate (which is not usually the case in the end-user/browser scenario). Unless, that is, TLS-PSK, the Secure Remote Password (SRP) protocol, or some other protocol is used that can provide strong mutual authentication in the absence of certificates.

TLS involves three basic phases:

1. Peer negotiation for algorithm support
2. Key exchange and authentication
3. Symmetric cipher encryption and message authentication

During the first phase, the client and server negotiate cipher suites, which determine the ciphers to be used, the key exchange and authentication algorithms, as well as the message authentication codes (MACs). The key exchange and authentication algorithms are typically public key algorithms, or as in TLS-PSK preshared keys could be used. The message authentication codes are made up from cryptographic hash functions using the HMAC construction for TLS, and a non-standard pseudorandom function for SSL.

Typical algorithms are:

* For key exchange: RSA, Diffie-Hellman, ECDH, SRP, PSK
* For authentication: RSA, DSA, ECDSA
* Symmetric ciphers: RC4, Triple DES, AES, IDEA, DES, or Camellia. In older versions of SSL, RC2 was also used.
* For cryptographic hash function: HMAC-MD5 or HMAC-SHA are used for TLS, MD5 and SHA for SSL, while older versions of SSL also used MD2 and MD4.

Typically, the key information and certificates necessary for TLS are handled in the form of X.509 certificates, which define required fields and data formats.

History and Development:

Early research efforts toward transport layer security included the Secure Network Programming (SNP) API, which in 1993 explored the approach of having a secure transport layer API closely resembling sockets, to facilitate retrofitting preexisting network applications with security measures. The SNP project received the 2004 ACM Software System Award.

The SSL protocol was originally developed by Netscape. Version 1.0 was never publicly released; version 2.0 was released in February 1995 but “contained a number of security flaws which ultimately led to the design of SSL version 3.0″, which was released in 1996. This later served as the basis for TLS version 1.0, an Internet Engineering Task Force (IETF) standard protocol first defined in RFC 2246 in January 1999. Visa, MasterCard, American Express and many leading financial institutions have endorsed SSL for commerce over the Internet.

SSL operates in modular fashion. It is extensible by design, with support for forward and backward compatibility and negotiation between peers.

Security:

TLS/SSL have a variety of security measures:

* The client may use the certificate authority’s (CA’s) public key to validate the CA’s digital signature on the server certificate. If the digital signature can be verified, the client accepts the server certificate as a valid certificate issued by a trusted CA.

* The client verifies that the issuing CA is on its list of trusted CAs.

* The client checks the server’s certificate validity period. The authentication process stops if the current date and time fall outside of the validity period.

* Protection against a downgrade of the protocol to a previous (less secure) version or a weaker cipher suite.

* Numbering all the Application records with a sequence number, and using this sequence number in the message authentication codes (MACs).

* Using a message digest enhanced with a key (so only a key-holder can check the MAC). This is specified in RFC 2104. TLS only.

* The message that ends the handshake (“Finished”) sends a hash of all the exchanged handshake messages seen by both parties.

* The pseudorandom function splits the input data in half and processes each one with a different hashing algorithm (MD5 and SHA-1), then XORs them together to create the MAC. This provides protection even if one of these algorithms is found to be vulnerable. TLS only.

* SSL v3 improved upon SSL v2 by adding SHA-1 based ciphers, and support for certificate authentication. Additional improvements in SSL v3 include better handshake protocol flow and increased resistance to man-in-the-middle attacks.

How It Works:

A TLS client and server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection’s security:

* The handshake begins when a client connects to a TLS-enabled server requesting a secure connection, and presents a list of supported ciphers and hash functions.

* From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision.

* The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA), and the server’s public encryption key.

The client may contact the server that issued the certificate (the trusted CA as above) and confirm that the certificate is authentic before proceeding.

* In order to generate the session keys used for the secure connection, the client encrypts a random number (RN) with the server’s public key (PbK), and sends the result to the server. Only the server can decrypt it (with its private key (PvK)): this is the one fact that makes the keys hidden from third parties, since only the server and the client have access to this data. The client knows PbK and RN, and the server knows PvK and (after decryption of the client’s message) RN. A third party may only know PbK, unless PvK has been compromised.

* From the random number, both parties generate key material for encryption and decryption.

This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes.

If any one of the above steps fails, the TLS handshake fails, and the connection is not created.

Government-imposed Protocol Limitations:

Some early implementations of SSL used 40-bit symmetric keys because of US government restrictions on the export of cryptographic technology. After several years of public controversy, a series of lawsuits, and eventual US government recognition of cryptographic products with longer key sizes produced outside the US, the authorities relaxed some aspects of the export restrictions.

Nefarious computer users have a variety of tools at their disposal enabling them to disrupt, intercept, and re-route network traffic in an effort to gain access to a system. In general terms, these threats can be categorized as follows:

Interception of communication between two systems — In this scenario, the attacker can be somewhere on the network between the communicating entities, copying any information passed between them. The attacker may intercept and keep the information, or alter the information and send it on to the intended recipient.

This attack can be mounted through the use of a packet sniffer — a common network utility.

Impersonation of a particular host — Using this strategy, an attacker’s system is configured to pose as the intended recipient of a transmission. If this strategy works, the user’s system remains unaware that it is communicating with the wrong host.

Both techniques intercept potentially sensitive information and, if the interception is made for hostile reasons, the results can be disastrous.

If SSH is used for remote shell login and file copying, these security threats can be greatly diminished. This is because the SSH client and server use digital signatures to verify their identity. Additionally, all communication between the client and server systems is encrypted. Attempts to spoof the identity of either side of a communication does not work, since each packet is encrypted using a key known only by the local and remote systems.

As most of you know, I highly support encryption in all things internet. As such, this article will focus on encrypting our instant messenger sessions and will talk about the Pidgin instant messenger system with a focus on Pidgin OTR (Off-The Record Messaging) and how your chat sessions can be completely encrypted and protected at all times. Before we go any further, I need to tell you that Pidgin supports multiple instant messengers all at once so if you use more than one messenger, you can run them all from within the one Pidgin client. Ok, lets take a look at what Pidgin supports:

MSN
AIM
ICQ
Yahoo
Bonjour
Gadu-Gadu
Google-Talk
Novell GroupWise
IRC
MySpace IM
QQ
SILC
Simple
SameTime
XMPP

Now keep in mind that even if you have multiple accounts with any instant messaging services, you can run them all at once through this system. The direct download for the Pidgin Messenger can be found at http://www.pidgin.im You can get the Pidgin OTR add-on from here.

You may now be wondering what Off-The-Record Messaging is all about. Let me explain:

*Encryption
No one else can read your instant messages.

*Authentication
You are assured the correspondent is who you think it is.

*Deniability
The messages you send do not have digital signatures that are checkable by a third party. Anyone can forge messages after a conversation to make them look like they came from you. However, during a conversation, your correspondent is assured the messages he sees are authentic and unmodified.

*Perfect forward secrecy
If you lose control of your private keys, no previous conversation is compromised.

It should be noted that Pidgin & OTR are completely free. It is licensed under the GNU General Public License which means you will never be charged for it. Every one likes something for free right?

Ok, the “No Digital Signature” means complete deniability. This means that in a court of law, no one can prove that an instant messenger conversation actually originated by you. All instant messengers, even the hugely popular ones by MSN, Yahoo, Google, & ICQ all contain digital signatures that go out with each message you send and can be personally traced back to you by an expert. Pidgin & OTR eliminate this possibility if implemented correctly. The main functionality of the OTR add-on is to encrypt all messages between two users. This means that you and the person you are talking to via instant messenger must both have the Pidgin instant messenger and OTR installed. This is a two way system.

Once you and the other person(s) are encrypted, you are assured of a completely private and highly secure instant messenger chat session. Proxy options are fully compatible with this instant messenger. The IAPS SSH 768-bit Encrypted Service is especially useful with this service.