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.
[...]
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.
You are implicitly suggesting to remove perfect-forward-secrecy as soon
as a TLS flow is created by the CDN. However these packets will still be
traveling over the public Internet and/or "private" (leased, not really
private) MPLS VPNs, where we KNOW that government agencies are
eavesdropping and recording network flows to keep for years ahead. In
other words, even when the TLS flow enters "your" network, you and your
customer are still at risk from pervasive monitoring.
Thanks,
Yaron
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
