search

dcposch / scramble

Secure email for everyone
http://dcposch.github.io/scramble/
226 stars 32 forks source link

Cannot send messages across servers #21

Closed jaekwon closed 11 years ago

jaekwon commented 11 years ago

I tried sending a message from hashed.im to scramble.io. (hashed.im is my domain).

dcposch commented 11 years ago

We'll have to clean up the rest api. One way this could work:

Another way this could work:

Option 2 is easy, but we'll have to be careful that such a permissive CORS setting won't cause security problems.

On Mon, Sep 9, 2013 at 1:36 PM, jaekwon notifications@github.com wrote:

I tried sending a message from hashed.im to scramble.io. (hashed.im is my domain).

  • I get an error "Could not find public key for ...@..".
  • Even though the send failed it still shows up under "Sent"

— Reply to this email directly or view it on GitHubhttps://github.com/dcposch/scramble/issues/21 .

jaekwon commented 11 years ago

More reasons for Option 1:

Reasoning as follows: First, I think we should be encrypting a message only once on the client. It doesn't improve security to re-encrypt the same message with different symmetric keys for multiple recipients (and again for the "sent" box). The only argument for doing so would be to shield recipients from association with a particular message, but that's hard to do considering that a lot of metadata is unencrypted on the server.

So let's say we change the impl to encrypt a message once (and of course encrypt the symmetric key separately for each recipient, which is already supported in openpgp.js). Then the client only needs to push the message to its server once, and the server would be responsible for storing the message in the appropriate "send" & "inbox" folders & pushing to other servers as necessary with retries etc.

Since Option 1 only sends a message once to its server for further processing, the client isn't responsible for staying online & managing retries & failures. The server is responsible for retries & reporting connection errors back to the user, probably as an email from the server.

jaekwon commented 11 years ago

Here's a sketch of how I think app.js should change. Code is untested & needs fixes but the idea is there: https://github.com/jaekwon/scramble/commit/48ae7bf4a7f11fd2f3a20c613f939559aeecb627

I'll continue working on this tonight. We could split this into server/client side work & get it done pretty quick. Feedback welcome.

jaekwon commented 11 years ago

Just realized that there are two steps to sending an email, both of which have option 1 or 2. That is, getting the public hashes could be done by the client directly, or delegated to the user's server. Sending the enciphered email can also be done by the client directly, or again delegated to the user's server.

I'm pretty sure sending the enciphered messages should be delegated to one's server as described above, but I'm not so sure about the pubhash->pubkey mapping...

dcposch commented 11 years ago

Yes, I agree. So to be clear, here's the full timeline of communications that will happen when xyz@scramble.io sends mail to abc@hashed.im

xyz's browser -> scramble.io server: GET /key/abc@hashed.im
scramble.io server -> hashed.im server: GET /key/abc@hashed.im
hashed.im server responds, scramble.io server stores the response and responds to xyz

xyz's browser verifies the public key. It encrypts the message. Then, it sends the message

xyz's browser -> scramble.io server: POST /email/  <posts the encrypted message and metadata>
scramble.io server -> hashed.im server: <sends an email via SMTP>

Does that sound reasonable? Let's do it.

jaekwon commented 11 years ago

yup. sounds good.

On Sep 11, 2013, at 2:49 PM, DC notifications@github.com wrote:

Yes, I agree. So to be clear, here's the full timeline of communications that will happen when xyz@scramble.io sends mail to abc@hashed.im

xyz's browser -> scramble.io server: GET /key/abc@hashed.im scramble.io server -> hashed.im server: GET /key/abc@hashed.im hashed.im server responds, scramble.io server stores the response and responds to xyz xyz's browser verifies the public key. It encrypts the message. Then, it sends the message

xyz's browser -> scramble.io server: POST /email/ scramble.io server -> hashed.im server: Does that sound reasonable? Let's do it.

— Reply to this email directly or view it on GitHub.

jaekwon commented 11 years ago

More code, now getting into Go channel code on the server. Check out the handlers.go changes for some go channel code...

https://github.com/jaekwon/scramble/compare/48ae7bf4a7f11fd2f3a20c613f939559aeecb627...multiple_recipients