'Secure sockets layer' allows encrypted secure communication between a browser and your web site. This must be setup on your site itself (rather than through Kartris). Kartris cannot use shared SSL; the secure certificate must be for your domain itself where your site is running, and be properly applied through the Microsoft IIS web server (and not via some external layer as some hosts such as GoDaddy do).

The first step is to check your site has SSL enabled. To do this, simply go to the front page of your site and then edit the address in the browser so it uses HTTPS instead of HTTP. For example,

https://www.demo.xyz/

If you see an error in your browser that the site is untrusted, or that the connection was interrupted, or any other browser error, then SSL is NOT running properly on your site. You should contact the host or your developer if you believe it should be.

Only once you have verified that SSL is installed and working should you attempt to activate the SSL support within Kartris.

Once logged in to the back end, find the general.security.ssl config setting. There are four possible settings ('always on' SSL was introduced in Kartris v2.7000, 'external' was introduced in Kartris v2.9008).

  • 'n' = off
  • 'y' = on for pages where sensitive data is transferred (login, checkout, back end, any page when user is logged in)
  • 'a' = always on, SSL for all pages
  • 'e' = external SSL, applied by a platform like Cloudflare, see 3.2.1.3. External SSL

Scope of SSL
SSL puts an additional overhead on a web server and a user's browser, and so in the past it has tended to be used only in places where sensitive data is transferred, especially for credit card transactions. There was seen as little point applying SSL to all traffic such as when a casual visitor is browsing the site, or a search engine is spidering it.

However, in recent years, SSL has become more widespread. Many web sites such as Google use SSL by default, and the revelations by Edward Snowden of pervasive internet surveillance by western security agencies have further highlighted the issues of eavesdropping and user-privacy. In summer 2014, Google indicated that it would start to give slight preference in its results to sites running SSL, which is likely to see a surge in the take up of 'always on' SSL.

Typically running SSL on a .NET web site involves a setup procedure to create a certificate request on IIS, then using this to purchase a secure certificate from a trusted authority, then installing this on IIS. It also requires a unique IP address, which further adds to the cost and complexity of setting it up on a server with multiple web sites.

Furthermore, most basic secure certificates only cover the www and root domain, not other subdomains. A so-called 'wildcard' cert which supports all subdomains too can be purchased, but it's generally around 5-10 times the price.

Nowadays, Google and others are encouraging sites wherever possible to use SSL, and Google claims to boost secure sites in results.

Fortunately there is now another option for SSL. Cloudflare.com provides a free SSL service which can be used if you change your DNS to Cloudflare.

However, Kartris needs some coding to support this. Previously, when set to use SSL, Kartris would check pages to see if they were secure using Current.Request.IsSecureConnection(). Unfortunately if you just turn on Cloudflare SSL without the updates to Kartris, it will go into a loop, because this code will return FALSE (as the site itself on IIS is running with http, not https).

Therefore, Kartris introduced a new 'e' setting for external SSL. In this case, it will format URLs where appropriate with https, but not do any checks to see if a page is secure.

If you want to force http to redirect to https, you can use the Page Rules feature within Cloudflare to do this. One thing to consider is your payment gateway callbacks. You might find that the https redirect rules interfer with these so possibly at rule number one, you may want to exclude the callback from the Cloudflare cache, so it continues to work exactly as before. Then you can put some redirection rules after that - the free Cloudflare offering allows up to three page rules, which should be enough to handle most things.

Cloudflare page rules screenshot

While the username and password system provides a decent level of security, it is not fool-proof. If your computer is lost or stolen, or some spyware passes your access details to a potential attacker, then an attacker could use your details to access your site. An attacker may also attempt a brute force attack - repeated trial and error attempts and logging in.

Since the number of admin users is typically quite small, and they will normally access from one or two locations (e.g. office or home), then it is possible to apply extra security to the back end in the form of an IP address restriction. For this to work, you must have a fixed IP (or one within a relatively narrow range).

Open up the web.config file in the root of the web, and find this tag:

Into the value, add your IP address, or part of your address. Separate multiple values with a comma. For example:

000.000.000.000,111.111.111

(the first number is a single IP address, the second is a partial IP address)

If you have your own server or virtual server, and have admin access to the IIS web server, you can restrict access to the back end through this.

In IIS 6, the ability to limit access by IP is built in. In IIS 7, you might have to activate this feature separately.

Using IIS to enforce security in this way adds an additional level of security because it is completely independent of Kartris. Anyone trying to access the Kartris back end will be turned away unless their IP address matches one of those you have expressly authorized. Kartris pages won't even get run.

You can also ban particular IP addresses and ranges (although it is far better from a security perspective to 'deny all' and then allow specific addresses rather than try to ban problem IPs and ranges).

Powered by tomeCMS