Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Hacker's Replacement for Gmail

dbpmail.net

Post reply on HN
Print view View original

191–200 of 218 posts

Re: A Hacker's Replacement for Gmail

#191

Post by tacticus »

pyre wrote: post #28
pfraze wrote: post #21

Earlier quoted context omitted.

I made a very extensive search for an open-source webmail solution that exported a REST api. Unfortunately, none of them do (that I could find). Most of them are from the XMLRPC days. I'd definitely contribute to a kickstarter for a good FOSS REST Email server.

| good FOSS REST Email server You should specify what you're talking about here. An all-in-one solution? An SMTP server? An IMAP server? A webmail client (e.g. SquirrelMail / RoundCube)?

I imagine it would be similar to what i've been looking for.

Central app that manages the storage, sending (server to server) and receiving (server to server) of email exposed over a rest api

Re: A Hacker's Replacement for Gmail

#192

Post by e12e »

clarkm wrote: post #110
jervisfm wrote: post #33

Earlier quoted context omitted.

The point about trusting hosting providers is an interesting one. Indeed, when renting a Virtual Private Server from a service provider, you have no choice but to trust them to keep your data safe. This made we wonder: would it be possible to actually secure the server in such a manner that the hosting party won't have access to your stuff without your say so ? I think you can (sort of) do this already with having so…

No -- unless you have exclusive physical control of the machine you'll always be vulnerable. A malicious VPS provider has access to the machine's RAM, which means they can do almost anything. For example, they could extract your SSH private key and silently decrypt all your traffic. Is such an attack easy? No. But I could compile sshd with debug symbols and it would be. Even without them it's still possible, just ver…

As far as I know, SSH v2 offers perfect forward secrecy, so the attacker would have to read the session key from ram, not the private key (the private key would allow the attacker to do MITM, though).

Re: A Hacker's Replacement for Gmail

#193

Post by e12e »

oijaf888 wrote: post #95
Sami_Lehtinen wrote: post #66

Earlier quoted context omitted.

That's why they take memory snapshot first, which is trivial with VPS and then pick encryption keys from it to access encrypted volumes. This is well known method and works with pure hardware machines too with physical access. It's great question when you get to server, to shut it down or leave on. If on, it could destroy data, if turned off encryption keys are gone. I think it would require some individual case anal…

How do you do that with a pure hardware machine with physical access without rebooting the machine? Even if you freeze the memory with liquid nitrogen and extract the data from it, that process results in the server needing rebooted afaik. Obviously I'm assuming there's no 0-day you can just enter in via the serial console or similar.

You might chill the RAM, reboot, read out the encryption keys, mirror the disks, verify that you can decrypt it -- and then leave the server off -- mail the customer a notice saying the server rebooted due to a power glitch.

At this point you have pretty much everything on hand to help you fool the customer into believing everything is ok (eg: replace the whole physical machine with a vm...).

Come to think of it -- if you know the hardware in the machine, you probably could replace the machine with a vm anyway -- just mirror the disks and go.

Re: A Hacker's Replacement for Gmail

#194

Post by e12e »

etherael wrote: post #114
th0br0 wrote: post #113

Earlier quoted context omitted.

But do you validate that boot partition each time you reboot the system? How do you know that your computed hashsum (or similar) is actually the true one? ...

got a hash of the boot partition, validate when it comes back up.

How do you know that you're not logging in to a vm, with all the data mirrored from your physical server?

Re: A Hacker's Replacement for Gmail

#195

Post by e12e »

viveksec wrote: post #78
bigiain wrote: post #62

Earlier quoted context omitted.

Hmmm, no Perfect Forward Secrecy on RC4-SHA... Would it be considered paranoid to read anything into the fact that they offer ECDHE-RC4-SHA for https sessions, but only RC4-SHA for SMTP connections?

> Hmmm, no Perfect Forward Secrecy on RC4-SHA... Actually dont see how you can have PFS on DHE either if one of the endpoints doesnt co-operate. You can simply dump the master keys and provide those to the decrypting app.

