[Ach] Removed prosody

Pepi Zawodsky pepi.zawodsky at maclemon.at
Fri Feb 20 00:13:32 CET 2015


Long rant about Devs refusing to fix stuff and then taking way too long for it leaving users only with the option to shut down everything and move into a small shack in the woods to drink Single Malt.


On 19 Feb 2015, at 20:14, Matthew Wild <mwild1 at gmail.com> wrote:
Matthew Wild wrote:
> People absolutely should be able to configure their server how they
> want to, and I want to allow that. But there is a real cargo-cult
> approach to system security gaining popularity, instead of securing
> the software upstream. It worries me.

I agree in part. The reason is that developers (in my experience) are only worried about compatibility and will do ANYTHING to make their product work with every other piece of shit on the internet before fixing a gaping security problem that affects their whole userbase.

Exhibit 1:
Adium, a very popular IM multi protocol client. Azet and me have been talking to them for almost 2 years now to finally remove SSLv3. Even after POODLE and POODLE-TLS they have not fixed this. Even though after the excellent effort of the XMPP manifesto so so many XMPP Servers use TLS 1.2 and there is only a handful of crappy leftover servers that only do SSL but no TLS at all?

As a User, I don't have any way to secure my system due to lack of config options. (Not that this would matter on OS X since it doesn't support ANY academically secure cipher anyway but that is a totally different problem.)

Exhibit 2:
znc, an IRC bouncer.
No Security config options other than „optionally use https for the webinterface“ which is, of course, not the default. It does SSLv2, SSLv3 and TLS depending on what is available. There is no way to fix this other than to shut it down. It took several hours of chat to convince them to _at least offer a config option_ for turn off all the insecure cruft instead of hardcoding SSLv[23]. This option is now said to be available in HEAD. Note that they did NOT decide to hard code to refuse SSL under any circumstance and offer config for TLS. They don't want to lose any users!

Exhibit 3:
A gazillion of iOS _ONLY_ apps that require at least iOS 5 (we're at 8.1.3) that use tons of APIs over the internet. If they use HTTPS at all you're already lucky. Keep in mind these are apps that are exclusively available on a platform of which you KNOW that it can use TLS 1.2, since iOS 8 you KNOW it can use SPDY as well which would make it even faster!
These APIs use SSLv3… and often they don't support any better whereas I've been advocating for years to ONLY support TLS 1.2 on such servers since they do not need any lesser protocol.

Exhibit 4:
Apple's iOS and OS X Push notification servers: They supported SSLv3 and that's it. After POODLE TLS broke they updated to TLS 1.0 which broke a ton of developer's push relays. The fix was to switch to TLS 1.0.

Exhibit 5:
Apple's OS X Server: The “best services” support TLS 1.0 only. Calendar and Addressbook are still SSLv3 only.

So, I'd be very happy to at least be able to turn insecure things off by having a config option. Waiting for developers to fix things upstream and to wait until said fixes trickle down to users takes a good 20 years.

If my fix is to turn my IRC bouncer OFF completely that is fine with me. It's not something I can suggest to my customers who use one or another software of any kind. They can't just turn off their Calendaring Server. I mean, sure they CAN, but then they're out of business.

Don't get me wrong, I'm ALL for fixing things in software and helping devs to do this. In reality this approach is needed but takes way to long to react to any emerging threat or disclosure. Businesses out there just won't break things for security. (See Banking Websites… )

Sorry, I'm in a kinda dystopian mood after today's events. :-)

If you know any way to convince developers to fix shit and to convince sysadmins to update servers and to convince CEOs to not force their IT departments to use insecure old crap anymore, by all means, please share it with us! We can only win!

Best regards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20150220/55ccbfc8/attachment.sig>

More information about the Ach mailing list