davidben
commented
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.
mosterdt
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?