Friday, October 17, 2014

Indelible email

Here's another idea for a form of secure messaging. This time, it's middleware for a secure email ecosystem.

The idea is to have businesses set up bitcoin wallets, manage the private keys, and to use bitcoin for email.

This would just be middleware to abstract bitcoin from users. On top of this would be a normal email server layer, where users can request their inboxes from the corporate server, with or without encryption and other features.

Using bitcoin for email would allow records to be created that could not be destroyed or altered, and would make compliance easier for businesses, and discovery (with subpoenas) easier for the courts.

With message sizes growing massively if this system were used, the blockchain messages could instead contain hashes of payloads located in parallel systems. Each business with a node, for example, could expose the payloads through web services, which would be encrypted so that only the recipient's public key could decrypt it.

I once wrote an idea for a client-encrypted email system, and the biggest criticism I could find of similar systems is that a user wouldn't, in practice, know it wasn't secretly compromised, no matter what protections were in place in the client. Using this corporate middleware that relies on the blockchain would solve those problems, at least for businesses.

Now, I've specifically said to use bitcoin, rather than a non-currency blockchain, because one benefit of this system could be requiring messages to have some payment made for processing of the messages. The amount would be set so that spamming would be costly, but normal email would cost little.

Emails could still be read and relied on pretty well without even being verified, subject to being revokable on discovery of a fraud within an hour. And any messages that are sent without payment could be ignored by the middleware as spam.

One challenge of this system would be how to communicate addresses. They could be actual bitcoin addresses communicated by text or QR code, but it seems like a more user-friendly approach would be to have a directory on each node, or to use TXT DNS records or something, so that normal email addresses could be looked up and converted into bitcoin addresses.

Anyway, thoughts on this system? Ideas for refinement of the idea, or criticisms of why it wouldn't work or is stupid?

Friday, September 26, 2014

I'm still here

Now that we live in a police state, we need a way to inform our loved ones when the secret police have taken us away subject to a preventative detention order to be held incommunicado.

Well, there's an app for that. Or there might be... I don't really know. But there could be, and here's how it would go:

Firstly, there needs to be a trustworthy authority for holding, though not issuing, public keys. A web of trust is suitable for the purpose, though using the blockchain would be more resilient.

Then, there needs to be an actual app.

The app would use your private key to sign a message. The message could contain your whereabouts, but that would be a risk of its own. Instead, the message could contain your whereabouts encrypted with the public key of 1...n trusted people. Actual content of the message, such as state of mind, e.g. "I feel safe" or "I think I'm being followed" could be selected from a list or preprogrammed into buttons.

Then, all that's left is to hit the button, which would encrypt the whole message with your private key, doing whatever digest stuff is necessary to be secure, and post the encrypted message to Facebook, Google+, and, if the message can be split up, to Twitter.

Now, you can't expect to oust the plain text message asking with the encrypted message and expect anyone to verify that the encrypted message is valid and matches the plain text message. That's why only the encrypted message would be posted.

To make the system functional, the app would allow the use to follow other people. Their encrypted messages would be downloaded and decrypted using relevant public keys, and the messages would be logged in the app.

From there, it's a simple matter to alert the user when friends of the user haven't checked in for more than a day or so.

So, if you're reading this and give a crap about civil liberties, and know about infosec-related programming, and want to help me out, or just give me opinions, advice, or let me know that this has already been done, then leave a comment or tweet at me @dcrafti.

/ramble

Monday, August 11, 2014

Open Letter to Bruce Billson MP re: Data Retention

Here is the letter that I submitted to my MP via the EFA/GetUp petition on Data Retention. Please consider also signing the petition and writing a letter to your MP, which the form makes extremely trivial to do.

Thursday, August 7, 2014

LexisNexis Rage

We said it's a free society, not a free society

I graduated from my Master of Laws degree earlier this year, and since then, I've been somewhat disconnected from being able to continue my studies. I mean disconnected in the literal sense.

Monash University, where I did my study (though I assume all other institutions are the same), give access to lots of online research tools for the duration of studies. Many of those tools are made by the likes of LexisNexis or ThomsonReuters. However, since graduation, I can no longer access any of these services.

In particular, LexisNexis makes a terrible database front-end for looking up reported cases and journal articles, called CaseBase. While the rest of the world has moved on to web 3.11, or some other such buzzword, CaseBase has remained true to its origins, firmly rooted in web 0.98beta.

They have no reason to spend money on improving their horrible front-end or adding features to their search "technology", because, as I'm sure you could guess, all their content is licensed either from journal companies, or some government department or government-approved monopoly. That means, for example, that you have to go through CaseBase, or some system just like it, in order to find out what was said in the decisions of the courts, for most court decisions. In Australia, which is a common law country, that means that without paying for a subscription, you cannot feasibly find out enough of the law to know what your responsibilities are, as a citizen.

You shouldn't need to pay for this stuff, but let's forget all that idealistic crap about citizens being able to read the laws of the land. I'm not cheap, so I'll just pay for a subscription. It can't be too much can it?

Try to find out on the website. I couldn't. I tried to LiveChat with them, but it took them somewhere north of an hour to respond, from my estimate, and I'd left my computer. I left a message on the phone and finally got a call back the next day. So this is an efficient company, huh?

So, now, back to how much it costs. I guess on an annual subscription, for this important information, $700 isn't too much is it? Oh, you think it is? Well, on an annual subscription, that's the monthly cost.

CaseBase costs $8,400 per year

Stripping out various journals and paring it back to just access to cases still cost about $5,000 per year, and when I still balked at that, the sales rep offered it to me for $3,400 per year, because I wouldn't be using it commercially.

Yeah, no.

This is what happens when information that should be public domain is locked up behind paywalls; we're left with sub-standard systems that cost a fortune.

It's a rort, and it needs to be fixed.

Tuesday, July 8, 2014

[Solved] Amazon EC2 HTTP/HTTPS Redirection Loop using IIS

I'm writing this up because, like with a couple of problem solving posts in the past, I think this could be helpful for other people who have spent hours googling without any results.

I have been setting up a site on a single Amazon EC2 instance. The site can be accessed with SSL or without.

I generated the certificate request, going through GeoTrust, installed it with only a little difficulty.
Everything was going well until I tried to visit any of the HTTPS pages. If they didn't require HTTPS, then the request was redirected back to the HTTP version with a 301 permanent redirection. If HTTPS was required, then a redirection loop was encountered, as my code kept redirecting back to HTTPS, with something redirecting back to HTTP.

Lots of articles exist where people can't reach the site over SSL, but that wasn't my problem. Lots of articles exist where the problem is that Amazon's Enterprise Load Balancer (ELB) was in use, which obviously intercepts HTTPS requests, then passes on the result as HTTP, which would cause a redirection if requesting a page that requires HTTPS, but should not cause a loop where HTTPS is optional.

Instead, the problem was much simpler. The binding I had set up in IIS for HTTPS was using the EC2 instance's public, elastic IP address, rather than the server's private IP address. This was resulting in a redirection to the non-secure version on requests for the secure version, because as far as the server knows, the elastic IP address is a different machine.

Anyway, so changing the binding to use the private IP address worked perfectly.

I can't be bothered trying to word this as a question and answer using the right keywords and then deciding on whether it is more appropriate to go on Stackoverflow.com or Serverfault.com, hence me brain-dumping this here.

Hopefully, this SEO-keyword-laden blog post will allow others who get bitten by this esoteric issue to find an answer much faster.