Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Features You Never Knew Were There: Unsecured SSL/TLS

DZone's Guide to

Features You Never Knew Were There: Unsecured SSL/TLS

One developer shares the headaches his team encountered while trying to secure their database using TLS, and how they solved the problem.

· Security Zone ·
Free Resource

RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.  

I wish I would have known to use HTTPS for security. With RavenDB 4.0’s move toward TLS as the security mechanism for encryption of data over the wire and authentication using x509, we had to learn way too much about how Transport Layer Security works.

In particular, it can be quite annoying when you realize that just because you use SSL (or more accurately, TLS) that isn’t sufficient. You need to use the proper version, and there are interoperability issues. Many of RavenDB’s users run it in environments that are subject to strict scrutiny and a high level of regulation and oversight. That means that we need to make sure that we are able to operate in such an environment. One option would be to use something like a FIPS configuration. We have a “normal”configuration and one that is aimed at people that need stricter standards. For many reasons, this is a really bad idea. Not least of all is the problem that even if you don’t have to meet the FIMS mandate, you still want to be secured. Amusingly enough, many FIPS certified stacks are actually less secured (because they can’t get patches to the certified binaries).

So the two options mode was rejected. That meant that we should run in a mode that can match the requirements of the most common deployment regulations. Of particular interest to us is PCI compliance, since we are often deployed in situations that involve money and payment processing.

That can be a bit of a problem. PCI requires that your communication will use TLS, obviously. But it also requires it to use TLS 1.2. That is great and with .NET it is easily supported. However, not all the tools are aware of this. This puts us back in the same state as with HTTP vs. HTTPS. If your client does not support TLS 1.2 and your server requires TLS 1.2, you end up with a connection error.

Image title

Such a thing can be maddening for the user.

Therefore, RavenDB will actually allow TLS and TLS11 connections, but instead of processing the request, it will give you an error that gives you something to work with.

Image title

Updated: I forgot to actually read the message. The reason we were getting the error about no certificate is that there wasn't a certificate there. In order for this to work, we need to actually pass the certificate, in which case we’ll get the appropriate error. I apologize for the error handling, but PowerShell:

Image title

Armed with this information, you can now do a simple web search and realize that we actually need to do this:

Image title

And that saves us a lot of TCP level debugging. It took a bit of time to set this (and the other) errors properly, and they are exactly the kind of things that will save you hours or days of frustration, but you’ll never realize that they were there even if you run into them unless you know the amount of effort that went into setting this up.

Do you pay to use your database? What if your database paid you? Learn more with RavenDB.

Topics:
security ,ssl/tls ,network security

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}