Re: RFR: 8217633: Configurable extensions with system properties [v2]

2021-01-26 Thread Xue-Lei Andrew Fan
On Mon, 25 Jan 2021 22:27:25 GMT, Rajan Halade  wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Update copyright years to 2021
>
> Marked as reviewed by rhalade (Reviewer).

Hi Bernd,

I agree with you that System property is not as useful to configure individual 
connections.  It is mostly used for corner cases that have interoperability or 
compatibility issues.  A general program should use APIs and the default system 
properties. 

> _Mailing list message from [Bernd Eckenfels](mailto:e...@zusammenkunft.net) 
> on [security-dev](mailto:security-dev@openjdk.java.net):_
> 
> Hello,
> 
> I wanted to mention again, that all those System property configurations are 
> good, especially to resolve the update pains, but not really useful if you 
> want to make configurations on a per-connection base. If you have to support 
> multiple partners it can be a real pain to setup a common feature set or 
> multiple instances. For this a generic feature setter for the context would 
> be really useful. Most prominent recent example is the ca-extension, which 
> only really makes sense if you also did programmatically configure a small 
> list of trusted CAs.
> 
Yes,  ca-extension is an item I was thinking of to support in JDK.

> I also think it would overall clean up the code and give a good place for 
> Javadoc all those options.
> Not to mention the default could be tied to a few new context names.
> 
Currently, the system properties are documented in the JSSE Reference Guides.  
But just as you know, it is as easy to follow.  I agree with you that it would 
be nice to have better place to have them all together.

Thank you for the review.

Regards,
Xuelei


> Gruss
> Bernd
> --
> http://bernd.eckenfels.net

-

PR: https://git.openjdk.java.net/jdk/pull/1752


Re: RFR: 8217633: Configurable extensions with system properties [v2]

2021-01-25 Thread Bernd Eckenfels
Hello,

I wanted to mention again, that all those System property configurations are 
good, especially to resolve the update pains, but not really useful if you want 
to make configurations on a per-connection base. If you have to support 
multiple partners it can be a real pain to setup a common feature set or 
multiple instances. For this a generic feature setter for the context would be 
really useful. Most prominent recent example is the ca-extension, which only 
really makes sense if you also did programmatically configure a small list of 
trusted CAs.

I also think it would overall clean up the code and give a good place for 
Javadoc all those options.
Not to mention the default could be tied to a few new context names.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: security-dev  im Auftrag von Xue-Lei 
Andrew Fan 
Gesendet: Monday, January 25, 2021 11:17:56 PM
An: security-dev@openjdk.java.net 
Betreff: Re: RFR: 8217633: Configurable extensions with system properties [v2]

> The TLS protocols are designed to tolerant unknown TLS extensions. However, 
> although it is not common, there are a few TLS implementations that cannot 
> handle unknown extensions properly. As results in unexpected interoperability 
> issue when new extensions are introduced in JDK. The interoperability impact 
> could be mitigated If applications can customize the extensions if needed.
>
> With this update, two system properties are added to configure the default 
> extensions in either client or server side of TLS connections.  Please note 
> that the impact of blocking TLS extensions is complicated.  For example, a 
> TLS connection may not be able to established if a mandatory extension is 
> blocked.  Please don't use this feature unless you clearly understand the 
> impact.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8217633
> CSR: https://bugs.openjdk.java.net/browse/JDK-8217993

Xue-Lei Andrew Fan has updated the pull request incrementally with one 
additional commit since the last revision:

  Update copyright years to 2021

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1752/files
  - new: https://git.openjdk.java.net/jdk/pull/1752/files/ad5f3330..5bd6e865

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1752=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1752=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1752.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1752/head:pull/1752

PR: https://git.openjdk.java.net/jdk/pull/1752


Re: RFR: 8217633: Configurable extensions with system properties [v2]

2021-01-25 Thread Rajan Halade
On Mon, 25 Jan 2021 22:17:56 GMT, Xue-Lei Andrew Fan  wrote:

>> The TLS protocols are designed to tolerant unknown TLS extensions. However, 
>> although it is not common, there are a few TLS implementations that cannot 
>> handle unknown extensions properly. As results in unexpected 
>> interoperability issue when new extensions are introduced in JDK. The 
>> interoperability impact could be mitigated If applications can customize the 
>> extensions if needed.
>> 
>> With this update, two system properties are added to configure the default 
>> extensions in either client or server side of TLS connections.  Please note 
>> that the impact of blocking TLS extensions is complicated.  For example, a 
>> TLS connection may not be able to established if a mandatory extension is 
>> blocked.  Please don't use this feature unless you clearly understand the 
>> impact.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8217993
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Update copyright years to 2021

Marked as reviewed by rhalade (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/1752


Re: RFR: 8217633: Configurable extensions with system properties [v2]

2021-01-25 Thread Jamil Nimeh
On Mon, 25 Jan 2021 22:17:56 GMT, Xue-Lei Andrew Fan  wrote:

>> The TLS protocols are designed to tolerant unknown TLS extensions. However, 
>> although it is not common, there are a few TLS implementations that cannot 
>> handle unknown extensions properly. As results in unexpected 
>> interoperability issue when new extensions are introduced in JDK. The 
>> interoperability impact could be mitigated If applications can customize the 
>> extensions if needed.
>> 
>> With this update, two system properties are added to configure the default 
>> extensions in either client or server side of TLS connections.  Please note 
>> that the impact of blocking TLS extensions is complicated.  For example, a 
>> TLS connection may not be able to established if a mandatory extension is 
>> blocked.  Please don't use this feature unless you clearly understand the 
>> impact.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8217993
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Update copyright years to 2021

Looks good to me.

-

Marked as reviewed by jnimeh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1752


Re: RFR: 8217633: Configurable extensions with system properties [v2]

2021-01-25 Thread Xue-Lei Andrew Fan
> The TLS protocols are designed to tolerant unknown TLS extensions. However, 
> although it is not common, there are a few TLS implementations that cannot 
> handle unknown extensions properly. As results in unexpected interoperability 
> issue when new extensions are introduced in JDK. The interoperability impact 
> could be mitigated If applications can customize the extensions if needed.
> 
> With this update, two system properties are added to configure the default 
> extensions in either client or server side of TLS connections.  Please note 
> that the impact of blocking TLS extensions is complicated.  For example, a 
> TLS connection may not be able to established if a mandatory extension is 
> blocked.  Please don't use this feature unless you clearly understand the 
> impact.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8217993

Xue-Lei Andrew Fan has updated the pull request incrementally with one 
additional commit since the last revision:

  Update copyright years to 2021

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1752/files
  - new: https://git.openjdk.java.net/jdk/pull/1752/files/ad5f3330..5bd6e865

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1752=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1752=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1752.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1752/head:pull/1752

PR: https://git.openjdk.java.net/jdk/pull/1752


Re: RFR: 8217633: Configurable extensions with system properties [v2]

2021-01-25 Thread Xue-Lei Andrew Fan
On Mon, 25 Jan 2021 21:32:18 GMT, Rajan Halade  wrote:

>> Xue-Lei Andrew Fan has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Update copyright years to 2021
>
> test/jdk/sun/security/ssl/SSLSocketImpl/BlockedExtension.java line 70:
> 
>> 68: 
>> 69: if (!shouldSuccess) {
>> 70: throw new Exception(
> 
> Suggestion:
> 
> throw new RuntimeException(

Good catches, the years should be 2021 now.  Thanks!

-

PR: https://git.openjdk.java.net/jdk/pull/1752