{"id":2531,"date":"2016-01-23T09:32:23","date_gmt":"2016-01-23T14:32:23","guid":{"rendered":"https:\/\/infotechguy.net\/?p=2531"},"modified":"2025-02-22T13:10:47","modified_gmt":"2025-02-22T18:10:47","slug":"1-way-vs-2-way-ssl-authentication","status":"publish","type":"post","link":"https:\/\/infotechguy.net\/?p=2531","title":{"rendered":"Linux — OpenSSL One,Two-way authentication"},"content":{"rendered":"

Table of Contents<\/h1>\n
    \n
  1. About SSL Authentication<\/a><\/li>\n
  2. Quick Review<\/a><\/li>\n
  3. Creating a Certificate Authority<\/a><\/li>\n
  4. 1-way “Standard” SSL Authentication<\/a><\/li>\n
  5. 2-way “Mutual” SSL Authentication<\/a><\/li>\n
  6. Advanced SSL Authentication: CRLs, CDP, and OCSP<\/a><\/li>\n
  7. Concept Review<\/a><\/li>\n<\/ol>\n

    About SSL Authentication:<\/h3>\n

    TLS Authentication<\/strong> or SSL authentication is nothing more than proving the authenticity of one or both parties in the formation of an TLS “Secure” \u00a0connection.<\/strong><\/p>\n

    1-way “Standard” TLS Authentication<\/strong> is the most common, you use this every time you log into Facebook, your bank website, google, etc. The point of this type of authentication is for you (as the client) to verify the authenticity of the web site you are connecting to and form a secure channel of communication.<\/p>\n

    2-way “Mutual” mTLS Authentication<\/strong> is less common than the traditional “one-way” TLS authentication we are a custom to when visiting secured websites. When we connect to our banking website or our favorite web e-mail site, we as the client are verifying the identify of the site we are requesting content from. This “one-way” authentication allows us as the client to connect with confidence that the web site we are receiving content from has been verified. this authenticity check is performed by our client browser with a little help from a third-party certificate authority.<\/p>\n

    Let’s first review a one-way TLS connection.<\/strong><\/p>\n

      \n
    1. The Client browsers receives https:\/\/google.com in it’s address barf<\/li>\n
    2. Client browsers knows based on https:\/\/ that this connection will require an SSL handshake and sends a CLIENT_HELLO to the destined web server (google). This includes other things like SSL\/TLS version, acceptable ciphers, etc<\/li>\n
    3. The web server receives the CLIENT_HELLO request and sends a SERVER_HELLO back to the client. SERVER_HELLO contains SSL version, acceptable ciphers, and the server certificate.<\/li>\n
    4. The client receives the servers certificate and it is verified against a list of known Certificate Authorities.<\/li>\n
    5. If the certificate is proven to be in good standing, the client sends back a pre-master secret is encrypted inside the server’s certificate. Remember only the server can decrypt anything encrypted with it’s certificate because only the server has the decryption key. Server Certificate encrypts, Server Key decrypt’s.<\/li>\n
    6. At this point both client and server have the pre-master secret and can calculate a master secret to use to symmetrically encrypt and decrypt data between them.<\/li>\n<\/ol>\n

      So as we can see from a traditional TLS handshake, the client is never verified as authentic. Now, in most situations this is fine, as most connect types of this nature only need to verify the server because that is where the content is coming from.<\/p>\n

      The difference<\/strong>: In a 2-way mutual authenticated TLS handshake, the server will ask the client to send its own certificate for verification. Just like the client asking for the server’s certificate in the 1-way TLS handshake above, the server will perform verification of the client certificate before continuing to the pre-master and master secret phase of the SSL handshake. If authenticity of the client cannot be verified the server closes the connection.<\/p>\n

      How is mutual trust obtained?<\/strong> Both the server and client must generate their own TLS certificate and keys, and both must be signed by the same Certificate Authority. This ensures that both the server and the client’s certificate are trusted. This allows authentication to remain asymmetrical, instead of symmetrical. For example, rather than have a shared password that 3 clients and the server use to encrypt and decrypt data. Each client and the server have their own certificates and keys that will be used for communication with the server. Asymmetrical authentication and encryption is better at enforcing authenticity because everyone has their own cert and key used to establish a secure connection with the server. Symmetrical authentication is faster at encrypting and decrypting but suffers from having every client use the same key.<\/p>\n

      What happens if a client key is compromised?<\/strong> In the symmetrical authentication scenario, mentioned previously, you would have a serious security issue on your hands. Each client would be at risk and the likely hood of eavesdropping would increase. An attacker only has to obtain one key to gain visibility into every connection. Asymmetrical on the other hand has a different way of handling this. Because each client has it’s own certificate and key pair, and the signing of each certificate is performed by a third-party Certificate Authority, one simply has to revoke the compromised client in the form of a CRL certificate(more on this later). Other client connections will not be compromised or have to be re-generated. The server verifying the client certificate will fail only for the revoked for the compromised client.<\/p>\n

      What happens if my Certificate Authority’s key is compromised?<\/strong> This is the worst case scenario that can happen in your PKI infrastructure.An attacker can impose and generate a new certificate authority certificate and start signing certificates that can be used to fake authenticity. In essence break the certificate authority’s\u00a0trust.\u00a0 Keep in mind a Certificate Authority key cannot decrypt your connections.<\/p>\n

      <\/p>\n

      <\/a>Let’s review….<\/h3>\n