Cryptography and ciphers uses in SSL

In and Out of cryptography and ciphers uses in SSL/TLS communication. Also the importance to disable RC4 in the environment,

Before go through the in depth of cipher suites I would like to give some lights on what is TLS, SSL and HTTPS, because many of us not so sure on these terms and difference.

TLS is the new name for SSL. Namely, SSL protocol got to version 3.0; TLS 1.0 is "SSL 3.1". TLS versions currently defined include TLS 1.1 and 1.2. Each new version adds a few features and modifies some internal details. We sometimes say "SSL/TLS".

HTTPS is HTTP-within-SSL/TLS. SSL (TLS) establishes a secured, bidirectional tunnel for arbitrary binary data between two hosts. HTTP is a protocol for sending requests and receiving answers, each request and answer consisting of detailed headers and (possibly) some content. HTTP is meant to run over a bidirectional tunnel for arbitrary binary data; when that tunnel is an SSL/TLS connection, then the whole is called "HTTPS".

To explain the acronyms:

"SSL" means "Secure Sockets Layer". This was coined by the inventors of the first versions of the protocol, Netscape (the company was later bought by AOL).

"TLS" means "Transport Layer Security". The name was changed to avoid any legal issues with Netscape so that the protocol could be "open and free" .It also hints at the idea that the protocol works over any bidirectional stream of bytes, not just Internet-based sockets.

"HTTPS" is supposed to mean "HyperText Transfer Protocol Secure", which is grammatically unsound. Nobody, except the terminally bored pedantic, ever uses the translation; "HTTPS" is better thought of as "HTTP with an S that means SSL". Other protocol acronyms have been built the same way, e.g. SMTPS, IMAPS, FTPS... all of them being a bare protocol that "got secured" by running it within some SSL/TLS.

Now let me go to the cipher suites, the “cipher” or “encryption technique”, there are a large number of different ciphers — some are very fast and very insecure.  Some are slower and very secure.  Some weak ones are around from the days.

Please find some of the most common Cipher suites uses in Exchange server, you can find the details from Registry.

The most common cipher suites are AES and RC4,

RC4:- In September 2015, Microsoft announced the end-of-support of the RC4 cipher in Microsoft Edge and Internet Explorer 11 in early 2016. There is consensus across the industry that RC4 is no longer cryptographically secure. Hence many customers are already in the process of complete upgrades away from RC4 soon (Disabling RC4 from Load balancers and from applications (exchange server)). As per my Microsoft, as a forthcoming update will disable RC4 by default and RC4 will no longer be used for TLS fallback negotiations.

AES: - AES, the Advanced Encryption Standard, is a relatively new encryption technique/cipher that is the successor of DES.  AES was standardized in 2001 after a 5 year review, and is currently one of the most popular algorithms used in symmetric key cryptography (which, for example, is used for the actual data transmission in SSL and TLS).  It is also the “gold standard” encryption technique; many security-conscious organizations actually require that their employees use AES-256 (256-bit AES) for all communications.

AES vs RC4

AES (Advanced Encryption Standard) and RC4 are two encryption ciphers that are used in a variety of applications. A common example where you would see both ciphers employed is in wireless routers. Although you would not explicitly see RC4 as an encryption mechanism there, both WEP and TKIP implement the RC4 cipher. Whereas AES is relatively new and very complex, RC4 is very old and is very simple.

The most significant difference between the two would probably be their type. AES is a block cipher that operates on discrete blocks of data using a fixed key and a formula while RC4 is a stream cipher that does not have a discrete block size. Instead, it uses a keystream of pseudorandom bits that is combined to the data using an exclusive OR (XOR) operation. You can use block ciphers as stream ciphers and vice versa, so the separation is not very distinct. But it is quite well known that RC4 is not very effective when used as a block cipher.

A good example of the weaknesses of RC4 is the implementation of WEP. WEP has been completely rendered insecure and can even be broken within a couple of minutes with tools that you can find readily available online. Although TKIP addresses some of the issues that have plagued WEP, it is not considered to be as secure as AES is. For this reason, it is advisable to use AES in any situation unless hardware limitations prevent you from doing so.

