[jacquesm]

It's simple: make computers secure enough that connecting one to the net won't imply being hacked within a few days (minutes in some cases). Re-enable mail servers to be run from home connections, make them dead simple to set up and bullet proof. And so on. You can only wind this clock back step-by-step, a reboot will break too much that we have come to depend on.

It all went wrong at NAT, we were supposed to be peers, not producers and consumers.

[jasode]

>It's simple: make computers secure enough that connecting one to the net won't imply being hacked within a few days

It's not really simple. It's actually complex and having a general purpose computer be hardened enough for non-geek homeowners not to screw up (social engineering, security warnings fatigue, etc) is possibly an unsolvable problem.

If RSA SecurID whose very business competency is security can be hacked[1], the homeowner running Dovecote/Sendmail/Qmail/etc on Linux or Linux container has no chance at all. If uber-techno-geek Mark Russinovich can get infected with a rootkit[2], the average homeowner has no chance.

One could supposedly burn an embedded chip with email software (a dedicated "email server appliance") that can't be hacked -- but that also means it can't be updated. Email technology evolves (cleartext email --> SSL email --> next tech is ???) Also, if a vulnerability is discovered, the homeowner has to buy a new email appliance. If you make an email server on FPGA than can be flashed with new firmware, you've now re-opened an attack vector from social engineering.

>Re-enable mail servers to be run from home connections,

If you're talking technical issues such as ISPs opening up SMTP traffic on port 25 for residential internet connections, that's not really the problem. The real issue is the social dynamic of trust which is affected by bad actors and spam. Analyzing it through the lens of "technology" disguises the true problem. The puzzle of "trust" happens in a layer above SMTP/25.

[1]http://bits.blogs.nytimes.com/2011/04/02/the-rsa-hack-how-th...

[2]https://blogs.technet.microsoft.com/markrussinovich/2005/10/...

[markdog12]

Thanks for Russinovich link. I hadn't read it and it was extremely interesting.

[nickpsecurity]

"It's not really simple. It's actually complex and having a general purpose computer be hardened enough for non-geek homeowners not to screw up (social engineering, security warnings fatigue, etc) is possibly an unsolvable problem."

It's actually straight-forward based on lessons learned in high-assurance security: research and field-proven stuff that actually stopped pentesters vs common stuff that doesn't. Apple already gets far with iPhones and app stores despite having way less security than I'd advocate. Their Macs showed auto-configuration & easy everything with a UX experience that needs to be in secure computers. That's just through whitelisting, quality control for apps, and sandboxing. Weak but fairly effective.

So, what's something better take? It takes POLA all through the architecture for one. Orange Book showed no apps must be able to write to most critical files of the system except specific, administrative ones. Secrets should be compartmentalized in partitions with code that uses them without leaks, esp covert channels. Turaya et al showed you could do that in a single partition most of the time. OpenVMS showed a transactional, versioned filesystem lets you dodge all kinds of bullets with broken installs, accidentally deleting stuff, and so on. Time Machine shows how to make other process, backups, easy as possible. It would be combined with above to make that safe where apps couldn't subvert it.

With above + whitelisting, apps are neither likely to try to do damage nor will do damage to critical files. The next step is mapping user's intent to computers securely. CapDesk, a capability-secure desktop from Combex, shows us hints of how to do that with their PowerBox feature. It's basically a file dialog that, in the background, gives the app permission for just what user clicks on. OS or GUI manages it where app can't do crap with it. Trustworthy GUI's like Nitpicker GUI in Genode prevent spoofing of this or other windows plus screen scraping. So, they're trusted dialogs for key actions that people get used to and allow fine-grained permissions to be inferred.

The next step is on the apps themselves. They're going to try all kinds of tricky stuff. Android permission model is a start on dealing with this. Could, as Common Criteria did, create profiles for specific types of apps that have just what permissions make sense for that type of app. Wouldn't be mandatory but profiles or certification to them could help users instantly determine security package is reasonable. Certification would be easy if it was a permission list, use of a safe language, avoidance of features marked risky (eg macros, ActiveX, or JavaScript), and so on. Any app using stuff like that leverages capability-model with extra compartmentalization. All apps in this model are written with a language using GC or safe, manual memory. Any JIT's are integrated with isolation and/or capability schemes. All that is enforced, a la CHERI or SAFE, down to the CPU with IO/MMU transparently managing tags on incoming or outgoing data.

