{"id":1785,"date":"2014-11-21T02:24:56","date_gmt":"2014-11-20T22:24:56","guid":{"rendered":"https:\/\/rakhesh.com\/?p=1785"},"modified":"2014-12-01T11:03:08","modified_gmt":"2014-12-01T07:03:08","slug":"notes-on-tlsssl-rsa-dsa-edh-ecdhe-and-so-on","status":"publish","type":"post","link":"https:\/\/rakhesh.com\/infrastructure\/notes-on-tlsssl-rsa-dsa-edh-ecdhe-and-so-on\/","title":{"rendered":"Notes on TLS\/SSL, RSA, DSA, EDH, ECDHE, and so on &#8230;"},"content":{"rendered":"<p>The <a href=\"https:\/\/blog.cloudflare.com\/\" target=\"_blank\">CloudFlare guys<\/a> make excellent technical posts.\u00a0Recently they introduced Keyless SSL (which is a way of conducting the SSL protocol wherein the server you are talking to does not necessarily need to have the private key) and as part of <a href=\"https:\/\/blog.cloudflare.com\/keyless-ssl-the-nitty-gritty-technical-details\/\" target=\"_blank\">the post\u00a0going into its technical details<\/a> they talk about the SSL protocol in general. Below are my notes on this and a few other posts. Crypto intrigues me as I like encryption and privacy so this is an area of interest.\u00a0<\/p>\n<p>Note:\u00a0This is not a summary of the CloudFlare blog post. It\u00a0was inspired by that post but I talk about a lot more basic stuff below.\u00a0<\/p>\n<h2>The TLS\/SSL protocol<\/h2>\n<p>First things first &#8211;\u00a0what we refer to as Secure Sockets Layer (SSL) protocol is not really SSL but Transport Layer Security (TLS).<\/p>\n<ul>\n<li>Versions 1.0 to 3.0 of SSL were called, well &#8230; SSL 1.0 to SSL 3.0.\u00a0<\/li>\n<li>TLS 1.0\u00a0was the upgrade from SSL 3.0. It is very similar to SSL such that TLS 1.0 is often referred to as SSL 3.1.\u00a0<\/li>\n<li>Although the differences between TLS 1.0 and SSL 3.0 are not huge, the two cannot talk to each other. TLS 1.0, however, <a href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/windows\/desktop\/aa380515(v=vs.85).aspx\" target=\"_blank\">includes a mode<\/a> wherein it can talk to SSL 3.0 but this decreases security.\u00a0<\/li>\n<\/ul>\n<p>The world still refers to TLS as SSL but keep in mind it&#8217;s really TLS. TLS has three versions so far &#8211; TLS 1.0, TLS 1.1, and TLS 1.2. A fourth version, TLS 1.3, is currently in draft form. I would be lying if I said I know the differences between these versions (or even the differences between SSL 3.0 and TLS 1.0) so it&#8217;s best to check the RFCs for more info!<\/p>\n<h2>TLS\/SSL goals<\/h2>\n<p>The TLS\/SSL protocol has <strong>two goals<\/strong>:<\/p>\n<ol>\n<li>Authenticate the\u00a0two parties that are talking with each other (authentication of a\u00a0server is the more common scenario &#8211; such as\u00a0when you visit your bank&#8217;s website for instance &#8211; but authentication of the user\/ client too is supported and used in some scenarios).\u00a0<\/li>\n<li>Protect the conversation between the two parties.<\/li>\n<\/ol>\n<p>Both goals are achieved via\u00a0<strong>encryption<\/strong>.<\/p>\n<p>Encryption is a way of &#8220;locking&#8221; data\u00a0such that only a person who has a &#8220;key&#8221; to unlock it can read it. Encryption mechanisms are essentially algorithms: you take a\u00a0message, follow the steps of the algorithm, and end\u00a0up with an encrypted gobbledygook.\u00a0All encryption algorithms make use of keys to lock and unlock the message &#8211; either\u00a0a single key (which both\u00a0encrypts and decrypts the message) or two keys (either can encrypt and decrypt).<\/p>\n<h3>Shared key\u00a0encryption\/ Symmetric\u00a0encryption<\/h3>\n<p>A very simple encryption algorithm is the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Caesar_cipher\" target=\"_blank\">Caesar Cipher<\/a>\u00a0where all you do is take some text and replace the letters with\u00a0letters that are a specified number away from it (for example you could replace &#8220;A&#8221; with &#8220;B&#8221;, &#8220;B&#8221; with &#8220;C&#8221;, and so on or &#8220;A&#8221; with &#8220;C&#8221;, &#8220;B&#8221; with &#8220;D&#8221;, and so on &#8230; in the first\u00a0case you replace with a letter <em>one<\/em> away from it, in the second case you replace with a letter <em>two<\/em> away from it). For the Caesar Cipher the key is simply\u00a0the &#8220;<em>number<\/em> of letters&#8221; away that you choose. Thus for instance, if both parties decide to use a key of 5, the encrypting algorithm will replace each letter with one that&#8217;s 5 letters away, while the decrypting algorithm will replace each letter with one that&#8217;s 5 letters before. The key in this case is a shared key &#8211; both parties need to know it\u00a0beforehand.\u00a0<\/p>\n<p>Encryption algorithms where a single shared key is used are known as symmetric encryption algorithms. The operations are symmetrical &#8211; you do something to encrypt, and you undo that something to decrypt. TLS\/SSL uses symmetric encryption to protect the\u00a0conversation between two parties. Examples of the\u00a0symmetric encryption algorithms TLS\/SSL uses are <a href=\"http:\/\/en.wikipedia.org\/wiki\/Advanced_Encryption_Standard\" target=\"_blank\">AES<\/a>\u00a0(preferred), <a href=\"http:\/\/en.wikipedia.org\/wiki\/Triple_DES\" target=\"_blank\">Triple DES<\/a>, and <a href=\"http:\/\/en.wikipedia.org\/wiki\/RC4\" target=\"_blank\">RC4<\/a>\u00a0(not preferred). Examples of popular symmetric \u00a0algorithms can \u00a0be found on this <a href=\"https:\/\/en.wikipedia.org\/wiki\/Symmetric-key_algorithm\" target=\"_blank\">Wikipedia page<\/a>.\u00a0<\/p>\n<p>Symmetric encryption has the\u00a0obvious disadvantage that you need a way of <em>securely\u00a0sharing the key<\/em> beforehand, which may not always be practical (and if you can securely share the key then why not securely share your message too?).<\/p>\n<h3>Public key encryption\/ Asymmetric\u00a0encryption<\/h3>\n<p>Encryption algorithms that use two keys are known as\u00a0asymmetric encryption or public key encryption. The name is because such algorithms make use of two keys &#8211; one of which is secret\/ private and the other is public\/ known to all. Here the operations aren&#8217;t symmetrical- you do something to encrypt, and you do <em>something else<\/em> to decrypt. The two keys are special in that they are mathematically linked and anything that&#8217;s encrypted by one of the keys can be decrypted only by the second key. A popular public key encryption algorithm is <a href=\"https:\/\/en.wikipedia.org\/wiki\/RSA_(cryptosystem)\" target=\"_blank\">RSA<\/a>. This <a href=\"http:\/\/blog.cloudflare.com\/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography\/\" target=\"_blank\">CloudFlare blog post on Elliptic Curve Cryptography<\/a>\u00a0(ECC), which is itself an example of a public key encryption algorithm, has a good explanation of how RSA works.\u00a0<\/p>\n<p>Public key encryption can be used for encryption as well as\u00a0authentication. Say there are two parties, each party will keep its private key to itself and publish the public key. If\u00a0the first party wants to encrypt a message for the second party, it can\u00a0encrypt it using the public key of\u00a0the second party. Only the second party will be able to decrypt the message as only it holds the private key. Thus the second party is authenticated\u00a0as only the second party holds the private key corresponding to the public key.<\/p>\n<p>Public key cryptography algorithms\u00a0can also be used to generate digital signatures. If the first party wants to send a message to the second party and sign it, such that the second party\u00a0can be sure it came from the first party, all the first party needs to do is send the message as usual but this time take a hash of the message encrypt that with its private key. When the second party receives this message it can decrypt the hash via the public key of the first party, make a hash itself of the message, and compare the two. If the hashes match it proves that the message wasn&#8217;t tampered in progress and also that the first party has indeed signed it as only its private key locked message can be unlocked by the public key. Very cool stuff actually!<\/p>\n<p>Not all public key cryptography algorithms are good at encryption and\u00a0signing nor are they required\u00a0to be so. RSA, for instance, is good at encryption &amp; decryption. Another algorithm, DSA (Digital Signature Algorithm) is good at signing &amp; validation. <a href=\"http:\/\/crypto.stackexchange.com\/a\/2586\" target=\"_blank\">RSA can do signing &amp; validation too but that&#8217;s due to the nature of its algorithm<\/a>.\u00a0<\/p>\n<h4>A\u00a0question of trust<\/h4>\n<p>While public key encryption can be used for authentication there is a problem. What happens if a third party publishes its public key on the network but claims that it is the second party. Obviously it&#8217;s a fraud but how is the first party to know of that? Two ways really: one way is the first party can perhaps call or through some other means verify with the second party\u00a0as to what its public key is and thus choose the correct one &#8211; this is tricky because it has to verify the identity somehow and be sure about it &#8211; or, the second way, there can be some trusted authority that verifies this for everyone &#8211; such a trusted authority will confirm that such and such public key really belongs to the second party.\u00a0<\/p>\n<p>These two ways of finding if you can trust someone are called the Web of Trust (WoT) and Public Key Infrastructure (PKI) respectively. Both achieve the same thing, the difference being the former\u00a0is decentralized while the latter is centralized. Both of these make use of something called <a href=\"https:\/\/en.wikipedia.org\/wiki\/X.509#Structure_of_a_certificate\" target=\"_blank\">certificates<\/a> &#8211; which is basically a digital document that contains the public key as well as some information on the owner of the public key (details such as the email address, web address, how long the certificate is valid for, etc).\u00a0<\/p>\n<h4>Web of Trust (WoT)<\/h4>\n<p>In a WoT model\u00a0everyone uploads their certificates to certain public servers. When a first party searches for certificates belonging to a second party it can find them &#8211; both legitimate ones (i.e. actually\u00a0belonging to the\u00a0second party) as well as illegitimate ones (i.e. falsely uploaded by other parties claiming to the be second party). By default though the first party doesn&#8217;t trust these certificates. It only trusts a certificate\u00a0once it verifies through some other means as to which is the legitimate one &#8211; maybe it calls up the second party or meets the party in person or gets details from its website. The first party\u00a0can also trust a\u00a0certificate if someone else it already trusts has marked\u00a0a certificate as trusted. Thus each party in effect builds up a web of certificates &#8211; it trusts a few and it trusts whatever is trusted by the few that it trusts.\u00a0<\/p>\n<p>To add to the pool once a party trusts a certificate it can indicate so for others to see. This is done by signing the certificate (which is similar to the signing process I mentioned earlier). So if the first party has somehow verified that a certificate it found really belongs to the second party, it can sign it and\u00a0upload that information to the public servers. Anyone else then searching for certificates of the second party will come across the true certificate too and find the signature of the first party.\u00a0<\/p>\n<p>WoT is what you use with programs such as PGP and GnuPG.\u00a0<\/p>\n<h4>Public Key Infrastructure (PKI)<\/h4>\n<p>In a PKI model there are designated\u00a0<a href=\"https:\/\/en.wikipedia.org\/wiki\/Certificate_authority\" target=\"_blank\">Certificate\u00a0Authorities<\/a> (CA)\u00a0which are trusted by everyone. Each party\u00a0sends their certificates to the CA to get it signed. The CA verifies that the party is who it claims to be and then signs it. There are many classes of validation &#8211; domain validation (the CA verifies that the requester can manage the domain the certificate is for), organization validation (the CA also verifies that the requester actually exists), and extended validation (a much more comprehensive validation than the other two).\u00a0<\/p>\n<p>Certificate Authorities have a tree structure. There are certain CAs &#8211; called root CAs &#8211;\u00a0which\u00a0are implicitly trusted by everyone. Their certificates are self-signed or unsigned but trusted by everyone. These root CAs sign certificates of other CAs who in-turn might sign certificates of other CAs or of a requester. Thus there&#8217;s a chain of trust &#8211; a root CA trust an intermediary CA, who trusts another intermediary CA, who trusts (signs) the certificate of a party. Because of this chain of trust, anyone who trusts the root CA will trust the certificate signed by one of its intermediaries.\u00a0<\/p>\n<p>\u00a0It&#8217;s probably worth pointing out that you don&#8217;t really need to get your certificate signed by a CA. For instance, say I want to encrypt all traffic between my computer and this blog and so I\u00a0create\u00a0a certificate for the\u00a0blog. I will be\u00a0the only person using this &#8211; all my regular visitors will visit the blog unencrypted. In such a case I don&#8217;t have to bother with them not trusting my certificate. I trust my certificate as I know what its public key and details look like, so I can\u00a0install the certificate and use an https link when browsing the blog, everyone else can use the regular http link. I don&#8217;t need to get it signed by a CA for my single person use. It&#8217;s only if I want the general public to trust the certificate that I must involve a CA.\u00a0<\/p>\n<p>PKI is what you use with Internet Browsers such as Firefox, Chrome, etc. PKI is also what you use with email programs such as Outlook, Thunderbird, etc to encrypt communication with a server (these emails program may also use WoT to encrypt communication between a sender &amp; recipient).\u00a0<\/p>\n<h2>TLS\/SSL (contd)<\/h2>\n<p>From here on I&#8217;ll use the words &#8220;client&#8221; and &#8220;server&#8221; interchangeably with\u00a0&#8220;first party&#8221; and &#8220;second party&#8221;. The intent is the same, just that it&#8217;s easier to think of one of one party as the client and the other as a server.\u00a0<\/p>\n<p>TLS\/SSL uses both asymmetric and symmetric encryption. TLS\/SSL clients use\u00a0asymmetric encryption to authenticate the server (and vice-versa too if required) and as part of that authentication they\u00a0also share with each other a\u00a0symmetric encryption key which they&#8217;ll use to\u00a0encrypt the rest of their conversation. TLS\/SSL\u00a0uses both types of encryption algorithms\u00a0because asymmetric encryption is computationally expensive (by design) and so it is not practical to encrypt the entire conversation using asymmetric encryption (see this StackExchange <a href=\"http:\/\/security.stackexchange.com\/a\/41226\" target=\"_blank\">answer<\/a> for more reasons). Better to use use asymmetric encryption to authenticate and bootstrap symmetric encryption.\u00a0<\/p>\n<p>When a TLS\/SSL client contacts a TLS\/SSL\u00a0the server sends the client its certificate. The client validates it using the PKI. Assuming the validation succeeds, client and server perform a &#8220;handshake&#8221; (a series of steps) the end result of which is (1) authentication and (2) the establishment of a &#8220;session key&#8221; which is the symmetric key used for encrypting the\u00a0rest of the\u00a0conversation.\u00a0<\/p>\n<p>CloudFlare&#8217;s <a href=\"https:\/\/blog.cloudflare.com\/keyless-ssl-the-nitty-gritty-technical-details\/\" target=\"_blank\">blog post on Keyless SSL<\/a> goes into more details of the handshake. There are two types of handshakes possible: RSA handshakes and Diffie-Hellman handshakes. The two types of handshakes differ in\u00a0terms of\u00a0what algorithms are used for authentication and what algorithms are used for session key generation.\u00a0<\/p>\n<h3>RSA handshake<\/h3>\n<p>RSA handshakes are based on the RSA algorithm which I mentioned earlier under public key encryption.\u00a0<\/p>\n<p>An RSA handshake uses RSA certificates for authentication (RSA certificates contain a public RSA key). Once authentication is successful, <em>the client<\/em> creates a random session key and encrypts with the public key of the server (this encryption uses the RSA algorithm). The server can decrypt this session key with its private key, and going forward both client &amp; server use this session key to encrypt further traffic (this encryption does not use the RSA algorithm, it uses one of the symmetric key algorithms).<\/p>\n<p>\u00a0The RSA handshake\u00a0has a drawback in that if someone were to capture and store past encrypted traffic, and if the server&#8217;s private key were to somehow leak, then such a person could easily decrypt the session key and thus decrypt the past traffic. The server&#8217;s private key plays a very crucial role here as it not only authenticates the server, it also\u00a0protects the session key.\u00a0<\/p>\n<h3>Diffie-Hellman handshake<\/h3>\n<p>Diffie-Hellman handshakes are based on the Diffie-Hellman key exchange algorithm.\u00a0<\/p>\n<p>The Diffie-Hellman key exchange is an interesting algorithm. It doesn&#8217;t do any encryption or authentication by itself. Instead, it offers a way for two parties to <em>generate a shared key in public<\/em> (i.e. anyone can snoop in on the conversation that takes place to generate the secret key) but the <em>shared key is secret and only the two parties know<\/em> of it (i.e. the third party snooping in on the conversation can&#8217;t deduce the shared key). A good explanation of how Diffie-Hellman does this can be found in <a href=\"http:\/\/wiki.openssl.org\/index.php\/Diffie_Hellman\" target=\"_blank\">this blog<\/a> post. Essentially: (1) the two parties agree upon a large prime number and a smaller\u00a0number in public, (2) each party then picks a secret number (the private key) for itself and calculates another number (the public key) based on this secret number, the prime number, and the smaller number, (3) the public keys are shared to each other and using each others public key, the prime number, and the small number, each party can calculate the (same) shared key. The beauty of the math involved in this algorithm is that even though a snooper knows the prime number, the small number, and the two public keys, it still cannot deduce the private keys or the shared key!<\/p>\n<p>There are two versions of the Diffie-Hellman algorithm:<\/p>\n<ul>\n<li>a fixed\/ static version, where both parties use the same public\/ private keys (and hence same shared key) across all their conversations; and<\/li>\n<li>an ephemeral version, where one party keeps changing its\u00a0public\/ private key (and hence the shared key)<\/li>\n<\/ul>\n<p>Since the Diffie-Hellman algorithm does not do authentication it needs some other mechanism to authenticate the client and server. It can use an RSA certificate (certificates containing an RSA public key) or a non-RSA certificates &#8211; for example DSA certificates (certificates containing a DSA public key) and ECDSA (Elliptic Curve Digital Signature Algorithm) certificates (ECDSA is a variant of DSA that uses <a href=\"http:\/\/en.wikipedia.org\/wiki\/Elliptic_curve_cryptography\" target=\"_blank\">Elliptic Curve Cryptography<\/a>\u00a0(ECC). ECDSA certificates contain an ECC public key. ECC keys are better than RSA &amp; DSA keys in that the ECC algorithm is harder to break.\u00a0So not only are ECC keys more future proof, you can also use smaller length keys (for instance a 256-bit ECC key is as secure as a 3248-bit RSA key) and hence the certificates are of a smaller size).\u00a0<\/p>\n<p>The fixed\/ static version of Diffie-Hellman requires a Diffie-Hellman certificate for authentication (see <a href=\"http:\/\/security.stackexchange.com\/a\/41226\" target=\"_blank\">here<\/a>\u00a0and <a href=\"http:\/\/pic.dhe.ibm.com\/infocenter\/zos\/v1r13\/index.jsp?topic=%2Fcom.ibm.zos.r13.gska100%2Fgska1a9120.htm\" target=\"_blank\">here<\/a>). Along with the public key of the server, this certificate also contains the prime number and smaller number required by the Diffie-Hellman algorithm. Since these numbers are a part of the certificate itself and cannot change, Diffie-Hellman certificates only work with fixed\/ static Diffie-Hellman algorithms and vice-versa. A Diffie-Hellman handshake that uses the fixed\/ static Diffie-Hellman algorithm has the same drawback as a RSA handshake. If the server&#8217;s private key is leaked, past traffic can be decrypted. \u00a0<\/p>\n<p>The ephemeral version of Diffie-Hellman (often referred to as EDH (Ephermeral Diffie-Hellman) or DHE (Diffie-Hellman Ephemeral)) works with RSA certificates, DSA certificates, and ECDSA certificates. EDH\/ DEH is computationally <a href=\"http:\/\/wiki.openssl.org\/index.php\/Diffie_Hellman#Working_with_Parameters_and_Generating_Keys\" target=\"_blank\">expensive<\/a> as it is not easy to keep generating a new prime number and small number for every\u00a0connection. A variant of EDH\/ DEH that uses elliptic curves &#8211; known as Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) &#8211; <a href=\"http:\/\/vincent.bernat.im\/en\/blog\/2011-ssl-perfect-forward-secrecy.html\" target=\"_blank\">doesn&#8217;t have the performance hit<\/a> of EDH\/ DEH and is preferred.\u00a0<\/p>\n<p>A Diffie-Hellman handshake that uses EDH\/ DEH or\u00a0ECDHE\u00a0doesn&#8217;t have the drawback of an RSA handshake. The server&#8217;s private key is only used to authenticate it, not for generating\/ protecting the shared session key. This feature of\u00a0EDH\/DHE and ECDHE wherein the shared\u00a0keys are generated for each connection and are shared keys themselves are random and independent of each other is known as <a href=\"https:\/\/en.wikipedia.org\/wiki\/Forward_secrecy#Perfect_forward_secrecy\" target=\"_blank\">Perfect Forward Secrecy<\/a> (PFS). (<em>Perfect<\/em> Forward Secrecy is a stronger form of Forward Secrecy. The latter does not require the shared keys themselves be independent of each other, only that the shared\u00a0keys not be related to the server&#8217;s private\/ public key).\u00a0<\/p>\n<h2>To be continued &#8230;<\/h2>\n<p>Writing this post took longer than I expected so I&#8217;ll conclude here.\u00a0I wanted to explore TLS\/SSL in the context of Windows and Active Directory, but I got side-tracked talking about handshakes and RSA, ECDHE, etc. Am glad I\u00a0went down that route though. I was aware of elliptic curves and ECDHE, ECDSA etc. but had never really explored them in detail until now nor written down a cumulative understanding of it all.\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The CloudFlare guys make excellent technical posts.\u00a0Recently they introduced Keyless SSL (which is a way of conducting the SSL protocol wherein the server you are talking to does not necessarily need to have the private key) and as part of the post\u00a0going into its technical details they talk about the SSL protocol in general. Below &hellip; <a href=\"https:\/\/rakhesh.com\/infrastructure\/notes-on-tlsssl-rsa-dsa-edh-ecdhe-and-so-on\/\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">Notes on TLS\/SSL, RSA, DSA, EDH, ECDHE, and so on &#8230;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[333],"tags":[342,337,345,335,336,339,338,138,340,344,334,343,341],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/1785"}],"collection":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/comments?post=1785"}],"version-history":[{"count":0,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/1785\/revisions"}],"wp:attachment":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/media?parent=1785"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/categories?post=1785"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/tags?post=1785"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}