Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Corey Bonnell <[e-mail]>]

Quite some time has elapsed since the last message of this discussion was sent, and I don’t think there was any resolution to the concerns raised. If I’m understanding Ilari correctly, there are networking appliances (such as HAProxy, as described here: https://stuff-things.net/2016/11/30/haproxy-sni/)  that sniff the SNI value in the ClientHello to determine the destination TLS server but do not otherwise decrypt/re-encrypt the flow. If a hosting provider uses a frontend such as HAProxy, an attacker could register the .arpa hostname and configure a TLS server to respond to the ALPN challenge request.

I believe this can be mitigated by not including the SNI extension in the challenge ClientHello. Not including any SNI value would mean that the ALPN challenge flow would be routed in the same manner as normal TLS flows to the IP address being validated, thus eliminating any possibility of an attacker exploiting any differences in the routing/address information in the challenge flow vs. normal flows to fraudulently obtain certificates. In addition, including the ALPN extension and omitting the SNI extension means that the security issues surrounding http-01 validation via HTTPS and default virtual hosts are effectively mitigated, as the server presumably will not respond to the unknown ALPN value. As such, I believe omitting the SNI value is a reasonable mitigation.

I don’t quite understand the need for embedding the IP address being validated in the TLS ClientHello, as that information is already available in the destination IP address field of the IP header. If any packets of the challenge request are NATted before being received at the final TLS server, then implementations can transmit the IP address being validated in some implementation-specific manner that need not be explicitly defined in the specification. Nonetheless, if the IP address is deemed necessary to include in the ClientHello, it would probably be best to include it in a new TLS extension.


Thanks,

Corey

________________________________
From: Ryan Sleevi <[e-mail]>
Sent: Thursday, April 25, 2019 7:34 AM
To: Ilari Liusvaara
Cc: Corey Bonnell; Ryan Sleevi; [e-mail]
Subject: Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05



On Thu, Apr 25, 2019 at 2:27 AM Ilari Liusvaara <[e-mail]<mailto:[e-mail]>> wrote:
On Wed, Apr 24, 2019 at 01:48:24PM -0400, Ryan Sleevi wrote:
> On Wed, Apr 24, 2019 at 1:34 PM Ilari Liusvaara <[e-mail]<mailto:[e-mail]>>
> wrote:
>
> > > If that's roughly correct, would you agree a possible mitigation
> > > (notwithstanding complexity concerns) 'could' be the use of a client
> > hello
> > > extension, echo'd by the server (thus confirming it understands the
> > > protocol, and is not merely 'dumb' parsing but an active participant in
> > the
> > > TLS handshake), that indicates the IP being verified?
> >
> > The server must already acknowledge the IP address being verified.
> >
>
> I'm not sure how this conclusion is reached. Could you help me understand
> more?

The validation certificate contains the IP address being verified
in the SAN extension.

> > And that mitigation does not work. If the NAT does not know about
> > TLS-ALPN, it will not know about whatever extension that would be,
> > and thus just copy it through straight to attacker, who can then
> > freely reply.
>
>
> I'm not sure why you say this. Your original threat model was that the TLS
> SNI NAT box does something 'sensible' in the absence of SNI - and that the
> attacker would not be able to terminate the handshake if SNI were absent.
> If the proposal were to omit the SNI, while still making sure it's bound to
> the request (via a separate extension), then as long as the TLS SNI NAT box
> does the sensible thing for an SNI-less request, there's no additional
> privilege.

What are the consequences if the server just takes that address without
checking (echoing the extension, with whatever is in it)?

TLS-ALPN with domain names is pretty robust security-wise against
servers and middleboxes doing wrong (but sensible) things.

I’m still struggling to build up a cohesive threat model for your concerns. Perhaps you can try writing one up, for folks who haven’t read this thread - and this might help folks like me who have read this thread.

Where I struggle is that the threats seem to continually shift through each message, but perhaps  I’m not understanding. For example, a middlebox that blindly echoes TLS extensions means it is terminating TLS, not merely dispatching on it. The security model of TLS-ALPN is, as discussed during that process, fundamentally undermined if the server starts echoing the ALPN - which is why the ALPN draft warns against it.

I’m trying to understand what “bad but legitimate” behaviors you see, because I doubt we can, will, or should solve for “bad and violating existing TLS invariant” behaviours. We should be careful to balance how many hypotheticals here, as unless we have a concrete threat model, we’re making protocol authors do unreasonable and undocumented dances.

And in CABForum BRs, fradulent IP address certificate is quite bad, as
it allows (at least in rules) getting fradulent DNS certificates for
any domain pointing to that name (due to existence of method 8).

I think that is largely orthogonal to this discussion. There is no need for a certificate - any “technical control” over the IP is sufficient for that purpose. If we’re countenancing servers that don’t do something sensible for SNI-less requests, then that’s already an issue, since CAs also aren’t required to use TLS-ALPN.

> If the issue is that the TLS SNI NAT box is *only* secure in the context of
> DNS - and maybe it does something sensible absent an SNI, and maybe it's
> terrible and fundamentally insecure absent an SNI - then what we're saying
> is middleboxes are evil and fundamentally insecure ;)

The reason for distinction between DNS and IP here is because of the
difference in how TLS-ALPN works with DNS and IP versus how clients
works with DNS and IP.

Consider TLS-SNI. That difference in behavior renders it insecure
w.r.t. such middleboxes for both DNS and IP. Yet I do not think anybody
would blame the middleboxes for this issue, they blame TLS-SNI instead.

I’m still not confident I have a clear understanding of your concerns, and that’s concerning if only because it sounds like you believe there are critical, unaddressed security issues with the draft, and it’s unclear how to move forward or address them. It appears the concerns are shifting in the messages, but it’s entirely likely I’m missing some metapoint you’re making.

Do you have suggestions on how to address the issues you see? That might also help make it clearer.