Back to: Yet another bad idea | Forward to: "Write me something fresh and new, but make it just like the last one"

Heartbleed note

Some of you might have noticed something called heartbleed generating a lot of tech news smoke and heat this week.

This web server runs on Apache, yes. But I don't provide an encrypted server connection over SSL—it's an unencrypted set-up because I'm not in the business of selling you something or handling your confidential information, and I don't see a pressing need to make your life and mine more complicated in order to provide an illusion of (non-existent) security. If you're not running an SSL encrypted service in the first place, then you're not vulnerable to a particularly nasty zero-day hitting OpenSSL. QED.

This is not to say that I won't be patching the OpenSSL setup on my colo box in due course, because security is next to godliness or good oral hygiene or something. But I'm not running around panicking. You aren't trusting me with your credit card details or your Google account credentials, and if you were, you can only expect me (or any commercial web server) to provide limited security against non-state actors. For example, if the folks at the Donut in Cheltenham want to read my blog, patching SSL isn't going to keep them out: (a) the machine isn't under my physical control, and (b) there's this little thing called RIPA(2000) that gives them the legal power to demand access to my private keys under a gagging order and on pain of imprisonment if they want to play medium-heavy. Or to go raid my colocation host (see (a)). Playing heavy-heavy in this context would involve armed police or drone strikes or ... you get the picture.

We live in a panopticon, and it's time to get real. Yes, we should look to our security updates for protection against "ordinary" criminals. But if you're worried about the government, patching NSA-exploited zero-days is a bit like trying to treat a bubonic plague outbreak by hanging a sprig of lavender over your front door: at best it's a displacement activity, while the cure lies elsewhere.

45 Comments

1:

You're probably right about there being very little security risk to this site.

But generally speaking it's smart to provide SSL to users, just to increase world-wide encrypted traffic. If only valuable stuff gets encrypted, it's immediatly clear wht is really valuable to an attacker.

2:

Encryption is mostly not for protection about targeted attacks, which usually have many other possible avenues - but to protect against mass collection of communications or at least raise its costs considerably. So yes, individuals will be crushed - but society as a whole can raise the stakes.

3:

it's smart to provide SSL to users, just to increase world-wide encrypted traffic

