On 2/12/2015, at 1:38 pm, Yoav Nir <ynir.i...@gmail.com> wrote: > >> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum <ja...@appelbaum.net> wrote: >> >> >>> These are corporate >>> firewalls. When it comes to filtering HTTPS connections, firewalls have >>> three ways to classify the connection: >>> 1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses. >>> 2. #1, and additionally follow the stream looking for certain patterns. >>> 3. Full “TLS proxy”. > >>> Whether they are relevant stakeholders or not is to me the same question as >>> whether the network administrator in a corporate environment is a relevant >>> stakeholder. We just make the middlebox that they deploy. >> >> That is a kind of goal post shifting but seeminly weirdly not >> relevant, if I understand. If it won't trouble the middle box, it >> doesn't sound like the network administrator will have troubles. >> >> It will however reduce off-path reassembly to technique #1 from above >> and #2 will be partially eliminated and #3 isn't an option for that >> attacker anyway. >> >> We are working on solutions to #1, TLS 1.3 should reduce and if >> possible, eliminate #2, and #3 is something that should require >> consent of the user in question. Without consent, TLS 1.3 should hard >> fail closed as a security measure. > > A TLS proxy requires user consent (or at least device administrator consent) > with TLS 1.2. TLS 1.3 does not change that.
With SNI it’s possible to operate a transparent TLS proxy without the users consent. The proxy only has visibility of the SNI hostname - no user data (source: the company I work develops routers with such a proxy). It’s quite useful in hotspot/public wifi environments where making policy decisions based on hostname is more than sufficient, and explicit user configuration of proxy settings is a non-starter. As long as the SNI data is still available in the clear, encrypting subsequent headers won't impact the ability for our particular proxy to operate, as it’s just a generic TCP relay agent at that point. With all that being said, I think the concerns about length hiding are better addressed through other means rather than header encryption. Not sure if this is the right place to consider, but would DTLS 1.3(?) be able to encrypt headers and still handle packet loss and re-ordering? If DTLS needs cleartext headers, would it be better to advise one approach for both protocols? Regards, Mike Copley _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
