2014-01-22
Microsoft has become a spam emitter
I'll start by quoting my tweet:
I admire how Microsoft IP address space with no reverse DNS has now become a source of spam emitters using forged HELOs. Thanks, uSoft!
Let me show you the specific log entry that sparked this:
remote from [23.96.34.64] EHLO mail.rackspace.com 550 Unknown command 'EHLO' HELO mail.rackspace.com 250 [...] Hello mail.rackspace.com MAIL FROM:<ps@mail.com> 554 unacceptable from address: <ps@mail.com>
This IP address space is registered to Microsoft and has no reverse DNS. It is certainly not Rackspace. As it turns out this was probably a Windows Azure customer since this appears to be a Windows Azure datacenter range (in their 'useast' region). To determine this I had to dig up a Microsoft document on Azure Datacenter IP ranges from Internet searches.
I'm blaming Microsoft directly here because Microsoft consciously passed up the chance to clarify what the IP address was and who it might belong to. That's what reverse DNS is for, as shown by eg Amazon AWS (which gives their AWS IPs clear reverse DNS). Microsoft opted to keep their Azure IPs anonymous, so Microsoft gets to take the blame.
(Certainly as a sysadmin investigating a problem I'm not going to bother looking further when there is no functioning reverse DNS. Nor can I really do anything more precisely calibrated than acting on the entire registered netblock (not unless I want to pull that Microsoft data on a regular basis and examine it for changes).)
PS: The cynic in me is muttering that Microsoft decided to not do reverse DNS so that people like me couldn't just block based on the domain name being in whatever magic domain. I'm not sure I believe that, but it's certainly a tempting idea. (Anti-spam work makes one a cynic.)
PPS: This is apparently causing problems for Azure customers. I'm a little bit surprised that any large ISPs have started to reject email if you don't have reverse DNS; the last time I looked at this I assumed it was far too risky and not likely to be adopted by anyone major any time soon.
Security is everyone's job (why Ruby is wrong about OpenSSL)
The short version of the Ruby controversy of the day is here. The really short version is that the Ruby core has bindings for OpenSSL, some versions of OpenSSL have defaults that are terrible for security, and the Ruby core developers have decided that they will not change the Ruby bindings to fix these terrible defaults. Instead they are simply washing their hands of the issue and making security the responsibility of users of the bindings (and OpenSSL).
The Ruby core developers are wrong. Security is everyone's job, all the way up and down the stack. If someone below you screws up, it is your job to fix this for your users. By rejecting this the Ruby developers have chosen mathematics instead of people, whether they understand it or not.
I don't say this as a matter of high-minded principles. I say this as a matter of pragmatic engineering because we already know what happens if we don't do this. If you leave security problems exposed by default, some number of your users will do nothing to fix them for various reasons and will themselves be insecure. Often this will be a reasonably large number of your users. If you actually care about security, this is a clearly bad thing. Conversely if you engineer things right and hide security problems by default, many of your users will use your defaults and be secure. The golden rule is that many of your users will never touch your defaults unless they clearly don't work, so they will get whatever security you left them by default.
(Nor is this a novel principle. We've experienced it over and over, across almost every conceivable environment, and not just in the context of security but the context of every single default ever. We know this.)
At this point in time, 'insecure by default' is plain and simply wrong. The inevitable and entirely predictable result of shipping an insecure by default layer is a raft of future downstream security updates as plenty of downstream developers have to individually make the fix that you could have done once, for all of them. Oh, and their software was vulnerable in the mean time.
(And if you argue that your downstream developers should all be smarter than that, as usual you are not solving the real problem. Security is people.)