>> That's not what I've seen. Instead, I see administrators creating port >> mirrors on demand and then >> filtering the traffic they are interested in using standard tcpdump rules, >> and I see MITM boxes >> that selectively decrypt some traffic to look inside it and apply some kind >> of security filtering. >> In the former case, DNS lookups and IP/port destinations are commonly used >> to trigger some suspicions too. > Correct.
Yes I realize all that. That is the “traditional” way.
My point is that if you own/control the endpoint, then it doesn’t matter from
the architecture point of view where you tap – and if TLS is not broken (i.e.,
does not allow you to “selectively decrypt”) you can tap the plaintext at the
endpoint. You just need a different set of tools. But considering how today’s
endpoints are loaded with tons and tons of “security software”, it seems rather
straightforward.
It’s not like you have an opaque endpoint, and the switch is the only place
your visibility starts.
>> That's not how the tcpdump/wireshark approach usually works. You give it the
>> private key and
>> decrypts the TLS connection as it's happening.
>
> Correct.
> Ex-post-facto is insufficient to purpose. Real-time is the focus. Archiving
> is rarely done,
> and is typically just snippets representative of the incident in question.
Yes. The contention is between being able to decrypt already-encrypted traffic
on-demand, and being able to tap the traffic before the encryption (or after
the decryption) on-demand.
Your current tools to the first. Evolvement of the technology is pushing you
towards the second. Arguing against it IMHO would have as much effect as
arguing against exporting strong crypto had decades ago. Or are you simply
trying to delay the inevitable?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
