Summary - YES, USE SSL!!!

Everyone should use SSL to secure their web site. Cost is not an obstacle because you can get free SSL certificates from Let's Encrypt. We have grown fond of two tools for utilizing Let's Encrypt on Windows Servers; Let's Encrypt Win Simple, a very advanced command line tool and Certify the Web, an easy-to-use GUI. 

SSL provides encryption of web page requests over the wire using https:// instead of http:// for the beginning of the url. To use SSL, you must install an SSL Certificate from a Certificate authority on the web server and enable it on your site. Most hosting companies can help you with this.

Once you have an SSL Certificate installed on your site, follow these instructions for setting up mojoPortal to use it properly.

Why Do I Need SSL?

Because bad guys are everywhere and they want as much info about you as possible so they can steal from you and others.

SSL is used to secure content sent over the internet by encrypting the packets so that it is not possible to get the contents by packet sniffing. You may think there is little risk that someone is sniffing packets but these days it is very easy to sniff packets using one of hundreds of tools available freely on the web. Even though IP Packets are addressed to specific IP Addresses, network cards configured in promiscuous mode can capture packets that were not addressed to them easily. It is particularly risky on public Wi-Fi networks in airports, coffee shops and elsewhere, you should assume there are people on the network actively trying to capture your packets.

But What is the Risk If My Site Doesn't Have any Sensitive Data?

High Risk because people use the same password for their frivolous online activities as they do their bank accounts.

If you are using mojoPortal content management system to run your site that means you will need to sign into the site to edit content. So, the first level of risk if someone captures your packets while you are signing in, they can get your username and password and then they can sign in as you. By using SSL, the credentials will be sent inside encrypted packets.

Old school thinking was that it is sufficient to just use SSL on the login page, the register page, the user profile, or only specific pages that would contain sensitive data. But when you sign in cookies are added to your web browser that prove you are authenticated with the site and that establish your roles. Once the cookies are assigned the web browser passes them in the request headers as you navigate through the site and if you then visit a non-secure page then the cookies could be stolen by someone who can sniff your packets. Then they can make web requests to your site passing the same cookies in the request headers and now they can interact with the site as you and with the same roles as you, so if you are the site administrator that means they can now manage your site.

So, the new school of thought given how easy it really is to sniff packets on public networks, is that once you are signed in you should remain in SSL (i.e., all URLs should use https) for the remainder of your browsing session until you sign out. When you have SSL enabled in the latest version of mojoPortal this is how it now behaves at least in terms of links generated by mojoPortal. If you are on a secure page and you click a link that uses a relative URL then it inherits the https protocol and links generated by mojoPortal use relative URLs so the default behavior will keep you in SSL as you navigate the site unless you click a link with just http or if you were to type in an URL directly using http.

By default, if you make any request for a non https URL within the site it would still send your cookies in the request header and that would mean that someone could sniff the packets and steal your cookies from just that one request. But there is a way by configuration to prevent this. In the Web.config file you can make settings that tell the browser not to pass the cookies on any requests if they are not using SSL. If you look in the mojoPortal Web.config file you will see the needed changes in comments:

<authentication mode="Forms">
<forms name=".mojochangeme" protection="All" timeout="50000000" path="/" cookieless="UseCookies" />
<!-- if you have an SSL certificate installed you should add requireSSL="true" to make sure that the auth cookie is not
passed in the request header for non ssl requests:
<forms name=".mojochangeme" protection="All" timeout="50000000" path="/" cookieless="UseCookies" requireSSL="true" />

-->
</authentication>

 

As shown above you would want to add the requireSSL="true" on the forms element. We also by default force the role cookie to only be passed over a secure request if SSL is available. You could override this by adding a setting to user.config like this:

<add key="RequireSslForRoleCookie" value="false" />

However, it is best to not do that since the default setting protects your role cookie. If someone on a local network could steal your role cookie, they could gain elevated privileges in your site.

Other cookies issued by the site are mainly cosmetic in nature, such as the one to toggle the collapse state of the admin toolbar. These cosmetic cookies do not have security implications but for good measure and security vigilance you can also add this setting inside the system.web element of web.config to secure all other cookies:

<httpCookies httpOnlyCookies="true" requireSSL="true" />

These settings are enabled on this site, so you will see if you sign into this site you remain in https for the rest of the session, and if you do manually change it to http or if some link on the site may have only http if it is not using a relative URL, then what will happen is the cookies are not passed in those requests and therefore you do not appear to be signed in for those requests, and you will see the sign-in link appear on the page. Then if you click the sign in link it will go to a secure page (ie the login page) and once it is there, since it is a secure request, it will now detect your cookies again and see that you are already authenticated so you are not forced to sign in again.

In summary there has been a change in tide in thinking about where you should use SSL. You really need to use everywhere for authenticated users and you really should configure it to prevent passing cookies for insecure requests to protect yourself and your site users from session hijacking. If they can steal your cookies, they can then use your cookies to hijack your web session because now they are interacting with the site as you. They can change your password or anything else that you can do once they have done that. That is why you see all major sites such as Facebook, Twitter, and Gmail all use SSL for every request. SSL is still important for securing any private data on your site, but even if you don't have any sensitive data on your site, it is all about protecting your user's cookies.