I see at least 6 classes of "middlebox":

1. Inline corporate device (e.g. proxy); explicitly trusted by client through 
configuration.

2. Inline lawful intercept surveillance device; the client is not aware that it 
is "trusting" the device.  (NOTE: I'm not commenting on whether this is 
ethical, just listing the options).

3. Inline surveillance device using some crypto backdoor (hopefully this is 
theoretical for TLS 1.3!).

4. Inline active MiTM attack.

5. Passive monitoring device, either inline or TAP/SPAN; authorized by client; 
"passive" in the sense that it does not modify TLS content.

6. Passive monitoring device; not authorized

Proper TLS 1.3 stack implementations would hopefully nullify classes 3 and 4.

My focus was on class 1, but class 2 will have similar capabilities.

Different mechanisms, possibly out-of-band, would be needed to hide knowledge 
of the hidden server from classes 1 and 2.  Furthermore, classes 1 and 2 will 
initially have a severe impact on the deployment of the mechanisms described in 
the draft.

I agree that both mechanisms will be effective against classes 5 and 6.  Was 
that the goal?

 

--Roelof

 

From: Christian Huitema <huit...@huitema.net>
Date: Thursday, February 22, 2018 at 1:12 PM
To: R du Toit <r@nerd.ninja>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: Comments on draft-ietf-tls-sni-encryption-01.txt

 

On 2/21/2018 3:31 PM, R du Toit wrote:

I have analyzed the two mechanisms proposed in the draft, with specific focus 
on the impact of middleboxes. 

 

Assumptions:

The middlebox is deployed inline, between the client and the fronting server, 
and is allowed to intercept TLS sessions.  The middlebox is policy-driven, and 
uses SNI as an input in determining whether or not to intercept the session; 
the policy must use the SNI of the hidden server.


We may want to be a bit more specific about middlebox assumptions, both in the 
draft and in your analysis.

The big question centers on your sentence "(the middlebox)  is allowed to 
intercept TLS sessions". Allowed by whom, and how? SNI encryption deployments, 
today, are attempting to prevent observation and interception by middleboxes 
that neither the client nor the server authorized. It is not surprising that 
SNI encryption would achieve just that, in the same way that TLS succeeds in 
hiding the content from intermediaries. If it doesn't, it's a bug.



 

Mechanism #1 : Tunnel ClientHello in 0-RTT early data.

(1) Mechanism #1 requires 0-RTT support, but the middlebox would not be 
violating the TLS 1.3 specification by not implementing 0-RTT.  The middlebox 
intercepts all sessions destined to a specific fronting server (F); the 
identity of F should be public knowledge, but even if it is not, we have to 
assume that the middlebox has a mechanism to decide when to intercept sessions 
destined to F.  


Yes, that's a weakness in the "0-RTT tunneling" mechanism. To work properly, it 
would need some kind of fallback when 0-RTT is blocked. That needs to be taken 
into account when evaluating the mechanism.



 

(2) Assume that the middlebox actually supports PSK and 0-RTT, i.e. TLS 
intercept with PSK/0-RTT support in the session between the client and the 
middlebox, as well as PSK/0-RTT support in the session between the middlebox 
and the fronting server.  The middlebox will be able to decode ClientHello#2 
sent in the 0-RTT early data because the client_early_traffic_secret will be 
known to the middlebox.  The middlebox would thus have access to the SNI of the 
hidden server, and would be able to evaluate policy.  The middlebox would have 
the option to pull out of the session after sending ClientHello#2 to the 
fronting server (re-encrypted with the client_early_traffic_secret shared 
between the middlebox and the fronting server).

 

Mechanism #2: Session ticket that can be decoded by Fronting and Hidden server.

(3) Mechanism #2 relies on PSK session resumption support in the middlebox; 
this is not guaranteed.

Actually, this is not specific to the session ticket solution. The 0-RTT 
mechanism also relies on PSK session resumption. In your previous paragraph, 
you state that "the client_early_traffic_secret will be known to the 
middlebox". But that early secret is based on the PSK in a resumption ticket 
with the fronting server. So in both cases, your middlebox only works 
transparently if it keeps track of session tickets and the corresponding 
identities and keys.



(4) The middlebox would not participate or interfere in any of the out-of-band 
channels between the fronting server and the hidden server, which implies that 
the middlebox will not be able to decode the session ticket generated by the 
hidden server - but it does not have to.  The middlebox would be able to 
observe the encoded session ticket in the NewSessionTicket message because it 
intercepts the initial TLS session between the client and the hidden server 
(even if mechanism #1 is used for the first session).  The middlebox would thus 
be able to extract the SNI of the hidden server from the NewSessionTicket 
message and build a mapping of encoded session tickets to hidden servers. TLS 
sessions (destined to the fronting server) that were not previously intercepted 
by the middlebox will use PSK identities that are not in the mapping table - 
the middlebox would likely force intercept of those sessions and strip the 
unknown PSK identities, which would result in a TLS session that terminates on 
the fronting server, leaving the fronting server without any knowledge of the 
hidden server.


Yes, that should be the fall back mode if the middlebox strips away the PSK 
identity. The client ends up with a session with the fronting server, and the 
attempt to connect to the hidden server remains secret. I agree that it should 
be documented in the draft.



 

(5) Ignoring middleboxes, in my opinion the infrastructure required for 
collaboration between fronting servers and hidden servers (stateful, 
shared-key, public-key, or otherwise) would be a practical barrier to entry for 
most server administrators.


The way to check that is to try some test deployments. We shall see.

-- Christian Huitema 


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to