Mailing List Archive

APLN negotiation and TLS cross-protocols attack
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.

- Stefan

golang ticket: https://github.com/golang/go/issues/46310
Twitter thread: https://twitter.com/icing/status/1402943686619639818
Re: APLN negotiation and TLS cross-protocols attack [ In reply to ]
On Thu, Jun 10, 2021 at 7:28 AM Stefan Eissing
<stefan.eissing@greenbytes.de> 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.
Re: APLN negotiation and TLS cross-protocols attack [ In reply to ]
> Am 10.06.2021 um 13:33 schrieb Eric Covener <covener@gmail.com>:
>
> On Thu, Jun 10, 2021 at 7:28 AM Stefan Eissing
> <stefan.eissing@greenbytes.de> 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.