[
https://issues.apache.org/jira/browse/QPID-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7056:
-----------------------------
Description:
During TLS handshaking, the client requests to negotiate a cipher suite from a
list of cryptographic options that it supports, starting with its first
preference. Then, the server selects a single cipher suite from the list of
cipher suites requested by the client. Normally, the selection honors the
client's preference.
Both Qpid Broker and Client need to be able influence the order of cipher
suites to negotiate. At the moment, the order of cipher suites is defined in
JDK implementations. For example, in Oracle 1.8 JDK GCM cipher suites (for
example, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, etc) are faster then
TLS_ECDHE_RSA_WITH_AES_255_CBC_SHA384 but cipher suite
TLS_ECDHE_RSA_WITH_AES_255_CBC_SHA384 is selected during negotiation of TLS.
Both broker and client should be able to override the order of cipher suites.
Thus, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 should be considered before
TLS_ECDHE_RSA_WITH_AES_255_CBC_SHA384.
Additionally, Broker should be able to select cipher suites based on its own
preference rather than the client's preference in order to mitigate the risks
of using weak cipher suites.
was:
During TLS handshaking, the client requests to negotiate a cipher suite from a
list of cryptographic options that it supports, starting with its first
preference. Then, the server selects a single cipher suite from the list of
cipher suites requested by the client. Normally, the selection honors the
client's preference. However, to mitigate the risks of using weak cipher
suites, the Broker may select cipher suites based on its own preference rather
than the client's preference.
Additionally, Broker should allow changing the preference order of cipher
suites to be able to select faster cipher suites. For example, GCM cipher
suites are faster then TLS_ECDHE_RSA_WITH_AES_255_CBC_SHA384. Thus, ciphers
suites like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 should be considered to use
before TLS_ECDHE_RSA_WITH_AES_255_CBC_SHA384.
Component/s: Java Client
Summary: [Java Broker/Client] Allow overriding of TLS cipher suites
preferences (was: [Java Broker] Allow overriding of TLS cipher suites
preferences)
> [Java Broker/Client] Allow overriding of TLS cipher suites preferences
> ----------------------------------------------------------------------
>
> Key: QPID-7056
> URL: https://issues.apache.org/jira/browse/QPID-7056
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker, Java Client
> Reporter: Alex Rudyy
>
> During TLS handshaking, the client requests to negotiate a cipher suite from
> a list of cryptographic options that it supports, starting with its first
> preference. Then, the server selects a single cipher suite from the list of
> cipher suites requested by the client. Normally, the selection honors the
> client's preference.
> Both Qpid Broker and Client need to be able influence the order of cipher
> suites to negotiate. At the moment, the order of cipher suites is defined in
> JDK implementations. For example, in Oracle 1.8 JDK GCM cipher suites (for
> example, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, etc) are faster then
> TLS_ECDHE_RSA_WITH_AES_255_CBC_SHA384 but cipher suite
> TLS_ECDHE_RSA_WITH_AES_255_CBC_SHA384 is selected during negotiation of TLS.
> Both broker and client should be able to override the order of cipher suites.
> Thus, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 should be considered before
> TLS_ECDHE_RSA_WITH_AES_255_CBC_SHA384.
> Additionally, Broker should be able to select cipher suites based on its own
> preference rather than the client's preference in order to mitigate the risks
> of using weak cipher suites.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
