I've been doing a lot of thinking about how to extend the core to more adaquately support and encourage secure websites (SSL over HTTPS).
I see three major problems with SSL support.
1) There is currently no integrated support for selective SSL, it's all or nothing.
This comes with a number of concerns. Having an entire site secure means dealing with incorrect links, performance issues, and potentially some search engine issue. This could be easily solved by implementing a "Require SSL" option at the module definition level, the module level, the page level, and the host level. Implementing this feature would almost parallel the logic already in place for module caching... At page request, DNN would discover if any component of the page to be rendered will require SSL, and if it does - respond with a redirect replacing http:// with https://.
2) There is not as much social / administrative push to see SSL implemented.
This is a huge issue. I've found shopping cart mechanisms that poorly implement SSL or don't implement it at all! Not even www.dotnetnuke.com has SSL enabled for login! allowing for unencrypted login and session cookies means that DNN is suseptible to attacks from anyone able to sniff network packets. If the DNN host account was sniffed - a malicious user could execute SQL statements, if SQL isn't locked down from the default NETWORK SERVICE account - this means that for servers using the full version of MSSQL - a SQL job could be created that executes code on the server... It's a big issue! Think about how often someone logs in as an admin or host over unsecure means. I've been shocked to see how little concern there is over SSL support - lets not wait until someone makes an example out of the product.
3) Limitations of IIS mean that only a single root domain can be secured on a particular DNN application at once. Because I host enterprise websites that need their own domain name and security to accept credit card transactions; I have had to resort to using a separate DNN application for each website I host - this kindof defeats the purpose of supporting multiple portals for similar websites on the same machine.
These IIS limitations are what I would like to address with this conversation. A little bit of research has shown me that IIS could be programatically configured while it's running by manipulating the XML metabase... This could open up the opportunity to have each portal its own website in IIS, allowing each portal its own root domain SSL Certificate.. In addition, this could mean that host headers could be managed directly from DNN, and not have to be mirrored in IIS. In the end, while it may become a little more difficult to host on generic 'hosting providers' - we would end up with a product that would be way more secure out of the box - encouraging SSL and allowing DNN to stand out from the rest of the open source CMS products out there.
The only other issue would be that each configured website in IIS would need to be running the same in-memory version of the DNN dll. This could happen by having DNN registered in the GAC.
I realize that i'm proposing some very time-intensive work, but I really think that this would bring DNN into a new level of maturity. V4.4 focused on performance, V4.5 focused on user experience... it would be nice to see one version in the next year seriously address security issues that have been lingering for some time now.
I am interested to hear some comments about the feasibility of these kind of changes, as well as some alternative ideas. There may be a way to get code to be shared without using the GAC - perhaps just by having websites in the same application group they'll be able to share components?
Comments or concerns?