Re: [TLS] Industry Concerns about TLS 1.3

[Watson Ladd <[e-mail]>]

On Fri, Sep 23, 2016 at 12:31 PM, BITS Security
<[e-mail]> wrote:
>> 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?
>
> For enterprises using Content Delivery Networks, the TLS session from the browser ends at the edge server in the Content Delivery Network.  The session that the enterprise sees is completely different: different IP's and ports, different TLS session, different application layer content because of caching, different network behavior (like packet drops and retransmissions).  If some infrastructure component in the data center is causing a problem, a trace on the browser side is blind to that.  An additional problem is that Microsoft does not allow logging of ephemeral keys in their browser.
>
> Likewise endpoint logging in the data center often does not provide adequate data to isolate the fault domain and/or the root cause of a problem.  Logs tell you that an event happened but not why it happened or which infrastructure component was the cause of the problem. For example, a log may indicate that a call was made that either didn't get answered or received a slow answer, but there could be ten infrastructure components between the server that made the call and the destination server that is supposed to answer.

I think you are confused about endpoints. Either these middleboxes
terminate a TLS connection or they do not. If they do, you can log the
application layer traffic at that box in and out. If they do not, then
IP level captures tell you what they are doing.  That some of these
endpoints are middleboxes from the standpoint of a higher layer of the
stack doesn't change that they are endpoints from the TLS layer's
perspective. I don't see what the barrier is.

>
> From the time a packet enters a data center, it is travelling through routers, switches, firewalls, load balancers, web servers, app servers, middleware servers, and possibly hitting a mainframe, all TLS encrypted for many enterprises.  Frequently, source and destination IP's are NAT'ed multiple times, so there is no visible relationship between the packet that enters the data center and the same call at deeper layers of the infrastructure.  Any one of these infrastructure nodes could be the cause of a problem.  The way to isolate the fault domain of a problem is to take a packet trace at each tier of the application infrastructure and look at the application layer data in a decrypted trace in order to find the transaction that is failing.

I do not want to be the person who has to figure out which SQL query
came from which HTTP request. Much easier to have the webserver tell
me (and maybe even add standard headers to permit RPC tracebacks).
Even better is it can track only those ensuing requests that
ultimately result in a failure.

>
> Large enterprises have built up robust out-of-band packet capture infrastructures in order to provide better network and application layer visibility than what logs provide.  Packet brokers and sniffers can handle 10 Gbits/sec. line rate or more of traffic, including write to disk at 20 Gbits/sec. or more.  This is needed because when IP's are NAT'ed, you have to trace everything in and out of a particular server and then decrypt in order to find the transaction of interest.  Some endpoints and/or infrastructure components have packet capture capability, but most are not robust enough to handle this kind of packet capture load in a busy production environment.

You do not need to capture every exchange, just the interesting ones.
What this sounds like is an environment where you have deployed dozens
of boxes with fast stripes on the side, with no real ability to ensure
that they are able to properly log, or administrative insight into
what black magic they might be doing, and have tried to make up with
it with dirty, labor-intensive hacks.

>
> There can be twenty or more layers to a large application, all TLS encrypted, that need to be inspected for troubleshooting, and replacing this with MITM infrastructure is not scalable.  Likewise, there can be hundreds of physical network taps feeding security monitoring tools like IDS/IPS, malware detection, and fraud monitoring.  Threats are coming not just from the Internet, but also from internal or 3rd party machines that have been compromised and then start reconnaissance from a wide variety of locations.  Large enterprises also have complex virtual environments which can be running TLS between VM's.  There is no scalable way to intercept VM to VM TLS that never leaves the virtual server.

The word scalable has a meaning. MITM scales linearly.
> --Andrew
>
>
> -----Original Message-----
> From: TLS [mailto:[e-mail]] On Behalf Of Watson Ladd
> Sent: Friday, September 23, 2016 11:44 AM
> To: Ackermann, Michael <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael <[e-mail]> 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:[e-mail]]
>> Sent: Friday, September 23, 2016 10:55 AM
>> To: Ackermann, Michael <[e-mail]>
>> Cc: BITS Security <[e-mail]>; [e-mail]
>> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>>
>> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.