A quick introduction: by day, I'm a DevOps Engineer at Red Gate, a software company in Cambridge, UK. Outside of work, I enjoy both amateur radio (hence the callsign, M0VFC) and community broadcast radio at Cambridge 105. This blog aims to span all those interests - so feel free to ignore the posts that aren't relevant!
Feel free to get in touch on Twitter (@rmc47).
73 / Best wishes,
Rob
After applying the latest set of Windows Updates to some of our EC2 instances, we saw some problems, including very high CPU utilisation by lsass.exe. The strange thing being, it only happened when that instance was listed in an EC2 Load Balancer's instance list - even if there was no traffic hitting that load balancer.
I spent some time this evening tracking it down, and it looks like there's a serious interaction between the patch for the Microsoft SChannel vulnerability and EC2's load balancer.
Here's the reproduction steps:
With that setup, run Wireshark on the instance. As soon as the instance is in service on the load balancer, you will see several Mbps of HTTPS handshake traffic between the two. Remove the instance from the load balancer, and after a short period, the traffic stops.
Now, uninstall KB2992611, reboot, add the instance back into the load balancer, and observe everything behaves as expected - only the occasional health checks and one or two handshakes.
By way of comparison, 10s of Wirecast capture with KB2992611 installed resulted in a 20MB capture file; 90s without it installed was only 53kB.
If you then manually download and reinstall KB2992611, the problem recurs, with very high traffic levels.
If the instance is not behind an EC2 Load Balancer, direct HTTPS access from Chrome appears to work fine, with no abnormal traffic observed.
My guess is it's a cipher negotiation issue, but at this point, my knowledge of TLS is inadequate to say any more...
Update: disabling TLS 1.2 works around the problem.
If you're affected, set the following registry key to disable TLS 1.2. This causes TLS 1.1 to be negotiated, which is successful:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:00000000
It's probably better just to disable the affected ciphers though, as [now - 2014-11-17] recommended by Microsoft.
Update 2, 2014-11-12: Amazon have acknowledged the issue, and are on the case: http://aws.amazon.com/security/security-bulletins/ms14-066-advisory/
Update 3, 2014-11-17: Microsoft have acknowledged the issue, and updated https://support2.microsoft.com/kb/2992611 with a workaround. Thanks @superkully for the spot.
Tomorrow morning, I'll be flying off to Bermuda - callsign prefix VP9 - for just over a week, along with Martin G3ZAY, Michael G7VJR and Dom M0BLF.
We'll be active from Thursday 20th to Thursday 28th February, mostly on the higher HF bands, since we're near the top of the sunspot cycle. Bermuda is often active in contests, so we'll pay a good amount of attention to the WARC bands (12/17/30m). The power limit on the island is 150W, so no linear amplifiers are allowed. As a result, we'll probably do quite a bit of CW to make the most of the power we have available.
Equipment wise, we're taking three Elecraft K3 transceivers, and one Kenwood TS590. We're staying with Ed VP9GE, so should have access to his antennas, but we're also taking lightweight verticals and dipoles to augment these and allow us more stations on the air simultaneously.
QSL for VP9/M0VFC, VP9/M0BLF and VP9/G3ZAY should be using Club Log OQRS (preferred) or via our home callsigns. VP9/G7VJR should go via M0OXO. All logs will be uploaded to LoTW as soon as possible.
Many companies say they listen to their users' feedback. Often, that seems like a false promise, but sometimes it's for real, and the last couple of days have turned up a few examples of this.
Last October Eben Upton, of Raspberry Pi fame, gave a talk at the RSGB Convention. But better than that, he stuck around afterwards and spent quite a while chatting to a few of us, myself and Pete 2E0SQL included.
We spoke about what features the Pi could usefully add to better support Software Defined Radio (SDR) applications, and hardware-accelerated Fast Fourier Transforms (FFTs) were pretty high up the list. If you're not familiar with these, they take a chunk of signal in the time domain, and transform it into the frequency domain - in other words, you give it a chunk of signal, and it breaks it down into frequency components.
This is something that the Pi's rather powerful graphics processor can do much more quickly than its main CPU. Today, they've announced a GPU accelerated FFT library. Thanks all!
At Red Gate, we use GitHub for source control. This means that someone compromising one of our developers' GitHub accounts potentially gets access to a lot of our source code.
Using 2-factor authentication reduces this risk considerably: not only must an attacker compromise a password, they must also have access to the owner's mobile phone. However, to make this defense effective, we need everyone's accounts to have 2-factor authentication enabled.
Previously, there was no way of doing this automatically, and towards the end of last year, I asked if it would be possible. This week, GitHub announced an API filter to get organization members with 2FA disabled, so now we can automatically nag people who don't switch it on!
If you use Amazon Web Services, their reserved instances provide a way of significantly reducing the cost of services you use for a long time - you trade an upfront commitment of a year or more for lower hourly rates. However, it's historically been quite tricky to see whether your reserved instances were being used efficiently - something I've spoken to Amazon about before.
Handily then, they've just announced a reserved instance utilization report, which solves the problem neatly for EC2 instance...
All in all, a rather positive week!