Closed mosterdt closed 3 years ago
While reading this specification, section 8.2. states that "MITM proxies" are required to remove any extensions they do not understand.
Yes. Or, more accurately, it's required to send a ClientHello only containing things it supports. Whether it choses to base its capabilities on the original ClientHello is its business. Though, of course, there are security implications for either option and more reason why MITM proxies are a terrible idea.
Either way, if you are a MITM proxy, you are terminating TLS, which means there are two TLS handshakes and, in one of them, you are a client. When acting as a client, you cannot send things you don't understand. Otherwise the server will respond in a way that confuses you.
However, looking at RFC 8446 Section 9.3, the first section you encounter on forwarding middleboxes explicitly states the opposite: the middlebox is not allowed to change or modify any parameters in the handshake and subsequent traffic if it doesn't understand some parameter in the ClientHello:
RFC 8446 does not discuss "forwarding middleboxes" at all. That section talks about a "middlebox which forwards ClientHello parameters it does not understand". Any middlebox that does this cannot terminate TLS in the first place (i.e. not a MITM proxy) because anyone terminating TLS is limited to only sending things it understands.
Rather, this section is talking about non-terminating proxies that attempt to inspect the cleartext portions of TLS anyway. We ran into quite a lot of those in the process of deploying TLS 1.3 and most of them were broken. This text clarifies that TLS promises no continuity of syntax after the ClientHello. A non-terminating proxy gets to assume it can parse the ClientHello and nothing else.
The words "MITM proxy" could refer to the forwarding middlebox as well.
See above. If you're forwarding things you understand, you cannot terminate TLS. The section doesn't apply to what this draft refers to as "MITM proxy" at all. (Well, there are some weird things that try to selectively proxy TLS. There are quite a lot of problems with this approach, but in that case which rules apply depends on which choice the proxy made. Additionally, the proxy cannot violate the forwarding middlebox rule in the process of making the decision. This basically boils down to saying you cannot make your decision based on anything after the ClientHello because, after that point, you cannot parse anything.)
Probably we should change this draft to match RFC 8446 in terminology and replace "MITM proxies" with "TLS-terminating proxies".
Section 9.3 requires that such proxies generate their own ClientHello containing only parameters they understand.
Yeah, I think that change is a good one.
Thank you for your detailed reply. I do understand the reasons for being this strict about middlebox behaviour. I certainly don't think there is anything wrong. It's just that the terminology is somewhat confusing. After careful reading, it's indeed clear that the section on non-terminating proxies is not really relevant for ESNI, but due to the wording used in this RFC, it looks at first glance that 8.2 is referring to that section:
Section 9.3 requires that such proxies remove any extensions they do not understand
vs
A middlebox which forwards ClientHello parameters it does not understand MUST NOT process any messages beyond that ClientHello.
It's a small detail, and not really that important. But I think it would make it more clear if the wording is changed slightly. I do like "TLS-terminating proxies" as well. Thanks for the hard work!
How does https://github.com/tlswg/draft-ietf-tls-esni/pull/475 look?
Looks good to me! Thank you for taking the time to look at this.
On Thu, 15 Jul 2021, 18:29 David Benjamin, @.***> wrote:
How does #475 https://github.com/tlswg/draft-ietf-tls-esni/pull/475 look?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tlswg/draft-ietf-tls-esni/issues/474#issuecomment-880842255, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACE3QJM22SXAMILF4TG5C5TTX4EGHANCNFSM5ALCNE2Q .
Hello,
While reading this specification, section 8.2. states that "MITM proxies" are required to remove any extensions they do not understand.
However, looking at RFC 8446 Section 9.3, the first section you encounter on forwarding middleboxes explicitly states the opposite: the middlebox is not allowed to change or modify any parameters in the handshake and subsequent traffic if it doesn't understand some parameter in the ClientHello:
Reading further, we find the bullet point the warning in section 8.2 refers to:
Here, the middlebox isn't so much required to "remove any extension they do not understand", but to "generate its own ClientHello containing only parameters it understands". After carefully reading over these sections multiple times, I do get the message, but I feel like it could be better worded as not to create confusion. The words "MITM proxy" could refer to the forwarding middlebox as well. Changing the wording in, for example, the following way makes the reference more clear in my opinion:
What do you think about this?