What I mean is that we have Many MITM solutions today and they are able to be a good source for troubleshooting/diagnostics, in limited situations or perspectives. This lack of scope, depth and detail are what drove us to install the packet collection infrastructures (debugging networks I think some are saying).
Some of the issues we have found include: * Level of detail is not sufficient. * Inherent tools are not sophisticated. * Data is difficult to share. * MITM management systems frequently do not "Play well" with overall management frameworks and other tools. * Problems take longer to resolve. * Depending upon the level of information logged on an MITM platform, the inherent processing can (and frequently does), create performance problems on the MITM and can change conditions, obfuscating the original issue. * MITMs are not usually configured to record, retain, archive or manage large amounts of diagnostic data. * A MITM platform frequently has a very limited vision of the overall session path. Or, there may be multiple MITM's involved in a session path. Which one has the best view? Which one(s) should you focus on? * AND, as you said, the more MITMs you add, the more latency and complexity you are forced to deal with. As a network diagnostic person this approach can actually make your responsibilities more difficult and less achievable. * The information collected is usually not granular enough to perform network diagnostics for those situations that require it. * One key initial piece of information in troubleshooting is to determine if the source of the problem is in: the Client, the Network or the Server. MITM's are rarely able to provide insight into this critical and time sensitive determination. * in general diagnostics are made more difficult with this approach. Multiple sessions and possibly interfaces may need to be traced and the MITM can further confuse things by acting as a router and/or a nat and/or a Load Balancer. As someone who deals with these types of additional complexities every day, I would like to see fewer MITMs rather than more. My organization uses the MITM diagnostics and management systems, and like most point solutions they are a valuable facet of our diagnostic arsenal, but because of the manifold shortcomings (some of which are listed above), they are not a central focus and are not a viable initial focal point or suitable overall point of triage. Triage may dictate the use of the MITM diagnostics, but MITM troubleshooting/diagnostics would not be an effective method on its own, for most situations/issues that exist in today's complex multi-tier applications. My job is to make things work and fix them ASAP when they don't. While I fully understand the need for effective security, I hope those on the security side would conversely understand the need to make things work, perform well, and quickly diagnose problems when they do not. I am often reminded of a colleague who states (jokingly I think) "The ultimate security is where no data flows and nothing works". I hope this is not the direction we are heading and that some form of compromise will be forthcoming between these two discrete factions with differing perspectives. -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Pawel Jakub Dawidek Sent: Saturday, September 24, 2016 2:54 AM To: tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 Hello. As a vendor of one of those MITM proxy solutions for TLS inspection I'd be grateful if you could be more specific about the "scope, depth and detail" that is not delivered by such solutions, so we can have discussion whether this is something we can address or not and if not, maybe we can come up with some alternative solutions before we give up. By doing MITM we increase latency, even if very little, that's inevitable. But can you really avoid doing MITM TLS inspection? In my opinion, no. Let me elaborate. Of course the amount of TLS traffic is growing rapidly (which is a good thing) thanks to many "contributions": - Server Name Indication extenstion, - Edward Snowden, - Free certificates (eg. Let's Encrypt), - HTTP 2.0. Because of that, every corporate network needs visibility inside TLS traffic not only incoming, but also outgoing, so they can not only debug, but also look for data leaks, malware, etc. Customers are increasingly aware of all this and it is not a question of MITM incresing latency, because it has to be done, the more important is to make it in a decrypt-once-feed-many fashion, as they have multiple solutions in place to analyze the traffic for different reasons. And when you do data leak prevention or malware detection you want to be in the middle so you can terminate the session as quickly as possible. I don't want to say that Forward Secrecy comes at no price. It makes observabilty harder (not impossible), it has higher CPU demands, it increases handshake times. This is the price we pay for a better security and in my opinion it is acceptable. W dniu 9/23/16 o 09:49, Ackermann, Michael pisze: > Without re stating the original message from the bank coalition, which > states this better than I could, the client and MITM solutions are not > practical in many situations. Also they do not provide the scope, depth or > detail that is utilized with today's solutions. > > -----Original Message----- > From: Watson Ladd [mailto:watsonbl...@gmail.com] > Sent: Friday, September 23, 2016 11:44 AM > To: Ackermann, Michael <mackerm...@bcbsm.com> > Cc: noloa...@gmail.com; tls@ietf.org > Subject: Re: [TLS] Industry Concerns about TLS 1.3 > > On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael <mackerm...@bcbsm.com> > wrote: >> I am not sure I understand what your reply means? >> >> Is it that we should create or even allow an environment to develop, where >> all providers of service cannot provide effective diagnostics and support? >> And then see the constituents of these industries collapse together. >> And only then realize we have an issue? >> I hope I am not understanding correctly. IETF is supposed to be looking >> ahead to provide better answers and circumvent predictable problems. Not >> ignoring, waiting and then reacting to negative situations that can and >> should be avoided. > > What exactly is the problem you are concerned with? As I've pointed > out previously one can still log the contents of TLS protected > connections: you do this at the client, or with an intercepting proxy. > What information does this not get you that you need on the network? > >> >> What I am saying, in relation to your "Delivering a stable product" >> comment is that over time various industries have learned what it takes to >> "Deliver a stable product". We did not want to invest millions in these >> debugging networks. But we learned the hard way, that it was necessary. >> I am not a member of the banking coalition that started this subject, nor >> of the banking industry at all, but I certainly understand their >> perspective and am concerned about the same unmanageable future they >> described. > > Do Akami, Cloudlflare and Google magically not have these problems? >> >> Thanks >> >> Mike >> >> >> >> -----Original Message----- >> From: Jeffrey Walton [mailto:noloa...@gmail.com] >> Sent: Friday, September 23, 2016 10:55 AM >> To: Ackermann, Michael <mackerm...@bcbsm.com> >> Cc: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org >> Subject: Re: [TLS] Industry Concerns about TLS 1.3 >> >> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <mackerm...@bcbsm.com> >> wrote: >>> From the perspective an Enterprise that runs these applications and has >>> invested HEAVILY in the debugging networks......... >>> >>> The reason we are debugging these networks is so that "The 5-6 order of >>> magnitude of folks using them" will have good service. If they do not, >>> they will consider competitors and/or generate a litany service calls or >>> complaints. I.E. When these "Folks" are slow or not working >>> they are just as unhappy as we are. >>> >> >> Isn't that the market operating as expected? Those who deliver a stable >> product at a competitive price are rewarded, while those who fail to deliver >> or deliver at an unreasonable cost are not? (Some hand waiving). >> >> If all providers failed to deliver or delivered an inferior product, then it >> might indicate a major course correction is needed. But I don't think that's >> the case here. >> >> Jeff >> >> >> The information contained in this communication is highly confidential and >> is intended solely for the use of the individual(s) to whom this >> communication is directed. If you are not the intended recipient, you are >> hereby notified that any viewing, copying, disclosure or distribution of >> this information is prohibited. Please notify the sender, by electronic mail >> or telephone, of any unintended receipt and delete the original message >> without making any copies. >> >> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are >> nonprofit corporations and independent licensees of the Blue Cross and Blue >> Shield Association. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > > The information contained in this communication is highly confidential and is > intended solely for the use of the individual(s) to whom this communication > is directed. If you are not the intended recipient, you are hereby notified > that any viewing, copying, disclosure or distribution of this information is > prohibited. Please notify the sender, by electronic mail or telephone, of any > unintended receipt and delete the original message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are > nonprofit corporations and independent licensees of the Blue Cross and Blue > Shield Association. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Pawel Jakub Dawidek Chief Technology Officer Wheel Systems / http://www.wheelsystems.com The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
