On Thu, Mar 15, 2018 at 4:53 AM, Ion Larranaga Azcue <[email protected]> wrote: > I fail to see how the current draft can be used to provide visibility to an > IPS system in order to detect bots that are inside the bank… > >
In an effort to help clear up the use case and not weighing in on the discussion... I think what Yoav is referring to by detecting BOTS within the network, is really so called advance persistent threat (APT) actors that are moving around the internal network leveraging existing access rights of compromised accounts and privilege escalation vulnerabilities. These might be detectable with 'visibility'. Patterns and behavior might be used to detect the APT use case whether or not encryption protects the stream, but it is more difficult. If an attacker was using their own server and the fingerprints were different, detection with encryption would be possible even if it is more difficult. Threat sharing groups do exchange detection techniques that involve encrypted traffic for the latter case. And I think everyone agrees, that this is not a use case the proponents are trying to cover. Best, Kathleen > > On the one hand, the bot would never opt-in for visibility if it’s trying to > exfiltrate data, so this capability would never get activated. And even if > the bot was nice enough as to opt-in for visibility, the party responsible > for providing the IPS with the required information is the server, which in > this case is under control of the attacker. There is no way the attacker’s > server will negotiate with the IPS the required keys to decrypt the channel > (most likely it can’t even communicate with it). > > > > And if you decide to close that connection because of the lack of > visibility, well… 99% of TLS servers in internet will not negotiate > visibility keys with your specific IPS, so you could as well close all TLS > traffic going outside. And you don’t need visibility for this, only a > well-configured firewall. > > > > So, maybe I’m wrong, but I think that this specific use case (analysis of > either malicious or legitimate clients’ traffic going from the enterprise > network to outside servers) is not covered by the draft under discussion > because the remote server will never negotiate the encryption keys with the > IPS. For me, the only way to provide visibility within this case is by > actively proxying every connection, something that proponents of the need > for visibility don’t seem to be comfortable with, and which in my opinion > does not require lowering the TLS protocol security level. > > > > Or maybe I misunderstood the use case altogether… > > > > > > De: TLS [mailto:[email protected]] En nombre de Yoav Nir > Enviado el: jueves, 15 de marzo de 2018 5:58 > Para: Rich Salz <[email protected]> > CC: [email protected] > Asunto: Re: [TLS] Breaking into TLS to protect customers > > > > Hi, Rich. > > > > You are conflating customers and users. The customer that may be protected > by breaking TLS in a bank’s server farm is the bank itself. An IPS system > with visibility into the traffic may detect bots that are there to steal > data or mine cryptocurrencies or whatever. > > > > If the customers of the bank are protected, it’s a happy side effect > (collateral benefit?). The object is to protect the system integrity and the > data. > > > > Yoav > > > > On 15 Mar 2018, at 5:29, Salz, Rich <[email protected]> wrote: > > > > Some on this list have said that they need to break into TLS in order to > protect customers. > > > > The thing customers seem to need the most protection is having their > personal data stolen. It seems to happen with amazing and disappointing > regularity on astounding scales. Some examples include > > · retailer Target, presumably subject to PCI-DSS rules > > · Anthem health insurance, presumably a regulated industry > > · Equifax, a financial-business organization (but apparently not > regulated) > > · Yahoo, a company created on and by and for the Internet (one would > think they know better) > > We could, of course, go on and on and on. > > > > NONE of those organizations are using TLS 1.3. > > > > So what kind of “protect the customer” requires breaking TLS? And what > benefits and increased protection will customers see? > > > > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > > > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > -- Best regards, Kathleen _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
