You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Jeremy Payne <jp...@gmail.com> on 2017/05/03 19:23:40 UTC
Failed NPN Negotiation
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!
Re: Failed NPN Negotiation
Posted by Alan Carroll <so...@yahoo-inc.com>.
Yes, that makes sense. If it's just a a null then you'd get that particular error message.
On Friday, May 5, 2017, 3:00:49 PM CDT, Jeremy Payne <jp...@gmail.com> wrote: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 <bc...@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 <jp...@gmail.com> wrote:
ERROR: failed to find registered SSL endpoint for ''
ATS 6.1.1Built 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 productionThe error seems somewhat innocent.. I am guessing what I may find is that theseerrors 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 areacausing these errors to generate.
Thanks!
Re: Failed NPN Negotiation
Posted by Jeremy Payne <jp...@gmail.com>.
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 <bc...@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 <jp...@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!
>
>
>
>
>
>
Re: Failed NPN Negotiation
Posted by Bryan Call <bc...@apache.org>.
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 <https://github.com/apache/trafficserver/issues>
Thank you,
-Bryan
> On May 3, 2017, at 12:23 PM, Jeremy Payne <jp...@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!
>
>
>
>