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)