The primary reason why RC4 is very popular is the fact that it is simple and it can be very fast. This is already being mitigated since AES implementations in hardware are becoming very popular as it provides speed advantages over software implementations.

Lastly, RC4 is trademarked since it was initially a trade secret, which led to some people coming up of inventive ways to call the leaked description way back in 1994; like ARCFOUR and ARC4 (Alleged RC4). On the other hand, AES is publicly available and can be freely used without hitting any legal problem.

Summary:

1. AES is a very new and complex encryption standard while RC4 is rather old and simple

2. AES is a block cipher while RC4 is a stream cipher

3. AES is extremely secure while RC4 is not so

4. RC4 is very fast compared to AES

5. RC4 is trademarked while AES is not

Common scenarios where people migrate from RC4 to AES

As I said earlier now many companies are in the process for switching from Rc4 to AES, including the infrastructure what I support. Current infrastructure what I support here it include Cisco AES and Citrix Netscaler Load Balancer. As per my experience we need to a lot pre-migration checks before we migrated from Rc4 to AES, as it may impact any kind of communication issues. Here in this case, we have tested many scenarios in our test environment by created test VIPs. I would like to share some common scenarios.

When we checked on our ACE VIPs, we found the below Cipher suites.

Testing SSL server <ACE VIP DNS Name> on port 443

  Supported Server Cipher(s):

    Accepted  SSLv3  256 bits  AES256-SHA

    Accepted  SSLv3  128 bits  RC4-MD5

    Accepted  TLSv1  256 bits  AES256-SHA

    Accepted  TLSv1  128 bits  RC4-MD5

  Prefered Server Cipher(s):

    SSLv3  256 bits  AES256-SHA

    TLSv1  256 bits  AES256-SHA

If I looked in to my Netscaler  VIP settings , there is a wider list of ciphers, but the interesting thing is that the preferred cipher is RC4. That means that it is the Netscaler enforcing this! I know this shouldn’t be an issue because it’s just preferred. And if client and server cannot match preferred then it will negotiate one of the others but quite odd that the Netscalers are preferring the weakest which is about to be disabled.

Testing SSL server <Netscaler VIP DNS Name> on port 443

  Supported Server Cipher(s):

    Accepted  SSLv3  256 bits  AES256-SHA

    Accepted  SSLv3  128 bits  AES128-SHA

    Accepted  SSLv3  168 bits  DES-CBC3-SHA

    Accepted  SSLv3  128 bits  RC4-SHA

    Accepted  SSLv3  128 bits  RC4-MD5

    Accepted  TLSv1  256 bits  AES256-SHA

    Accepted  TLSv1  128 bits  AES128-SHA

    Accepted  TLSv1  168 bits  DES-CBC3-SHA

    Accepted  TLSv1  128 bits  RC4-SHA

    Accepted  TLSv1  128 bits  RC4-MD5

  Prefered Server Cipher(s):

    SSLv3  128 bits  RC4-MD5

    TLSv1  128 bits  RC4-MD5

And if I connect directly to one of the servers bypassing the Netscaler (because they don’t use Policy Based Routing) I can see that the preferred is now what the Windows server is preferring (AES128):

Testing SSL server <Server name FQDN> on port 443

  Supported Server Cipher(s):

    Accepted  TLSv1  256 bits  AES256-SHA

    Accepted  TLSv1  128 bits  AES128-SHA

    Accepted  TLSv1  168 bits  DES-CBC3-SHA

    Accepted  TLSv1  128 bits  RC4-SHA

    Accepted  TLSv1  128 bits  RC4-MD5

  Prefered Server Cipher(s):

    TLSv1  128 bits  AES128-SHA

 

So in summary it seems that even with ACE we currently support AES 256, and even if you adjust your preferred list on the Netscaler we’ll still get either AES128 or AES256, if we have AES in addition to the RC4, then exchange should not break. RC4. And moreover there are many applications which are running RC4 alone on Cisco ACE. Hence there is every possibility that exchange applications running with RC4 cipher alone would fail post the change(That  I need to test individually and coordinate with application Vendor to address this, it include tremendous time )

