Is HTTPS enough to secure your connection to a Webservice?

For many years, hardly anyone has bothered to secure their own server with a certificate or HTTPS. Why?

Because certificates are expensive and there was no reason to secure a private handwritten HTML page with the family pictures.

Bussines Websites with money transactions were the first to go HTTPS.

In the old days, many or nearly every MySQL Server had an open port to the internet. Today you can't do that anymore.

Is it so? Everybody will probably answer this question with:

"You have to connect to the database over a REST-Service, for safety!".

But what is the difference between login to a REST-Service and login to a Database-Server? Log in to a Database-Server is done with User and Password. And to a WebService? Normally with basic authentication, what under the hood is User and Password.

So why is it better to use a Webservice instead of a direct connection? The WebService could do more checks. Well, besides the security, if you send a request directly to your database server everything has to be transferred to the client. Inside a Webservice, you can prefilter manage and do different things before you send the data to the client. This could reduce the amount of data that must be transferred, but on the other hand, if you use JSON the data gets expanded by all the fancy { and } and some data gets really big, like pictures or other data blobs, because every byte has to be encoded with Base64 or Hexstrings.

As the internet gets faster and faster it looks like nobody cares anymore about the amound of data. The days for handwritten, optimized HTML are long gone. Everybody is using some kind of framework that transfers big javascript files with every response.

So, let's say that more bytes are transferred, so the database connection is certainly slower, but nobody cares about it, because of the increased security.

If you are using HTTP everybody in the middle could read all your data, that's why you have to use HTTPS. Thanks to Let's Encrypt it is not a factor of money anymore. But how secure is your connection?

If you open a website with your browser, you get this little lock in front of your URL. Nice we are safe! Are you sure? Let's leave that aside for now. What about when we query a REST(Full) web service from within an application?

We use a component or native HTTP-Get to the URL of our web service. The URL has HTTPS at the beginning.

Are you sure you are connected to your server?

Let's check if the certificate is correct! That's a really good idea. So we write a little proof of concept application. Intercept the certificate-check-call and compare if the information matches our certificate. 

And?

Fail! This is not our certificate! Is there a Man-In-The-Middle? Yes, it's your virus-scanner application! A very bad habit of a virus scanner is to check all HTTP and HTTPS traffic to find bad HTML that could harm your PC or your data.

Of course, it could also be another tool, such as Fiddler. But that should be clear to me because in this case, I started the tool by myself. However, on the way from my internet connection to my server, a corresponding tool could also be used.

I have no clue if the virus scanner has a backdoor and I'm not an aluminum hat carrier. But let's assume for the moment that this is the case, then the login data to your web service has been sent directly to the NSA in plain text. LOL...NSA in this case stands for all strangers who should not receive your data or logins.

If you have to protect your data stream, in this case, you have two options. 1.) Ignore it and may the NSA be happy with my login information, or 2.) Stop the data transfer.

So we are doomed?

There is one possibility you can do. (Not so easy on a website, but from your application).

Crypt your traffic!

Use the public RSA-Key of your Service to crypt your request. Send the public key of your application to the server so that the server could encode the data for you. Perhaps change the key for every new request.

Doesn't that sound familiar? 

Yes, it's like the SSH/HTTPS handshake. Thanks, virus scanner developer. 

Oh, by the way, if you are doing the crypting by yourself anyway, there is no need for an SSL certificate in the first place.

One nice side effect: Any tool that is trying to read your data stream can not fool you with its own certificate to read the data.

If you have read this far, I have one last question: Should I do a webinar / Youtube video on this topic?

Please leave a comment.