[
https://issues.apache.org/jira/browse/QPID-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16319932#comment-16319932
]
Rob Godfrey edited comment on QPID-8064 at 1/10/18 9:08 AM:
------------------------------------------------------------
I think it is reasonable for the FileKeyStore to validate that at least one
entry of type PrivateKeyEntry is present, and that a FileTrustStore validates
there is at least one element of type TrustedCertificateEntry. The interfaces
for KeyStore and TrustStore imply the requirement for these entry types in the
store. Additionally we should ensure that no assumptions are made that the
underlying Java KeyStore *only* contains these entry types. For instance I
think FileTrustStoreImpl createCertificates(final KeyStore ts) should change
{code:java}
while (aliases.hasMoreElements())
{
certificates.add(ts.getCertificate(aliases.nextElement()));
}
{code}
to
{code:java}
while (aliases.hasMoreElements())
{
String alias = aliases.nextElement();
if(ts.isCertificateEntry(alias))
{
certificates.add(ts.getCertificate(alias));
}
}
{code}
and the constructor of QpidBestFitX509KeyManager should change
{code:java}
for(String alias : Collections.list(ks.aliases()))
{
if(ks.isKeyEntry(alias))
{
aliases.add(alias);
}
}
{code}
to
{code:java}
for(String alias : Collections.list(ks.aliases()))
{
if(ks.entryInstanceOf(alias, KeyStore.PrivateKeyEntry.class))
{
aliases.add(alias);
}
}
{code}
was (Author: rgodfrey):
I think it is reasonable for the FileKeyStore to validate that at least one
entry of type PrivateKeyEntry is present, and that a FileTrustStore validates
there is at least one element of type TrustedCertificateEntry. The interfaces
for KeyStore and TrustStore imply the requirement for these entry types in the
store. Additionally we should ensure that no assumptions are made that the
underlying Java KeyStore *only* contains these entry types. For instance I
think FileTrustStoreImpl createCertificates(final KeyStore ts) should change
{code:java}
while (aliases.hasMoreElements())
{
certificates.add(ts.getCertificate(aliases.nextElement()));
}
{code}
to
{code:java}
String alias = aliases.nextElement();
if(ts.isCertificateEntry(alias))
{
certificates.add(ts.getCertificate(alias));
}
{code}
and the constructor of QpidBestFitX509KeyManager should change
{code:java}
for(String alias : Collections.list(ks.aliases()))
{
if(ks.isKeyEntry(alias))
{
aliases.add(alias);
}
}
{code}
to
{code:java}
for(String alias : Collections.list(ks.aliases()))
{
if(ks.entryInstanceOf(alias, KeyStore.PrivateKeyEntry.class))
{
aliases.add(alias);
}
}
{code}
> [Broker-J] FileKeyStore should validate java keystore content to make sure
> that private key is present
> ------------------------------------------------------------------------------------------------------
>
> Key: QPID-8064
> URL: https://issues.apache.org/jira/browse/QPID-8064
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: qpid-java-6.0.8, qpid-java-broker-7.0.0, qpid-java-6.1.5
> Reporter: Alex Rudyy
> Priority: Minor
> Fix For: Future
>
>
> Currently Broker-J does not issue any error or warning when private key is
> missed in java keystore (i.e., truststore is provided instead of keystore).
> We should add a validation for the private key and deny keystore creation (or
> recovery) if private key is not present.
> When keystore without private key is configured, an attempt to make TLS
> fails, but the root cause of the failure is difficult to debug. Even when
> java debug logging is enabled (-Djavax.net.debug=all) the logs for the
> handshake failure are confusing: "fatal error: 40: no cipher suites in
> common", for example
> {noformat}
> HttpManagement-HTTP-392, READ: TLSv1 Handshake, length = 224
> *** ClientHello, TLSv1.2
> RandomCookie: GMT: -1512757423 bytes = { 141, 10, 192, 6, 218, 230, 103,
> 203, 46, 231, 80, 160, 40, 21, 47, 125, 0, 149, 138, 74, 65, 251, 5, 165,
> 194, 45, 196, 236 }
> Session ID: {}
> Cipher Suites: [Unknown 0xaa:0xaa, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, Unknown 0xcc:0xa9, Unknown 0xcc:0xa8,
> Unknown 0xcc:0x14, Unknown 0xcc:0x13, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
> TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA,
> TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
> Compression Methods: { 0 }
> Unsupported extension type_10794, data:
> Extension renegotiation_info, renegotiated_connection: <empty>
> Extension server_name, server_name: [type=host_name (0),
> value=abcd24p9390.abc.ef.g1234567.net]
> Unsupported extension type_23, data:
> Unsupported extension type_35, data:
> Extension signature_algorithms, signature_algorithms: SHA256withECDSA,
> Unknown (hash:0x8, signature:0x4), SHA256withRSA, SHA384withECDSA, Unknown
> (hash:0x8, signature:0x5), SHA384withRSA, Unknown (hash:0x8, signature:0x6),
> SHA512withRSA, SHA1withRSA
> Unsupported extension status_request, data: 01:00:00:00:00
> Unsupported extension type_18, data:
> Unsupported extension type_16, data: 00:0c:02:68:32:08:68:74:74:70:2f:31:2e:31
> Unsupported extension type_30032, data:
> Extension ec_point_formats, formats: [uncompressed]
> Extension elliptic_curves, curve names: {unknown curve 56026, unknown curve
> 29, secp256r1, secp384r1}
> Unsupported extension type_23130, data: 00
> ***
> [read] MD5 and SHA1 hashes: len = 224
> 0000: 01 00 00 DC 03 03 A6 D5 27 51 8D 0A C0 06 DA E6 ........'Q......
> 0010: 67 CB 2E E7 50 A0 28 15 2F 7D 00 95 8A 4A 41 FB g...P.(./....JA.
> 0020: 05 A5 C2 2D C4 EC 00 00 26 AA AA C0 2B C0 2F 00 ...-....&...+./.
> 0030: 9E C0 2C C0 30 CC A9 CC A8 CC 14 CC 13 C0 13 00 ..,.0...........
> 0040: 33 C0 14 00 39 00 9C 00 9D 00 2F 00 35 00 0A 01 3...9...../.5...
> 0050: 00 00 8D 2A 2A 00 00 FF 01 00 01 00 00 00 00 24 ...**..........$
> 0060: 00 22 00 00 1F 76 73 69 6E 32 34 70 39 33 39 30 ."...abcd24p9390
> 0070: 2E 73 76 72 2E 75 73 2E 6A 70 6D 63 68 61 73 65 .abc.ef.g1234567
> 0080: 2E 6E 65 74 00 17 00 00 00 23 00 00 00 0D 00 14 .net.....#......
> 0090: 00 12 04 03 08 04 04 01 05 03 08 05 05 01 08 06 ................
> 00A0: 06 01 02 01 00 05 00 05 01 00 00 00 00 00 12 00 ................
> 00B0: 00 00 10 00 0E 00 0C 02 68 32 08 68 74 74 70 2F ........h2.http/
> 00C0: 31 2E 31 75 50 00 00 00 0B 00 02 01 00 00 0A 00 1.1uP...........
> 00D0: 0A 00 08 DA DA 00 1D 00 17 00 18 5A 5A 00 01 00 ...........ZZ...
> %% Initialized: [Session-37, SSL_NULL_WITH_NULL_NULL]
> HttpManagement-HTTP-392, fatal error: 40: no cipher suites in common
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> %% Invalidated: [Session-37, SSL_NULL_WITH_NULL_NULL]
> HttpManagement-HTTP-392, SEND TLSv1.2 ALERT: fatal, description =
> handshake_failure
> HttpManagement-HTTP-392, WRITE: TLSv1.2 Alert, length = 2
> HttpManagement-HTTP-392, fatal: engine already closed. Rethrowing
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> {noformat}
> The broker should not allow keystore creation without private key or at least
> one certificate.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
