Re: [PEPr] Comment on Payment::Ewire_Payment

Asbjørn Sloth Tønnesen wrote:

On Wed, 2005-03-30 at 11:02 -0500, Philippe Jausions wrote:

[..] Still, e-mail notification is not secure, regardless of how many headers you parse. E-mail headers can be forged as well.

Yes, but the recevied headers are added on the way from the sender to the receipient. Lets follow an example mails way though the internet: 1) @217.116.227.145 When the mail is sent from eWIRE the mail doesn't contain any "Received" headers. 2) @195.190.153.169 The mail is received by eWIREs SMTP server (mail.ngdc.net) and it appends the following header:

Received: from app (unknown [217.116.227.145])

       by mail.ngdc.net (Postfix) with ESMTP id 2688748056
       for <ewire@cf-lan.dk>; Wed, 16 Mar 2005 00:21:31 +0100 (CET)
   

3) @217.61.223.78 The mail is received by my mail server and it appends the following header:

Received: from mail.ngdc.net (mail.ngdc.net [195.190.153.169])

       by asbjorn.biz (Postfix) with ESMTP id 70C2716C05
       for <ewire@cf-lan.dk>; Wed, 16 Mar 2005 00:21:31 +0100 (CET)
   

So if I trust my mail server, I can rely on this information 4) @127.0.0.1 My virus scanner appends the following header:

Received: from asbjorn.biz ([127.0.0.1])

       by localhost (tux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
       id 29753-08; Wed, 16 Mar 2005 00:21:31 +0100 (CET)
   

5) @127.0.0.1 My mail server recieves the mail from my virus scanner, adds:

Received: from localhost (localhost [127.0.0.1])

       by asbjorn.biz (Postfix) with ESMTP id EC0EF16C10;
       Wed, 16 Mar 2005 00:21:31 +0100 (CET)
   

and pipe it to my script, which only allows the following addresses to be used in the "Recieved" headers:

From Ewire.php

// Who are we trusting $allowed_ip_addresses = array( 'ewire app' => '217.116.227.145', 'ewire host' => '195.190.153.169', 'localhost' => '127.0.0.1');

If an unauthorized ip address apears in the recieved headers, it will result in an error, which I in my example, means the script would sent me an mail with the subject "Invalid ip in route: ip_address". Can you give an example on how you will you break this control? You are assuming you know the chain of SMTP servers an e-mail from point A to point B will follow. This is most likely out of control of the common user and could be a major headache to maintain the list of $allowed_ip_addresses.

What if eWire suddenly changes their SMTP server IP address? Or use a pool of servers, or change Internet provided or add a new one...? On the receiving end. What if your mail administrator add a new server to handle more load and so on. What if somewhere an internet provider decides that all e-mail traffic should go through some gateway... simply put... not manageable nor reliable. Someone could generate an e-mail pretending the message came from ewire server by adding some "Received From/By" headers. Maybe even send it as UDP forging some low level packet information... I'm not an expert of hacking at so low level, but doesn't sound impossible to me. Also parsing plain text to find information in a message is not reliable. What if eWire changes the format of the e-mail?

Yes, a signed e-mail would be much better. But this means all the users of eWire would need to have a public key, which will most likely not be the case. Although, this can be enforced by the package itself. That could be a good way to up the security.

No, if it is signed with eWIREs private key, everybody who have the public key, is able to decrypt the file. Good point. That would work fine this way.

I haven't heard from eWIRE since I made the suggesion, but Lasse Rungholm (Sales/Marketing, eWIRE), sounded to like the idea in the phone, and would bring it up on the weekly development meeting. My point is that, "reveived"-control is not the best solution, but I think it is secure enogh for now. Then it must be up to another release to add support for signined xml documents. Anyway, as is, I wouldn't want the package in PEAR. With a more robust infrastructure on eWire's end, then yes, it would be useful. I understand that it's not in your hands, but maybe this would trigger something to make it better...A signed XML attachment sounds very promising if they are willing to implement it. Well, that would bring a different headache about managing the keys, but would be much more secure...

I wouldn't think they implemented the e-mail notification as THE way to integrate their payment platform into a system... -Philippe