[ https://issues.apache.org/jira/browse/DIRSERVER-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pierre Smits updated DIRSERVER-2068: ------------------------------------ Fix Version/s: Upcoming release (was: 2.0.0.AM27) > 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 > Priority: Major > Fix For: Upcoming release > > 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 (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org