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

Error Handling Belongs at Layer 7 (Policy)

DZone's Guide to

Error Handling Belongs at Layer 7 (Policy)

In this article, we explore the double edged sword of database security and database performance, and why it's so hard to have both.

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.  

Image title

When you setup a RavenDB server securely, it doesn’t require a valid X509 certificate to be able to connect to it.

You might want to read that statement a few times to realize what I’m saying. You don’t need a certificate to connect to a RavenDB service. But on the other hand, we use a client certificate to authenticate connections. So which is it?

The problem is with the specific OSI layer that we are talking about. When using SSL/TLS you can require a client certificate upon connection. That ensures that only connections with a client certificate can be processed by the server. This is almost what we want, but it has the sad effect of having really poor error reporting capabilities.

For example, let us assume that you are trying to connect to a secured RavenDB server without a certificate. If we just require a client certificate, then the error would be raised a the SSL layer, giving you errors that look something like:

  • The connection has been closed.
  • Could not establish trust relationship for the SSL/TLS.

This can also happen if there is a firewall in the middle, if enough packets were dropped, if there is a solar storm or just because it is Monday.

Or, it can be because you don’t have a certificate, your certificate expired, it is not known or you are trying to access a resource you are not authorized to.

In all of those cases, the error you’ll receive if you require and validate the certificate at OSI Layer 6 is going, to put it plainly, suck. Just imagine trying to debug something like that in a protocol that by design is intended to be hard/impossible to eavesdrop on. Instead, we can allow access to the server without a certificate and enforce the required certificate at a higher level.

That means that when you connect to RavenDB and you don’t have a certificate, we’ll accept the connect and then either give you an error (if you are an API) that you can reason about (because it will tell you what is wrong) or you’ll be redirected to a nice error page (if you are using the browser). Alternatively, if you have a certificate and it is not valid for any number of reasons, RavenDB will tell you all about it.

That reduces the amount of hair loss in the case of errors significantly.

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

Topics:
performance ,error handling ,database performance

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}