> 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”. >> >> >> Each of these is “heavier” in amount of resources that it consumes and in >> the amount of breakage that it might introduce than the one before it, so >> you only use a higher-numbered way if the lower-numbered way does not give >> you the results you need. Specifically for #2 which is the one we’re >> concerned about, there are very few attacks that can be detected by #2 that >> cannot be detected by #1. I asked someone who does work on these >> “protections” as we call them, and she told me that only two or three >> protections require following the stream that do not require proxying, and >> those were turned off in the default and recommended profiles. So at least >> with a Check Point firewall, mostly you would not get breakage if record >> lengths were encrypted, but someone making a client or a server cannot >> assume that all paths will be free from such inspection. Also, there are >> many firewall vendors and one is installed in most corporate environments. > > That sounds like you're saying that the vendor you represent won't > have issues and that it isn't a problem. Unless I misunderstand, > you're claiming a concern and you've just cleared up that concern. So > we can move on with Bryan's proposal?
To be clear, I don’t represent anybody. If I did, I would have to clear this mailing list message with a corporate lawyer and PR department. I don’t think Bryan’s proposal will hurt the capabilities of a Check Point firewall, and it will make life difficult for me as a developer no more than it will make life difficult for developers of OpenSSL, NSS, SChannel, or any of a dozen other TLS implementations. I don’t know about the other IDS/IPS/Firewall devices. >> So at least one vendor is listening in on this list, and I have a good hunch >> that at least Cisco, Blue Coat and several others are on this list as well. > > I'd love for Blue Coat to step up and talk about how this is similarly > not a problem or how it is a problem for their illegal surveillance > business in Syria, where they've been caught selling surveillance and > censorship gear. I suspect they won't say much but we can hope, right? I suspect that the Blue Coat people on this list do not represent their employer either. >> 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. >>> For example, do we really care what sandvine or xkeyscore or narus or >>> similar vendors think? I think the answer is no. They're still going >>> to do extremely powerful traffic analysis and the more information TLS >>> leaks, the more they will use it to degrade the security of TLS for >>> all users. It may be that they will be full, on path, attackers and >>> yes, in some cases, they can do different more powerful attacks. >>> Again, we should treat that as a negative thing and make it as hard as >>> is possible. >>> >>>> >>>> If enough middleboxes block TLS 1.3, the browsers will implement a >>>> downgrade >>>> dance. If they do that, attackers will be able to exploit the downgrade >>>> dance. I don’t think the net effect is better security. We’d be far >>>> better >>>> off writing a separate document on how to use the padding feature that >>>> is >>>> already in 1.3 to mitigate traffic analysis without actually flooding >>>> your >>>> Internet connection. Splitting records and padding a few can be more >>>> effective than masking the length bits. >>> >>> Censors are going to perform surveillance and then censor; TLS 1.3 >>> should treat surveillance as a security issue and censorship as an >>> attack. It may be that we can't stop certain kinds of on path attacks >>> but man on the side seems nearly entirely do-able. I mean aside from >>> the TCP reset issues do to layer violation concerns. At least we'll >>> have DTLS, which won't suffer from such a trivial denial of service... >>> right? >> >> Or just use IPsec (I did say I’m no that side of the building…) > > How well will IPsec deal with such an adversary? I think it is > instructive at all the ways that a protocol won't compose cleanly with > something like Tor, as well as how many distingusihers exist for > technique #2 above. It is very frustrating because yes, it would be > nice if we could just use IPsec. That is however nearly a total lost > cause with regard to surveillance and censorship issues. I once talked > to a Narus vendor who made some amazing claims about traffic analysis > on IPsec - I'll try to dig up some documents. IPsec has had a lightly-implemented TFC feature since RFC 4301. Without it a packet of IPsec is the same size as the original plaintext packet + a constant overhead rounded up to 4 bytes. So you could do as much traffic analysis on non-TFC IPsec as you could on the plaintext. Yoav _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
