[sf-lug] HeartBleed OpenSSL bug mini-Q&A

[Rick Moen]

Quoting Jim Stockford (jim at systemateka.com):

>     "Neepery"! Wow! yES! I love it, way to go, Rick!

It's not really a novel word.

> Puzzlement_1:
>     SF-LUG.{com,org} does not serve up any https
> pages, only http static pages. Seems unnecessary
> to document the lack of https services. Did you
> (RM) mean to suggest so?

I'm not sure I quite follow your question.  Or rather, it seems a rather
odd one.

Michael's unthread post reassured SF-LUG (and BALUG) members that
'BALUG.org & SF-LUG.{org,com} NOT vulnerable', and when I asked
what SSL hosts that concerned, he said (in part) that no SF-LUG sites
serve https but that 'folks want to know if their information was or may
have been compromised' -- and my reaction was, compromise of _what_
information?

Even in the case of BALUG, where two minor virthosts (archive and
secure) can be used to get to SSL-wrapped BALUG contents, the
'information' transmitted over SSL for such things struck me as about
the farthest thing from sensitive and secret.  

So, I've felt puzzlement on a couple of those points; thus my queries
about them.

Nowhere did I say 'It's unnecessary to document the lack of https
services'.  You could reasonably conclude that if I'd meant to say that,
I would have employed my passing acquantance with the English language
to, y'know, say it.  So, in short, no.


> Puzzlement_2:
>     "4. A convoluted way a sufficiently motivated person
> might, in theory,locally re-engineer https queries about
> sf-lug.{org|com} to be served from the obscure,
> unadvertised alternate BALUG https host."
>     ??? Seems impossible to me.

Um, Michael alluded upthread to how.  You just jigger an /etc/hosts
entry to send the traffic to secure.balug.org with the needed HTTP
headers.  But, my point is, Michael imagining people doing so just to
engineer a way to communicate with the SF-LUG Web site over https is...
really reaching for an example -- especially given that, as you said,
the site consists solely of a single static HTML page.


> PS I know of more than one current web site that is or
> very recently has been running Red Hat 7.3 for part of
> its operational mix (speaking of the merits of good olde
> software).

{shudder}

Making such as site tenable in light of threats that have emerged since
2002 would be so much work that I have to wonder about the sanity of
whoever's still doing that in 2014.  When I say I'm wary of the patch
treadmill, I don't mean that continuing to run unmodified, unmaintained,
overengineered, buggy code from 12 years ago fully exposed to the public
Internet is a good idea.

Rather, what I mean is what Ranum does:  Instead of running
overfeatured, buggy software and frantically patching it all the time,
concentrate on miminising Internet-facing services and favouring
software that doesn't suck.

Thus, for example, running unmaintained RHL 7.3 in 2014 is nothing like
running maintained, patched OpenSSL 0.9.8 in 2014.  Vive le difference.

If I could jettison the TLS part of OpenSSL completely on my Web server,
I would.  My one recent experiment in doing so found GnuTLS, which I was
horrified to find was a significantly worse option than OpenSSL.  So, I
continue to look for other options.