Self-Signed Certificates with SSL

Question

Today I was playing around with an SslStream implementation in C#, and was able to create a client/server connection over TCP. Also to verify it, I used wireshark to ensure that the data was in fact encrypted, but I have a couple of questions.

First, I should explain the process I went through.

• Create a TCP client with an SslStream layer inside. The TCP client connects to the server and DOES NOT try to authenticate the servers identify (just returns true when validating the server certificate). Once connected, just send a simple message to the server
• Create a TCP server with an SslStream layer inside. The server uses an X509 certificate that I generated with powershell (see this post from MSDN if interested)
• Install the certificate on my server computer's Personal Certificates (which requires me entering the password for the private key that was generated). The server listens, connects to the incoming connection, and prints out the decrypted data on screen.

Now, my question is basically this. What I've set up above, is this essentially a secure connection (e.g. both server and client have the symmetric key and encrypt/decrypt at will), but both are unable to verify "who" is on either end? For example, the client can't be sure of the server's identity, and the server can't be sure of the client's identity. Is this the case?

I want to use this scheme in a IOT project to control a garage door with a smartphone app.

So, my question is leading to another question: if I have my smartphone app (client) establish the SSL connection with my server, and then enter a password in my smartphone app which my server can verify (I guess I could use SHA-2 to hash the password on both ends, but is there any point since the channel is secure?), wouldn't this be able to verify the client from the server's perspective? Am I missing anything here?

Thanks.

Answer 1

For example, the client can't be sure of the server's identity, and the server can't be sure of the client's identity. Is this the case?

Correct. But validating the server certificates only addresses the first point: that the client is not sure about the servers identity, i.e. that the client might actually be connected to some man in the middle attacker instead who is able to sniff and modify the traffic.

Client identity is typically addressed inside the application protocol (i.e. login with username and password) but can also be addressed inside TLS with client certificates.

... then enter a password in my smartphone app which my server can verify ... wouldn't this be able to verify the client from the server's perspective?

Yes, this identifies the client against the server. But as long as the server certificate is not checked it might still be that a man in the middle attacker can intercept the connection and just claim to be the server against the client and claim to be the client against the server - then forward, analyse and potentially modify the data between real client and real server. And the attacker could also sniff the password this way and use it later again to impersonate the real client, without the real client being involved at all. In case of the garage door this would mean that the attacker could control the door even if the owner of the garage is not present.

Using a client certificate would protect against this attack even if the server is not authenticated by the client with a certificate - as long as the server checks that the client certificate is the expected one.

Answer 2

Password-based authentication (as you describe in the last paragraph of your question) is perhaps the most common way for a client to authenticate with a server in https. Another method is to use client certificates.

With regard to the client authenticating the server, you write:

The TCP client connects to the server and DOES NOT try to authenticate the servers identify (just returns true when validating the server certificate).

Without the client authenticating the server's identity - this opens the door to a Man-In-The-Middle (MITM) attack. An attacker that is able to position himself between the client and the server can present his own certificate to the client. If the client does not authenticate that the certificate is the true and correct certificate for the server, and the client trusts the certificate of the MITM, then the MITM can intercept and/or alter all communication between the client and the server. This is why it is essential that the client authenticates the server's certificate. Normally on the web, this is done through PKI, where trusted CA's authenticate servers certificates, then sign the certificates to indicate their 'stamp of approval'. Another way of authenticating a server certificate is to use 'certificate pinning', where the server's certificate is stored by the client, and the client checks that the certificate presented by the server matches the one that the client has stored. Certificate pinning is common with IOT clients.

Answer 3

Let me start by saying that SHA-256 is not an encryption algorithm, it is a hash so you can't:

I guess I could use SHA-2 to encrypt the password on both ends, but is there any point since the channel is secure?

Sha-256 is a hash algorithm that on its own does not provide any security as hashes are deterministic in nature, in other words, if you know the plain text you'll know the hash and you can map known hashes to known plain texts (rainbow tables). There is no sense to talk about security if you don't present a threat model. The question as such is too general to be answered. As suggested in the comments, you may use certificate pinning to distribute your self-signed certificate in an out-of-band fashion, but that does not provide much flexibility and limited security.

What you need to understand is that a self-signed certificate on its own (without pinning) provides no security besides the cryptographic aspect of it, there is no authentication. You should avoid use of them in commercial applications. Certificate issued from a trusted CA (be it private or public) is a better option and pinning them provides much more security and flexibility to your application. If you pin the self-signed cert, there is no revocation available, no CRL or OCSP. In order to invalidate your certificate you'll need to change it on the server and push it to the application this can lead to long outages.