On Thu, 29 Apr 2021 at 22:36, Liwei <xieliwei@xxxxxxxxx> wrote: > > On Thu, 29 Apr 2021 at 21:06, Rob Emery <apache-list@xxxxxxxxxxxxxxx> 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. Lih --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|