From beandrew@cisco.com Tue Nov 13 15:47:49 2018 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC78130DF9 for ; Tue, 13 Nov 2018 15:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEb4d3S-hbXz for ; Tue, 13 Nov 2018 15:47:45 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D50130DF1 for ; Tue, 13 Nov 2018 15:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15598; q=dns/txt; s=iport; t=1542152865; x=1543362465; h=from:to:cc:subject:date:message-id:mime-version; bh=FX9AdCsnZfJqk+tQUtWefGGlakYY1NOLhyjUEAnv+nY=; b=hBglB+MZ3Wo1jZ5eb14t8aaCdRlRPYI5DJFFel3HjUIR8NhP4dsBeOER 0i9hshMAhwdJPEmMI1gn2ba29n30xL2EFg1sZhx/qE0LB/NbUwZanW9g0 DrfSRYBB5alVkThX18klJI2BBecr4RCr9sHffAi2qzz5Zj3l9Oe/hTIC5 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAC6Yetb/4gNJK1hAxoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVEFAQEBAQsBgQ1ILmaBAicKhFCHNot8k26FVBSBZgsBASO?= =?us-ascii?q?ESYM+IjQNDQEDAQECAQECbRwBC4VuTA4EAUciFxQSAQQOBQiDGoEdZA+qFYo?= =?us-ascii?q?lBQWLfReBQD+BEAGEU4FaAQECAYErARIBCRxBhRQCiHCFfpATVQkCgWGFFIo?= =?us-ascii?q?jIIFYhQSKF4lag06KLgIRFIEmHThkcXAVgyeGCIUUhT5BMQGLOoEfgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.56,230,1539648000"; d="scan'208,217";a="481074829" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2018 23:47:43 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id wADNlh61017819 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 13 Nov 2018 23:47:43 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 13 Nov 2018 17:47:42 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1395.000; Tue, 13 Nov 2018 17:47:42 -0600 From: "Ben Andrews (beandrew)" To: "websec@ietf.org" CC: "Darren McKinnon (darmckin)" Thread-Topic: Question regarding RFC 6797 Thread-Index: AdR6wiwG2dbwAoTgTByzf5RIQikPIg== Date: Tue, 13 Nov 2018 23:47:42 +0000 Message-ID: <879670c11a604e03b7d1f9e8ed0888d9@XCH-ALN-005.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.18.252.170] Content-Type: multipart/alternative; boundary="_000_879670c11a604e03b7d1f9e8ed0888d9XCHALN005ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: X-Mailman-Approved-At: Fri, 16 Nov 2018 23:27:30 -0800 Subject: [websec] Question regarding RFC 6797 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 00:01:37 -0000 --_000_879670c11a604e03b7d1f9e8ed0888d9XCHALN005ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To whom it may concern, I'm not sure if this is the best way to get this answer, but I'm looking fo= r some clarification as to what is the correct behavior for HSTS when you h= ave a web service on ServerA that is then proxied by ServerB, and both host= s have HSTS enabled. This question was spurred by a customer who open up a = case stating that SSLLabs was reporting that their site was reporting our H= STS implementation was invalid because it had more than one HSTS header. - The customer (and SSLLabs) reasoning comes from Section 7.1 where it stat= es that "If an STS header field is included, the HSTS Host MUST include onl= y one such header field." https://tools.ietf.org/html/rfc6797#section-7.1 * It's definitely clear that an individual HSTS Host should never add two H= STS headers to the packet. * What isn't clear to me is what happens when you have two HSTS hosts invol= ved in the connection especially since that same section specifies the foll= owing which implies that any HSTS should add an HSTS header if it is respon= ding to a secure HTTP request. "When replying to an HTTP request that was conveyed over a secure transport= , an HSTS Host SHOULD include in its response message an STS header field t= hat MUST satisfy the grammar specified above in Section 6.1". - However, when you look at both Section 8.1 and Appendix A it's defining s= pecific behaviors for when there are more than one HSTS host/header which i= nsinuates that having more than one header is not actually invalid. https://tools.ietf.org/html/rfc6797#section-8.1 "If a UA receives more than one STS header field in an HTTP response messag= e over secure transport, then the UA MUST process only the first such heade= r field." * This statement especially specifically defines the UA's behavior when it = receives more than one HSTS header is received. Was this intended simply to= avoid errors, or was the behavior described specifically to support situat= ions when you might have more than one HSTS header? https://tools.ietf.org/html/rfc6797#appendix-A "An HSTS Host may update UA notions of HSTS Policy via new HSTS header fiel= d parameter values. We chose to have UAs honor the "freshest" information = received from a server because there is the chance of a web site sending ou= t an erroneous HSTS Policy, such as a multi-year max-age value, and/or an i= ncorrect includeSubDomains directive." For example, if you have 2x HSTS Hosts involved in a connection, once sourc= e HTTP server (ServerA) on the corporate network and one proxy server (Serv= erB) for external users to reach the HTTP server. What would be the correct behavior when ServerB receives an HTTPS packet fr= om ServerA with an existing HSTS header that it is supposed to proxy to the= UA: A) ServerB should include its own HSTS header as the second header since it= was the second host to add the HSTS header to the HTTP packet. B) ServerB should include its own HSTS header as the first header since it'= s the "freshest" information. C) ServerB should update the existing HSTS header field with any updated HS= TS header parameters/directives. D) ServerB should include its own HSTS header overwriting ServerA's HSTS he= ader completely E) ServerB should forward ServerA's HSTS header without modifying the HSTS = header in any way. This question regarding the behavior of HSTS in non-transparent proxy situa= tions also brings up the question of what happens when that proxy server's = purpose is to transform an external routable domain to an internal only dom= ain. Assuming an error-free secure transport, would the UA add the domain i= t used to reach the proxy or if it's aware of the internal domain should it= add the internal domain instead since that was the original source of the = content? This specifically would be an extremely fringe situation that woul= dn't apply to most use cases. Not to mention it likely would fall outside o= f the scope of this RFC especially after reading the rationale within Secti= on 14.3 and Appendix A, but it definitely would be a situation where more g= uidance on the expected behavior with HSTS in proxy situations could be use= ful. Please let me know if you have any further comments, questions, issues, or = concerns. Kind regards, Ben Andrews Cisco TAC Business Hours: 09:30-17:30 EST M - F Tel: (919)574-6712 Email: beandrew@cisco.com Direct Manager: Chris Myers Phone: (919) 574-5319 Email: chrimyer@cisco.com CIN contact numbers are: North America +1 800 553 2447 Asia-Pacific +61 2 8448 7107 Australia +1 800 805 227 Europe +32 2 704 5555 UK +44 800 960 547 Case uploader: https://cway.cisco.com/csc/ --_000_879670c11a604e03b7d1f9e8ed0888d9XCHALN005ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To whom it may concern,

 

