You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Alexander Bersenev (JIRA)" <ji...@apache.org> on 2015/06/02 22:01:50 UTC
[jira] [Updated] (DIRSERVER-2068) Failed to decrypt a timestamp if
it was encrypted with non-best-fit algo
[ https://issues.apache.org/jira/browse/DIRSERVER-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Bersenev updated DIRSERVER-2068:
------------------------------------------
Attachment: preauth.patch
The patch
> Failed to decrypt a timestamp if it was encrypted with non-best-fit algo
> ------------------------------------------------------------------------
>
> Key: DIRSERVER-2068
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2068
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: core
> Affects Versions: 2.0.0-M20
> Reporter: Alexander Bersenev
> Fix For: 2.0.0-M21
>
> Attachments: preauth.patch
>
>
> Suppose the client supports two encryption suites:
> default_tkt_enctypes = des-cbc-md5 des3-cbc-sha1-kd
> Server also supports three encryption suites:
> des-cbc-md5, des3-cbc-sha1-kd and aes128-cts-hmac-sha1-96
> The client send as-req with list of supported ciphers. Server answers the client with three ciphers.
> The client chooses des-cbc-md5 and sends as-req with encrypted timestamp.
> The bug is here. The server can try to decrypt timestamp with wrong algo(des3-cbc-sha1-kd). This occurs because of function
> getBestEncryptionType( Set<EncryptionType> requestedTypes, Set<EncryptionType> configuredTypes )
> returns some encryption type that both client and server support. It not necessary the cipher that was used to encrypt the timestamp.
> Attached patch does decryption of timestamp always with cipher it was encrypted(if the server is configured to support that cipher)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)