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:00:49 UTC
[jira] [Created] (DIRSERVER-2068) Failed to decrypt a timestamp if
it was encrypted with non-best-fit algo
Alexander Bersenev created DIRSERVER-2068:
---------------------------------------------
Summary: 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
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)