IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
Hi all, my name is Jason McClure and I’m a Platforms PFE with Microsoft. If you read Demystifying Schannel from Nathan Penn, then you may be asking yourself “What do all those letters and numbers mean?”
Often, we deal with confusion on the differences between a Protocol, Key Exchange, Ciphers, and Hashing Algorithms. Understanding the differences will make it much easier to understand what and why settings are configured and hopefully assist in troubleshooting when issues do arise. Let’s take a look at each of these areas.
A cryptographic protocol is leveraged for security data transport and describes how the algorithms should be used.
Great! What does that mean? Simply put, the protocol decides what Key Exchange, Cipher, and Hashing algorithm will be leveraged to set up the secure connection.
Transport Layer Security is designed to layer on top of a transport protocol (i.e. TCP) encapsulating higher level protocols, such the application protocol. An example of this would be the Remote Desktop Protocol.
TLS has 3 specifications: 1.0, 1.1, 1.2 with 1.3 in draft as of July 2017.
- TLS 1.0 was defined in 1999 by RFC 2246 and was an upgrade to SSL 3.0 with small but significant enough changes that they do not interoperate.
- TLS 1.1 was defined in 2006 by RFC 4346 providing some small security improvements.
- TLS 1.2 was defined in 2008 by RFC 5246 updating the previous specification to include things such as more secure hash algorithms like SHA-256 and advanced capabilities like elliptical curve cryptography (ECC).
TLS itself is composed of two layers: TLS Record Protocol and the TLS Handshake Protocol:
- The TLS Record Protocol is responsible for things like dividing and reassembling messages into manageable blocks, compressing and decompressing blocks, applying Message Authentication Code, and encrypting and decrypting messages. This is accomplished leveraging the keys created during the handshake.
- The TLS Handshake Protocol is responsible for the Cipher Suite negotiation between peers, authentication of the server and optionally the client, and the key exchange.
You can read more on the TLS protocol at https://msdn.microsoft.com/en-us/library/windows/desktop/aa380516(v=vs.85).aspx
SSL is the predecessor to TLS and works quite similarly. The main difference is where the encryption takes place. TLS encrypts the protocol (implicitly), while SSL encrypts the port (explicitly). For example 443 for HTTPS.
SSL also came in 3 varieties: 1.0, 2.0, 3.0.
- SSL 1.0 was first developed by Netscape but was never made public due to security flaws.
- SSL 2.0 was also quickly replaced due to multiple vulnerabilities by SSL 3.0 and was prohibited in 2011 by RFC 6176.
- In 2014 SSL 3.0 was found to be vulnerable to the POODLE attack and prohibited in 2015 by RFC 7568.
Well, that was exhausting! Let’s move on to Key Exchanges.
Just like the name implies, this is the exchange of the keys used in our encrypted communication. As an example, when a symmetric key block cipher is used to encrypt data, both parties must have the same shared key to encrypt/decrypt the message. For obvious reasons, we do not want this to be shared out in plaintext, so a key exchange algorithm is used as a way to secure the communication to share the key.
Diffie-Hellman does not rely on encryption and decryption rather a mathematical function that allows both parties to generate a shared secret key. This is accomplished by each party agreeing on a public value and a large prime number. Then each party chooses a secret value used to derive the public key that was used.
Elliptic-curve Diffie-Hellman (ECDH) is a variant of the Diffie-Hellman leveraging elliptic-curve cryptography. Both ECDH and its predecessor leverage mathematical computations however elliptic-curve cryptography (ECC) leverages algebraic curves whereas Diffie-Hellman leverages modular arithmetic.
Public-Key Cryptography Standards (PKCS) includes encryption mechanisms such as RSA. In an RSA key exchange, secret keys are exchanged by encrypting the secret key with the intended recipients public key. The only way to decrypt the secret key is by leveraging the recipients private key.
Ciphers have existed for thousands of years. In simple terms they are a series of instructions for encrypting or decrypting a message.
We could spend an extraordinary amount of time talking about the different types of ciphers, whether symmetric key or asymmetric key, stream ciphers or block ciphers, or how the key is derived, however I just want to focus on what they are and how they relate to Schannel.
DES, 3DES, RC2, and AES are all symmetric key block ciphers. Symmetric key means that the same key is used for encryption and decryption. This requires both the sender and receiver to have the same shared key prior to communicating with one another, and that key must remain secret from everyone else. The use of block ciphers encrypts fixed sized blocks of data.
The denotation of 56-bit, 128-bit, etc. indicates the key size of the cipher.
RC4 is a symmetric key stream cipher. As noted above, this means that the same key is used for encryption and decryption. The main difference to notice here is the user of a stream cipher instead of a block cipher. In a stream cipher, data is transmitted in a continuous steam using plain-text combined with a keystream.
Hashing Algorithms, are fixed sized blocks representing data of arbitrary size. They are used to verify the integrity of the data of the data being transmitted.
When the message is created a hash of the original message is generated using the agreed upon algorithm (i.e. MD5, SHA, SHA256, SHA384, SHA512). That hash is used by the receiver to ensure that the data is the same as when the sender sent it. We won’t get into the mechanisms of each of these in this post; just a brief overview.
MD5 produces a 128-bit hash value. For example, if you were to use an input “I Love cryptography”, the generated hash value would be “733a3430b260001f9b0546ad381bbbd0“.
SHA (SHA-1) produces 160-bit hash value. The same input leveraging SHA would produce a hash value of “bd1d09e1dde1a6434afa190b5dd301b0fe7da26a”. Notice the length difference?
NOTE: Both hash algorithms have been found to be vulnerable to attacks such as collision vulnerabilities and are typically not recommended for use in cryptography.
SHA-2 is a set of cryptographic hash functions and is the successor to SHA-1. There are 6 functions in total: SHA-224, SHA-256, SHA-384, and SHA-512. Each of these are indicative of the bit size used, for example, leveraging our previous input of “I Love cryptography” and SHA-256 we get a hash value of “a886b5b89f9039f9f2986133e0abc2aec35194a25799b51b249cefad80ce8fab”. Again, see the noticeable size difference?
Putting this all together
Now that everything is explained; what does this mean? Well to reference Nathan’s article let’s break down the cipher suite one piece at a time:
TLS indicates that the TLS will be used to establish a secure communication. Remember that a protocol simply defines how the algorithms should be used.
ECDHE indicates that the Elliptic-Curve Diffie-Hellman will be leveraged for key exchange. This is a where the keys will be exchanged that are leveraged for encrypting and decrypting our message traffic.
ECDSA Wait…. what? This wasn’t talked about previously. This is the algorithm, in this instance the Elliptic-Curve Digital Signature Algorithm, used to create the digital signature for authentication.
AES_256 indicates that AES encryption with 256-bit key size will be leveraged to encrypt the message.
GCM Again…… what? This is the mode of operation that the cipher leverages. In this case Galois Counter Mode (GCM). The purpose is to mask the patterns within the encrypted data.
SHA384 indicates that the hashing algorithm used for message verification and in this example is SHA2 with a 384-bit key.
Hopefully this helps to further break down the barriers of understanding encryption and cipher suites.
For more information about cryptography check out Cryptography Essentials: