This is the detail about this 16K limit:
The SSL specification requires fragmentation of data greater than 16k (2^14 = 16384 = 16k) during SSL handshake:
http://www.ietf.org/rfc/rfc2246.txt (section 6.2.1):
“The record layer fragments information blocks into TLSPlaintext
records carrying data in chunks of 2^14 bytes or less. Client message
boundaries are not preserved in the record layer (i.e., multiple
client messages of the same ContentType may be coalesced into a
single TLSPlaintext record, or a single message may be fragmented
across several records).” What this means is that if any single part of the SSL handshake (ie either party’s x509 certificate, or the server’s TrustedCAsList string, etc) is larger than 16k, fragmentation will occur at one endpoint, and the other endpoint will need to re-assemble/defragment.
Some old security lib/provider had a bug in their code that it didn’t do this fragmenting/defragmenting properly. Such system will only expect one fragment during the SSL handshake. When the returning message has more than one fragment, it will stop reading the 2nd fragment and throw EOF (end of file) error message.
if your client is using username/password authentication, you can just open a username/password only port, it won’t return the whole list of trusted CA during handshake, so you won’t have this issue.
You can also suggest your client to upgrade their system, it’s very old and outdated.