Or just dump the plaintext data.

If I tell you a secret, and you tell someone else ... there's not a lot I can do a about that. If you don't want a third party to be able to hand over your plaintext (or store it) -- don't give them your plaintext (or a means to access your plaintext).

Similarly, if I send you a PGP encrypted email, I can't know if you decrypt that and hand it over to someone else (willingly or unwittingly).

Re: A Hacker's Replacement for Gmail

#196

Post by bigiain »

e12e wrote: post #195
viveksec wrote: post #78

Earlier quoted context omitted.

> Hmmm, no Perfect Forward Secrecy on RC4-SHA... Actually dont see how you can have PFS on DHE either if one of the endpoints doesnt co-operate. You can simply dump the master keys and provide those to the decrypting app.

Or just dump the plaintext data. If I tell you a secret, and you tell someone else ... there's not a lot I can do a about that. If you don't want a third party to be able to hand over your plaintext (or store it) -- don't give them your plaintext (or a means to access your plaintext). Similarly, if I send you a PGP encrypted email, I can't know if you decrypt that and hand it over to someone else (willingly or unwitt…

I can though, still assume that if I send you a GPG encrypted email to your gmail account - I've only got to worry about _you_ leaking the contents, not Google.

-----BEGIN PGP MESSAGE-----

hQIMA13LrXtLThhwAQ/+LmYMzmaQ3Ui0AF5yRKzCVL/rXzUO3h+cKZVnA2AL/SAR PHcVjgGkm4BT3C8pokeTl+UQPqsBj/i3gteC0zi5QTMyXYxnkCC6915yVGON86BS E5i+pEpXIubnWiKZh81Ik+YARYnTqi+Ea5zW0OAzKmd48FX9m21MK0fKHcdjoYZk 56JaMbTgcSTcW2RIztwQr9EeTnf/XIHsIrhQuOGmZd9kTmbxn9mA+W2AKzgPmv7s Z+RUgEMrbyjNK+s2V/ibPE0CDpBKR6cleWRmAgEknu2Z8QaBIgiv+a64mKMbtL6I H8ZCcM1djgBmXvjfHRwJEvEKEIfJKVQ5Q1SMyskAkWt23CQIbd1toLzx/2e0F0O3 Zjppm+qnBhM6JUOnuc5L42uvZK1+0L3aT99UX5L2xOV8OdqgVto1u+d/Q35LUhNl jjslEKidDxhxFWVHJvVhY/4ogQZIq4WrEpDMoYjRzniECMi779MTl6UnX0vRjVuw 3dbXppozqhB40P7q9Om+ORXGfMrzpIRwABltY6NI5PPjeFgHeNZ/gAFxfWn6INYa mielp57irCYBAVaVIodds2EZNSJ3o8m8A/p4HKbuS8W1qDkU2QY4k+Ns27LY3EQM 0fXx6Ug5INql6vHQpj02W4q4S8A0FipS70WZIH4eWm/aLDWV4PT/0hMoGAhYPgvS lgFoQeoAPeaPJ+Tlb1WX5V7cePBH3EZte+0WcBwlZBBejCBNVAjpyFUG4jMcOv/B IPPa+7IFWjE/1kf7n6e+/OsqDjXWem2j5wJd8R0SJlJk97/VjGDvYAn2mdNCqQ43 /sLRy5oTgEE+kljtFriL5Qfdhkei5UR8RZxV3Yv3J+ARohj7JJovSi0psR9hVI5J BGL2emenig== =Eqf+ -----END PGP MESSAGE-----

Re: A Hacker's Replacement for Gmail

#197

Post by e12e »

bigiain wrote: post #196
e12e wrote: post #195

Earlier quoted context omitted.

Or just dump the plaintext data. If I tell you a secret, and you tell someone else ... there's not a lot I can do a about that. If you don't want a third party to be able to hand over your plaintext (or store it) -- don't give them your plaintext (or a means to access your plaintext). Similarly, if I send you a PGP encrypted email, I can't know if you decrypt that and hand it over to someone else (willingly or unwitt…

I can though, still assume that if I send you a GPG encrypted email to your gmail account - I've only got to worry about _you_ leaking the contents, not Google. -----BEGIN PGP MESSAGE----- hQIMA13LrXtLThhwAQ/+LmYMzmaQ3Ui0AF5yRKzCVL/rXzUO3h+cKZVnA2AL/SAR PHcVjgGkm4BT3C8pokeTl+UQPqsBj/i3gteC0zi5QTMyXYxnkCC6915yVGON86BS E5i+pEpXIubnWiKZh81Ik+YARYnTqi+Ea5zW0OAzKmd48FX9m21MK0fKHcdjoYZk 56JaMbTgcSTcW2RIztwQr9EeTnf/XIHsIrhQ…

Oh, absolutely. I just wanted to point out that if you're communicating with google, you're communicating with google -- so even if they enable perfect forward secrecy over smtp/tls -- that's not a 100% fix.

It is still better than them not enabling it -- because if we can assume they do not log the data by default, on their own (aka: we can trust google) -- old data won't be accessible once a (theoretical) new warrant arrives.

Re: A Hacker's Replacement for Gmail

#198

Post by junto »

old-gregg wrote: post #157
cbr wrote: post #132

Earlier quoted context omitted.

It's easier now, in that we have good well-documented software, but the external environment has changed. While other servers used to just accept the email you sent, spam countermeasures have gotten complex enough that if you just follow the postfix installation guide you're going to have a lot of your outbound smtp filtered.

Grab a free account at mailgun.com and configure it as your outgoing SMTP relay. You'll get an IP address for your outbound traffic which is "clean", monitored and registered with a ton of ESPs. You can also use Mailgun as a proxy for your incoming mails as well, for spam filtering or custom routing purposes.

Out of interest, how would you go about doing this, especially interested on the inbound?

Re: A Hacker's Replacement for Gmail

#199

Post by noinsight »

mike-cardwell wrote: post #169
etherael wrote: post #72

Earlier quoted context omitted.

Isn't the pure hardware method for memory snapshots some ridiculously complex mechanism with freezing the memory and quickly transferring it to a reading device? If you're going to pull this, you need to know in advance that it's necessary, that's not some minor thing that everyone is going to just do automatically, it's an extra, complicated step it's easy to screw up. That said, I acknowledge the possibility of com…

"ridiculously complex mechanism" ... Not really. Anyone with the ability to stick a USB stick in a USB port and hit a power reset button can pull off this attack: http://www.mcgrewsecurity.com/tools/msramdmp/

Hmm, that requires USB booting though, if you disable that from the BIOS and password protect it, they can't really use this method. If they pull the battery the machine needs to be turned off and so the RAM will clear.

Re: A Hacker's Replacement for Gmail

#200

Post by homeomorphic »

moxie wrote: post #29
LeafStorm wrote: post #13

While I don't necessarily trust an external company with all my emails, I also don't trust myself to maintain the myriad daemons involved in this setup without doing something subtly wrong that results in my server not sending/receiving all the mail it should -- or, worse, being used for spam. What would be useful is a pre-assembled virtual machine image or other form of appliance that allows you to deploy and test a…

I've been hosting my own mail since 1996. It's actually one of the easier services to self-host: 1) SMTP was developed for unreliable environments. If you have problems with uptime, your incoming email will bounce around for 5 days before it gets dropped. So assuming you can get your SMTP server running one day out of five, you shouldn't be in danger of losing anything. 2) Contemporary daemons like postfix and doveco…

I've been meaning to finally get around to doing this myself, so I'll shoot you a question: Do you have a fallback MX? I'm thinking of getting a super-cheap VPS running only Postfix as a mail fallback in case my primary host goes down for an extended period. How is accessing mail on the fallback host (when primary is down) usually handled? An IMAP daemon running there as well? Should the fallback just wait for the main one to come back and then send all the waiting mail there?
Post reply on HN