Firewalls, IDS and sticky tape

More Surface Pro blogging....

I had some issues with some of the Windows 8 apps that rely on Xbox Live sign in - Most seemed to take ages to sign in and others refused to sign in at all (SmartGlass in Windows 8!!!). I'd been poking around BitDefender and just couldn't deep enough into the configuration so removed it and went back to ESET.

After fiddling around trying to resolve SmartGlass sign in error 0x3ec with no success, I made some changes to get everything else working...SmartGlass now shows error 0x3ea and I've stopped wasting any more time on it.

[Please note - SSL scanning in original post, but see update comment at end of post]
Long story short - I often enforce an SSL scan (just because a service uses secured transport doesn't mean someone's cocked up something within the delivery), and this was basically what was causing the issue. After adding some certificates as trusted or excluded the whole sign process was fine.

Excluded certificates: login.live.com, storage.live.com
Trusted certificates: none (other than what you already have)

Not happy that some certificates have to be excluded from SSL scanning but a leap of faith needed to get features operational. Don't forget to disable all obsolete versions of SSL (TLS 1.x > only!) if the option exists in your security system.

In addition to that firewall rules need to be added for outbound traffic.

Application: {windows}\system32\WWaHost.exe
Application: {windows}\SysWow64\WWaHost.exe
Protocols: TCP
Ports: HTTP, HTTPS (ports 80 and 443 by default)
Direction: Outbound

The net result is that I have Windows 8 applications working and still isolated by the OS, IDS and SPI features working. There was an issue with a previous version where if your Xbox was wired to the network and you were using wireless for your SmartGlass device the two could not communicate - They needed to be on the same wireless network. I can understand why that might have been done but it renders the features pointless for me (it just doesn't fit the topology we need here at home).

As I've invested too much time already in SmartGlass I just uninstalled and moved on, but the rest of Xbox One, 360, SP3, Windows and WP are operational again.

Update 25-07-2015

I've now disabled SSL scanning in a few security suites due to concerns about privacy and chain management. A number of well thought of systems will not work with SSL scanning enabled (due to the way in which many security suites insert themselves into the chain). The firewall rules mentioned here could still help you but I no longer recommend SSL scanning
As part of my study for things like CEH I'm building a home IDS separate from these software components - these suites are fairly good for most people but anyone who does a lot on their home networks should consider defence-in-depth these days.

Silver bullet? No such thing

With recent activity surrounding OpenSSL / LibreSSL / BoringSSL and the ongoing debate into the feasibility of open source quality control, it may be worth sharing a couple of quick tips to help.

Changing passwords on systems affected by heartbleed isn't going to fix the problem - intruders can still get in and insert themselves in between you and the destination. Once the vendor has resolved the issue with the OpenSSL version in use on their web server or router, its better to ensure a few settings (where available) are enabled in your browser.

I had a look at Chrome, Aviator and IE and they all have these settings, but as I've stopped using other browsers I can't answer for the likes of Firefox or Safari - I'm sure they must have similar options by now.

• In the HTTPS section of settings there will be a check box worded something like "Check for certificate revocation". Ensure this option is enabled / checked as it will ensure that once the vendor has updated OpenSSL they will get new SSL certificates and revoke the previous ones. This option ensures no-one can use the old certificates to impersonate.
• Enable SSL scanning in your security suite - Usually vendors tuck the setting away somewhere in advanced settings, but your protected traffic should also be liable to the same scans as your normal web traffic.
• Ensure that use of obsolete secure layer protocols are rejected - A lot of home & personal security suites should allow you to do this easily and it will be worded something like "Block encrypted communications using obsolete SSL v2 protocol".
• If at all possible, force use of TLS 1.2 - this won't be possible everywhere as not all vendors and services have upgraded. Avoid use of TLS v1.0 if possible. SSL v1 was created by Netscape 1995 so don't expect it to be so helpful 20 years later. TLS v1 dates back to 1999 so be realistic about that too. TLS v1.2 was "defined" in 2008 and v1.3 is currently in draft.
• IE has an option (set to enabled by default I think) called "Warn about cert. address mismatch", make sure this is still checked. It will provide a warning if the certificate was issued a domain other than the one the client-server communication is actually happening on.

Please note: This is just a thin slice of the solutions available of a much wider problem. I hope that going forward that vendors such as browser manufacturers and cloud solutions firms start making these settings default.

I did ask BT if their devices were susceptible to Heartbleed but got no response - I will assume that the answer was "yes" and there's no documentation indicating whether an update has been applied to the closed system. BT tried to tell people that even though their devices were vulnerable it wouldn't matter because the intruder would have to be able to access your network to take advantage of the problem. Omitting that their devices are wifi enabled routers with guest networks for BT FON.

A lot of admins panicked in the days following the Heartbleed reports and updated their systems with the faulty version so it pays to be a bit more careful as the end user. Don't assume there's a warm blanket encasing your journey online and take responsibility for yourself.