Hacker News Reader

Comment by lrvick | Hacker News Reader

But you pay for this EC2 instance, and all traffic flows through it.

Honest question: What stops a malicious employee on your end sshing to this server and dumping plaintext messages from memory? What stops a court from ordering you to do that?

Even if you disable remote access, what stops someone from adding a new LaunchConfiguation that enables it silently on the next instance rotation in spite of whatever configuration is in place today?

At the end of the day it seems like you -can- spy on the traffic just as easily as you could if you were running the smtp services on an ec2 instance directly.

Given that, what is the value proposition here?

(Or if I am totally wrong, by all means call me out accordingly)

View on HN

Because traffic to and from the server will be over TLS, there won't be plaintext messages in memory on the gateway. We specifically designed to avoid the problems you have outlined.

In all honesty, couldn't this be a question to Amazon for anything that ever runs on any EC2 instance? What makes you not distrust any cloud vendor when they manage every bit of your information including keys.

Although, if they have to route stuff through EC2 instances anyway, I could just start jedieaston's homegrown EC2 email service, let customers pay me $100 a year to get them a domain name and spin up a email server in a EC2 instance and give them a login, then they don't have to have a box at their house which is liable to ISP and power outages. And you get the same amount of privacy that you get with this box (so about as much as you trust Amazon).

I -do- distrust all cloud vendors. My keys all reside in physically controlled HSMs.

Well the E-Mail server still runs locally. While they could intercept traffic on their VPN endpoint, the traffic should be encrypted (TLS). However, I am not to sure if all e-mail servers speak TLS to each other.

Well if it does VPN first, then initiates the SMTP connection with TLS on the local smtp server all the way to the RX mail server, then this works out fine.

A lot of mail servers don't support this though, so it would be on the client to also be able to ensure it will not relay mail except to TLS endpoints verified by a well known CA.

In my experience this is rarely the case, but if it is and Helm is willing to tell end users "sorry I can't safely send mail to this endpoint" then I could see some value to this approach.

Yes - we initiate a VPN connection first to the gateway, then inbound/outbound connections are over TLS. Over 92% of email traffic is over TLS and we will be exposing an option in the future where customers can require it or reject emails.

Reply on news.ycombinator.com