ok.. so here is my best guess as to whats going on with regards to this error with the 'empty' protocol list... it looks like the 'rogue' client is possibly sending a \0 or some other 'garbage' non-printable character(s) as a protocol. this is the reason why len > 0, but the requested protocol appears to be 'empty'
On Wed, May 3, 2017 at 3:08 PM, Bryan Call <[email protected]> wrote: > I looked through our produciton logs on all our servers (a lot of servers) > and I am seeing this too once in awhile. It shouldn’t print the log unless > len > 0, but from the logs it looks like the length is 0. > > It might be helpful to also print len to see what the value is. Can you > please file an issue on this? > > Link to issues: > https://github.com/apache/trafficserver/issues > > Thank you, > > -Bryan > > On May 3, 2017, at 12:23 PM, Jeremy Payne <[email protected]> wrote: > > ERROR: failed to find registered SSL endpoint for '' > > ATS 6.1.1 > Built against RHEL-openssl 1.0.1e-fips > > > Has anyone identified any legacy/broken clients out in the wild that may > be responsible for causing these errors ? > I cant seem to generate the same error using openssl: > > openssl s_client -connect ip:port -nextprotoneg '' > > If I pass an empty list, ATS just returns a list of supported protocols > and closes the TLS connection. Which is per spec(if i read correctly). > > The request must be flawed some other way for ATS to generate this error. > I can't run debug or packet capture on these machines since they are in > production > The error seems somewhat innocent.. I am guessing what I may find is that > these > errors are caused by some broken/incomplete client/TLS implementation. I > am leaning towards > this being something amiss with early implementations of boringssl. > > However, while I am testing some older clients I am putting this out to > the community. > Maybe someone here has already identified some broken clients or > identified a general area > causing these errors to generate. > > Thanks! > > > > > >