I’m not sure if this is the best way to get th= is answer, but I’m looking for some clarification as to what is the c= orrect behavior for HSTS when you have a web service on ServerA that is the= n proxied by ServerB, and both hosts have HSTS enabled. This question was spurred by a customer who open up a case statin= g that SSLLabs was reporting that their site was reporting our HSTS impleme= ntation was invalid because it had more than one HSTS header.

 

- The customer (and SSLLabs) reasoning comes from Se= ction 7.1 where it states that “If an STS header field is included, t= he HSTS Host MUST include only one such header field.”

https://tools.ietf.org/html/rfc6797#section-7.1

* It’s definitely clear that an individual HST= S Host should never add two HSTS headers to the packet.

* What isn’t clear to me is what happens when = you have two HSTS hosts involved in the connection especially since that sa= me section specifies the following which implies that any HSTS should add a= n HSTS header if it is responding to a secure HTTP request.

“When replying to an HTTP request that was con= veyed over a secure transport, an HSTS Host SHOULD include in its response = message an STS header field that MUST satisfy the grammar specified above i= n Section 6.1”.

 

- However, when you look at both Section 8.1 and App= endix A it’s defining specific behaviors for when there are more than= one HSTS host/header which insinuates that having more than one header is = not actually invalid.

https://tools.ietf.org/html/rfc6797#section-8.1

“If a UA receives more than one STS header fie= ld in an HTTP response message over secure transport, then the UA MUST proc= ess only the first such header field.”

* This statement especially specifically defines the= UA’s behavior when it receives more than one HSTS header is received= . Was this intended simply to avoid errors, or was the behavior described s= pecifically to support situations when you might have more than one HSTS header?

