{"id":216,"date":"2020-03-20T22:07:04","date_gmt":"2020-03-20T21:07:04","guid":{"rendered":"https:\/\/blog.remyblom.nl\/?p=216"},"modified":"2020-11-17T10:20:57","modified_gmt":"2020-11-17T09:20:57","slug":"article-archive-patrick-nohe-cipher-suites","status":"publish","type":"post","link":"https:\/\/blog.remyblom.nl\/?p=216","title":{"rendered":"Article Archive: Patrick Nohe &#8211; Cipher Suites"},"content":{"rendered":"\n<p>Every once and a while you run into an article on the internet that\u2019s\n just too good to just make a bookmark (or some similar technique that \nallows you to store the URL to that previous piece of useful \ninformation). I have been on the internet long enough to know that no \nmatter how good an article might be, just wait long enough and it will \nbe gone, some day\u2026 So I decided to store these kinds of articles right \nhere, on my own website, in what I call the <strong>Article Archive<\/strong>.<\/p>\n\n\n\n<p>At my work, one of the things I do is install certificates on webservers, no big deal, but I tend to want to understand what I&#8217;m doing, what certificates are doing, how TLS is making the connection to my bank <strong>secure<\/strong>. And I don&#8217;t settle for &#8220;by using cryptography&#8221;. Patrick Nohe wrote this wonderfully complete breakdown of what a cipher suite actually is and what new things TLSv1.3 is bringing us. Let&#8217;s dive in!<\/p>\n\n\n\n<p>Original: <a href=\"https:\/\/www.thesslstore.com\/blog\/cipher-suites-algorithms-security-settings\/\" target=\"_blank\" rel=\"noreferrer noopener\" aria-label=\"https:\/\/www.thesslstore.com\/blog\/cipher-suites-algorithms-security-settings\/ (opens in a new tab)\">https:\/\/www.thesslstore.com\/blog\/cipher-suites-algorithms-security-settings\/<\/a><\/p>\n\n\n\n<h1 class=\"wp-block-heading\">Cipher Suites: Ciphers, Algorithms and Negotiating Security Settings<\/h1>\n\n\n\n<h2 class=\"wp-block-heading\">SSL\/TLS Cipher suites determine the parameters of an HTTPS connection. And\nthey\u2019ve just undergone a facelift.<\/h2>\n\n\n\n<p>If you interact with SSL\/TLS and HTTPS encryption long\nenough, you\u2019re eventually going to come across the term \u201ccipher suite.\u201d And\nwhile that sounds like a fancy nickname for Alan Turing\u2019s hotel room, cipher\nsuites play a critical role in every HTTPS connection you make on the internet.<\/p>\n\n\n\n<p>So, what are encryption ciphers? And what are cipher suites?<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/05\/Cipher-Suite-3-300x265.png\" alt=\"What is a cipher suite?\" class=\"wp-image-10647\"\/><\/figure>\n\n\n\n<p>Ciphers are algorithms, more specifically they\u2019re a set of\nsteps for performing a cryptographic function \u2013 it can be encryption, decryption,\nhashing or digital signatures. Nowadays ciphers are dependent upon the advanced\nprocessing capabilities of computers. That hasn\u2019t always been the case though.\nOne of the first, well-known historical ciphers belonged to Caesar \u2013 the very\nfirst emperor of Rome and purveyor of fancy appetizer salads \u2013 who used it to\ncommunicate with his generals during military operations.<\/p>\n\n\n\n<p>Over the years, ciphers have become more complex, but the\nlogic behind them has stayed the same. Whether it was Caesar crossing the\nRubicon, the infamous Enigma cipher of World War II or some of the algorithms\nof today\u2014the idea has always been to encode or encipher a message in such a way\nthat only the intended party can read it. <\/p>\n\n\n\n<p>Today we\u2019re going to discuss SSL\/TLS Cipher Suites \u2013 groups\nof ciphers that help secure an HTTPS connection \u2013 then go over their various\nparts and finish by looking at what\u2019s changed between TLS 1.2 and TLS 1.3.<\/p>\n\n\n\n<p>Let\u2019s hash it out.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Cipher Suites \u2013 Some Background<\/h2>\n\n\n\n<p>As we just covered, a cipher is really just an algorithm, or\na set of steps that are used to perform a specific mathematical function \u2013 be that\nencryption, hashing or digital signatures. Ciphers have always had a basis in\nmath, even Caesar\u2019s primitive shift cipher required counting forward a designated\nnumber of spaces in the alphabet to encrypt something. <\/p>\n\n\n\n<p>I\u2019m going to use Caesar\u2019s cipher to explain some basic\nconcepts that will be useful later when we get into modern cipher suites. The\npiece of data or information \u2013 it\u2019s all digital now, though historically there\u2019s\ntypically been some kind of ink and paper\/parchment involved. Anyway, that original\nunencrypted piece of data would be referred to as the plaintext, as it\u2019s easily\nreadable in its raw form. After the encryption process has been performed, it\nbecomes a piece of ciphertext and should ideally be unreadable to anyone\nwithout the private key.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Keys vs. Algorithms<\/h3>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/05\/Maths-300x300.png\" alt=\"\" class=\"wp-image-10670\"\/><\/figure>\n\n\n\n<p>Encryption is performed by keys, but it\u2019s important to square\nhow keys and algorithms\/ciphers fit together. <\/p>\n\n\n\n<p>The algorithm or cipher used is just that, it\u2019s a sequence\nof steps that must be used to encrypt the plaintext. <\/p>\n\n\n\n<p>Depending on the cryptosytem, either the values within that\nalgorithm, or the value the algorithm arrives at itself, are the keys. <\/p>\n\n\n\n<p>We\u2019ll clarify that point in a minute, just think of it this\nway: the algorithms are the general principles\/rules used by a given cryptosystem,\nthe keys are what actually performs the function. <\/p>\n\n\n\n<h3 class=\"wp-block-heading\">It\u2019s just Math<\/h3>\n\n\n\n<p>Sometimes it\u2019s best to illustrate with an example so let\u2019s go\nback to Caesar\u2019s cipher and illustrate. In Caesar\u2019s cipher, the actual\nalgorithm is: <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/Caesar-algorithm.png\" alt=\"caesar cipher formula\" class=\"wp-image-10646\"\/><\/figure>\n\n\n\n<p>Ok, now let\u2019s take a closer look at each component. <\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"\"><tbody><tr><td><strong>Variable<\/strong>   <\/td><td><strong>Description <\/strong>  <\/td><\/tr><tr><td>   <strong>x<\/strong>   <\/td><td>x represents the raw input, in this case x refers to whatever letter we\u2019re shifting   <\/td><\/tr><tr><td>   <strong>e(x) <\/strong>  <\/td><td>e(x) represents the encrypted value   <\/td><\/tr><tr><td>   <strong>k<\/strong>   <\/td><td>k represents the key   <\/td><\/tr><tr><td>   <strong>mod<\/strong>   <\/td><td>mod represents the modulus   <\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>In Caesar\u2019s cipher, the key is simply the number of spaces\nyou decide to shift the letters. So, in the example below the key would be 3.\nWe\u2019re shifting everything three spaces forward. <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/Caesar-in-Action.png\" alt=\"Caesar cipher at work\" class=\"wp-image-10645\"\/><\/figure>\n\n\n\n<p>Now let\u2019s add in the modulus. Modular arithmetic wraps\naround after it reaches the modulus, which is basically the end of the line,\nthe number cap \u2013 however you want to think about it. With the alphabet, the\nmodulus is obviously 26. There are 26 letters, so if you want to move a \u201cY\u201d\nthree spaces forward you have to wrap around and start back at 1 (or A) again.\nSo in this instance, the equation would be B = (Y + 3)(mod 26).<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/Caesar-Reacharound.png\" alt=\"Reacharound from Z to A\" class=\"wp-image-10644\"\/><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Modern Ciphers &amp; Cipher Suites<\/h2>\n\n\n\n<p>It\u2019s no different at the digital level. The math is far more\ncomplicated now \u2013 no human could do it efficiently \u2013 but the concept is still\nthe same. It\u2019s all just math. Now let\u2019s apply what we learned about algorithms\nin general to SSL\/TLS and HTTPS connections. <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/Cipher-Suite-Computer-300x300.png\" alt=\"Modern Cipher Suites\" class=\"wp-image-10657\"\/><\/figure>\n\n\n\n<p>An HTTPS connection is actually a fairly complicated\nprocess. Last week we took a deep dive on the TLS handshake. This is the process\nwhere a client and server agree on a mutually support cipher suite and then use\nthe chosen cipher suite to negotiate a secure connection. <\/p>\n\n\n\n<p>Part of what makes the handshake so complicated is that it\nleverages several different cryptographic functions to achieve the HTTPS connection.\nDuring the handshake, the client and server will use:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>A key exchange algorithm<\/li><li>A bulk encryption cipher<\/li><li>A digital signature scheme<\/li><li>A Hash\/MAC function<\/li><\/ul>\n\n\n\n<p>These ciphers all work together at various points to perform\nauthentication, key generation and exchange and a check-sum to ensure integrity.\n<\/p>\n\n\n\n<p>In order to determine what specific algorithms to use, the\nclient and server start by deciding on a cipher suite to use. Cipher suites are\ncollections of these algorithms that can work together to perform the handshake\nand the encryption\/decryption that follows. At the outset of the connection\nboth parties share a list of supported cipher suites and then decide on the\nmost secure, mutually supported suite. <\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>The math is more complicated now\u2026 but the underlying concepts are still the same. It\u2019s all just math.<\/p><\/blockquote>\n\n\n\n<p>There are 37 TLS 1.2 ciphers and five TLS 1.3 ciphers. Understanding\ntheir different parts is key to understanding HTTPS connections and SSL\/TLS itself.\nLet\u2019s start with an overview of TLS 1.2 \u2013 as it\u2019s still the more common version\nof the protocol \u2013 and then we\u2019ll talk about what\u2019s improved in TLS 1.3.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What is a TLS 1.2 Cipher Suite?<\/h2>\n\n\n\n<p>As we covered in the last section, a Cipher Suite is a\ncombination of algorithms used to negotiate security settings during the\nSSL\/TLS handshake. When the ClientHello and ServerHello messages are exchanged\nthe client sends a prioritized list of cipher suites it supports. The server\nthen responds with the cipher suite it has selected from the list.<\/p>\n\n\n\n<p>Cipher suites are named combinations of:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Key Exchange Algorithms (RSA, DH, ECDH, DHE,\nECDHE, PSK)<\/li><li>Authentication\/Digital Signature Algorithm (RSA,\nECDSA, DSA)<\/li><li>Bulk Encryption Algorithms (AES, CHACHA20, Camellia,\nARIA)<\/li><li>Message Authentication Code Algorithms (SHA-256,\nPOLY1305)<\/li><\/ul>\n\n\n\n<p>So, for instance, here\u2019s an example of a cipher suite:<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/04\/TLS-1.2-Cipher-Suite.png\" alt=\"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256\" class=\"wp-image-10324\"\/><\/figure>\n\n\n\n<p>I\u2019ve color-coated it to help you distinguish between the\nciphers.<\/p>\n\n\n\n<p>TLS is the protocol. Starting with ECDHE we can see that\nduring the handshake the keys will be exchanged via ephemeral Elliptic Curve\nDiffie Hellman (ECDHE). RSA is the authentication algorithm. AES_128_GCM is the\nbulk encryption algorithm: AES running Galois Counter Mode with 128-bit key\nsize. Finally, SHA-256 is the hashing algorithm.<\/p>\n\n\n\n<p>By the end of this article all of that will make sense. <\/p>\n\n\n\n<p>During the TLS 1.2 handshake it\u2019s going to play out like\nthis:<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>Client and Server determine a mutually supported\ncipher suite<\/li><li>Server sends its certificate and public key<\/li><li>Client authenticates the certificate &amp; digital\nsignature<\/li><li>Key exchange functions are performed to generate\nsymmetric session keys<\/li><li>Encryption begins; HMAC is used to ensure the\nhandshake wasn\u2019t tampered with<\/li><\/ol>\n\n\n\n<p>Obviously, that\u2019s incredibly condensed, if you\u2019re interested\ncheck out the full TLS Handshake article, but hopefully you can see where each cipher\/algorithm\ncomes into the picture. <\/p>\n\n\n\n<p>\n\t\t\t<a href=\"https:\/\/www.thesslstore.com\/blog\/explaining-ssl-handshake\/\">Taking a Closer Look at the SSL\/TLS Handshake<\/a>\n\t\t<\/p>\n\n\n\n<p>\n\t\t\t<em>\n\t\t\t\t\t\t\t\t\t In Everything Encryption \n\t\t\t\t\t\t\t\t\t\t\t\t\t By Patrick Nohe \n\t\t\t\t\t\t\t<\/em>\n\t\t<\/p>\n\n\n\n<p>There\u2019s a lot going on underneath the hood when you connect \nto a website via HTTPS. First and foremost, everyone needs to\u2026 shake \nhands?!<\/p>\n\n\n\n<p>\n\t\t\t<a href=\"https:\/\/www.thesslstore.com\/blog\/explaining-ssl-handshake\/\">\n\t\t\t\tRead more\t\t\t<\/a>\n\t\t<\/p>\n\n\n\n<p>Unfortunately, TLS 1.2 has 37 different cipher suites to\nchoose from and not all of them are still considered secure. You may be\nwondering how you wind up with nearly 40 different cipher suites. It\u2019s\ntwo-fold. For one, TLS 1.2 has been around about 10 years, meaning there\u2019s been\nplenty of times for new algorithms to arrive and old ones to phase out. And as\nthat happens, the IANA, the Internet Assigned Numbers Authority, the\norganization that administers all of this, has to keep creating new combinations\nof ciphers \u2013 new cipher suites \u2013 owing to the fact that four different algorithms\nare required and there are myriad possible combinations. <\/p>\n\n\n\n<p>Of course, not all of the algorithms play nice together, but\nenough do that there are 37 approved TLS 1.2 cipher suites in use today. <\/p>\n\n\n\n<p>Let\u2019s dive a little deeper into the four different\ncomponents of the TLS 1.2 cipher suite. But first let\u2019s talk a little bit about\nthe two different kinds of encryption that you see in SSL\/TLS.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Two Kinds of Encryption<\/h2>\n\n\n\n<p>One of the biggest points of confusion when it comes to SSL\/TLS centers around the <a href=\"https:\/\/www.thesslstore.com\/blog\/difference-encryption-hashing-salting\/\">types of encryption<\/a>\n that are used. That has to do with how SSL certificates are advertised.\n And this really shouldn\u2019t come as too much of a surprise given the fact\n the industry has never taken the time to correct everyone on the fact \nthat we\u2019re now using TLS certificates. <\/p>\n\n\n\n<p>The 2048-bit key associated with your SSL certificate is\nused to help negotiate the HTTPS connection, but its role is actually a lot narrower\nthan most people are led to believe. And 2048-bit keys are far from the only\noption when it comes to public key cryptosystems. ECDSA uses much smaller keys\nto accomplish a similar function. <\/p>\n\n\n\n<p>We just seem to be fixated on the 2048-bit private key because it sounds more impressive. And we can trot out the, \u201c<em>it would take over a quadrillion years for a modern computer to crack this key and we\u2019ll all already be dead by then!<\/em>\u201d <\/p>\n\n\n\n<p>But, arguably, the bulk cipher and the symmetric key you end\nup using DURING the connection are equally, if not more important than the\npublic\/private key pair. <\/p>\n\n\n\n<p>Symmetric encryption involves two keys that are the same, or\nas the name quite cleverly implies, are symmetric. Both keys can perform both\nfunctions: encryption and decryption. This is the type of encryption that you\u2019re\nactually using to communicate with the site you\u2019re visiting. <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/Asymmetric-vs-Symmetric.png\" alt=\"Two different encryption types\" class=\"wp-image-10668\"\/><\/figure>\n\n\n\n<p>Conversely, with asymmetric encryption, you are talking\nabout different keys with different abilities. When encryption is asymmetric,\none key encrypts and the other key decrypts. Asymmetric encryption, which\ntypically takes the form of RSA with TLS 1.2, is responsible for verifying\ndigital signatures and, when RSA key exchange is in use, it\u2019s for encrypting the\npre-master secret that will be used to derive the symmetric session key. But\nRSA is not the only key exchange mechanism in use, so 2048-bit keys are\nactually kind of an odd thing to advertise. <\/p>\n\n\n\n<p>Symmetric encryption keys, which are typically AES or Advanced \nEncryption Standard, range from 128-bit to 256-bit in key size. And this\n is completely efficient and secure for symmetric encryption, where \ncomputational hardness needs to go hand-in-hand with \nusability\/performance. <\/p>\n\n\n\n<p>\n\t\t\t<a href=\"https:\/\/www.thesslstore.com\/blog\/what-is-256-bit-encryption\/\">How strong is 256-bit Encryption?<\/a>\n\t\t<\/p>\n\n\n\n<p>\n\t\t\t<em>\n\t\t\t\t\t\t\t\t\t In Everything Encryption \n\t\t\t\t\t\t\t\t\t\t\t\t\t By Patrick Nohe \n\t\t\t\t\t\t\t<\/em>\n\t\t<\/p>\n\n\n\n<p>256-bit encryption strength gets tossed around all the time, \nbut most people have no idea what 256 bits of security means or how \nstrong it actually is. Let\u2019s hash it out.<\/p>\n\n\n\n<p>\n\t\t\t<a href=\"https:\/\/www.thesslstore.com\/blog\/what-is-256-bit-encryption\/\">\n\t\t\t\tRead more\t\t\t<\/a>\n\t\t<\/p>\n\n\n\n<p>Those 2048-bit asymmetric RSA keys are expensive to compute with, and\n add latency to handshakes. They\u2019re also vulnerable to padding attacks \nin some implementations. <\/p>\n\n\n\n<p>Long story short, both asymmetric encryption and symmetric\nencryption are represented here, but the symmetric encryption is more relevant in\nthe context of cipher suites. <\/p>\n\n\n\n<p>Now let\u2019s look at the four different components of a cipher\nsuite. <\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Key Exchange<\/h2>\n\n\n\n<p>The first spot in the TLS 1.2 cipher suite is designated for the key exchange mechanism that will be used. <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/05\/1.2-first-cipher.png\" alt=\"\" class=\"wp-image-10672\"\/><\/figure>\n\n\n\n<p>Key exchange refers to the actual process that\u2019s used to transmit \nthose symmetric session keys (or the key shares they\u2019re derived from), \nbut it\u2019s not the only algorithm used in the generation process. That\u2019s \nconfusing, I know. The key exchange portion of the handshake determines \nthe parameters for the key generation, but the hashing algorithm also \nplays a role in generating keys by providing <a href=\"https:\/\/www.thesslstore.com\/blog\/why-all-the-fuss-about-64-bit-serial-numbers\/\">Pseudo-Random Functions<\/a> (PRFs), typically as a cryptographically secure pseudo-random number generator (CSPRNG).<\/p>\n\n\n\n<p>The important thing to take away is that the key exchange mechanism \nthat\u2019s chosen isn\u2019t solely responsible for generating the actual key.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">RSA<\/h3>\n\n\n\n<p>RSA is named after the gentlemen that created it: Rivest, Shamir and Adleman. <a href=\"https:\/\/www.thesslstore.com\/blog\/public-key-cryptography-key-exchange\/\">This is the most common asymmetric cryptosystem<\/a>.\n It uses exponentiation of prime numbers and has a wide range of \napplications. With SSL\/TLS you commonly see RSA used in the context of \nkey exchange. Again, this is where all those 2048-bit (and 3072- and \n4096-bit) keys come from. <\/p>\n\n\n\n<p>Every handshake, regardless of whether or not RSA is chosen, <a href=\"https:\/\/www.thesslstore.com\/blog\/explaining-ssl-handshake\/\">begins with a Client and Server Hello<\/a> where they exchanged randoms, a client random and a server random.<\/p>\n\n\n\n<p>The way RSA operates is fairly simple, once the client and\nserver decide to use a cipher suite that includes RSA key exchange \u2013 and after the\nclient has authenticated the server: <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/04\/RSA-Key-Exchange-1024x233.png\" alt=\"\" class=\"wp-image-10532\"\/><\/figure>\n\n\n\n<ol class=\"wp-block-list\"><li>The client uses the public key that the server sent over to encrypt a pre-master secret and transmit it. <\/li><li>The server uses its private key to decrypt the pre-master secret. <\/li><li>Both parties use PRFs, the client random, the server random and the pre-master secret to derive the master secret. <\/li><li>Both parties use the master secret and more pseudo-random functions to calculate the session key. <\/li><\/ol>\n\n\n\n<p>It\u2019s during those last two steps, 3 &amp; 4, when mixing the\nmaster secret and deriving the session key, where the hashing algorithm\u2019s pseudo-random\nfunctions are leveraged. <\/p>\n\n\n\n<p>RSA key exchange has been useful for a long time, but it\u2019s\nat the end of its life. TLS 1.3 has done away with RSA key exchange \u2013 in\naddition to all other static key exchange mechanisms \u2013 because of known vulnerabilities.\n<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Diffie-Hellman &amp; Elliptic Curve Diffie-Hellman<\/h3>\n\n\n\n<p>Named after Whitfield Diffie and Martin Hellman, this is a\nkey exchange protocol, it\u2019s NOT an asymmetric encryption protocol in the same\nvein as RSA though. The problem that Diffie and Hellman (using work inspired by\nRalph Merkle) set out to solve was how to exchange a secure key over an\nunsecure network with an attacker watching.<\/p>\n\n\n\n<p>What they came up with was Diffie-Hellman key exchange,\nwhich was eventually succeeded by RSA, but has now re-taken the advantage. <\/p>\n\n\n\n<p>Diffie-Hellman key exchange works like this:<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/04\/Diffie-Hellman-Key-Share-1024x239.png\" alt=\"Diffie Hellman key exchange\" class=\"wp-image-10533\"\/><\/figure>\n\n\n\n<ol class=\"wp-block-list\"><li>After exchanging randoms (g &amp; p), both the\nclient and server select their own pre-master secret (a &amp; b, respectively)\nand compute a similar equation \u2013 <strong>g<sup>a<\/sup><\/strong> <em>mod<\/em> <strong>p = A<\/strong>, &amp; <strong>g<sup>b<\/sup><\/strong>\n<em>mod<\/em> <strong>p = B.<\/strong><\/li><li>The value each arrived at (A &amp; B) is sent to\nthe other, and both parties repeat the same operation \u2013 B<sup>a<\/sup> <em>mod<\/em> p,\n&amp; A<sup>b<\/sup> <em>mod<\/em> p.<\/li><\/ol>\n\n\n\n<p>Each party provides what is called a \u201ckey share,\u201d and they\neach arrive independently at the shared session key. There is a rule of modular\nexponentiation that dictates this. <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/05\/Modulo-Rule.png\" alt=\"(ga mod p)b mod p = gab mod p\n(gb mod p)a mod p = gba mod p\" class=\"wp-image-10669\"\/><\/figure>\n\n\n\n<p>If that was a lot of math, the key takeaway is that: with\nDiffie-Hellman no asymmetric encryption actually takes place during the key\nexchange, rather the two parties mutually arrive at values that can be used to\nderive the session key. <\/p>\n\n\n\n<p>Now let\u2019s talk about Elliptic Curve Diffie-Hellman, which is \nbasically just a modern-day iteration of Diffie-Hellman undergirded by <a href=\"https:\/\/www.thesslstore.com\/blog\/you-should-be-using-ecc-for-your-ssl-tls-certificates\/\">elliptic curve cryptography<\/a>\n as opposed to some other cryptosystem. Basically, it uses points \nplotted on an elliptic curve as the basis for its calculations.<\/p>\n\n\n\n<p>There are a couple of things to keep in mind with Diffie-Hellman,\nfirst of all \u2013 it lacks a true authentication mechanism when being used ephemerally.\nEphemeral keys are temporary and usually not authenticated. <\/p>\n\n\n\n<p>Second, as we just mentioned, <a href=\"https:\/\/www.thesslstore.com\/blog\/tls-1-3-approved\/\">in TLS 1.3 all static key generation\/exchange mechanisms were deprecated<\/a>.\n That\u2019s what basically killed RSA, and it also does away with DH schemes\n that aren\u2019t ephemeral, too. ECDHE or Elliptic Curve Diffie-Hellman \nEphemeral is now the standard for key exchange.<\/p>\n\n\n\n<p>That\u2019s because Perfect Forward Secrecy is mandatory in TLS\n1.3. Perfect Forward Secrecy protects individual sessions from being decrypted,\neven in the event a certificate\u2019s private key is compromised. Static key exchange\nschemes couldn\u2019t support that. Ergo, they\u2019re gone. <\/p>\n\n\n\n<h3 class=\"wp-block-heading\">PSK<\/h3>\n\n\n\n<p>Typically written as TLS-PSK, this is a cipher that provides\nsecure communication based on pre-shared symmetric keys exchanged between parties\nin advance. We\u2019re not going to spend a lot of time on PSK as it\u2019s fairly rare\noutside of highly regulated network environments and we definitely wouldn\u2019t\nadvice its commercial use. It was not included in TLS 1.3.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Digital Signature\/Authentication <\/h2>\n\n\n\n<p>Here\u2019s where things start to get confusing \u2013 and you can\nalso begin to see how these cipher suites have multiple permutations. For\nexample, there are four common iterations of Diffie-Hellman:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Diffie-Hellman (DH) <em>*deprecated in TLS 1.3<\/em><\/li><li>Diffie-Hellman Ephemeral (DHE) <\/li><li>Elliptic Curve Diffie-Hellman (ECDH) <em>*deprecated in TLS 1.3<\/em><\/li><li>Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)<\/li><\/ul>\n\n\n\n<p>But none of those can handle authentication, so they have to\nbe paired with an authentication scheme \u2013 historically, that\u2019s been either DSA,\nRSA or ECDSA. <\/p>\n\n\n\n<p>RSA can function as BOTH a key exchange mechanism, as well\nas provide authentication with digital signatures. You can even use\nDiffie-Hellman and RSA together. All these combinations and we\u2019re not even halfway\nthrough the cipher suite. <\/p>\n\n\n\n<p>The Signature algorithm is the second algorithm in the TLS\n1.2 cipher suite.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/1.2-second-cipher-1.png\" alt=\"\" class=\"wp-image-10674\"\/><\/figure>\n\n\n\n<p>One more thing, you sometimes people refer to the type of\nSSL certificate on the basis of its signing algorithm. For instance, when\nsomeone says they have an RSA SSL certificate or an Elliptic Curve SSL\ncertificate, they\u2019re alluding to the signing algorithm. That\u2019s because this is\ndetermined during the generation of the CSR. Keep that in mind, because it\u2019s\npart of why TLS 1.3 cipher suites don\u2019t include the signing scheme.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">RSA Digital Signatures<\/h3>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/Digital-Signature-2-1-300x300.png\" alt=\"Digital Signatures\" class=\"wp-image-10675\"\/><\/figure>\n\n\n\n<p>Digital Signatures are one of the best ways to authenticate\nanother party. Using the digital signature, the client can verify the authenticity\nof the SSL\/TLS certificate, and in the case of cipher suites using Diffie-Hellman,\nverify ownership of the public\/private key pair. <\/p>\n\n\n\n<p>With RSA, the client (and sometimes the server if a client\nSSL certificate is in use) checks the authenticity of the certificate being\npresented by running a series of checks. It looks at the certificate chain by\nfollowing the digital signatures left by the signing CA back to one of the\nroots in its trust store. It checks the validity dates and the revocation status\nof the certificate, too. Then it uses the associated public key to verify the\nprivate key\u2019s signature. <\/p>\n\n\n\n<p>The final verification that the server is in possession of\nthe private key comes during the key exchange, when the client encrypts the\npre-master secret with the public key and the server decrypts it with private\nkey.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Elliptic Curve Digital Signature Algorithm<\/h3>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/ECDSA-300x300.jpg\" alt=\"Elliptic Curve Digital Signature Algorithm\" class=\"wp-image-10681\"\/><\/figure>\n\n\n\n<p>As we mentioned earlier, Diffie-Hellman key exchange has no\nauthentication mechanism in ephemeral mode. That means it needs to be paired\nwith an authentication mechanism. As we just covered, RSA is an option, the\nother popular method is called the Elliptic Curve Digital Signature Algorithm,\nwhich has now replaced DSA. The way ECDSA works is very similar to RSA at the\noutset, but with one major difference.<\/p>\n\n\n\n<p>Whereas both methods check the certificate the same way, when Diffie \nHellman is in use the actual key exchange portion can\u2019t be used to prove\n possession of the private key. Instead, the server takes the two \nrandoms (client and server) as well as the Diffie-Hellman parameters it \nhas chosen (its pre-master secret) and encrypts them all with its \nprivate key. This serves as its de facto digital signature. The client \nwill use the public key to verify the signature and thus, ownership of \nthe private key.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What about DSA?<\/h3>\n\n\n\n<p>The Digital Signature Algorithm, which was already on its\nway out, has been entirely removed from TLS 1.3. While there is some debate\nover how secure DSA still is, what really hamstrung it was key size. DSA uses\nkeys that are comparable in size to RSA: 1024-, 2048-, 3096-bit keys, that \u2013 as\nwe covered \u2013 are expensive to compute with. By comparison, it\u2019s Elliptic\nCurve-based counterpart, ECDSA, uses keys that are typically 224- or 256-bit. <\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Edwards-curve Digital Signature Algorithm<\/h3>\n\n\n\n<p>EdDSA is a digital signature scheme that removes the need\nfor pseudo-random number generation from the equation. We touched on PRFs\nearlier, they\u2019re typically generated using the designated hash function, but\nthey\u2019re not always actually random. In fact, the secret values that are\nproduced, which are sometimes called nonces, can leak private keys if the RNG\nis ever broken\/made predictable. <\/p>\n\n\n\n<p>Instead, EdDSA picks a nonce based on a hash of the private\nkey and the message, which means after the private key is generated there\u2019s no\nmore need for random number generators. EdDSA is one of the three digital\nsignature schemes approved for use in TLS 1.3.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Bulk Encryption Ciphers<\/h2>\n\n\n\n<p>While neither of the previous two categories are included in\nTLS 1.3 cipher suites, these next two \u2013 bulk ciphers and hashing algorithms \u2013 are\nincluded. <\/p>\n\n\n\n<p>Your bulk cipher is what will be used for the actual symmetric\nencryption that will occur during an HTTPS connection. Traditionally there are\ntwo kinds of bulk cipher: <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/Hashed-Out-Lock-Icon-300x300.jpg\" alt=\"\" class=\"wp-image-10677\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\"><li>Block ciphers<\/li><li>Stream ciphers<\/li><\/ul>\n\n\n\n<p>A block cipher, as its name might suggest, encrypts data in\nblocks of a pre-determined size. Unlike with asymmetric encryption though, this\nisn\u2019t necessarily linked to key size. A 256-bit key doesn\u2019t always create\n256-bit blocks of ciphertext. For instance, AES produces 128-bit blocks,\nregardless of key size. <\/p>\n\n\n\n<p>At any rate, after data is encrypted into blocks, it\u2019s then incumbent\nupon the recipient to decrypt the blocks and piece them back together so that\nthe information is intelligible. <\/p>\n\n\n\n<p>So, what happens if the data being encrypted isn\u2019t exactly\nthe right size? That\u2019s extremely common. It means the data needs to be segmented\ninto appropriately sized chunks, and any unfilled space needs to be padded with\nthrowaway data to make it fit, which can open attack vectors and is just,\ngenerally, inefficient.<\/p>\n\n\n\n<p>The other type of cipher is a stream cipher, which encrypts\ndata in long pseudorandom streams. When you see the cipher written out, the\nbulk cipher is the third algorithm listed and it typically includes a modifier\nthat dictates how the bulk cipher should be run. <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/05\/1.2-third-cipher.png\" alt=\"\" class=\"wp-image-10676\"\/><\/figure>\n\n\n\n<p>For instance, in the example above we\u2019re running AES or Advanced\nEncryption Standard, running in GCM or Galois Counter Mode, using 256-bit keys.\nAES is, by design, a block cipher. But it can be run as a stream cipher in\ncounter mode. <\/p>\n\n\n\n<p>We\u2019ll get to it in a second, but in TLS 1.3, the bulk cipher\nis now expected to be an AEAD or Authenticated Encryption with Associated Data\nalgorithm, meaning that it can not only encrypt the communication but also authenticate\nit. Originally these two functions had been performed separately, but issues\nwith errors, and just difficulty implementing it correctly in general, motivated\nthe IETF to combine the two functions in TLS 1.3.<\/p>\n\n\n\n<p>We\u2019ll get into the authentication portion of the AEAD when\nwe discuss hashing algorithms in the next section.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">AES<\/h3>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/Cipher-Evolution-1-300x300.png\" alt=\"Rounds of encryption\" class=\"wp-image-10660\"\/><\/figure>\n\n\n\n<p>Advanced Encryption Standard, a.k.a. Rijndael, is a NIST-approved\nencryption cipher with a block size of 128 bits, and symmetric keys with\nlengths of either 128, 192 or 256 bits. It\u2019s actually the first and only\npublicly available cipher that\u2019s approved by the NSA to encrypt \u201cTop Secret\u201d\ndata. AES was the successor to the Data Encryption Standard, which was first\npublished in 1977. <\/p>\n\n\n\n<p>AES works in an interesting way. It operates on 4 x 4 arrays\nof bites called a \u201cstate.\u201d As we just said, AES is naturally a block cipher and\nits blocks are 128 bits. It\u2019s key sizes actually refer to the number of \u201crounds\u201d\nthat the plaintext will be put through as it\u2019s encrypted. <\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>128-bit key = 10 Rounds<\/li><li>192-bit key = 12 Rounds<\/li><li>256-bit key = 14 Rounds<\/li><\/ul>\n\n\n\n<p>Each round the plaintext undergoes includes substitutions from\na lookup table, rows shifted cyclically and a linear mixing operation that\ncombines the four bytes in each column. For decryption a set of reverse rounds\nis used. <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/05\/AES-ShiftRows.png\" alt=\"\" class=\"wp-image-10678\"\/><\/figure>\n\n\n\n<p>AES is the most commonly supported bulk cipher in TLS 1.2\n&amp; TLS 1.3 cipher suites. When run in Galois Counter Mode and CCM (Counter\nwith CBC_MAC) mode, AES functions as a stream cipher with message authentication\ncapabilities (an AEAD). <\/p>\n\n\n\n<p>CBC just means that AES is being run in block cipher mode. I\nrealize that may be confusing because we just discussed how block ciphers aren\u2019t\nsupported by TLS 1.3. With CCM, the counter mode means you\u2019re running the\ncipher in stream mode, the CBC_MAC portion is for the message authentication\npart of the AEAD.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">CHACHA20_POLY1305<\/h3>\n\n\n\n<p>CHACHA20_POLY1305 is a relatively new option for SSL\/TLS,\nhaving been finalized in 2015. It\u2019s a stream cipher that works alongside\nPOLY1305, which works as an authenticator to accomplish AEAD. CHACHA is much\nfaster than AES in software-only implementations. It\u2019s about 3 times faster on\nplatforms that don\u2019t have specialized AES hardware. Both CHACHA and POLY1305\nare considered easy to implement and provide excellent performance. <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/Cipher-Settings-1-300x300.png\" alt=\"\" class=\"wp-image-10663\"\/><\/figure>\n\n\n\n<p>CHACHA20_POLY1305 uses a 256-bit key and a 96-bit nonce.\nDuring the encryption\/authentication process, a one-time POLY1305 key is\ngenerated from the 256-bit key and the nonce. CHACHA20 then performs its\nencryption, using the same key and nonce. Finally, POLY1305 authenticates the\nmessage. The output is a piece of ciphertext the same length as the plaintext\nthat was input, as well as a 128-bit MAC tag.<\/p>\n\n\n\n<p>POLY1305 can also be used as a hashing algorithm on its own.\n<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Other Bulk Ciphers<\/h3>\n\n\n\n<p>Here are some ill-advised SSL ciphers from handshakes past.<\/p>\n\n\n\n<h5 class=\"wp-block-heading\">DES\/Triple DES<\/h5>\n\n\n\n<p>The Data Encryption Standard, originally nicknamed Lucifer, was\nthe first publicly available civilian block cipher. The version of DES we know\ntoday is a revised version of the original. DES is more notable for what it\ninspired than what it actually does. It\u2019s encryption, by today\u2019s standards, is\nfairly pedestrian with block sizes of 64 bits and a key size of 56 bits. Those\nkey sizes were already considered worrisome as early as the 1970s, but by 1998\nthe EFF had demonstrated a special-purpose machine designed just to break DES\nand that was pretty much the final nail in its coffin.<\/p>\n\n\n\n<p>Triple DES is an extension of DES that triple-encrypts each\nblock with either two or three different keys. This still is sufficient for\nmany regulatory bodies though. NIST, for instance, only allows Triple DES in\nits three-key version. And even at that, 3DES only provides 112 bits of\nsecurity.<\/p>\n\n\n\n<h5 class=\"wp-block-heading\">RC4<\/h5>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/Cipher-Configuration-1-300x300.png\" alt=\"\" class=\"wp-image-10658\"\/><\/figure>\n\n\n\n<p>Ron\u2019s Code 4 or Rivest Cipher 4 \u2013 it\u2019s known by both names \u2013\ninvented by RSA\u2019s Ron Rivest, is impressive for its speed and simplicity. It is\nno longer, however, impressive for its security, which has been shown to be\nwanting across multiple vulnerabilities. Originally a trade secret, it was\nleaked in September 1994 to a mailing list and then cracked within days. <\/p>\n\n\n\n<p>Though it was originally recommended as a workaround for the\nBEAST attacks back in 2011, by 2013 new attacks demonstrated that it would be feasible\nto break RC4-encrypted TLS. Improvements to the attacks in 2015 made it even more\nviable and within months RC4 had been deprecated. RC4 has two successors in RC5\n&amp; RC6, neither is acceptable for TLS 1.3.<\/p>\n\n\n\n<h5 class=\"wp-block-heading\">Camellia<\/h5>\n\n\n\n<p>A symmetric key block cipher with similar capabilities and\nkey sizes to AES. It was developed in Japan by NTT and Mitsubishi and is\napproved by the ISO\/IEC, EU and the Japanese CRYPTREC project. As of now, in\nits full implementation Camellia has not been broke. While there were Camellia\nTLS 1.2 cipher suites, it\u2019s not included in TLS 1.3.<\/p>\n\n\n\n<h5 class=\"wp-block-heading\">ARIA<\/h5>\n\n\n\n<p>Another block cipher that is similar to AES, ARIA was\ndeveloped by a group of researchers in South Korea in 2003. Like AES, its key\nsizes refer to the number of rounds that occur during encryption. Like\nCamellia, it is also not included in TLS 1.3.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Data Integrity\/Authentication<\/h2>\n\n\n\n<p>Not to be confused with server\/client authentication, the\nhashing algorithm that has traditionally been associated with SSL\/TLS has historically\nhandled message authentication and pseudo-random functions. As we\u2019ll discuss in\njust a moment, that\u2019s been rethought for TLS 1.3, with HKMF or HMAC-based key\nderivation function. <\/p>\n\n\n\n<p>Let\u2019s start with TLS 1.2 and the Hash-Based Message Authentication \nCode which has traditionally appeared as the fourth algorithm in the \ncipher suite.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/05\/1.2-fourth-cipher.png\" alt=\"\" class=\"wp-image-10679\"\/><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Hash-Based Message Authentication Code (HMAC)<\/h3>\n\n\n\n<p>This is a type of message authentication that uses\ncryptographic hashes to both authenticate a message and ensure data integrity.\nHistorically this has been done by two main cipher families: MD5 and SHA. <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/Cipher-Book-1-300x300.png\" alt=\"HMAC\" class=\"wp-image-10662\"\/><\/figure>\n\n\n\n<p>MD5 is totally outmoded now. It was once a highly used hash\nfunction that produced 128-bit digests or hash values. When you hash something,\nyou\u2019re mapping data of any length to a fixed-length output. In order for a\nhashing algorithm to be considered secure, it has to be resistant to collisions.\nA collision occurs when two disparate inputs create the same value. This\nrenders the algorithm useless. MD5 was found to be embarrassingly insecure\naround 2012. Collisions can be found trivially on a home computer within\nseconds. <\/p>\n\n\n\n<p>SHA replaced MD5 and has served adequately ever since. In\n2016 the entire SSL\/TLS industry shifted away from SHA-1 as the standard hashing\nalgorithm and upgraded to SHA-2. Google managed to create a SHA-1 collision\nlater that year. SHA-2 is still considered a secure hashing algorithm and is\nincluded in TLS 1.3. It just plays a different role.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">AEAD vs HMAC<\/h3>\n\n\n\n<p>With a traditional HMAC, the message is hashed along with a\nsecret key or Message Authentication Code, we\u2019ll get into HMAC in-depth in the\nfuture, the important takeaway is that the hash function basically serves as a\ncheck-sum, arriving alongside the ciphertext and indicating whether the message\nwas tampered with. The recipient will use the same key to run the same hash function\nand compare values. <\/p>\n\n\n\n<p>Historically there has been three different approaches to\nthis:<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/Cipher-Problem-1-300x300.png\" alt=\"\" class=\"wp-image-10659\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\"><li>Encrypt-then-MAC<\/li><li>MAC-then-Encrypt<\/li><li>MAC-and-Encrypt<\/li><\/ul>\n\n\n\n<p>SSL\/TLS, perhaps foolishly, has always used a Mac-then-Encrypt\napproach for message authentication. Or, more accurately, a MAC-then-Pad-then-Encrypt\nmodel. This has been problematic because it opens itself up to padding oracle\nattacks. It\u2019s also somewhat inefficient, because the client or server have to\nuse resources to decrypt the message first, which is wasteful if it can\u2019t be\nauthenticated. Attackers can actually send a bunch of unauthenticated requests\nto a server and overwork it by making it decrypt a bunch of garbage. <\/p>\n\n\n\n<p>TLS 1.3 goes in a different direction with AEAD. It MACs and\nEncrypts simultaneously, shutting the window on padding attacks and saving clients\nand servers time and resources by making it easier for them to discard\nunauthenticated messages without having to decrypt them. &nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">HMAC-based Key Derivation Functions<\/h3>\n\n\n\n<p>Sticking with TLS 1.3, hashing has seen a bit of an overhaul.\nWe just talked about AEAD bulk ciphers, the message authentication that had originally\nbe handled by the HMAC algorithm, has been offloaded to the bulk cipher now. <\/p>\n\n\n\n<p>Instead, focus on the last three words in HKDF: Key Derivation\nFunction.<\/p>\n\n\n\n<p>Let\u2019s go back to the key exchange conversation we had earlier\nand the pseudo-random functions that were used to mix keys during RSA key\nexchange and calculate them during Diffie-Hellman. HKDF provides a much more\nsecure, much more random method for deriving those keys. <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/12\/Binary-Key-300x120.png\" alt=\"\" class=\"wp-image-10585\"\/><\/figure>\n\n\n\n<p>There are two primary stages: extract and expand. <\/p>\n\n\n\n<p>The extract portion takes key input information (key shares,\nrandoms, pre-master secrets) and optionally a salt, and then extracts a sufficiently\nsecure pseudorandom key.<\/p>\n\n\n\n<p>The expand stage is a mechanism where the algorithm expands\nthe key to requisite size without compromising its computational hardness. RFC\n5869, which specifies HKDF makes it extremely clear that the two stages should\nnot be conflated. As we\u2019ve discussed many times, the Random Number Generators\nthat get used for pseudo-random functions are much more fallible than many\nwould care to admit. Especially if the same seeds are re-used by many different\nimplementations. Hence TLS 1.3\u2019s focus on increasing the security of its\npseudo-random functions to avoid some of the vulnerabilities that have surfaced\nlately.<\/p>\n\n\n\n<p><em>Obviously, this is an\nincomplete list, there are dozens of other ciphers. But this should at least\ngive you some more context when you see the lists of cipher suites we have in\nthe next section. <\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">TLS 1.2 Cipher Suite List<\/h2>\n\n\n\n<p>Here\u2019s a list of the current RECOMMENDED cipher suites for\nuse with TLS 1.2. We\u2019re not going to publish all 37 of the ciphers that are\navailable. These are the ones that are advisable:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256<\/li><li>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384<\/li><li>TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256<\/li><li>TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384<\/li><li>TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256<\/li><li>TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384<\/li><li>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<\/li><li>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<\/li><li>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256<\/li><li>TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384<\/li><li>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256<\/li><li>TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384<\/li><li>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<\/li><li>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384<\/li><li>TLS_DHE_RSA_WITH_AES_128_CBC_SHA<\/li><li>TLS_DHE_RSA_WITH_AES_256_CBC_SHA<\/li><li>TLS_DHE_RSA_WITH_AES_128_CBC_SHA256<\/li><li>TLS_DHE_RSA_WITH_AES_256_CBC_SHA256<\/li><li>TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256<\/li><li>TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305<\/li><li>TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256<\/li><li>TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305<\/li><\/ul>\n\n\n\n<p>Again, you should be using Ephemeral Diffie-Hellman. Not\nonly is it mandatory in TLS 1.3, it also facilitates Perfect Forward Secrecy,\nwhich guards against the decryption of individual sessions in the even the\nserver\u2019s private key is ever compromised.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What\u2019s Different in TLS 1.3?<\/h2>\n\n\n\n<p>We\u2019ve tried to point out when things have changed during\neach section, but we\u2019ll go ahead an give a more comprehensive list here. Let\u2019s\nstart with the makeup of the cipher suite itself, then we\u2019ll go back over the\nways that the algorithms themselves have been updated for TLS 1.3 cipher\nsuites.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Shorter Cipher Suites<\/h3>\n\n\n\n<p>The biggest thing you\u2019ll notice about TLS 1.3 cipher suites\nis that they\u2019re much shorter than their TLS 1.2 counterparts. That\u2019s owing to\ntwo major things:<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>The type of certificate is no longer listed (whether\nits RSA or ECDSA)<\/li><li>They key exchange mechanism is not listed (always\nDHE or ECDHE)<\/li><\/ol>\n\n\n\n<p>That means that the number of negotiations that need to be\ndone when determining encryption parameters has been reduced from four to two. <\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/04\/TLS-1.3-cipher-suite.png\" alt=\"\" class=\"wp-image-10325\"\/><\/figure>\n\n\n\n<p>As you can see, TLS 1.3 cipher suites only include an AEAD\nbulk cipher and an HKDF.<\/p>\n\n\n\n<p>The client goes into the handshake with the knowledge that\nDiffie-Hellman Ephemeral scheme will be used for the key exchange process. This\nmeans it can send its portion of the key share during the Client Hello. <\/p>\n\n\n\n<p>That, in turn, can cut the TLS 1.3 handshake down to a\nsingle roundtrip, where the server responds with all the requisite information for\nthe two parties to derive the session key and begin communicating securely during\nits Server Hello message. &nbsp;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Deprecation of Old Ciphers\/Functionality<\/h3>\n\n\n\n<p>But the changes go well beyond just the length of the cipher\nsuites and the reduced number of negotiations during the handshake. Things have\nalso been made much more secure.<\/p>\n\n\n\n<p>TLS 1.3 has eliminated:<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2017\/08\/Deprecated-Ciphers-300x300.png\" alt=\"TLS 1.3 removed these ciphers\" class=\"wp-image-10642\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\"><li>SSL Compression<\/li><li>Static key exchange functions<\/li><li>Block ciphers (CBC)<\/li><li>Non-AEAD ciphers (MAC-then-Encrypt)<\/li><li>Renegotiation of encryption parameters<\/li><\/ul>\n\n\n\n<p>It\u2019s also dropped support for older, vulnerable SSL ciphers\nlike:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>RC4<\/li><li>DSA<\/li><li>MD5<\/li><li>SHA1<\/li><li>Weak Elliptic Curves<\/li><li>RSA Key Exchange<\/li><li>Static Diffie-Hellman (DH, ECDH)<\/li><\/ul>\n\n\n\n<p>Because the structure of 1.3 cipher suites is different from\nits predecessors\u2019, TLS 1.3 cipher suites will not be interchangeable with older\nTLS versions. That essentially means you\u2019re going to need to have two different\nimplementations if you plan on continuing to support TLS 1.2. And there\u2019s nothing\nwrong with continuing to support TLS 1.2, either. <\/p>\n\n\n\n<p>Until more companies in the hosting community make it a\npoint to transition to TLS 1.3, shutting off TLS 1.2 would be foolish.<\/p>\n\n\n\n<p>You should have already disabled TLS 1.1, TLS 1.0, SSL 3.0\nand SSL 2.0 though. The PCI DSS deadline for deprecating SSL 3.0 was last\nSummer. The deadline for TLS 1.0 and TLS 1.1 is January 2020.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">TLS 1.3 Cipher Suite List<\/h2>\n\n\n\n<p>Here are the five TLS 1.3 cipher suites that are supported\nby OpenSSL right now.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>TLS_AES_256_GCM_SHA384<\/li><li>TLS_CHACHA20_POLY1305_SHA256<\/li><li>TLS_AES_128_GCM_SHA256<\/li><li>TLS_AES_128_CCM_8_SHA256<\/li><li>TLS_AES_128_CCM_SHA256<\/li><\/ul>\n\n\n\n<p>There may be more cipher suites incoming as TLS 1.3\ncontinues to gain its footing, but reducing the number of possible options was\nalso one of the biggest considerations when the IETF was finalizing TLS 1.3, so\nif there are additional cipher suites added don\u2019t expect the explosion of\ncombinations we saw with the TLS 1.2. <\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What We Hashed Out (For the Skimmers)<\/h2>\n\n\n\n<p>For those that like to skim, here are the key takeaways from\ntoday\u2019s conversation:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Ciphers are algorithms, sets of instructions for performing \ncryptographic functions like encrypting, decrypting, hashing and \nsigning. They can be symmetric or asymmetric, depending on the type of \nencryption they support.<\/li><li>A Cipher Suite is a combination of \nciphers used to negotiate security settings during the SSL\/TLS \nhandshake. During the handshake, the client and server exchange a \nprioritized list of Cipher Suites and decide on the suite that is best \nsupported by both.<\/li><li>TLS 1.3 the structure of Cipher Suites has \nchanged, shrinking from four ciphers to just two and cutting then number\n of negotiations in half. <\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Every once and a while you run into an article on the internet that\u2019s just too good to just make a bookmark (or some similar technique that allows you to store the URL to that previous piece of useful information). I have been on the internet long enough to know that no matter how good &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/blog.remyblom.nl\/?p=216\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Article Archive: Patrick Nohe &#8211; Cipher Suites&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[17,19],"tags":[],"class_list":["post-216","post","type-post","status-publish","format-standard","hentry","category-article-archive","category-crypto"],"_links":{"self":[{"href":"https:\/\/blog.remyblom.nl\/index.php?rest_route=\/wp\/v2\/posts\/216","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.remyblom.nl\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.remyblom.nl\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.remyblom.nl\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.remyblom.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=216"}],"version-history":[{"count":2,"href":"https:\/\/blog.remyblom.nl\/index.php?rest_route=\/wp\/v2\/posts\/216\/revisions"}],"predecessor-version":[{"id":218,"href":"https:\/\/blog.remyblom.nl\/index.php?rest_route=\/wp\/v2\/posts\/216\/revisions\/218"}],"wp:attachment":[{"href":"https:\/\/blog.remyblom.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=216"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.remyblom.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=216"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.remyblom.nl\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=216"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}