Exchange will accept max TLS 1.2 on inbound and 1.1 on outbound. It will use the Windows server cipher suites and preferences.

Domino will send 1.2 and accept 1.2 but does not support 1.1. So Domino->Exchange is 1.2 but Exchange->Domino is TLS 1.0 max. But should accept AES128/256. It maintains its own list of ciphers and preferences separate from Windows.

Ironport needs a software upgrade to handle anything better than 1.0.

How is the cipher chosen in an SSL or TLS session?

In general, when an SSL client, such as an email program or web browser, connects to a server and wishes to use SSL or TLS, the client sends the server a list of encryption ciphers that it supports.  The server then goes through the list, in order, and chooses the first match that it also supports.  Usually, the client orders the list with the most secure methods first, so that the most secure method supported by both the client and server is selected.  Sometimes, the client orders the list based on other criteria to make a compromise between security and speed; this can result in a sub-optimal cipher being chosen.

AES encryption is the way to go when using SSL, if you have any choice about it.   If you have qualms about security, we highly recommend using a web browser and/or email client that will enable use of AES (which these days includes all modern programs).

Note that SSL and TLS protect only the data sent between you and the server.  When you send and receive email, the message data travels over the Internet between the sender and recipient and will be unprotected, no matter how good your  SSL.

More details on Encryption and SSL

Here we are going to how to protect the communication different encryption type to protect the communication, the two main types of encryption.

Symmetric Encryption:-

In symmetric encryption, you and your destination share a “secret” key. Using this key, you can encrypt a message into “cyphertext”. Cyphertext looks like a random sequence of characters and is completely meaningless to anyone unless they also have the secret key, in which case they can decrypt the cyphertext back into the original message and read it.
Using symmetric key encryption, eavesdropping and unwanted backups of your messages no longer are a problem (unless the eavesdropper knows what your secret key is). It also becomes harder for someone to modify your messages in transit in any kind of a meaningful way.

An example of a popular, excellent method used for symmetric encryption is AES-256

Message Digests / Authentication Codes:-

A “Message Digest” or “Message Authentication Code” is really a very simple concept. You take your message and pass it through an algorithm that spits out a relatively short sequence of characters (maybe 128 or 256 or so of them). This sequence of characters is a “fingerprint” of the message. Any change in the message would produce a significantly different “fingerprint”. There is no way to “reverse engineer” the original message from its fingerprint and it is almost “impossible” (assuming that your method of making these fingerprints is sufficiently “good”) to find two messages that yield the same fingerprint (just like trying to find two complete strangers who have the same fingerprint).

An example of a good modern function for this process is “SHA2“.

Asymmetric Encryption

In asymmetric encryption, also known as “public key” encryption, each person has TWO keys. Any cyphertext created using one of the keys can ONLY be decrypted using the other key. For example, say you have keys “K1” and “K2”. If you encrypt your message with K1, then ONLY K2 can be used to decrypt it. Similarly, if you encrypt using K2, ONLY K1 can be used to decrypt it. This is distinctly different from symmetric key encryption where you only have one key that performs both functions on the same

In asymmetric key encryption, the two keys that each person possesses are commonly named the “private” and “public” keys because the “public” one is published or given out freely to anyone who wants a copy and the “private” one is kept secret. The security of asymmetric key encryption depends only on whether you can keep your private key secret.

Securing Your Email with TLS

The easiest thing you can do to make your email more secure is to use an email provider that supports “Transport Layer Security” (SSL / TLS) for their Webmail, POP, IMAP, and SMTP servers.

TLS uses a combination of asymmetric and symmetric key encryption mechanisms. If you connect to a server using TLS

1. The server uses its private key to prove to you that it is in fact the server that you are trying to connect to. This lets you know that you are not connecting to a “middleman” that is trying to intercept your communications.
2. You send the server your public key.
3. The server generates a “secret key” and sends it to you encrypted using your public key.
4. You and the server then communicate using symmetric key encryption using this shared secret key. (Symmetric key encryption is faster than asymmetric key encryption).

The benefits of TLS are twofold: 1. you can determine if you are connecting to the right server, and 2. you and the server can communicate securely.

