Hi Rich and Eric, Thanks for the replies.
Let me add to the picture: Client <-> *Middlebox* <-> TLS terminating <-> Desired Origin Or to put it in the TLS ECH draft terminology (split mode topology) - as per my understanding - : Client <-> *Middlebox* <-> Client-facing server <-> Backend server With "Middlebox" really meaning a middlebox like a firewall or similar. >From the draft, ECH seems to be designed to still allow successful TLS connection establishment if the encrypted_client_hello extension is dropped from the ClientHello on a conforming middlebox. Provided that the middlebox is authoritative for the client-facing server's public name, as reported/delivered by DNS to the client. We can assume that this is the case here. >From Section 7: " If the "encrypted_client_hello" is not present [in the ClientHello], then the server completes the handshake normally, as described in [RFC8446]." >From Section 6.1.4: " If the message is a ServerHello, the client computes accept_confirmation as described in Section 7.2. If this value matches the last 8 bytes of ServerHello.random, the server has accepted ECH. Otherwise, it has rejected ECH." In this case, ECH will of course be deemed "rejected". >From Section 6.1.6: "If both authentication and the handshake complete successfully, the client MUST perform the processing described below then abort the connection with an "ech_required" alert before sending any application data to the server." Both authentication and the handshake should complete successfully here. Section 6.1.6 also states: " If none of the values provided in "retry_configs" contains a supported version, or an earlier TLS version was negotiated, the client can regard ECH as securely disabled by the server, and it SHOULD retry the handshake with a new transport connection and ECH disabled." This part does not make it very clear whether ECH should be regarded as being "securely disabled" when the ServerHello does not contain the encrypted_client_hello extension at all, since the paragraph in which "securely disabled" is mentioned presupposes the presence of "retry_configs". I am assuming that is the intention though - that a non-ECHed ServerHello + authenticated cert will lead to ECH being securely disabled, in turn triggering the retry mechanism. >From Section 6.1.7: "The TLS implementation MUST NOT report such connections as successful to the application." and "These connections are only used to trigger retries, as described in Section 6.1.6." It is this retry mechanism that I am after. This is something that is to be implemented on the ECH supporting client. I would like to test this functionality with such a middlebox in-line, but need a client that already supports the connection retry attempt when ECH got disabled in this way. Is my understanding above correct, and if so, does anyone know if such a client implementation is available already? I hope this is clearer. Thanks, SB On Tue, Oct 4, 2022 at 11:19 AM Salz, Rich <rs...@akamai.com> wrote: > I do not understand your question. Let me start with a picture. > > > > Client <-> TLS terminating <-> Desired Origin > > Concretely for an example: > > Browser <-> a CDN <-> origin for www.example.com > > > > The key phrase is the middle entity is a TLS terminating one. (As opposed > to a conventional firewall or similar that just forwards packets, which is > why I say “middle entity” rather than “middle box” > > > > In order to connect to the CDN, it must have a certificate for > www.example.com and DNS must have sent the browser to the CDN. If not, > the browser will fail the connection. > > > > In order to avoid confusion with their own IT structure, it is common for > the “Example, Com” entity to actually have a different name for their > origin website, call it origin.example.com > > > > So, can you rephrase your question perhaps? > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
