Traditionally if one was to secure a web server using TLS (or previously, SSL) – then one would configure your web server to use TCP port 443 to listen for TLS requests from clients (browsers). When a browser connects to the web server using the HTTPS protocol, the server would encrypt the communications and all would be well with the world.
A problem occurs when you use name based Virtual Hosting on your web server. If you need to determine the client request before providing content from a virtual host, e.g. blah.com vs. blahblah.com, then this couldn’t be done if you encrypted the communications using TLS. Enter stage left: Server Name Indication.
According to Wikipedia:
Server Name Indication is a feature that extends the SSL and TLS protocols. It permits the client to request the domain name before the certificate is committed to the server. This is essential for using TLS in virtual hosting mode.
I’ve a need to use Server Name Indication (SNI) for some freelance IT work I perform, but colleagues shy away from SNI since Internet Explorer on Windows XP is unsupported.
Is this an issue? Are so many people still on Windows XP that it will diminish the security aspects of implementing SSL to secure input of personal data ?
One of the best places to determine OS usage trends in Australia would be from Google, but they don’t provide such data. Therefore I turn to another source of data: StatCounter. They have been providing stats to websites and business for well over 10 years, so their data should be viable.
Source: StatCounter Global Stats – OS Market Share
The chart above shows Operating system usage for 2014 in Australia. Windows XP sits at 4 percent usage at the end of 2014. For an operating system that’s now unsupported and 4 Major versions old; it just shouldn’t be considered anymore.
Source: StatCounter Global Stats – Combine Chrome (all versions) & Firefox (5+) Market Share
The second chart shows browser usage statistics in 2014. Internet Explorer 6, which doesn’t support SNI, isn’t even on the chart anymore.
Knowing the actual statistics – the usage of Internet Explorer 6 (or a lesser version) and Windows XP seems to be so minimal that usage of SNI is a viable option; especially where it gives a rise to cost saving on implementation of x509 certificates on web front ends. What do you think?
A client I’m consulting for is using Jive as their EDRMS of choice. It’s not bad; but after using Office 365 recently, Jive is not as integrated as you’d like with Office 2013.
Working in the cloud (Jive is a cloud EDRMS) requires that another client you may connect from have the appropriate client plugin. In the case of Office 2013, you need to install the Jive plugin from their community website. It’s not easy to find, but it can be found.
The first issue I hit after installing this is that the 64bit version of Office 2013 disabled the COM Add-In. This occurred using the Jive extension version 30.1.655.15760.
After digging around on the support community pages; there is a registry fix to make the plugin compatible with x64 office clients. The one provided was for Office 2011; so I’ve included here a modified registry file for Office 2013 64bit edition.
Steps to get the extension working are:
- Uninstall the Jive for Office extension.
- Import this registry file for windows:
- Reinstall the JiveOfficeInstaller.msi
After that; success!
Jive extension now working in Office 2013 x64
I’ve recently been working more day to day on Amazon Web Services, and I found it a little unwieldy to navigate around policy documents assigned to IAM groups.
Sometimes you just want to have a local copy of the policies to edit/play with/look at.
Therefore, I came up with a quick script to solve this. Enjoy…
Of course, the AWS SDK for Powershell is required.
Next entries »
I host this blog in WordPress, and it’s a great micro CMS with all the bells and whistles. I also publish and host the XML file for a podcast of the Angry Human. It’s picked up by feed burner, and then iTunes takes the feed burner RSS feed and et voila! All the Apple listeners to the show Angry Human by David Biedny get their recent shows!
I recently had an issue where I’ve moved this site from Rackspace Cloud Sites to the Godaddy Managed WordPress sites. One of the things that was happening was the URI for the podcast XML RSS feed was returning as a 404 not found; even though it was there. Nothing I tried made this thing work, and nowhere could I find other people talking about RSS XML files published alongside wordpress not working. Even adding a new .htaccess file in the subfolder on the server to turn off URL rewrites did not work.
Another client I had recently worked with wanted some SEO optimisations, and we ended up implementing the awesome WordPress SEO plugin by Joost de Valk . One of the things I had noted about this plugin on the Godaddy hosting, was that the XML site map feature used to help bots index the site, was not working. We fixed this quite easily with a commonly known fix in the .htaccess file on the WordPress host.
I had not groked this similar error until an “Aha” moment when I realised an XML file, whether it be sitemap.xml or angryhuman.xml had been invoking the same rewrite error causing a 404 not found on a valid URI for a hosted file. Double checking and I had indeed implemented WordPress SEO plugin on this site.
The root cause: any self published XML file outside of the standard wordpress folders on a GoDaddy Managed WordPress Site – will return a 404 not found if you are using WordPress 3.9 and WordPress SEO by Yoast.
Therefore the fix in this case for my self published XML feed for Angry Human was adding this to the .htaccess: