Topics covered by previous Maintenance Packs:
1.4.4 (Build 676):
Added Features / Abilities:
- New - Password ZIP as encryption method available
The outgoing AdHoc encryption now supports three subtypes. Besides the
classic self-extracting archive (which still provides the
best security) you may now alternatively send the message content either
as an AES-encrypted- or a Windows-compatible password ZIP.
- New - OCSP queries available
S/MIME signature verification may now utilize OCSP queries to determine
the revocation status of a signer’s certificate. This query can
be limited to be done only on qualified signatures. Be aware that in
order to successfully perform queries port 80 towards the internet needs
to be opened on the firewall.
- New - S/MIME verification protocol available
As some workflow processes require more details and transparency about
a verification process an optional verification protocol may be
added for each signature. The html based document appears as another
attachment and may be applied to attachment-signatures or
message-signatures or both. Currently theses protocols are available in
English and German. The Language will follow the decrypt summary setting.
- Logging configuration improved
Logging options have been consolidated to single view in which log level
and log history can be easily adjusted.
- RCPTS Token available in AdHoc Password Reply.
Upon customer request the password notification now also considers an RCPTS
token which allows annotating the recipients to which the password applies.
Addressed Problems / Fixes:
- Some signatures verified as ‚Data modified’
This indicator turned out to be just the tip of larger iceberg. It became
apparent, that quite a few S/MIME signatures are made in a way that the
included certificates are in reverse order. The problem arises from an OpenSSL
that isn’t capable of handling such signatures. Sometimes it would not
extract the signer’s certificate. Sometimes it wasn’t able to check the
certificate chain against the own CA store. This led us to develop to a new level
of verification in which all included certificates are extracted from the signature,
then being sorted starting with the signer and finally the chain is filled with
available sub-CA or CA certificates from the CA store. By this the verification
process and the subsequent key extraction process have become much more reliable.
- InLine PGP-Data in HTML messages not recognized or leading to a timeout.
Again this effect is rather the result of no existing standards on how to handle
HTML bodytext parts within the Inline-PGP processing method (Especially at what
stage it was encrypted: before or after HTML conversion). If looked at, the plain
text is decrypted, the HTML not. This is mainly to the inability of GnuPG to
recognize it as PGP data. This is a familiar situation as some aspects have
already been covered by the previous maintenance pack. This time some of the
samples were even capable of putting the GnuPG process in an endless loop. Luckily
the provided samples helped to find a way to avoid this and increased PGP detection
quality at the same time.
- User controlled Encryption results in undetermined upon empty subject line
This condition has been fixed.
- Operational service crashed when automatically generating new keys
The function that caused this has been reworked.
- Unverifiable signatures
As RFCs and their interpretations are sometimes no as precise as one would wish, we
had to learn, that the S/MIME key IDs may have different presentations. This sometimes
lead to unverifiable signatures on messages and keys as the matching CA certificate could
not be identified. After improving the detection for these IDs the verification has
become much more reliable.
Security issues
- PGP Module (GnuPG) update to v1.4.10
The latest version of GnuPG is part of this update. Besides small performance upgrades
no noteworthy changes in regard to to CompanyCRYPT are part of this release.
The following link provides more details.
1.4.3 (Build 651):
Added Features / Abilities:
- Status Tab added
The most visible amendment to the web interface is the summary view 'Status' under the 'System'
tab. It provides a quick overview of the service status of all CompanyCRYPT hosts within an installation
(local and remote), along with some information of re-processed messages. It is planned for
future releases to extend this initial design to allow service control of remote hosts and the display
of more statistical information.
- Improved decryption for PGP embedded within HTML
The Inline-PGP processing has received further improvement and is now
able to handle significantly more HTML transformations. Yet it has to
be recognized, that the decrypting side has no influence on the
encoding within the encrypted content. If the decrypted result is not
encoded to HTML, it will most likely not look the way the sender
intended it to be.
- Polish language support added
With this Maintenance Pack the decrypt summary and the AdHoc decryption module
(the one that the external partner will see) is also available in Polish.
Addressed Problems / Fixes:
- S/MIME signed messages - Unclear handling of trailing CRLF in signed data
It appears that OpenSSL changes its expectation towards a trailing CRLF
within different versions. To compensate this, a mechanism was
implemented to look for indicators of such a condition and to attempt a
second verification with added CRLF in the event of a verification
failure.
- OpenSSL - Problems with irregular base64 encoding line length
There are some mail encryption gateways that do not stick to a fixed
line length when encoding S/MIME data to Base64. Although this isn't
against any RFC, it became apparent, that OpenSSL is no capable of
handling this. To compensate even that, a routine has been added that
works much like a pre processor. This mechanism however can only
reformat line lengths. Any missing or corrupt data will still remain a
problem.
- UserControl without trigger together with 'Company Signing' didn't deal
with address exceptions correctly
The address exceptions simply weren't considered. This has been fixed.
- Import-Overwrite check didn't care for certificate restrictions (signonly)
When importing a sign-only certificate the pre-check didn't show the correct warning.
This has been fixed.
- AdHoc encryption and empty subject line
The combination of triggered encryption (by header value) together with
an empty subject line and no available key resulted in a crash
condition. This has been fixed.
- Distributed environment - Master on PCS only system
On a PCS only system, the master relies on a slave to provide necessary
licence information as part of the synchronisation. This process didn't
always work correctly, resulting in an invalid licence display. This
has now been fixed.
- Returncodes - Encrypt fail and undetermined
All
return code conditions have been revised to represent the process
results more precisely. This has been implemented to better follow the
concept of an actual system/process fail that requires administrative
action to be represented by 'Undetermined' whereas message processing
stops that are caused by rather operational circumstances (like no key
available) should result to 'Encrypt Fail'.
- AutoEncryption - Logic error, if recipient was on exclude list
AutoEncryption had a small logic bug when a recipient was on the exclude list
and still a user controlled trigger was set. This has been resolved.
- User controlled encryption alternatives
The alternative settings under user controlled encryption for dealing
with unavailable key conditions were overwritten by the settings from
Automatic encryption, making it impossible to use different settings.
This has now been fixed.
1.4.3 (Build 612):
Added Features / Abilities:
- Inline-PGP processing improvement
Along with a more memory orientated processing that provides significant speed
improvements, the Inline-PGP processing is now capable of dealing with
multiple PGP-blocks mixed with plan parts in the message body text.
Also some obstruction caused by HTML conversion (CRLF -- <BR>)
can now be handled.
- Detached signature files (*.asc / *.p7s)
Such files, only containing the signature of another attachment in the same
message can now be verified for PGP and S/MIME. Still some requirements
remain for this to be successful. Upon multiple attachment/signature
pairs in one message the file names have to follow the convention for
the signature files of using the original attachment name plus
appending a method related extension (like *.asc for PGP and *.p7s or
*.p7f for S/MIME). Additionally the signature attachment has to appear
after the attachment it was generated from.
- Sub-CA detection and extraction
The long
missing detection and automatic extraction of (Sub-) CA certificates
from chains included in S/MIME signatures is now implemented.
- Italian language support added
With thisMaintenance Pack the decrypt summary and the AdHoc decryption module
(the one that the external parter will see) is also available in Italian.
- Embedded (Inline) messages will not be processed anymore
This is also something that we worked for quite a while. From now on
embedded messages in containers (like Zip archives) are not processed
anymore. Also on encryption the inline messages (i.e. forwarded full
MIME messages) are not processed twice. This limits CompanyCRYPT jobs
to exactly one call per message.
Important Note: To make this come into effect all CompanyCRYPT jobs
have to be re-initialized (Click here to see how)!
Addressed Problems / Fixes:
- User Controlled Encryption with activated Company Signing - NOT CHECKED (Undetermined)
Upon Company Signing was activated with the option "If available sign
with user key" the scenario job 'User Controlled Encryption' ended with
"Encrypt/Sign --> Failed: GnuPG reports error #2 [9] " (Returncode:
NOT CHECKED). This happened regardless of an set trigger or the
availability of a recipient encryption key. This has been fixed.
- AdHoc Encryption - Empty message for recipient
Upon activation by subject control with the method AdHoc encryption an
empty message was passed to the recipient. This has been fixed.
- S/MIME Opaque Signature - Not detected as such by MIMEsweeper
It seems that MIMEsweeper relies on (optional) Content-Type-Parameters
to detect S/MIME opaque signatures. By the nature of these messages
they may be mistaken for encrypted S/MIME messages (Only one
container), but simply message and signature are combined and just
encoded to base64. CompanyCRYPT now adds those parameters to enable
clear detection.
- Chinese character set - Data mistaken for PGP
Some messages using the Chinese character sets appear to have the same
binary pattern as PGP files. Although all reported cases always showed
spam messages the effect behind it is unwanted and has therefore been
resolved.
- SyncManager - Changes are not committed on Slave systems
Unfortunately the SyncManager tool never signalled to the operational
service that local changes have been made. In effect the changes were
displayed in the SyncManager, but overwritten shortly after by the next
synchronisation cycle. This has been fixed.
- Inline-PGP - Attachments decrypted OK, but bodytext still PGP
This effect is rather the result of no existing standards on how to
handle HTML bodytext parts within the Inline-PGP processing method
(Especially at what stage it were encrypted: before or after HTML
conversion). If looked at, the plain text is decrypted, the HTML not.
this is mainly to the inability of GNPG to recognize it as PGP data.
Since
we understand that the user will consider this a failed processing, we
enhanced the decryption to even handle PGP in HTML (See: 'General
benefits' first topic). But be aware, that due to the missing
standards, the result may still not be the desired one. For one we
cannot cover all possibilities to encode text (meaning the PGP block)
into HTML. Secondly the display of the decrypted part solely depends on
what was encrypted at the senders site: HTML or plain text.
- S/MIME signed messages - Display problems using freemailer web interfaces
Many customers have reported that opaque signed S/MIME messages cannot
be displayed correctly using some freemailer web interfaces. To
minimize operational difficulties the default S/MIME signing method has
now been changed to 'Clearsign' or also known as 'detached' signatures
Noteworthy changes:
- CompanyCRYPT generated system notifications and messages are not
processed by decrypt or encrypt jobs anymore
To avoid unexpected effects and to have a more stringent processing,
all messages generated by CompanyCRYPT itself will now be ignored by
all decrypt and encrypt jobs. This rule affects all key responder
replies (key answers / notifications), import notifications, message
processing notifications anlong with 'AdHoc-encryption' password
replies.
- 'Best-Effort + User-Controlled-Encryption' renamed to 'Automatic Encryption'
Since this job is about to see more complex encryption tasks it would
be confusing to have it keep its name. Therefore it was simply
re-labled. The only visible effect should be, when opening the scenario
properties in the MIMEsweeper policy editor, that the job name is not
highlighted. The internal (MIMEsweeper identified) name remains the same.
1.4.2 (Build 584)
- User Controlled Encryption - Sensitivity setting won't work on it's own
Due to a logic error the subject control had to be activated to make other trigger
work, even if there was no keyword configured. This has been fixed
- MIME encoding 'binary' - Undetermind
The Content-Type-Encoding 'binary' has been found in some messages.
Although this is a MIME encoding type, the RFC clearly states, that it
should under no circumstances be used in internet emails. This is
mainly to the fact, that 'binary' encoding has no line length defined
and does not require CRLF as line terminators. CompanyCRYPT previously
didn't process such messages. Now the behaviour has been changed to
treat such messages as 8bit encoded content. If the sending part keeps
the lines within 1024 chars including the trailing CRLF, all things
should work smoothly.
- Best Effort - Multiple recipients
In a very few cases the splitting of emails that fall under different encryption
policies (PGP, S/MIME, Plain) did completely fail and result in illegal
address formats. This has been fixed.
- Isolated PKS7 signature file - 'Too many encryption layers'
If a PKCS7 signature file was attached to message with no linkable data
from which this signature was derived, the decrypt process refuses the
messages after the configured maximum reprocessing steps. This is due
to the lack of a proper tagging of of the data. This has also been
fixed.
- Backup - File too large
The backup did include all log files in the log folder. In larger environments
these logs may become very large. With a default history of seven days, one backup
file may become as large as 100 MB. Having a history for the backup
files as well, the whole benefit of a backup becomes costly. Therefore
the logs are now, by default, excluded from the backup. If needed a
manual switch in the config file may be used to re-enable it.
- MIKE parameter - Reset to default
The new 'Company ID' tab unfortunately also accessed the MIKE parameters.
Whenever changes were applied in this tab, the MIKE parameters
(listener address and sender address) were reset to default. This has
been fixed.
- Synchronisation - Timeout
In some network
environments we encountered 'Traffic-Shaper' or 'Traffic Optimizer'
that interfered with the CompanyCRYPT synchronisation. This led to a
timout after a positive handshake. The sync-protocol has been modified
to even work with the modified packages.
1.4.1 (Build 572)
- User-Controlled-Encryption - Outlook parameter not working
Due to a logic error, the encryption could not be triggered using the MIME
header parameter 'Sensitivity'. This has been fixed,
- User-Controlled-Encryption - Wrong return code
When set to raise 'Encrypt fail' upon no available encrypt key the job falsely
raised a returncode, that was interpreted as 'Undetermined'. This has been
corrected to raise the proper returncode for 'Encrypt fail'.
- Import of private keys - Passphrase with special characters
When adding the feature of uploading a key, the encoding method of the import
page was modified. This unfortunately led to a double encoding of passphrases,
which made it impossible to use special characters in passphrases.
This has been fixed.
NOTE: The characters quotation marks (") and pipe symbol (|) can still not be used.
- Address detection - Falsely considered alias name data
In some rare occasions the recipient address was extracted incorrectly
from the alias name. This happened when the recipient email address
(enclosed in > <) was also entered in the alias name field
(enclosed in ") together with some valid email address characters like
('). In general the data between double-quote characters should be
ignored. The CompanyCRYPT processing therefore has been changed to
reflect this behaviour.
- Automatic key generation - Key reply send from wrong address
The sending address of key replies can be configured. However upon an
automatic key generation this setting did not have any effect and the
key reply was always send from the key owner address. This has been
corrected.
- Automatic key generation - German 'Umlaut' characters prevented key generation
This applied to the unattended generation of key material, by use of
the reference list. Whenever special characters appeared in some of the
key parameters (name, company name, ...) the process would stop and
would not generate the requested key. This has been changed to
automatically convert such characters to valid encodings (i.e. UTF-8).
- PGP key reply messages - Displayed key length wrong
The key length displayed in key replies did not show the value from the
encryption sub key, instead it showed the value from the signing sub key
(usually smaller). This has been corrected
- Service start on missing configuration file
This applied to both, the Operational and the Reprocess service. In
case of a missing Companycrypt.cfg file, the services would be shown in
Windows Service Manager as being in the process of 'Starting'. However,
never reaching the 'Started' condition the stop button never becomes
available. The services did detected the missing file condition and
stopped working, but this was not signaled back to Windows, which led
to no available buttons to control the service. The only way to stop
the process, was by ending the task using the taskmanager. This has
been fixed. The service will stop immediately after the start, upon a
missing configuration file.
Security issues
1.4.1 Build 572:
- PGP Module (GnuPG) update to v1.4.9
The latest version of GnuPG is part of this update. Besides small performance upgrades no noteworthy changes
in regard to to CompanyCRYPT are part of this release. The following link provides more details.
General benefits, added features:
1.4.2 Build 584:
- LDAP Keyserver available
The scenario jobs "Encryption - Best Effort", "Encryption - User Control" and its
combination can now query internet LDAP services to aquire encryption
certificates. The keyserver may also be configured to only query upon
given address ranges.
- Company Signing
An additional tab has been added under 'Encryption' to have a single point where to
define signing policies. This enables the 'Best Effort' and 'User Control' scenarios
to also perform sign-only tasks on mails that are not encrypted. It is also
possible to configure addresses or address ranges to be excluded from the signing
process.
1.4.1 Build 572:
- PGP - Partitioned Encoding Format now supported
The PGP corporation (this is the company producing and selling the PGP
desktop software) decided to change the handling of file names when
applying 'Inline-PGP' on emails. The file name in this format will not
be transmitted in plain text in the MIME container. Instead it becomes
part of the encrypted data. In result the normal CompanyCRYPT
decryption process would decrypt the file, but would not provide the
original file name or extension. It would have been easier for us, if
PGP had announced this prior to implementing it in their products, but
they preferred to surprise us and the customers with this new feature.
By some accidental whitepaper disclosures from eMail archives and some
reverse engineering, we are now happy to be able to process this kind
of data correctly, at least for the existing PGP implementations
(Desktop and PGP Universal). We will see what they come up with in the
future
- New 'Smart' Job - Best Effort Encryption
There is now a job (szenario) available that is independent of static
MIMEsweeper address lists. It will simply always encrypt emails for
those recipients, where the key or certificate is available within
CompanyCRYPT. If the recipients consist of a mixed group (PGP, S/MIME,
'No-Key') the eMail will be split up through the Reprocess service.
- WebGUI - Rearangements
In preparation of future improvements (multi domain support) a new tab
under Central Accounts has been introduced. Apart from the possibility
to configure the system notification sender address it doesn't provide
anything new. The purpose of this change is to integrate company relevant
settings in a single view. This will make them configurable for multiple
Company-ID's in the next update.
- BCC recipient detection
Finally a method has been developed to always get the exact SMTP email
address information from the MIMEsweeper. This solves a long term issue
on Site2Site connections, where external BCC recipients sometimes weren't
able to open encrypted messages, because the assigned key for that domain
wasn't used. With this new mechanism the processing will be using the
correct keys.
- Apple eMail client compatibility
We found Apple email clients that didn't comply with the RFC describing
PGP/MIME. When processing mails with this method, it is expected the encrypted
content is correctly MIME encoded. In this case the line endings should
be CRLF and not LF only as some examples showed. When detected, this will
now be automatically corrected.
- Key list display
The display color of expired keys is changed to grey (inactive). The
red text color will now be used to indicate that a key or certificate
is about to expire in less than 30 days. This way the signaling color
red is used more meaningful.
- Online Remote Support
With our strategic decision for the 'Teamviewer' product family for our
support section, we are now happy to provide an extremely fast and easy
to handle way of online support (similar to WebEx session). To improve
this even further the necessary client module is now integrated and
startable from the CompanyCRYPT web interface (Click on 'Remote Support'
in the startup view).