Ursecta

In an interview with Computer Sweden, Dan Egerstad explains that he indeed used Tor exit nodes,  five of them. Then he sat back and collected both logon credentials and email contents of all the confused souls who thought that Tor protected them. 

Thinking about the Dan Egerstad affair and reading the comments to the Wired article, it may very well be that he set up a Tor node and simply caught credentials when people routed unsecured POP connections through Tor and exited through his node. This makes a lot of sense. I can very well imagine embassy people, and others, using Tor because it’s a great security product, while completely misunderstanding what it’s for.

Maybe that explains why Dan is so cool about getting sued for this. Assume he set up a Tor node for non-malicious reasons, then added a sniffer to it to make sure it wasn’t being used illegally, like for child porn (the sniffer would only give useful info for those sessions that used his Tor node as an exit node, of course). So when he then checks the logs, he finds all these POP email credentials in his own logs on his own machine. He goes on to publish these, not actually using them to get into the email boxes? Has he done anything illegal? I don’t think so. People put their credentials on his machine entirely unasked and of their own volition. They even went to the trouble of installing a Tor client to be able to.

Maybe he did set the whole thing up to catch the credentials, but if he sticks to a very plausible story like the above, there’s no provable intent, is there?

I don’t know for sure this is what happened, but if it didn’t, it will.

Note: in the comment to the above article, “anonymouse” writes that it is an MITM attack using false SSL/TLS certs at the Tor exit node, but that would only be necessary if the victim used SSL protected POP connections through Tor and I don’t see why they would. If they were naive enough to think Tor would do anything at all for their email security, I don’t think they would be savvy enough to add SSL to the POP.

Just saw mention on a forum of downloading a VMWare appliance ready-to-run parental control package. It’s definitely a great convenience to get a pre-installed entire OS with apps and all this way, but what about malware? It seems we have very little guarantees about how clean these installs are, and yet I don’t see people worrying much about it. My neck hairs stand on end just thinking about it.

There is no way I know of to scan such a ready-to-run VMWare image for malware. There is no way to reliably scan them once they’re up and running, since they can easily be rootkitted or even contain malware compiled into the kernel.

Personally, I couldn’t dream up a better vector to get an entire package of malware onto sombebody else’s host or network than having them install an entire virtual machine preloaded with it.

But they sure are neat. I’ve downloaded one or two myself to test out preinstalled servers of different kinds, but I don’t think I’ll do that anymore.

We have a lot of vulnerabilities in software, and it doesn’t seem to diminish.

One of the major reasons we have all these vulnerabilities is that every software developer (or organization) needs to develop every darn litte thing itself. IOW, the networking code, the user interaction, the database handling, etc, just to be able to sell that one good idea or process that is their own. A very small part of every product is what differentiates it from the others, while the rest of the product is a rehash of what everyone does and has to do. Nobody likes to do all those parts, but we have to. And that’s where the vulnerabilities appear, in general.

Even though I don’t like the car analogy, I’m going to use it: it’s as if every car manufacturer had to create every high level system itself, like the braking system, electrical system, interior, etc. They don’t, they buy those from a few suppliers that know how to do that stuff right and cheap. The equivalence of APIs and operating systems would be components like wipers, bolts, nut, etc. The equivalence of the network stack would be the high voltage inductor, while the network handling code would be the ignition system.

Actually, it’s a bad analogy. One of the problems we have is that no physical analogy is right for software systems, so we keep misleading ourselves with them. But still, that’s my analogy for now.

We can’t quite yet get to the same level of component reuse in software as car manufacturers can. So every software engineer, in principle, has to create his own ignition system, even if he’s only interested in building his own idea of a sleek sports car. And, sure, his ignition system won’t equal one made by Bosch. Duh.

Trying to teach him how to make perfect ignition systems won’t work. He’ll be bored and distracted from his main interest. So this has to change.

(All the “software components” stuff is/was about this, but nobody has gotten the abstraction level right yet. They haven’t found the right place to cut the cables, so to speak. My feeling is they’ve always tried to solve too many problems in a too general way with all these systems, including Corba, COM, VCL, whathaveyou. Like I’d ever want to use a readymade ignition system in a juice press. Which actually may not even have a fuse box which the ignition system relies on. The analogy turns slightly ridiculous here…)

The other thing here is “complexity” vs “simplicity”. Complexity screws everything up. It causes exponentially increasing development times and bug counts. It makes for fragile systems and maintenance nightmares. But, you say, people want complex software… no they don’t. They want systems with complex behaviour, which is not the same as complex software. You can build very complex systems from a set of simple software units, if you do it right. That way the total complexity of the system increases linearly with size and function instead of exponentially.

This is what structured programming, OOP and all the rest is all about: trying to build complex systems using simple software. The trick is reducing complex processes to interacting simple processes, then treating each of them as a simple subsystem. Surprisingly few development organisations seem to get this and keep on building complex software using these techniques. Personally, I have a very hard time even imagining which system actually has to be built using complex software and can’t be done by a collection of simple software parts. I don’t really think there are any.

Dividing a complex system into simple software parts, if done right, makes each part easily manageable, allows you to divide the development organization into smaller coherent parts, allows easier documentation, easier testing and bug resolution, easier replacement, etc, etc. It’s a boatload of Good.

The current paradigm change (yey, got to use “the word”!) that’s occurring due to multi-cores will actually help. The transition will be very painful (developers and designers seem to have great difficulty thinking of business processes in anything but a sequential fashion), but if we’re lucky, that may be what’s needed. Pain is good.

Short version: you can’t confront “simplicity” with “complexity” without indicating what level of composition you’re talking about.