[
https://issues.apache.org/jira/browse/KAFKA-8154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163344#comment-17163344
]
Paul Webb edited comment on KAFKA-8154 at 7/23/20, 8:52 AM:
------------------------------------------------------------
Hi. Please note that we were recently affected by this issue. I tried several
kafka clients/ brokers and JDKs. The actual cause in the end was that the java
security providers was being changed. Specifically:
{code:java}
Security.insertProviderAt(providerToAdd, 1);
{code}
By adding at position 1, it appeared that the new provider was returning an
invalid application buffer size. This may explain why this could be difficult
to reproduce.
This is some logging to show the issue:
{noformat}
2020-07-23 08:13:55.963Z INFO - Adding provider: OpenSSLProvider: Conscrypt
info: Android's OpenSSL-backed security provider
2020-07-23 08:13:55.963Z INFO - ---- SECURITY PROVIDERS -----
2020-07-23 08:13:55.965Z INFO - -> Sun: SUN info: SUN (DSA key/parameter
generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates;
JKS & DKS keystores; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP,
Collection CertStores, JavaPolicy Po
licy; JavaLoginConfig Configuration)
2020-07-23 08:13:55.965Z INFO - -> SunRsaSign: SunRsaSign info: Sun RSA
signature provider
2020-07-23 08:13:55.965Z INFO - -> SunEC: SunEC info: Sun Elliptic Curve
provider (EC, ECDSA, ECDH)
2020-07-23 08:13:55.966Z INFO - -> Provider: SunJSSE info: Sun JSSE
provider(PKCS12, SunX509/PKIX key/trust factories, SSLv3/TLSv1/TLSv1.1/TLSv1.2)
2020-07-23 08:13:55.966Z INFO - -> SunJCE: SunJCE info: SunJCE Provider
(implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, PBE,
Diffie-Hellman, HMAC)
2020-07-23 08:13:55.966Z INFO - -> SunProvider: SunJGSS info: Sun (Kerberos
v5, SPNEGO)
2020-07-23 08:13:55.966Z INFO - -> Provider: SunSASL info: Sun SASL
provider(implements client mechanisms for: DIGEST-MD5, GSSAPI, EXTERNAL, PLAIN,
CRAM-MD5, NTLM; server mechanisms for: DIGEST-MD5, GSSAPI, CRAM-MD5, NTLM)
2020-07-23 08:13:55.966Z INFO - -> XMLDSigRI: XMLDSig info: XMLDSig (DOM
XMLSignatureFactory; DOM KeyInfoFactory; C14N 1.0, C14N 1.1, Exclusive C14N,
Base64, Enveloped, XPath, XPath2, XSLT TransformServices)
2020-07-23 08:13:55.966Z INFO - -> SunPCSC: SunPCSC info: Sun PC/SC provider
2020-07-23 08:13:55.966Z INFO - -> BouncyCastleProvider: BC info:
BouncyCastle Security Provider v1.61
2020-07-23 08:13:55.966Z INFO - ---- SECURITY PROVIDERS -----{noformat}
So my hypothesis is that the new provider ( in this case from Conscrypt) is
inserted at the head of the list. When the SSLSession is called
(getApplicationBufferSize) it returns MAX_PLAINTEXT_LENGTH which is 2^14
(16384) as per [https://tools.ietf.org/html/rfc5246#section-6.2.1]
When the new provider is added to the back of the list Kafka behaved fine and
this issued disappeared completely.
Hope this helps.
was (Author: pwebb.itrs):
Hi. Please note that we were recently affected by this issue. I tried several
kafka clients/ brokers and JDKs. The actual cause in the end was that the java
security providers was being changed. Specifically:
{code:java}
Security.insertProviderAt(providerToAdd, 1);
{code}
By adding at position 1, it appeared that the new provider was returning an
invalid application buffer size. This may explain why this could be difficult
to reproduce. When the new provider is added to the back of the list Kafka
behaved fine.
Hope this helps.
> Buffer Overflow exceptions between brokers and with clients
> -----------------------------------------------------------
>
> Key: KAFKA-8154
> URL: https://issues.apache.org/jira/browse/KAFKA-8154
> Project: Kafka
> Issue Type: Bug
> Components: clients
> Affects Versions: 2.1.0
> Reporter: Rajesh Nataraja
> Priority: Major
> Attachments: server.properties.txt
>
>
> https://github.com/apache/kafka/pull/6495
> https://github.com/apache/kafka/pull/5785
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
