On 4/29/2021 11:11 AM, Liwei wrote:
> 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.
>
>
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-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|