Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable
On 14 September 2018 at 15:22, Alan Bateman wrote: > On 14/09/2018 13:46, David Lloyd wrote: >> >> : >>> >>> There are essentially two main parts to this change: >>> >>> 1. Deprecation of System.s[etS]ecurityManager() >> >> We (JBoss) use this method to configure some things at run time (like >> customizing the Policy) before installing our security manager, so >> this would be not so great for us. > > The security manager is legacy these days and I think we need to figure out > a plan how to deprecate and eventually bury it. I have no idea how many > releases or years that might take but the proposal here is a profitable > first step. It's easy to imagine follow on steps where the default changes > to not support the security manager without some opt-in. Yes, this will be > disruptive for a number of usages but there is lots of time to look for > solutions to the issues that people are using the security manager for today > - for example we've seen several cases where people set a security manager > because they lack hooks to prevent plugins from doing things (plugins or > tests calling System.exit comes up periodically for example). As an another data point, we are using a (custom) security manager to restrict access to certain cloud environment metadata resources. -- David Black / Security Engineer.
Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable
On 14 September 2018 at 13:46, David Lloyd wrote: > On Thu, Sep 13, 2018 at 3:03 PM Sean Mullan wrote: >> >> This is a SecurityManager related change which warrants some additional >> details for its motivation. >> >> The current System.setSecurityManager() API allows a SecurityManager to >> be set at run-time. However, because of this mutability, it incurs a >> performance overhead even for applications that never call it and do not >> enable a SecurityManager dynamically, which is probably the majority of >> applications. > > What kind of performance overhead? Yes, have you done performance tests to determine what the overhead is in "standard applications" (the micro-benchmark in https://bugs.openjdk.java.net/browse/JDK-8191053 might not be reflective of actual application performance differences). > >> For example, there are lots of "SecurityManager sm = >> System.getSecurityManager(); if (sm != null) ..." checks in the JDK. If >> it was known that a SecurityManager could never be set at run-time, >> these checks could be optimized using constant-folding. > > I think they could be optimized using constant-folding either way, if > something like SwitchPoint were used instead of a plain field; am I > incorrect in my understanding? The reason I ask is... (see below) > >> There are essentially two main parts to this change: >> >> 1. Deprecation of System.s[etS]ecurityManager() > > We (JBoss) use this method to configure some things at run time (like > customizing the Policy) before installing our security manager, so > this would be not so great for us. We also use it. This is certainly an interesting change to me because there are valid use cases for 'later' enforcing / bringing up a security manager. Use cases include, being able to execute / perform operations prior to setting up a security manager (although arguably it is possible for a custom security manager to await for a signal / flag to be set to enter an "enforcing mode" or a different "initialisation" policy). I was thinking about if it would be useful to permit dynamically calling setSecurityManager once. The following quoted part is from Sean Mullan's initial email (just to avoid any confusion) -> > > 2. A new JDK-specific system property to disallow the setting of the > security manager at run-time: jdk.allowSecurityManager > > If set to false, it allows the run-time to optimize the code and improve > performance when it is known that an application will never run with a > SecurityManager. To support this behavior, the System.setSecurityManager() > API has been updated such that it can throw an UnsupportedOperationException > if it does not allow a security manager to be set dynamically. As an outsider this change, especially when considering the context of https://bugs.openjdk.java.net/browse/JDK-8200447 felt strange until I found Alan Bateman's email suggesting that the "security manager is legacy these day's". On a somewhat related note ... I have been meaning for some time to bring up the fact that it is harder than it should be for non-applet applications to make use of a security manager (this is slightly off-topic I guess ...) - for example: * cachePolicy being set to forever unless overridden (this is easy to work around) - there are arguments for and against this but the behaviour differing between when a security manager is in use and when one is not can be surprising to some. * in some breaks usages of ParallelStream because InnocuousForkJoinWorkerThread can potentially be used (this is fairly easy to workaround) (also iirc the nio version can also be problematic). -- David Black / Security Engineer.
Re: RFR 8210786 : Typo s/overriden/overridden/ in several places
This makes sense. No other comment. Thanks Max > 在 2018年9月16日，05:10，Ivan Gerasimov 写道： > > Hi Max! > > >> On 9/15/18 6:28 AM, Weijun Wang wrote: >> In the bug description you listed some in jdk/internal/org/objectweb/asm, >> but they are not included in the fix. Is it because those are not doc only >> but inside source code? > For the ASM changes, I thought it may be better to fix them in the upstream > project. > I don't know how/if the ASM sources in OpenJDK are updated. If they are not, > then it may make sense to fix these typos too. > >> There are similar typos in other modules as well. Any reason not to include >> them. > Yep, there are 200+ occurrences in other modules, mostly in java.desktop. I > think I'll create another separate issue and will assign it to someone from > the jdk client team. > >> Thanks >> Max >> >>> On Sep 15, 2018, at 2:03 PM, Ivan Gerasimov >>> wrote: >>> >>> Hello! >>> >>> This is a followup of the fix of JDK-8210785 (Trivial typo fix in >>> X509ExtendedKeyManager javadoc). >>> >>> A few more occurrences of the typo were found. >>> >>> Would you please help review? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210786 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8210786/00/webrev/ >>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >>> >> > > -- > With kind regards, > Ivan Gerasimov >
Re: RFR 8210786 : Typo s/overriden/overridden/ in several places
Hi Max! On 9/15/18 6:28 AM, Weijun Wang wrote: In the bug description you listed some in jdk/internal/org/objectweb/asm, but they are not included in the fix. Is it because those are not doc only but inside source code? For the ASM changes, I thought it may be better to fix them in the upstream project. I don't know how/if the ASM sources in OpenJDK are updated. If they are not, then it may make sense to fix these typos too. There are similar typos in other modules as well. Any reason not to include them. Yep, there are 200+ occurrences in other modules, mostly in java.desktop. I think I'll create another separate issue and will assign it to someone from the jdk client team. Thanks Max On Sep 15, 2018, at 2:03 PM, Ivan Gerasimov wrote: Hello! This is a followup of the fix of JDK-8210785 (Trivial typo fix in X509ExtendedKeyManager javadoc). A few more occurrences of the typo were found. Would you please help review? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210786 WEBREV: http://cr.openjdk.java.net/~igerasim/8210786/00/webrev/ -- With kind regards, Ivan Gerasimov -- With kind regards, Ivan Gerasimov
Re: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped
It was exported in the past .. and it was publicly documented .. http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html .. so I think Sergey was correct in his "JDK" scope. Implementation would be for something entirely internal. +1 -phil. On 9/13/18, 7:20 PM, mandy chung wrote: On 9/13/18 2:43 PM, Sergey Bylokhov wrote: Hello. Please review fix for jdk12. Bug: https://bugs.openjdk.java.net/browse/JDK-8210692 Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00 CSR: https://bugs.openjdk.java.net/browse/JDK-8210693 Thus change looks okay to me. This class is not exported and so I have updated the CSR of "Implementation" scope rather than JDK. Mandy The client code has a "com.sun.awt.SecurityWarning" class which at some point in the past, JDK 6u10, was used as a kind of "public" API. During development of jdk9 it was considered that this API is not supported and may be removed in the future: JDK-8051640. In jdk11 this class was marked as "forRemoval = true" (see JDK-8205588) and can be dropped in 12. In the fix these things were removed: - com/sun/awt/SecurityWarning.java - The test for SecurityWarning class - Test groups, because SecurityWarning is the latest class in "com/sun/awt" package - The reference to "com/sun/awt" in the "default.policy" (cc) core-libs-dev: I am not sure who is responsible to review the change in "default.policy".
Re: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped
Were people mis-reading this as java.desktop ? Yes, its fine, this was added under https://bugs.openjdk.java.net/browse/JDK-8055206 and we should have removed that when jdk.desktop was backed out under https://bugs.openjdk.java.net/browse/JDK-8173409 -phil. On 9/14/18, 11:41 AM, Sean Mullan wrote: On 9/13/18 7:52 PM, Stuart Marks wrote: I'd guess that security-dev would have reviewers for the change to default.policy. Cc'd. The default.policy file change looks like this is not specifically related to this change because the jdk.desktop module no longer exists. I guess it is ok to include it with this change but I think someone else (maybe Phil Race) should double-check that is ok. --Sean s'marks On 9/13/18 2:43 PM, Sergey Bylokhov wrote: Hello. Please review fix for jdk12. Bug: https://bugs.openjdk.java.net/browse/JDK-8210692 Webrev: http://cr.openjdk.java.net/~serb/8210692/webrev.00 CSR: https://bugs.openjdk.java.net/browse/JDK-8210693 The client code has a "com.sun.awt.SecurityWarning" class which at some point in the past, JDK 6u10, was used as a kind of "public" API. During development of jdk9 it was considered that this API is not supported and may be removed in the future: JDK-8051640. In jdk11 this class was marked as "forRemoval = true" (see JDK-8205588) and can be dropped in 12. In the fix these things were removed: - com/sun/awt/SecurityWarning.java - The test for SecurityWarning class - Test groups, because SecurityWarning is the latest class in "com/sun/awt" package - The reference to "com/sun/awt" in the "default.policy" (cc) core-libs-dev: I am not sure who is responsible to review the change in "default.policy".
Re: RFR 8210786 : Typo s/overriden/overridden/ in several places
In the bug description you listed some in jdk/internal/org/objectweb/asm, but they are not included in the fix. Is it because those are not doc only but inside source code? There are similar typos in other modules as well. Any reason not to include them. Thanks Max > On Sep 15, 2018, at 2:03 PM, Ivan Gerasimov wrote: > > Hello! > > This is a followup of the fix of JDK-8210785 (Trivial typo fix in > X509ExtendedKeyManager javadoc). > > A few more occurrences of the typo were found. > > Would you please help review? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210786 > WEBREV: http://cr.openjdk.java.net/~igerasim/8210786/00/webrev/ > > -- > With kind regards, > Ivan Gerasimov >
Re: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth
It would greatly help if you can provide the client side debug output so
we can see what's going on locally:
-Djavax.net.debug=all or System.setProperty()
Please also let us know if you are using a custom client keymanager.
It's possible that it isn't properly selecting an entity to use, in
which case an empty message will be sent.
Brad
On 9/14/2018 11:18 PM, Norman Maurer wrote:
Ok will try to find time today.
Am 15.09.2018 um 08:08 schrieb Xuelei Fan :
Hi Norman,
I have not had a chance to look into the details. But sure, it helps a lot if
you can provide a java client to reproduce the issue.
Thanks,
Xuelei
On 9/14/2018 10:29 PM, Norman Maurer wrote:
Is there any more details you need ?
Just wondering. If you say so I can also provide a pure jdk client (without the
Netty wrapper) that shows the problem when used with OpenSSL on the server in
the next days.
Bye
Norman
Am 13.09.2018 um 21:07 schrieb Norman Maurer :
Hi all,
I am currently in the process of adding TLS 1.3 support into netty-tcnative[1]
which uses JNI to make use of OpenSSL for it. During this work I noticed that I
received test-failures when mutual auth is used and the JDK implementation is
used on the client side. When using the JDK implementation on the server and
client side all works as expected. Also if I use another protocol (like
TLSv1.2) all works as expected.
The problem I am observing is that the client seems to sent the certificate
“too late” and so the server (which uses openssl) will report and error that
the client did not provide an certificate (even when it was required).
To reproduce this you can use openssl s_server like this and just create your
usual SSLSocket with a KeyManagerFactory configured.
./bin/openssl s_server -tls1_3 -cert
~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test.crt
-key
~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test_unencrypted.pem
-4 -accept localhost:8443 -state -debug -Verify 1
When now try to connect to it via the JDK TLS1.3 implementation I see the
following output:
SSL_accept:before SSL initialization
read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5))
- 16 03 03 01 60`
read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160))
- 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 ...\.."@n}..
0010 - ea 34 47 a4 fa d0 bb 92-f5 62 ec f6 21 e5 ec da .4G..b..!...
0020 - d6 6b 75 aa b9 34 20 b7-57 a6 83 7b c8 bc a2 0f .ku..4 .W..{
0030 - 52 82 11 6f a3 1a 84 c5-4b fd e0 80 58 3c 2a bf R..oK...X<*.
0040 - af 54 32 4c 7d 4f fe 00-14 c0 2c c0 2b c0 2f c0 .T2L}O,.+./.
0050 - 13 c0 14 00 9c 00 2f 00-35 13 01 13 02 01 00 00 ../.5...
0060 - ff 00 05 00 05 01 00 00-00 00 00 0a 00 20 00 1e . ..
0070 - 00 17 00 18 00 19 00 09-00 0a 00 0b 00 0c 00 0d
0080 - 00 0e 00 16 01 00 01 01-01 02 01 03 01 04 00 0b
0090 - 00 02 01 00 00 0d 00 28-00 26 04 03 05 03 06 03 ...(.&..
00a0 - 08 04 08 05 08 06 08 09-08 0a 08 0b 04 01 05 01
00b0 - 06 01 04 02 03 03 03 01-03 02 02 03 02 01 02 02
00c0 - 00 32 00 28 00 26 04 03-05 03 06 03 08 04 08 05 .2.(.&..
00d0 - 08 06 08 09 08 0a 08 0b-04 01 05 01 06 01 04 02
00e0 - 03 03 03 01 03 02 02 03-02 01 02 02 00 11 00 09
00f0 - 00 07 02 00 04 00 00 00-00 00 17 00 00 00 2b 00 ..+.
0100 - 09 08 03 04 03 03 03 02-03 01 00 2d 00 02 01 01 ...-
0110 - 00 33 00 47 00 45 00 17-00 41 04 4e da b3 f2 63 .3.G.E...A.N...c
0120 - ee 6e bf e3 af 73 be c9-92 c5 ec 70 ff c7 64 b8 .n...s.p..d.
0130 - 8a 9a cc fd f9 d6 36 ef-ce e0 dc 81 01 2f 87 57 ..6../.W
0140 - 56 f0 e4 2d 8b c8 73 14-eb 5f 21 0a 5e 94 46 ba V..-..s.._!.^.F.
0150 - de d1 33 57 4c b5 b3 66-c9 26 fb ff 01 00 01 00 ..3WL..f.&..
SSL_accept:before SSL initialization
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write change cipher spec
SSL_accept:TLSv1.3 write encrypted extensions
SSL_accept:SSLv3/TLS write certificate request
SSL_accept:SSLv3/TLS write certificate
SSL_accept:TLSv1.3 write server certificate verify
write to 0x7fe400f050c0 [0x7fe403018a00] (1430 bytes => 1430 (0x596))
- 16 03 03 00 9b 02 00 00-97 03 03 bc 7f 3b 07 ad .;..
0010 - fb 21 9c 6f 7c 4a 9d 84-9a 82 6e 9c 1a b4 e3 5d .!.o|Jn]
0020 - a8 d3 9d 52 a7 e1 93 c3-cc 8c 82 20 b7 57 a6 83 ...R... .W..
0030 - 7b c8 bc a2 0f 52 82 11-6f a3 1a 84 c5 4b fd e0 {R..oK..
0040 - 80 58 3c 2a bf af 54 32-4c 7d 4f fe 13 01 00 00 .X<*..T2L}O.
0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 O.+.3.E...A.
0060 - 7d 81 11 ab ff a6 60 e7-5f 23 82 ed 22 35 76 24 }.`._#.."5v$
0070 - b0 47 09 25 0c 79 b9 07-5b 3e 28 b7 3c d8 d3 ce .G.%.y..[>(.<...
0080 -
Re: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth
Ok will try to find time today.
> Am 15.09.2018 um 08:08 schrieb Xuelei Fan :
>
> Hi Norman,
>
> I have not had a chance to look into the details. But sure, it helps a lot
> if you can provide a java client to reproduce the issue.
>
> Thanks,
> Xuelei
>
>> On 9/14/2018 10:29 PM, Norman Maurer wrote:
>> Is there any more details you need ?
>> Just wondering. If you say so I can also provide a pure jdk client (without
>> the Netty wrapper) that shows the problem when used with OpenSSL on the
>> server in the next days.
>> Bye
>> Norman
>>> Am 13.09.2018 um 21:07 schrieb Norman Maurer :
>>>
>>> Hi all,
>>>
>>> I am currently in the process of adding TLS 1.3 support into
>>> netty-tcnative[1] which uses JNI to make use of OpenSSL for it. During this
>>> work I noticed that I received test-failures when mutual auth is used and
>>> the JDK implementation is used on the client side. When using the JDK
>>> implementation on the server and client side all works as expected. Also if
>>> I use another protocol (like TLSv1.2) all works as expected.
>>>
>>> The problem I am observing is that the client seems to sent the certificate
>>> “too late” and so the server (which uses openssl) will report and error
>>> that the client did not provide an certificate (even when it was required).
>>>
>>> To reproduce this you can use openssl s_server like this and just create
>>> your usual SSLSocket with a KeyManagerFactory configured.
>>>
>>> ./bin/openssl s_server -tls1_3 -cert
>>> ~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test.crt
>>> -key
>>> ~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test_unencrypted.pem
>>> -4 -accept localhost:8443 -state -debug -Verify 1
>>>
>>> When now try to connect to it via the JDK TLS1.3 implementation I see the
>>> following output:
>>> SSL_accept:before SSL initialization
>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5))
>>> - 16 03 03 01 60`
>>> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160))
>>> - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 ...\.."@n}..
>>> 0010 - ea 34 47 a4 fa d0 bb 92-f5 62 ec f6 21 e5 ec da .4G..b..!...
>>> 0020 - d6 6b 75 aa b9 34 20 b7-57 a6 83 7b c8 bc a2 0f .ku..4 .W..{
>>> 0030 - 52 82 11 6f a3 1a 84 c5-4b fd e0 80 58 3c 2a bf R..oK...X<*.
>>> 0040 - af 54 32 4c 7d 4f fe 00-14 c0 2c c0 2b c0 2f c0 .T2L}O,.+./.
>>> 0050 - 13 c0 14 00 9c 00 2f 00-35 13 01 13 02 01 00 00 ../.5...
>>> 0060 - ff 00 05 00 05 01 00 00-00 00 00 0a 00 20 00 1e . ..
>>> 0070 - 00 17 00 18 00 19 00 09-00 0a 00 0b 00 0c 00 0d
>>> 0080 - 00 0e 00 16 01 00 01 01-01 02 01 03 01 04 00 0b
>>> 0090 - 00 02 01 00 00 0d 00 28-00 26 04 03 05 03 06 03 ...(.&..
>>> 00a0 - 08 04 08 05 08 06 08 09-08 0a 08 0b 04 01 05 01
>>> 00b0 - 06 01 04 02 03 03 03 01-03 02 02 03 02 01 02 02
>>> 00c0 - 00 32 00 28 00 26 04 03-05 03 06 03 08 04 08 05 .2.(.&..
>>> 00d0 - 08 06 08 09 08 0a 08 0b-04 01 05 01 06 01 04 02
>>> 00e0 - 03 03 03 01 03 02 02 03-02 01 02 02 00 11 00 09
>>> 00f0 - 00 07 02 00 04 00 00 00-00 00 17 00 00 00 2b 00 ..+.
>>> 0100 - 09 08 03 04 03 03 03 02-03 01 00 2d 00 02 01 01 ...-
>>> 0110 - 00 33 00 47 00 45 00 17-00 41 04 4e da b3 f2 63 .3.G.E...A.N...c
>>> 0120 - ee 6e bf e3 af 73 be c9-92 c5 ec 70 ff c7 64 b8 .n...s.p..d.
>>> 0130 - 8a 9a cc fd f9 d6 36 ef-ce e0 dc 81 01 2f 87 57 ..6../.W
>>> 0140 - 56 f0 e4 2d 8b c8 73 14-eb 5f 21 0a 5e 94 46 ba V..-..s.._!.^.F.
>>> 0150 - de d1 33 57 4c b5 b3 66-c9 26 fb ff 01 00 01 00 ..3WL..f.&..
>>> SSL_accept:before SSL initialization
>>> SSL_accept:SSLv3/TLS read client hello
>>> SSL_accept:SSLv3/TLS write server hello
>>> SSL_accept:SSLv3/TLS write change cipher spec
>>> SSL_accept:TLSv1.3 write encrypted extensions
>>> SSL_accept:SSLv3/TLS write certificate request
>>> SSL_accept:SSLv3/TLS write certificate
>>> SSL_accept:TLSv1.3 write server certificate verify
>>> write to 0x7fe400f050c0 [0x7fe403018a00] (1430 bytes => 1430 (0x596))
>>> - 16 03 03 00 9b 02 00 00-97 03 03 bc 7f 3b 07 ad .;..
>>> 0010 - fb 21 9c 6f 7c 4a 9d 84-9a 82 6e 9c 1a b4 e3 5d .!.o|Jn]
>>> 0020 - a8 d3 9d 52 a7 e1 93 c3-cc 8c 82 20 b7 57 a6 83 ...R... .W..
>>> 0030 - 7b c8 bc a2 0f 52 82 11-6f a3 1a 84 c5 4b fd e0 {R..oK..
>>> 0040 - 80 58 3c 2a bf af 54 32-4c 7d 4f fe 13 01 00 00 .X<*..T2L}O.
>>> 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 O.+.3.E...A.
>>> 0060 - 7d 81 11 ab ff a6 60 e7-5f 23 82 ed 22 35 76 24 }.`._#.."5v$
>>> 0070 - b0 47 09 25 0c 79 b9 07-5b 3e 28 b7 3c d8 d3 ce .G.%.y..[>(.<...
>>> 0080 - 6b 89 c6 01 21 28 c9 97-ae 50 a5 e7 43 35 ae c7 k...!(...P..C5..
>>> 0090 - 73
Re: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth
Hi Norman,
I have not had a chance to look into the details. But sure, it helps a
lot if you can provide a java client to reproduce the issue.
Thanks,
Xuelei
On 9/14/2018 10:29 PM, Norman Maurer wrote:
Is there any more details you need ?
Just wondering. If you say so I can also provide a pure jdk client (without the
Netty wrapper) that shows the problem when used with OpenSSL on the server in
the next days.
Bye
Norman
Am 13.09.2018 um 21:07 schrieb Norman Maurer :
Hi all,
I am currently in the process of adding TLS 1.3 support into netty-tcnative[1]
which uses JNI to make use of OpenSSL for it. During this work I noticed that I
received test-failures when mutual auth is used and the JDK implementation is
used on the client side. When using the JDK implementation on the server and
client side all works as expected. Also if I use another protocol (like
TLSv1.2) all works as expected.
The problem I am observing is that the client seems to sent the certificate
“too late” and so the server (which uses openssl) will report and error that
the client did not provide an certificate (even when it was required).
To reproduce this you can use openssl s_server like this and just create your
usual SSLSocket with a KeyManagerFactory configured.
./bin/openssl s_server -tls1_3 -cert
~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test.crt
-key
~/Documents/workspace/netty/handler/src/test/resources/io/netty/handler/ssl/test_unencrypted.pem
-4 -accept localhost:8443 -state -debug -Verify 1
When now try to connect to it via the JDK TLS1.3 implementation I see the
following output:
SSL_accept:before SSL initialization
read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5))
- 16 03 03 01 60`
read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160))
- 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 ...\.."@n}..
0010 - ea 34 47 a4 fa d0 bb 92-f5 62 ec f6 21 e5 ec da .4G..b..!...
0020 - d6 6b 75 aa b9 34 20 b7-57 a6 83 7b c8 bc a2 0f .ku..4 .W..{
0030 - 52 82 11 6f a3 1a 84 c5-4b fd e0 80 58 3c 2a bf R..oK...X<*.
0040 - af 54 32 4c 7d 4f fe 00-14 c0 2c c0 2b c0 2f c0 .T2L}O,.+./.
0050 - 13 c0 14 00 9c 00 2f 00-35 13 01 13 02 01 00 00 ../.5...
0060 - ff 00 05 00 05 01 00 00-00 00 00 0a 00 20 00 1e . ..
0070 - 00 17 00 18 00 19 00 09-00 0a 00 0b 00 0c 00 0d
0080 - 00 0e 00 16 01 00 01 01-01 02 01 03 01 04 00 0b
0090 - 00 02 01 00 00 0d 00 28-00 26 04 03 05 03 06 03 ...(.&..
00a0 - 08 04 08 05 08 06 08 09-08 0a 08 0b 04 01 05 01
00b0 - 06 01 04 02 03 03 03 01-03 02 02 03 02 01 02 02
00c0 - 00 32 00 28 00 26 04 03-05 03 06 03 08 04 08 05 .2.(.&..
00d0 - 08 06 08 09 08 0a 08 0b-04 01 05 01 06 01 04 02
00e0 - 03 03 03 01 03 02 02 03-02 01 02 02 00 11 00 09
00f0 - 00 07 02 00 04 00 00 00-00 00 17 00 00 00 2b 00 ..+.
0100 - 09 08 03 04 03 03 03 02-03 01 00 2d 00 02 01 01 ...-
0110 - 00 33 00 47 00 45 00 17-00 41 04 4e da b3 f2 63 .3.G.E...A.N...c
0120 - ee 6e bf e3 af 73 be c9-92 c5 ec 70 ff c7 64 b8 .n...s.p..d.
0130 - 8a 9a cc fd f9 d6 36 ef-ce e0 dc 81 01 2f 87 57 ..6../.W
0140 - 56 f0 e4 2d 8b c8 73 14-eb 5f 21 0a 5e 94 46 ba V..-..s.._!.^.F.
0150 - de d1 33 57 4c b5 b3 66-c9 26 fb ff 01 00 01 00 ..3WL..f.&..
SSL_accept:before SSL initialization
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write change cipher spec
SSL_accept:TLSv1.3 write encrypted extensions
SSL_accept:SSLv3/TLS write certificate request
SSL_accept:SSLv3/TLS write certificate
SSL_accept:TLSv1.3 write server certificate verify
write to 0x7fe400f050c0 [0x7fe403018a00] (1430 bytes => 1430 (0x596))
- 16 03 03 00 9b 02 00 00-97 03 03 bc 7f 3b 07 ad .;..
0010 - fb 21 9c 6f 7c 4a 9d 84-9a 82 6e 9c 1a b4 e3 5d .!.o|Jn]
0020 - a8 d3 9d 52 a7 e1 93 c3-cc 8c 82 20 b7 57 a6 83 ...R... .W..
0030 - 7b c8 bc a2 0f 52 82 11-6f a3 1a 84 c5 4b fd e0 {R..oK..
0040 - 80 58 3c 2a bf af 54 32-4c 7d 4f fe 13 01 00 00 .X<*..T2L}O.
0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 O.+.3.E...A.
0060 - 7d 81 11 ab ff a6 60 e7-5f 23 82 ed 22 35 76 24 }.`._#.."5v$
0070 - b0 47 09 25 0c 79 b9 07-5b 3e 28 b7 3c d8 d3 ce .G.%.y..[>(.<...
0080 - 6b 89 c6 01 21 28 c9 97-ae 50 a5 e7 43 35 ae c7 k...!(...P..C5..
0090 - 73 10 60 62 57 25 9b c9-f1 93 28 70 03 44 e1 a0 s.`bW%(p.D..
00a0 - 14 03 03 00 01 01 17 03-03 00 27 0f 8b fb 2d 33 ..'...-3
00b0 - 72 c6 a8 28 0b 7d e1 c3-b7 d0 f3 d9 18 5b ca e0 r..(.}...[..
00c0 - 56 09 74 48 ba 28 16 1c-15 11 d9 fa 6e b3 bc b9 V.tH.(..n...
00d0 - 4d 54 17 03 03 00 42 35-53 5b 9a 8e 09 df 86 c4 MTB5S[..
00e0 - 00 28 05 6d a8 c9 bb 38-e2 77
RFR 8210786 : Typo s/overriden/overridden/ in several places
Hello! This is a followup of the fix of JDK-8210785 (Trivial typo fix in X509ExtendedKeyManager javadoc). A few more occurrences of the typo were found. Would you please help review? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210786 WEBREV: http://cr.openjdk.java.net/~igerasim/8210786/00/webrev/ -- With kind regards, Ivan Gerasimov