This is true. However, my server hosts a number of domains, not just antipope.org, and has a single IP address. I use named virtual hosts on Apache to take requests for servers in these domains and show them the appropriate view of the web server filesystem, with a wildcard match that points IP lookups at the obvious place -- antipope.org. Adding an encrypted server isn't just a matter of installing a public key and telling apache to run ModSSL on the right port; I'd also have to re-jig everything and decide which of those virtual servers get the SSL connections, and how to serve up the right certificates and stuff. All of which, my pet sysadmin advises me (because I'm so out of practice at running my own public-facing server that I pay a professional to do it for me, these days) is a bundle of not much fun at all, actually. Oh, and getting those PK certificates would cost me money.

So I'd be spending money and brains and time to gain ... not much at all, really.

Note, however, that the instant I see a reason to start selling something direct from my website, or tracking your inside leg measurement (or retaining other personal information that the Information Commissioner's Office might be interested in the disposition of), this policy will be revised faster than Kim Jong-Un's politburo line-up during a purge ... on Ex-Lax.

4:

At what point in the future will internet security become trivial enough so that bugs like this are no longer possible?

5:

It's pretty trivial, you can define multiple SSL sites easily, e.g.:

NameVirtualHost *:443

[VirtualHost *:443]
DocumentRoot "/files/example.org/"
ServerName example.org:443
ErrorLog "logs/example.error_log"
CustomLog "logs/example.access_log" proxy
SSLEngine on
SSLHonorCipherOrder on
SSLCertificateFile /etc/pki/tls/certs/example.org.crt
SSLCertificateKeyFile /etc/pki/tls/private/example.org.key
SSLCACertificateFile /etc/pki/tls/certs/someca-bundle.crt
[/VirtualHost]

if you need help feel free to ping me.

6:

In general, I'd like to see strong security as a default. SSL, alas, is neither strong, default nor particularly secure. It's also a pain to set up.

Amusingly, there is a proposal in draft for an EU prohibition on dangerously bad security (in the sense of confidentiality) which I've been wishing we might have in Canada... see Slaw, http://www.slaw.ca/2014/04/09/secure-communications-by-mandated-design/

--dave

7:

It's actually not trivial, because you need to have a single certificate that is valid for all of the hosts running on it.

http virtual hosts work because the HTTP connection says "Use this host." With https, however, you can't say which host to use until you've already established the encrypted connection. Which requires the certificate.

8:

It's much easier now to do SSL virtual hosting on a single IP and there are many choices:

- SNI, which seems to be preferred way now that browser support is ubiquitous https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

- wildcard certificate (if 2nd level domain is the same)

- multi-domain certificate

- non-standart port (i know this is stretching it a bit, but you can serve redirects to SSL site on proper port when accessed via http)

--igor

9:

Never.

Computer systems are among the most complex things built by man, and security systems are among the most complex things among computer systems. Conceptually, things may be simple, but there is lots of complex math, oodles of things to look for and keep track of, and so on.

Both the recent Apple SSL bug and this one were due to relatively trivial programming errors that caused unintended behaviour in certain use cases. Sure, you can say "don't use C for this", but what is the alternative? The ever-patched Java? C++, which is just like C with added stuff?

10:
It's actually not trivial, because you need to have a single certificate that is valid for all of the hosts running on it.
You don't have to do that if you use SNI and most browsers support it (IE on XP being the notable exception, but I imagine most readers of this site don't use that browser).
Oh, and getting those PK certificates would cost me money.
StartSSL offers free certificates (but they charge for revocation and wildcard certificates).
11:

Ubiquitous SNI is new since last time I looked into SSL. Nevertheless: I can't be arsed spending money and time doing this without a good reason. (You'd rather I used the time to write more fiction, wouldn't you? Admit it!)

12:

I just read a very nice analysis of the bug here - http://www.hackerfactor.com/blog/index.php?/archives/606-Heartbreaker.html

The author suggests that the issue is a bit overblown - certainly it is a potential issue, but not a "omg reset all your passwords now" one necessarily. Reason being, the bug depends on uninitialised memory being read by the attacker - memory that could contain certificates or passwords or god-knows-what.

Except this rather depends on how exactly your OS performs memory management. They haven't naively passed about unintialised memory like this for years - linux always reuses the same memory, macs always zero-out, so neither is actually vulnerable by default.

13:

People are seeing "OpenSSL bug" and somehow misinterpreting this as "HTTPS bug". AIUI, if you're running, say, a mail server that accepts mail from the outside and is willing to negotiate an encrypted connection, you're vulnerable there too.

14:

Ssh! (But I am informed that no TLS attacks relying on Heartbleed have been observed in the wild ... yet.)

15:

"You'd rather I used the time to write more fiction, wouldn't you? Admit it!"

+1 Insightful. Dorking around with the web server when you don't have to has all the bad points of work, none of the good ones.

(I haven't even made it through all the discussion threads on picking a decent CA yet.)

16:

Well, at this point, Heartbleed exploits have landed in the Metasploit framework, so if the black hats aren't using it yet, they will be very shortly.

Looking back further, at least one security researcher has found apparent Heartbleed exploit attempts in log files dating back to November, 2013 --- several months before the announcement:

https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013

17:
Except this rather depends on how exactly your OS performs memory management. They haven't naively passed about unintialised memory like this for years - linux always reuses the same memory, macs always zero-out, so neither is actually vulnerable by default.

There were actively demonstrated attacks on Yahoo and ArsTechnica, both of which use Linux. OpenSSL does not use the system malloc(3).

18:
Ssh!

Maybe that too - I can't remember if that uses openssl.


(sorry, couldn't resist a cheap pun...)

19:

At what point in the future will internet security become trivial enough so that bugs like this are no longer possible?

When the power goes off for good.

20:

It also depends on whether or not OpenSSL actually uses the system malloc. Turns out it doesn't. And that - surprise, surprise - they got it very, very wrong when they tried to implement their own internal free list to "work around" a slow malloc on some systems.

I'm with Theo and Ted on this one. When it comes to security-related software, keep it simple. Malloc is slow? Use it anyway - the implementation might improve, and trying to work around the problem in your own code increases - exponentially - the likelihood of bugs.

21:

I'm guessing you have outsourced other things in your life like you have an agent, and I'm guessing an accountant. Have you perhaps considered outsourcing the technology? That would allow you to specialize more on the stuff you do appear to enjoy such as death march writing binges =)

22:

No, ssh is not affected.

While openssh *does* use the openssl library for some of the crypto functions, it doesn't touch any of the network traversal stuff (which is what heartbleed attacks).

23:

You'd rather I used the time to write more fiction, wouldn't you?

Well, yes. As has come up before, we can find web nerds under every other rock - but the global supply of Charles Stross fiction producers is sharply limited!

24:

> StartSSL offers free certificates (but they charge for revocation and wildcard certificates).

They charge for revocation, but don't charge for wildcards. I got a free class 1 certificate for *.example.com.

25:

OPENSSL_malloc is a macro replacement for CRYPTO_malloc.

CRYPTO_malloc is defined in crypto/mem.c. It calls "malloc_ex_func". malloc_ex_func gets defined during the initialization. According to the definition in crypto/crypto.h:
#define CRYPTO_malloc_init() CRYPTO_set_mem_functions(malloc, realloc, free)

This definition sets malloc_ex_func to 'malloc'. That's the standard system malloc.

Reference: https://github.com/openssl/openssl/blob/master/crypto/crypto.h lines 352 and 384.

26:

I should have added to this comment but somehow omitted - this is the original author's comment addressing this point.

27:

The other reason not to bother with SSL unless you actually need it is because it places a demand on /dev/random and on a big server with a lot going on, you may start running low on truly random numbers.

Quantum electronic noise random number generators do exist, but I've not yet seen anyone building motherboards with these built in (which would be very nice to see), nor are PCI cards with these devices on them very common. USB sticks are the usual form factor, which is distinctly sub-optimal for a server environment.

28:

Intel CPUs used to have a very useful on-chip HWRNG.

ID Quantique make add-on hardware sources in card and USB formats. They actually use shot-noise from illuminated photodiodes as the noise source, because the expected behaviour is rather easily calculated from quantum statistical mechanics.

29:

I'm not sure if you missed the joke, or I'm missing yours.


Meanwhile: Oops?
Heartbleed coder: bug in OpenSSL was an honest mistake

31:

The craziest thing about the heartbleed hype is that it's not proportional in the least to how serious it is (compared to other recent vulnerabilities in the SSL/TLS domain).

This is not to say that heartbleed isn't bad. Heartbleed is bad. An attacker can use it to dump passwords, private keys, and other things. However, it's not conveniently and trivially weaponizable (although it has been partially weaponized recently, as a proof of concept).

A lot of the hype around heartbleed within the relatively non-technical media, to the extent that it hasn't been unfocused screaming about how the whole internet is broken forever, has been asking whether or not the bug was an NSA plant. Well, if it was, it was a stupid one: if you wanted to inject a vulnerability into the crypto code of every major corporation, heartbleed would not be the one you would make. You get data, some of which might be sensitive, but the data you get will be relatively unstructured (you get the contents of a dirty palimpsest buffer); if you hit it too infrequently you'll either not get anything interesting at all or you'll get small truncated/corrupted bits of interesting information which are now more or less useless; if you hit it too frequently, the buffer will be filled entirely with the stuff from your request.

Compare instead with Apple's 'goto FAIL' bug, and the nearly-identical bug in gnuTLS. These bugs are, if you were the NSA, almost exactly what you'd want to plant. The bug is kind of hard to notice, because of the brain's normal de-duplicating circuitry (the the same reason you have a hard time counting the the instances of the the word 'the' in this parenthetical phrase); it completely circumvents the only defense any browser has against DNS spoofing; it makes extremely targetted man in the middle attacks trivial; it doesn't require the attacker to search for keys or store keys or do anything any more complicated than decrypt and open up another encrypted connection on the other end with some dumping or logging in the middle; it doesn't affect anything other than https. If your use case is to intercept someone's webmail or social media activity, it's perfect.

The only media attention that 'goto FAIL' got was a handful of 'lol apple' stories on tech news sites, with comment threads making 'goto considered harmful' jokes and criticizing brace style. Why is heartbleed getting mainstream media attention, when it's more opaque, less dangerous, less easy to weaponize, and fundamentally less likely to have been used?

33:

The only media attention that 'goto FAIL' got was a handful of 'lol apple' stories on tech news sites, with comment threads making 'goto considered harmful' jokes and criticizing brace style. Why is heartbleed getting mainstream media attention, when it's more opaque, less dangerous, less easy to weaponize, and fundamentally less likely to have been used?

Why do you think heartbleed is less dangerous? It was actually easy to weaponize (have you looked at the sample exploit code?), didn't leave traces in most logging setups even for retrospective detection, and didn't require access to your target's live communication stream.

Oh, and according to reports today the NSA discovered heartbleed two years ago and has been using it: http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html

34:

Also: because it's got a nice, evocative name ("Goto FAIL" vs. "Heartbleed"?), a pretty website, and there's something users have to do (other than "wait for the patch").

35:
if the folks at the Donut in Cheltenham want to read my blog, patching SSL isn't going to keep them out

Of course it will! I mean, if they want to see traffic *really badly*, they'll use techniques that carry a risk of detection. But they don't care *that* much, they just *sorta* want to see all the traffic.

Casual encryption can defeat casual surveillance.

36:

Charles you say
"But if you're worried about the government, patching NSA-exploited zero-days is a bit like trying to treat a bubonic plague outbreak by hanging a sprig of lavender over your front door: at best it's a displacement activity, while the cure lies elsewhere."

So, on the subject of "... the cure lies elswehere" where does the cure to government snooping lie?

37:

So, on the subject of "... the cure lies elswehere" where does the cure to government snooping lie?

At last! Someone asked the right question!

The answer clearly lies somewhere in the solution space known as "politics", because this isn't a technical problem, it's a systems-level one.

The trouble with this, however, is that our current political system has a huge blind spot called "the war on terror". Almost any draconian policy can be justified by an appeal to the precautionary principle given a high-stakes bogeyman, and any elected politician who slackens off on the pursuit of terrorists by any means available will be crucified if there is a subsequent terrorist incident (even if there's no evidence that the policies they oppose would have prevented it).

So we have a system of perverse incentives in democratic politics that (a) motivate the security agencies to extend their reach via mission creep ("we have a task; this tool might help us do it; therefore we need this tool") and (b) provide strong disincentives to elected politicians who might yank on the brake handle.

Figuring out a solution to this sort of trap is going to be hard, but it might be possible if enough elected politicians come to agree privately that things have gone too far; then, if they move as a cross-party group, by consensus, nobody has to go first and take the blame if anything goes wrong.

See also, walking it back on the war on drugs.

38:

Ada. Fast, robust, secure, provably verifiable, designed for writing software that really, really needs to work, and it's been around since 1980.

Turns out that people don't really want languages which are fast, robust, secure, etc, so it never really got much traction outside specialist areas (such as defense). The saddest thing about working in the computer industry is nothing ever seems to be learnt.

39:

The saddest thing about working in the computer industry is nothing ever seems to be learnt.

Not only that, the next iteration of the unlearned lesson involves virtualization and heaps of XML.

40:

The other thing that might work is when there are critical failure of Big Data. So far, we've had embarrassing and totally predictable failures of Big Data. Unfortunately, it's going to take missing a pandemic or some such issue where a large number of innocent members of the Us crowd die to show that there's nothing to be gained from the big brush spying that they're doing now.

Of course, if a lot of the files get out into the public, sort of like what happened with the STASI after the fall of East Germany, that might cause a sufficient mess too, especially if the personal information of the rich and powerful hits the streets in a way that even the NSA can't deal with.

41:

The webcomic XKCD has a simple explanation of the heartbleed bug, for anyone interested:

http://xkcd.com/1354/

42:
(b) there's this little thing called RIPA(2000) that gives them the legal power to demand access to my private keys under a gagging order and on pain of imprisonment if they want to play medium-heavy.

Why don't you move your colo to a non-RIPA infected site? While it seems trivial, it does seem to effective, at least as far as Yahoo moving their ops to Ireland is concerned. The idea of the head of Yahoo being carpetted by Teresa May for having the audacity to not want their users data subject to RIPA is simply risible.

43:

The site's jurisdiction isn't the problem; it's that Charlie is resident in a RIPA infected site. Yahoo's move works because the it's the company that's moving.

44:

RIPA

Just looked it up.

Man you folks over on that side of the pond like to enact sweeping laws. The second paragraph of Wikipedia:
RIPA can be invoked by government officials specified in the Act on the grounds of national security, and for the purposes of detecting crime, preventing disorder, public safety, protecting public health, or in the interests of the economic well-being of the United Kingdom, that is, any grounds can be covered at will under its exceedingly broad scope.

Over here Senator Feinstein seems to be headed to get some CIA folks into court over looking at some Senate computers And I tend to agree with her positions on the matter as made public to date.

But back to RIPA, "in the interests of the economic well-being of the United Kingdom" seems to allow most anything with a sympathetic judge or whatever the process is.

45:

You didn't read down far enough to come across it being used to allow a council to spy on a family to confirm they weren't sending their children to the wrong school, then?

From my (distant, ill-informed, and blackly cynical) perspective, Feinstein could well be pissed off that they wouldn't trust her, even after all the times she's covered for any and all sections of the US intelligence forces.

Specials

Merchandise

About this Entry

This page contains a single entry by Charlie Stross published on April 10, 2014 6:42 PM.

Yet another bad idea was the previous entry in this blog.

"Write me something fresh and new, but make it just like the last one" is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Search this blog

Propaganda