As written, the document provides a basic/general description of MITM proxies.
It mentions some of the issues (client auth, handling of 0-RTT application
data, single point of failure, updates/patches, risks of disclosure of
PII/PHI), but does not really provide alternatives or specific solutions. I
oppose adoption of this document in its current shape.
Some specific issues:
* The document does not describe alternatives to MITM proxies.
* Section 4.1.2 “Inbound provisioning” does not discuss security and
operational issues around server key sharing with the proxy. No real discussion
of short-lived creds and “keyless” scenarios.
* Section 4.2 “Maintain security posture and limit modifications” seems to
recommend modifications to the ClientHello, rather than having the proxy
generate a new ClientHello. Proxies sending ClientHellos they did not generate
are a common cause of interop issues.
* Section 4.2 also explicitly allows completely insecure configurations:
“TLS proxy stacks MAY provide user configurable options, such as an
option to accept self-signed server certificates, an option to let
the handshake continue with expired but otherwise valid server
certificates, etc.”
Cheers,
Andrei
From: TLS <[email protected]> On Behalf Of Nick Harper
Sent: Monday, July 27, 2020 7:12 AM
To: Ben Schwartz <[email protected]>
Cc: Jen Linkova <[email protected]>; Nancy Cam-Winget (ncamwing)
<[email protected]>; OpSec Chairs <[email protected]>;
OPSEC <[email protected]>; [email protected]
Subject: [EXTERNAL] Re: [TLS] [OPSEC] Call For Adoption:
draft-wang-opsec-tls-proxy-bp
As currently written, this draft has multiple problems.
Section 4 decides not to repeat the Protocol Invariants described in section
9.3 of RFC 8446. However, further sections are written assuming that a proxy
acts in a way contrary to those Protocol Invariants. One such example is
section 4.2 in this draft. It describes how a proxy might generate its list of
cipher suites by modifying the client's list. A proxy that copies the cipher
suites from the client-initiated ClientHello into its own ClientHello is
violating the 1st and 3rd points of the TLS 1.3 Protocol Invariants. For a best
practices document, I think it would be reasonable to reiterate the Protocol
Invariants.
In addition to reiterating the Protocol Invariants, it should also summarize
the advice from the cited papers SECURITY_IMPACT and APPLIANCE_ANALYSIS. One of
the problems pointed out by those papers is that TLS proxies will make
connections to a server that presents a certificate the client wouldn't accept,
but because of the proxy, the client isn't aware of the certificate issues. I
don't see this issue addressed at all in the draft. (A similar issue with the
server selecting a weak cipher suite is possibly implied by section 4.2, but it
is not spelled out well.)
If this draft is adopted, it needs to say the following things, which it
currently doesn't.
- When a TLS proxy generates its ClientHello, it should be created
independently from the client-initiated ClientHello. The proxy MAY choose to
omit fields from its ClientHello based on the client-initiated ClientHello, but
it MUST NOT add fields to its ClientHello based on the client-initiated
ClientHello. This is effectively a restatement of the 1st (a client MUST
support all parameters it sends) and 3rd (it MUST generate its own ClientHello
containing only parameters it understands) points of the TLS 1.3 Protocol
Invariants.
- If a proxy chooses to conditionally proxy TLS connections and needs more
information than what is contained in the client-initiated ClientHello, then
the only way to make that decision is to send its own ClientHello to the server
the client is connecting to and use information observed on that connection to
make the decision to proxy the pending connection.
- If a proxy chooses to not proxy some TLS connections, the proxy will fail
open. The only way to avoid failing open is to proxy all connections.
On Mon, Jul 27, 2020 at 6:31 AM Ben Schwartz
<[email protected]<mailto:[email protected]>> wrote:
I'm concerned about this work happening outside the TLS working group. For
example, the question of proper handling of TLS extensions is not addressed at
all in this draft, and has significant security and functionality implications.
There are various other tricky protocol issues (e.g. version negotiation, TLS
1.3 record padding, TLS 1.3 0-RTT vs. TLS 1.2 False Start, round-trip deadlock
when buffers fill, ticket (non-)reuse, client certificate linkability
pre-TLS-1.3, implications of SAN scope of synthesized certificates) that could
arise and are going to be difficult to get right in any other WG.
The title "TLS Proxy Best Practice" implies that it is possible to proxy TLS
correctly, and that this document is the main source for how to do it. I think
the TLS WG is the right place to make those judgments.. For the OpSec group, I
think a more appropriate draft would be something like "TLS Interception
Pitfalls", documenting the operational experience on failure modes of TLS
interception.
On Mon, Jul 27, 2020 at 8:57 AM Nancy Cam-Winget (ncamwing)
<[email protected]<mailto:[email protected]>> wrote:
The document is not imposing any standards but rather provide guidelines for
those implementing TLS proxies; given that proxies will continue to exist I'm
not sure why there is a belief that the IETF should ignore this.
Warm regards, Nancy
On 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 0553 - MITLL"
<[email protected]<mailto:[email protected]> on behalf of
[email protected]<mailto:[email protected]>> wrote:
I support Stephen and oppose adoption. IMHO, this is not a technology that
IETF should standardize.
On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell"
<[email protected]<mailto:[email protected]> on behalf of
[email protected]<mailto:[email protected]>> wrote:
I oppose adoption. While there could be some minor benefit
in documenting the uses and abuses seen when mitm'ing tls,
I doubt that the effort to ensure a balanced document is at
all worthwhile. The current draft is too far from what it'd
need to be to be adopted.
Send to ISE.
S.
On 23/07/2020 02:30, Jen Linkova wrote:
> One thing to add here: the chairs would like to hear active and
> explicit support of the adoption. So please speak up if you believe
> the draft is useful and the WG shall work on getting it published.
>
> On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
>
<[email protected]<mailto:[email protected]>>
wrote:
>>
>> Folks,
>>
>>
>>
>> This email begins a Call For Adoption on
draft-wang-opsec-tls-proxy-bp.
>>
>>
>>
>> Please send comments to [email protected]<mailto:[email protected]> by
August 3, 2020.
>>
>>
>>
>> Ron
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> _______________________________________________
>> OPSEC mailing list
>> [email protected]<mailto:[email protected]>
>>
https://www.ietf.org/mailman/listinfo/opsec<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsec&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C23d5e7f8ac1047d98fe108d8323724a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637314559736707680&sdata=P0RE3llePUKRCp8og1EVm7G45N1UujWmY6aTOTRBGUE%3D&reserved=0>
>
>
>
> --
> SY, Jen Linkova aka Furry
>
> _______________________________________________
> TLS mailing list
> [email protected]<mailto:[email protected]>
>
https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C23d5e7f8ac1047d98fe108d8323724a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637314559736712671&sdata=vmUnm3RlE4rBBLF6oLlh%2B%2FzReeorfWNrbczvyVV7cXI%3D&reserved=0>
>
_______________________________________________
TLS mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C23d5e7f8ac1047d98fe108d8323724a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637314559736717662&sdata=2rDSL3aK31w3fXWvrqAmE5frKSTbaABPNls9H2ZFABU%3D&reserved=0>
_______________________________________________
TLS mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C23d5e7f8ac1047d98fe108d8323724a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637314559736722653&sdata=%2BzrWj9rV6e4ewc%2BZJxS4PPFgZRcoi%2FB0sdAQKMPNfLw%3D&reserved=0>
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