https://tools.ietf.org/html/rfc6797#appendix-A

“An HSTS Host may update UA notions of HSTS Po= licy via new HSTS header field parameter values.  We chose to have UAs= honor the "freshest" information received from a server because = there is the chance of a web site sending out an erroneous HSTS Policy, such as a multi-year max-age value, and/or an incorrect inclu= deSubDomains directive.”

 

For example, if you have 2x HSTS Hosts involved in a= connection, once source HTTP server (ServerA) on the corporate network and= one proxy server (ServerB) for external users to reach the HTTP server.

What would be the correct behavior when ServerB rece= ives an HTTPS packet from ServerA with an existing HSTS header that it is s= upposed to proxy to the UA:

A) ServerB should include its own HSTS header as the= second header since it was the second host to add the HSTS header to the H= TTP packet.

B) ServerB should include its own HSTS header as the= first header since it’s the “freshest” information.=

C) ServerB should update the existing HSTS header fi= eld with any updated HSTS header parameters/directives.

D) ServerB should include its own HSTS header overwr= iting ServerA’s HSTS header completely

E) ServerB should forward ServerA’s HSTS heade= r without modifying the HSTS header in any way.

 

This question regarding the behavior of HSTS in non-= transparent proxy situations also brings up the question of what happens wh= en that proxy server’s purpose is to transform an external routable d= omain to an internal only domain. Assuming an error-free secure transport, would the UA add the domain it used to rea= ch the proxy or if it’s aware of the internal domain should it add th= e internal domain instead since that was the original source of the content= ? This specifically would be an extremely fringe situation that wouldn’t apply to most use cases. Not to menti= on it likely would fall outside of the scope of this RFC especially after r= eading the rationale within Section 14.3 and Appendix A, but it definitely = would be a situation where more guidance on the expected behavior with HSTS in proxy situations could be useful.

 

Please let me know if you have any further comments,= questions, issues, or concerns.

 

Kind regards,

 

Ben Andrews

Cisco TAC

Business Hours: 09:30-17:30 EST M - F

Tel: (919)574-6712

Email: beandrew@cisco.com<mailto:beandrew@cisco.com>=

 

Direct Manager: Chris Myers

Phone: (919) 574-5319

Email: chrimyer@cisco.com<mailto:chrimyer@cisco.com>=

 

CIN contact numbers are:

North America +1 800 553 2447

Asia-Pacific +61 2 8448 7107

Australia +1 800 805 227

Europe +32 2 704 5555

UK +44 800 960 547

Case uploader: https://cway.cisco.com/csc/

 

