Hi Warren, Thanks a lot for your quick review and comments.
You are right, for the first web proxy scenario, the proxy could be terminating the transport layer so the client and server’s IP addresses may not be preserved. However, the TLS layer remains the same because the client always attempts to establish an end-to-end TLS session with the actual server, even if it is configured with a web proxy (after an HTTP CONNECT to the web proxy). The proxy has to rely on the fact that the client would trust the proxy’s certificate to proxy the TLS session. This is the same for a web proxy and a network middlebox like a firewall. Please let me know if I misunderstood your points. There is a scenario with CDN and TLS offloading (deployed in front of the server) where the proxy is the other “end” of TLS session. This was referred as “inbound TLS proxy" in the draft), but it seems not the case here. We will revise the text related to “preserving IP addresses”, and describe the two deployment types explicitly. Best, -Eric On Mar 4, 2020, at 3:24 PM, Eric Wang (ejwang) <[email protected]<mailto:[email protected]>> wrote: Re: [OPSEC] Request comments and discussion for draft-camwinget-tls-ns-impact Warren Kumari <[email protected]<mailto:[email protected]>> Wed, 04 March 2020 15:35 UTCShow header<https://mailarchive.ietf.org/arch/browse/opsec/#> On Tue, Mar 3, 2020 at 9:18 PM Nancy Cam-Winget (ncamwing) <[email protected]><mailto:<[email protected]>> wrote: > > Hello OPSEC participants, > > > > Given the trends to improve on security and privacy, we thought it important > to also > document how network security solutions are used and how they interact with > TLS. > > We have submitted > https://datatracker.ietf.org/doc/draft-camwinget-tls-ns-impact/ > and believe it is appropriate to discuss in this working group. Thank you for this document -- I found it to be nicely readable and understandable -- other than one major questions / point. I'm sure I'm going to mess up the terminology horribly here - apologies in advance... Section 3: " To achieve this, a TLS Proxy must be able to present a valid X.509 certificate to the TLS client to appear as a valid TLS Server; similarly, the client must be able to validate the X.509 certificate using the appropriate trust anchor for that TLS connection." I'm seen at least 2 deployment types for this sort of inspection - the first is where a client is informed that there is a proxy server that they need to send their traffic through -- i.e the system or browser is configured with a proxy server (OS X called this "Secure Web Proxy"), and is configured with something like https://proxy.example.com:8080<https://proxy.example.com:8080/>. The second is a security appliance which does MiTM type stuff, and the client installs a corporate CA certificate. These are two very very different deployment scenarios, and the "valid" part in "valid X.509 certificate" have very different meanings[0]. I think that it would be useful to clearly outline these two methods of watching "encrypted" user traffic, and clarify which one(s) you are talking about. The sentence: "This TLS Proxy is a transparent hop on the packet path; and where necessary, preserves the client's and server's original IP address and the intended source and destination TCP ports." implies only the second, but I think it would be useful to be much clearer in the introduction... W [0]: Yup, technically they are both valid, but (at least in my opinion) the second is much less so :-P > > > > Warm regards, Nancy (and my co-authors) > > _______________________________________________ > OPSEC mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/opsec -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf * [OPSEC] Request comments and discussion for draft…<https://mailarchive.ietf.org/arch/msg/opsec/GkSgkHStvNR_4lyE1Udk4gWb3Us/> Nancy Cam-Winget (ncamwing) * Re: [OPSEC] Request comments and discussion for d…<https://mailarchive.ietf.org/arch/msg/opsec/sHj-qUF1lluxVTEZYbBZL7LFZxM/> Schönwälder, Jürgen * Re: [OPSEC] Request comments and discussion for d…<https://mailarchive.ietf.org/arch/msg/opsec/6NiImtrcCoCfkZVaGKfJuQN5yUg/> Warren Kumari
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
