On 12/2/15, Mike Copley <mi...@lamsap.org> wrote: > > 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).
Yes, we use that for a pluggable transport ( https://trac.torproject.org/projects/tor/wiki/doc/meek ) to bypass such proxies - connect to google.com, use http header to route to blocked.com, and so on. > 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. That is an attack in my book and public hotspots that do MITM are also a problem that we need to solve. It is partially solved with WISPr XML, I think. Though everything in this space is awful because it breaks everything by default while a system thinks it is online. > 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. I hope that we'll hide the SNI data by default and I understand that a discussion about encrypted SNI is currently scheduled for some point in the future. > 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? I'm pretty sure that encryption is the only way to "hide" the data we want to hide... All the best, Jacob _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
