[
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.
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.
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.
> [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
> Assignee: Alex Rudyy
> Fix For: qpid-java-6.0.1, qpid-java-6.1
>
> Attachments:
> 0001-QPID-7056-Java-Broker-Java-Client-Improve-TLS-handli.patch,
> 0001-QPID-7056-Java-Broker-Java-Client-Improve-TLS-handli.patch,
> order-cipher-suites.diff
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
