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.
Posts
No comments:
Post a Comment