> Am 10.06.2021 um 13:33 schrieb Eric Covener <[email protected]>:
>
> On Thu, Jun 10, 2021 at 7:28 AM Stefan Eissing
> <[email protected]> wrote:
>>
>> In short: there is the possibility of a middle-man tricking a client into
>> accepting the response from another TLS server, if it uses the same
>> certificate. This seems to be in the open, so we can talk about it here.
>>
>> People think about how to prevent this and enforce stricter ALPN
>> negotiation. But it is hairy since ALPN has been deployed for over 5 years.
>> Breakage may ensue.
>>
>> Our server is also 'relaxed' about this. If you look at
>> ssl_engine_kernel.c#2760, if no protocol overlap was found, we continue the
>> handshake as if no ALPN was supplied at all.
>>
>> I guess we can always add a "SSLStrictALPN on", but let's see where this
>> discussion goes.
>
> Strict HTTP parsing goes a long way too. Hard to respond in an
> exploitable way to a misdirected client who is speaking a different
> protocol.
Yes. However if your SMTP server uses the same TLS cert as your https: server,
you can feed our error pages to a SMTP client as well, as I understand it.
