[Djigzo users] Customer experience

Martijn Brinkers martijn at djigzo.com
Wed Jun 17 22:33:08 CEST 2009


Hi Eamonn,

Gooed to hear from you

You seem to have quite some experience with email encryption which is 
nice :). I know most of these products just from what I could find on 
the Internet. Unfortunately I do not have any hands-on experience with 
most of these products so it's nice to get your feedback on these 
products. It's funny that you mention Ironmail. When it was still called 
PostX (which was bought by Ironport) I did some product development for 
them (specifically I created their Outlook and Lotus Notes plugins) so I 
have some experience with Ironmail products. I have been thinking of 
creating a .html envelope with a Javascript decryption engine. 
Decrypting a message body is possible but I do not see how you can 
extracting and writing attachments by using only Javascript. So for 
attachments you have to use Flash, Java, ActiveX or “push” the 
attachments to an external server because Javascript does not allow you 
to write files to your local system. I'm not sure how Ironmail solves 
this but I guess they use one of these technologies for writing the 
attachments. Replying to the encrypted message with any client-less 
solution requires you to open a portal page as well on which you have to 
reply.

The question now is whether you can reliably extract attachments from 
the .html file and store them locally. I think that most corporate users 
are not allowed to run any .html that can write to the local file 
system. Most corporate clients therefore need to open a portal to get 
the attachments from the .html. So the main question now is whether it's 
worth the trouble to do everything locally when it's not 100% reliable?

Do you know if and how others extract the attachments locally?

Kind regards,

Martijn Brinkers


Eamonn McGonigle wrote:
> Hi Martijn,
> 
> I have been playing with Djigzo for a couple of months now and I think 
> it is fantastic...so let me start by saying thanks for your hard work on 
> it and for releasing it to the open-source community.
> 
> If you are looking for votes (!), I think #2 below is a real winner.  I 
> have been evaluating Djigzo in comparison to Cisco's Ironport for a 
> number of encryption requirements.  While the "gateway-to-gateway" 
> S/MIME capabilities of Djigzo are ideal, I also have a requirement for 
> clientless support which Ironport's PXE does very nicely (but at a steep 
> price).  There appear to be a few other products out there covering the 
> same ground (the ZixDirect at www.zixcorp.com and Trend Micro Private 
> Post from Trend Micro, to pick two examples).  The PDF encryption in 
> Djigzo doesn't meet the requirements because to achieve an adequate key 
> length would require typing in a password so long that users would never 
> find it acceptable.  I considered modifying your code to lengthen the 
> PDF encryption password and increase the "alphabet" from which password 
> characters were drawn but dropped the idea when I worked out how long 
> the password would need to be to achieve even 128-bit key strength.  I 
> would therefore be delighted to see Djigzo offer the kind of clientless 
> capability you outline.
> 
> If I may venture a suggestion, I would have a slight concern about the 
> idea that the encrypted blob is pushed up to the server where the 
> decryption key is stored for decryption.  I would suggest that it is not 
> ideal to have the decryption key and the encrypted content both on this 
> server.  I know Cisco's Ironport works slightly differently.  The user 
> receives the message in a HTML wrapper similar to what you describe 
> below. When he logs onto the server, a script in his browser downloads 
> the decryption key which is then used to decrypt the blob locally on the 
> user's PC (done by a bunch of Javascript code which comes down with the 
> HTML wrapper).  This approach has the advantage that the message content 
> is never actually stored on the key server...only the decryption key 
> (which is pretty useless without the message content).  I guess the 
> obvious counter-argument is that the message is encrypted on this server 
> in the first instance so uploading it again for decryption isn't a 
> dramatic dilution of the security (once the encrypted message content 
> isn't actually stored on the same server as the decryption keys). 
> 
> Best Wishes,
> Eamonn
> 
> 
> 
> Martijn Brinkers wrote:
>> Hi Dan,
>>
>> Dan Banach wrote:
>>   
>>>    Sorry it's taken some time to respond. We deal with a wide range of
>>> email recipients (large companies, small offices, individuals, etc.)
>>> with a wide range of email encryption knowledge, so the ideal encryption
>>> solution for us would be very flexible. Not only flexible for outgoing
>>> mail, but also incoming mail as well. Some users/business' use PGP,
>>> others use certs and some use the various other options. Being able to
>>> communicate with them all is very helpful.
>>>     
>> Right now now I'm working on Blackberry S/MIME support for BIS users 
>> (for BES users there is already S/MIME email). Once that is finished I 
>> will start working on new major features. There are some features I 
>> would like to start working on but I'm not sure which one that should be.
>>
>> Two main new features I was thinking about are:
>>
>> 1. PGP support
>> 2. Client-less email encryption
>>
>> Nr 1 is clear. I will briefly explain nr 2.
>>
>> Client-less
>>
>> Currently Djigzo supports S/MIME and PDF encryption. Recipients that do 
>> not want are cannot receive S/MIME or encrypted PDFs are currently not 
>> supported. The new encryption functionality I would like to add is the 
>> following:
>>
>> If an email sent to an external recipient needs to be encrypted and the 
>> recipient cannot receive S/MIME email of an encrypted PDF the email will 
>> be converted to a .html file. The original plain-text message (and 
>> attachments) will be encrypted with a certificate for the external 
>> recipient and added to the .html. The .html will be added to a general 
>> message (which does not contain any sensitive information) and sent to 
>> the recipient. The recipient opens the .html message in the email client 
>> (can for example be hotmail). The .html will open a SSL connection to 
>> the companies Djigzo server (which can be a dedicated server just for 
>> the portal). The Djigzo server will show a login page. The recipient now 
>> has to login. After the login the recipients browser will push the 
>> encrypted 'blob' (contained in the HTML) to the portal. The portal will 
>> decrypt the message with the private key of the recipient (which is 
>> stored on the companies Djigzo server). The recipient can now read the 
>> message and download any attachments (the portal uses SSL for secure 
>> access).
>> The main advantage is that the recipient only requires a browser. The 
>> encrypted data is stored locally on the recipients system (there is no 
>> long term copy on the Djigzo server). An attacker needs access to the 
>> locally stored .html file AND the portal password to read the message.
>> The message is encrypted with the same algorithm as a S/MIME message. 
>> The only difference is that it's encoded inside a .html file.
>> A disadvantage is that the Djigzo server needs to be accessible to 
>> external recipients.
>>
>>
>> Right now I'm leaning towards implementing feature 2 but it could be 
>> that you or any other Djigzo user has another preference or request for 
>> a feature. If so I'm all ears :)
>>
>>
>>   
>>>  I
>>> think another great feature you could include would be to grant internal
>>> users the ability to manage their own decryption profiles. They should
>>> be able to add/create there own certs/keys and create their own
>>> passwords. Ideally it is tied into the directory via ldap or something
>>> so authentication and user information is seamless.
>>>
>>>     
>> One problem is that currently the settings for an external user are 
>> shared by all internal users. So, if internal user A changes settings 
>> for external user E internal user B will also be affected. Do you want 
>> the user list to be different for each internal user?
>> Right now you can add admins with different roles. You can add an admin 
>> that can add keys etc. but not change the MTA settings,
>>
>>
>>
>> Kind regards,
>>
>> Martijn
>> _______________________________________________
>> Users mailing list
>> Users at lists.djigzo.com
>> http://lists.djigzo.com/lists/listinfo/users
>>
>>   
> _______________________________________________
> Users mailing list
> Users at lists.djigzo.com
> http://lists.djigzo.com/lists/listinfo/users
> 


-- 
Djigzo open source email encryption



More information about the Users mailing list