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 <bcall@apache.org> 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 <jp557198@gmail.com> 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!
>
>
>
>
>
>
|