lst_hoe02(a)kwsoft.de wrote:
>
> at least in theory there should be some certificate directorys
> available to search for the public key of a given mailaddress. This
> lead to some questions e.g.
A certificate directory would definitely be a good add-on for Djigzo.
Christine
>
> - Are there really some known "certificate yellow pages" available for
> public?
>
> - Would Djigzo be able to use such a directory to request public keys?
>
> Thanks for any comments
>
> Andreas
>
--
dagdag is just a two-character rotation of byebye.
lst_hoe02(a)kwsoft.de wrote:
>
> Have i got it right that you plan to operate some sort of LDAP directory
> as "cache" for numerous others like ldap://directory.bridge-ca.org and
> others?
Yes LDAP or HTTP (see for example rfc4387)
It's similar to a PGP key server.
> If Djigzo get really widely used this can get expensive i guess...
A certificate is not that big and you only need to retrieve it once but
yes if it becomes really popular you'll need multiple servers,
redundancy etc.
> Hm, it would not be that security sensitive as the Djigzo instances do
> the querys should still check if the certificates which they get are
> valid, so one could start with some sort of VPS with around 10Euro/month
> as server.
We have our own rack so we host our own server.
Yes you are right in that the Djigzo server should decide whether a
certificate is trusted or not (the owner decides which roots to trust)
so you don't need to trust the directory
> But the main question would be how to get the certificates in the store.
I was thinking of the following. The directory server trusts some of the
main CAs (like Verisign, StartSSL, CACert etc). If someone starts a
search for a certificate the directory cache will checks it's cache and
also checks all external servers (Verisign, CACert etc) for matching
certs. If an external server has a matching cert it will be stored in
the cache. A user can also upload a certificate. If the certificate is
trusted (ie issued by a root trusted by the directory cache) it will be
automatically accepted. If the certificate is not trusted the user has
to finish a captcha test (to prevent someone from 'spamming' the
directory). Or if you are an approved user you can be allowed to upload
certificates without a captcha test.
Kind regards,
Martijn Brinkers
--
Djigzo open source email encryption
lst_hoe02(a)kwsoft.de wrote:
>
> As said in theory this "yellow pages" are already available but i have
> found only one (meta-directory) so far at ldap://directory.bridge-ca.org.
> At least in germany every CA providing services like "qualifizierte
> elektronische Signatur" should have one too, but i have not found one yet.
But it would be nice to build some kind of caching certificate directory
that interfaces with other directories. The main advantage of this is
that a client only need one interface to query multiple directories.
>
>> Djigzo, or any other S/MIME solution, can then query the server for
>> certificates.
>
> Some comercial solutions already does something like that. It could be
> as simple as do an LDAP query i guess. Uploading our own certificates
> would be more difficult as it normaly require that you are subscribed of
> some sort at the provider.
Yes but that's why it would be nice to have our own directory that
allows others to upload their certificates.
Martijn
--
Djigzo open source email encryption
lst_hoe02(a)kwsoft.de wrote:
> at least in theory there should be some certificate directorys available
> to search for the public key of a given mailaddress. This lead to some
> questions e.g.
>
> - Are there really some known "certificate yellow pages" available for
> public?
>
> - Would Djigzo be able to use such a directory to request public keys?
>
Good idea!
This has been on my mind for some time now. To create a publicly
accessible certificate store (yellow page like you named it). The
certificate server can periodically query existing certificate servers
(like Verisign) for updated certificates and allow users to upload their
certificates.
Djigzo, or any other S/MIME solution, can then query the server for
certificates.
Need to find some time though to build it :)
--
Djigzo open source email encryption
Hello
at least in theory there should be some certificate directorys
available to search for the public key of a given mailaddress. This
lead to some questions e.g.
- Are there really some known "certificate yellow pages" available for public?
- Would Djigzo be able to use such a directory to request public keys?
Thanks for any comments
Andreas
lst_hoe02(a)kwsoft.de wrote:
>
> I would not say it should only be done with SASL. We should clearly
> state in the documentation that the input mailadresses must be validated
> to prevent fraud, but this should not be limited to SASL-AUTH in any
> way. A simple turn-on/tun-off option for solution 3. would be my favourite.
> The rest is up to the administration.
I have put it on the todo list. It will be included with the next release.
Thanks,
Martijn
--
Djigzo open source email encryption
lst_hoe02(a)kwsoft.de wrote:
>> 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...
>
I prefer solution 3 because you can tell Postfix that it should not
accept the message when envelope sender is not equal to the SASL
authenticated user. With solution 3 Djigzo then makes sure that the from
is equal to the envelope sender.
A problem with both solutions is that the check should only be done when
the user has authenticated via SASL (and when you enable the option of
course). You can add a SASL Authenticated header to the Received header
but I don't know how reliable checking for this is.
> This is something from Jetty installed by default (see
> /etc/jetty6/jetty.xml) and i'm not sure if it is save to disable...
I will check this
Kind regards,
Martijn
--
Djigzo open source email encryption
lst_hoe02(a)kwsoft.de wrote:
> This guy has completely overlooked the policy settings possible with
> Djigzo:
>
> http://www.infoworld.com/d/security-central/smime-gateways-can-create-fatal…
>
>
> The advantages he counts for EchoWorx mostly are present in Djigzo as
> well if i understand it correctly??
I have a mixed feeling about the article. In the article he refers to he
asked for solutions to allow virus scanning of S/MIME encrypted
messages. Because an S/MIME encrypted message can only be opened with
the correct key you somehow need to decrypt the message just before
virus scanning. There is no free lunch, you either cannot scan the
message or you have to decrypt it. He then 'complains' in the article
that the message is decrypted before virus scanning. The EchoWorx
solution he prefers is afaik more-or-less a webmail solution. A link is
sent to the recipient via email. The user clicks the link and can open
the message online. The message is not encrypted and the message itself
is stored online on the EchoWorx server. If this server is hacked all
email will be accessible.
--
Djigzo open source email encryption
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 :)
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
