MITM attacks and prevention, etc & Countermail

Not wishing to hijack the other thread, may i present ......

I've read the eff info on the link on Countermails www before, but i'm posting it in case others havn't, worth reading

Sounds good to me, and they "seem" professional and serious about privacy.

*

Some nice looking free tools

Unfortunately they ALL require Java to be installed I believe that their email service does too ? I don't have Java installed, nor do i want it, others feel the same.

@ Countermail

Would it be possible to run your service etc without Java in the future ?

Also could you do a real video demo of how your service would defeat a real MITM attack. For example by getting one of those free certs filled in with fake info, and then trying to use your service with it ? That should provide people with even more confidence then they "may" have already

 

Java is not evil if you use it in the correct way, in fact Java and Flash is the only practical ways to achieve end-to-end encryption in a _webmail_ service, we believe that Java is way better than Flash, and Javascript is way to slow.

We will never reduce our webmail to something less than end-to-end security. Using SSL alone is far from secure.

However, there are some important points regarding Java:
1. Only accept signed Java applets
2. Make sure that you can control which applet-version your using, with our premium services our applet can be executed from a harddrive/USB-memory, so you don't need to download it every time, which also means that you have control which applet you used.

We will open up an IMAP proxy server (no hardrives, CD-ROM based), so if you have an OpenPGP-compatible email client you can use your own client, on your computer or mobile.

 

CloneRanger,

This is why I don't trust CA's. One never knows what they're up to or who they're colluding with. The only way to go is to generate your own keys and utilize the WOT model. Sure, it isn't as convenient but it is a helluva lot more secure.

 

@ Countermail

Thanks for replying

But it means installing many MBytes of code " it's not a small package some OS's are smaller than that " and i don't need it for anything else, and it's VERY intrusive wanting to constantly update numerous things etc to/from it's servers. I know we can configure our FW's to control this, but i don't like stuff like that.

Flash gee wiz i hope not, lots of info around stating how it can be used to track.

How much slower is Javascript in % ?

That's good to hear

Agreed, unfortunately it has been for a few years

Re - (no hardrives, CD-ROM based) Nice, but how about loading up the CD-ROM into RAM/Flash etc memory, and then running it from there ? That would be even faster surely ?

*

I'm dissapointed you didn't respond to my request

Could you, will you ?

TIA

*

@ chronomatic

Thing is, not everybody knows how to do that, so making it as simple, but still secure/effective, as possible is i expect what most people would want/choose.

 

Approx 10 times slower, it's a huge difference.

Our IMAP-solution will not require anything other than a OpenPGP compatible email client.

You may have missed the whole point about hardrive-free servers (?)
It's not about speed on the server, it's about privacy.
CD-ROM = ReadOnlyMemory = No IP-leakage to any harddrive

Yes, we will do this later this year.

 

I see, thanks

So you are actually streaming from a CD/ROM in real time, ok thanks. But if it's only ROM, then there must be other computer/software/memory/data etc etc involved for your www and service etc to be interactive ?

So what's actually on the ROM and what's elsewhere ?

Look forward to that

 

It's the webserver and IMAP proxy that uses CD-ROM.

You read about it on our webpage:
https://countermail.com/?p=server

 

So what are the data retention policies in Sweden now?

 

From the Countermail page:

With all due respect, the above is absolute and total rubbish. AES-CBC does absolutely nothing to help with identity verification or authentication. That is not the job of AES nor what it was designed for. AES is a block cipher, plain and simple. To use AES underneath SSL is superfluous since SSL already encrypts the traffic end-to-end.

The key to using SSL correctly is to verify that the owner of the certificate is who they say they are. This is usually the job of the CA's, but seeing how they sometimes do a lousy job, MITM attacks sometimes happen. But, again, AES does absolutely nothing to help with that.

 

It seems like you have completely misunderstood us.

We are NOT using AES to verify any certificate or server, we use it just for plain AES-CBC encryption. We are using RSA to encrypt/verify the session key. If a MITM have a CA-cert the SSL encryption is basically useless, that's why we added this layer.

We are currently adding a HMAC to the MITM protection.