Named Query Parameters

The Rdbhost protocol now uses named parameters in addition to positional parameters.

Where before you could submit a query like:

<input name="q"
value="SELECT * FROM personnel WHERE firstName = %s AND lastName = %s" />
<input name="arg000" value="John" />
<input name="arg001" value="Smith" />

Now you can make it more readable, like:

<input name="q" value="SELECT * FROM personnel WHERE firstName = %(first) AND lastName = %(last)" />
<input name="arg:first" value="John" />
<input name="arg:last" value="Smith" />

This addition has a couple of benefits. The first is the greater readability and greater ease in assuring the correct parameter values are matched to the correct query tokens.

The other is that each parameter can be used in the query multiple times. For example, in the following snippet, we want to ensure that the value is at least 0.

CASE WHEN (%(val))<=0 THEN trunc(%(val),6) ELSE 0.00 END

The query snippet could be written with positional parameters, but there would then be no way to ensure the same value is passed as both values, and a negative value could be returned. Using a named parameter ensures that parameter value is used both times.

Using your own SSL/TLS Certificate

Rdbhost now supports your using your own SSL/TLS certificate for your rdbhost subdomain, to encrypt and authenticate data transfer with your account at www.rdbhost.com.

Why Use Certificates

The SSL/TLS certificates have two purposes, encryption and authentication. Any certificate, including a free self-signed certificate, will enable the server to encrypt data transferred between server and client. This encryption prevents data from being observed by eavesdroppers who might have access to your data stream.

However, a connection encrypted with a non-authenticated certificate is vulnerable to a type of attack known as a 'man in the middle' attack. If someone can insert a proxy into the network path between the client and the server, they can conduct a 'man in the middle' attack, impersonating each end of the connection to the other end. When the client (browser) requests a certificate, the proxy sends its own, and then requests a cert from the server. The proxy would hold a certificate for each half of the connection, and thus decrypt and encrypt all data passing through, recording whatever part it is interested in intercepting. This attack can happen because with an un-authenticated certificate, the client has no way of knowing that it is getting a cert from the proxy rather than the server.

The way to prevent this sort of 'man in the middle' attack, if it concerns you, is to use an authenticated, or 'trusted', certificate. If you purchase a 'trusted' certificate from vendor, they supposedly verify that you are indeed the owner of the site, and issue you a certificate that is digitally signed by them using their own trusted certificate. The client can verify the issuers signature with the issuer directly, and thus be assured that the certificate you present is your own. The 'man in the middle' attacker can present a certificate, but presumably would not be able to convince a trusted certificate issuer that they owned *your* domain, and thus could not present a certificate for your domain with a trusted issuer certificate.

There are a few certificate issuers that are trusted by all browsers as released. If your vendor is not one of those, they will have a certificate signed by one of those, sign your certificate with theirs, and send a bundle of certificates that establish a chain of trust from a trusted issuer to you. Godaddy.com is a very popular issuer of certificates, and they issue a bundle file with multiple certificates to establish the chain of trust. The client browser can see who signed your certificate, read the issuers certificate and find who signed it, and repeat until an intrinsically trusted issuer is found.

User Experience

Even if you are not very worried about someone conducting such an attack, you might still want a signed certificate to avoid browser warnings. Browsers, especially Firefox, can be very assertive about warning users of perceived limitations in a site's certificate. Having a trusted certificate avoids warnings and gives the user a smoother user experience. The warnings are so common these days, that many users are blase about it, but it is your call as to how tolerant your users will be.

The Rdbhost Way

Buy your trusted certificate from a vendor of your choice. There are websites that will create a public key pair and a CSR Certificate Signing Request for you, and you should create the CSR using your domain and the subdomain you use for Rdbhost server access, for example rdbhost.mydomain.com. The certificate vendor will create a certificate based on the CSR and make it available for download.

If you have not registered a domain alias on the site, do so now, registering the domain and subdomain, that you use for Rdbhost database access, for example 'rdbhost.mydomain.com'. The domain alias page is linked from the profile page.

If you have not entered the subdomain into the DNS zone manager of your domain registrar, you need to do so.

Visit the Certificate Manager on www.rdbhost.com and paste the certificate into the form field. If your vendor provides a chain (or 'bundle') file, paste it in after your certificate. Paste the private key in at the beginning or the end. Each of these files is a simple text file, so it can be opened in a text editor for cutting and pasting.

Within a minute or two after submitting the form, your account will be accessible using that domain, secured by SSL/TLS and your authenticated certificate.

Limitations

This SSL/TLS service relies on SNI Server Name Indication, an extension to the HTTP protocol. SNI is supported by many modern browsers, but not all. On Windows, notably, SNI handling is left to the OS by most browser brands, and while Vista and later support it, XP does not.

If your user is accessing the database using a browser that does not support SNI, they will get the default Rdbhost certificate, in lieu of your trusted certificate.


As always, comments are welcome.