--_000_879670c11a604e03b7d1f9e8ed0888d9XCHALN005ciscocom_-- From nobody Mon Nov 26 07:52:13 2018 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B629F130FBE for ; Mon, 26 Nov 2018 07:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.76 X-Spam-Level: X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=usaa.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgw8ixg_3U26 for ; Mon, 26 Nov 2018 07:52:03 -0800 (PST) Received: from prodomx102l.usaa.com (prodomx102l.usaa.com [167.24.25.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03022130F14 for ; Mon, 26 Nov 2018 07:52:02 -0800 (PST) Received: from pps.filterd (prodomx102l.usaa.com [127.0.0.1]) by prodomx102l.usaa.com (8.16.0.22/8.16.0.22) with SMTP id wAQFaSr2005212 for ; Mon, 26 Nov 2018 09:52:00 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=usaa.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=201408; bh=DD3nE9FqVkcbJt5AAMw2ViUF6MLCtI/oK4YxrWBUVEk=; b=wPwxqeWovBHFTW7tHaZthheIKVgs4cpK66aSAYYhDwb6P7rFgmvvWbAuxdA6DcW2BqWD FYyeGAe6IqYMVKr5yG58p2JMVFr1Kekp+mysqHv7TLAEQs6UTZTL9E6SbhGcJuCmQTWZ Li7JUBj4fEfbNtIjeDpvt3pOIFFmnGexOdZTyHLFjVSo8uiLHURnoZqlBfNIvZ51qADq hCxXLDmk5NMCYfpbFEzWX3F2Jcu6m45hjF3bq9bQZb7aZfOgeXDN2nh5aAo51g3GbG89 sJcobEl6GtmKqJjvmTBL6jFBcGTL9RbjiOMHyDFwh396m+BOLZbOZFaLZ5yaTASoZF48 pA== Received: from pps.reinject (localhost [127.0.0.1]) by prodomx102l.usaa.com with ESMTP id 2ny29eua64-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 26 Nov 2018 09:52:00 -0600 Received: from prodomx102l.usaa.com (prodomx102l.usaa.com [127.0.0.1]) by pps.reinject (8.16.0.20/8.16.0.20) with SMTP id wAQFlD39012239 for ; Mon, 26 Nov 2018 09:52:00 -0600 Received: from prodex01wdf.eagle.usaa.com (prodex01wdf.eagle.usaa.com [10.225.39.39]) by prodomx102l.usaa.com with ESMTP id 2ny29eua63-1; Mon, 26 Nov 2018 09:52:00 -0600 Received: from PRODEX02WDF.eagle.usaa.com (10.225.39.40) by PRODEX01WDF.eagle.usaa.com (10.225.39.39) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 26 Nov 2018 09:51:59 -0600 Received: from PRODEX02WDF.eagle.usaa.com ([10.225.39.40]) by PRODEX02WDF.eagle.usaa.com ([10.225.39.40]) with mapi id 15.00.1395.000; Mon, 26 Nov 2018 09:51:59 -0600 From: "Mehner, Carl" To: "Ben Andrews (beandrew)" , "websec@ietf.org" CC: "Darren McKinnon (darmckin)" Thread-Topic: Question regarding RFC 6797 Thread-Index: AdR6wiwG2dbwAoTgTByzf5RIQikPIgK2SsKw Date: Mon, 26 Nov 2018 15:51:59 +0000 Message-ID: <83a390bf984341c0a8e55d251f75601b@PRODEX02WDF.eagle.usaa.com> References: <879670c11a604e03b7d1f9e8ed0888d9@XCH-ALN-005.cisco.com> In-Reply-To: <879670c11a604e03b7d1f9e8ed0888d9@XCH-ALN-005.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL1VTQUEiLCJpZCI6IjdlNWFjM2Q3LWFhYzgtNGNlMC1hMTI3LWRlZjY5OWVjODc0MSIsInByb3BzIjpbeyJuIjoiQ2xhc3NpZmljYXRpb24iLCJ2YWxzIjpbeyJ2YWx1ZSI6IlB1YmxpYyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNy4yLjExLjAiLCJUcnVzdGVkTGFiZWxIYXNoIjoieWRQZk45OEUwOW53ZUd2Y25pZmdVSzNiQVRWb1RGaGJKdGZORVMzWHQxeGY5eDNBTWRVUVAzUmpoWE1uUjZsdiJ9 x-usaa-classification: Public x-ms-exchange-transport-fromentityheader: Hosted x-c2processedorg: b8bcc573-fb52-4e08-924e-ca559c360d81 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [websec] Question regarding RFC 6797 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 15:52:13 -0000 SGkgQmVuLA0KDQo+IEZyb206IHdlYnNlYyBbbWFpbHRvOndlYnNlYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQmVuIEFuZHJld3MNCj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTMs IDIwMTggNTo0OCBQTQ0KPiANCj4gLSBUaGUgY3VzdG9tZXIgKGFuZCBTU0xMYWJzKSByZWFzb25p bmcgY29tZXMgZnJvbSBTZWN0aW9uIDcuMSB3aGVyZSBpdA0KPiBzdGF0ZXMgdGhhdCDigJxJZiBh biBTVFMgaGVhZGVyIGZpZWxkIGlzIGluY2x1ZGVkLCB0aGUgSFNUUyBIb3N0IE1VU1QgaW5jbHVk ZQ0KPiBvbmx5IG9uZSBzdWNoIGhlYWRlciBmaWVsZC7igJ0NCj4gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzY3OTcjc2VjdGlvbi03LjENCj4gKiBJdOKAmXMgZGVmaW5pdGVseSBjbGVh ciB0aGF0IGFuIGluZGl2aWR1YWwgSFNUUyBIb3N0IHNob3VsZCBuZXZlciBhZGQgdHdvIEhTVFMN Cj4gaGVhZGVycyB0byB0aGUgcGFja2V0Lg0KPiAqIFdoYXQgaXNu4oCZdCBjbGVhciB0byBtZSBp cyB3aGF0IGhhcHBlbnMgd2hlbiB5b3UgaGF2ZSB0d28gSFNUUyBob3N0cw0KPiBpbnZvbHZlZCBp biB0aGUgY29ubmVjdGlvbiBlc3BlY2lhbGx5IHNpbmNlIHRoYXQgc2FtZSBzZWN0aW9uIHNwZWNp ZmllcyB0aGUNCj4gZm9sbG93aW5nIHdoaWNoIGltcGxpZXMgdGhhdCBhbnkgSFNUUyBzaG91bGQg YWRkIGFuIEhTVFMgaGVhZGVyIGlmIGl0IGlzDQo+IHJlc3BvbmRpbmcgdG8gYSBzZWN1cmUgSFRU UCByZXF1ZXN0Lg0KDQpXZWxsIHRoZSByZmMgZG9lcyBzYXkgImluY2x1ZGUiIG5vdCBhZGQuIFNv LCBldmVuIGlmIHlvdSB0cmVhdCBhIHByb3h5IGFzIGEgaG9zdCwgdGhlIHByb3h5IE1VU1Qgb25s eSBzZW5kIG9uZSBoZWFkZXIuDQoNCj4g4oCcV2hlbiByZXBseWluZyB0byBhbiBIVFRQIHJlcXVl c3QgdGhhdCB3YXMgY29udmV5ZWQgb3ZlciBhIHNlY3VyZQ0KPiB0cmFuc3BvcnQsIGFuIEhTVFMg SG9zdCBTSE9VTEQgaW5jbHVkZSBpbiBpdHMgcmVzcG9uc2UgbWVzc2FnZSBhbiBTVFMNCj4gaGVh ZGVyIGZpZWxkIHRoYXQgTVVTVCBzYXRpc2Z5IHRoZSBncmFtbWFyIHNwZWNpZmllZCBhYm92ZSBp biBTZWN0aW9uIDYuMeKAnS4NCj4gDQo+IC0gSG93ZXZlciwgd2hlbiB5b3UgbG9vayBhdCBib3Ro IFNlY3Rpb24gOC4xIGFuZCBBcHBlbmRpeCBBIGl04oCZcyBkZWZpbmluZw0KPiBzcGVjaWZpYyBi ZWhhdmlvcnMgZm9yIHdoZW4gdGhlcmUgYXJlIG1vcmUgdGhhbiBvbmUgSFNUUyBob3N0L2hlYWRl cg0KPiB3aGljaCBpbnNpbnVhdGVzIHRoYXQgaGF2aW5nIG1vcmUgdGhhbiBvbmUgaGVhZGVyIGlz IG5vdCBhY3R1YWxseSBpbnZhbGlkLg0KDQpEaXNjdXNzaW5nIGhvdyB0byBkZWFsaW5nIHdpdGgg bXVsdGlwbGUgaGVhZGVycyBkb2VzIG5vdCBtZWFuIHRoYXQgc2VuZGluZyBtdWx0aXBsZSBoZWFk ZXJzIGlzIHZhbGlkLiANCg0KPiDigJxJZiBhIFVBIHJlY2VpdmVzIG1vcmUgdGhhbiBvbmUgU1RT IGhlYWRlciBmaWVsZCBpbiBhbiBIVFRQIHJlc3BvbnNlDQo+IG1lc3NhZ2Ugb3ZlciBzZWN1cmUg dHJhbnNwb3J0LCB0aGVuIHRoZSBVQSBNVVNUIHByb2Nlc3Mgb25seSB0aGUgZmlyc3QNCj4gc3Vj aCBoZWFkZXIgZmllbGQu4oCdDQo+ICogVGhpcyBzdGF0ZW1lbnQgZXNwZWNpYWxseSBzcGVjaWZp Y2FsbHkgZGVmaW5lcyB0aGUgVUHigJlzIGJlaGF2aW9yIHdoZW4gaXQNCj4gcmVjZWl2ZXMgbW9y ZSB0aGFuIG9uZSBIU1RTIGhlYWRlciBpcyByZWNlaXZlZC4uIFdhcyB0aGlzIGludGVuZGVkIHNp bXBseQ0KPiB0byBhdm9pZCBlcnJvcnMsIG9yIHdhcyB0aGUgYmVoYXZpb3IgZGVzY3JpYmVkIHNw ZWNpZmljYWxseSB0byBzdXBwb3J0DQo+IHNpdHVhdGlvbnMgd2hlbiB5b3UgbWlnaHQgaGF2ZSBt b3JlIHRoYW4gb25lIEhTVFMgaGVhZGVyPw0KDQpUbyBhdm9pZCBlcnJvcnMgYW5kIHRvIGhhdmUg Y29uc2lzdGVuY3kgYWNyb3NzIFVBcyBvbiBkZWFsaW5nIHdpdGggbWlzY29uZmlndXJlZCBIU1RT IEhvc3RzLg0KDQo+IOKAnEFuIEhTVFMgSG9zdCBtYXkgdXBkYXRlIFVBIG5vdGlvbnMgb2YgSFNU UyBQb2xpY3kgdmlhIG5ldyBIU1RTIGhlYWRlcg0KPiBmaWVsZCBwYXJhbWV0ZXIgdmFsdWVzLsKg IFdlIGNob3NlIHRvIGhhdmUgVUFzIGhvbm9yIHRoZSAiZnJlc2hlc3QiDQo+IGluZm9ybWF0aW9u IHJlY2VpdmVkIGZyb20gYSBzZXJ2ZXIgYmVjYXVzZSB0aGVyZSBpcyB0aGUgY2hhbmNlIG9mIGEg d2ViIHNpdGUNCj4gc2VuZGluZyBvdXQgYW4gZXJyb25lb3VzIEhTVFMgUG9saWN5LCBzdWNoIGFz IGEgbXVsdGkteWVhciBtYXgtYWdlIHZhbHVlLA0KPiBhbmQvb3IgYW4gaW5jb3JyZWN0IGluY2x1 ZGVTdWJEb21haW5zIGRpcmVjdGl2ZS7igJ0NCg0KVGhpcyBpcyBhY3Jvc3MgbXVsdGlwbGUgcmVx dWVzdHMsIG5vdCB3aXRoaW4gdGhlIHNhbWUgcmVzcG9uc2UgKHNvIGl0IGRvZXNuJ3QgYXBwbHkg dG8geW91ciBleGFtcGxlIGJlbG93KS4NCg0KPiBGb3IgZXhhbXBsZSwgaWYgeW91IGhhdmUgMngg SFNUUyBIb3N0cyBpbnZvbHZlZCBpbiBhIGNvbm5lY3Rpb24sIG9uY2Ugc291cmNlDQo+IEhUVFAg c2VydmVyIChTZXJ2ZXJBKSBvbiB0aGUgY29ycG9yYXRlIG5ldHdvcmsgYW5kIG9uZSBwcm94eSBz ZXJ2ZXINCj4gKFNlcnZlckIpIGZvciBleHRlcm5hbCB1c2VycyB0byByZWFjaCB0aGUgSFRUUCBz ZXJ2ZXIuDQo+IFdoYXQgd291bGQgYmUgdGhlIGNvcnJlY3QgYmVoYXZpb3Igd2hlbiBTZXJ2ZXJC IHJlY2VpdmVzIGFuIEhUVFBTIHBhY2tldA0KPiBmcm9tIFNlcnZlckEgd2l0aCBhbiBleGlzdGlu ZyBIU1RTIGhlYWRlciB0aGF0IGl0IGlzIHN1cHBvc2VkIHRvIHByb3h5IHRvIHRoZQ0KPiBVQToN Cj4gQSkgU2VydmVyQiBzaG91bGQgaW5jbHVkZSBpdHMgb3duIEhTVFMgaGVhZGVyIGFzIHRoZSBz ZWNvbmQgaGVhZGVyIHNpbmNlIGl0DQo+IHdhcyB0aGUgc2Vjb25kIGhvc3QgdG8gYWRkIHRoZSBI U1RTIGhlYWRlciB0byB0aGUgSFRUUCBwYWNrZXQuDQo+IEIpIFNlcnZlckIgc2hvdWxkIGluY2x1 ZGUgaXRzIG93biBIU1RTIGhlYWRlciBhcyB0aGUgZmlyc3QgaGVhZGVyIHNpbmNlIGl04oCZcw0K PiB0aGUg4oCcZnJlc2hlc3TigJ0gaW5mb3JtYXRpb24uDQo+IEMpIFNlcnZlckIgc2hvdWxkIHVw ZGF0ZSB0aGUgZXhpc3RpbmcgSFNUUyBoZWFkZXIgZmllbGQgd2l0aCBhbnkgdXBkYXRlZA0KPiBI U1RTIGhlYWRlciBwYXJhbWV0ZXJzL2RpcmVjdGl2ZXMuDQo+IEQpIFNlcnZlckIgc2hvdWxkIGlu Y2x1ZGUgaXRzIG93biBIU1RTIGhlYWRlciBvdmVyd3JpdGluZyBTZXJ2ZXJB4oCZcyBIU1RTDQo+ IGhlYWRlciBjb21wbGV0ZWx5DQo+IEUpIFNlcnZlckIgc2hvdWxkIGZvcndhcmQgU2VydmVyQeKA mXMgSFNUUyBoZWFkZXIgd2l0aG91dCBtb2RpZnlpbmcgdGhlDQo+IEhTVFMgaGVhZGVyIGluIGFu eSB3YXkuDQoNCkxvZ2ljYWxseSwgdGhlIFVBIHdvdWxkIHNlZSBib3RoIHNlcnZlcnMgYXMgdGhl IHNhbWUgIkhTVFMgSG9zdCIsIHNvIEkgd291bGQgc2F5LCAiRSIuIEFsdGhvdWdoLCB5b3UgY291 bGQgZG8gJ0MnIG9yICdEJyBpZiB5b3UgY2hvc2UgdG8gb3IgaGFkIGEgbmVlZCB0byAoZS5nIGlu dGVybmFsIFVBcyBoaXR0aW5nIFNlcnZlciBBIHNob3VsZCBnZXQgb25lIGhlYWRlciwgYnV0IGV4 dGVybmFsIFVBcyBoaXR0aW5nIHByb3h5IFNlcnZlciBCIHNob3VsZCBnZXQgYW5vdGhlcikuDQpB KSB3b3VsZCBiZSB3cm9uZywgYmVjYXVzZSB0aGUgSFNUUyBIb3N0IHdvdWxkIGJlIHNlbmRpbmcg bXVsdGlwbGUgaGVhZGVycw0KQikgZG9lc24ndCBtYWtlIGEgbG90IG9mIHNlbnNlLCBiZWNhdXNl IHRoZSBkaXNjdXNzaW9uIGFib3V0ICdmcmVzaG5lc3MnIGlzIG1vcmUgYXJvdW5kIGZpeGluZyBh biBvbGQgSFNUUyBkaXJlY3RpdmUgKGUuZy4gcmVwbGFjaW5nIG9uZSBzZW50IHdlZWtzIGFnbyBm b3IgMiB5ZWFycyBtYXgtYWdlIHdpdGggb25lIHNlbnQgbm93IHdpdGggMi1tb250aHMgbWF4LWFn ZS4pIG5vdCBldmVudHMgdGhhdCBhcmUgaGFwcGVuaW5nIG1pbGxpc2Vjb25kcyBhcGFydC4NCg0K PiBUaGlzIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUgYmVoYXZpb3Igb2YgSFNUUyBpbiBub24tdHJh bnNwYXJlbnQgcHJveHkNCj4gc2l0dWF0aW9ucyBhbHNvIGJyaW5ncyB1cCB0aGUgcXVlc3Rpb24g b2Ygd2hhdCBoYXBwZW5zIHdoZW4gdGhhdCBwcm94eQ0KPiBzZXJ2ZXLigJlzIHB1cnBvc2UgaXMg dG8gdHJhbnNmb3JtIGFuIGV4dGVybmFsIHJvdXRhYmxlIGRvbWFpbiB0byBhbiBpbnRlcm5hbA0K PiBvbmx5IGRvbWFpbi4gQXNzdW1pbmcgYW4gZXJyb3ItZnJlZSBzZWN1cmUgdHJhbnNwb3J0LCB3 b3VsZCB0aGUgVUEgYWRkIHRoZQ0KPiBkb21haW4gaXQgdXNlZCB0byByZWFjaCB0aGUgcHJveHkg b3IgaWYgaXTigJlzIGF3YXJlIG9mIHRoZSBpbnRlcm5hbCBkb21haW4NCj4gc2hvdWxkIGl0IGFk ZCB0aGUgaW50ZXJuYWwgZG9tYWluIGluc3RlYWQgc2luY2UgdGhhdCB3YXMgdGhlIG9yaWdpbmFs IHNvdXJjZSBvZg0KPiB0aGUgY29udGVudD8gVGhpcyBzcGVjaWZpY2FsbHkgd291bGQgYmUgYW4g ZXh0cmVtZWx5IGZyaW5nZSBzaXR1YXRpb24gdGhhdA0KPiB3b3VsZG7igJl0IGFwcGx5IHRvIG1v c3QgdXNlIGNhc2VzLiBOb3QgdG8gbWVudGlvbiBpdCBsaWtlbHkgd291bGQgZmFsbCBvdXRzaWRl DQo+IG9mIHRoZSBzY29wZSBvZiB0aGlzIFJGQyBlc3BlY2lhbGx5IGFmdGVyIHJlYWRpbmcgdGhl IHJhdGlvbmFsZSB3aXRoaW4gU2VjdGlvbg0KPiAxNC4zIGFuZCBBcHBlbmRpeCBBLCBidXQgaXQg ZGVmaW5pdGVseSB3b3VsZCBiZSBhIHNpdHVhdGlvbiB3aGVyZSBtb3JlDQo+IGd1aWRhbmNlIG9u IHRoZSBleHBlY3RlZCBiZWhhdmlvciB3aXRoIEhTVFMgaW4gcHJveHkgc2l0dWF0aW9ucyBjb3Vs ZCBiZQ0KPiB1c2VmdWwuDQoNClRoZSBVQSB3b3VsZCBvbmx5IGFkZCB0aGUgZG9tYWluIGl0IHVz ZWQgdG8gcmVhY2ggdGhlIEhTVFMgSG9zdC4gSWYgdGhhdCBkb21haW4gaXMgdGhlIHByb3h5IHRo ZW4gaXQgd291bGQgbm90ZSB0aGF0IG9uZSwgaWYgdGhlIGRvbWFpbiBpcyB0aGUgaW50ZXJuYWwt b25seSBvbmUsIHRoZW4gaXQgd291bGQgbm90ZSB0aGUgaW50ZXJuYWwgZG9tYWluLg0KDQo+IFBs ZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbnkgZnVydGhlciBjb21tZW50cywgcXVlc3Rp b25zLCBpc3N1ZXMsIG9yDQo+IGNvbmNlcm5zLg0KPiANCj4gS2luZCByZWdhcmRzLA0KPiANCj4g QmVuIEFuZHJld3MNCj4gQ2lzY28gVEFDDQo+IEJ1c2luZXNzIEhvdXJzOiAwOTozMC0xNzozMCBF U1QgTSAtIEYNCj4gVGVsOiAoOTE5KTU3NC02NzEyDQo+IEVtYWlsOiBtYWlsdG86YmVhbmRyZXdA Y2lzY28uY29tPG1haWx0bzpiZWFuZHJld0BjaXNjby5jb20+DQo+IA0KPiBEaXJlY3QgTWFuYWdl cjogQ2hyaXMgTXllcnMNCj4gUGhvbmU6ICg5MTkpIDU3NC01MzE5DQo+IEVtYWlsOiBtYWlsdG86 Y2hyaW15ZXJAY2lzY28uY29tPG1haWx0bzpjaHJpbXllckBjaXNjby5jb20+DQo+IA0KPiBDSU4g Y29udGFjdCBudW1iZXJzIGFyZToNCj4gTm9ydGggQW1lcmljYSArMSA4MDAgNTUzIDI0NDcNCj4g QXNpYS1QYWNpZmljICs2MSAyIDg0NDggNzEwNw0KPiBBdXN0cmFsaWEgKzEgODAwIDgwNSAyMjcN Cj4gRXVyb3BlICszMiAyIDcwNCA1NTU1DQo+IFVLICs0NCA4MDAgOTYwIDU0Nw0KDQo=