Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
Currently the domain certificate is only used for encrypting. For
decryption the gateway works like any email client i.e, decrypt when
possible.
That's what i suspected. "Domain-encryption" is thus "enforced" by the
sender as of today because receiving site has no way to prevent
decrypting for all recipients with *any* matching private-key...
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.
Sounds like a sane solution to me.
Am I missing something?
The documentation needs to be adjusted. As of now i have difficulties
to find the relevant parts for "S/MIME VPN" or "domain-encryption" or
however we will call it in future. I'm sure i have read about it
somewhere but i'm not able to find it again
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?
I also think this behavior sounds reasonable, but I do not understand why to
differentiate between those two modes. As far as I can follow, I do not see
any need for decryption with a certificate's key which does not contain the
correct e-mail address nor was manually associated with the user or the domain.
When thinking about your pobox-scenario, Martijn, you could manually assign the
pobox certificate with your actual email address and the decryption would even
work in "high-secure mode".
I think having two modes is better than having just one. The main reason
for the decrypt if possible mode is that it's much easier from a
management perspective. With the only decrypt when the email address
match mode setting up an S/MIME tunnel for domain encryption requires
both the sender and the recipient to setup the correct certificate. Also
when forwarding you need to do more work.
Some companies don't like to have encrypted email within their
infrastructure because it cannot be scanned so they prefer to decrypt
when possible. Whether or not you think "decrypt if possible" is a good
thing or not depends on what you think a gateway should do. I therefore
think having the two options is the best thing to do. I'll need to
explain the pros and cons of the two approaches to make it easier for an
end user to understand.
Kind regards,
Martijn
···
On 02/02/2011 09:57 AM, Manuel Faux wrote:
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?
I also think this behavior sounds reasonable, but I do not understand why to
differentiate between those two modes. As far as I can follow, I do not see
any need for decryption with a certificate's key which does not contain the
correct e-mail address nor was manually associated with the user or the domain.
When thinking about your pobox-scenario, Martijn, you could manually assign the
pobox certificate with your actual email address and the decryption would even
work in "high-secure mode".
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
···
On 02/02/2011 09:57 AM, Manuel Faux wrote:
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?
I also think this behavior sounds reasonable, but I do not understand why to
differentiate between those two modes. As far as I can follow, I do not see
any need for decryption with a certificate's key which does not contain the
correct e-mail address nor was manually associated with the user or
the domain.
When thinking about your pobox-scenario, Martijn, you could
manually assign the
pobox certificate with your actual email address and the decryption
would even
work in "high-secure mode".
I think having two modes is better than having just one. The main reason
for the decrypt if possible mode is that it's much easier from a
management perspective. With the only decrypt when the email address
match mode setting up an S/MIME tunnel for domain encryption requires
both the sender and the recipient to setup the correct certificate. Also
when forwarding you need to do more work.
Some companies don't like to have encrypted email within their
infrastructure because it cannot be scanned so they prefer to decrypt
when possible. Whether or not you think "decrypt if possible" is a good
thing or not depends on what you think a gateway should do. I therefore
think having the two options is the best thing to do. I'll need to
explain the pros and cons of the two approaches to make it easier for an
end user to understand.
I agree that if it is possible, let the user choose.
As i'm in progress updating the main server it would be nice if you
could estimate a timeframe for the next release including this change.
I'm currently working on new features, the main new feature is scanning
of outgoing email for certain content based on regular expressions (for
data leak prevention), but it could take about two weeks to finish it.
The new release also has support for DSN.
I will start working on the "strict mode" feature this week and need to
decide whether I will backport it to the previous release or whether the
new release will be finished soon enough. To answer your question I hope
to have it finished within two weeks either the new release or a
backport (or both).
The majority of the work is testing and building the virtual appliances
and testing them. If you want to work with a bleeding edge version
(which is well tested btw) I can probably deliver faster.
Kind regards,
Martijn
···
On 01/-10/-28163 08:59 PM, lst_hoe02(a)kwsoft.de wrote:
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
On 02/02/2011 09:57 AM, Manuel Faux wrote:
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?
I also think this behavior sounds reasonable, but I do not understand
why to
differentiate between those two modes. As far as I can follow, I do
not see
any need for decryption with a certificate's key which does not
contain the
correct e-mail address nor was manually associated with the user or
the domain.
When thinking about your pobox-scenario, Martijn, you could manually
assign the
pobox certificate with your actual email address and the decryption
would even
work in "high-secure mode".
I think having two modes is better than having just one. The main reason
for the decrypt if possible mode is that it's much easier from a
management perspective. With the only decrypt when the email address
match mode setting up an S/MIME tunnel for domain encryption requires
both the sender and the recipient to setup the correct certificate. Also
when forwarding you need to do more work.
Some companies don't like to have encrypted email within their
infrastructure because it cannot be scanned so they prefer to decrypt
when possible. Whether or not you think "decrypt if possible" is a good
thing or not depends on what you think a gateway should do. I therefore
think having the two options is the best thing to do. I'll need to
explain the pros and cons of the two approaches to make it easier for an
end user to understand.
I agree that if it is possible, let the user choose.
As i'm in progress updating the main server it would be nice if you
could estimate a timeframe for the next release including this change.
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
···
On 01/-10/-28163 08:59 PM, lst_hoe02(a)kwsoft.de wrote:
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
On 02/02/2011 09:57 AM, Manuel Faux wrote:
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?
I also think this behavior sounds reasonable, but I do not understand
why to
differentiate between those two modes. As far as I can follow, I do
not see
any need for decryption with a certificate's key which does not
contain the
correct e-mail address nor was manually associated with the user or
the domain.
When thinking about your pobox-scenario, Martijn, you could manually
assign the
pobox certificate with your actual email address and the decryption
would even
work in "high-secure mode".
I think having two modes is better than having just one. The main reason
for the decrypt if possible mode is that it's much easier from a
management perspective. With the only decrypt when the email address
match mode setting up an S/MIME tunnel for domain encryption requires
both the sender and the recipient to setup the correct certificate. Also
when forwarding you need to do more work.
Some companies don't like to have encrypted email within their
infrastructure because it cannot be scanned so they prefer to decrypt
when possible. Whether or not you think "decrypt if possible" is a good
thing or not depends on what you think a gateway should do. I therefore
think having the two options is the best thing to do. I'll need to
explain the pros and cons of the two approaches to make it easier for an
end user to understand.
I agree that if it is possible, let the user choose.
As i'm in progress updating the main server it would be nice if you
could estimate a timeframe for the next release including this change.
I'm currently working on new features, the main new feature is scanning
of outgoing email for certain content based on regular expressions (for
data leak prevention), but it could take about two weeks to finish it.
The new release also has support for DSN.
I will start working on the "strict mode" feature this week and need to
decide whether I will backport it to the previous release or whether the
new release will be finished soon enough. To answer your question I hope
to have it finished within two weeks either the new release or a
backport (or both).
The majority of the work is testing and building the virtual appliances
and testing them. If you want to work with a bleeding edge version
(which is well tested btw) I can probably deliver faster.
Because i have to test the new mailserver anyway it would be fine to
have something like a RC version which could later be replaced by the
final release.
My mail server is configured to process mail for about ten different
domains. In all domains, there's mail that is forwarded to one of my
personal email addresses. I read that mail on one of three different
computers and a smartphone. If encrypted email is not decrypted and
re-encrypted on my djigzo server, I'd have to have private keys of all
email adresses that I receive mail for, on each of those computers.
Because Djigzo neatly reencrypts the mail, I only need one private key
for all mail. The fact that the mail is re-encrypted doesn't bother me,
because I trust my server.
As Martijn said, if some messages are too private and/or secret to be
decrypted on the server, just don't put the private key for that
particular email address on the server. Like, in a company you could
have board members decrypt their email on their laptop. The Djigzo
gateway will simply keep the mail encrypted because it can't encrypt it.
You could even supply two different certificates to board members, one
of wich the private key sits on the Djigzo gateway, the others private
key only sits on the persons laptop.
I do agree with you that there's a potential security hole. The fact
that you can intercept an encrypted email and redirect it to someone
else who can read it unencrypted requires an accomplice inside the
organization. If you have "the bad guys" inside your organization, then
your problems are not limited to email security. But suppose a very
confidential message to the board gets redirected to "all(a)acme.com".
Then everybody in the company gets the confidential email, unencrypted.
But then, sending email that should be confidential for most of your
staff, I don't think it's a good idea to encrypt that with a key that
sits on the gateway anyway.
Martijn, I do second the wish to have a "paranoid" feature on the
gateway. Setting that to "on" for me would mean that I have to keep more
private keys on more computers and phones, so I wouldn't use it.
dagdag
Christine
···
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?
--
The total amount of clue on the Internet is a fixed constant (Bill
Cheswick, ca. 1994).
The Internet has grown a lot since then (Wietse Venema, 2011).