If you get any warning messages when connecting to a server using TLS, you should think twice about ignoring them. While your provider may just have a small technical problem that is causing the warning, these warnings can also indicate that your communications are being intercepted. These warnings usually indicate one of the following:

1. The server’s SSL “certificate” (i.e. public/private key pair) has expired.
2. Some of the information in the certificate doesn’t match the information you expect — i.e. the certificate was issued for a different server name than the one you are trying to connect to. (You could be inadvertently connecting to the wrong server.)
3. The certificate was issued by an untrusted agency.
4. There is a “man in the middle” eavesdropping on your connection

SSL/TLS certificates are (generally) issued by third party agencies such as Thawte.com or VeriSign. These 3rd party companies do a background check on companies that request certificates, and only issue certificates if the companies have a right to them. The certificate includes the name of the company, the name of the issuing company, and the name of the server to which it is issued. When you connect to an SSL server you can verify this embedded information and the fact that it was issued by a third party company that you trust. If the certificate is valid then you can have a high degree of confidence that the server you are connecting to is the server you want to reach.

By using TLS for WebMail, POP, IMAP, and SMTP  you ensure that communications between your personal computer and your email service provider’s servers will be encrypted. Your message contents, username, and password will be hidden from eavesdroppers — but only hidden from eavesdroppers between you and your service provider!

TLS services do not protect your messages once they arrive to your SMTP Server or when they leave your SMTP Server and head to their destinations (unless your provider can and is using SMTP TLS to talk to the recipient’s SMTP server).  So, it doesn’t generally protect your message contents, but it does completely protect your username and password from detection. This is very important because it prevents identity theft, forged messages, etc.

TLS is very easy to use. It usually only involves clicking a few checkboxes in the configuration of your email client. It is transparent to your recipients – you can use TLS for these services even if your recipients can not or do not. These measures protect you and your password. We strongly encourage the use of TLS for email communications (and, really, any communications over the Internet) whenever possible.

How Does Secure Socket Layer (SSL or TLS) Work

SSL relies on the concept of “public key cryptography” to accomplish these same tasks. In normal “symmetric” encryption, the two parties communicating share a “password” and that password is used to both encrypt and decrypt messages. While this is fast and efficient, how do you communicate the shared passwords with people you have not yet met in a way that is itself secure?

In “public key cryptography”, each person has two keys — a “public” key and a “private” key. Anything encrypted with the person’s public key can only be decrypted with the private key and vice versa. Each person then tells the world what his public key is and keeps his private key safe, secure, and, well, private.

If  User-A sends User-B a message encrypted with B’s public key, then only B can open it, as only B has her private key. This is like an envelope that anyone can seal but which only B can open.

If A sends B a message encrypted with A’s private key, then anyone can open it, as everyone has access to A’s public key.  However, successfully opening the message proves that it was sent by A and no one else, as only A has access to his private key. This is like an envelope that only A can seal, but which anyone can open and thus prove that A sealed it.

So, let’s see how SSL actually works for securing your communications over the Internet. Before the communications occur, the following takes place:

A company wishes to secure communications to their web server company.com.

They create a public and private key for company.com (this is also known as an “SSL Certificate“).

They go to a trusted third party company such as Thawte or Verisign: Thawte makes the company prove its identity and right to use the company.com domain. This usually involves a some paperwork and a fee.

Once the verification is complete, Thawte gives the company a new public key that has some additional information in it. This information is the certification from Thawte that this public key is for the company and company.com, that this has been verified by Thawte, and that this is valid for a certain period of time. This certification information is encrypted using Thawte’s own private key

Then, when A wishes to communicate with the company at company.com,

