Some security related questions

Gateway
1

lst_hoe02(a)kwsoft.de wrote:

Djigzo uses the "From:" header of the mail to decide which sender
certificate to use. As the header is set by the MUA it is prone to
spoofing and therefore the decision which certificate to use may be
wrong. What is the reason to use the header in this case and not the
envelop sender (MAIL FROM) as it is the case for the recipient?

I saw your message on the Postfix mailing list about forcing the from
header to be the same as the SASL user :slight_smile:

The envelope sender (the MAIL FROM) can be spoofed as easily as the From
header (the only difference is that Postfix allows you to match the
envelope sender to the sasl user). The reason for using the from header
is that the from represents the identity of the sender and the envelope
sender is the postman. The envelope sender is used when a message
bounces for example. For example Outlook express checks whether the from
header is equal to the email address in the certificate for signed
messages and if the email addresses do not match a big warning is shown.
Same with Thunderbird (A question mark is shown op top of a blue envelope)

Not long ago one of our users mistakenly believed that Djigzo was using
the enveloped sender instead of the from header and asked. Quote "..what
is involved in making Djigzo use the "From" header to select the signing
certificate instead of the envelope sender?"

There are probably tons of good reasons why using the envelope sender is
better than using the from header and visa-versa. I think using the from
header better reflects the identity of the sender.

There are multiple solutions (not all of them implemented yet) to your
problem.

1) Let Postfix remove the from header. Postfix will add the envelope
sender as the from header (as discussed on Postfix mailing list)
2) Create a mailet that checks whether the envelope sender is equal to
the from and if not bounce the message
3) Create a mailet that makes the from header equal to the envelope sender.

The database potentialy hold the private keys used for signing and
decryption and should therefore be secured as much as possible. In the
standard installation a default password is used and no obvious warning
is in the documentation that on should at least prevent remote access to
PostgreSQL. This is default for PostgreSQL in some cases but not in all.
If one change the password in hibernate.cfg.xml this file is
world-readable at least when installed by .deb files. Is it possible to
do the following change: Include a warning to protect access with the
Djigzo DB-user and maybe a option to use access control based on the OS
user which is "djigzo" anyway (local socket) so no handling with
passwords is required for the DB.

I'll check whether Postgres works with ident instead of login.

>>Include a warning to protect access with the

I will add a warning to the documentation.

Is there any documentation which ports are used and what they are used
for? We have the following ports after std. .deb install:
djigzo user
15012 (localhost) --> no problem
9000 (*) --> ??
10025 (*) --> James Mailinput
jetty user
8443 (*) --> Web-Interface
8282 (*) --> ??

So two ports might be unused but open.

The posts used by Djigzo are

9000 communication between back-end and from-end
10025 The MPA port
8443 Web interface

15012 this is I think a port used by Java (this is dynamically chosen
and is not always the same port)

8282 I will check this

Thanks,

Martijn

···

--
Djigzo open source email encryption

2

Zitat von Martijn Brinkers <martijn(a)djigzo.com>:

lst_hoe02(a)kwsoft.de wrote:

Djigzo uses the "From:" header of the mail to decide which sender
certificate to use. As the header is set by the MUA it is prone to
spoofing and therefore the decision which certificate to use may be
wrong. What is the reason to use the header in this case and not the
envelop sender (MAIL FROM) as it is the case for the recipient?

I saw your message on the Postfix mailing list about forcing the from
header to be the same as the SASL user :slight_smile:

Yes that was the reasoning for asking. We don't have the problem today
as we only allow one special system inject mails, but i want to
understand the reasoning because it is some potential securitiy breach.

The envelope sender (the MAIL FROM) can be spoofed as easily as the From
header (the only difference is that Postfix allows you to match the
envelope sender to the sasl user). The reason for using the from header
is that the from represents the identity of the sender and the envelope
sender is the postman. The envelope sender is used when a message
bounces for example. For example Outlook express checks whether the from
header is equal to the email address in the certificate for signed
messages and if the email addresses do not match a big warning is shown.
Same with Thunderbird (A question mark is shown op top of a blue envelope)

Don't know for other MTAs but as we have seen it is much easier to
control the MAIL FROM then the "From:" header in Postfix. I suspect
this is the case for most MTAs as they normaly deal with the envelop
data anyway, but content-inspection is optional.

Not long ago one of our users mistakenly believed that Djigzo was using
the enveloped sender instead of the from header and asked. Quote "..what
is involved in making Djigzo use the "From" header to select the signing
certificate instead of the envelope sender?"

There are probably tons of good reasons why using the envelope sender is
better than using the from header and visa-versa. I think using the from
header better reflects the identity of the sender.

This is true because the "From:" header is displayed by the receivers
MUA. The MAIL FROM is only available in some cases.

There are multiple solutions (not all of them implemented yet) to your
problem.

1) Let Postfix remove the from header. Postfix will add the envelope
sender as the from header (as discussed on Postfix mailing list)

This is only useful if Djigzo should be limited to be used with Postfix.

2) Create a mailet that checks whether the envelope sender is equal to
the from and if not bounce the message

This would be the most "secured" possibility. Not sure how this would
interact with BATV and the like.

3) Create a mailet that makes the from header equal to the envelope sender.

Could this be configurable to choose between 2. and 3. maybe even in
the web-interface...

The database potentialy hold the private keys used for signing and
decryption and should therefore be secured as much as possible. In the
standard installation a default password is used and no obvious warning
is in the documentation that on should at least prevent remote access to
PostgreSQL. This is default for PostgreSQL in some cases but not in all.
If one change the password in hibernate.cfg.xml this file is
world-readable at least when installed by .deb files. Is it possible to
do the following change: Include a warning to protect access with the
Djigzo DB-user and maybe a option to use access control based on the OS
user which is "djigzo" anyway (local socket) so no handling with
passwords is required for the DB.

I'll check whether Postgres works with ident instead of login.

At least when using local sockets this is no problem for PostgreSQL
(http://www.postgresql.org/docs/8.3/static/auth-methods.html#AUTH-IDENT). Not
sure if hibernate is able to do so and this is limited to Unix (no
Windows).

>>Include a warning to protect access with the

I will add a warning to the documentation.

Is there any documentation which ports are used and what they are used
for? We have the following ports after std. .deb install:
djigzo user
15012 (localhost) --> no problem
9000 (*) --> ??
10025 (*) --> James Mailinput
jetty user
8443 (*) --> Web-Interface
8282 (*) --> ??

So two ports might be unused but open.

The posts used by Djigzo are

9000 communication between back-end and from-end
10025 The MPA port

Maybe bind to localhost only by default???

8443 Web interface

15012 this is I think a port used by Java (this is dynamically chosen
and is not always the same port)

8282 I will check this

This is something from Jetty installed by default (see
/etc/jetty6/jetty.xml) and i'm not sure if it is save to disable...

Regards

Andreas