Servers, SSL, RDP/NLA, Backups, Secure Social Networking (SecuShare), Namecoin

Post date: Sep 23, 2012 5:10:48 PM

• Updated my SSL certificate and fine tuned CAs and intermediate certificates with my crt in one file for Dovecot and Postfix, so now my SMTPS (+submission) and IMAPS both pass certificate checks perfectly.
• Fine tuned automated encrypted, Secure off site backup system (Home & Work).
• Dovecot auth service kept crashing, I had to set client server per process to 1, so now process basically does one task and dies. This is not fast / optimal, but in my case, doesn't really matter. In perfect world I really couldn't accept this kind of solution.
• Turned RDP Network Layer Authentication (NLA) on for all servers. For Linux there is Remmina RDP client which handles NLA beautifully. Biggest problem are Windows XP computers. I just don't get it why Microsoft hasn't enabled NLA authentication by default on XP RDP clients. It's possible to enable it by modifying registry and booting computer. But that's bit hard to explain for some customers. Suddenly they just can't connect servers anymore.
• Decentralized, distributed and secure social networking. Nice. Here's cartoonified story about it, I think this is good for younger people, so they can figure out where the problems are with current dominating designs. http://my.pages.de/dsn-vn/
• secushare.org - This is something I really like. They also thought implementing generally accepted APIs and avoiding creating own user interfaces and focusing on providing perfect core code in tight C. Quoted from their project page:

1. updates, comments, postings, messages, files and chat are only visible to the intended recipients
2. the type of the message cannot be guessed at by looking at its size
3. communication between parties cannot be measured as they may have none to several routing hops in-between. an observer never knows if a communication came where it came from and ends where it is going to.
4. automatic responses and forwarded messages can intentionally be delayed so that an observer cannot tell two communications are related
5. communications cannot be decrypted weeks later, just because the attacker gained access to one of the involved private keys (forward secrecy)
6. even if an attacker gains access to a cleartext log, there is no proof the material was actually ever transmitted by anyone (for a case in court mere data would not suffice, you need actual testimonies)
7. the list of contacts is never managed on potentially unsafe servers, it is only visible to those it should be visible to
8. the infrastructure is robust and resilient against attacks

Shouldn't be that hard, right?

• Updated my samilehtinen.geek domain DNS information and applied for .42 domain.
• Studied and tested PyCrypto, and surprise surprise, it's faster than corresponding pure Python implementations. Ha! My OTR project uses AES-256 in pure Python and it's slow.
• tent.io - Nope, not too good. I studied whole protocol. Only communication is encrypted, not data in rest at hosts -> design is bad! Otherwise it's basic decentralized and OAuth 2, REST, web service & JSON based protocol. It's just like SMTPS with TLS. Any server admin can still snoop your email as much as they want to. Unfortunately many systems are designed with very bad security guidelines, like Facebook and Google+. You should create independent "social network" for earch purpose, because in most cases system design is so bad that different topics/purposes and content related to those aren't properly isolated.
• Just one day I was thinking about using DHT solution for anonymous collaboration program as key value storage. Well, it seems that there are solutions for that already. I also remember how horrible solutions email over freenet apps are. Distributed key, value storage isn't actually quite optimal for email. It can be made to work, but it's not pretty. After reading more about these existing advanced solutions, I decided that it's better to drop these things. Although it's nice to think about these things, even on simpler level. Freemail - Specification.
• Namecoin: I didn't like it too much, having all chains checked etc is very taxing. Also Namecoin payments etc, didn't sound like too viable. There are many other and better alternatives than that.
• Whoa, I just listed so many topic more to study: secure social network communication, distributed data structures and databases, encryption and also private cloud virtualization and PaaS solutions. Well, you can't ever know enough, can you? - Maybe knowledge adds pain and ignorance is bliss?
• Once again, I just so much prefer simplest working solution which will full fill known future requirements.