Hard for me to imagine easy hacks on systems that combine above principles. It will sound hard to some reader until they remember existing mainframe, desktop, and UNIX architectures are much more complicated than a Rust or Go app against a straight-forward API with a permission list and/or security policy. Or a set of OS components coded similarly. Side effect is extensions and maintenance become easier once you have OS in type-safe, memory-safe, concurrency-safe, modular language with isolation as default coding strategy.

Note: This covers security at the software and firmware level. Attacks on transistors or RF through software are outside of scope as R&D is ongoing.

[choosername]

> (a dedicated "email server appliance") that can't be hacked -- but that also means it can't be updated.

> if a vulnerability is discovered, the homeowner has to buy a new email appliance.

that's the update

[Analemma_]

> It's simple: make computers secure enough that connecting one to the net won't imply being hacked within a few days (minutes in some cases).

You remind me of that episode of Star Trek when the crew is trying to figure out how to stop an asteroid impact and Q goes "It's simple! Just change the gravitational constant of the universe".

[abcampbell]

+1

Darkweb shows that there is a (small, but real) market for an anonymous, decentralized web. I don't know anyone that prefers to navigate the web in a way that is permanently stored in NSA/advertiser servers forever.

Which implies that the reason there is not widespread adoption of a more decentralized, anonymous web is thus more of a product question.

[curun1r]

> Re-enable mail servers to be run from home connections

Mail servers, perhaps. SMTP servers, not a chance in hell. SMTP simply wasn't designed for a world with SPAMers, phishing and others who abuse email. If we're going to enable decentralized, we need to build in security and accountability from the start rather than relying on the naive protocols from the dawn of the internet. Note that you can have security and accountability while still maintaining anonymity. As an example, proof-of-work systems can mitigate the risk of bulk mail.

But if you're trying to replace SMTP, you're traveling a well-trodden path that no one has successful traversed as of yet. I wish whomever goes down that path the best of luck, since we need a good, modern, decentralized replacement for SMTP. But I wouldn't bet on anyone, even someone like TBL, being able to succeed at it.

[CiPHPerCoder]

I'm looking forward to SMIMP.

https://github.com/smimp

[gaius]

We only have SMTP because people were too lazy to implement X.400 which lacks most of its shortcomings...

[pjc50]

How does X.400 authenticate senders?

[infodroid]

Also in my experience ISP's to this day favour downloads over uploads by at least a 20:1 margin. Not to mention their restrictions on open ports and running internet-facing servers.

Though I'm not sure if this was just a market response to customer preferences or if it was a contributing factor to digital consumerism.

[mcphage]

> Also in my experience ISP's to this day favour downloads over uploads by at least a 20:1 margin. [...] Though I'm not sure if this was just a market response to customer preferences or if it was a contributing factor to digital consumerism.

Verizon ran a campaign recently where they made their FiOS service 1:1 claiming that it was due to customer demand. But it happened right around when the FCC was debating net neutrality, so I always assumed that Verizon hoped they could fool a few people into thinking that it was what net neutrality was all about.

[gaius]

That's the A in ADSL for you...

[ebbv]

The usual way home computers get compromised is user error; downloading and installing software that they shouldn't. It's social engineering. "Your computer has a virus! Install our software!"

Also running a home email server isn't usually that helpful. Even if you do that you're going to have to use relays to get your message where you want it to go (unless the topology of internet email changes dramatically), so you might as well cut out the step of having your own server and just send the mail directly to the first relay you'd be using anyway.

[nickpsecurity]

That won't work given his primary threat model: government censorship. Actually, I had to point this out to Bruce Schneier back when he was calling for tech to take back the Internet. I dropped a dump of all kinds of it from CompSci. I also told him it wouldn't work. Civil liberty and privacy from government is inherently a political problem because the government can always outlaw this, jail someone for that, or sometimes even murder its opponents. Problem is government itself. Only people can do something about that.

I agree with the need for what you suggested, though. It's also within reach of current technology with legacy compatibility for the most part. CHERI team has demonstrated that nicely with a FreeBSD port to a capability architecture that also supports safe, C apps. See main paper and "Beyond PDP-11" for details.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

[ZenoArrow]

I agree with your assessment.

It sounds like the path forward is going to rely on improving IPv6 adoption as a first step. We aren't likely to get rid of NAT without it. Consumer pressure could be placed on ISPs and web hosts to push things forward.

[fit2rule]

I agree with you - we have to stop focusing on building the network, and go back to building the computer again.

If our systems were safer, and could be relied on as a resource to share resources with others, which we want to share, we wouldn't need to broker the process out to others.

Its only because OS vendors fell asleep at the wheel - dazed, perhaps, by the potential to shift the problem out to the end-developers - and stopped building good OS features.