On incoming signed E-Mails, Djigzo puts the CN of the sender's
intermediate CA next to the "X-Djigzo-Info-Signer-ID-0-1"-header.
Shouldn't it be the CN of the sender's user certificate which is displayed?
Same thing happens with the "
X-Djigzo-Info-Encryption-Recipient-0-0"-Header in incoming encrypted
E-Mails.
Is there a way to use the value of the FROM-header instead of the
default CN ("persona non-validated" by default) for automatically
generated certificates?
As long as outgoing emails have their source in my trusted environment,
this would make things easier without representing a security issue.
Is it possible to use end-to-end encryption for specific users, so that
a specific user has it's own private key stored on his client and djigzo
only passes through the encrypted email?
I tried to do so. But as I don't have any CA except Djigzo's built-in
CA, i created the internal user and its certificate with the built-in
CA, exported the key to the client, deleted the user, but Djigzo still
decrypts incoming E-Mail for this user before. Is this a bug or working
as intended?
Zitat von Bernhard Heinzle <bernhard.heinzle(a)gmail.com>:
Hi Martjin,
maybe you can help me with the following issues:
On incoming signed E-Mails, Djigzo puts the CN of the sender's
intermediate CA next to the "X-Djigzo-Info-Signer-ID-0-1"-header.
Shouldn't it be the CN of the sender's user certificate which is displayed?
Same thing happens with the "
X-Djigzo-Info-Encryption-Recipient-0-0"-Header in incoming encrypted
E-Mails.
The standard mail clients i'm aware of don't display headers at all so
not sure what you are trying to achieve...
Is there a way to use the value of the FROM-header instead of the
default CN ("persona non-validated" by default) for automatically
generated certificates?
As long as outgoing emails have their source in my trusted environment,
this would make things easier without representing a security issue.
Is it possible to use end-to-end encryption for specific users, so that
a specific user has it's own private key stored on his client and djigzo
only passes through the encrypted email?
I tried to do so. But as I don't have any CA except Djigzo's built-in
CA, i created the internal user and its certificate with the built-in
CA, exported the key to the client, deleted the user, but Djigzo still
decrypts incoming E-Mail for this user before. Is this a bug or working
as intended?
You must delete the users certificate/key after export in Djigzo. The
"user" is only a container for user specific settings and created
on-the-fly with defaults if not available. As long as Djigzo finds a
matching private key it does its work and decrypt the message.
On incoming signed E-Mails, Djigzo puts the CN of the sender's
intermediate CA next to the "X-Djigzo-Info-Signer-ID-0-1"-header.
Shouldn't it be the CN of the sender's user certificate which is displayed?
Same thing happens with the "
X-Djigzo-Info-Encryption-Recipient-0-0"-Header in incoming encrypted
E-Mails.
I can understand the misunderstanding :). S/MIME (or CMS to be exact)
identifies a signing and encryption certificate using the following two
methods:
Issuer/Serial number or,
Subject Key Identifier
Subject Key Identifier is not widely used so in most cases Issuer/Serial
is used. The reason behind this is that in principle the sender is not
obliged to add the signing certificate to the email.
These headers are adding more or less for debugging purposes. I can
however understand that it would be nice to also add info about the
signing certificate. If you want you can add a JIRA feature request for
this. Not sure however when it will be added.
Is there a way to use the value of the FROM-header instead of the
default CN ("persona non-validated" by default) for automatically
generated certificates?
As long as outgoing emails have their source in my trusted environment,
this would make things easier without representing a security issue.
The email address is added to the Subject of the generated certificate.
But you also want to use the "name" part of the from?
Is it possible to use end-to-end encryption for specific users, so that
a specific user has it's own private key stored on his client and djigzo
only passes through the encrypted email?
Only if the message is encrypted with a certificate for which the
gateway does not have a private key.
I tried to do so. But as I don't have any CA except Djigzo's built-in
CA, i created the internal user and its certificate with the built-in
CA, exported the key to the client, deleted the user, but Djigzo still
decrypts incoming E-Mail for this user before. Is this a bug or working
as intended?
See Andreas explanation (i.e., you should delete the certificate with
the private key).
The standard mail clients i'm aware of don't display headers at all so
not sure what you are trying to achieve...
of course you are right, but i'm thinking about if it makes sense to
make this information (wether the email was encrypted and/or signed)
accessible for end-users in a way they can unterstand it, for instance
by extending the web mail software. same as a possible
thunderbird-addon, which was discussed some time ago in this mailing
list (http://lists.djigzo.com/pipermail/users/2010-July/000335.html)
You must delete the users certificate/key after export in Djigzo. The
"user" is only a container for user specific settings and created
on-the-fly with defaults if not available. As long as Djigzo finds a
matching private key it does its work and decrypt the message.
Regards
Andreas
as i was not quite sure anymore if i deleted the certificate/key or not
i tested it once again. djigzo decrypts the message even after deleting
the certificate/key. even after rebooting the gateway.
kind regards
bernhard
···
Am 12.01.2011 16:02, schrieb lst_hoe02(a)kwsoft.de:
exactly, i'd like to use the name-part of the from-header as common name.
···
Am 12.01.2011 16:26, schrieb Martijn Brinkers:
Is there a way to use the value of the FROM-header instead of the
default CN ("persona non-validated" by default) for automatically
generated certificates?
As long as outgoing emails have their source in my trusted environment,
this would make things easier without representing a security issue.
The email address is added to the Subject of the generated certificate.
But you also want to use the "name" part of the from?
Zitat von Bernhard Heinzle <bernhard.heinzle(a)gmail.com>:
The standard mail clients i'm aware of don't display headers at all so
not sure what you are trying to achieve...
of course you are right, but i'm thinking about if it makes sense to
make this information (wether the email was encrypted and/or signed)
accessible for end-users in a way they can unterstand it, for instance
by extending the web mail software. same as a possible
thunderbird-addon, which was discussed some time ago in this mailing
list (http://lists.djigzo.com/pipermail/users/2010-July/000335.html)
With this in mind it would be useful, yes.
You must delete the users certificate/key after export in Djigzo. The
"user" is only a container for user specific settings and created
on-the-fly with defaults if not available. As long as Djigzo finds a
matching private key it does its work and decrypt the message.
as i was not quite sure anymore if i deleted the certificate/key or not
i tested it once again. djigzo decrypts the message even after deleting
the certificate/key. even after rebooting the gateway.
Huhh? This would be magic, because without private key you can and
should never be able to decrypt a message. Do you maybe have more than
one key for the user (=address) in question or using the same private
key in different certificates?
BTW: I have seen you are using the built in CA. In most cases it is
more useful to get some cheap "well-known" certificates like from
www.startssl.com instead, so you don't suffer the pain to distribute
your root CA certificate. The builtin CA is useful if you like to
create a "island-of-trust" or a S/MIME site-to-site VPN.
Regards
Andreas
···
Am 12.01.2011 16:02, schrieb lst_hoe02(a)kwsoft.de:
as i was not quite sure anymore if i deleted the certificate/key or not
i tested it once again. djigzo decrypts the message even after deleting
the certificate/key. even after rebooting the gateway.
Are you sure you deleted all private keys? You can see with what
certificates the message was encrypted with from the headers. Are you
sure that the gateway does not have a copy of the signer's private key?
Email clients also encrypt the message with the signing certificate to
make sure you can read the message from the sent items folder.
seems as if i found the reason.
as the sender's certificate was issued by the same CA as the recipient's
certificate, djigzo took the sender's certificate for decrypting the
message. could this be the explanation?
if yes:
given the situation that user a and b are internal users in djigzo, b
gets deleted (user, certificate and keys), but emails send to a and b
still can be read by b because djigzo uses the key of user a. is this
justifiable (if the explanation mentioned above is correct)?
kind regards,
bernhard
···
Am 12.01.2011 17:37, schrieb Martijn Brinkers:
as i was not quite sure anymore if i deleted the certificate/key or not
i tested it once again. djigzo decrypts the message even after deleting
the certificate/key. even after rebooting the gateway.
Are you sure you deleted all private keys? You can see with what
certificates the message was encrypted with from the headers. Are you
sure that the gateway does not have a copy of the signer's private key?
Email clients also encrypt the message with the signing certificate to
make sure you can read the message from the sent items folder.
Zitat von Bernhard Heinzle <bernhard.heinzle(a)gmail.com>:
The standard mail clients i'm aware of don't display headers at all so
not sure what you are trying to achieve...
of course you are right, but i'm thinking about if it makes sense to
make this information (wether the email was encrypted and/or signed)
accessible for end-users in a way they can unterstand it, for instance
by extending the web mail software. same as a possible
thunderbird-addon, which was discussed some time ago in this mailing
list (http://lists.djigzo.com/pipermail/users/2010-July/000335.html)
With this in mind it would be useful, yes.
You must delete the users certificate/key after export in Djigzo. The
"user" is only a container for user specific settings and created
on-the-fly with defaults if not available. As long as Djigzo finds a
matching private key it does its work and decrypt the message.
as i was not quite sure anymore if i deleted the certificate/key or not
i tested it once again. djigzo decrypts the message even after deleting
the certificate/key. even after rebooting the gateway.
Huhh? This would be magic, because without private key you can and
should never be able to decrypt a message. Do you maybe have more than
one key for the user (=address) in question or using the same private
key in different certificates?
'magic' would be the right word
it might be that i found the solution (see the reply on martjin's post)
BTW: I have seen you are using the built in CA. In most cases it is more
useful to get some cheap "well-known" certificates like from
www.startssl.com instead, so you don't suffer the pain to distribute
your root CA certificate. The builtin CA is useful if you like to create
a "island-of-trust" or a S/MIME site-to-site VPN.
sure, but i'm still using djigzo in a testing environment, but thanks
for the advice.
···
Am 12.01.2011 17:32, schrieb lst_hoe02(a)kwsoft.de:
Am 12.01.2011 16:02, schrieb lst_hoe02(a)kwsoft.de:
seems as if i found the reason.
as the sender's certificate was issued by the same CA as the recipient's
certificate, djigzo took the sender's certificate for decrypting the
message. could this be the explanation?
Yes if the private key of the sender is stored on the gateway and the
message was encrypted by an email client (Outlook, Thunderbird) etc. the
gateway will be able to decrypt the message. The email client will also
encrypt the message with the certificate of the sender to make sure the
sender can open the message from the sent items folder.
if yes:
given the situation that user a and b are internal users in djigzo, b
gets deleted (user, certificate and keys), but emails send to a and b
still can be read by b because djigzo uses the key of user a. is this
justifiable (if the explanation mentioned above is correct)?
Yes. Djigzo tries to decrypt the message not matter who the recipient
is. It only looks with which certificate the message was encrypted with
and uses the private key associated with the certificate.
Djigzo also checks attached messages (message/rfc822) to see whether
they are encrypted. You can for example forward two messages both
encrypted with a different certificate and Djigzo will decrypt the
messages (if a private key is available).
> > if yes:
> > given the situation that user a and b are internal users in djigzo,
> > b gets deleted (user, certificate and keys), but emails send to a
> > and b still can be read by b because djigzo uses the key of user a.
> > is this justifiable (if the explanation mentioned above is correct)?
>
> Yes. Djigzo tries to decrypt the message not matter who the recipient
> is. It only looks with which certificate the message was encrypted
> with and uses the private key associated with the certificate.
>
> Djigzo also checks attached messages (message/rfc822) to see whether
> they are encrypted. You can for example forward two messages both
> encrypted with a different certificate and Djigzo will decrypt the
> messages (if a private key is available).
I think this behaviour can be used to decrypt messages in a way it was
never intended to:
Given the situation a colleague of mine receives an encrypted email from
an external communication partner. I was able to eavesdrop the SMTP
communication between the sender and our Djigzo appliance, so I possess
the encrypted mail cipher. I may now send the encrypted mail to myself
via our Djigzo Appliance to gain access to the content of the mail:
Djigzo decrypts the mail with the key of my colleague, but delivers the
mail to myself.
In my opinion Djigzo should not deliver any decrypted mails to
recipients their certificate was not used to encrypt the mail.
Is this behaviour intended to exist? I think not even being in the same
enterprise legitimises being able to decrypt confidential messages of
others.
I think this behaviour can be used to decrypt messages in a way it
was never intended to: Given the situation a colleague of mine
receives an encrypted email from an external communication partner. I
was able to eavesdrop the SMTP communication between the sender and
our Djigzo appliance, so I possess the encrypted mail cipher. I may
now send the encrypted mail to myself via our Djigzo Appliance to
gain access to the content of the mail: Djigzo decrypts the mail with
the key of my colleague, but delivers the mail to myself.
"was never intended to" depends on how you look at it :). From my point
of view it was intended that way because I implemented it that way.
Djigzo is an email encryption gateway that encrypts and decrypts email
at the gateway level. If you don't want email to be decrypted at the
gateway level than don't put the private key on the gateway. If the
private key is not available, the message cannot be decrypted.
In my opinion Djigzo should not deliver any decrypted mails to
recipients their certificate was not used to encrypt the mail.
Is this behaviour intended to exist? I think not even being in the
same enterprise legitimises being able to decrypt confidential
messages of
Then you should either not use a gateway encryption product or encrypt
email for specific users with certificates that are not stored on the
gateway (i.e., use real desktop-to-desktop encryption). A gateway
encryption solution assumes that you can trust you internal infrastructure.
I can see whether I can make it optional (default off) to add checks to
make sure the email is only delivered in decrypted form if the email
address matches the certificate used for decryption. There are a couple
of problems that need to be solved.
** Start of technical stuff you can skip if you are not interested **
A message can have multiple recipients so the message should be split if
encrypted into multiple recipients. It's also unclear how to handle
domain encryption. Domain encryption is used by companies to setup a
secure S/MIME tunnel. It currently is not clear whether the certificate
was intended as a domain certificate so if additional checks are
required to make sure only the intended recipients can read the message
the receiving gateway should know whether the certificate is a domain
certificate. Another option would be to completely disable domain
encryption if the additional checks are enabled because you probably
don't want domain encryption in that case.
Kind regards,
Martijn
···
On 02/01/2011 11:11 AM, Manuel Faux wrote:
Is this behaviour intended to exist? I think not even being in the same
enterprise legitimises being able to decrypt confidential messages of
others.
"was never intended to" depends on how you look at it :). From my
point of view it was intended that way because I implemented it that way.
Djigzo is an email encryption gateway that encrypts and decrypts email
at the gateway level. If you don't want email to be decrypted at the
gateway level than don't put the private key on the gateway. If the
private key is not available, the message cannot be decrypted.
What do you think is the benefit of this feature? Is there any "normal"
situation you forward an encrypted email without reencrypting it?
Then you should either not use a gateway encryption product or encrypt
email for specific users with certificates that are not stored on the
gateway (i.e., use real desktop-to-desktop encryption). A gateway
encryption solution assumes that you can trust you internal infrastructure.
I think a gateway solution should not weaken the security of a
desktop-to-desktop scenario, in situations it is not necessary in. I use
a gateway scenario, because I want to benefit from the advantages like a
centralized archive, an enforceable security policy and the transparency
in front of my users. On the one hand I share your opinion, that in general
you should assume to trust your internal infrastructure, but on the other
hand there may be employees with different responsibilities which may not
share same trust level.
I have noticed, that other products refuse to decrypt messages in such a
scenario. I just wanted to make sure you are aware of this feature and
wanted to hear your opinion about it.
I think a gateway solution should not weaken the security of a
desktop-to-desktop scenario, in situations it is not necessary in.
The reason to use a gateway is that most users find it too hard to use
email encryption properly. If your end users will not use encryption,
then it's better to have gateway to gateway encryption than no
encryption at all. If you're willing to force your user to use desktop
encryption, then you don't need a gateway for encryption. The use of a
gateway would be limited to issuing certificates and certificate
management and such.
dagdag
Christine
···
On 02/01/2011 12:36 PM, Manuel Faux wrote:
I use
a gateway scenario, because I want to benefit from the advantages like a
centralized archive, an enforceable security policy and the transparency
in front of my users. On the one hand I share your opinion, that in general
you should assume to trust your internal infrastructure, but on the other
hand there may be employees with different responsibilities which may not
share same trust level.
I have noticed, that other products refuse to decrypt messages in such a
scenario. I just wanted to make sure you are aware of this feature and
wanted to hear your opinion about it.
I was just thinking of the following situation which actually happens in
my case. I still use a very old email address I have already for a long
time (m.brinkers(a)pobox.com). Pobox is only a forwarding service so email
sent to my Pobox account is forwarded to my Djigzo email address. When
someone sends encrypted email to my Pobox account using an email client
it will be encrypted with the certificate for the Pobox email address.
The email however will be forwarded to my Djigzo address. The gateway
can decrypt the message because the gateway contains the private key of
the Pobox account. When strict mode will be enabled, the gateway will
refuse to decrypt the message because there will be a mismatch between
recipient email address and certificate email address. Whether or not
this is a good think (not in my case) it of course up to the gateway admin.
Kind regards,
Martijn Brinkers
···
On 02/01/2011 12:36 PM, Manuel Faux wrote:
"was never intended to" depends on how you look at it :). From my
point of view it was intended that way because I implemented it that way.
Djigzo is an email encryption gateway that encrypts and decrypts email
at the gateway level. If you don't want email to be decrypted at the
gateway level than don't put the private key on the gateway. If the
private key is not available, the message cannot be decrypted.
What do you think is the benefit of this feature? Is there any "normal"
situation you forward an encrypted email without reencrypting it?
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
"was never intended to" depends on how you look at it :). From my
point of view it was intended that way because I implemented it that way.
Djigzo is an email encryption gateway that encrypts and decrypts email
at the gateway level. If you don't want email to be decrypted at the
gateway level than don't put the private key on the gateway. If the
private key is not available, the message cannot be decrypted.
What do you think is the benefit of this feature? Is there any "normal"
situation you forward an encrypted email without reencrypting it?
I was just thinking of the following situation which actually happens in
my case. I still use a very old email address I have already for a long
time (m.brinkers(a)pobox.com). Pobox is only a forwarding service so email
sent to my Pobox account is forwarded to my Djigzo email address. When
someone sends encrypted email to my Pobox account using an email client
it will be encrypted with the certificate for the Pobox email address.
The email however will be forwarded to my Djigzo address. The gateway
can decrypt the message because the gateway contains the private key of
the Pobox account. When strict mode will be enabled, the gateway will
refuse to decrypt the message because there will be a mismatch between
recipient email address and certificate email address. Whether or not
this is a good think (not in my case) it of course up to the gateway admin.
I would suggest the following:
- For "non-domain-encryption" eg. automatic private-key selection only
use a key if the recipient address also matches
- If one would like settings like above or domain-encryption it is
necessaey to manual select the keys considered by Djigzo for
decryption and asign it to the user (address) or domain
(domain-encryption)
In any case incoming encrypted mail should be split to single
recipient to simplify the handling and allow a mix of both. The
percentage of encrypted mail which has also multiple recipients should
be low enough to not bother with the additional overhead.
I was just thinking of the following situation which actually happens in
my case. I still use a very old email address I have already for a long
time (m.brinkers(a)pobox.com). Pobox is only a forwarding service so email
sent to my Pobox account is forwarded to my Djigzo email address. When
someone sends encrypted email to my Pobox account using an email client
it will be encrypted with the certificate for the Pobox email address.
The email however will be forwarded to my Djigzo address. The gateway
can decrypt the message because the gateway contains the private key of
the Pobox account. When strict mode will be enabled, the gateway will
refuse to decrypt the message because there will be a mismatch between
recipient email address and certificate email address. Whether or not
this is a good think (not in my case) it of course up to the gateway
admin.
I would suggest the following:
- For "non-domain-encryption" eg. automatic private-key selection only
use a key if the recipient address also matches
- If one would like settings like above or domain-encryption it is
necessaey to manual select the keys considered by Djigzo for decryption
and asign it to the user (address) or domain (domain-encryption)
Yes agree. So the above settings will be used in the "strict mode".
In any case incoming encrypted mail should be split to single recipient
to simplify the handling and allow a mix of both. The percentage of
encrypted mail which has also multiple recipients should be low enough
to not bother with the additional overhead.
Yes splitting the mail into multiple emails might be the easiest
approach. However this also makes the gateway vulnerable to a DOS
attack. Suppose someone sends an encrypted message to 1000 recipients.
If the message is split up, it will explode into 1000 messages which
need to be handled/decrypted individually. In real life situations an
encrypted email can have a lot of recipients when domain encryption is
used (for example when a mailing is sent to multiple recipients).
I'm therefore thinking to split the message in two (only in strict mode)
if needed. If there is no decryption certificate for one or more users,
split the message into a message that will be decrypted and into a
message that won't be encrypted. This way you only require two messages
no matter how many recipients there are. I think I don't have to decrypt
the complete message. I only need to decrypt the encrypted session keys
to see whether there is a valid certificate for the recipient.
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
I was just thinking of the following situation which actually happens in
my case. I still use a very old email address I have already for a long
time (m.brinkers(a)pobox.com). Pobox is only a forwarding service so email
sent to my Pobox account is forwarded to my Djigzo email address. When
someone sends encrypted email to my Pobox account using an email client
it will be encrypted with the certificate for the Pobox email address.
The email however will be forwarded to my Djigzo address. The gateway
can decrypt the message because the gateway contains the private key of
the Pobox account. When strict mode will be enabled, the gateway will
refuse to decrypt the message because there will be a mismatch between
recipient email address and certificate email address. Whether or not
this is a good think (not in my case) it of course up to the gateway
admin.
I would suggest the following:
- For "non-domain-encryption" eg. automatic private-key selection only
use a key if the recipient address also matches
- If one would like settings like above or domain-encryption it is
necessaey to manual select the keys considered by Djigzo for decryption
and asign it to the user (address) or domain (domain-encryption)
Yes agree. So the above settings will be used in the "strict mode".
In any case incoming encrypted mail should be split to single recipient
to simplify the handling and allow a mix of both. The percentage of
encrypted mail which has also multiple recipients should be low enough
to not bother with the additional overhead.
Yes splitting the mail into multiple emails might be the easiest
approach. However this also makes the gateway vulnerable to a DOS
attack. Suppose someone sends an encrypted message to 1000 recipients.
If the message is split up, it will explode into 1000 messages which
need to be handled/decrypted individually. In real life situations an
encrypted email can have a lot of recipients when domain encryption is
used (for example when a mailing is sent to multiple recipients).
I'm therefore thinking to split the message in two (only in strict mode)
if needed. If there is no decryption certificate for one or more users,
split the message into a message that will be decrypted and into a
message that won't be encrypted. This way you only require two messages
no matter how many recipients there are. I think I don't have to decrypt
the complete message. I only need to decrypt the encrypted session keys
to see whether there is a valid certificate for the recipient.
This is the same problem any MTA will have. Postfix by default limit
the number of recipients per mail to 100...
What i don't found out yet is if the domain-encryption feature can be
set on the receiver side or if it is only triggered by the sender,
using one of the recipients valid certificates to encrypt mail for
many different recipients.
So is it a sender or a recipient "policy". I would for sure like to
control on my end (receiver) if i like cross-usage of
certificates/keys, but it looks like all is needed is a sender able
split certificate usage from recipient address??
In case i got it right the answer will be yes, we need a switch to
turn off this behaviour and splitting the messages in a part with
valid recipient<-->certificate pairs and a part without, which will
not be decrypted will be a way to go.
Currently the domain certificate is only used for encrypting. For
decryption the gateway works like any email client i.e, decrypt when
possible. So what I'm thinking of is to add "strict mode", In "strict
mode" a recipient will only receive the message decrypted if one of the
following is true:
1. the message is encrypted with a certificate with private key
containing an email address that matches the email address of the recipient.
or,
2. the message is encrypted with a certificate with private key that was
manually selected for the recipient
or,
3. the message is encrypted with a certificate with private key that was
manually selected for the domain of the recipient
On non-strict mode the gateway behaves like it does not i.e, decrypt
when possible.
Am I missing something?
Kind regards,
Martijn
···
On 01/-10/-28163 08:59 PM, lst_hoe02(a)kwsoft.de wrote:
This is the same problem any MTA will have. Postfix by default limit the
number of recipients per mail to 100...
What i don't found out yet is if the domain-encryption feature can be
set on the receiver side or if it is only triggered by the sender, using
one of the recipients valid certificates to encrypt mail for many
different recipients.
So is it a sender or a recipient "policy". I would for sure like to
control on my end (receiver) if i like cross-usage of certificates/keys,
but it looks like all is needed is a sender able split certificate usage
from recipient address??
In case i got it right the answer will be yes, we need a switch to turn
off this behaviour and splitting the messages in a part with valid
recipient<-->certificate pairs and a part without, which will not be
decrypted will be a way to go.