User-A makes a connection to company.com from his computer (e.g. from his web browser if this is a web site). This connection is made to a special “port” (address) on company.com that is set up for SSL communications only (alternately, “User-A” could connect to a non-secure port and the initiate a secure connection after the fact

“User-A” connects to company.com on its SSL-secured port, indicating that he wants a secure connection and specifying what level of SSL security he knows how to use (e.g. what versions and Ciphers his programs can use), the company sends back its public key (and some other information, like what Ciphers will actually be used).

“User-A” gets the public key and decides if it is “OK”…

If the public key has expired, this could be a problem (these are only valid for a certain number of years before they have to be re-verified)

If the public key claims to be for some domain that is not company.com that could be a significant problem.

“User-A” has the public key for Thawte (and many other third party companies) stored in its computer — because these come with the computer. Thus, “User-A” can decrypt the validation information, prove the validation is actually from Thawte, and verify that the public key is certified by Thawte. If “User-A” trusts Thawte, then he can trust that he is really communicating with Company. If “User-A” doesn’t trust Thawte, or whatever Third Party verification company is actually being used, then the identity of who is running the servers to which “User-A” is connecting is suspect.

If “User-A” doesn’t trust the server, then the communication is terminated before anything sensitive is communicated.

Note: If “User-A” has his own SSL certificate, he may send that to the server at this point to see if the server trusts “User-A”.  These “Client-side SSL certificates” are not commonly used, but provide a good way for users like “User-A” to authenticate themselves with a server without using a username or password (or in addition to doing so, as a second factor).  In cases where this is used, the server would have to already know about the “User-A”’s certificate and verify it in a similar way to how the client verified the server.  If this fails, the connection is terminated.  If a client-side certificate is not needed, this step is skipped.

Once “User-A” is happy with the server (and the server with “User-A”, if needed), then he can generate a “symmetric key” (a password) for use with the Cipher chosen by the server.  ”User-A” encrypts this key using the server’s public key and sends it back to the server.  The server (and only the server) can decrypt this message and get this key, which is now shared by both “User-A” and server.

“User-A” will then start communicating with the company by encrypting all data using this key and the chosen Cipher.  Normal “symmetric” (password-based) encryption takes place from this point forward because it is much faster than using the public and private keys for everything. The public and private keys were needed to enable the company (and possibly “User-A”) to prove its identity and right to domain.com and to enable “User-A” and server to generate and securely communicate the unique, shared password for the rest of the dialog.

For SSL and other asymmetric encryption systems, there are two keys involved. The key built into the SSL certificate is the asymmetric key. Due to how the math works, the asymmetric keys are easier to break than symmetric encryption keys. As a result, asymmetric keys must be longer (have larger bit lengths, like 1024, 2048, or more).

The asymmetric key is used together with the asymmetric encryption algorithm during the initial client-server communications. During that phase, identity is checked and verified, etc. Also, because asymmetric encryption is much slower than symmetric encryption, the client and server agree on a symmetric encryption algorithm and new symmetric key to use for the remainder of their communications session. They then switch from asymmetric to symmetric encryption (using something like AES) for the rest of the session. The 128bit or 256bit encryption key is that used for the specific symmetric encryption session.

So:
* The 1024+ key is the asymmetric key used for all initial communications over SSL with a specific server.
* The 128-256 bit key is the symmetric encryption session key used for a single specific session of encrypted communications between client and server. It is negotiated during the start of the session, that communication protected using the asymmetric encryption.
* Because of the mathematical nature of asymmetric encryption, the key length for asymmetric keys must be much longer than that for symmetric keys to ensure security

TLS with SMTP

The mechanism and language (i.e. protocol) by which one email server transmits email message(s) to another email server is called SMTP (Simple Mail Transport Protocol). For a long time now, email servers have had the option of using TLS to transparently encrypt the message transmission from one server to the other.

Use of TLS with SMTP, when available, ensures that the message contents are secured during transmission between the servers.

Not all servers support TLS!

Use of TLS requires that the server administrators:

1. purchase of one or more SSL certificates
2. configure the email servers to use them (and keep these configurations updated)
3. allocate additional computational resources on the email servers involved.

For these reasons, many email providers, especially free or public ones, have in the past not supported TLS at all.  Over the last few years, however, the trend has been to add TLS everywhere. Now, the majority of providers do support TLS.

For TLS transmission to be used, the destination email server must “advertise” support for TLS (see: How to Tell Who Supports TLS for Email Transmission) and the sending computer or server must be configured to use TLS connections when possible.The sending computer or server could be configured for:

1. No TLS — never use it.
2. Opportunistic TLS — use it if it is available, if not, send insecurely.
3. Forced TLS — use TLS or do not deliver the email at all