Can you look at the Hello in the capture to see if it is OK? On Thu, Apr 29, 2021 at 11:43 AM Jim Albert <j...@netrition.com> wrote:
> On 4/29/2021 11:11 AM, Liwei wrote: > > On Thu, 29 Apr 2021 at 22:36, Liwei <xieli...@gmail.com> wrote: > >> On Thu, 29 Apr 2021 at 21:06, Rob Emery <apache-l...@codeweavers.net> > wrote: > >> ------ 8< Snip 8< --------- > >>> Yeah we actually already have that enabled in our access logs and we > can > >>> see that the clients in question are using TLS1.2 when successful (i.e. > >>> on the next connection). However these connections that result in the > >>> plaintext response actually aren't logged in either the access or error > >>> log at all. > >> This seems to indicate something wrong in front of Apache. Likely some > >> other machine trying to respond in http mode. A misconfigured load > >> balancer perhaps? > >> > >> If you have some fancy multicast/round-robin DNS configuration, maybe > >> a misconfigured endpoint? Seems like the domain is on Route 53, so > >> that might be a possibility. > >> > >> Not as likely since you did report that a system integrator > >> experienced the same problem, but do you have any local DNS overrides > >> that might be interfering with things? > >> > >> Lih > > Doh! Ignore my previous email, the capture and your first email > > clearly stated that the response is coming from httpd, so what I said > > doesn't make sense. > > > > Looking at common code paths that lead to a 400 error, I'd imagine two > > possible scenarios: > > 1. Something is mangling the initial TLS hello, can you verify that > > the raw packet makes sense? > > 2. Worker exhaustion, given that you seem to be proxying requests, > > does this happen during particularly busy moments? > > > > There are too many variables to contend with here, especially with the > > upstream firewall potentially mangling things and the proxy and > > downstream server potentially killing a request early. > > > > You're trying to get this replicated in a lab environment, so I'd say > > that would be the best way forward in eliminating other variables. I'd > > probably try to replay the exact contents of the failing TLS hello you > > captured to quickly eliminate the possibility of upstream mangling. > > I'd also monitor or capture packets to the downstream server to see if > > there's any correlation. > > > > > > I actually thought your suggestion of a reverse proxy or load balancer > presenting a problem had merit. I still think that's a good question so > we know are we dealing with the error coming from a back end apache or > something in front of it. > > Also, does your packet trace allow you the ability to see if a firewall > is dropping packets and perhaps a misguided IPS blocking some traffic? > > Jim > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
