From mstjohns at comcast.net Sat Sep 1 18:03:45 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Sat, 1 Sep 2018 14:03:45 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> Message-ID: On 8/23/2018 1:50 PM, Adam Petcher wrote: > It will only support a subset of the API that is supported by the > implementation in SunEC. In particular, it will reject any private > keys with scalar values specified using BigInteger (as in > ECPrivateKeySpec), and its private keys will not return scalar values > as BigInteger (as in ECPrivateKey.getS()). Um... why??? EC Private keys are integers.... I've said this multiple times and - with the single exception of EDDSA keys because of a very idiosyncratic (and IMHO short-sighted) RFC specification - all of the EC private keys of whatever curve can be expressed as integers. Mike From mstjohns at comcast.net Sat Sep 1 18:18:11 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Sat, 1 Sep 2018 14:18:11 -0400 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> Message-ID: Hi Valerie - I may be speaking only for myself, but there are probably a number of folk using sun.security.pkcs11.wrapper.* in lieu of the PKCS11 provider for a number of reasons including an ability to manage the key storage and wrapping efficiently.?? Looking at this I'm thinking there will be a large number of things breaking because of the way you refactored things. While I understand that none of the sun.security.* classes are "public" - these were mostly taken directly from the IAIK contribution way back when and the folks I worked with used them in lieu of external libraries to have a consistent PKCS11 interface java-to-java. Perhaps instead you'd consider doing something like leaving the Java to Native public methods intact? Mike On 8/31/2018 7:53 PM, Valerie Peng wrote: > > Hi Martin, > > With the new model of "creating the key handle as needed", I think we > should not allow the direct access of keyID field outside of P11Key > class. This field should be made private and accessed through methods. > In addition, existing PKCS11.C_XXX() methods with P11 keyID arguments > can be made private and we can add wrapper methods with P11Key object > argument to ensure proper usage of the P11Key object and its keyID field. > > I have also refactored the keyID management code into a separate > holder class. The prototype code can be found at: > http://cr.openjdk.java.net/~valeriep/6913047Exp/webrev.00/ > > The main changes that I made are in P11Key.java and PKCS11.java. The > other java classes are updated to call the wrapper methods in PKCS11.java. > > Thanks & have a great Labor day weekend, > > Valerie > > > On 8/16/2018 5:28 PM, Valerie Peng wrote: >> >> Hi Martin, >> >> >> Since there is no regression test for this test, you will need to add >> a "noreg-xxx" label to the bug record. For this issue, it'll probably >> be "noreg-hard". >> >> To understand the changes better, please find my questions and some >> review comments below: >> >> >> - line 397: It's incorrect to change initialize() to >> ensureInitialized(). If the cipher object were to be initialized >> twice with two different keys, you need to re-initialize again. >> - line 471: Why do you change it to Throwable from PKCS11Exception? >> >> >> - line 99: comment is somewhat unclear. typo: "temporal" should be >> "temporary". >> - line 148-149: JDK-8165996 has been fixed. This does not apply now, >> does it? >> - You changed the constructors of all the P11Key-related classes to >> take an additional boolean argument "tmpNativeKey". However, this >> boolean argument is only used when the underlying token is "NSS". Why >> limiting to NSS only? It seems that all callers except for PKCS11 >> KeyStore pass true for "tmpNativeKey". When "tmpNativeKey" is true, >> the keyID handle first destroyed in constructor and later created >> again (ref count == 1) and destroyed (when ref count drops to 0). >> This replaced the PhantomReference approach in SessionKeyRef class, >> right? Now both approaches seem to be used and key destruction is >> taking places at different methods. I think we should clarify the >> cleanup model and perhaps refactor the code so it's easier which >> approach is in use. Or grouping all these cleanup-related >> fields/variables into a separate class for readability/clarity. >> - line 157-175: nativeKeyWrapperKeyID is a static variable, shouldn't >> it be synchronized on a class level object? >> - line 1343: the impl doesn't look right. Why do you call both >> removeObject() and addObject() here with the same check? >> - line 1363: the change seems incorrect, you should still call >> session.removeObject(). the call setKeyIDAndSession(0, null) does not >> lower the session object count. >> >> Thanks, >> Valerie >> >> On 8/7/2018 5:41 PM, Valerie Peng wrote: >>> >>> Hi Martin, >>> >>> Thanks for the update, I will resume the review on this one with >>> your latest webrev. >>> >>> BTW, there is no webrev.07 for your other fix, i.e. JDK-8029661, >>> right? Just checking. >>> >>> Regards, >>> Valerie >>> >>> On 8/3/2018 2:13 PM, Martin Balao wrote: >>>> Hi Valerie, >>>> >>>> ?* >>>> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10/ >>>> >>>> ?* >>>> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10.zip >>>> >>>> >>>> New in webrev 10: >>>> >>>> ?* Bug fix when private DSA/EC keys are sensitive >>>> ? * I found this bug removing "attributes = compatibility" entry in >>>> NSS configuration file so keys were CKA_SENSITIVE. >>>> ? * This is really an NSS bug when unwrapping ephemeral keys >>>> (NSC_UnwrapKey function), because CKA_NETSCAPE_DB attribute is >>>> required but not used/needed. There was a similar bug when creating >>>> objects (NSC_CreateObject function), fixed many years ago [1]. >>>> ? * In those cases in which the bug occurs (private keys, of DSA/EC >>>> type, sensitive and without CKA_NETSCAPE_DB attribute set), I store >>>> an empty CKA_NETSCAPE_DB attribute in the buffer that will later be >>>> used for key unwrapping. I'm not doing a C_SetAttributeValue call >>>> because keys are read-only. We can let users set CKA_NETSCAPE_DB >>>> attribute in NSS configuration file [2] but this would be a >>>> workaround on users side. >>>> ? * Changes in: >>>> ? ?* p11_keymgmt.c >>>> ? ? * L175-187, L212-214 and L275-278 >>>> >>>> ?* Bug fix when storing sensitive RSA keys in a keystore >>>> ? * CKA_NETSCAPE_DB attribute is not needed so we return it as null >>>> (instead of failing with an "Invalid algorithm" message) >>>> ? * Changes in: >>>> ? ?* P11KeyStore.java >>>> ? ? * L1909-1914 >>>> >>>> ?* Lines length was cut to improve code readability >>>> >>>> Regression tests on jdk/sun/security/pkcs11 category passed. I ran >>>> my internal test suite too, that covers the following services >>>> (with SunPKCS11 provider): Cipher, Signature, KeyAgreement, Digest, >>>> Mac, KeyGenerator, KeyPairGenerator and Keystore. >>>> >>>> Kind regards, >>>> Martin.- >>>> >>>> -- >>>> [1] - https://bugzilla.mozilla.org/show_bug.cgi?id=309701#c6 >>>> >>>> [2] - >>>> https://alvinalexander.com/java/jwarehouse/openjdk-8/jdk/test/sun/security/pkcs11/fips/fips.cfg.shtml >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Mon Sep 3 14:19:40 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 3 Sep 2018 14:19:40 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com> <34b096660ca44a4cb3f674198cd51d35@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <647A92CD-85A6-4785-9E02-F41FDDBDB5DB@oracle.com> <0B89D420-B95D-4C6B-9C54-B7A0BFAE83B1@oracle.com> Message-ID: <38f2e1d2cbe24387bf693ac55492cf68@sap.com> Hi Max, I - moved getErrorPosition method to Manifest.java - in read() method, removed "int offset" - in the exception message, I write now " manifest of " ... (without mentioning a manifest name) http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/ Best regards, Matthias > -----Original Message----- > From: Weijun Wang > Sent: Freitag, 31. August 2018 15:53 > To: Baesken, Matthias > Cc: Alan Bateman ; Sean Mullan > ; Chris Hegarty ; > security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > > > > On Aug 31, 2018, at 8:52 PM, Baesken, Matthias > wrote: > > > > Hi Max : > > > >> > >> - No need to "import java.security.Security". > > > > Sure I can remove this, it is a leftover. > > > >> - In the updated read() method, I think there is no need to use an "int > offset" > >> parameter. "int lineNumber" is enough and you can modify it and return it > >> without a new local variable. > >> > > > > Currently we need it in Manifest.java public void read(InputStream is) > throws IOException { ... } > > I was talking about the name of the parameter. You can simply use > > int read(Manifest.FastInputStream is, byte[] lbuf, String filename, int > lineNumber) > > and there is no need to reassign it with "int lineNumber = offset" anymore. > > > > >> In fact, I have a small concern on the hardcoded file name here, because > >> when verifying a signed jar, the META-INF/X.SF file is also parsed into a > >> Manifest object and if it's invalid similar exceptions will be thrown. I don't > >> have a nice solution now. > > > > Then lets just say : (e.g. test.jar:10 ) > > > > Or ( to mention that it is about a manifest from the jar ) > > > > :manifest-line (e.g. test.jar:manifest-line 10 ) > > How about you pass in the full name ("/path/to/file.jar!META- > INF/MANIFEST.MF") to "new Manifest(stream,name)" directly? > > So the name will be constructed in JarFile.java (after checking for > jarPathInExceptionText). The getErrorPosition method simply concat the > name (if not null) and the line number. Thus the exception thrown from > parsing X.SF simply will not include any file info. If we want it we can enhance > later. > > Thanks > Max > > > > > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: Weijun Wang > >> Sent: Freitag, 31. August 2018 04:32 > >> To: Baesken, Matthias > >> Cc: Alan Bateman ; Sean Mullan > >> ; Chris Hegarty ; > >> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > >> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > >> parsing of jar archives > >> > >> Some more comments: > >> > >> Attributes.java > >> > >> - No need to "import java.security.Security". > >> > >> - In the updated read() method, I think there is no need to use an "int > offset" > >> parameter. "int lineNumber" is enough and you can modify it and return it > >> without a new local variable. > >> > >> - I feel like calling Attributes::getErrorPosition from Manifest a little > strange. > >> Maybe it's better to define the method in Manifest and call it from > >> Attributes. First, I think putting the method in a higher level object makes > >> more sense. Second, the position is for the whole Manifest and not an > >> Attributes section (I mean the line number is counted from the first line of > >> the manifest). > >> > >>> On Aug 30, 2018, at 10:50 PM, Baesken, Matthias > >> wrote: > >>> > >>> > >>> > >>> Hi Max, probably we should add the info about the MANIFEST.MF , > for > >> example : > >>> change getErrorPosition to > >>> > >>> > >> > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.7/src/java.base/s > >> hare/classes/java/util/jar/Attributes.java.udiff.html > >>> > >>> > >>> static String getErrorPosition(String filename, final int lineNumber) { > >>> if (filename == null || !jarPathInExceptionText) { > >>> return "META-INF/MANIFEST.MF line:" + lineNumber; > >>> } > >>> > >>> final File file = new File(filename); > >>> return AccessController.doPrivileged(new PrivilegedAction() > { > >>> public String run() { > >>> return file.getAbsolutePath() + "!META-INF/MANIFEST.MF line:" > + > >> lineNumber; > >> > >> I prefer "file:line" which is more compact and more commonly used. > >> > >> In fact, I have a small concern on the hardcoded file name here, because > >> when verifying a signed jar, the META-INF/X.SF file is also parsed into a > >> Manifest object and if it's invalid similar exceptions will be thrown. I don't > >> have a nice solution now. if we want to show the .SF name also, we will > need > >> a public API because SignatureFileVerifier.java is inside sun.security.util. > >> Something like Manifest(InputStream,jarName,entryName)? > >> > >> Sorry for making this complicated. > >> > >> Thanks > >> Max > >> > >>> } > >>> ..... > >>> > >>> > >>> Best regards, Matthias > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Weijun Wang > >>>> Sent: Donnerstag, 30. August 2018 16:04 > >>>> To: Baesken, Matthias > >>>> Cc: Alan Bateman ; Sean Mullan > >>>> ; Chris Hegarty > ; > >>>> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > >>>> Subject: Re: [RFR] 8205525 : Improve exception messages during > manifest > >>>> parsing of jar archives > >>>> > >>>> > >>>> > >>>>> On Aug 30, 2018, at 8:26 PM, Baesken, Matthias > >>>> wrote: > >>>>> > >>>>>> - What will the output look like? Is it "/tmp/x.jar:100"? > >>>>>> > >>>>> > >>>>> Yes it look like this : > >>>>> > >>>>> line too long (/testdata/jars/file_with_long_line_1.jar:2) > >>>> > >>>> Is this a little misleading? I think you mean > >>>> > >>>> /testdata/jars/file_with_long_line_1.jar!META-INF/MANIFEST.MF:2 > >>>> > >>>> Thanks > >>>> Max > > From weijun.wang at oracle.com Mon Sep 3 15:13:52 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 3 Sep 2018 23:13:52 +0800 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <38f2e1d2cbe24387bf693ac55492cf68@sap.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com> <34b096660ca44a4cb3f674198cd51d35@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <647A92CD-85A6-4785-9E02-F41FDDBDB5DB@oracle.com> <0B89D420-B95D-4C6B-9C54-B7A0BFAE83B1@oracle.com> <38f2e1d2cbe24387bf693ac55492cf68@sap.com> Message-ID: Hi Matthias The change looks fine. We can enhance the name if we want to support .SF parsing later. Please revise your CSR and get it approved first. Thanks Max > On Sep 3, 2018, at 10:19 PM, Baesken, Matthias wrote: > > Hi Max, I > > - moved getErrorPosition method to Manifest.java > - in read() method, removed "int offset" > - in the exception message, I write now " manifest of " ... (without mentioning a manifest name) > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/ > > > Best regards, Matthias > > >> -----Original Message----- >> From: Weijun Wang >> Sent: Freitag, 31. August 2018 15:53 >> To: Baesken, Matthias >> Cc: Alan Bateman ; Sean Mullan >> ; Chris Hegarty ; >> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest >> parsing of jar archives >> >> >> >>> On Aug 31, 2018, at 8:52 PM, Baesken, Matthias >> wrote: >>> >>> Hi Max : >>> >>>> >>>> - No need to "import java.security.Security". >>> >>> Sure I can remove this, it is a leftover. >>> >>>> - In the updated read() method, I think there is no need to use an "int >> offset" >>>> parameter. "int lineNumber" is enough and you can modify it and return it >>>> without a new local variable. >>>> >>> >>> Currently we need it in Manifest.java public void read(InputStream is) >> throws IOException { ... } >> >> I was talking about the name of the parameter. You can simply use >> >> int read(Manifest.FastInputStream is, byte[] lbuf, String filename, int >> lineNumber) >> >> and there is no need to reassign it with "int lineNumber = offset" anymore. >> >>> >>>> In fact, I have a small concern on the hardcoded file name here, because >>>> when verifying a signed jar, the META-INF/X.SF file is also parsed into a >>>> Manifest object and if it's invalid similar exceptions will be thrown. I don't >>>> have a nice solution now. >>> >>> Then lets just say : (e.g. test.jar:10 ) >>> >>> Or ( to mention that it is about a manifest from the jar ) >>> >>> :manifest-line (e.g. test.jar:manifest-line 10 ) >> >> How about you pass in the full name ("/path/to/file.jar!META- >> INF/MANIFEST.MF") to "new Manifest(stream,name)" directly? >> >> So the name will be constructed in JarFile.java (after checking for >> jarPathInExceptionText). The getErrorPosition method simply concat the >> name (if not null) and the line number. Thus the exception thrown from >> parsing X.SF simply will not include any file info. If we want it we can enhance >> later. >> >> Thanks >> Max >> >>> >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: Weijun Wang >>>> Sent: Freitag, 31. August 2018 04:32 >>>> To: Baesken, Matthias >>>> Cc: Alan Bateman ; Sean Mullan >>>> ; Chris Hegarty ; >>>> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >>>> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest >>>> parsing of jar archives >>>> >>>> Some more comments: >>>> >>>> Attributes.java >>>> >>>> - No need to "import java.security.Security". >>>> >>>> - In the updated read() method, I think there is no need to use an "int >> offset" >>>> parameter. "int lineNumber" is enough and you can modify it and return it >>>> without a new local variable. >>>> >>>> - I feel like calling Attributes::getErrorPosition from Manifest a little >> strange. >>>> Maybe it's better to define the method in Manifest and call it from >>>> Attributes. First, I think putting the method in a higher level object makes >>>> more sense. Second, the position is for the whole Manifest and not an >>>> Attributes section (I mean the line number is counted from the first line of >>>> the manifest). >>>> >>>>> On Aug 30, 2018, at 10:50 PM, Baesken, Matthias >>>> wrote: >>>>> >>>>> >>>>> >>>>> Hi Max, probably we should add the info about the MANIFEST.MF , >> for >>>> example : >>>>> change getErrorPosition to >>>>> >>>>> >>>> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.7/src/java.base/s >>>> hare/classes/java/util/jar/Attributes.java.udiff.html >>>>> >>>>> >>>>> static String getErrorPosition(String filename, final int lineNumber) { >>>>> if (filename == null || !jarPathInExceptionText) { >>>>> return "META-INF/MANIFEST.MF line:" + lineNumber; >>>>> } >>>>> >>>>> final File file = new File(filename); >>>>> return AccessController.doPrivileged(new PrivilegedAction() >> { >>>>> public String run() { >>>>> return file.getAbsolutePath() + "!META-INF/MANIFEST.MF line:" >> + >>>> lineNumber; >>>> >>>> I prefer "file:line" which is more compact and more commonly used. >>>> >>>> In fact, I have a small concern on the hardcoded file name here, because >>>> when verifying a signed jar, the META-INF/X.SF file is also parsed into a >>>> Manifest object and if it's invalid similar exceptions will be thrown. I don't >>>> have a nice solution now. if we want to show the .SF name also, we will >> need >>>> a public API because SignatureFileVerifier.java is inside sun.security.util. >>>> Something like Manifest(InputStream,jarName,entryName)? >>>> >>>> Sorry for making this complicated. >>>> >>>> Thanks >>>> Max >>>> >>>>> } >>>>> ..... >>>>> >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Weijun Wang >>>>>> Sent: Donnerstag, 30. August 2018 16:04 >>>>>> To: Baesken, Matthias >>>>>> Cc: Alan Bateman ; Sean Mullan >>>>>> ; Chris Hegarty >> ; >>>>>> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >>>>>> Subject: Re: [RFR] 8205525 : Improve exception messages during >> manifest >>>>>> parsing of jar archives >>>>>> >>>>>> >>>>>> >>>>>>> On Aug 30, 2018, at 8:26 PM, Baesken, Matthias >>>>>> wrote: >>>>>>> >>>>>>>> - What will the output look like? Is it "/tmp/x.jar:100"? >>>>>>>> >>>>>>> >>>>>>> Yes it look like this : >>>>>>> >>>>>>> line too long (/testdata/jars/file_with_long_line_1.jar:2) >>>>>> >>>>>> Is this a little misleading? I think you mean >>>>>> >>>>>> /testdata/jars/file_with_long_line_1.jar!META-INF/MANIFEST.MF:2 >>>>>> >>>>>> Thanks >>>>>> Max >>> > From weijun.wang at oracle.com Tue Sep 4 02:50:43 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 4 Sep 2018 10:50:43 +0800 Subject: RFR 8210338: Better output for GenerationTests.java Message-ID: <6B4EF3D8-FAB0-4F53-B879-2E2EC1382451@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8210338/webrev.00/ This test enhancement adds section breaks and ensures everything written to stdout is flushed asap. With these info we will have a better understanding of when timeout happens in this test and what the best fix (to the parent bug) is. Thanks Max From xuelei.fan at oracle.com Tue Sep 4 04:38:27 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 3 Sep 2018 21:38:27 -0700 Subject: RFR 8210338: Better output for GenerationTests.java In-Reply-To: <6B4EF3D8-FAB0-4F53-B879-2E2EC1382451@oracle.com> References: <6B4EF3D8-FAB0-4F53-B879-2E2EC1382451@oracle.com> Message-ID: <968d3ac3-2240-edf4-ee55-d3c1d50daade@oracle.com> Looks fine to me. Xuelei On 9/3/2018 7:50 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8210338/webrev.00/ > > This test enhancement adds section breaks and ensures everything written to stdout is flushed asap. With these info we will have a better understanding of when timeout happens in this test and what the best fix (to the parent bug) is. > > Thanks > Max > From matthias.baesken at sap.com Tue Sep 4 11:33:44 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 4 Sep 2018 11:33:44 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com> <34b096660ca44a4cb3f674198cd51d35@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <647A92CD-85A6-4785-9E02-F41FDDBDB5DB@oracle.com> <0B89D420-B95D-4C6B-9C54-B7A0BFAE83B1@oracle.com> <38f2e1d2cbe24387bf693ac55492cf68@sap.com> Message-ID: <6ab99c1fc2004b32a5c08965c838d855@sap.com> > The change looks fine. We can enhance the name if we want to support .SF > parsing later. > > Please revise your CSR and get it approved first. Hi Max, Thanks ! I adjusted the CSR , please approve : https://bugs.openjdk.java.net/browse/JDK-8207768 Best regards, Matthias > -----Original Message----- > From: Weijun Wang > Sent: Montag, 3. September 2018 17:14 > To: Baesken, Matthias > Cc: Alan Bateman ; Sean Mullan > ; Chris Hegarty ; > security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > Hi Matthias > > The change looks fine. We can enhance the name if we want to support .SF > parsing later. > > Please revise your CSR and get it approved first. > > Thanks > Max > > > On Sep 3, 2018, at 10:19 PM, Baesken, Matthias > wrote: > > > > Hi Max, I > > > > - moved getErrorPosition method to Manifest.java > > - in read() method, removed "int offset" > > - in the exception message, I write now " manifest of " ... (without > mentioning a manifest name) > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/ > > > > > > Best regards, Matthias > > > > > >> -----Original Message----- > >> From: Weijun Wang > >> Sent: Freitag, 31. August 2018 15:53 > >> To: Baesken, Matthias > >> Cc: Alan Bateman ; Sean Mullan > >> ; Chris Hegarty ; > >> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > >> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > >> parsing of jar archives > >> > >> > >> > >>> On Aug 31, 2018, at 8:52 PM, Baesken, Matthias > >> wrote: > >>> > >>> Hi Max : > >>> > >>>> > >>>> - No need to "import java.security.Security". > >>> > >>> Sure I can remove this, it is a leftover. > >>> > >>>> - In the updated read() method, I think there is no need to use an "int > >> offset" > >>>> parameter. "int lineNumber" is enough and you can modify it and > return it > >>>> without a new local variable. > >>>> > >>> > >>> Currently we need it in Manifest.java public void read(InputStream is) > >> throws IOException { ... } > >> > >> I was talking about the name of the parameter. You can simply use > >> > >> int read(Manifest.FastInputStream is, byte[] lbuf, String filename, int > >> lineNumber) > >> > >> and there is no need to reassign it with "int lineNumber = offset" > anymore. > >> > >>> > >>>> In fact, I have a small concern on the hardcoded file name here, > because > >>>> when verifying a signed jar, the META-INF/X.SF file is also parsed into a > >>>> Manifest object and if it's invalid similar exceptions will be thrown. I > don't > >>>> have a nice solution now. > >>> > >>> Then lets just say : (e.g. test.jar:10 ) > >>> > >>> Or ( to mention that it is about a manifest from the jar ) > >>> > >>> :manifest-line (e.g. test.jar:manifest-line 10 ) > >> > >> How about you pass in the full name ("/path/to/file.jar!META- > >> INF/MANIFEST.MF") to "new Manifest(stream,name)" directly? > >> > >> So the name will be constructed in JarFile.java (after checking for > >> jarPathInExceptionText). The getErrorPosition method simply concat the > >> name (if not null) and the line number. Thus the exception thrown from > >> parsing X.SF simply will not include any file info. If we want it we can > enhance > >> later. > >> > >> Thanks > >> Max > >> > >>> > >>> > >>> Best regards, Matthias > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Weijun Wang > >>>> Sent: Freitag, 31. August 2018 04:32 > >>>> To: Baesken, Matthias > >>>> Cc: Alan Bateman ; Sean Mullan > >>>> ; Chris Hegarty > ; > >>>> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > >>>> Subject: Re: [RFR] 8205525 : Improve exception messages during > manifest > >>>> parsing of jar archives > >>>> > >>>> Some more comments: > >>>> > >>>> Attributes.java > >>>> > >>>> - No need to "import java.security.Security". > >>>> > >>>> - In the updated read() method, I think there is no need to use an "int > >> offset" > >>>> parameter. "int lineNumber" is enough and you can modify it and > return it > >>>> without a new local variable. > >>>> > >>>> - I feel like calling Attributes::getErrorPosition from Manifest a little > >> strange. > >>>> Maybe it's better to define the method in Manifest and call it from > >>>> Attributes. First, I think putting the method in a higher level object > makes > >>>> more sense. Second, the position is for the whole Manifest and not an > >>>> Attributes section (I mean the line number is counted from the first line > of > >>>> the manifest). > >>>> > >>>>> On Aug 30, 2018, at 10:50 PM, Baesken, Matthias > >>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>> Hi Max, probably we should add the info about the MANIFEST.MF , > >> for > >>>> example : > >>>>> change getErrorPosition to > >>>>> > >>>>> > >>>> > >> > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.7/src/java.base/s > >>>> hare/classes/java/util/jar/Attributes.java.udiff.html > >>>>> > >>>>> > >>>>> static String getErrorPosition(String filename, final int lineNumber) { > >>>>> if (filename == null || !jarPathInExceptionText) { > >>>>> return "META-INF/MANIFEST.MF line:" + lineNumber; > >>>>> } > >>>>> > >>>>> final File file = new File(filename); > >>>>> return AccessController.doPrivileged(new PrivilegedAction() > >> { > >>>>> public String run() { > >>>>> return file.getAbsolutePath() + "!META-INF/MANIFEST.MF line:" > >> + > >>>> lineNumber; > >>>> > >>>> I prefer "file:line" which is more compact and more commonly used. > >>>> > >>>> In fact, I have a small concern on the hardcoded file name here, > because > >>>> when verifying a signed jar, the META-INF/X.SF file is also parsed into a > >>>> Manifest object and if it's invalid similar exceptions will be thrown. I > don't > >>>> have a nice solution now. if we want to show the .SF name also, we will > >> need > >>>> a public API because SignatureFileVerifier.java is inside > sun.security.util. > >>>> Something like Manifest(InputStream,jarName,entryName)? > >>>> > >>>> Sorry for making this complicated. > >>>> > >>>> Thanks > >>>> Max > >>>> > >>>>> } > >>>>> ..... > >>>>> > >>>>> > >>>>> Best regards, Matthias > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Weijun Wang > >>>>>> Sent: Donnerstag, 30. August 2018 16:04 > >>>>>> To: Baesken, Matthias > >>>>>> Cc: Alan Bateman ; Sean Mullan > >>>>>> ; Chris Hegarty > >> ; > >>>>>> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > >>>>>> Subject: Re: [RFR] 8205525 : Improve exception messages during > >> manifest > >>>>>> parsing of jar archives > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Aug 30, 2018, at 8:26 PM, Baesken, Matthias > >>>>>> wrote: > >>>>>>> > >>>>>>>> - What will the output look like? Is it "/tmp/x.jar:100"? > >>>>>>>> > >>>>>>> > >>>>>>> Yes it look like this : > >>>>>>> > >>>>>>> line too long (/testdata/jars/file_with_long_line_1.jar:2) > >>>>>> > >>>>>> Is this a little misleading? I think you mean > >>>>>> > >>>>>> /testdata/jars/file_with_long_line_1.jar!META-INF/MANIFEST.MF:2 > >>>>>> > >>>>>> Thanks > >>>>>> Max > >>> > > From adam.petcher at oracle.com Tue Sep 4 12:57:59 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 4 Sep 2018 08:57:59 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> Message-ID: <1c957616-cd36-1cc8-9257-fad9a3dcb0a6@oracle.com> On 9/1/2018 2:03 PM, Michael StJohns wrote: > On 8/23/2018 1:50 PM, Adam Petcher wrote: >> It will only support a subset of the API that is supported by the >> implementation in SunEC. In particular, it will reject any private >> keys with scalar values specified using BigInteger (as in >> ECPrivateKeySpec), and its private keys will not return scalar values >> as BigInteger (as in ECPrivateKey.getS()). > > Um... why??? EC Private keys are integers.... I've said this multiple > times and - with the single exception of EDDSA keys because of a very > idiosyncratic (and IMHO short-sighted) RFC specification - all of the > EC private keys of whatever curve can be expressed as integers. > The explanation is in the JEP: "The existing API for ECC private keys has some classes that specify private scalar values using BigInteger. There is no way to get a value out of a BigInteger (into, for example, a fixed-length array) without branching." There is no problem with making private keys integers in the API. The problem is specifically with BigInteger and its implementation. BigInteger stores the value in the shortest int array possible. To access the value, you need to branch on the length of the array, which leaks whether the high-order bits of the private key are 0. From weijun.wang at oracle.com Tue Sep 4 13:31:58 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 4 Sep 2018 21:31:58 +0800 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <6ab99c1fc2004b32a5c08965c838d855@sap.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com> <34b096660ca44a4cb3f674198cd51d35@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <647A92CD-85A6-4785-9E02-F41FDDBDB5DB@oracle.com> <0B89D420-B95D-4C6B-9C54-B7A0BFAE83B1@oracle.com> <38f2e1d2cbe24387bf693ac55492cf68@sap.com> <6ab99c1fc2004b32a5c08965c838d855@sap.com> Message-ID: <058BD7B5-4D3A-4B56-ACB0-0DEDDDEA24B3@oracle.com> I've added myself as a reviewer. You might want to set scope to "JDK". A CSR is approved by the CSR group after you finalize it. First you should propose it. If you think it's urgent or trivial, you can also fast-track it. Read https://wiki.openjdk.java.net/display/csr/Main for more details. Thanks Max > On Sep 4, 2018, at 7:33 PM, Baesken, Matthias wrote: > >> The change looks fine. We can enhance the name if we want to support .SF >> parsing later. >> >> Please revise your CSR and get it approved first. > > Hi Max, Thanks ! > > I adjusted the CSR , please approve : > > https://bugs.openjdk.java.net/browse/JDK-8207768 > > Best regards, Matthias > > > >> -----Original Message----- >> From: Weijun Wang >> Sent: Montag, 3. September 2018 17:14 >> To: Baesken, Matthias >> Cc: Alan Bateman ; Sean Mullan >> ; Chris Hegarty ; >> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest >> parsing of jar archives >> >> Hi Matthias >> >> The change looks fine. We can enhance the name if we want to support .SF >> parsing later. >> >> Please revise your CSR and get it approved first. >> >> Thanks >> Max >> >>> On Sep 3, 2018, at 10:19 PM, Baesken, Matthias >> wrote: >>> >>> Hi Max, I >>> >>> - moved getErrorPosition method to Manifest.java >>> - in read() method, removed "int offset" >>> - in the exception message, I write now " manifest of " ... (without >> mentioning a manifest name) >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/ >>> >>> >>> Best regards, Matthias >>> >>> >>>> -----Original Message----- >>>> From: Weijun Wang >>>> Sent: Freitag, 31. August 2018 15:53 >>>> To: Baesken, Matthias >>>> Cc: Alan Bateman ; Sean Mullan >>>> ; Chris Hegarty ; >>>> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >>>> Subject: Re: [RFR] 8205525 : Improve exception messages during manifest >>>> parsing of jar archives >>>> >>>> >>>> >>>>> On Aug 31, 2018, at 8:52 PM, Baesken, Matthias >>>> wrote: >>>>> >>>>> Hi Max : >>>>> >>>>>> >>>>>> - No need to "import java.security.Security". >>>>> >>>>> Sure I can remove this, it is a leftover. >>>>> >>>>>> - In the updated read() method, I think there is no need to use an "int >>>> offset" >>>>>> parameter. "int lineNumber" is enough and you can modify it and >> return it >>>>>> without a new local variable. >>>>>> >>>>> >>>>> Currently we need it in Manifest.java public void read(InputStream is) >>>> throws IOException { ... } >>>> >>>> I was talking about the name of the parameter. You can simply use >>>> >>>> int read(Manifest.FastInputStream is, byte[] lbuf, String filename, int >>>> lineNumber) >>>> >>>> and there is no need to reassign it with "int lineNumber = offset" >> anymore. >>>> >>>>> >>>>>> In fact, I have a small concern on the hardcoded file name here, >> because >>>>>> when verifying a signed jar, the META-INF/X.SF file is also parsed into a >>>>>> Manifest object and if it's invalid similar exceptions will be thrown. I >> don't >>>>>> have a nice solution now. >>>>> >>>>> Then lets just say : (e.g. test.jar:10 ) >>>>> >>>>> Or ( to mention that it is about a manifest from the jar ) >>>>> >>>>> :manifest-line (e.g. test.jar:manifest-line 10 ) >>>> >>>> How about you pass in the full name ("/path/to/file.jar!META- >>>> INF/MANIFEST.MF") to "new Manifest(stream,name)" directly? >>>> >>>> So the name will be constructed in JarFile.java (after checking for >>>> jarPathInExceptionText). The getErrorPosition method simply concat the >>>> name (if not null) and the line number. Thus the exception thrown from >>>> parsing X.SF simply will not include any file info. If we want it we can >> enhance >>>> later. >>>> >>>> Thanks >>>> Max >>>> >>>>> >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Weijun Wang >>>>>> Sent: Freitag, 31. August 2018 04:32 >>>>>> To: Baesken, Matthias >>>>>> Cc: Alan Bateman ; Sean Mullan >>>>>> ; Chris Hegarty >> ; >>>>>> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >>>>>> Subject: Re: [RFR] 8205525 : Improve exception messages during >> manifest >>>>>> parsing of jar archives >>>>>> >>>>>> Some more comments: >>>>>> >>>>>> Attributes.java >>>>>> >>>>>> - No need to "import java.security.Security". >>>>>> >>>>>> - In the updated read() method, I think there is no need to use an "int >>>> offset" >>>>>> parameter. "int lineNumber" is enough and you can modify it and >> return it >>>>>> without a new local variable. >>>>>> >>>>>> - I feel like calling Attributes::getErrorPosition from Manifest a little >>>> strange. >>>>>> Maybe it's better to define the method in Manifest and call it from >>>>>> Attributes. First, I think putting the method in a higher level object >> makes >>>>>> more sense. Second, the position is for the whole Manifest and not an >>>>>> Attributes section (I mean the line number is counted from the first line >> of >>>>>> the manifest). >>>>>> >>>>>>> On Aug 30, 2018, at 10:50 PM, Baesken, Matthias >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Max, probably we should add the info about the MANIFEST.MF , >>>> for >>>>>> example : >>>>>>> change getErrorPosition to >>>>>>> >>>>>>> >>>>>> >>>> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.7/src/java.base/s >>>>>> hare/classes/java/util/jar/Attributes.java.udiff.html >>>>>>> >>>>>>> >>>>>>> static String getErrorPosition(String filename, final int lineNumber) { >>>>>>> if (filename == null || !jarPathInExceptionText) { >>>>>>> return "META-INF/MANIFEST.MF line:" + lineNumber; >>>>>>> } >>>>>>> >>>>>>> final File file = new File(filename); >>>>>>> return AccessController.doPrivileged(new PrivilegedAction() >>>> { >>>>>>> public String run() { >>>>>>> return file.getAbsolutePath() + "!META-INF/MANIFEST.MF line:" >>>> + >>>>>> lineNumber; >>>>>> >>>>>> I prefer "file:line" which is more compact and more commonly used. >>>>>> >>>>>> In fact, I have a small concern on the hardcoded file name here, >> because >>>>>> when verifying a signed jar, the META-INF/X.SF file is also parsed into a >>>>>> Manifest object and if it's invalid similar exceptions will be thrown. I >> don't >>>>>> have a nice solution now. if we want to show the .SF name also, we will >>>> need >>>>>> a public API because SignatureFileVerifier.java is inside >> sun.security.util. >>>>>> Something like Manifest(InputStream,jarName,entryName)? >>>>>> >>>>>> Sorry for making this complicated. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> } >>>>>>> ..... >>>>>>> >>>>>>> >>>>>>> Best regards, Matthias >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Weijun Wang >>>>>>>> Sent: Donnerstag, 30. August 2018 16:04 >>>>>>>> To: Baesken, Matthias >>>>>>>> Cc: Alan Bateman ; Sean Mullan >>>>>>>> ; Chris Hegarty >>>> ; >>>>>>>> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >>>>>>>> Subject: Re: [RFR] 8205525 : Improve exception messages during >>>> manifest >>>>>>>> parsing of jar archives >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Aug 30, 2018, at 8:26 PM, Baesken, Matthias >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> - What will the output look like? Is it "/tmp/x.jar:100"? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes it look like this : >>>>>>>>> >>>>>>>>> line too long (/testdata/jars/file_with_long_line_1.jar:2) >>>>>>>> >>>>>>>> Is this a little misleading? I think you mean >>>>>>>> >>>>>>>> /testdata/jars/file_with_long_line_1.jar!META-INF/MANIFEST.MF:2 >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>> >>> > From mstjohns at comcast.net Tue Sep 4 18:01:08 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 4 Sep 2018 14:01:08 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <1c957616-cd36-1cc8-9257-fad9a3dcb0a6@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <1c957616-cd36-1cc8-9257-fad9a3dcb0a6@oracle.com> Message-ID: Below On 9/4/2018 8:57 AM, Adam Petcher wrote: > On 9/1/2018 2:03 PM, Michael StJohns wrote: > >> On 8/23/2018 1:50 PM, Adam Petcher wrote: >>> It will only support a subset of the API that is supported by the >>> implementation in SunEC. In particular, it will reject any private >>> keys with scalar values specified using BigInteger (as in >>> ECPrivateKeySpec), and its private keys will not return scalar >>> values as BigInteger (as in ECPrivateKey.getS()). >> >> Um... why??? EC Private keys are integers.... I've said this multiple >> times and - with the single exception of EDDSA keys because of a very >> idiosyncratic (and IMHO short-sighted) RFC specification - all of the >> EC private keys of whatever curve can be expressed as integers. >> > > The explanation is in the JEP: > > "The existing API for ECC private keys has some classes that specify > private scalar values using BigInteger. There is no way to get a value > out of a BigInteger (into, for example, a fixed-length array) without > branching." > > There is no problem with making private keys integers in the API. The > problem is specifically with BigInteger and its implementation. > BigInteger stores the value in the shortest int array possible. To > access the value, you need to branch on the length of the array, which > leaks whether the high-order bits of the private key are 0. > > *buzz* wrong answer.?? Sorry.?? The internal storage of the key can be anything you want it to be if you want to prevent a non-constant-time issue for normal calculation.? But the import/export of the key really isn't subject to the cargo cult "must not branch" dogma - hint - I'm moving across a security boundary line anyway.??? So if I do a "getEncoded()" or a "getS()" on an ECPrivateKey object or provide a BigInteger on an ECPrivateKeySpec there is no additional threat over the presence of the private key bits in public space. If you believe this to be such a problem, then I'd suggest instead updating BigInteger to allow for BigEndian or LittleEndian encoding input/output and fix the constant time issue there inside the implementation rather than breaking public APIs. Alternately, I guess you could throw some sort of exception if someone tries to call getS() or getEncoded().? Or you could do what PKCS11 does for non-extractable private keys and only class the private key as a PrivateKey - make it opaque.? But then how do you create the key from stored information? Later, Mike From adam.petcher at oracle.com Tue Sep 4 19:19:51 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 4 Sep 2018 15:19:51 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <1c957616-cd36-1cc8-9257-fad9a3dcb0a6@oracle.com> Message-ID: <77ab28a5-8b14-db97-941e-7d3783a4f4c9@oracle.com> On 9/4/2018 2:01 PM, Michael StJohns wrote: > Below > > *buzz* wrong answer.?? Sorry.?? The internal storage of the key can be > anything you want it to be if you want to prevent a non-constant-time > issue for normal calculation.? But the import/export of the key really > isn't subject to the cargo cult "must not branch" dogma - hint - I'm > moving across a security boundary line anyway.??? So if I do a > "getEncoded()" or a "getS()" on an ECPrivateKey object or provide a > BigInteger on an ECPrivateKeySpec there is no additional threat over > the presence of the private key bits in public space. I think what you are suggesting is that the implementation should convert between BigInteger and the internal representation when necessary. The problem with this approach is that it is too easy to inadvertently supply a BigInteger to the implementation, and this would result in a branch. I understand that this branch may be acceptable in some circumstances, but we would need something in the API to tell the implementation whether it is okay to branch or not. I think the simplest way to do that is to have a provider that never branches. If branching is okay, then SunEC can be used. > > If you believe this to be such a problem, then I'd suggest instead > updating BigInteger to allow for BigEndian or LittleEndian encoding > input/output and fix the constant time issue there inside the > implementation rather than breaking public APIs. BigInteger wasn't designed for this sort of thing, and changing it so that supports constant-time encoding/decoding is a massive undertaking, if it is even possible. It would be more reasonable to add a new public type for integers that supports constant-time operations, but I don't think that helps us here. > > Alternately, I guess you could throw some sort of exception if someone > tries to call getS() or getEncoded().? Or you could do what PKCS11 > does for non-extractable private keys and only class the private key > as a PrivateKey - make it opaque.? But then how do you create the key > from stored information? That's essentially the plan. Calling PrivateKey::getEncoded will return null, which is a convention for non-extractable keys. Trying to convert from/to an ECPrivateKeySpec using the KeyFactory in the new provider will result in an exception---so you won't have an object to call getS() on. To create the key from stored information, the best way is to construct a PKCS8EncodedKeySpec using the encoded key. If you are starting with a BigInteger, and if branching is acceptable, you can use the KeyFactory from SunEC to convert an ECPrivateKeySpec to PrivateKey to get the encoded value. From xuelei.fan at oracle.com Tue Sep 4 19:25:28 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 4 Sep 2018 12:25:28 -0700 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: References: Message-ID: I have no finished the full code review. So far, I have a few question about the struct of the code. 1. XECParameters I can see the reason to dynamic parameters for something other than X25519/X448. But for JSSE, currently, only named curves are used. It would be nice to use the name for the static parameters. 2. "TlsPremasterSecret" only XDH key agreement It would be nice the JCE implementation can support key agreement other than TLS protocols and providers other than SunJSSE provider. It would be nice if the JCE implementation does not bind to the SunJSSE provider private algorithm name. We used to use SunJSSE private name in the JCE crypto implementation. But there are some known problems with this dependence. Is there a problem to support generic key agreement? 3. NamedGroupFunctions It might be more straightforward to define these functions in NamedGroup. If comparing nameGroup.getFunctions().getParameterSpec() and namedGroup.getParameterSpec(), I'd prefer the latter. 4. SSLKeyAgreementCredentials I did not see too much benefit of this new interface. It is not always true that a key agreement could have a public key. Although we can simplify the key agreement for public key based, but it also add additional layers. I know where this improvement comes from. Maybe, you can consolidate the named group functions, and encode/decode the credentials there. Xuelei On 8/30/2018 8:58 AM, Adam Petcher wrote: > Webrev: http://cr.openjdk.java.net/~apetcher/8171279/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8171279 > > Please review the following change to add support for X25519 and X448 > (XDH) to TLS 1.3. This change includes some refactoring to remove code > that was duplicated for DH and ECDH, and to avoid adding more for XDH. > In addition to running the included regression test, I tested by > connecting to an openssl server and confirmed that the connection was > established using TLS 1.3 and X25519/X448. > > Here are some detailed notes: > > *) The NamedGroupFunctions class was added to hold the functions that > are needed for key agreement with some named group. Most of the > group-specific code was moved into subclasses of NamedGroupFunctions. > This allowed me to remove a bunch of code like "if (type == ECDHE) {...} > else if (type == FFDHE) {...}". > *) There are a couple of files in the webrev with no changes due to a > webrev issue. Please ignore them. > *) I moved some code related to XDH parameters and encoding into > java.base. ECUtil now has code to encode/decode XDH public keys, and the > XECParameters file was moved into java.base/sun.security.util. This > organization is similar to how CurveDB and NamedCurve are in java.base, > and it allows the TLS implementation to encode/decode keys without using > the jdk.crypto.ec module. > From mstjohns at comcast.net Tue Sep 4 21:20:22 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 4 Sep 2018 17:20:22 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <77ab28a5-8b14-db97-941e-7d3783a4f4c9@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <1c957616-cd36-1cc8-9257-fad9a3dcb0a6@oracle.com> <77ab28a5-8b14-db97-941e-7d3783a4f4c9@oracle.com> Message-ID: <79b68c86-e5ad-f4a2-7cf5-5edfdc46a906@comcast.net> On 9/4/2018 3:19 PM, Adam Petcher wrote: > I think what you are suggesting is that the implementation should > convert between BigInteger and the internal representation when > necessary. The problem with this approach is that it is too easy to > inadvertently supply a BigInteger to the implementation, and this > would result in a branch. I understand that this branch may be > acceptable in some circumstances, but we would need something in the > API to tell the implementation whether it is okay to branch or not. I > think the simplest way to do that is to have a provider that never > branches. If branching is okay, then SunEC can be used. Basically yes. But I don't understand what you mean by "inadvertently supply a BigInteger"?? AFAICT, you "supply" a BigInteger in an ECPrivateKeySpec and you retrieve one when you call getEncoded() or getS().??? Your implementation would convert between the BigInteger and internal representation during the use of the engineGeneratePrivate() method of the KeyFactorySpi and would convert from your internal representation when exporting S, or encoding something as PKCS8. Again - you're wrongly conflating interface requirements with implementation requirements. And how do you expect to move key material between SunEC and this implementation?? See below for my commentary on that. > That's essentially the plan. Calling PrivateKey::getEncoded will > return null, which is a convention for non-extractable keys. Trying to > convert from/to an ECPrivateKeySpec using the KeyFactory in the new > provider will result in an exception---so you won't have an object to > call getS() on. That's not what PKCS11 does - it just gives you a "PrivateKey" object with an internal type of sun.security.pkcs11.P11Key.? While that object is not type safe exactly, it is provider safe. You're still wanting to use the various EC classes of java.security, java.security.spec, and java.security.interfaces, but you're unwilling to actually meet their contracts for some really suspect reasons. > > To create the key from stored information, the best way is to > construct a PKCS8EncodedKeySpec using the encoded key. If you are > starting with a BigInteger, and if branching is acceptable, you can > use the KeyFactory from SunEC to convert an ECPrivateKeySpec to > PrivateKey to get the encoded value. Umm... what? If you were doing NewEC -> SunEC manually (getEncoded() -> KeySpec) - you'll need to end up emitting a PKCS8 blob using RFC5915, which - unsurprisingly has? BigEndian INTEGERs? (yes, its an octet string, but the encoding is specified by RFC3447 as pretty much the big endian encoding of an integer).? E.g. it may look opaque from Java's point of view, but it's not really opaque. (See below) Or have you got a different way of encoding the PKCS8 blob for the new provider?? E.g. point me at a specification please. My head hurt when I tried to work through the various cases of translating a private key from your provider to SunEC or to BouncyCastle and vice versa.? Basically, if you don't support the getS() call, then KeyFactory.translateKey() will fail.? (Below from sun.security.ec.ECKeyFactory.java - the SunEC provider's implementation). > ?private PrivateKey implTranslatePrivateKey(PrivateKey key) > ??????????? throws InvalidKeyException { > ??????? if (key instanceof ECPrivateKey) { > ??????????? if (key instanceof ECPrivateKeyImpl) { > ??????????????? return key; > ??????????? } > ??????????? ECPrivateKey ecKey = (ECPrivateKey)key; > ??????????? return new ECPrivateKeyImpl( > ??????????????? ecKey.getS(), > ??????????????? ecKey.getParams() > ??????????? ); > ??????? } else if ("PKCS#8".equals(key.getFormat())) { > ??????????? return new ECPrivateKeyImpl(key.getEncoded()); > ??????? } else { > ??????????? throw new InvalidKeyException("Private keys must be instance " > ??????????????? + "of ECPrivateKey or have PKCS#8 encoding"); > ??????? } > 4.1 I2OSP > > > > I2OSP converts a nonnegative integer to an octet string of a > specified length. > > I2OSP (x, xLen) > > Input: > x nonnegative integer to be converted > xLen intended length of the resulting octet string > > Output: > X corresponding octet string of length xLen > > Error: "integer too large" > > Steps: > > 1. If x >= 256^xLen, output "integer too large" and stop. > > 2. Write the integer x in its unique xLen-digit representation in > base 256: > > x = x_(xLen-1) 256^(xLen-1) + x_(xLen-2) 256^(xLen-2) + ... > + x_1 256 + x_0, > > where 0 <= x_i < 256 (note that one or more leading digits will be > zero if x is less than 256^(xLen-1)). > > 3. Let the octet X_i have the integer value x_(xLen-i) for 1 <= i <= > xLen. Output the octet string > > X = X_1 X_2 ... X_xLen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed Sep 5 01:59:40 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 4 Sep 2018 18:59:40 -0700 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> Message-ID: These sun.security.pkcs11.wrapper classes are internal and subject to changes without notice. For the time being, maybe we can leave these method intact and add a comment about calling the new methods which use P11Key argument instead of the key handle argument. Regards, Valerie On 9/1/2018 11:18 AM, Michael StJohns wrote: > Hi Valerie - > > I may be speaking only for myself, but there are probably a number of > folk using sun.security.pkcs11.wrapper.* in lieu of the PKCS11 > provider for a number of reasons including an ability to manage the > key storage and wrapping efficiently.?? Looking at this I'm thinking > there will be a large number of things breaking because of the way you > refactored things. > > While I understand that none of the sun.security.* classes are > "public" - these were mostly taken directly from the IAIK contribution > way back when and the folks I worked with used them in lieu of > external libraries to have a consistent PKCS11 interface java-to-java. > > Perhaps instead you'd consider doing something like leaving the Java > to Native public methods intact? > > Mike > > > > > On 8/31/2018 7:53 PM, Valerie Peng wrote: >> >> Hi Martin, >> >> With the new model of "creating the key handle as needed", I think we >> should not allow the direct access of keyID field outside of P11Key >> class. This field should be made private and accessed through >> methods. In addition, existing PKCS11.C_XXX() methods with P11 keyID >> arguments can be made private and we can add wrapper methods with >> P11Key object argument to ensure proper usage of the P11Key object >> and its keyID field. >> >> I have also refactored the keyID management code into a separate >> holder class. The prototype code can be found at: >> http://cr.openjdk.java.net/~valeriep/6913047Exp/webrev.00/ >> >> The main changes that I made are in P11Key.java and PKCS11.java. The >> other java classes are updated to call the wrapper methods in >> PKCS11.java. >> >> Thanks & have a great Labor day weekend, >> >> Valerie >> >> >> On 8/16/2018 5:28 PM, Valerie Peng wrote: >>> >>> Hi Martin, >>> >>> >>> Since there is no regression test for this test, you will need to >>> add a "noreg-xxx" label to the bug record. For this issue, it'll >>> probably be "noreg-hard". >>> >>> To understand the changes better, please find my questions and some >>> review comments below: >>> >>> >>> - line 397: It's incorrect to change initialize() to >>> ensureInitialized(). If the cipher object were to be initialized >>> twice with two different keys, you need to re-initialize again. >>> - line 471: Why do you change it to Throwable from PKCS11Exception? >>> >>> >>> - line 99: comment is somewhat unclear. typo: "temporal" should be >>> "temporary". >>> - line 148-149: JDK-8165996 has been fixed. This does not apply now, >>> does it? >>> - You changed the constructors of all the P11Key-related classes to >>> take an additional boolean argument "tmpNativeKey". However, this >>> boolean argument is only used when the underlying token is "NSS". >>> Why limiting to NSS only? It seems that all callers except for >>> PKCS11 KeyStore pass true for "tmpNativeKey". When "tmpNativeKey" is >>> true, the keyID handle first destroyed in constructor and later >>> created again (ref count == 1) and destroyed (when ref count drops >>> to 0). This replaced the PhantomReference approach in SessionKeyRef >>> class, right? Now both approaches seem to be used and key >>> destruction is taking places at different methods. I think we should >>> clarify the cleanup model and perhaps refactor the code so it's >>> easier which approach is in use. Or grouping all these >>> cleanup-related fields/variables into a separate class for >>> readability/clarity. >>> - line 157-175: nativeKeyWrapperKeyID is a static variable, >>> shouldn't it be synchronized on a class level object? >>> - line 1343: the impl doesn't look right. Why do you call both >>> removeObject() and addObject() here with the same check? >>> - line 1363: the change seems incorrect, you should still call >>> session.removeObject(). the call setKeyIDAndSession(0, null) does >>> not lower the session object count. >>> >>> Thanks, >>> Valerie >>> >>> On 8/7/2018 5:41 PM, Valerie Peng wrote: >>>> >>>> Hi Martin, >>>> >>>> Thanks for the update, I will resume the review on this one with >>>> your latest webrev. >>>> >>>> BTW, there is no webrev.07 for your other fix, i.e. JDK-8029661, >>>> right? Just checking. >>>> >>>> Regards, >>>> Valerie >>>> >>>> On 8/3/2018 2:13 PM, Martin Balao wrote: >>>>> Hi Valerie, >>>>> >>>>> ?* >>>>> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10/ >>>>> >>>>> ?* >>>>> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10.zip >>>>> >>>>> >>>>> New in webrev 10: >>>>> >>>>> ?* Bug fix when private DSA/EC keys are sensitive >>>>> ? * I found this bug removing "attributes = compatibility" entry >>>>> in NSS configuration file so keys were CKA_SENSITIVE. >>>>> ? * This is really an NSS bug when unwrapping ephemeral keys >>>>> (NSC_UnwrapKey function), because CKA_NETSCAPE_DB attribute is >>>>> required but not used/needed. There was a similar bug when >>>>> creating objects (NSC_CreateObject function), fixed many years ago >>>>> [1]. >>>>> ? * In those cases in which the bug occurs (private keys, of >>>>> DSA/EC type, sensitive and without CKA_NETSCAPE_DB attribute set), >>>>> I store an empty CKA_NETSCAPE_DB attribute in the buffer that will >>>>> later be used for key unwrapping. I'm not doing a >>>>> C_SetAttributeValue call because keys are read-only. We can let >>>>> users set CKA_NETSCAPE_DB attribute in NSS configuration file [2] >>>>> but this would be a workaround on users side. >>>>> ? * Changes in: >>>>> ? ?* p11_keymgmt.c >>>>> ? ? * L175-187, L212-214 and L275-278 >>>>> >>>>> ?* Bug fix when storing sensitive RSA keys in a keystore >>>>> ? * CKA_NETSCAPE_DB attribute is not needed so we return it as >>>>> null (instead of failing with an "Invalid algorithm" message) >>>>> ? * Changes in: >>>>> ? ?* P11KeyStore.java >>>>> ? ? * L1909-1914 >>>>> >>>>> ?* Lines length was cut to improve code readability >>>>> >>>>> Regression tests on jdk/sun/security/pkcs11 category passed. I ran >>>>> my internal test suite too, that covers the following services >>>>> (with SunPKCS11 provider): Cipher, Signature, KeyAgreement, >>>>> Digest, Mac, KeyGenerator, KeyPairGenerator and Keystore. >>>>> >>>>> Kind regards, >>>>> Martin.- >>>>> >>>>> -- >>>>> [1] - https://bugzilla.mozilla.org/show_bug.cgi?id=309701#c6 >>>>> >>>>> [2] - >>>>> https://alvinalexander.com/java/jwarehouse/openjdk-8/jdk/test/sun/security/pkcs11/fips/fips.cfg.shtml >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Sep 5 04:17:26 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 5 Sep 2018 12:17:26 +0800 Subject: RFR 8210395: Add doc to SecurityTools.java Message-ID: <22AF6964-E1CD-491A-BC9C-0318965FE171@oracle.com> I ran javadoc on test/lib so I can learn the useful helper classes, and find out SecurityTools.java has no javadoc at all. Please review this change http://cr.openjdk.java.net/~weijun/8210395/webrev.00/ Thanks Max From matthias.baesken at sap.com Wed Sep 5 08:07:02 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 5 Sep 2018 08:07:02 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives Message-ID: <2bc2e45729c640d9afab76d108ec6951@sap.com> Hi Max, thanks for adding yourself as a reviewer. I set the CSR ( https://bugs.openjdk.java.net/browse/JDK-8207768 ) to proposed. Best regards, Matthias > > Message: 2 > Date: Tue, 4 Sep 2018 21:31:58 +0800 > From: Weijun Wang > To: "Baesken, Matthias" > Cc: "security-dev at openjdk.java.net" , > "core-libs-dev at openjdk.java.net" dev at openjdk.java.net> > Subject: Re: [RFR] 8205525 : Improve exception messages during > manifest parsing of jar archives > Message-ID: <058BD7B5-4D3A-4B56-ACB0-0DEDDDEA24B3 at oracle.com> > Content-Type: text/plain; charset=us-ascii > > I've added myself as a reviewer. You might want to set scope to "JDK". > > A CSR is approved by the CSR group after you finalize it. First you should > propose it. If you think it's urgent or trivial, you can also fast-track it. > > Read https://wiki.openjdk.java.net/display/csr/Main for more details. > > Thanks > Max > > > On Sep 4, 2018, at 7:33 PM, Baesken, Matthias > wrote: > > > >> The change looks fine. We can enhance the name if we want to support > .SF > >> parsing later. > >> > >> Please revise your CSR and get it approved first. > > > > Hi Max, Thanks ! > > > > I adjusted the CSR , please approve : > > > > https://bugs.openjdk.java.net/browse/JDK-8207768 > > > > Best regards, Matthias From christoph.langer at sap.com Wed Sep 5 15:01:54 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 5 Sep 2018 15:01:54 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <2bc2e45729c640d9afab76d108ec6951@sap.com> References: <2bc2e45729c640d9afab76d108ec6951@sap.com> Message-ID: <75b6f813364f42678d87851aac533346@sap.com> Hi Matthias, I have reviewed your change, +1 I also reviewed the CSR. Best regards Christoph > -----Original Message----- > From: Baesken, Matthias > Sent: Mittwoch, 5. September 2018 10:07 > To: security-dev at openjdk.java.net; Weijun Wang > ; core-libs-dev at openjdk.java.net > Cc: Langer, Christoph > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > Hi Max, thanks for adding yourself as a reviewer. > > I set the CSR ( https://bugs.openjdk.java.net/browse/JDK-8207768 ) to > proposed. > > Best regards, Matthias > > > > > Message: 2 > > Date: Tue, 4 Sep 2018 21:31:58 +0800 > > From: Weijun Wang > > To: "Baesken, Matthias" > > Cc: "security-dev at openjdk.java.net" , > > "core-libs-dev at openjdk.java.net" > dev at openjdk.java.net> > > Subject: Re: [RFR] 8205525 : Improve exception messages during > > manifest parsing of jar archives > > Message-ID: <058BD7B5-4D3A-4B56-ACB0-0DEDDDEA24B3 at oracle.com> > > Content-Type: text/plain; charset=us-ascii > > > > I've added myself as a reviewer. You might want to set scope to "JDK". > > > > A CSR is approved by the CSR group after you finalize it. First you should > > propose it. If you think it's urgent or trivial, you can also fast-track it. > > > > Read https://wiki.openjdk.java.net/display/csr/Main for more details. > > > > Thanks > > Max > > > > > On Sep 4, 2018, at 7:33 PM, Baesken, Matthias > > wrote: > > > > > >> The change looks fine. We can enhance the name if we want to support > > .SF > > >> parsing later. > > >> > > >> Please revise your CSR and get it approved first. > > > > > > Hi Max, Thanks ! > > > > > > I adjusted the CSR , please approve : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8207768 > > > > > > Best regards, Matthias From adam.petcher at oracle.com Wed Sep 5 17:09:36 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 5 Sep 2018 13:09:36 -0400 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: References: Message-ID: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> Updated webrev: http://cr.openjdk.java.net/~apetcher/8171279/webrev.01/ On 9/4/2018 3:25 PM, Xuelei Fan wrote: > I have no finished the full code review.? So far, I have a few > question about the struct of the code. > 1. XECParameters > I can see the reason to dynamic parameters for something other than > X25519/X448.? But for JSSE, currently, only named curves are used.? It > would be nice to use the name for the static parameters. Sorry, I don't think I understand what you are suggesting here. As far as I know, nothing in sun.security.ssl uses XECParameters directly. It is used indirectly through ECUtil to encode and decode keys, and in this case the name is used to look up the parameters. Is there some place in the code where JSSE is doing something too complicated related to these parameters? > > 2. "TlsPremasterSecret" only XDH key agreement > It would be nice the JCE implementation can support key agreement > other than TLS protocols and providers other than SunJSSE provider.? > It would be nice if the JCE implementation does not bind to the > SunJSSE provider private algorithm name. > > We used to use SunJSSE private name in the JCE crypto implementation. > But there are some known problems with this dependence. > > Is there a problem to support generic key agreement? I simply continued the pattern that was used in DH and ECDH. We can use a different string here, but I worry that people will be surprised if DH and ECDH support "TlsPreMasterSecret" but XDH doesn't. I would rather continue to use "TlsPreMasterSecret" for now, and then add support for a standard, TLS-independent name (that means the same thing) in a separate ticket. But if you feel strongly that XDH should not support "TlsPreMasterSecret", then perhaps we can use a different string now. In this case, let me know if you have any suggestions for what string to use. > > 3. NamedGroupFunctions > It might be more straightforward to define these functions in > NamedGroup.? If comparing nameGroup.getFunctions().getParameterSpec() > and namedGroup.getParameterSpec(), I'd prefer the latter. A simple way to accomplish this is to leave the structure alone and add methods in NamedGroup that pass through to the corresponding methods in NamedGroupFunctions. I made this change in the updated webrev. Let me know what you think. > > 4. SSLKeyAgreementCredentials > I did not see too much benefit of this new interface.? It is not > always true that a key agreement could have a public key. Although we > can simplify the key agreement for public key based, but it also add > additional layers. > > I know where this improvement comes from.? Maybe, you can consolidate > the named group functions, and encode/decode the credentials there. This interface is only used to validate public keys against algorithm constraints. In the latest webrev, I moved all of this functionality into NamedGroupFunctions and removed the SSLKeyAgreementCredentials interface. From xuelei.fan at oracle.com Wed Sep 5 17:35:50 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 5 Sep 2018 10:35:50 -0700 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> Message-ID: <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> On 9/5/2018 10:09 AM, Adam Petcher wrote: > Updated webrev: http://cr.openjdk.java.net/~apetcher/8171279/webrev.01/ > > On 9/4/2018 3:25 PM, Xuelei Fan wrote: > >> I have no finished the full code review.? So far, I have a few >> question about the struct of the code. >> 1. XECParameters >> I can see the reason to dynamic parameters for something other than >> X25519/X448.? But for JSSE, currently, only named curves are used.? It >> would be nice to use the name for the static parameters. > > Sorry, I don't think I understand what you are suggesting here. As far > as I know, nothing in sun.security.ssl uses XECParameters directly. Okay, it is used indirectly. > It > is used indirectly through ECUtil to encode and decode keys, and in this > case the name is used to look up the parameters. Can the public NamedParameterSpec be used, instead of the private XECParameters? I think XECParameters may be better in the EC provider, please try to mitigate the dependence between modules. If one day the sun.security.util.XECParameters get updated, the EC implementation get impacted a lot. I prefer to use public APIs if possible. > Is there some place in > the code where JSSE is doing something too complicated related to these > parameters? > Yes, the algorithm name is sufficient, I'm not sure the necessary to use XECParameters in sun.security.util. >> >> 2. "TlsPremasterSecret" only XDH key agreement >> It would be nice the JCE implementation can support key agreement >> other than TLS protocols and providers other than SunJSSE provider. It >> would be nice if the JCE implementation does not bind to the SunJSSE >> provider private algorithm name. >> >> We used to use SunJSSE private name in the JCE crypto implementation. >> But there are some known problems with this dependence. >> >> Is there a problem to support generic key agreement? > > I simply continued the pattern that was used in DH and ECDH. We can use > a different string here, but I worry that people will be surprised if DH > and ECDH support "TlsPreMasterSecret" but XDH doesn't. It could support "TlsPreMasterSecret", right? My concern is about not limited to this one only. > I would rather > continue to use "TlsPreMasterSecret" for now, and then add support for a > standard, TLS-independent name (that means the same thing) in a separate > ticket. But if you feel strongly that XDH should not support > "TlsPreMasterSecret", then perhaps we can use a different string now. In > this case, let me know if you have any suggestions for what string to use. > See above. >> >> 3. NamedGroupFunctions >> It might be more straightforward to define these functions in >> NamedGroup.? If comparing nameGroup.getFunctions().getParameterSpec() >> and namedGroup.getParameterSpec(), I'd prefer the latter. > > A simple way to accomplish this is to leave the structure alone and add > methods in NamedGroup that pass through to the corresponding methods in > NamedGroupFunctions. I made this change in the updated webrev. Let me > know what you think. > It looks like a problem to me to use this before it constructed. this.functions = new ECDHFunctions(this); and the use of new object for each named group is not effective. The current NamedGroupFunctions abstract class does not sound good enough to me, considering the numbers of the named groups. I have no idea so far, but I think you can improve it. Probably use static methods? >> >> 4. SSLKeyAgreementCredentials >> I did not see too much benefit of this new interface.? It is not >> always true that a key agreement could have a public key. Although we >> can simplify the key agreement for public key based, but it also add >> additional layers. >> >> I know where this improvement comes from.? Maybe, you can consolidate >> the named group functions, and encode/decode the credentials there. > > This interface is only used to validate public keys against algorithm > constraints. In the latest webrev, I moved all of this functionality > into NamedGroupFunctions and removed the SSLKeyAgreementCredentials > interface. > Thanks, I like it the new design. Xuelei From xuelei.fan at oracle.com Wed Sep 5 18:01:53 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 5 Sep 2018 11:01:53 -0700 Subject: Code Review Request, JDK-8210334, TLS 1.3 server fails if ClientHello doesn't have pre_shared_key and psk_key_exchange_modes Message-ID: Hi, Please review: http://cr.openjdk.java.net/~xuelei/8210334/webrev.00/ Simple update, no new regression test. Thanks, Xuelei From anthony.scarpino at oracle.com Wed Sep 5 18:13:33 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 5 Sep 2018 11:13:33 -0700 Subject: Code Review Request, JDK-8210334, TLS 1.3 server fails if ClientHello doesn't have pre_shared_key and psk_key_exchange_modes In-Reply-To: References: Message-ID: <0ED05798-8389-4FD4-8D4B-040423F62FEC@oracle.com> Looks fine > On Sep 5, 2018, at 11:01 AM, Xuelei Fan wrote: > > Hi, > > Please review: > http://cr.openjdk.java.net/~xuelei/8210334/webrev.00/ > > Simple update, no new regression test. > > Thanks, > Xuelei From bradford.wetmore at oracle.com Wed Sep 5 18:16:13 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 5 Sep 2018 11:16:13 -0700 Subject: Code Review Request, JDK-8210334, TLS 1.3 server fails if ClientHello doesn't have pre_shared_key and psk_key_exchange_modes In-Reply-To: References: Message-ID: <4da72f16-4eb0-fb71-6c07-251340d61c18@oracle.com> Looks good. Brad On 9/5/2018 11:01 AM, Xuelei Fan wrote: > Hi, > > Please review: > ??? http://cr.openjdk.java.net/~xuelei/8210334/webrev.00/ > > Simple update, no new regression test. > > Thanks, > Xuelei From adam.petcher at oracle.com Wed Sep 5 18:47:27 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 5 Sep 2018 14:47:27 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <79b68c86-e5ad-f4a2-7cf5-5edfdc46a906@comcast.net> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <1c957616-cd36-1cc8-9257-fad9a3dcb0a6@oracle.com> <77ab28a5-8b14-db97-941e-7d3783a4f4c9@oracle.com> <79b68c86-e5ad-f4a2-7cf5-5edfdc46a906@comcast.net> Message-ID: On 9/4/2018 5:20 PM, Michael StJohns wrote: > On 9/4/2018 3:19 PM, Adam Petcher wrote: >> I think what you are suggesting is that the implementation should >> convert between BigInteger and the internal representation when >> necessary. The problem with this approach is that it is too easy to >> inadvertently supply a BigInteger to the implementation, and this >> would result in a branch. I understand that this branch may be >> acceptable in some circumstances, but we would need something in the >> API to tell the implementation whether it is okay to branch or not. I >> think the simplest way to do that is to have a provider that never >> branches. If branching is okay, then SunEC can be used. > > Basically yes. > > But I don't understand what you mean by "inadvertently supply a > BigInteger"?? AFAICT, you "supply" a BigInteger in an ECPrivateKeySpec > and you retrieve one when you call getEncoded() or getS().??? Your > implementation would convert between the BigInteger and internal > representation during the use of the engineGeneratePrivate() method of > the KeyFactorySpi and would convert from your internal representation > when exporting S, or encoding something as PKCS8. > I mean that the JCA client code may put a private key value in an ECPrivateKeySpec and give it to the KeyFactory of the new ECC implementation. Also problematic is calling getS() on an ECPrivateKey from the new implementation and converting the private key to a BigInteger. Both of these situations may leak some bits of the private key value into side channels, and the use of the "NewEC" provider is an assertion by the programmer/environment that these side-channel leaks are unacceptable. So the new provider will prevent these problems by rejecting ECPrivateKeySpec in its KeyFactory, and by returning null from getS(). BigInteger will not be used by engineGeneratePrivate when the spec is a PKCS8EncodedKeySpec (the only option). BigInteger is also not required to encode/decode a PKCS#8 private key. > Again - you're wrongly conflating interface requirements with > implementation requirements. > > And how do you expect to move key material between SunEC and this > implementation?? See below for my commentary on that. > > >> That's essentially the plan. Calling PrivateKey::getEncoded will >> return null, which is a convention for non-extractable keys. Trying >> to convert from/to an ECPrivateKeySpec using the KeyFactory in the >> new provider will result in an exception---so you won't have an >> object to call getS() on. > That's not what PKCS11 does - it just gives you a "PrivateKey" object > with an internal type of sun.security.pkcs11.P11Key.? While that > object is not type safe exactly, it is provider safe. > > You're still wanting to use the various EC classes of java.security, > java.security.spec, and java.security.interfaces, but you're unwilling > to actually meet their contracts for some really suspect reasons. > Sorry, I referred to the wrong methods in my last e-mail. ECPrivateKey::getS will return null in the new implementation. The getEncoded method will return the encoded key, as usual. The second sentence referred to ECPrivateKeySpec::getS, which will remain unchanged, but you won't be able to use ECPrivateKeySpec with the new provider. I don't believe my proposal violates the contracts of any of these classes, but if you believe that it does (after the correction above), then let me know which contracts are violated. > >> >> To create the key from stored information, the best way is to >> construct a PKCS8EncodedKeySpec using the encoded key. If you are >> starting with a BigInteger, and if branching is acceptable, you can >> use the KeyFactory from SunEC to convert an ECPrivateKeySpec to >> PrivateKey to get the encoded value. > > Umm... what? > > If you were doing NewEC -> SunEC manually (getEncoded() -> KeySpec) - > you'll need to end up emitting a PKCS8 blob using RFC5915, which - > unsurprisingly has? BigEndian INTEGERs (yes, its an octet string, but > the encoding is specified by RFC3447 as pretty much the big endian > encoding of an integer). E.g. it may look opaque from Java's point of > view, but it's not really opaque. (See below) > > Or have you got a different way of encoding the PKCS8 blob for the new > provider?? E.g. point me at a specification please. > There is no issue with integers or endianness. The problem is specifically with BigInteger---it uses a variable-length representation, and it's spec does not give any guarantees about branching. The PKCS#8 encoding is fine because it is fixed length, so I can directly use the privateKey octet string (with bytes reversed, if necessary) in a branchless double-and-add loop. > My head hurt when I tried to work through the various cases of > translating a private key from your provider to SunEC or to > BouncyCastle and vice versa.? Basically, if you don't support the > getS() call, then KeyFactory.translateKey() will fail. (Below from > sun.security.ec.ECKeyFactory.java - the SunEC provider's implementation). > >> ?private PrivateKey implTranslatePrivateKey(PrivateKey key) >> ??????????? throws InvalidKeyException { >> ??????? if (key instanceof ECPrivateKey) { >> ??????????? if (key instanceof ECPrivateKeyImpl) { >> ??????????????? return key; >> ??????????? } >> ??????????? ECPrivateKey ecKey = (ECPrivateKey)key; >> ??????????? return new ECPrivateKeyImpl( >> ??????????????? ecKey.getS(), >> ??????????????? ecKey.getParams() >> ??????????? ); >> ??????? } else if ("PKCS#8".equals(key.getFormat())) { >> ??????????? return new ECPrivateKeyImpl(key.getEncoded()); >> ??????? } else { >> ??????????? throw new InvalidKeyException("Private keys must be >> instance " >> ??????????????? + "of ECPrivateKey or have PKCS#8 encoding"); >> ??????? } > The code above could be improved by using the PKCS#8 encoding when getS() returns null. The only way to get private keys in or out of the new provider is through a PKCS#8 encoding. Moving keys to/from another provider that supports ECPrivateKeySpec but not PKCS#8 encoding can be accomplished by translating the specs---possibly with the help of a KeyFactory that supports both, like the one in SunEC. From adam.petcher at oracle.com Wed Sep 5 19:49:24 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 5 Sep 2018 15:49:24 -0400 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> Message-ID: <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> New webrev: http://cr.openjdk.java.net/~apetcher/8171279/webrev.02/ On 9/5/2018 1:35 PM, Xuelei Fan wrote: > On 9/5/2018 10:09 AM, Adam Petcher wrote: > >> Is there some place in the code where JSSE is doing something too >> complicated related to these parameters? >> > Yes, the algorithm name is sufficient, I'm not sure the necessary to > use XECParameters in sun.security.util. The algorithm name is not quite sufficient. See the new methods that were added to ECUtil that encode/decode public keys. We also need to know the key length (which is in XECParameters) in order to encode/decode public keys. > >> >> I simply continued the pattern that was used in DH and ECDH. We can >> use a different string here, but I worry that people will be >> surprised if DH and ECDH support "TlsPreMasterSecret" but XDH doesn't. > It could support "TlsPreMasterSecret", right?? My concern is about not > limited to this one only. Yes, it supports "TlsPreMasterSecret" in the webrev now. Perhaps I'm not sure what you are suggesting here. > >>> >>> 3. NamedGroupFunctions >>> It might be more straightforward to define these functions in >>> NamedGroup.? If comparing >>> nameGroup.getFunctions().getParameterSpec() and >>> namedGroup.getParameterSpec(), I'd prefer the latter. >> >> A simple way to accomplish this is to leave the structure alone and >> add methods in NamedGroup that pass through to the corresponding >> methods in NamedGroupFunctions. I made this change in the updated >> webrev. Let me know what you think. >> > It looks like a problem to me to use this before it constructed. > ??? this.functions = new ECDHFunctions(this); > > and the use of new object for each named group is not effective. The > current NamedGroupFunctions abstract class does not sound good enough > to me, considering the numbers of the named groups. > > I have no idea so far, but I think you can improve it.? Probably use > static methods? In the latest webrev, I changed it so there is a single static NamedGroupFunctions of each type, and the NamedGroup is passed in as the first argument to each method that requires it (rather than being a member of NamedGroupFunctions). From mstjohns at comcast.net Wed Sep 5 21:53:23 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 5 Sep 2018 17:53:23 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <1c957616-cd36-1cc8-9257-fad9a3dcb0a6@oracle.com> <77ab28a5-8b14-db97-941e-7d3783a4f4c9@oracle.com> <79b68c86-e5ad-f4a2-7cf5-5edfdc46a906@comcast.net> Message-ID: On 9/5/2018 2:47 PM, Adam Petcher wrote: > On 9/4/2018 5:20 PM, Michael StJohns wrote: > >> On 9/4/2018 3:19 PM, Adam Petcher wrote: >>> I think what you are suggesting is that the implementation should >>> convert between BigInteger and the internal representation when >>> necessary. The problem with this approach is that it is too easy to >>> inadvertently supply a BigInteger to the implementation, and this >>> would result in a branch. I understand that this branch may be >>> acceptable in some circumstances, but we would need something in the >>> API to tell the implementation whether it is okay to branch or not. >>> I think the simplest way to do that is to have a provider that never >>> branches. If branching is okay, then SunEC can be used. >> >> Basically yes. >> >> But I don't understand what you mean by "inadvertently supply a >> BigInteger"?? AFAICT, you "supply" a BigInteger in an >> ECPrivateKeySpec and you retrieve one when you call getEncoded() or >> getS().??? Your implementation would convert between the BigInteger >> and internal representation during the use of the >> engineGeneratePrivate() method of the KeyFactorySpi and would convert >> from your internal representation when exporting S, or encoding >> something as PKCS8. >> > > I mean that the JCA client code may put a private key value in an > ECPrivateKeySpec and give it to the KeyFactory of the new ECC > implementation. Also problematic is calling getS() on an ECPrivateKey > from the new implementation and converting the private key to a > BigInteger. Both of these situations may leak some bits of the private > key value into side channels, and the use of the "NewEC" provider is > an assertion by the programmer/environment that these side-channel > leaks are unacceptable. So the new provider will prevent these > problems by rejecting ECPrivateKeySpec in its KeyFactory, and by > returning null from getS(). BigInteger will not be used by > engineGeneratePrivate when the spec is a PKCS8EncodedKeySpec (the only > option). BigInteger is also not required to encode/decode a PKCS#8 > private key. BigInteger is not required to encode a PKCS8 key, but its trivial to translate from BigInteger to PKCS8 and vice versa.? Note that internally, the current BigInteger stores the magnitude as an array of int in big endian order and stores the sign separately.? The BigInteger (int sigNum, byte[] magnitude) constructor mostly just copies the magnitude bytes over (and converts 4 bytes to an integer) for positive integers. ? While the current BigInteger doesn't have a byte[] BigInteger.getMagnitude() call, it would be trivial to subclass BigInteger to copy the magnitude bytes (without branching) out. In any event, for NewEC to OldEc - you do use the sign/magnitude call to create the BigInteger - no leaking on the part of NewEC, and once it gets to OldEC its not your problem.? For OldEc to NewEc you copy the BigInteger to NewBigInteger (trivial wrapper class) and do a getMagnitude(). > >> Again - you're wrongly conflating interface requirements with >> implementation requirements. >> >> And how do you expect to move key material between SunEC and this >> implementation?? See below for my commentary on that. >> >> >>> That's essentially the plan. Calling PrivateKey::getEncoded will >>> return null, which is a convention for non-extractable keys. Trying >>> to convert from/to an ECPrivateKeySpec using the KeyFactory in the >>> new provider will result in an exception---so you won't have an >>> object to call getS() on. >> That's not what PKCS11 does - it just gives you a "PrivateKey" object >> with an internal type of sun.security.pkcs11.P11Key. While that >> object is not type safe exactly, it is provider safe. >> >> You're still wanting to use the various EC classes of java.security, >> java.security.spec, and java.security.interfaces, but you're >> unwilling to actually meet their contracts for some really suspect >> reasons. >> > > Sorry, I referred to the wrong methods in my last e-mail. > ECPrivateKey::getS will return null in the new implementation. The > getEncoded method will return the encoded key, as usual. The second > sentence referred to ECPrivateKeySpec::getS, which will remain > unchanged, but you won't be able to use ECPrivateKeySpec with the new > provider. > > I don't believe my proposal violates the contracts of any of these > classes, but if you believe that it does (after the correction above), > then let me know which contracts are violated. While the contract for getEncoded() explicitly allows for a null result, getS() of ECPrivateKey does not.??? This more than any other reason appears to be why the PKCS 11 provider represents the ECPrivateKey as a simple PrivateKey object. > >> >>> >>> To create the key from stored information, the best way is to >>> construct a PKCS8EncodedKeySpec using the encoded key. If you are >>> starting with a BigInteger, and if branching is acceptable, you can >>> use the KeyFactory from SunEC to convert an ECPrivateKeySpec to >>> PrivateKey to get the encoded value. >> >> Umm... what? >> >> If you were doing NewEC -> SunEC manually (getEncoded() -> KeySpec) - >> you'll need to end up emitting a PKCS8 blob using RFC5915, which - >> unsurprisingly has? BigEndian INTEGERs (yes, its an octet string, but >> the encoding is specified by RFC3447 as pretty much the big endian >> encoding of an integer). E.g. it may look opaque from Java's point of >> view, but it's not really opaque. (See below) >> >> Or have you got a different way of encoding the PKCS8 blob for the >> new provider?? E.g. point me at a specification please. >> > > There is no issue with integers or endianness. The problem is > specifically with BigInteger---it uses a variable-length > representation, and it's spec does not give any guarantees about > branching. The PKCS#8 encoding is fine because it is fixed length, so > I can directly use the privateKey octet string (with bytes reversed, > if necessary) in a branchless double-and-add loop. Yup - and see the above for how to use BigInteger.? Note that you MUST provide the bytes in BigEndian order for the current version of how to encode an ec private key as PKCS8.? You must also provide exactly N bytes including any leading (or for little endian - trailing) '0's to pad it out.? Which looks to me like a possible requirement to test and branch. > >> My head hurt when I tried to work through the various cases of >> translating a private key from your provider to SunEC or to >> BouncyCastle and vice versa.? Basically, if you don't support the >> getS() call, then KeyFactory.translateKey() will fail. (Below from >> sun.security.ec.ECKeyFactory.java - the SunEC provider's >> implementation). >> >>> ?private PrivateKey implTranslatePrivateKey(PrivateKey key) >>> ??????????? throws InvalidKeyException { >>> ??????? if (key instanceof ECPrivateKey) { >>> ??????????? if (key instanceof ECPrivateKeyImpl) { >>> ??????????????? return key; >>> ??????????? } >>> ??????????? ECPrivateKey ecKey = (ECPrivateKey)key; >>> ??????????? return new ECPrivateKeyImpl( >>> ??????????????? ecKey.getS(), >>> ??????????????? ecKey.getParams() >>> ??????????? ); >>> ??????? } else if ("PKCS#8".equals(key.getFormat())) { >>> ??????????? return new ECPrivateKeyImpl(key.getEncoded()); >>> ??????? } else { >>> ??????????? throw new InvalidKeyException("Private keys must be >>> instance " >>> ??????????????? + "of ECPrivateKey or have PKCS#8 encoding"); >>> ??????? } >> > > The code above could be improved by using the PKCS#8 encoding when > getS() returns null. So implementing your provider requires other providers to change? Because??? Do you expect BouncyCastle and NSS to change as well? E.g.? This gets called by KeyFactorySpi.engineTranslateKey for bouncycastle: > ??? public BCECPrivateKey( > ??????? ECPrivateKey key, > ??????? ProviderConfiguration configuration) > ??? { > ??????? this.d = key.getS(); > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > ??????? this.algorithm = key.getAlgorithm(); > ??????? this.ecSpec = key.getParams(); > ??????? this.configuration = configuration; > ??? } > > The only way to get private keys in or out of the new provider is > through a PKCS#8 encoding. Moving keys to/from another provider that > supports ECPrivateKeySpec but not PKCS#8 encoding can be accomplished > by translating the specs---possibly with the help of a KeyFactory that > supports both, like the one in SunEC. > *pounds head against table*?? Bits are bits are bits.? Creating a PKCS8EncodedKeySpec gets you a byte array which you can convert to a BigInteger by decoding the PKCS8 structure and taking the PKCS8 PrivateKey octets and doing new BigInteger (1, privateKeyOctets). That doesn't require ASN1 integer representation (e.g. leading byte is zero if high bit is set) and doesn't cause a branch. In any event, if I'm copying things out of NewEC then I'm responsible for any of the interface weirdness with respect to timing attacks. Later, Mike From mstjohns at comcast.net Wed Sep 5 20:49:02 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 5 Sep 2018 16:49:02 -0400 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> Message-ID: <68fff06c-c161-0930-f7bb-58a7b794a98a@comcast.net> On 9/4/2018 9:59 PM, Valerie Peng wrote: > These sun.security.pkcs11.wrapper classes are internal and subject to > changes without notice. No arguments there.? But that interface has been stable since the initial contribution and to be blunt - the PKCS11 provider only works well if you use the keys you created through the provider. There's a set of idiosyncratic choices for how to map keys to certs to keys that make keys created by non-provider calls (e.g. C code or other non-java libs) to the token difficult to use through the provider and vice versa.? That led to us using the wrapper classes directly. Maybe its time to provide a PKCS11AttributeSpec? of some sort for key creation and for looking things up?? The current model is literally 12-15 years old AFAICT. > > For the time being, maybe we can leave these method intact and add a > comment about calling the new methods which use P11Key argument > instead of the key handle argument. That should work.? You may want to think about deprecating those methods and target removing them for a later release in a couple of years. Thanks - Mike > > Regards, > Valerie > > On 9/1/2018 11:18 AM, Michael StJohns wrote: >> Hi Valerie - >> >> I may be speaking only for myself, but there are probably a number of >> folk using sun.security.pkcs11.wrapper.* in lieu of the PKCS11 >> provider for a number of reasons including an ability to manage the >> key storage and wrapping efficiently. Looking at this I'm thinking >> there will be a large number of things breaking because of the way >> you refactored things. >> >> While I understand that none of the sun.security.* classes are >> "public" - these were mostly taken directly from the IAIK >> contribution way back when and the folks I worked with used them in >> lieu of external libraries to have a consistent PKCS11 interface >> java-to-java. >> >> Perhaps instead you'd consider doing something like leaving the Java >> to Native public methods intact? >> >> Mike >> >> >> >> >> On 8/31/2018 7:53 PM, Valerie Peng wrote: >>> >>> Hi Martin, >>> >>> With the new model of "creating the key handle as needed", I think >>> we should not allow the direct access of keyID field outside of >>> P11Key class. This field should be made private and accessed through >>> methods. In addition, existing PKCS11.C_XXX() methods with P11 keyID >>> arguments can be made private and we can add wrapper methods with >>> P11Key object argument to ensure proper usage of the P11Key object >>> and its keyID field. >>> >>> I have also refactored the keyID management code into a separate >>> holder class. The prototype code can be found at: >>> http://cr.openjdk.java.net/~valeriep/6913047Exp/webrev.00/ >>> >>> The main changes that I made are in P11Key.java and PKCS11.java. The >>> other java classes are updated to call the wrapper methods in >>> PKCS11.java. >>> >>> Thanks & have a great Labor day weekend, >>> >>> Valerie >>> >>> >>> On 8/16/2018 5:28 PM, Valerie Peng wrote: >>>> >>>> Hi Martin, >>>> >>>> >>>> Since there is no regression test for this test, you will need to >>>> add a "noreg-xxx" label to the bug record. For this issue, it'll >>>> probably be "noreg-hard". >>>> >>>> To understand the changes better, please find my questions and some >>>> review comments below: >>>> >>>> >>>> - line 397: It's incorrect to change initialize() to >>>> ensureInitialized(). If the cipher object were to be initialized >>>> twice with two different keys, you need to re-initialize again. >>>> - line 471: Why do you change it to Throwable from PKCS11Exception? >>>> >>>> >>>> - line 99: comment is somewhat unclear. typo: "temporal" should be >>>> "temporary". >>>> - line 148-149: JDK-8165996 has been fixed. This does not apply >>>> now, does it? >>>> - You changed the constructors of all the P11Key-related classes to >>>> take an additional boolean argument "tmpNativeKey". However, this >>>> boolean argument is only used when the underlying token is "NSS". >>>> Why limiting to NSS only? It seems that all callers except for >>>> PKCS11 KeyStore pass true for "tmpNativeKey". When "tmpNativeKey" >>>> is true, the keyID handle first destroyed in constructor and later >>>> created again (ref count == 1) and destroyed (when ref count drops >>>> to 0). This replaced the PhantomReference approach in SessionKeyRef >>>> class, right? Now both approaches seem to be used and key >>>> destruction is taking places at different methods. I think we >>>> should clarify the cleanup model and perhaps refactor the code so >>>> it's easier which approach is in use. Or grouping all these >>>> cleanup-related fields/variables into a separate class for >>>> readability/clarity. >>>> - line 157-175: nativeKeyWrapperKeyID is a static variable, >>>> shouldn't it be synchronized on a class level object? >>>> - line 1343: the impl doesn't look right. Why do you call both >>>> removeObject() and addObject() here with the same check? >>>> - line 1363: the change seems incorrect, you should still call >>>> session.removeObject(). the call setKeyIDAndSession(0, null) does >>>> not lower the session object count. >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 8/7/2018 5:41 PM, Valerie Peng wrote: >>>>> >>>>> Hi Martin, >>>>> >>>>> Thanks for the update, I will resume the review on this one with >>>>> your latest webrev. >>>>> >>>>> BTW, there is no webrev.07 for your other fix, i.e. JDK-8029661, >>>>> right? Just checking. >>>>> >>>>> Regards, >>>>> Valerie >>>>> >>>>> On 8/3/2018 2:13 PM, Martin Balao wrote: >>>>>> Hi Valerie, >>>>>> >>>>>> ?* >>>>>> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10/ >>>>>> >>>>>> ?* >>>>>> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10.zip >>>>>> >>>>>> >>>>>> New in webrev 10: >>>>>> >>>>>> ?* Bug fix when private DSA/EC keys are sensitive >>>>>> ? * I found this bug removing "attributes = compatibility" entry >>>>>> in NSS configuration file so keys were CKA_SENSITIVE. >>>>>> ? * This is really an NSS bug when unwrapping ephemeral keys >>>>>> (NSC_UnwrapKey function), because CKA_NETSCAPE_DB attribute is >>>>>> required but not used/needed. There was a similar bug when >>>>>> creating objects (NSC_CreateObject function), fixed many years >>>>>> ago [1]. >>>>>> ? * In those cases in which the bug occurs (private keys, of >>>>>> DSA/EC type, sensitive and without CKA_NETSCAPE_DB attribute >>>>>> set), I store an empty CKA_NETSCAPE_DB attribute in the buffer >>>>>> that will later be used for key unwrapping. I'm not doing a >>>>>> C_SetAttributeValue call because keys are read-only. We can let >>>>>> users set CKA_NETSCAPE_DB attribute in NSS configuration file [2] >>>>>> but this would be a workaround on users side. >>>>>> ? * Changes in: >>>>>> ? ?* p11_keymgmt.c >>>>>> ? ? * L175-187, L212-214 and L275-278 >>>>>> >>>>>> ?* Bug fix when storing sensitive RSA keys in a keystore >>>>>> ? * CKA_NETSCAPE_DB attribute is not needed so we return it as >>>>>> null (instead of failing with an "Invalid algorithm" message) >>>>>> ? * Changes in: >>>>>> ? ?* P11KeyStore.java >>>>>> ? ? * L1909-1914 >>>>>> >>>>>> ?* Lines length was cut to improve code readability >>>>>> >>>>>> Regression tests on jdk/sun/security/pkcs11 category passed. I >>>>>> ran my internal test suite too, that covers the following >>>>>> services (with SunPKCS11 provider): Cipher, Signature, >>>>>> KeyAgreement, Digest, Mac, KeyGenerator, KeyPairGenerator and >>>>>> Keystore. >>>>>> >>>>>> Kind regards, >>>>>> Martin.- >>>>>> >>>>>> -- >>>>>> [1] - https://bugzilla.mozilla.org/show_bug.cgi?id=309701#c6 >>>>>> >>>>>> [2] - >>>>>> https://alvinalexander.com/java/jwarehouse/openjdk-8/jdk/test/sun/security/pkcs11/fips/fips.cfg.shtml >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajan.halade at oracle.com Wed Sep 5 22:33:35 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 5 Sep 2018 15:33:35 -0700 Subject: RFR: 8210432: Add additional TeliaSonera root certificate Message-ID: <925a0a48-ede3-0471-776c-69404ca60a96@oracle.com> Please review this fix to add new TeliaSonera root certificate to the cacert store. Webrev: http://cr.openjdk.java.net/~rhalade/8210432/webrev.00/ Thanks, Rajan From sean.mullan at oracle.com Thu Sep 6 00:59:28 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 5 Sep 2018 20:59:28 -0400 Subject: RFR: 8210432: Add additional TeliaSonera root certificate In-Reply-To: <925a0a48-ede3-0471-776c-69404ca60a96@oracle.com> References: <925a0a48-ede3-0471-776c-69404ca60a96@oracle.com> Message-ID: <1576970a-9834-5b45-175c-e9380b9f6de4@oracle.com> Looks good. --Sean On 9/5/18 6:33 PM, Rajan Halade wrote: > Please review this fix to add new TeliaSonera root certificate to the > cacert store. > > Webrev: http://cr.openjdk.java.net/~rhalade/8210432/webrev.00/ > > Thanks, > Rajan From jamil.j.nimeh at oracle.com Thu Sep 6 04:51:47 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 5 Sep 2018 21:51:47 -0700 Subject: RFR: JDK-8140466: ChaCha20-Poly1305 TLS cipher suites Message-ID: <2462efde-95f6-b244-873b-bcde43312799@oracle.com> Hello all, This change will add ChaCha20-Poly1305 cipher suites to our TLS 1.2 and TLS 1.3 implementations.? A few test cases had to be updated to reflect the new suites as well. JBS: https://bugs.openjdk.java.net/browse/JDK-8140466 CSR: https://bugs.openjdk.java.net/browse/JDK-8204192 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8140466/webrev.01/ Thanks, --Jamil From adam.petcher at oracle.com Thu Sep 6 13:53:22 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 6 Sep 2018 09:53:22 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <1c957616-cd36-1cc8-9257-fad9a3dcb0a6@oracle.com> <77ab28a5-8b14-db97-941e-7d3783a4f4c9@oracle.com> <79b68c86-e5ad-f4a2-7cf5-5edfdc46a906@comcast.net> Message-ID: On 9/5/2018 5:53 PM, Michael StJohns wrote: > > BigInteger is not required to encode a PKCS8 key, but its trivial to > translate from BigInteger to PKCS8 and vice versa.? Note that > internally, the current BigInteger stores the magnitude as an array of > int in big endian order and stores the sign separately. The BigInteger > (int sigNum, byte[] magnitude) constructor mostly just copies the > magnitude bytes over (and converts 4 bytes to an integer) for positive > integers. ? While the current BigInteger doesn't have a byte[] > BigInteger.getMagnitude() call, it would be trivial to subclass > BigInteger to copy the magnitude bytes (without branching) out. > > In any event, for NewEC to OldEc - you do use the sign/magnitude call > to create the BigInteger - no leaking on the part of NewEC, and once > it gets to OldEC its not your problem.? For OldEc to NewEc you copy > the BigInteger to NewBigInteger (trivial wrapper class) and do a > getMagnitude(). See the code for BigInteger[1]. The sign/magnitude constructor calls stripLeadingZeroBytes (line 405) on the magnitude to convert it to an int array. This method compares the leading values in the byte array to zero in a short-circuit expression in a for loop (line 4298). So this constructor branches on the value that is supplied to it, and it cannot be used in a branchless implementation. I don't know how to write this branchless getMagnitude method that you are proposing. I would need to convert from a variable-length int array to a fixed-length byte array. In doing this, I can't branch on the length of the variable-length array, because doing so would leak whether the high-order bits of the key are zero. If you know how to do this, then please provide some code to illustrate how it is done. [1] http://hg.openjdk.java.net/jdk/jdk/file/805807f15830/src/java.base/share/classes/java/math/BigInteger.java > While the contract for getEncoded() explicitly allows for a null > result, getS() of ECPrivateKey does not.??? This more than any other > reason appears to be why the PKCS 11 provider represents the > ECPrivateKey as a simple PrivateKey object. Good point. There is no need for the private keys for this provider to implement ECPrivateKey, since there is only one method that is effectively unimplemented. We should use a new implementation class (not ECPrivateKeyImpl) that implements PrivateKey, not ECPrivateKey. > So implementing your provider requires other providers to change? > Because??? Do you expect BouncyCastle and NSS to change as well? I think the situation is improved by not having the new private keys implement ECPrivateKey. Then the JDK ECKeyFactory code does not need to change, and neither do other providers, assuming they behave in a similar way. Though I think it is acceptable if other providers don't behave this way, and therefore cannot translate private keys from this new provider. I've updated the JEP to indicate that interoperability with these providers is a non-goal. > >> >> The only way to get private keys in or out of the new provider is >> through a PKCS#8 encoding. Moving keys to/from another provider that >> supports ECPrivateKeySpec but not PKCS#8 encoding can be accomplished >> by translating the specs---possibly with the help of a KeyFactory >> that supports both, like the one in SunEC. >> > *pounds head against table*?? Bits are bits are bits.? Creating a > PKCS8EncodedKeySpec gets you a byte array which you can convert to a > BigInteger by decoding the PKCS8 structure and taking the PKCS8 > PrivateKey octets and doing new BigInteger (1, privateKeyOctets). > > That doesn't require ASN1 integer representation (e.g. leading byte is > zero if high bit is set) and doesn't cause a branch. See above for my explanation of why this solution does, in fact, branch. From xuelei.fan at oracle.com Thu Sep 6 16:10:16 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 6 Sep 2018 09:10:16 -0700 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> Message-ID: <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> On 9/5/2018 12:49 PM, Adam Petcher wrote: > New webrev: http://cr.openjdk.java.net/~apetcher/8171279/webrev.02/ > > On 9/5/2018 1:35 PM, Xuelei Fan wrote: > >> On 9/5/2018 10:09 AM, Adam Petcher wrote: >> >>> Is there some place in the code where JSSE is doing something too >>> complicated related to these parameters? >>> >> Yes, the algorithm name is sufficient, I'm not sure the necessary to >> use XECParameters in sun.security.util. > > The algorithm name is not quite sufficient. See the new methods that > were added to ECUtil that encode/decode public keys. We also need to > know the key length (which is in XECParameters) in order to > encode/decode public keys. > I did not get your point. The public key sizes for x25519 and x448 are fixed, right? >> >>> >>> I simply continued the pattern that was used in DH and ECDH. We can >>> use a different string here, but I worry that people will be >>> surprised if DH and ECDH support "TlsPreMasterSecret" but XDH doesn't. >> It could support "TlsPreMasterSecret", right?? My concern is about not >> limited to this one only. > > Yes, it supports "TlsPreMasterSecret" in the webrev now. Perhaps I'm not > sure what you are suggesting here. > OKay, let me say it in another way. Thank you for making it works with the SunJSSE provider as you use a SunJSSE provider private algorithm name "TlsPreMasterSecret", and implement the algorithm in the cyrpto provider. That's good. The "TlsPreMasterSecret" is not a public one, and it is not expected to be used in other JSSE provider. If I want to implement a JSSE provider by myself, and I use the name "x25519", the crypto provider will deny it. So I have to use the "TlsPreMasterSecret" for my provider. However, the name is not supported, and the name can be changed at anytime in the future. How should I do to use the crypto provider for my JSSE provider? Looks like no way to use the JDK cyrpto provider unless I use the SunJSSE private name. Should I implement my own crypto provider? I don't want to do that unless it is really necessary. For the KeyAgreement.generateSecret?(String algorithm) method, it seems that the supported algorithms of each provider are missed in the documentation. As may make the method hard to use. This issue is not specific to XDH. I'm fine if you don't want to address it in this update. >> >>>> >>>> 3. NamedGroupFunctions >>>> It might be more straightforward to define these functions in >>>> NamedGroup.? If comparing >>>> nameGroup.getFunctions().getParameterSpec() and >>>> namedGroup.getParameterSpec(), I'd prefer the latter. >>> >>> A simple way to accomplish this is to leave the structure alone and >>> add methods in NamedGroup that pass through to the corresponding >>> methods in NamedGroupFunctions. I made this change in the updated >>> webrev. Let me know what you think. >>> >> It looks like a problem to me to use this before it constructed. >> ??? this.functions = new ECDHFunctions(this); >> >> and the use of new object for each named group is not effective. The >> current NamedGroupFunctions abstract class does not sound good enough >> to me, considering the numbers of the named groups. >> >> I have no idea so far, but I think you can improve it.? Probably use >> static methods? > > In the latest webrev, I changed it so there is a single static > NamedGroupFunctions of each type, and the NamedGroup is passed in as the > first argument to each method that requires it (rather than being a > member of NamedGroupFunctions). > After the re-org, I guess you can put the inner classes in NamedGroup enum and declare them as private? The getFunctions() method may be unnecessary then. Thanks, Xuelei From adam.petcher at oracle.com Thu Sep 6 17:04:20 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 6 Sep 2018 13:04:20 -0400 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> Message-ID: On 9/6/2018 12:10 PM, Xuelei Fan wrote: >> The algorithm name is not quite sufficient. See the new methods that >> were added to ECUtil that encode/decode public keys. We also need to >> know the key length (which is in XECParameters) in order to >> encode/decode public keys. >> > I did not get your point.? The public key sizes for x25519 and x448 > are fixed, right? Yes, the key sizes are fixed. All we need in ECUtil is a mapping from curve name to this (fixed) size. Are you suggesting some other solution, other than using the XECParameters to map curve names to key sizes? > >> >> Yes, it supports "TlsPreMasterSecret" in the webrev now. Perhaps I'm >> not sure what you are suggesting here. >> > OKay, let me say it in another way. > > Thank you for making it works with the SunJSSE provider as you use a > SunJSSE provider private algorithm name "TlsPreMasterSecret", and > implement the algorithm in the cyrpto provider.? That's good. > > The "TlsPreMasterSecret" is not a public one, and it is not expected > to be used in other JSSE provider.? If I want to implement a JSSE > provider by myself, and I use the name "x25519", the crypto provider > will deny it.? So I have to use the "TlsPreMasterSecret" for my > provider. However, the name is not supported, and the name can be > changed at anytime in the future. How should I do to use the crypto > provider for my JSSE provider? Looks like no way to use the JDK cyrpto > provider unless I use the SunJSSE private name.? Should I implement my > own crypto provider? I don't want to do that unless it is really > necessary. > > For the KeyAgreement.generateSecret?(String algorithm) method, it > seems that the supported algorithms of each provider are missed in the > documentation.? As may make the method hard to use. > > This issue is not specific to XDH.? I'm fine if you don't want to > address it in this update. I agree that this is an issue, but I think it is out of scope for this ticket. There are several tickets[1,2] related to the issues associated with generateSecret, we just need to find the time to work on them. Continuing work on the KeyDerivation JEP[3] may also help with all of this. [1] https://bugs.openjdk.java.net/browse/JDK-8189441 [2] https://bugs.openjdk.java.net/browse/JDK-6791936 [3] https://bugs.openjdk.java.net/browse/JDK-8189808 > >> >> In the latest webrev, I changed it so there is a single static >> NamedGroupFunctions of each type, and the NamedGroup is passed in as >> the first argument to each method that requires it (rather than being >> a member of NamedGroupFunctions). >> > After the re-org, I guess you can put the inner classes in NamedGroup > enum and declare them as private?? The getFunctions() method may be > unnecessary then. I don't know if that works, exactly, due to the fact that I can't reference static enum members in the body of an enum constructor. How about this alternative? I can move the NamedGroup enum and all the NamedGroupFunction classes into a separate class (in a separate file) called NamedGroups. Then all the NamedGroupFunction classes can be private in this class, but the NamedGroup enum can still have package access. I would prefer to leave the getFunctions() method of NamedGroup (and keep it private) because the functions object may be missing and the Optional return type of getFunctions() forces me to deal with this when I call it from within NamedGroup. From adam.petcher at oracle.com Thu Sep 6 17:17:44 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 6 Sep 2018 13:17:44 -0400 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> Message-ID: <805f9005-eda5-522e-f215-7999544b3faf@oracle.com> Minor correction below. On 9/6/2018 1:04 PM, Adam Petcher wrote: > >> >>> >>> In the latest webrev, I changed it so there is a single static >>> NamedGroupFunctions of each type, and the NamedGroup is passed in as >>> the first argument to each method that requires it (rather than >>> being a member of NamedGroupFunctions). >>> >> After the re-org, I guess you can put the inner classes in NamedGroup >> enum and declare them as private?? The getFunctions() method may be >> unnecessary then. > > I don't know if that works, exactly, due to the fact that I can't > reference static enum members in the body of an enum constructor. How > about this alternative? I can move the NamedGroup enum and all the > NamedGroupFunction classes into a separate class (in a separate file) > called NamedGroups. Then all the NamedGroupFunction classes can be > private in this class, but the NamedGroup enum can still have package > access. I would prefer to leave the getFunctions() method of > NamedGroup (and keep it private) because the functions object may be > missing and the Optional return type of getFunctions() forces me to > deal with this when I call it from within NamedGroup. > > Actually, it does work. I just have to move the static members of each NamedGroupFunctions subclass into its subclass (e.g. make them singletons). Still, I like my proposed alternative better, because it allows us to simplify SupportedGroupsExtension. Let me know if you have a preference. From xuelei.fan at oracle.com Thu Sep 6 17:55:02 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 6 Sep 2018 10:55:02 -0700 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> Message-ID: On 9/6/2018 10:04 AM, Adam Petcher wrote: > On 9/6/2018 12:10 PM, Xuelei Fan wrote: > >>> The algorithm name is not quite sufficient. See the new methods that >>> were added to ECUtil that encode/decode public keys. We also need to >>> know the key length (which is in XECParameters) in order to >>> encode/decode public keys. >>> >> I did not get your point.? The public key sizes for x25519 and x448 >> are fixed, right? > > Yes, the key sizes are fixed. All we need in ECUtil is a mapping from > curve name to this (fixed) size. Are you suggesting some other solution, > other than using the XECParameters to map curve names to key sizes? Using name only (NamedParameterSpec?) and have the JCE provider handle it, then you don't need to move XECParameters into java.base module. Xuelei From xuelei.fan at oracle.com Thu Sep 6 18:47:30 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 6 Sep 2018 11:47:30 -0700 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: <805f9005-eda5-522e-f215-7999544b3faf@oracle.com> References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <805f9005-eda5-522e-f215-7999544b3faf@oracle.com> Message-ID: <97e318af-f6c5-485a-39f8-b9a1ff0d6db1@oracle.com> On 9/6/2018 10:17 AM, Adam Petcher wrote: >>>> >>>> In the latest webrev, I changed it so there is a single static >>>> NamedGroupFunctions of each type, and the NamedGroup is passed in as >>>> the first argument to each method that requires it (rather than >>>> being a member of NamedGroupFunctions). >>>> >>> After the re-org, I guess you can put the inner classes in NamedGroup >>> enum and declare them as private?? The getFunctions() method may be >>> unnecessary then. >> >> I don't know if that works, exactly, due to the fact that I can't >> reference static enum members in the body of an enum constructor. How >> about this alternative? I can move the NamedGroup enum and all the >> NamedGroupFunction classes into a separate class (in a separate file) >> called NamedGroups. Then all the NamedGroupFunction classes can be >> private in this class, but the NamedGroup enum can still have package >> access. I would prefer to leave the getFunctions() method of >> NamedGroup (and keep it private) because the functions object may be >> missing and the Optional return type of getFunctions() forces me to >> deal with this when I call it from within NamedGroup. >> I think it should be able to use the "functions" field directly. Optional ngf = getFunctions() if (ngf.isEmpty() { ... } V.S. if (functions != null) { ... } I did not see the benefits of the getFunctions() method. >> > Actually, it does work. I just have to move the static members of each > NamedGroupFunctions subclass into its subclass (e.g. make them > singletons). Still, I like my proposed alternative better, because it > allows us to simplify SupportedGroupsExtension. Let me know if you have > a preference. My concerns are mainly about: 1. the NamedGroupFunctions should be private and should not be used other than the NamedGroup enum impl. 2. the ffdh/ecdh/xdhFunctions static fields should be private of the NamedGroup enum as well, and better be lazy instantiated as you are using Map objects in the NamedGroupFunctions implementation (for performance). 3. NamedGroupFunctions.namedGroupParams is fine in general, but in this context, it means the map will always be generated. We used to use a SupportedGroups to wrap and cache the parameters, and don't care about the unsupported groups. But in the new re-org, looks like the unsupported groups may also have a chance to cache/use the parameters. #3 is a new find when I'm trying to understand your proposal. It would be nice if you could think about the SupportedGroups impact. For the question about how it works, there are a few approaches. You can use singletons as you said or inner enum (See CipherSuite.java). Xuelei From adam.petcher at oracle.com Thu Sep 6 19:13:05 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 6 Sep 2018 15:13:05 -0400 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> Message-ID: <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> On 9/6/2018 1:55 PM, Xuelei Fan wrote: >> Yes, the key sizes are fixed. All we need in ECUtil is a mapping from >> curve name to this (fixed) size. Are you suggesting some other >> solution, other than using the XECParameters to map curve names to >> key sizes? > Using name only (NamedParameterSpec?) and have the JCE provider handle > it, then you don't need to move XECParameters into java.base module. > Do you have a specific suggestion on how I can do that? I don't think there is anything in the JCE API for XDH that allows a lookup from name to key length. Are you proposing that I enhance the public API to avoid using XECParameters here? Also, why do you object to having XECParameters in java.base? Most of the crypto code is in java.base, including similar classes like ECParameters and CurveDB. I admit that it is unfortunate that XECParameters is used directly here, instead of going over JCE---is that what you object to? From xuelei.fan at oracle.com Thu Sep 6 19:19:16 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 6 Sep 2018 12:19:16 -0700 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> Message-ID: I think I suggested to use NamedParameterSpec, which is a public API. NamedParameterSpec -> name "x25519" -> key size is the key size of x25519. Please let me know if the logic is wrong. > Also, why do you object to having XECParameters in java.base? Please read my previous comments. > ... similar classes like ECParameters and CurveDB. Previously, there is no NamedParameterSpec, so we have to workaround to use ECParameters. Now, we don't have to do the ugly thing any more if I did not miss something. Thanks, Xuelei On 9/6/2018 12:13 PM, Adam Petcher wrote: > On 9/6/2018 1:55 PM, Xuelei Fan wrote: > >>> Yes, the key sizes are fixed. All we need in ECUtil is a mapping from >>> curve name to this (fixed) size. Are you suggesting some other >>> solution, other than using the XECParameters to map curve names to >>> key sizes? >> Using name only (NamedParameterSpec?) and have the JCE provider handle >> it, then you don't need to move XECParameters into java.base module. >> > Do you have a specific suggestion on how I can do that? I don't think > there is anything in the JCE API for XDH that allows a lookup from name > to key length. Are you proposing that I enhance the public API to avoid > using XECParameters here? > > Also, why do you object to having XECParameters in java.base? Most of > the crypto code is in java.base, including similar classes like > ECParameters and CurveDB. I admit that it is unfortunate that > XECParameters is used directly here, instead of going over JCE---is that > what you object to? > From sean.mullan at oracle.com Thu Sep 6 19:29:12 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 6 Sep 2018 15:29:12 -0400 Subject: RFR (JDK 12): 6899533: SecureClassLoader and URLClassLoader have unnecessary check for createClassLoader permission Message-ID: Please review this change to remove code that is no longer necessary now that pre-JDK 1.2 SecurityManager methods are no longer supported [1]. In addition, the initialized flag and associated code has been removed from SecureClassLoader as this was only necessary to prevent finalizer attacks prior to JDK 6. webrev: http://cr.openjdk.java.net/~mullan/webrevs/6899533/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-6899533 --Sean [1] https://bugs.openjdk.java.net/browse/JDK-8189750 From mandy.chung at oracle.com Thu Sep 6 20:22:55 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 6 Sep 2018 13:22:55 -0700 Subject: RFR (JDK 12): 6899533: SecureClassLoader and URLClassLoader have unnecessary check for createClassLoader permission In-Reply-To: References: Message-ID: <04d210cb-037f-2e62-1761-8d41995a2c15@oracle.com> On 9/6/18 12:29 PM, Sean Mullan wrote: > Please review this change to remove code that is no longer necessary > now that pre-JDK 1.2 SecurityManager methods are no longer supported > [1]. In addition, the initialized flag and associated code has been > removed from SecureClassLoader as this was only necessary to prevent > finalizer attacks prior to JDK 6. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/6899533/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-6899533 Looks good.? Happy to see this is cleaned up. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Thu Sep 6 20:43:16 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 6 Sep 2018 16:43:16 -0400 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> Message-ID: <486a8d33-f4d6-8bcd-3123-3b4b3ef411df@oracle.com> On 9/6/2018 3:19 PM, Xuelei Fan wrote: > I think I suggested to use NamedParameterSpec, which is a public API. > > ?? NamedParameterSpec -> name "x25519" > ?????? -> key size is the key size of x25519. > > Please let me know if the logic is wrong. It's that last arrow that I still don't get. How does this code figure out that "X25519" -> 255 and "X448" -> 448? Perhaps you can reply with some code to illustrate how you think this should work. From xuelei.fan at oracle.com Thu Sep 6 20:49:52 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 6 Sep 2018 13:49:52 -0700 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: <486a8d33-f4d6-8bcd-3123-3b4b3ef411df@oracle.com> References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> <486a8d33-f4d6-8bcd-3123-3b4b3ef411df@oracle.com> Message-ID: <7589d254-7e2c-1b63-1d3e-10d74cbf4684@oracle.com> I asked the question in a previous email. The key size for x25529 is fixed, right? If it is not right, stop here and tell me that it is not right. Keep reading if it is right. OK, as the key size for x25519 is fixed, when you know the algorithm is x25519, you know the key size. Does it sound right to you? If it is not right, stop here and tell me that it is not right. Otherwise, keep reading. From the name you know the key size, when you create a NamedParameterSpec object for "x25519", you know the name and key size from the object, right? Let's look at the x25519 case at first. If we figure it out, we then can look into the x488. Thanks, Xuelei On 9/6/2018 1:43 PM, Adam Petcher wrote: > On 9/6/2018 3:19 PM, Xuelei Fan wrote: > >> I think I suggested to use NamedParameterSpec, which is a public API. >> >> ?? NamedParameterSpec -> name "x25519" >> ?????? -> key size is the key size of x25519. >> >> Please let me know if the logic is wrong. > > It's that last arrow that I still don't get. How does this code figure > out that "X25519" -> 255 and "X448" -> 448? Perhaps you can reply with > some code to illustrate how you think this should work. > > > From xuelei.fan at oracle.com Thu Sep 6 21:31:28 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 6 Sep 2018 14:31:28 -0700 Subject: RFR: JDK-8140466: ChaCha20-Poly1305 TLS cipher suites In-Reply-To: <2462efde-95f6-b244-873b-bcde43312799@oracle.com> References: <2462efde-95f6-b244-873b-bcde43312799@oracle.com> Message-ID: <259c957a-93fd-533e-84f8-d9b2411012bf@oracle.com> SSLCipher.java -------------- line 2159-2164 in the update vs line 1992-1997 in the old file. The new code is fine, but it takes me a while to analysis the code, and comparing with the old one. Maybe, we can use the same implementation code for the same logic for maintenance? Just a very personal preference. You make the final choice. If you accept it, please consider other places that compute the nonce value. 2180 sequence); 'sn' should be used here. The 'sequence' variable may be different from the one used for the cipher. Otherwise, looks fine to me. Thanks, Xuelei On 9/5/2018 9:51 PM, Jamil Nimeh wrote: > Hello all, > This change will add ChaCha20-Poly1305 cipher suites to our TLS 1.2 and > TLS 1.3 implementations.? A few test cases had to be updated to reflect > the new suites as well. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8140466 > CSR: https://bugs.openjdk.java.net/browse/JDK-8204192 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8140466/webrev.01/ > > Thanks, > --Jamil From jamil.j.nimeh at oracle.com Fri Sep 7 00:02:19 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 6 Sep 2018 17:02:19 -0700 Subject: RFR: JDK-8140466: ChaCha20-Poly1305 TLS cipher suites In-Reply-To: <259c957a-93fd-533e-84f8-d9b2411012bf@oracle.com> References: <2462efde-95f6-b244-873b-bcde43312799@oracle.com> <259c957a-93fd-533e-84f8-d9b2411012bf@oracle.com> Message-ID: <9be40d26-09aa-5538-07ea-078e63e8496d@oracle.com> Hi Xuelei, thank you for the comments - my replies are in-line: On 9/6/2018 2:31 PM, Xuelei Fan wrote: > SSLCipher.java > -------------- > line 2159-2164 in the update vs line 1992-1997 in the old file. > > The new code is fine, but it takes me a while to analysis the code, > and comparing with the old one.? Maybe, we can use the same > implementation code for the same logic for maintenance??? Just a very > personal preference.? You make the final choice.? If you accept it, > please consider other places that compute the nonce value. Respectfully, I think the way the AES-GCM code sets up the cipher doesn't match very well with how ChaCha20 does it.? Even the RFC itself says that the nonce construction is different.? There's no per-record nonce_explicit and it's really just a padded sequence number XORed with the client or server read/write IV.? I think the current code follows the procedure in 7905 closely.? Taking the GCM construction will muddy it a bit, since things like recordIvSize get brought in...for CC20 that's always zero, so why have it at all?? It just clutters things IMO. > > 2180?? sequence); > 'sn' should be used here.? The 'sequence' variable may be different > from the one used for the cipher. Oh!? Good catch.? I will fix this. > > Otherwise, looks fine to me. > Thanks Xuelei, much appreciated, --Jamil > Thanks, > Xuelei > > On 9/5/2018 9:51 PM, Jamil Nimeh wrote: >> Hello all, >> This change will add ChaCha20-Poly1305 cipher suites to our TLS 1.2 >> and TLS 1.3 implementations.? A few test cases had to be updated to >> reflect the new suites as well. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8140466 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8204192 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8140466/webrev.01/ >> >> Thanks, >> --Jamil From Xuelei.Fan at Oracle.Com Fri Sep 7 00:08:27 2018 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Thu, 6 Sep 2018 17:08:27 -0700 Subject: RFR: JDK-8140466: ChaCha20-Poly1305 TLS cipher suites In-Reply-To: <9be40d26-09aa-5538-07ea-078e63e8496d@oracle.com> References: <2462efde-95f6-b244-873b-bcde43312799@oracle.com> <259c957a-93fd-533e-84f8-d9b2411012bf@oracle.com> <9be40d26-09aa-5538-07ea-078e63e8496d@oracle.com> Message-ID: > On Sep 6, 2018, at 5:02 PM, Jamil Nimeh wrote: > > Hi Xuelei, thank you for the comments - my replies are in-line: > >> On 9/6/2018 2:31 PM, Xuelei Fan wrote: >> SSLCipher.java >> -------------- >> line 2159-2164 in the update vs line 1992-1997 in the old file. >> >> The new code is fine, but it takes me a while to analysis the code, and comparing with the old one. Maybe, we can use the same implementation code for the same logic for maintenance? Just a very personal preference. You make the final choice. If you accept it, please consider other places that compute the nonce value. > Respectfully, I think the way the AES-GCM code sets up the cipher doesn't match very well with how ChaCha20 does it. Even the RFC itself says that the nonce construction is different. There's no per-record nonce_explicit and it's really just a padded sequence number XORed with the client or server read/write IV. I think the current code follows the procedure in 7905 closely. This is a sound reason to me. Okay, keep it. Xuelei > Taking the GCM construction will muddy it a bit, since things like recordIvSize get brought in...for CC20 that's always zero, so why have it at all? It just clutters things IMO. > >> >> 2180 sequence); >> 'sn' should be used here. The 'sequence' variable may be different from the one used for the cipher. > Oh! Good catch. I will fix this. >> >> Otherwise, looks fine to me. >> > Thanks Xuelei, much appreciated, > --Jamil > >> Thanks, >> Xuelei >> >>> On 9/5/2018 9:51 PM, Jamil Nimeh wrote: >>> Hello all, >>> This change will add ChaCha20-Poly1305 cipher suites to our TLS 1.2 and TLS 1.3 implementations. A few test cases had to be updated to reflect the new suites as well. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8140466 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8204192 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8140466/webrev.01/ >>> >>> Thanks, >>> --Jamil > From adam.petcher at oracle.com Fri Sep 7 12:49:52 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 7 Sep 2018 08:49:52 -0400 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: <7589d254-7e2c-1b63-1d3e-10d74cbf4684@oracle.com> References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> <486a8d33-f4d6-8bcd-3123-3b4b3ef411df@oracle.com> <7589d254-7e2c-1b63-1d3e-10d74cbf4684@oracle.com> Message-ID: On 9/6/2018 4:49 PM, Xuelei Fan wrote: > I asked the question in a previous email.? The key size for x25529 is > fixed, right? Right. > > If it is not right, stop here and tell me that it is not right. Keep > reading if it is right. > > OK, as the key size for x25519 is fixed, when you know the algorithm > is x25519, you know the key size.? Does it sound right to you? Possibly right---it depends on what you mean by "know". If all you have is the name, then you need use a static mapping to look up the key length. > > If it is not right, stop here and tell me that it is not right. > Otherwise, keep reading. > > From the name you know the key size, when you create a > NamedParameterSpec object for "x25519", you know the name and key size > from the object, right? The NamedParameterSpec object holds the name only, and not the key size. We create the NamedParameterSpec from the algorithm name in the NamedGroup enum, which also doesn't have the key size. Are you suggesting that I add the key size to this enum as well? Like this: ??????? // x25519 and x448 ??????? X25519????? (0x001D, "x25519", true, "x25519", 255, ??????????????????????????? ProtocolVersion.PROTOCOLS_TO_13), ??????? X448??????? (0x001E, "x448", true, "x448", 448, ??????????????????????????? ProtocolVersion.PROTOCOLS_TO_13), The constructor will take this length and store it. Then we can get this value out of the NamedGroup in XDHKeyExchange and pass it in to the methods of ECUtil so we don't need to get it from XECParameters. Is this what you had in mind? From sean.mullan at oracle.com Fri Sep 7 13:11:37 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 7 Sep 2018 09:11:37 -0400 Subject: RFR: 8209452: VerifyCACerts.java failed with "At least one cacert test failed" (gtecybertrustglobalca certificate) In-Reply-To: <124c347ad58d4a51b6ffc554359f28a3@sap.com> References: <82a0b10007ac4aa38345d9a3f8f3f0c9@sap.com> <7b55b2d3-0a20-36dc-9a83-ecc5285a4f03@oracle.com> <124c347ad58d4a51b6ffc554359f28a3@sap.com> Message-ID: On 8/23/18 8:10 AM, Langer, Christoph wrote: > Hi Sean, > > thanks for the information. > > Can you please let me know when you've crated the Jira item for removal that I can add me as a watcher? There was actually an existing bug for this which had been marked Confidential initially but I have now made Public: https://bugs.openjdk.java.net/browse/JDK-8195793 --Sean From xuelei.fan at oracle.com Fri Sep 7 13:34:07 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 7 Sep 2018 06:34:07 -0700 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> <486a8d33-f4d6-8bcd-3123-3b4b3ef411df@oracle.com> <7589d254-7e2c-1b63-1d3e-10d74cbf4684@oracle.com> Message-ID: > The NamedParameterSpec object holds the name only, and not the key size. The name is not a meaningless string, it refer to a specific thing. For more examples, please refer to the standard names documentation, every name has its specific meaning and the background. If the name is just a meaningless string, there is nothing we can do for it and we may not want to define a meaningless API. The parse of the NamedParameterSpec name is really about the implementation details. For example, for KeyFactory: public PublicKey engineGeneratePublic(KeySpec keySpec) { if (the algorithm is 'x25519') { // use the X25519 parameters, including key size } else if ('x448') { // use the X25519 parameters, including key size } } There are a few alternatice ways. You can define a enum in the XDH provider, or just use switch, or use Map, or something else you like. Which one is a better one, it may depends on the implementation details. Please don't define the x25519 parameters in JSSE. JSSE should use the 'x25519' name (via NamedParameterSpec object) only. The underlying JCE provider should take the responsibility to support the NamedParameterSpec and defines the internal/private parameters for the specific name. Thanks, Xuelei On 9/7/2018 5:49 AM, Adam Petcher wrote: > On 9/6/2018 4:49 PM, Xuelei Fan wrote: > >> I asked the question in a previous email.? The key size for x25529 is >> fixed, right? > > Right. > >> >> If it is not right, stop here and tell me that it is not right. Keep >> reading if it is right. >> >> OK, as the key size for x25519 is fixed, when you know the algorithm >> is x25519, you know the key size.? Does it sound right to you? > > Possibly right---it depends on what you mean by "know". If all you have > is the name, then you need use a static mapping to look up the key length. > >> >> If it is not right, stop here and tell me that it is not right. >> Otherwise, keep reading. >> >> From the name you know the key size, when you create a >> NamedParameterSpec object for "x25519", you know the name and key size >> from the object, right? > > The NamedParameterSpec object holds the name only, and not the key size. > We create the NamedParameterSpec from the algorithm name in the > NamedGroup enum, which also doesn't have the key size. Are you > suggesting that I add the key size to this enum as well? Like this: > > ??????? // x25519 and x448 > ??????? X25519????? (0x001D, "x25519", true, "x25519", 255, > ??????????????????????????? ProtocolVersion.PROTOCOLS_TO_13), > ??????? X448??????? (0x001E, "x448", true, "x448", 448, > ??????????????????????????? ProtocolVersion.PROTOCOLS_TO_13), > > The constructor will take this length and store it. Then we can get this > value out of the NamedGroup in XDHKeyExchange and pass it in to the > methods of ECUtil so we don't need to get it from XECParameters. Is this > what you had in mind? From xuelei.fan at oracle.com Fri Sep 7 14:06:52 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 7 Sep 2018 07:06:52 -0700 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> <486a8d33-f4d6-8bcd-3123-3b4b3ef411df@oracle.com> <7589d254-7e2c-1b63-1d3e-10d74cbf4684@oracle.com> Message-ID: On 9/7/2018 6:34 AM, Xuelei Fan wrote: > > The NamedParameterSpec object holds the name only, and not the key size. > The name is not a meaningless string, it refer to a specific thing.? For > more examples, please refer to the standard names documentation, every > name has its specific meaning and the background.? If the name is just a > meaningless string, there is nothing we can do for it and we may not > want to define a meaningless API. > > The parse of the NamedParameterSpec name is really about the > implementation details.? For example, for KeyFactory: > > ?? public PublicKey engineGeneratePublic(KeySpec keySpec) { > ????? if (the algorithm is 'x25519') { > ????????? // use the X25519 parameters, including key size > ????? } else if ('x448') { > ????????? // use the X25519 parameters, including key size stupid copy and past: X25519 -> X448 > ????? } > ?? } > > There are a few alternatice ways.? You can define a enum in the XDH > provider, or just use switch, or use Map, or something else you like. > Which one is a better one, it may depends on the implementation details. > > Please don't define the x25519 parameters in JSSE.? JSSE should use the > 'x25519' name (via NamedParameterSpec object) only.? The underlying JCE > provider should take the responsibility to support the > NamedParameterSpec and defines the internal/private parameters for the > specific name. > > Thanks, > Xuelei > > On 9/7/2018 5:49 AM, Adam Petcher wrote: >> On 9/6/2018 4:49 PM, Xuelei Fan wrote: >> >>> I asked the question in a previous email.? The key size for x25529 is >>> fixed, right? >> >> Right. >> >>> >>> If it is not right, stop here and tell me that it is not right. Keep >>> reading if it is right. >>> >>> OK, as the key size for x25519 is fixed, when you know the algorithm >>> is x25519, you know the key size.? Does it sound right to you? >> >> Possibly right---it depends on what you mean by "know". If all you >> have is the name, then you need use a static mapping to look up the >> key length. >> >>> >>> If it is not right, stop here and tell me that it is not right. >>> Otherwise, keep reading. >>> >>> From the name you know the key size, when you create a >>> NamedParameterSpec object for "x25519", you know the name and key >>> size from the object, right? >> >> The NamedParameterSpec object holds the name only, and not the key >> size. We create the NamedParameterSpec from the algorithm name in the >> NamedGroup enum, which also doesn't have the key size. Are you >> suggesting that I add the key size to this enum as well? Like this: >> >> ???????? // x25519 and x448 >> ???????? X25519????? (0x001D, "x25519", true, "x25519", 255, >> ???????????????????????????? ProtocolVersion.PROTOCOLS_TO_13), >> ???????? X448??????? (0x001E, "x448", true, "x448", 448, >> ???????????????????????????? ProtocolVersion.PROTOCOLS_TO_13), >> >> The constructor will take this length and store it. Then we can get >> this value out of the NamedGroup in XDHKeyExchange and pass it in to >> the methods of ECUtil so we don't need to get it from XECParameters. >> Is this what you had in mind? From adam.petcher at oracle.com Fri Sep 7 14:30:10 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 7 Sep 2018 10:30:10 -0400 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> <486a8d33-f4d6-8bcd-3123-3b4b3ef411df@oracle.com> <7589d254-7e2c-1b63-1d3e-10d74cbf4684@oracle.com> Message-ID: <0a33a03c-3408-463b-458a-6d2754742d52@oracle.com> On 9/7/2018 9:34 AM, Xuelei Fan wrote: > JSSE should use the 'x25519' name (via NamedParameterSpec object) only. This is the part that I don't know how to do. In JSSE, we convert between the array containing the encoded public key and the BigInteger representation of the public key used in XECPublicKeySpec. To do this, you need to know the length of the key, in bits. That means that JSSE needs to know the length of the key, in addition to the name, in order to do this conversion. I understand that there are lots of ways to get this information in JSSE, but I don't know which ways you would find acceptable. We keep going back and forth, saying the exact same things, and we don't seem to be making any progress. Can you please provide some code to illustrate what you want me to do? All I need is an acceptable implementation of the following method, that is used by JSSE to decode public keys: public static XECPublicKeySpec decodeXecPublicKey(byte[] key, ??????????????????????????????????????? NamedParameterSpec spec) ??????? throws InvalidParameterSpecException { ??? XECParameters params = XECParameters.get( ??????? InvalidParameterSpecException::new, spec); ??? BigInteger u = decodeXecPublicKey(key, params.getBits()); ??? return new XECPublicKeySpec(spec, u); } For reference, here is the implementation of the helper method that does the actual decoding, using the length. public static BigInteger decodeXecPublicKey(byte[] key, ??????????????????????????????????????????? int bits) { ??? ArrayUtil.reverse(key); ??? // clear the extra bits ??? int bitsMod8 = bits % 8; ??? if (bitsMod8 != 0) { ??????? int mask = (1 << bitsMod8) - 1; ??????? key[0] &= mask; ??? } ??? return new BigInteger(1, key); } From xuelei.fan at oracle.com Fri Sep 7 15:34:33 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 7 Sep 2018 08:34:33 -0700 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: <0a33a03c-3408-463b-458a-6d2754742d52@oracle.com> References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> <486a8d33-f4d6-8bcd-3123-3b4b3ef411df@oracle.com> <7589d254-7e2c-1b63-1d3e-10d74cbf4684@oracle.com> <0a33a03c-3408-463b-458a-6d2754742d52@oracle.com> Message-ID: <0b163b6f-fac7-5273-b176-d641509ea5cb@oracle.com> Please let me know if you understand the following logic. Otherwise, I will see if I could do something for you, maybe a prototype, maybe a more detailed description. However, I may need more time for a prototype/detailed description. Per RFC 8446/7748, the X25519 key size is 32 bytes. Here we know the key size. [1] Per RFC 8446, the X25519 public key is encoded as byte string inputs and outputs, as defined in RFC 7748. Her we know the encoding of the key. [2] Suppose x25519 is used [3], then we know that the key sized per [1] and the encoded key per [2]. Next step, let convert the encoded key bytes to PublicKey. EncodedKeySpec keySpec = ... // find a way to construct the keySpec // at least, we can use: // new EncodedKeySpec(byte[]); // But please check if there's a better one KeyFactory kFac = KeyFactory.getInstance("x25519"); // we know the name in [3] PublicKey pubKey = kFac.generatePublic?(keySpec); Here you got the public key. We may also need to generate the key pair. KeyPairGenerator kpg = KeyPairGenerator.getInstance("x25519"); // we know the name in [3] // may be optional, we know the name in [3]. NamedParameterSpec nps = new NamedParameterSpec("x25519"); kpg.initialize(nps); KeyPair kp = kpg.generateKeyPair(); How you get the private key. That's it. I know you may need to adjust the crypto implementation if the provider does not support the above scenarios yet. Xuelei On 9/7/2018 7:30 AM, Adam Petcher wrote: > On 9/7/2018 9:34 AM, Xuelei Fan wrote: > >> JSSE should use the 'x25519' name (via NamedParameterSpec object) only. > > This is the part that I don't know how to do. In JSSE, we convert > between the array containing the encoded public key and the BigInteger > representation of the public key used in XECPublicKeySpec. To do this, > you need to know the length of the key, in bits. That means that JSSE > needs to know the length of the key, in addition to the name, in order > to do this conversion. I understand that there are lots of ways to get > this information in JSSE, but I don't know which ways you would find > acceptable. > > We keep going back and forth, saying the exact same things, and we don't > seem to be making any progress. Can you please provide some code to > illustrate what you want me to do? All I need is an acceptable > implementation of the following method, that is used by JSSE to decode > public keys: > > public static XECPublicKeySpec decodeXecPublicKey(byte[] key, > ??????????????????????????????????????? NamedParameterSpec spec) > ??????? throws InvalidParameterSpecException { > > ??? XECParameters params = XECParameters.get( > ??????? InvalidParameterSpecException::new, spec); > ??? BigInteger u = decodeXecPublicKey(key, params.getBits()); > ??? return new XECPublicKeySpec(spec, u); > } > > For reference, here is the implementation of the helper method that does > the actual decoding, using the length. > > public static BigInteger decodeXecPublicKey(byte[] key, > ??????????????????????????????????????????? int bits) { > > ??? ArrayUtil.reverse(key); > ??? // clear the extra bits > ??? int bitsMod8 = bits % 8; > ??? if (bitsMod8 != 0) { > ??????? int mask = (1 << bitsMod8) - 1; > ??????? key[0] &= mask; > ??? } > ??? return new BigInteger(1, key); > } > > From adam.petcher at oracle.com Fri Sep 7 16:03:27 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 7 Sep 2018 12:03:27 -0400 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: <0b163b6f-fac7-5273-b176-d641509ea5cb@oracle.com> References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> <486a8d33-f4d6-8bcd-3123-3b4b3ef411df@oracle.com> <7589d254-7e2c-1b63-1d3e-10d74cbf4684@oracle.com> <0a33a03c-3408-463b-458a-6d2754742d52@oracle.com> <0b163b6f-fac7-5273-b176-d641509ea5cb@oracle.com> Message-ID: This is more clear, thanks. See below. On 9/7/2018 11:34 AM, Xuelei Fan wrote: > EncodedKeySpec keySpec = ... // find a way to construct the keySpec > ???????????????????????????? // at least, we can use: > ???????????????????????????? //??? new EncodedKeySpec(byte[]); > ???????????????????????????? // But please check if there's a better one Do you mean X509EncodedKeySpec, or some class that is specific to XDH? An X509EncodedKeySpec would probably work---we would just need to put the key into a SubjectPublicKeyInfo, which means I need the OID. Is it okay for me to put the OID in JSSE? I could put it in the NamedGroup enum, like this: ??? X25519????? (0x001D, "x25519", true, "x25519", "1.3.101.110", ??????? ProtocolVersion.PROTOCOLS_TO_13), ??? X448??????? (0x001E, "x448", true, "x448", "1.3.101.111", ??????? ProtocolVersion.PROTOCOLS_TO_13), I'm not sure if the second x25519/x448 strings (for algorithm and NamedParameterSpec names) would still be needed, since I can use the OID in some of these places. If it's not needed, then perhaps I can remove it and only use the OID to interact with the JCA provider. We don't have a type for XDH encoded public keys. It would be nice to be able to do something simple like: byte[] keyBytes = ... NamedParameterSpec paramSpec = new NamedParameterSpec("X25519"); XECEncodedPublicKeySpec keySpec = new XECEncodedKeySpec(paramSpec, keyBytes); and then give keySpec to the "XDH" key factory. But this XECEncodedKeySpec type does not exist, so this would require an enhancement to the API. From xuelei.fan at oracle.com Fri Sep 7 16:12:21 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 7 Sep 2018 09:12:21 -0700 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> <486a8d33-f4d6-8bcd-3123-3b4b3ef411df@oracle.com> <7589d254-7e2c-1b63-1d3e-10d74cbf4684@oracle.com> <0a33a03c-3408-463b-458a-6d2754742d52@oracle.com> <0b163b6f-fac7-5273-b176-d641509ea5cb@oracle.com> Message-ID: <16b4291f-b119-2a4e-883e-06dfe30fc6c9@oracle.com> On 9/7/2018 9:03 AM, Adam Petcher wrote: > This is more clear, thanks. See below. > > > On 9/7/2018 11:34 AM, Xuelei Fan wrote: >> EncodedKeySpec keySpec = ... // find a way to construct the keySpec >> ???????????????????????????? // at least, we can use: >> ???????????????????????????? //??? new EncodedKeySpec(byte[]); >> ???????????????????????????? // But please check if there's a better one > > Do you mean X509EncodedKeySpec, or some class that is specific to XDH? I did not search the spec definitions. At least we can use the EncodedKeySpec class. It's nice if you can find a better one, or define a new one for XDH. Your following comments make sense to me. Thanks, Xuelei > An X509EncodedKeySpec would probably work---we would just need to put > the key into a SubjectPublicKeyInfo, which means I need the OID. Is it > okay for me to put the OID in JSSE? I could put it in the NamedGroup > enum, like this: > > ??? X25519????? (0x001D, "x25519", true, "x25519", "1.3.101.110", > ??????? ProtocolVersion.PROTOCOLS_TO_13), > ??? X448??????? (0x001E, "x448", true, "x448", "1.3.101.111", > ??????? ProtocolVersion.PROTOCOLS_TO_13), > > I'm not sure if the second x25519/x448 strings (for algorithm and > NamedParameterSpec names) would still be needed, since I can use the OID > in some of these places. If it's not needed, then perhaps I can remove > it and only use the OID to interact with the JCA provider. > > We don't have a type for XDH encoded public keys. It would be nice to be > able to do something simple like: > > byte[] keyBytes = ... > NamedParameterSpec paramSpec = new NamedParameterSpec("X25519"); > XECEncodedPublicKeySpec keySpec = new XECEncodedKeySpec(paramSpec, > keyBytes); > > and then give keySpec to the "XDH" key factory. But this > XECEncodedKeySpec type does not exist, so this would require an > enhancement to the API. From xuelei.fan at oracle.com Fri Sep 7 16:20:13 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 7 Sep 2018 09:20:13 -0700 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> <486a8d33-f4d6-8bcd-3123-3b4b3ef411df@oracle.com> <7589d254-7e2c-1b63-1d3e-10d74cbf4684@oracle.com> <0a33a03c-3408-463b-458a-6d2754742d52@oracle.com> <0b163b6f-fac7-5273-b176-d641509ea5cb@oracle.com> Message-ID: <29f345f6-d0a5-d96c-c24b-9f3cfb37b640@oracle.com> > I'm not sure if the second x25519/x448 strings (for algorithm and > NamedParameterSpec names) would still be needed, since I can use > the OID in some of these places. I see your points. However, we may want to think if third party wants to implement a JSSE provider, whether the JCE providers are sufficient for them and how the JCE provider could be used for them. Using OID works, but it is not as straightforward as a name. We should document the names in the Standard Names document. So using OIDs might not be as good as using names. I guess we have documented the 'x25519" algorithm name for JDK 11? If it is true, then we should be able to use them. Xuelei On 9/7/2018 9:03 AM, Adam Petcher wrote: > This is more clear, thanks. See below. > > > On 9/7/2018 11:34 AM, Xuelei Fan wrote: >> EncodedKeySpec keySpec = ... // find a way to construct the keySpec >> ???????????????????????????? // at least, we can use: >> ???????????????????????????? //??? new EncodedKeySpec(byte[]); >> ???????????????????????????? // But please check if there's a better one > > Do you mean X509EncodedKeySpec, or some class that is specific to XDH? > An X509EncodedKeySpec would probably work---we would just need to put > the key into a SubjectPublicKeyInfo, which means I need the OID. Is it > okay for me to put the OID in JSSE? I could put it in the NamedGroup > enum, like this: > > ??? X25519????? (0x001D, "x25519", true, "x25519", "1.3.101.110", > ??????? ProtocolVersion.PROTOCOLS_TO_13), > ??? X448??????? (0x001E, "x448", true, "x448", "1.3.101.111", > ??????? ProtocolVersion.PROTOCOLS_TO_13), > > I'm not sure if the second x25519/x448 strings (for algorithm and > NamedParameterSpec names) would still be needed, since I can use the OID > in some of these places. If it's not needed, then perhaps I can remove > it and only use the OID to interact with the JCA provider. > > We don't have a type for XDH encoded public keys. It would be nice to be > able to do something simple like: > > byte[] keyBytes = ... > NamedParameterSpec paramSpec = new NamedParameterSpec("X25519"); > XECEncodedPublicKeySpec keySpec = new XECEncodedKeySpec(paramSpec, > keyBytes); > > and then give keySpec to the "XDH" key factory. But this > XECEncodedKeySpec type does not exist, so this would require an > enhancement to the API. From mstjohns at comcast.net Fri Sep 7 16:43:39 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 7 Sep 2018 12:43:39 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <1c957616-cd36-1cc8-9257-fad9a3dcb0a6@oracle.com> <77ab28a5-8b14-db97-941e-7d3783a4f4c9@oracle.com> <79b68c86-e5ad-f4a2-7cf5-5edfdc46a906@comcast.net> Message-ID: On 9/6/2018 9:53 AM, Adam Petcher wrote: > On 9/5/2018 5:53 PM, Michael StJohns wrote: > >> >> BigInteger is not required to encode a PKCS8 key, but its trivial to >> translate from BigInteger to PKCS8 and vice versa. Note that >> internally, the current BigInteger stores the magnitude as an array >> of int in big endian order and stores the sign separately. The >> BigInteger (int sigNum, byte[] magnitude) constructor mostly just >> copies the magnitude bytes over (and converts 4 bytes to an integer) >> for positive integers. ? While the current BigInteger doesn't have a >> byte[] BigInteger.getMagnitude() call, it would be trivial to >> subclass BigInteger to copy the magnitude bytes (without branching) out. >> >> In any event, for NewEC to OldEc - you do use the sign/magnitude call >> to create the BigInteger - no leaking on the part of NewEC, and once >> it gets to OldEC its not your problem.? For OldEc to NewEc you copy >> the BigInteger to NewBigInteger (trivial wrapper class) and do a >> getMagnitude(). > > See the code for BigInteger[1]. The sign/magnitude constructor calls > stripLeadingZeroBytes (line 405) on the magnitude to convert it to an > int array. This method compares the leading values in the byte array > to zero in a short-circuit expression in a for loop (line 4298). So > this constructor branches on the value that is supplied to it, and it > cannot be used in a branchless implementation. > > I don't know how to write this branchless getMagnitude method that you > are proposing. I would need to convert from a variable-length int > array to a fixed-length byte array. In doing this, I can't branch on > the length of the variable-length array, because doing so would leak > whether the high-order bits of the key are zero. If you know how to do > this, then please provide some code to illustrate how it is done. Simple way to do this is to extend BigInteger and fix these perceived problems.? You may have to replace/replicate pretty much everything, but as long as it has a BigInteger signature when output, you're good to go.? Actually, do that - clone BigInteger.java as SafeBigInteger.java, have extend java.math.BigInteger and change out the things that bother you. ? I checked - BigInteger is not a final class so this should work. ?E.g. as long as *I* can call the functions I need to call on the object you exported, I'm fine with it. In any event, you're still missing the point here.? You're EXPORTING the key from your provider to other providers which probably already don't care that much about the one in 256 (approx - slightly larger)? time where exporting the key might leak the fact of leading zero bits. > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/805807f15830/src/java.base/share/classes/java/math/BigInteger.java > > >> While the contract for getEncoded() explicitly allows for a null >> result, getS() of ECPrivateKey does not.??? This more than any other >> reason appears to be why the PKCS 11 provider represents the >> ECPrivateKey as a simple PrivateKey object. > > Good point. There is no need for the private keys for this provider to > implement ECPrivateKey, since there is only one method that is > effectively unimplemented. We should use a new implementation class > (not ECPrivateKeyImpl) that implements PrivateKey, not ECPrivateKey. *pounds head on table*? Sure.? And then you can't use any translation features and then you break all the code. > >> So implementing your provider requires other providers to change? >> Because??? Do you expect BouncyCastle and NSS to change as well? > > I think the situation is improved by not having the new private keys > implement ECPrivateKey. Then the JDK ECKeyFactory code does not need > to change, and neither do other providers, assuming they behave in a > similar way. Though I think it is acceptable if other providers don't > behave this way, and therefore cannot translate private keys from this > new provider. I've updated the JEP to indicate that interoperability > with these providers is a non-goal. OK.? At this point you're no longer calling this an EC key. Make sure you catch all the places where ECPrivateKey is used instead of PrivateKey.? I think you're incredibly short sighted and not a lot of folks will implement this, but go for it.? I think its a *really* bad idea and that you're fixing the wrong problems. > >> >>> >>> The only way to get private keys in or out of the new provider is >>> through a PKCS#8 encoding. Moving keys to/from another provider that >>> supports ECPrivateKeySpec but not PKCS#8 encoding can be >>> accomplished by translating the specs---possibly with the help of a >>> KeyFactory that supports both, like the one in SunEC. >>> >> *pounds head against table*?? Bits are bits are bits.? Creating a >> PKCS8EncodedKeySpec gets you a byte array which you can convert to a >> BigInteger by decoding the PKCS8 structure and taking the PKCS8 >> PrivateKey octets and doing new BigInteger (1, privateKeyOctets). >> >> That doesn't require ASN1 integer representation (e.g. leading byte >> is zero if high bit is set) and doesn't cause a branch. > > See above for my explanation of why this solution does, in fact, branch. > See my commentary on why this still doesn't matter. Later, Mike From adam.petcher at oracle.com Fri Sep 7 17:32:52 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 7 Sep 2018 13:32:52 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <1c957616-cd36-1cc8-9257-fad9a3dcb0a6@oracle.com> <77ab28a5-8b14-db97-941e-7d3783a4f4c9@oracle.com> <79b68c86-e5ad-f4a2-7cf5-5edfdc46a906@comcast.net> Message-ID: <161a7099-89c9-681e-7caa-3beab165eca6@oracle.com> I'm only going to respond to one of your points in detail, see inline below. For the other points, I don't think we are going to agree. You want the implementation to be more interoperable, and I have stated that the level of interoperability that you want is not a goal of the JEP. This is supposed to be a more secure software ECC implementation, with corresponding restrictions on its API. I will be happy with it if the API is just functional enough to allow us to use it in SunJSSE, with some non-trivial modifications to the SunJSSE code. In the initial release of this new provider, it should only be enabled by users who are willing to accept this tradeoff between security and usability/interoperability, and who are willing to modify existing code to make the new provider work. On 9/7/2018 12:43 PM, Michael StJohns wrote: > > Simple way to do this is to extend BigInteger and fix these perceived > problems.? You may have to replace/replicate pretty much everything, > but as long as it has a BigInteger signature when output, you're good > to go.? Actually, do that - clone BigInteger.java as > SafeBigInteger.java, have extend java.math.BigInteger and change out > the things that bother you. I checked - BigInteger is not a final > class so this should work. Thanks for the suggestion. I agree that this might work, but it would greatly increase the scope/effort of this JEP. There might also be other solutions that require less effort (e.g. new types of keys/specs that hold values as integers, but not BigInteger) that should be considered. I've updated the JEP to record this suggestion, and to indicate that it is out of scope. We can always enhance the interface/implementation later. From anthony.scarpino at oracle.com Fri Sep 7 17:53:36 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 7 Sep 2018 10:53:36 -0700 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> Message-ID: <65FD868B-4AC2-4CFE-9C19-5319489634CC@oracle.com> Adam, I tend to agree with Mike that disallowing import/export of keys using BigInteger is not the value of a branchless implementation. As you point out in the JEP the provider is greatly hindered by this design choice. I feel it would be better to implementing the BigInteger parts and have a property to shut them off for a pure branchless implementation. That should allow the provider to be used in the default provider list and the ?opt-in? would be the property to turn off BigInteger or any other branching situation. I am concerned the desire for a purest provider will result in it being unused. Documentation can be clear about the import/export situation, the preference toward PKCS8EncodedKeySpec, and the property to lock it down. Tony > On Aug 23, 2018, at 10:50 AM, Adam Petcher wrote: > > I'm starting work on yet another ECC JEP[1], this time with the goal of developing improved implementations of existing algorithms, rather than implementing new ones. The JEP will re-implement ECDH and ECDSA for the 256-, 384-, and 521-bit NIST prime curves. The new implementation will be all Java, and will resist side-channel attacks by not branching on secrets. It will go in a new provider which is not in the provider list in the java.security file by default. So it will need to be manually enabled by changing the configuration or putting the new provider name in the code. It will only support a subset of the API that is supported by the implementation in SunEC. In particular, it will reject any private keys with scalar values specified using BigInteger (as in ECPrivateKeySpec), and its private keys will not return scalar values as BigInteger (as in ECPrivateKey.getS()). > > Please take a look and send me any feedback you have. I'm especially looking for suggestions on how this new implementation should fit into the API. I would prefer to have it enabled by default, but I can't think of a way to do that without either branching on secrets in some cases (converting a BigInteger private key to an array) or breaking compatibility (throwing an exception when it gets a BigInteger private key). > > [1] https://bugs.openjdk.java.net/browse/JDK-8204574 > From sean.mullan at oracle.com Fri Sep 7 18:13:18 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 7 Sep 2018 14:13:18 -0400 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <46322abe1477459cad6ea342950b2da4@sap.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <446574fd-4a70-fad8-3bd1-c43d0e374b92@oracle.com> <34b096660ca44a4cb3f674198cd51d35@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> Message-ID: <10a18d9f-c40f-5e82-ab52-6f7cefccddff@oracle.com> On 8/27/18 10:25 AM, Baesken, Matthias wrote: >> Will sun.net.util.SocketExceptions be changed to use the supporting >> class or is that a separate issue? >> > I think this is a separate issue . I think we should fix it as part of this issue. It shouldn't be hard and then we don't have to file another issue to fix it. --Sean From adam.petcher at oracle.com Fri Sep 7 19:08:21 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 7 Sep 2018 15:08:21 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <65FD868B-4AC2-4CFE-9C19-5319489634CC@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <65FD868B-4AC2-4CFE-9C19-5319489634CC@oracle.com> Message-ID: This is a good suggestion. I don't have particularly strong feelings about using separate providers vs a property in a single provider. I think the fundamental issues are the same, and this choice mostly affects API details. Do you think this should be a system property, security property, or something else? Should it be modifiable at any time? Perhaps it has to be in order to address Mike's desire to put the provider in "import/export mode". Would the property affect existing keys? Again, I think it would have to, so you can generate a key, turn off branchless mode, and then export it. What about curves other than P256, P384, and P521? We can't do branchless operations in those curves, so any attempt to use them when this property is enabled would result in an exception. The questions above are for everybody, if you have thoughts on any of this, please share. My initial thoughts are that using a property may give us some additional flexibility, and may improve the interface, but the main cost is additional complexity in the implementation, since we'll need to implement some checks that would otherwise be accomplished by provider selection and having separate code. On 9/7/2018 1:53 PM, Anthony Scarpino wrote: > Adam, > > I tend to agree with Mike that disallowing import/export of keys using BigInteger is not the value of a branchless implementation. As you point out in the JEP the provider is greatly hindered by this design choice. I feel it would be better to implementing the BigInteger parts and have a property to shut them off for a pure branchless implementation. That should allow the provider to be used in the default provider list and the ?opt-in? would be the property to turn off BigInteger or any other branching situation. I am concerned the desire for a purest provider will result in it being unused. Documentation can be clear about the import/export situation, the preference toward PKCS8EncodedKeySpec, and the property to lock it down. > > Tony > >> On Aug 23, 2018, at 10:50 AM, Adam Petcher wrote: >> >> I'm starting work on yet another ECC JEP[1], this time with the goal of developing improved implementations of existing algorithms, rather than implementing new ones. The JEP will re-implement ECDH and ECDSA for the 256-, 384-, and 521-bit NIST prime curves. The new implementation will be all Java, and will resist side-channel attacks by not branching on secrets. It will go in a new provider which is not in the provider list in the java.security file by default. So it will need to be manually enabled by changing the configuration or putting the new provider name in the code. It will only support a subset of the API that is supported by the implementation in SunEC. In particular, it will reject any private keys with scalar values specified using BigInteger (as in ECPrivateKeySpec), and its private keys will not return scalar values as BigInteger (as in ECPrivateKey.getS()). >> >> Please take a look and send me any feedback you have. I'm especially looking for suggestions on how this new implementation should fit into the API. I would prefer to have it enabled by default, but I can't think of a way to do that without either branching on secrets in some cases (converting a BigInteger private key to an array) or breaking compatibility (throwing an exception when it gets a BigInteger private key). >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8204574 >> From Roger.Riggs at Oracle.com Fri Sep 7 19:19:09 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 7 Sep 2018 15:19:09 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <65FD868B-4AC2-4CFE-9C19-5319489634CC@oracle.com> Message-ID: Hi, In general, System properties should be avoided, they add complexity to configurations and especially if they change sensitive behavior.? In any case, the defaults should be secure-by-default; not the other way around. Perhaps two different providers, one secure and one more secure. $.02, Roger On 9/7/2018 3:08 PM, Adam Petcher wrote: > This is a good suggestion. I don't have particularly strong feelings > about using separate providers vs a property in a single provider. I > think the fundamental issues are the same, and this choice mostly > affects API details. > > Do you think this should be a system property, security property, or > something else? Should it be modifiable at any time? Perhaps it has to > be in order to address Mike's desire to put the provider in > "import/export mode". Would the property affect existing keys? Again, > I think it would have to, so you can generate a key, turn off > branchless mode, and then export it. What about curves other than > P256, P384, and P521? We can't do branchless operations in those > curves, so any attempt to use them when this property is enabled would > result in an exception. > > The questions above are for everybody, if you have thoughts on any of > this, please share. My initial thoughts are that using a property may > give us some additional flexibility, and may improve the interface, > but the main cost is additional complexity in the implementation, > since we'll need to implement some checks that would otherwise be > accomplished by provider selection and having separate code. > > On 9/7/2018 1:53 PM, Anthony Scarpino wrote: >> Adam, >> >> I tend to agree with Mike that disallowing import/export of keys >> using BigInteger is not the value of a branchless implementation.? As >> you point out in the JEP the provider is greatly hindered by this >> design choice. I feel it would be better to implementing the >> BigInteger parts and have a property to shut them off for a pure >> branchless implementation.? That should allow the provider to be used >> in the default provider list and the ?opt-in? would be the property >> to turn off BigInteger or any other branching situation.? I am >> concerned the desire for a purest provider will result in it being >> unused. Documentation can be clear about the import/export situation, >> the preference toward PKCS8EncodedKeySpec, and the property to lock >> it down. >> >> Tony >> >>> On Aug 23, 2018, at 10:50 AM, Adam Petcher >>> wrote: >>> >>> I'm starting work on yet another ECC JEP[1], this time with the goal >>> of developing improved implementations of existing algorithms, >>> rather than implementing new ones. The JEP will re-implement ECDH >>> and ECDSA for the 256-, 384-, and 521-bit NIST prime curves. The new >>> implementation will be all Java, and will resist side-channel >>> attacks by not branching on secrets. It will go in a new provider >>> which is not in the provider list in the java.security file by >>> default. So it will need to be manually enabled by changing the >>> configuration or putting the new provider name in the code. It will >>> only support a subset of the API that is supported by the >>> implementation in SunEC. In particular, it will reject any private >>> keys with scalar values specified using BigInteger (as in >>> ECPrivateKeySpec), and its private keys will not return scalar >>> values as BigInteger (as in ECPrivateKey.getS()). >>> >>> Please take a look and send me any feedback you have. I'm especially >>> looking for suggestions on how this new implementation should fit >>> into the API. I would prefer to have it enabled by default, but I >>> can't think of a way to do that without either branching on secrets >>> in some cases (converting a BigInteger private key to an array) or >>> breaking compatibility (throwing an exception when it gets a >>> BigInteger private key). >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8204574 >>> > From xuelei.fan at oracle.com Fri Sep 7 19:23:52 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 7 Sep 2018 12:23:52 -0700 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <65FD868B-4AC2-4CFE-9C19-5319489634CC@oracle.com> Message-ID: Hi, I have not had a chance to review this JEP yet. Personally, if possible, I would expect there is no public APIs update so that more applications can benefit from the enhancement, and SunJSSE could benefits from more crypto providers. I'm not sure if it is possible or not now, or how could we minimize the APIs update. I will see if I could be here next week. Please go ahead if you have an agreement before I look into this JEP. Thanks, Xuelei On 9/7/2018 12:08 PM, Adam Petcher wrote: > This is a good suggestion. I don't have particularly strong feelings > about using separate providers vs a property in a single provider. I > think the fundamental issues are the same, and this choice mostly > affects API details. > > Do you think this should be a system property, security property, or > something else? Should it be modifiable at any time? Perhaps it has to > be in order to address Mike's desire to put the provider in > "import/export mode". Would the property affect existing keys? Again, I > think it would have to, so you can generate a key, turn off branchless > mode, and then export it. What about curves other than P256, P384, and > P521? We can't do branchless operations in those curves, so any attempt > to use them when this property is enabled would result in an exception. > > The questions above are for everybody, if you have thoughts on any of > this, please share. My initial thoughts are that using a property may > give us some additional flexibility, and may improve the interface, but > the main cost is additional complexity in the implementation, since > we'll need to implement some checks that would otherwise be accomplished > by provider selection and having separate code. > > On 9/7/2018 1:53 PM, Anthony Scarpino wrote: >> Adam, >> >> I tend to agree with Mike that disallowing import/export of keys using >> BigInteger is not the value of a branchless implementation.? As you >> point out in the JEP the provider is greatly hindered by this design >> choice. I feel it would be better to implementing the BigInteger parts >> and have a property to shut them off for a pure branchless >> implementation.? That should allow the provider to be used in the >> default provider list and the ?opt-in? would be the property to turn >> off BigInteger or any other branching situation.? I am concerned the >> desire for a purest provider will result in it being unused. >> Documentation can be clear about the import/export situation, the >> preference toward PKCS8EncodedKeySpec, and the property to lock it down. >> >> Tony >> >>> On Aug 23, 2018, at 10:50 AM, Adam Petcher >>> wrote: >>> >>> I'm starting work on yet another ECC JEP[1], this time with the goal >>> of developing improved implementations of existing algorithms, rather >>> than implementing new ones. The JEP will re-implement ECDH and ECDSA >>> for the 256-, 384-, and 521-bit NIST prime curves. The new >>> implementation will be all Java, and will resist side-channel attacks >>> by not branching on secrets. It will go in a new provider which is >>> not in the provider list in the java.security file by default. So it >>> will need to be manually enabled by changing the configuration or >>> putting the new provider name in the code. It will only support a >>> subset of the API that is supported by the implementation in SunEC. >>> In particular, it will reject any private keys with scalar values >>> specified using BigInteger (as in ECPrivateKeySpec), and its private >>> keys will not return scalar values as BigInteger (as in >>> ECPrivateKey.getS()). >>> >>> Please take a look and send me any feedback you have. I'm especially >>> looking for suggestions on how this new implementation should fit >>> into the API. I would prefer to have it enabled by default, but I >>> can't think of a way to do that without either branching on secrets >>> in some cases (converting a BigInteger private key to an array) or >>> breaking compatibility (throwing an exception when it gets a >>> BigInteger private key). >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8204574 >>> > From sean.mullan at oracle.com Fri Sep 7 19:41:10 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 7 Sep 2018 15:41:10 -0400 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> Message-ID: <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> On 8/29/18 10:01 AM, Baesken, Matthias wrote: > Hi Max, thanks for your input . > > I created another webrev , this contains now the suggested SecurityProperties class : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/ java/util/jar/Attributes.java 469 return AccessController.doPrivileged(new PrivilegedAction() { 470 public String run() { 471 return file.getAbsolutePath() + ":" + lineNumber; 472 } 473 }); I have a serious concern with the code above. With this change, untrusted code running under a SecurityManager could potentially create a JarFile on a non-absolute path ex: "foo.jar", and (somehow) cause an IOException to be thrown which would then reveal the absolute path of where the jar was located, and thus could reveal sensitive details about the system (ex: the user's home directory). It could still be hard to exploit, since it would have to be a known jar that exists, and you would then need to cause an IOException to be thrown, but it's still theoretically possible. In short, this is a more general issue in that it may allow untrusted code to access something it couldn't have previously. new JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path. Granted this can only be done if the security property is enabled, but I believe this is not something administrators should have to know about their environment and account for when enabling this property. The above code should be changed to return only what the caller provides to JarFile, which is the name of the file (without the full path). --Sean From anthony.scarpino at oracle.com Fri Sep 7 23:07:10 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 7 Sep 2018 16:07:10 -0700 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <65FD868B-4AC2-4CFE-9C19-5319489634CC@oracle.com> Message-ID: > On Sep 7, 2018, at 12:08 PM, Adam Petcher wrote: > > This is a good suggestion. I don't have particularly strong feelings about using separate providers vs a property in a single provider. I think the fundamental issues are the same, and this choice mostly affects API details. > > Do you think this should be a system property, security property, or something else? Should it be modifiable at any time? I would say a security property > Perhaps it has to be in order to address Mike's desire to put the provider in "import/export mode". Would the property affect existing keys? Again, I think it would have to, so you can generate a key, turn off branchless mode, and then export it. My thought was the property would allow the branchless import/export for that java instance. Not turning it on and off during operations. I think the value of the branchless operation is in the usage of the algorithms. If an app wants to use a pure branchless provider the property can be set or never use the APIs with BigInteger in them. One could avoid the property completely by just documenting clearly the interfaces that branched and then leave it to the app developer, but from the email discussion with Mike it sounded like you preferred strong controls on the provider. > What about curves other than P256, P384, and P521? We can't do branchless operations in those curves, so any attempt to use them when this property is enabled would result in an exception. I wasn?t going to propose anything further than your existing curves, but it would be nice if branchful curves could be added to eventual replace SunEC. I know that isn?t the intent of this JEP and depends if you want to expand it. > > The questions above are for everybody, if you have thoughts on any of this, please share. My initial thoughts are that using a property may give us some additional flexibility, and may improve the interface, but the main cost is additional complexity in the implementation, since we'll need to implement some checks that would otherwise be accomplished by provider selection and having separate code. A branchless and branchful provider is also an fine idea. You?d know better on the code impact between two providers vs a property. A branchful class extending the branchless class may create the seperation your looking for. Tony > >> On 9/7/2018 1:53 PM, Anthony Scarpino wrote: >> Adam, >> >> I tend to agree with Mike that disallowing import/export of keys using BigInteger is not the value of a branchless implementation. As you point out in the JEP the provider is greatly hindered by this design choice. I feel it would be better to implementing the BigInteger parts and have a property to shut them off for a pure branchless implementation. That should allow the provider to be used in the default provider list and the ?opt-in? would be the property to turn off BigInteger or any other branching situation. I am concerned the desire for a purest provider will result in it being unused. Documentation can be clear about the import/export situation, the preference toward PKCS8EncodedKeySpec, and the property to lock it down. >> >> Tony >> >>> On Aug 23, 2018, at 10:50 AM, Adam Petcher wrote: >>> >>> I'm starting work on yet another ECC JEP[1], this time with the goal of developing improved implementations of existing algorithms, rather than implementing new ones. The JEP will re-implement ECDH and ECDSA for the 256-, 384-, and 521-bit NIST prime curves. The new implementation will be all Java, and will resist side-channel attacks by not branching on secrets. It will go in a new provider which is not in the provider list in the java.security file by default. So it will need to be manually enabled by changing the configuration or putting the new provider name in the code. It will only support a subset of the API that is supported by the implementation in SunEC. In particular, it will reject any private keys with scalar values specified using BigInteger (as in ECPrivateKeySpec), and its private keys will not return scalar values as BigInteger (as in ECPrivateKey.getS()). >>> >>> Please take a look and send me any feedback you have. I'm especially looking for suggestions on how this new implementation should fit into the API. I would prefer to have it enabled by default, but I can't think of a way to do that without either branching on secrets in some cases (converting a BigInteger private key to an array) or breaking compatibility (throwing an exception when it gets a BigInteger private key). >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8204574 >>> > From weijun.wang at oracle.com Fri Sep 7 23:58:59 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 8 Sep 2018 07:58:59 +0800 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <036f88e423b743bbb68c73e2a59486d4@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> Message-ID: <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.com> In my understanding, the author deliberately wants to show the absolute paths when there are multiple jar files with the same name (Ex: a jar hell). Maybe we can add some more detail in the java.security so an admin knows what exact impact it has. --Max > On Sep 8, 2018, at 3:41 AM, Sean Mullan wrote: > > On 8/29/18 10:01 AM, Baesken, Matthias wrote: >> Hi Max, thanks for your input . >> I created another webrev , this contains now the suggested SecurityProperties class : >> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/ > > java/util/jar/Attributes.java > > 469 return AccessController.doPrivileged(new PrivilegedAction() { > 470 public String run() { > 471 return file.getAbsolutePath() + ":" + lineNumber; > 472 } > 473 }); > > I have a serious concern with the code above. > > With this change, untrusted code running under a SecurityManager could potentially create a JarFile on a non-absolute path ex: "foo.jar", and (somehow) cause an IOException to be thrown which would then reveal the absolute path of where the jar was located, and thus could reveal sensitive details about the system (ex: the user's home directory). It could still be hard to exploit, since it would have to be a known jar that exists, and you would then need to cause an IOException to be thrown, but it's still theoretically possible. > > In short, this is a more general issue in that it may allow untrusted code to access something it couldn't have previously. new JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path. > > Granted this can only be done if the security property is enabled, but I believe this is not something administrators should have to know about their environment and account for when enabling this property. > > The above code should be changed to return only what the caller provides to JarFile, which is the name of the file (without the full path). > > --Sean From weijun.wang at oracle.com Sat Sep 8 01:31:10 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 8 Sep 2018 09:31:10 +0800 Subject: RFR 8205507: jdk/javax/xml/crypto/dsig/GenerationTests.java timed out Message-ID: <59413F33-F156-425E-B348-75C0AC83F497@oracle.com> Please review the change at http://cr.openjdk.java.net/~weijun/8205507/webrev.00/ Here I cached the keys for each signature method. Running 100 times on solaris-sparcv9 and the longest duration is 10 minutes, much shorter than the timeout threshold of 50 mins. I didn't hardcoded the keys because I'm afraid some keys might fail (this happened before, for example, if first byte of key is zero). With a cache, and especially the keys persisted into a file, we gain both randomness (although not as random as before) and reproducibility. Noreg-self. Thanks Max From sean.mullan at oracle.com Sat Sep 8 13:42:06 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Sat, 8 Sep 2018 09:42:06 -0400 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.com> Message-ID: On 9/7/18 7:58 PM, Weijun Wang wrote: > In my understanding, the author deliberately wants to show the absolute paths when there are multiple jar files with the same name (Ex: a jar hell). If you are very familiar with a particular application and understand the risks associated with running it, then I agree that is ok. But security properties apply to all applications using that JDK, and so I don't always think it is practical for an admin to understand every type of application that may be using that JDK and whether or not enabling this property presents a risk. > Maybe we can add some more detail in the java.security so an admin knows what exact impact it has. It would be a slippery slope in my opinion. You would have to say something like: "enabling this property may allow untrusted code running under a SecurityManager to access sensitive information such as the user.home system property even if it has not been granted permission to do so." I think we should consider not allowing this property to take effect if a SecurityManager is running. --Sean > > --Max > >> On Sep 8, 2018, at 3:41 AM, Sean Mullan wrote: >> >> On 8/29/18 10:01 AM, Baesken, Matthias wrote: >>> Hi Max, thanks for your input . >>> I created another webrev , this contains now the suggested SecurityProperties class : >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/ >> >> java/util/jar/Attributes.java >> >> 469 return AccessController.doPrivileged(new PrivilegedAction() { >> 470 public String run() { >> 471 return file.getAbsolutePath() + ":" + lineNumber; >> 472 } >> 473 }); >> >> I have a serious concern with the code above. >> >> With this change, untrusted code running under a SecurityManager could potentially create a JarFile on a non-absolute path ex: "foo.jar", and (somehow) cause an IOException to be thrown which would then reveal the absolute path of where the jar was located, and thus could reveal sensitive details about the system (ex: the user's home directory). It could still be hard to exploit, since it would have to be a known jar that exists, and you would then need to cause an IOException to be thrown, but it's still theoretically possible. >> >> In short, this is a more general issue in that it may allow untrusted code to access something it couldn't have previously. new JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path. >> >> Granted this can only be done if the security property is enabled, but I believe this is not something administrators should have to know about their environment and account for when enabling this property. >> >> The above code should be changed to return only what the caller provides to JarFile, which is the name of the file (without the full path). >> >> --Sean > From weijun.wang at oracle.com Sat Sep 8 15:42:56 2018 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 8 Sep 2018 23:42:56 +0800 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> Message-ID: <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> Thinking about this again. Looks like the absolute path is not necessary. Even if there are multiple files using the same name, they will be in different directories, no matter absolute or relative. Suppose the jarPath info is used for debugging purpose mostly like the developer can find out what the current working directory is and can find the files. *Matthias*: Is the absolute path really necessary? Are you working on actual case? As for the possible global effect of a security property, maybe we can emphasis that this is both a security property and system property, and if it?s just for one time use, it?s better to use a system property. BTW, does the existing value ?hostInfo? of the property have a similar problem? Thanks Max >> ? 2018?9?8??21:42?Sean Mullan ??? >> >> On 9/7/18 7:58 PM, Weijun Wang wrote: >> In my understanding, the author deliberately wants to show the absolute paths when there are multiple jar files with the same name (Ex: a jar hell). > > If you are very familiar with a particular application and understand the risks associated with running it, then I agree that is ok. But security properties apply to all applications using that JDK, and so I don't always think it is practical for an admin to understand every type of application that may be using that JDK and whether or not enabling this property presents a risk. > >> Maybe we can add some more detail in the java.security so an admin knows what exact impact it has. > > It would be a slippery slope in my opinion. You would have to say something like: "enabling this property may allow untrusted code running under a SecurityManager to access sensitive information such as the user.home system property even if it has not been granted permission to do so." > > I think we should consider not allowing this property to take effect if a SecurityManager is running. > > --Sean > >> --Max >>> On Sep 8, 2018, at 3:41 AM, Sean Mullan wrote: >>> >>> On 8/29/18 10:01 AM, Baesken, Matthias wrote: >>>> Hi Max, thanks for your input . >>>> I created another webrev , this contains now the suggested SecurityProperties class : >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/ >>> >>> java/util/jar/Attributes.java >>> >>> 469 return AccessController.doPrivileged(new PrivilegedAction() { >>> 470 public String run() { >>> 471 return file.getAbsolutePath() + ":" + lineNumber; >>> 472 } >>> 473 }); >>> >>> I have a serious concern with the code above. >>> >>> With this change, untrusted code running under a SecurityManager could potentially create a JarFile on a non-absolute path ex: "foo.jar", and (somehow) cause an IOException to be thrown which would then reveal the absolute path of where the jar was located, and thus could reveal sensitive details about the system (ex: the user's home directory). It could still be hard to exploit, since it would have to be a known jar that exists, and you would then need to cause an IOException to be thrown, but it's still theoretically possible. >>> >>> In short, this is a more general issue in that it may allow untrusted code to access something it couldn't have previously. new JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path. >>> >>> Granted this can only be done if the security property is enabled, but I believe this is not something administrators should have to know about their environment and account for when enabling this property. >>> >>> The above code should be changed to return only what the caller provides to JarFile, which is the name of the file (without the full path). >>> >>> --Sean From openjdk at suche.org Sun Sep 9 21:44:31 2018 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Sun, 9 Sep 2018 23:44:31 +0200 Subject: NPE in SupportedGroupsExtension In-Reply-To: <82966446-732a-c992-0c7d-c8d6c8cba8c8@oracle.com> References: <82966446-732a-c992-0c7d-c8d6c8cba8c8@oracle.com> Message-ID: <1e80314f-2594-4d98-2638-f29f2fa25f2c@suche.org> Hi, i found another bug with firefox nigthly "64.0a1 (2018-09-08) (64-bit)" and "OpenJDK Runtime Environment 18.9 (build 11+28)". It is not possible to establish an connection. The exception i receive is "pre_shared_key key extension is offered without a psk_key_exchange_modes extension". If there is an PSK without an matching extension this should not kill the connection i think. Nearly all other server accept this. Gru? Thomas Lu?nig javax.net.ssl.SSLHandshakeException: pre_shared_key key extension is offered without a psk_key_exchange_modes extension ?? ?at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) ?? ?at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) ?? ?at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) ?? ?at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) ?? ?at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) ?? ?at java.base/sun.security.ssl.PskKeyExchangeModesExtension$PskKeyExchangeModesOnTradeAbsence.absent(PskKeyExchangeModesExtension.java:327) ?? ?at java.base/sun.security.ssl.SSLExtension.absentOnTrade(SSLExtension.java:572) ?? ?at java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:180) ?? ?at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:522) ?? ?at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) ?? ?at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1189) ?? ?at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1125) ?? ?at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:831) ?? ?at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:792) ?? ?at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) ?? ?at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) ?? ?at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1065) ?? ?at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1052) ?? ?at java.base/java.security.AccessController.doPrivileged(Native Method) ?? ?at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:999) From jamil.j.nimeh at oracle.com Mon Sep 10 04:11:34 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sun, 9 Sep 2018 21:11:34 -0700 Subject: NPE in SupportedGroupsExtension In-Reply-To: <1e80314f-2594-4d98-2638-f29f2fa25f2c@suche.org> References: <82966446-732a-c992-0c7d-c8d6c8cba8c8@oracle.com> <1e80314f-2594-4d98-2638-f29f2fa25f2c@suche.org> Message-ID: <9438e88e-9a29-8898-7181-1a5c95190e47@oracle.com> Hi Thomas, This is a known issue captured in JDK-8210334 and the fix for it was committed to JDK 12 a few days ago.? Looks like the backport of the fix is planned for 11.0.2.? The backport ID is JDK-8210445 in case you're interested. --Jamil On 9/9/2018 2:44 PM, Thomas Lu?nig wrote: > Hi, > > i found another bug with firefox nigthly "64.0a1 (2018-09-08) > (64-bit)" and "OpenJDK Runtime Environment 18.9 (build 11+28)". > It is not possible to establish an connection. The exception i receive > is "pre_shared_key key extension is offered without a > psk_key_exchange_modes extension". > If there is an PSK without an matching extension this should not kill > the connection i think. Nearly all other server accept this. > > Gru? Thomas Lu?nig > > javax.net.ssl.SSLHandshakeException: pre_shared_key key extension is > offered without a psk_key_exchange_modes extension > > ?? ?at > java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > ?? ?at > java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > ?? ?at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > ?? ?at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) > ?? ?at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) > ?? ?at > java.base/sun.security.ssl.PskKeyExchangeModesExtension$PskKeyExchangeModesOnTradeAbsence.absent(PskKeyExchangeModesExtension.java:327) > ?? ?at > java.base/sun.security.ssl.SSLExtension.absentOnTrade(SSLExtension.java:572) > ?? ?at > java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:180) > ?? ?at > java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:522) > ?? ?at > java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) > ?? ?at > java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1189) > ?? ?at > java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1125) > ?? ?at > java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:831) > ?? ?at > java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:792) > ?? ?at > java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) > ?? ?at > java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) > ?? ?at > java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1065) > ?? ?at > java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1052) > ?? ?at java.base/java.security.AccessController.doPrivileged(Native > Method) > ?? ?at > java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:999) > From matthias.baesken at sap.com Mon Sep 10 07:53:20 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 10 Sep 2018 07:53:20 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> Message-ID: Hello are you fine with changing from file.getAbsolutePath() to file.getName() ? http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/src/java.base/share/classes/java/util/jar/Manifest.java.frames.html 206 static String getErrorPosition(String filename, final int lineNumber) { 207 if (filename == null || !jarPathInExceptionText) { 208 return "line " + lineNumber; 209 } 210 211 final File file = new File(filename); 212 return AccessController.doPrivileged(new PrivilegedAction() { 213 public String run() { 214 return "manifest of " + file.getName() + ":" + lineNumber; 215 } Best regards, Matthias > -----Original Message----- > From: Wang Weijun > Sent: Samstag, 8. September 2018 17:43 > To: Sean Mullan > Cc: Baesken, Matthias ; Alan Bateman > ; Chris Hegarty ; > security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > Thinking about this again. Looks like the absolute path is not necessary. Even > if there are multiple files using the same name, they will be in different > directories, no matter absolute or relative. Suppose the jarPath info is used > for debugging purpose mostly like the developer can find out what the > current working directory is and can find the files. *Matthias*: Is the absolute > path really necessary? Are you working on actual case? > > As for the possible global effect of a security property, maybe we can > emphasis that this is both a security property and system property, and if it?s > just for one time use, it?s better to use a system property. > > BTW, does the existing value ?hostInfo? of the property have a similar > problem? > > Thanks > Max > > >> ? 2018?9?8??21:42?Sean Mullan ? > ?? > >> > >> On 9/7/18 7:58 PM, Weijun Wang wrote: > >> In my understanding, the author deliberately wants to show the absolute > paths when there are multiple jar files with the same name (Ex: a jar hell). > > > > If you are very familiar with a particular application and understand the risks > associated with running it, then I agree that is ok. But security properties > apply to all applications using that JDK, and so I don't always think it is > practical for an admin to understand every type of application that may be > using that JDK and whether or not enabling this property presents a risk. > > > >> Maybe we can add some more detail in the java.security so an admin > knows what exact impact it has. > > > > It would be a slippery slope in my opinion. You would have to say > something like: "enabling this property may allow untrusted code running > under a SecurityManager to access sensitive information such as the > user.home system property even if it has not been granted permission to do > so." > > > > I think we should consider not allowing this property to take effect if a > SecurityManager is running. > > > > --Sean > > > >> --Max > >>> On Sep 8, 2018, at 3:41 AM, Sean Mullan > wrote: > >>> > >>> On 8/29/18 10:01 AM, Baesken, Matthias wrote: > >>>> Hi Max, thanks for your input . > >>>> I created another webrev , this contains now the suggested > SecurityProperties class : > >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/ > >>> > >>> java/util/jar/Attributes.java > >>> > >>> 469 return AccessController.doPrivileged(new > PrivilegedAction() { > >>> 470 public String run() { > >>> 471 return file.getAbsolutePath() + ":" + lineNumber; > >>> 472 } > >>> 473 }); > >>> > >>> I have a serious concern with the code above. > >>> > >>> With this change, untrusted code running under a SecurityManager > could potentially create a JarFile on a non-absolute path ex: "foo.jar", and > (somehow) cause an IOException to be thrown which would then reveal the > absolute path of where the jar was located, and thus could reveal sensitive > details about the system (ex: the user's home directory). It could still be hard > to exploit, since it would have to be a known jar that exists, and you would > then need to cause an IOException to be thrown, but it's still theoretically > possible. > >>> > >>> In short, this is a more general issue in that it may allow untrusted code > to access something it couldn't have previously. new > JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path. > >>> > >>> Granted this can only be done if the security property is enabled, but I > believe this is not something administrators should have to know about their > environment and account for when enabling this property. > >>> > >>> The above code should be changed to return only what the caller > provides to JarFile, which is the name of the file (without the full path). > >>> > >>> --Sean From christoph.langer at sap.com Mon Sep 10 08:04:25 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 10 Sep 2018 08:04:25 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> Message-ID: Hi Matthias, I think it would be enough to drop the privileged section and just return "filename" as is. (without conveting to a file object). I also agree with Sean that the common parts of the new src/java.base/share/classes/sun/security/util/SecurityProperties.java should be aligned with src/java.base/share/classes/sun/net/util/SocketExceptions.java (That is, SocketExceptions calling SecurityProperties) Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Baesken, Matthias > Sent: Montag, 10. September 2018 09:53 > To: Wang Weijun ; Sean Mullan > > Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: [CAUTION] RE: [RFR] 8205525 : Improve exception messages during > manifest parsing of jar archives > > Hello are you fine with changing from file.getAbsolutePath() to > file.getName() ? > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/src/java.base/s > hare/classes/java/util/jar/Manifest.java.frames.html > > > 206 static String getErrorPosition(String filename, final int lineNumber) { > 207 if (filename == null || !jarPathInExceptionText) { > 208 return "line " + lineNumber; > 209 } > 210 > 211 final File file = new File(filename); > 212 return AccessController.doPrivileged(new PrivilegedAction() > { > 213 public String run() { > 214 return "manifest of " + file.getName() + ":" + lineNumber; > 215 } > > > Best regards, Matthias > > > > -----Original Message----- > > From: Wang Weijun > > Sent: Samstag, 8. September 2018 17:43 > > To: Sean Mullan > > Cc: Baesken, Matthias ; Alan Bateman > > ; Chris Hegarty ; > > security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > > parsing of jar archives > > > > Thinking about this again. Looks like the absolute path is not necessary. > Even > > if there are multiple files using the same name, they will be in different > > directories, no matter absolute or relative. Suppose the jarPath info is used > > for debugging purpose mostly like the developer can find out what the > > current working directory is and can find the files. *Matthias*: Is the > absolute > > path really necessary? Are you working on actual case? > > > > As for the possible global effect of a security property, maybe we can > > emphasis that this is both a security property and system property, and if > it?s > > just for one time use, it?s better to use a system property. > > > > BTW, does the existing value ?hostInfo? of the property have a similar > > problem? > > > > Thanks > > Max > > > > >> ? 2018?9?8??21:42?Sean Mullan ? > > ?? > > >> > > >> On 9/7/18 7:58 PM, Weijun Wang wrote: > > >> In my understanding, the author deliberately wants to show the > absolute > > paths when there are multiple jar files with the same name (Ex: a jar hell). > > > > > > If you are very familiar with a particular application and understand the > risks > > associated with running it, then I agree that is ok. But security properties > > apply to all applications using that JDK, and so I don't always think it is > > practical for an admin to understand every type of application that may be > > using that JDK and whether or not enabling this property presents a risk. > > > > > >> Maybe we can add some more detail in the java.security so an admin > > knows what exact impact it has. > > > > > > It would be a slippery slope in my opinion. You would have to say > > something like: "enabling this property may allow untrusted code running > > under a SecurityManager to access sensitive information such as the > > user.home system property even if it has not been granted permission to > do > > so." > > > > > > I think we should consider not allowing this property to take effect if a > > SecurityManager is running. > > > > > > --Sean > > > > > >> --Max > > >>> On Sep 8, 2018, at 3:41 AM, Sean Mullan > > wrote: > > >>> > > >>> On 8/29/18 10:01 AM, Baesken, Matthias wrote: > > >>>> Hi Max, thanks for your input . > > >>>> I created another webrev , this contains now the suggested > > SecurityProperties class : > > >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/ > > >>> > > >>> java/util/jar/Attributes.java > > >>> > > >>> 469 return AccessController.doPrivileged(new > > PrivilegedAction() { > > >>> 470 public String run() { > > >>> 471 return file.getAbsolutePath() + ":" + lineNumber; > > >>> 472 } > > >>> 473 }); > > >>> > > >>> I have a serious concern with the code above. > > >>> > > >>> With this change, untrusted code running under a SecurityManager > > could potentially create a JarFile on a non-absolute path ex: "foo.jar", and > > (somehow) cause an IOException to be thrown which would then reveal > the > > absolute path of where the jar was located, and thus could reveal sensitive > > details about the system (ex: the user's home directory). It could still be > hard > > to exploit, since it would have to be a known jar that exists, and you would > > then need to cause an IOException to be thrown, but it's still theoretically > > possible. > > >>> > > >>> In short, this is a more general issue in that it may allow untrusted code > > to access something it couldn't have previously. new > > JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path. > > >>> > > >>> Granted this can only be done if the security property is enabled, but I > > believe this is not something administrators should have to know about > their > > environment and account for when enabling this property. > > >>> > > >>> The above code should be changed to return only what the caller > > provides to JarFile, which is the name of the file (without the full path). > > >>> > > >>> --Sean From matthias.baesken at sap.com Mon Sep 10 08:21:09 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 10 Sep 2018 08:21:09 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> Message-ID: > I think it would be enough to drop the privileged section and just return > "filename" as is. (without conveting to a file object). OK, any objections on this ? > I also agree with Sean that the common parts of the new > src/java.base/share/classes/sun/security/util/SecurityProperties.java should > be aligned with > src/java.base/share/classes/sun/net/util/SocketExceptions.java (That is, > SocketExceptions calling SecurityProperties) OK I will include this in the next webrev . Thanks, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 10. September 2018 10:04 > To: Baesken, Matthias ; Wang Weijun > ; Sean Mullan > Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: RE: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > Hi Matthias, > > I think it would be enough to drop the privileged section and just return > "filename" as is. (without conveting to a file object). > > I also agree with Sean that the common parts of the new > src/java.base/share/classes/sun/security/util/SecurityProperties.java should > be aligned with > src/java.base/share/classes/sun/net/util/SocketExceptions.java (That is, > SocketExceptions calling SecurityProperties) > > Best regards > Christoph > > > > -----Original Message----- > > From: core-libs-dev On Behalf > > Of Baesken, Matthias > > Sent: Montag, 10. September 2018 09:53 > > To: Wang Weijun ; Sean Mullan > > > > Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > > Subject: [CAUTION] RE: [RFR] 8205525 : Improve exception messages > during > > manifest parsing of jar archives > > > > Hello are you fine with changing from file.getAbsolutePath() to > > file.getName() ? > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/src/java.base/s > > hare/classes/java/util/jar/Manifest.java.frames.html > > > > > > 206 static String getErrorPosition(String filename, final int lineNumber) { > > 207 if (filename == null || !jarPathInExceptionText) { > > 208 return "line " + lineNumber; > > 209 } > > 210 > > 211 final File file = new File(filename); > > 212 return AccessController.doPrivileged(new > PrivilegedAction() > > { > > 213 public String run() { > > 214 return "manifest of " + file.getName() + ":" + lineNumber; > > 215 } > > > > > > Best regards, Matthias > > > > > > > -----Original Message----- > > > From: Wang Weijun > > > Sent: Samstag, 8. September 2018 17:43 > > > To: Sean Mullan > > > Cc: Baesken, Matthias ; Alan Bateman > > > ; Chris Hegarty > ; > > > security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > > > Subject: Re: [RFR] 8205525 : Improve exception messages during > manifest > > > parsing of jar archives > > > > > > Thinking about this again. Looks like the absolute path is not necessary. > > Even > > > if there are multiple files using the same name, they will be in different > > > directories, no matter absolute or relative. Suppose the jarPath info is > used > > > for debugging purpose mostly like the developer can find out what the > > > current working directory is and can find the files. *Matthias*: Is the > > absolute > > > path really necessary? Are you working on actual case? > > > > > > As for the possible global effect of a security property, maybe we can > > > emphasis that this is both a security property and system property, and if > > it?s > > > just for one time use, it?s better to use a system property. > > > > > > BTW, does the existing value ?hostInfo? of the property have a similar > > > problem? > > > > > > Thanks > > > Max > > > > > > >> ? 2018?9?8??21:42?Sean Mullan > ? > > > ?? > > > >> > > > >> On 9/7/18 7:58 PM, Weijun Wang wrote: > > > >> In my understanding, the author deliberately wants to show the > > absolute > > > paths when there are multiple jar files with the same name (Ex: a jar > hell). > > > > > > > > If you are very familiar with a particular application and understand the > > risks > > > associated with running it, then I agree that is ok. But security properties > > > apply to all applications using that JDK, and so I don't always think it is > > > practical for an admin to understand every type of application that may > be > > > using that JDK and whether or not enabling this property presents a risk. > > > > > > > >> Maybe we can add some more detail in the java.security so an admin > > > knows what exact impact it has. > > > > > > > > It would be a slippery slope in my opinion. You would have to say > > > something like: "enabling this property may allow untrusted code running > > > under a SecurityManager to access sensitive information such as the > > > user.home system property even if it has not been granted permission to > > do > > > so." > > > > > > > > I think we should consider not allowing this property to take effect if a > > > SecurityManager is running. > > > > > > > > --Sean > > > > > > > >> --Max > > > >>> On Sep 8, 2018, at 3:41 AM, Sean Mullan > > > wrote: > > > >>> > > > >>> On 8/29/18 10:01 AM, Baesken, Matthias wrote: > > > >>>> Hi Max, thanks for your input . > > > >>>> I created another webrev , this contains now the suggested > > > SecurityProperties class : > > > >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/ > > > >>> > > > >>> java/util/jar/Attributes.java > > > >>> > > > >>> 469 return AccessController.doPrivileged(new > > > PrivilegedAction() { > > > >>> 470 public String run() { > > > >>> 471 return file.getAbsolutePath() + ":" + lineNumber; > > > >>> 472 } > > > >>> 473 }); > > > >>> > > > >>> I have a serious concern with the code above. > > > >>> > > > >>> With this change, untrusted code running under a SecurityManager > > > could potentially create a JarFile on a non-absolute path ex: "foo.jar", and > > > (somehow) cause an IOException to be thrown which would then reveal > > the > > > absolute path of where the jar was located, and thus could reveal > sensitive > > > details about the system (ex: the user's home directory). It could still be > > hard > > > to exploit, since it would have to be a known jar that exists, and you > would > > > then need to cause an IOException to be thrown, but it's still theoretically > > > possible. > > > >>> > > > >>> In short, this is a more general issue in that it may allow untrusted > code > > > to access something it couldn't have previously. new > > > JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path. > > > >>> > > > >>> Granted this can only be done if the security property is enabled, but > I > > > believe this is not something administrators should have to know about > > their > > > environment and account for when enabling this property. > > > >>> > > > >>> The above code should be changed to return only what the caller > > > provides to JarFile, which is the name of the file (without the full path). > > > >>> > > > >>> --Sean > From matthias.baesken at sap.com Mon Sep 10 13:59:08 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 10 Sep 2018 13:59:08 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> Message-ID: New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.9/ - SocketExceptions class has been adjusted to new sun.security.util.SecurityProperties - Attributes getErrorPosition adjusted (see proposal of Christoph " I think it would be enough to drop the privileged section and just return "filename" as is.) After the changes I wonder - should the jarPath category be renamed to jarFile (or something else) ? Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 10. September 2018 10:04 > To: Baesken, Matthias ; Wang Weijun > ; Sean Mullan > Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: RE: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > Hi Matthias, > > I think it would be enough to drop the privileged section and just return > "filename" as is. (without conveting to a file object). > > I also agree with Sean that the common parts of the new > src/java.base/share/classes/sun/security/util/SecurityProperties.java should > be aligned with > src/java.base/share/classes/sun/net/util/SocketExceptions.java (That is, > SocketExceptions calling SecurityProperties) > > Best regards > Christoph > > > > -----Original Message----- > > From: core-libs-dev On Behalf > > Of Baesken, Matthias > > Sent: Montag, 10. September 2018 09:53 > > To: Wang Weijun ; Sean Mullan > > > > Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > > Subject: [CAUTION] RE: [RFR] 8205525 : Improve exception messages > during > > manifest parsing of jar archives > > > > Hello are you fine with changing from file.getAbsolutePath() to > > file.getName() ? > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/src/java.base/s > > hare/classes/java/util/jar/Manifest.java.frames.html > > > > > > 206 static String getErrorPosition(String filename, final int lineNumber) { > > 207 if (filename == null || !jarPathInExceptionText) { > > 208 return "line " + lineNumber; > > 209 } > > 210 > > 211 final File file = new File(filename); > > 212 return AccessController.doPrivileged(new > PrivilegedAction() > > { > > 213 public String run() { > > 214 return "manifest of " + file.getName() + ":" + lineNumber; > > 215 } > > > > > > Best regards, Matthias > > > > > > > -----Original Message----- > > > From: Wang Weijun > > > Sent: Samstag, 8. September 2018 17:43 > > > To: Sean Mullan > > > Cc: Baesken, Matthias ; Alan Bateman > > > ; Chris Hegarty > ; > > > security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > > > Subject: Re: [RFR] 8205525 : Improve exception messages during > manifest > > > parsing of jar archives > > > > > > Thinking about this again. Looks like the absolute path is not necessary. > > Even > > > if there are multiple files using the same name, they will be in different > > > directories, no matter absolute or relative. Suppose the jarPath info is > used > > > for debugging purpose mostly like the developer can find out what the > > > current working directory is and can find the files. *Matthias*: Is the > > absolute > > > path really necessary? Are you working on actual case? > > > > > > As for the possible global effect of a security property, maybe we can > > > emphasis that this is both a security property and system property, and if > > it?s > > > just for one time use, it?s better to use a system property. > > > > > > BTW, does the existing value ?hostInfo? of the property have a similar > > > problem? > > > > > > Thanks > > > Max > > > > > > >> ? 2018?9?8??21:42?Sean Mullan > ? > > > ?? > > > >> > > > >> On 9/7/18 7:58 PM, Weijun Wang wrote: > > > >> In my understanding, the author deliberately wants to show the > > absolute > > > paths when there are multiple jar files with the same name (Ex: a jar > hell). > > > > > > > > If you are very familiar with a particular application and understand the > > risks > > > associated with running it, then I agree that is ok. But security properties > > > apply to all applications using that JDK, and so I don't always think it is > > > practical for an admin to understand every type of application that may > be > > > using that JDK and whether or not enabling this property presents a risk. > > > > > > > >> Maybe we can add some more detail in the java.security so an admin > > > knows what exact impact it has. > > > > > > > > It would be a slippery slope in my opinion. You would have to say > > > something like: "enabling this property may allow untrusted code running > > > under a SecurityManager to access sensitive information such as the > > > user.home system property even if it has not been granted permission to > > do > > > so." > > > > > > > > I think we should consider not allowing this property to take effect if a > > > SecurityManager is running. > > > > > > > > --Sean > > > > > > > >> --Max > > > >>> On Sep 8, 2018, at 3:41 AM, Sean Mullan > > > wrote: > > > >>> > > > >>> On 8/29/18 10:01 AM, Baesken, Matthias wrote: > > > >>>> Hi Max, thanks for your input . > > > >>>> I created another webrev , this contains now the suggested > > > SecurityProperties class : > > > >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/ > > > >>> > > > >>> java/util/jar/Attributes.java > > > >>> > > > >>> 469 return AccessController.doPrivileged(new > > > PrivilegedAction() { > > > >>> 470 public String run() { > > > >>> 471 return file.getAbsolutePath() + ":" + lineNumber; > > > >>> 472 } > > > >>> 473 }); > > > >>> > > > >>> I have a serious concern with the code above. > > > >>> > > > >>> With this change, untrusted code running under a SecurityManager > > > could potentially create a JarFile on a non-absolute path ex: "foo.jar", and > > > (somehow) cause an IOException to be thrown which would then reveal > > the > > > absolute path of where the jar was located, and thus could reveal > sensitive > > > details about the system (ex: the user's home directory). It could still be > > hard > > > to exploit, since it would have to be a known jar that exists, and you > would > > > then need to cause an IOException to be thrown, but it's still theoretically > > > possible. > > > >>> > > > >>> In short, this is a more general issue in that it may allow untrusted > code > > > to access something it couldn't have previously. new > > > JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path. > > > >>> > > > >>> Granted this can only be done if the security property is enabled, but > I > > > believe this is not something administrators should have to know about > > their > > > environment and account for when enabling this property. > > > >>> > > > >>> The above code should be changed to return only what the caller > > > provides to JarFile, which is the name of the file (without the full path). > > > >>> > > > >>> --Sean > From sean.mullan at oracle.com Mon Sep 10 14:24:29 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 10 Sep 2018 10:24:29 -0400 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.com> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> Message-ID: On 9/8/18 11:42 AM, Wang Weijun wrote: > Thinking about this again. Looks like the absolute path is not necessary. Even if there are multiple files using the same name, they will be in different directories, no matter absolute or relative. Suppose the jarPath info is used for debugging purpose mostly like the developer can find out what the current working directory is and can find the files. *Matthias*: Is the absolute path really necessary? Are you working on actual case? > > As for the possible global effect of a security property, maybe we can emphasis that this is both a security property and system property, and if it?s just for one time use, it?s better to use a system property. > > BTW, does the existing value ?hostInfo? of the property have a similar problem? No. In that case, the sensitive data (IP address) is provided by the caller, so there is no leakage of sensitive data from trusted code that it is calling. --Sean From sean.mullan at oracle.com Mon Sep 10 14:26:07 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 10 Sep 2018 10:26:07 -0400 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> Message-ID: <4adc8e90-a307-380c-3535-e4201bf60311@oracle.com> On 9/10/18 4:21 AM, Baesken, Matthias wrote: >> I think it would be enough to drop the privileged section and just return >> "filename" as is. (without conveting to a file object). > > OK, any objections on this ? No, this is fine with me. --Sean From weijun.wang at oracle.com Mon Sep 10 14:31:25 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 10 Sep 2018 22:31:25 +0800 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <943590a6-9adc-7cb2-937b-4fbd8203cd8b@oracle.com> <6cfa4b0266de4fdf85d6c959c450043c@sap.com> <00ab9b6f-f1c2-19b1-eccf-62b49794682f@oracle.com> <60acb2950d9147e5adc8e246de7d7b08@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> Message-ID: <9E7E3778-37D4-4ACF-8892-854783B54997@oracle.com> > On Sep 10, 2018, at 9:59 PM, Baesken, Matthias wrote: > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.9/ Looks fine to me. > > - SocketExceptions class has been adjusted to new sun.security.util.SecurityProperties > - Attributes getErrorPosition adjusted (see proposal of Christoph " I think it would be enough to drop the privileged section and just return "filename" as is.) > > After the changes I wonder - should the jarPath category be renamed to jarFile (or something else) ? jarFile seems to be an instance of JarFile. I don't think jarPath has any problem. Thanks Max > > > Best regards, Matthias > >> -----Original Message----- >> From: Langer, Christoph >> Sent: Montag, 10. September 2018 10:04 >> To: Baesken, Matthias ; Wang Weijun >> ; Sean Mullan >> Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> Subject: RE: [RFR] 8205525 : Improve exception messages during manifest >> parsing of jar archives >> >> Hi Matthias, >> >> I think it would be enough to drop the privileged section and just return >> "filename" as is. (without conveting to a file object). >> >> I also agree with Sean that the common parts of the new >> src/java.base/share/classes/sun/security/util/SecurityProperties.java should >> be aligned with >> src/java.base/share/classes/sun/net/util/SocketExceptions.java (That is, >> SocketExceptions calling SecurityProperties) >> >> Best regards >> Christoph >> >> >>> -----Original Message----- >>> From: core-libs-dev On Behalf >>> Of Baesken, Matthias >>> Sent: Montag, 10. September 2018 09:53 >>> To: Wang Weijun ; Sean Mullan >>> >>> Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >>> Subject: [CAUTION] RE: [RFR] 8205525 : Improve exception messages >> during >>> manifest parsing of jar archives >>> >>> Hello are you fine with changing from file.getAbsolutePath() to >>> file.getName() ? >>> >>> >>> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/src/java.base/s >>> hare/classes/java/util/jar/Manifest.java.frames.html >>> >>> >>> 206 static String getErrorPosition(String filename, final int lineNumber) { >>> 207 if (filename == null || !jarPathInExceptionText) { >>> 208 return "line " + lineNumber; >>> 209 } >>> 210 >>> 211 final File file = new File(filename); >>> 212 return AccessController.doPrivileged(new >> PrivilegedAction() >>> { >>> 213 public String run() { >>> 214 return "manifest of " + file.getName() + ":" + lineNumber; >>> 215 } >>> >>> >>> Best regards, Matthias >>> >>> >>>> -----Original Message----- >>>> From: Wang Weijun >>>> Sent: Samstag, 8. September 2018 17:43 >>>> To: Sean Mullan >>>> Cc: Baesken, Matthias ; Alan Bateman >>>> ; Chris Hegarty >> ; >>>> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >>>> Subject: Re: [RFR] 8205525 : Improve exception messages during >> manifest >>>> parsing of jar archives >>>> >>>> Thinking about this again. Looks like the absolute path is not necessary. >>> Even >>>> if there are multiple files using the same name, they will be in different >>>> directories, no matter absolute or relative. Suppose the jarPath info is >> used >>>> for debugging purpose mostly like the developer can find out what the >>>> current working directory is and can find the files. *Matthias*: Is the >>> absolute >>>> path really necessary? Are you working on actual case? >>>> >>>> As for the possible global effect of a security property, maybe we can >>>> emphasis that this is both a security property and system property, and if >>> it?s >>>> just for one time use, it?s better to use a system property. >>>> >>>> BTW, does the existing value ?hostInfo? of the property have a similar >>>> problem? >>>> >>>> Thanks >>>> Max >>>> >>>>>> ? 2018?9?8??21:42?Sean Mullan >> ? >>>> ?? >>>>>> >>>>>> On 9/7/18 7:58 PM, Weijun Wang wrote: >>>>>> In my understanding, the author deliberately wants to show the >>> absolute >>>> paths when there are multiple jar files with the same name (Ex: a jar >> hell). >>>>> >>>>> If you are very familiar with a particular application and understand the >>> risks >>>> associated with running it, then I agree that is ok. But security properties >>>> apply to all applications using that JDK, and so I don't always think it is >>>> practical for an admin to understand every type of application that may >> be >>>> using that JDK and whether or not enabling this property presents a risk. >>>>> >>>>>> Maybe we can add some more detail in the java.security so an admin >>>> knows what exact impact it has. >>>>> >>>>> It would be a slippery slope in my opinion. You would have to say >>>> something like: "enabling this property may allow untrusted code running >>>> under a SecurityManager to access sensitive information such as the >>>> user.home system property even if it has not been granted permission to >>> do >>>> so." >>>>> >>>>> I think we should consider not allowing this property to take effect if a >>>> SecurityManager is running. >>>>> >>>>> --Sean >>>>> >>>>>> --Max >>>>>>> On Sep 8, 2018, at 3:41 AM, Sean Mullan >>>> wrote: >>>>>>> >>>>>>> On 8/29/18 10:01 AM, Baesken, Matthias wrote: >>>>>>>> Hi Max, thanks for your input . >>>>>>>> I created another webrev , this contains now the suggested >>>> SecurityProperties class : >>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/ >>>>>>> >>>>>>> java/util/jar/Attributes.java >>>>>>> >>>>>>> 469 return AccessController.doPrivileged(new >>>> PrivilegedAction() { >>>>>>> 470 public String run() { >>>>>>> 471 return file.getAbsolutePath() + ":" + lineNumber; >>>>>>> 472 } >>>>>>> 473 }); >>>>>>> >>>>>>> I have a serious concern with the code above. >>>>>>> >>>>>>> With this change, untrusted code running under a SecurityManager >>>> could potentially create a JarFile on a non-absolute path ex: "foo.jar", and >>>> (somehow) cause an IOException to be thrown which would then reveal >>> the >>>> absolute path of where the jar was located, and thus could reveal >> sensitive >>>> details about the system (ex: the user's home directory). It could still be >>> hard >>>> to exploit, since it would have to be a known jar that exists, and you >> would >>>> then need to cause an IOException to be thrown, but it's still theoretically >>>> possible. >>>>>>> >>>>>>> In short, this is a more general issue in that it may allow untrusted >> code >>>> to access something it couldn't have previously. new >>>> JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path. >>>>>>> >>>>>>> Granted this can only be done if the security property is enabled, but >> I >>>> believe this is not something administrators should have to know about >>> their >>>> environment and account for when enabling this property. >>>>>>> >>>>>>> The above code should be changed to return only what the caller >>>> provides to JarFile, which is the name of the file (without the full path). >>>>>>> >>>>>>> --Sean >> > From sean.mullan at oracle.com Mon Sep 10 14:35:18 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 10 Sep 2018 10:35:18 -0400 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> Message-ID: <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> On 9/10/18 9:59 AM, Baesken, Matthias wrote: > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.9/ > > > - SocketExceptions class has been adjusted to new sun.security.util.SecurityProperties > - Attributes getErrorPosition adjusted (see proposal of Christoph " I think it would be enough to drop the privileged section and just return "filename" as is.) > > After the changes I wonder - should the jarPath category be renamed to jarFile (or something else) ? Yes, renaming it to "jarFile" makes more sense. You will need to update the CSR with this change too. A few other comments: - java/util/jar/Manifest.java 62 // name of the corresponding jar archive if available. 63 private String jarFilename; You can mark this final. - sun/net/util/SocketExceptions.java 33 import java.security.Security; This import is no longer needed. --Sean From weijun.wang at oracle.com Mon Sep 10 14:42:50 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 10 Sep 2018 22:42:50 +0800 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> Message-ID: <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> > On Sep 10, 2018, at 10:35 PM, Sean Mullan wrote: > >> After the changes I wonder - should the jarPath category be renamed to jarFile (or something else) ? > > Yes, renaming it to "jarFile" makes more sense. You will need to update the CSR with this change too. Well, maybe either is OK. I am still thinking that one day we could make this more precise, for example: /path/to/lib.jar!META-INF/MANIFEST.MF:23 /path/to/lib.jar!META-INF/SIGNER.SF:34 The name should (at least vaguely) cover these info. --Max From christoph.langer at sap.com Mon Sep 10 14:46:58 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 10 Sep 2018 14:46:58 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> Message-ID: Hi Sean, Max, do you think we need property jdk.includeInExceptions=jar at all, if we don't resolve the absolute path? @Matthias: small remark to the code: src/java.base/share/classes/sun/security/util/SecurityProperties.java 36 public static String privilegeGetOverridable(String propName) { Should that method really be public? At the moment it doesn't seem to be used outside of SecurityProperties. Best regards Christoph > -----Original Message----- > From: Weijun Wang > Sent: Montag, 10. September 2018 16:43 > To: Sean Mullan > Cc: Baesken, Matthias ; Langer, Christoph > ; security-dev at openjdk.java.net; core-libs- > dev at openjdk.java.net > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > > > > On Sep 10, 2018, at 10:35 PM, Sean Mullan > wrote: > > > >> After the changes I wonder - should the jarPath category be renamed > to jarFile (or something else) ? > > > > Yes, renaming it to "jarFile" makes more sense. You will need to update the > CSR with this change too. > > Well, maybe either is OK. > > I am still thinking that one day we could make this more precise, for example: > > /path/to/lib.jar!META-INF/MANIFEST.MF:23 > /path/to/lib.jar!META-INF/SIGNER.SF:34 > > The name should (at least vaguely) cover these info. > > --Max From weijun.wang at oracle.com Mon Sep 10 14:57:15 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 10 Sep 2018 22:57:15 +0800 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> Message-ID: <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com> > On Sep 10, 2018, at 10:46 PM, Langer, Christoph wrote: > > Hi Sean, Max, > > do you think we need property jdk.includeInExceptions=jar at all, if we don't resolve the absolute path? I think so. File path is still sensitive. In fact, I tend to believe people usually use absolute paths for JAR files (or maybe made absolute by using a file:// URL somewhere inside JDK). Do you really see relative jar paths while testing this code change? > > @Matthias: > small remark to the code: > src/java.base/share/classes/sun/security/util/SecurityProperties.java > 36 public static String privilegeGetOverridable(String propName) { > > Should that method really be public? At the moment it doesn't seem to be used outside of SecurityProperties. I like it to be public. There are quite some other such system/security properties (Ex: jdk.serialFilter) that can make use of this method. Thanks Max > > Best regards > Christoph From adam.petcher at oracle.com Mon Sep 10 15:14:43 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 10 Sep 2018 11:14:43 -0400 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: <16b4291f-b119-2a4e-883e-06dfe30fc6c9@oracle.com> References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> <486a8d33-f4d6-8bcd-3123-3b4b3ef411df@oracle.com> <7589d254-7e2c-1b63-1d3e-10d74cbf4684@oracle.com> <0a33a03c-3408-463b-458a-6d2754742d52@oracle.com> <0b163b6f-fac7-5273-b176-d641509ea5cb@oracle.com> <16b4291f-b119-2a4e-883e-06dfe30fc6c9@oracle.com> Message-ID: <81a6942a-1099-ebfe-178a-3b1a6d76398e@oracle.com> Xuelei, Here is the latest webrev: http://cr.openjdk.java.net/~apetcher/8171279/webrev.04/ I modified the TLS implementation so that it uses X509EncodedKeySpec when interacting with the provider. I did a small amount of refactoring in X509Key to expose the functionality I needed to do this. This change removed the dependency on XECParameters, and I moved it back into jdk.crypto.ec. I also moved some more functions into NamedGroup (e.g. isAvailableGroup). This webrev also has the change to NamedGroup that makes NamedGroupFunctions private. I put the NamedGroup enum into its own file, which I think is reasonable because it is used in several places other than SupportedGroupsExtension. It also makes sense to separate all of the known named groups and their properties (NamedGroups.java) from the supported_groups extension and the logic related to which groups are supported for key exchange (SupportedGroupsExtension.java). This change required changes to the import statements of several files. I'm not totally sure I understood your concern related to the AlgorithmParameters map. The map is always created, but we only create and cache parameters when they are first needed. Of course, the map is not a proper cache, and the objects stay in memory forever once they are created. Is this your concern, or is it something else? I've made several structural changes since the first webrev, and I haven't been paying too close attention to style, so you probably shouldn't either. Once the approach and structure look good to you, I can clean up the code and submit another webrev so you can check it for style, formatting, etc. I also haven't merged in changes from the default branch in a while, so I'll need to do that, too. On 9/7/2018 12:12 PM, Xuelei Fan wrote: > On 9/7/2018 9:03 AM, Adam Petcher wrote: >> This is more clear, thanks. See below. >> >> >> On 9/7/2018 11:34 AM, Xuelei Fan wrote: >>> EncodedKeySpec keySpec = ... // find a way to construct the keySpec >>> ???????????????????????????? // at least, we can use: >>> ???????????????????????????? //??? new EncodedKeySpec(byte[]); >>> ???????????????????????????? // But please check if there's a better >>> one >> >> Do you mean X509EncodedKeySpec, or some class that is specific to XDH? > I did not search the spec definitions.? At least we can use the > EncodedKeySpec class.?? It's nice if you can find a better one, or > define a new one for XDH. > > Your following comments make sense to me. > > Thanks, > Xuelei > >> An X509EncodedKeySpec would probably work---we would just need to put >> the key into a SubjectPublicKeyInfo, which means I need the OID. Is >> it okay for me to put the OID in JSSE? I could put it in the >> NamedGroup enum, like this: >> >> ???? X25519????? (0x001D, "x25519", true, "x25519", "1.3.101.110", >> ???????? ProtocolVersion.PROTOCOLS_TO_13), >> ???? X448??????? (0x001E, "x448", true, "x448", "1.3.101.111", >> ???????? ProtocolVersion.PROTOCOLS_TO_13), >> >> I'm not sure if the second x25519/x448 strings (for algorithm and >> NamedParameterSpec names) would still be needed, since I can use the >> OID in some of these places. If it's not needed, then perhaps I can >> remove it and only use the OID to interact with the JCA provider. >> >> We don't have a type for XDH encoded public keys. It would be nice to >> be able to do something simple like: >> >> byte[] keyBytes = ... >> NamedParameterSpec paramSpec = new NamedParameterSpec("X25519"); >> XECEncodedPublicKeySpec keySpec = new XECEncodedKeySpec(paramSpec, >> keyBytes); >> >> and then give keySpec to the "XDH" key factory. But this >> XECEncodedKeySpec type does not exist, so this would require an >> enhancement to the API. From adam.petcher at oracle.com Mon Sep 10 15:50:05 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 10 Sep 2018 11:50:05 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <65FD868B-4AC2-4CFE-9C19-5319489634CC@oracle.com> Message-ID: <6186d731-076d-307e-d401-2196788cf839@oracle.com> See inline below. It also occurred to me that we could use Provider properties here. We have the "ImplementedIn" property, and we can similarly add a standard "Branchless" property. I think my preferred solution is still to use separate providers, and perhaps use a read-only "Branchless" property to aid in provider selection. That is, JCA client code that supports the branchless API (that is, no BigInteger) could loop through the providers until it finds one with the "Branchless" property set. This same mechanism could be used to select a provider that allows branching in an environment where the highest-priority provider is branchless. We may also be able to set the "Branchless" property at runtime to influence the behavior of a single provider. But this would introduce a lot of complication, and I think it is starting to get away from the intended use of these properties. On 9/7/2018 7:07 PM, Anthony Scarpino wrote: >> On Sep 7, 2018, at 12:08 PM, Adam Petcher wrote: >> >> This is a good suggestion. I don't have particularly strong feelings about using separate providers vs a property in a single provider. I think the fundamental issues are the same, and this choice mostly affects API details. >> >> Do you think this should be a system property, security property, or something else? Should it be modifiable at any time? > I would say a security property > >> Perhaps it has to be in order to address Mike's desire to put the provider in "import/export mode". Would the property affect existing keys? Again, I think it would have to, so you can generate a key, turn off branchless mode, and then export it. > My thought was the property would allow the branchless import/export for that java instance. Not turning it on and off during operations. I think the value of the branchless operation is in the usage of the algorithms. If an app wants to use a pure branchless provider the property can be set or never use the APIs with BigInteger in them. > > One could avoid the property completely by just documenting clearly the interfaces that branched and then leave it to the app developer, but from the email discussion with Mike it sounded like you preferred strong controls on the provider. The issues related to branching are too subtle, and I don't think we should expose any of it to the developer except "use this provider/property/algorithm to indicate that branching on secrets is unacceptable." Moreover, I'm intimately familiar with all of these issue, and yet I still don't have confidence in my own ability to switch SunJSSE over to using a branchless ECC implementation, unless I have strong enforcement in the provider. It would be too easy for me to simply miss an existing call to getS() or a use of ECPrivateKeySpec. If we only have a single provider, and a security property that has been set to indicate that branching is unacceptable in that provider, then I think that means that there is no way to change the value of the property and use private keys as BigInteger in that JVM process without using some other (third party) provider. Though maybe I'm misunderstanding something about your proposal. > >> What about curves other than P256, P384, and P521? We can't do branchless operations in those curves, so any attempt to use them when this property is enabled would result in an exception. > I wasn?t going to propose anything further than your existing curves, but it would be nice if branchful curves could be added to eventual replace SunEC. I know that isn?t the intent of this JEP and depends if you want to expand it. Sure, but for this JEP, we need to be concerned about how the API can be misused, and a branching implementation is obtained when a branchless one is expected. The developer shouldn't be expected to know that three of the curves have branchless implementations, and using any other curve will result in branching. So any global "don't branch" property would need to cause the use of any other curve to fail. From xuelei.fan at oracle.com Mon Sep 10 17:13:08 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 10 Sep 2018 10:13:08 -0700 Subject: RFR 8171279: Support X25519 and X448 in TLS 1.3 In-Reply-To: <81a6942a-1099-ebfe-178a-3b1a6d76398e@oracle.com> References: <72284379-0896-84e5-900e-49f56445b2b1@oracle.com> <2f0860b4-2108-313a-a5e3-8b1ad6e41f31@oracle.com> <3b378c70-9bae-d8f7-08cd-865a22891af2@oracle.com> <1c74b748-f3c6-19fd-5223-65fa2ceb3227@oracle.com> <09147bc0-e691-c955-d179-9aa0e343c003@oracle.com> <486a8d33-f4d6-8bcd-3123-3b4b3ef411df@oracle.com> <7589d254-7e2c-1b63-1d3e-10d74cbf4684@oracle.com> <0a33a03c-3408-463b-458a-6d2754742d52@oracle.com> <0b163b6f-fac7-5273-b176-d641509ea5cb@oracle.com> <16b4291f-b119-2a4e-883e-06dfe30fc6c9@oracle.com> <81a6942a-1099-ebfe-178a-3b1a6d76398e@oracle.com> Message-ID: <51c4c052-7882-8f58-edff-0e31bff44f0b@oracle.com> On 9/10/2018 8:14 AM, Adam Petcher wrote: > Xuelei, > > Here is the latest webrev: > http://cr.openjdk.java.net/~apetcher/8171279/webrev.04/ > > I modified the TLS implementation so that it uses X509EncodedKeySpec > when interacting with the provider. I did a small amount of refactoring > in X509Key to expose the functionality I needed to do this. I don't think it is not straightforward choice to us X509EncodedKeySpec. We have to use the right OID, and make sure the key bytes for X.509 protocols are exactly the same as TLS. Not mention to the cost to add the OID and remove the OID. Maybe, using EncodedKeySpec is more simple. package sun.security.ssl; private class XDHEncodeKeySpec extension EncodedKeySpec { // algorithm: x25519 or x448 XDHEncodeKeySpec(byte[] encodedKey, String algorithm) { super(encodedKey, algorithm); } @Override String getFormat() { return "raw"; } ... } package sun.security.ec; public class XDHKeyFactory extends KeyFactorySpi { private PublicKey generatePublicImpl(KeySpec keySpec) throws InvalidKeyException, InvalidKeySpecException { ... } else if (keySpec instanceof EncodedKeySpec && encodedKeySpec.getAlgorithm() is "x25519" && encodedKeySpec.getFormat is "raw") { // raw public key byte[] radPublicKey = encodedKeySpec.getEncoded(); } else { } } } > This change > removed the dependency on XECParameters, and I moved it back into > jdk.crypto.ec. I also moved some more functions into NamedGroup (e.g. > isAvailableGroup). > > This webrev also has the change to NamedGroup that makes > NamedGroupFunctions private. I put the NamedGroup enum into its own > file, which I think is reasonable because it is used in several places > other than SupportedGroupsExtension. It also makes sense to separate all > of the known named groups and their properties (NamedGroups.java) from > the supported_groups extension and the logic related to which groups are > supported for key exchange (SupportedGroupsExtension.java). This change > required changes to the import statements of several files. > They do not sound like good reasons to me. You may not want to do that again if you understand the following questions you have. > I'm not totally sure I understood your concern related to the > AlgorithmParameters map. The map is always created, but we only create > and cache parameters when they are first needed. In the current implementation, there is only one map and the parameters are not create unless they are supported. In your implementation, there are three maps, which are created always, even if FFDHE/XDH is not supported. This is a minor issue to me. If I did not miss something, in your implementation, the parameters can be created and push to the map even it is not supported? Am I right? We used to try avoid to generate parameters for unsupported groups. > Of course, the map is > not a proper cache, and the objects stay in memory forever once they are > created. Is this your concern, or is it something else? > > I've made several structural changes since the first webrev, and I > haven't been paying too close attention to style, so you probably > shouldn't either. Once the approach and structure look good to you, I > can clean up the code and submit another webrev so you can check it for > style, formatting, etc. I also haven't merged in changes from the > default branch in a while, so I'll need to do that, too. > Yes, let's work out the big picture at first. Help it helps. Xuelei > > On 9/7/2018 12:12 PM, Xuelei Fan wrote: >> On 9/7/2018 9:03 AM, Adam Petcher wrote: >>> This is more clear, thanks. See below. >>> >>> >>> On 9/7/2018 11:34 AM, Xuelei Fan wrote: >>>> EncodedKeySpec keySpec = ... // find a way to construct the keySpec >>>> ???????????????????????????? // at least, we can use: >>>> ???????????????????????????? //??? new EncodedKeySpec(byte[]); >>>> ???????????????????????????? // But please check if there's a better >>>> one >>> >>> Do you mean X509EncodedKeySpec, or some class that is specific to XDH? >> I did not search the spec definitions.? At least we can use the >> EncodedKeySpec class.?? It's nice if you can find a better one, or >> define a new one for XDH. >> >> Your following comments make sense to me. >> >> Thanks, >> Xuelei >> >>> An X509EncodedKeySpec would probably work---we would just need to put >>> the key into a SubjectPublicKeyInfo, which means I need the OID. Is >>> it okay for me to put the OID in JSSE? I could put it in the >>> NamedGroup enum, like this: >>> >>> ???? X25519????? (0x001D, "x25519", true, "x25519", "1.3.101.110", >>> ???????? ProtocolVersion.PROTOCOLS_TO_13), >>> ???? X448??????? (0x001E, "x448", true, "x448", "1.3.101.111", >>> ???????? ProtocolVersion.PROTOCOLS_TO_13), >>> >>> I'm not sure if the second x25519/x448 strings (for algorithm and >>> NamedParameterSpec names) would still be needed, since I can use the >>> OID in some of these places. If it's not needed, then perhaps I can >>> remove it and only use the OID to interact with the JCA provider. >>> >>> We don't have a type for XDH encoded public keys. It would be nice to >>> be able to do something simple like: >>> >>> byte[] keyBytes = ... >>> NamedParameterSpec paramSpec = new NamedParameterSpec("X25519"); >>> XECEncodedPublicKeySpec keySpec = new XECEncodedKeySpec(paramSpec, >>> keyBytes); >>> >>> and then give keySpec to the "XDH" key factory. But this >>> XECEncodedKeySpec type does not exist, so this would require an >>> enhancement to the API. > From xuelei.fan at oracle.com Mon Sep 10 18:23:18 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 10 Sep 2018 11:23:18 -0700 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> Message-ID: Can I have the links to the new formulas that you will be used? Are they part of any current standards? Thanks, Xuelei On 8/23/2018 10:50 AM, Adam Petcher wrote: > I'm starting work on yet another ECC JEP[1], this time with the goal of > developing improved implementations of existing algorithms, rather than > implementing new ones. The JEP will re-implement ECDH and ECDSA for the > 256-, 384-, and 521-bit NIST prime curves. The new implementation will > be all Java, and will resist side-channel attacks by not branching on > secrets. It will go in a new provider which is not in the provider list > in the java.security file by default. So it will need to be manually > enabled by changing the configuration or putting the new provider name > in the code. It will only support a subset of the API that is supported > by the implementation in SunEC. In particular, it will reject any > private keys with scalar values specified using BigInteger (as in > ECPrivateKeySpec), and its private keys will not return scalar values as > BigInteger (as in ECPrivateKey.getS()). > > Please take a look and send me any feedback you have. I'm especially > looking for suggestions on how this new implementation should fit into > the API. I would prefer to have it enabled by default, but I can't think > of a way to do that without either branching on secrets in some cases > (converting a BigInteger private key to an array) or breaking > compatibility (throwing an exception when it gets a BigInteger private > key). > > [1] https://bugs.openjdk.java.net/browse/JDK-8204574 > From sean.mullan at oracle.com Mon Sep 10 19:11:52 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 10 Sep 2018 15:11:52 -0400 Subject: RFR 8205507: jdk/javax/xml/crypto/dsig/GenerationTests.java timed out In-Reply-To: <59413F33-F156-425E-B348-75C0AC83F497@oracle.com> References: <59413F33-F156-425E-B348-75C0AC83F497@oracle.com> Message-ID: <65b12687-352b-2dc4-fe4a-6277c487f2e9@oracle.com> On 9/7/18 9:31 PM, Weijun Wang wrote: > Please review the change at > > http://cr.openjdk.java.net/~weijun/8205507/webrev.00/ Looks good. --Sean > > Here I cached the keys for each signature method. Running 100 times on solaris-sparcv9 and the longest duration is 10 minutes, much shorter than the timeout threshold of 50 mins. > > I didn't hardcoded the keys because I'm afraid some keys might fail (this happened before, for example, if first byte of key is zero). With a cache, and especially the keys persisted into a file, we gain both randomness (although not as random as before) and reproducibility. > > Noreg-self. > > Thanks > Max > From christoph.langer at sap.com Mon Sep 10 19:29:42 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 10 Sep 2018 19:29:42 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com> Message-ID: <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com> Hi, > > do you think we need property jdk.includeInExceptions=jar at > all, if we don't resolve the absolute path? > > I think so. File path is still sensitive. > > In fact, I tend to believe people usually use absolute paths for JAR files (or > maybe made absolute by using a file:// URL somewhere inside JDK). Do you > really see relative jar paths while testing this code change? I agree. > > small remark to the code: > > src/java.base/share/classes/sun/security/util/SecurityProperties.java > > 36 public static String privilegeGetOverridable(String propName) { > > > > Should that method really be public? At the moment it doesn't seem to be > used outside of SecurityProperties. > > I like it to be public. There are quite some other such system/security > properties (Ex: jdk.serialFilter) that can make use of this method. Ok, maybe it should be named "priviledgedGetOverridable" then. @Matthias: Further small cleanups, as you touch the files: src/java.base/share/classes/java/util/jar/Manifest.java: line 35: you can remove "import java.util.Iterator;" src/java.base/share/classes/sun/net/util/SocketExceptions.java: line 41: indentation is ridiculously long, I think it should be 8 chars src/java.base/share/classes/sun/security/util/SecurityProperties.java: Indentation of lines 38-45 is too deep, should be 12. The 2 methods could use a brief Javadoc. Best regards Christoph From adam.petcher at oracle.com Mon Sep 10 20:23:09 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 10 Sep 2018 16:23:09 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> Message-ID: <81dd5ea3-5d0b-5f4d-9e8d-bd8d98fcc49f@oracle.com> The paper[1] containing the proposed formulas is referenced in the JEP. As far as I know, they are not part of any standard. If you know of any standardized, complete EC point arithmetic formulas, then let me know. I think it is okay to use these formulas as long as they produce the same result as the operations in Section 2.2 of SEC 1[2]. [1] https://eprint.iacr.org/2015/1060.pdf [2] http://www.secg.org/sec1-v2.pdf On 9/10/2018 2:23 PM, Xuelei Fan wrote: > Can I have the links to the new formulas that you will be used?? Are > they part of any current standards? > > Thanks, > Xuelei > > On 8/23/2018 10:50 AM, Adam Petcher wrote: >> I'm starting work on yet another ECC JEP[1], this time with the goal >> of developing improved implementations of existing algorithms, rather >> than implementing new ones. The JEP will re-implement ECDH and ECDSA >> for the 256-, 384-, and 521-bit NIST prime curves. The new >> implementation will be all Java, and will resist side-channel attacks >> by not branching on secrets. It will go in a new provider which is >> not in the provider list in the java.security file by default. So it >> will need to be manually enabled by changing the configuration or >> putting the new provider name in the code. It will only support a >> subset of the API that is supported by the implementation in SunEC. >> In particular, it will reject any private keys with scalar values >> specified using BigInteger (as in ECPrivateKeySpec), and its private >> keys will not return scalar values as BigInteger (as in >> ECPrivateKey.getS()). >> >> Please take a look and send me any feedback you have. I'm especially >> looking for suggestions on how this new implementation should fit >> into the API. I would prefer to have it enabled by default, but I >> can't think of a way to do that without either branching on secrets >> in some cases (converting a BigInteger private key to an array) or >> breaking compatibility (throwing an exception when it gets a >> BigInteger private key). >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8204574 >> From jonathan.gibbons at oracle.com Mon Sep 10 20:37:09 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 10 Sep 2018 13:37:09 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager Message-ID: <5B96D5F5.7010800@oracle.com> Please review a patch to have the Source Launcher be able to work when a security manager is enabled. There are 4 parts to the work: an update to the default policy file, an update to the source launcher itself, updates to tests, and a custom security manager to help with testing. 1. src/java.base/share/lib/security/default.policy Add reasonably fine-grain permissions to give javac the permissions it needs to run when a security manager is enabled. These permissions were determined by running all javac tests under with a special security manager installed: more on that later. There is one anomalous property which was detected, which is a property to control some internal javac behavior. Arguably, it should eventually be renamed with at least a "javac.*" prefix. 2. src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java Update the source launcher to use doPrivileged in a couple of places: most notably around the main invocation of javac. Generally, it continues to be the policy that command-line tools like javac, javadoc do not use fine-grained doPrivileged blocks throughout the tool, and this update does not change that. It is worth noting that when javac is invoked from the Source Launcher, it does not support callbacks like annotation processors, task listeners, and other plugin code, so that eliminates any issues relating to using callbacks from code in a doPrivileged block. 3. test/langtools/tools/lib/security/PermissiveTestSecurityManager.java This is a custom new security manager for manual testing purposes in conjunction with jtreg, so that we can run a large subset of tests under the influence of a security manager. . It is a design characteristic of jtreg that almost all tests have their own distinct codebase, and so it is impractical to use a modified policy file to grant all necessary permissions to all necessary tests, so this security manager installs a custom Policy object that grants permissions to test code while deferring to the system policy for everything else (and for javac in particular.) Using this security manager, it is possible to run all the javac tests to detect with high probability all the permissions that it requires. Using a custom security manager to install a custom Policy object allows the feature to be easily enabled on the jtreg command line. There is one workaround in this security manager: a bug was uncovered such that the jdk.zipfs module needs permission to access the user.dir system property. ( https://bugs.openjdk.java.net/browse/JDK-8210469 ) A temporary workaround is used to get a clean test run. Note: this code is not directly used in any normal/automated test runs for javac; nevertheless, it is deemed worthwhile to save the code for use in similar situations in the future. 4. Minor updates to tests. Some new test cases are added to Source Launcher tests. Although most tests are not directly affected by the use of a security manager, there are some exceptions. Some tests manipulate the security manager and/or expect the security manager to be unset. These tests are modified to "pass by default" if the runtime conditions are not suitable (i.e. a security manager has been installed.) Although it is not a requirement to be able to run annotation processing tests when a security manager is enabled (because that condition cannot arise with the Source Launcher), most annotation processing tests do run successfully. There were 3 exceptions, where the test required more permissions than granted to javac in code being called from javac. These permissions were to access test.* system properties and the setIO runtime permission. Rather than grant unnecessary properties to javac, it was enough to use doPrivileged in a couple of places in the javac "toolbox" test library, and to refactor those tests to better use toolbox. In conjunction with these changes,ignoring any tests on the ProblemList, all javac tests pass, with and without a security manager being present. JBS: https://bugs.openjdk.java.net/browse/JDK-8210274 Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.00/ -- Jon From anthony.scarpino at oracle.com Mon Sep 10 21:35:51 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 10 Sep 2018 14:35:51 -0700 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <6186d731-076d-307e-d401-2196788cf839@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <65FD868B-4AC2-4CFE-9C19-5319489634CC@oracle.com> <6186d731-076d-307e-d401-2196788cf839@oracle.com> Message-ID: <186bea37-b35b-a110-ad8f-f1fb9b5a5e2d@oracle.com> On 09/10/2018 08:50 AM, Adam Petcher wrote: > See inline below. > > It also occurred to me that we could use Provider properties here. We > have the "ImplementedIn" property, and we can similarly add a standard > "Branchless" property. I think my preferred solution is still to use > separate providers, and perhaps use a read-only "Branchless" property to > aid in provider selection. That is, JCA client code that supports the > branchless API (that is, no BigInteger) could loop through the providers > until it finds one with the "Branchless" property set. This same > mechanism could be used to select a provider that allows branching in an > environment where the highest-priority provider is branchless. > > We may also be able to set the "Branchless" property at runtime to > influence the behavior of a single provider. But this would introduce a > lot of complication, and I think it is starting to get away from the > intended use of these properties. A provider property would be good route to explore I think. It would be nice to cut down on Security properties. > > On 9/7/2018 7:07 PM, Anthony Scarpino wrote: > >>> On Sep 7, 2018, at 12:08 PM, Adam Petcher >>> wrote: >>> >>> This is a good suggestion. I don't have particularly strong feelings >>> about using separate providers vs a property in a single provider. I >>> think the fundamental issues are the same, and this choice mostly >>> affects API details. >>> >>> Do you think this should be a system property, security property, or >>> something else? Should it be modifiable at any time? >> I would say a security property >> >>> Perhaps it has to be in order to address Mike's desire to put the >>> provider in "import/export mode". Would the property affect existing >>> keys? Again, I think it would have to, so you can generate a key, >>> turn off branchless mode, and then export it. >> My thought was the property would allow the branchless import/export >> for that java instance.?? Not turning it on and off during >> operations.? I think the value of the branchless operation is in the >> usage of the algorithms. If an app wants to use a pure branchless >> provider the property can be set or never use the APIs with BigInteger >> in them. >> >> One could avoid the property completely by just documenting clearly >> the interfaces that branched and then leave it to the app developer, >> but from the email discussion with Mike it sounded like you preferred >> strong controls on the provider. > > The issues related to branching are too subtle, and I don't think we > should expose any of it to the developer except "use this > provider/property/algorithm to indicate that branching on secrets is > unacceptable." Moreover, I'm intimately familiar with all of these > issue, and yet I still don't have confidence in my own ability to switch > SunJSSE over to using a branchless ECC implementation, unless I have > strong enforcement in the provider. It would be too easy for me to > simply miss an existing call to getS() or a use of ECPrivateKeySpec. > > If we only have a single provider, and a security property that has been > set to indicate that branching is unacceptable in that provider, then I > think that means that there is no way to change the value of the > property and use private keys as BigInteger in that JVM process without > using some other (third party) provider. Though maybe I'm > misunderstanding something about your proposal. A single provider with a security property is fine. I think we agree the property will tell if the API's that use BigInteger will work with the provider or not. Internally you can design the algorithm code however you want. It's only the import/export parts I've been referring to. > >> >>> What about curves other than P256, P384, and P521? We can't do >>> branchless operations in those curves, so any attempt to use them >>> when this property is enabled would result in an exception. >> I wasn?t going to propose anything further than your existing curves, >> but it would be nice if branchful curves could be added to eventual >> replace SunEC.? I know that isn?t the intent of this JEP and depends >> if you want to expand it. > > Sure, but for this JEP, we need to be concerned about how the API can be > misused, and a branching implementation is obtained when a branchless > one is expected. The developer shouldn't be expected to know that three > of the curves have branchless implementations, and using any other curve > will result in branching. So any global "don't branch" property would > need to cause the use of any other curve to fail. Ok.. I had the impression that the other curves could work with the branchless code. If they cannot, then I wouldn't worry about including them. Tony From xuelei.fan at oracle.com Mon Sep 10 23:49:07 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 10 Sep 2018 16:49:07 -0700 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <81dd5ea3-5d0b-5f4d-9e8d-bd8d98fcc49f@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <81dd5ea3-5d0b-5f4d-9e8d-bd8d98fcc49f@oracle.com> Message-ID: <59eb69e2-4f55-1ed2-b505-0304160122dc@oracle.com> On 9/10/2018 1:23 PM, Adam Petcher wrote: > The paper[1] containing the proposed formulas is referenced in the JEP. Thanks! > As far as I know, they are not part of any standard. If you know of any > standardized, complete EC point arithmetic formulas, then let me know. I don't know, either. > I think it is okay to use these formulas as long as they produce the > same result as the operations in Section 2.2 of SEC 1[2]. > The motivation of the JEP is that some formulas may be more easier to expose attacks. It's true that the formulas impact the security level of the implementation. I was just wondering if the JEP proposed formulas have been well analyze. A standard or formal recommendation may indicate the good quality of the formulas. It's a concern to me that interoperability is listed as "non-goals". In general, it may introduce a lot of problems in the current JCE framework. I don't know your detailed design yet, and not sure if you are able to mitigate the impact. Looks like the debate was mainly about the BigInteger. If the keys are used in the same provider, I don't think the BigInteger is a problem as you can extend a private BigInteger that you like. If the keys are use between two providers, add a thine clue to export/import BigInteger may be worthy for provider interoperability. I'm a little bit nervous about the two providers design. It simplify the initial crypto implementation, but left the complexity to developers and sustaining. I don't have a good sense about how to use them in JSSE. What if the proposed formulas is vulnerable in the future? If you believe it is a better one, please consider to replace the current EC implementation. I know it may only support secp256r1/secp384r1/secp521r1 now, but we can use it to replace the implementation of the three curves for now. Thanks, Xuelei > [1] https://eprint.iacr.org/2015/1060.pdf > [2] http://www.secg.org/sec1-v2.pdf > > > On 9/10/2018 2:23 PM, Xuelei Fan wrote: >> Can I have the links to the new formulas that you will be used?? Are >> they part of any current standards? >> >> Thanks, >> Xuelei >> >> On 8/23/2018 10:50 AM, Adam Petcher wrote: >>> I'm starting work on yet another ECC JEP[1], this time with the goal >>> of developing improved implementations of existing algorithms, rather >>> than implementing new ones. The JEP will re-implement ECDH and ECDSA >>> for the 256-, 384-, and 521-bit NIST prime curves. The new >>> implementation will be all Java, and will resist side-channel attacks >>> by not branching on secrets. It will go in a new provider which is >>> not in the provider list in the java.security file by default. So it >>> will need to be manually enabled by changing the configuration or >>> putting the new provider name in the code. It will only support a >>> subset of the API that is supported by the implementation in SunEC. >>> In particular, it will reject any private keys with scalar values >>> specified using BigInteger (as in ECPrivateKeySpec), and its private >>> keys will not return scalar values as BigInteger (as in >>> ECPrivateKey.getS()). >>> >>> Please take a look and send me any feedback you have. I'm especially >>> looking for suggestions on how this new implementation should fit >>> into the API. I would prefer to have it enabled by default, but I >>> can't think of a way to do that without either branching on secrets >>> in some cases (converting a BigInteger private key to an array) or >>> breaking compatibility (throwing an exception when it gets a >>> BigInteger private key). >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8204574 >>> > From weijun.wang at oracle.com Tue Sep 11 00:13:38 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Sep 2018 08:13:38 +0800 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com> <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com> Message-ID: <46E0E264-EBB7-436A-8A47-894531670D1F@oracle.com> > On Sep 11, 2018, at 3:29 AM, Langer, Christoph wrote: > > Ok, maybe it should be named "priviledgedGetOverridable" then. Ah yes. My mistake. From stuart.marks at oracle.com Tue Sep 11 02:28:14 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 10 Sep 2018 19:28:14 -0700 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <46E0E264-EBB7-436A-8A47-894531670D1F@oracle.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com> <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com> <46E0E264-EBB7-436A-8A47-894531670D1F@oracle.com> Message-ID: <7619d4d5-ad06-f8d0-8da7-04f002763f7e@oracle.com> On 9/10/18 5:13 PM, Weijun Wang wrote: > > >> On Sep 11, 2018, at 3:29 AM, Langer, Christoph wrote: >> >> Ok, maybe it should be named "priviledgedGetOverridable" then. > > Ah yes. My mistake. Small spelling nit: there's no "d" before "g", so this should likely be privilegedGetOverridable s'marks From Alan.Bateman at oracle.com Tue Sep 11 07:58:18 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Sep 2018 08:58:18 +0100 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <5B96D5F5.7010800@oracle.com> References: <5B96D5F5.7010800@oracle.com> Message-ID: <8dee0eec-9357-f688-676a-46a72c0c7de4@oracle.com> On 10/09/2018 21:37, Jonathan Gibbons wrote: > Please review a patch to have the Source Launcher be able to work when > a security manager is enabled. It's not clear to me that this is an interesting use-case but in any case I think you've got two scenarios to test. One is setting java.security.manager on the command line, the other is the launched code's main method calling System.setSecurityManager which amounts to setting a security manager in a running VM. You might want to add a test case for the latter. Is there any way (spi.ToolProvider or some means) for untrusted code to indirectly run the source launcher? This question is important because the updated source launcher could be abused to probe anywhere on the file system. What are the implications for uses of javax.tools and com.sun.tools.javac.Main in code running with a security manager? Maybe that is a separate project but I would have expected to see privileged blocks in places that need permissions. -Alan From matthias.baesken at sap.com Tue Sep 11 09:07:25 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 11 Sep 2018 09:07:25 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com> <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com> Message-ID: Hello, please check the new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.10/ I kept the jarPath category name . Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 10. September 2018 21:30 > To: Weijun Wang ; Baesken, Matthias > > Cc: Sean Mullan ; security- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: RE: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > Hi, > > > > do you think we need property jdk.includeInExceptions=jar at > > all, if we don't resolve the absolute path? > > > > I think so. File path is still sensitive. > > > > In fact, I tend to believe people usually use absolute paths for JAR files (or > > maybe made absolute by using a file:// URL somewhere inside JDK). Do > you > > really see relative jar paths while testing this code change? > > I agree. > > > > small remark to the code: > > > src/java.base/share/classes/sun/security/util/SecurityProperties.java > > > 36 public static String privilegeGetOverridable(String propName) { > > > > > > Should that method really be public? At the moment it doesn't seem to > be > > used outside of SecurityProperties. > > > > I like it to be public. There are quite some other such system/security > > properties (Ex: jdk.serialFilter) that can make use of this method. > > Ok, maybe it should be named "priviledgedGetOverridable" then. > > @Matthias: > Further small cleanups, as you touch the files: > src/java.base/share/classes/java/util/jar/Manifest.java: line 35: you can > remove "import java.util.Iterator;" > > src/java.base/share/classes/sun/net/util/SocketExceptions.java: > line 41: indentation is ridiculously long, I think it should be 8 chars > > src/java.base/share/classes/sun/security/util/SecurityProperties.java: > Indentation of lines 38-45 is too deep, should be 12. > The 2 methods could use a brief Javadoc. > > Best regards > Christoph From norman.maurer at googlemail.com Tue Sep 11 10:32:14 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Tue, 11 Sep 2018 12:32:14 +0200 Subject: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well Message-ID: <9D5DC438-0D54-4A88-9711-19C7B5A34A87@googlemail.com> Hi all, Would it be possible to consider exposing SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible to reuse it when a custom SSLEngine / SSLContextSpi is provided ? I am asking because it provides really nice extra functionality by wrapping for X509TrustManager implementation and do extra hostname checks etc. At the moment we can not make use of this extra functionality in netty with our custom SSLEngine implementation as there is no way to access this. Which means depending on if the user use our implementation or the default implementation the behaviour if quite different when using a X509TrustManager in the sense that when using the default implementation a lot of extra checks are done. As the extra checks done in AbstractTrustManagerWrapper is not really depending on the underlying SSLContextSpi implementation (at least as far as I was able to understand it so far) it would be nice to be able to make use of it. Bye Norman From weijun.wang at oracle.com Tue Sep 11 11:03:33 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Sep 2018 19:03:33 +0800 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com> <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com> Message-ID: Attributes.java: - Line 377: Too long, add a break. Otherwise fine. I don't have a strong opinion on making Manifest.jarFilename final or a different property name. Thanks Max > On Sep 11, 2018, at 5:07 PM, Baesken, Matthias wrote: > > Hello, please check the new webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.10/ > > I kept the jarPath category name . > > Best regards, Matthias > > >> -----Original Message----- >> From: Langer, Christoph >> Sent: Montag, 10. September 2018 21:30 >> To: Weijun Wang ; Baesken, Matthias >> >> Cc: Sean Mullan ; security- >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> Subject: RE: [RFR] 8205525 : Improve exception messages during manifest >> parsing of jar archives >> >> Hi, >> >>>> do you think we need property jdk.includeInExceptions=jar at >>> all, if we don't resolve the absolute path? >>> >>> I think so. File path is still sensitive. >>> >>> In fact, I tend to believe people usually use absolute paths for JAR files (or >>> maybe made absolute by using a file:// URL somewhere inside JDK). Do >> you >>> really see relative jar paths while testing this code change? >> >> I agree. >> >>>> small remark to the code: >>>> src/java.base/share/classes/sun/security/util/SecurityProperties.java >>>> 36 public static String privilegeGetOverridable(String propName) { >>>> >>>> Should that method really be public? At the moment it doesn't seem to >> be >>> used outside of SecurityProperties. >>> >>> I like it to be public. There are quite some other such system/security >>> properties (Ex: jdk.serialFilter) that can make use of this method. >> >> Ok, maybe it should be named "priviledgedGetOverridable" then. >> >> @Matthias: >> Further small cleanups, as you touch the files: >> src/java.base/share/classes/java/util/jar/Manifest.java: line 35: you can >> remove "import java.util.Iterator;" >> >> src/java.base/share/classes/sun/net/util/SocketExceptions.java: >> line 41: indentation is ridiculously long, I think it should be 8 chars >> >> src/java.base/share/classes/sun/security/util/SecurityProperties.java: >> Indentation of lines 38-45 is too deep, should be 12. >> The 2 methods could use a brief Javadoc. >> >> Best regards >> Christoph > From matthias.baesken at sap.com Tue Sep 11 11:29:12 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 11 Sep 2018 11:29:12 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com> <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com> Message-ID: > I don't have a strong opinion on making Manifest.jarFilename final Hi, just making it final leads to compile errors anyway. Best regards, Matthias > -----Original Message----- > From: Weijun Wang > Sent: Dienstag, 11. September 2018 13:04 > To: Baesken, Matthias > Cc: Langer, Christoph ; Sean Mullan > ; security-dev at openjdk.java.net; core-libs- > dev at openjdk.java.net > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > Attributes.java: > > - Line 377: Too long, add a break. > > Otherwise fine. > > I don't have a strong opinion on making Manifest.jarFilename final or a > different property name. > > Thanks > Max > > > On Sep 11, 2018, at 5:07 PM, Baesken, Matthias > wrote: > > > > Hello, please check the new webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.10/ > > > > I kept the jarPath category name . > > > > Best regards, Matthias > > > > > >> -----Original Message----- > >> From: Langer, Christoph > >> Sent: Montag, 10. September 2018 21:30 > >> To: Weijun Wang ; Baesken, Matthias > >> > >> Cc: Sean Mullan ; security- > >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net > >> Subject: RE: [RFR] 8205525 : Improve exception messages during manifest > >> parsing of jar archives > >> > >> Hi, > >> > >>>> do you think we need property jdk.includeInExceptions=jar > at > >>> all, if we don't resolve the absolute path? > >>> > >>> I think so. File path is still sensitive. > >>> > >>> In fact, I tend to believe people usually use absolute paths for JAR files > (or > >>> maybe made absolute by using a file:// URL somewhere inside JDK). Do > >> you > >>> really see relative jar paths while testing this code change? > >> > >> I agree. > >> > >>>> small remark to the code: > >>>> src/java.base/share/classes/sun/security/util/SecurityProperties.java > >>>> 36 public static String privilegeGetOverridable(String propName) { > >>>> > >>>> Should that method really be public? At the moment it doesn't seem to > >> be > >>> used outside of SecurityProperties. > >>> > >>> I like it to be public. There are quite some other such system/security > >>> properties (Ex: jdk.serialFilter) that can make use of this method. > >> > >> Ok, maybe it should be named "priviledgedGetOverridable" then. > >> > >> @Matthias: > >> Further small cleanups, as you touch the files: > >> src/java.base/share/classes/java/util/jar/Manifest.java: line 35: you can > >> remove "import java.util.Iterator;" > >> > >> src/java.base/share/classes/sun/net/util/SocketExceptions.java: > >> line 41: indentation is ridiculously long, I think it should be 8 chars > >> > >> src/java.base/share/classes/sun/security/util/SecurityProperties.java: > >> Indentation of lines 38-45 is too deep, should be 12. > >> The 2 methods could use a brief Javadoc. > >> > >> Best regards > >> Christoph > > From christoph.langer at sap.com Tue Sep 11 12:14:15 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 11 Sep 2018 12:14:15 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <4ab295a8-a61e-efa2-cad8-cf177613057e@oracle.com> <73BAE390-FD57-45CB-A137-D1917B48B9B1@oracle.com> <252b3b00f4e94b8796256675ce2571b1@sap.com> <9bb8b30850aa48e493a15d48cfd79efa@sap.com> <69b2a09539384016b890e64e71700809@sap.com> <46322abe1477459cad6ea342950b2da4@sap.com> <2DC8295E-0F73-43E0-B307-B71DC348FC33@oracle.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com> <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com> Message-ID: Hi, first of all, I suggest to use "jarDetails" instead of "jarPath" as category name. Because with this contribution we add the notion of jar file plus line of manifest to Exceptions occurring when parsing jar manifests. And if there were further Exception details to be added in the area of jar files, they could go under a category "jarDetails" as well. Would you agree? Then, in Manifest.java, the field "jarPathInExceptionText" could be renamed to "detailedExceptions". As for the code, I have the following remarks: src/java.base/share/classes/java/util/jar/Manifest.java: You could further clean up the ordering of includes by sorting them alphabetically and add a blank line between lines 34/35. Line 52: I suggest an indentation of 8 chars Please use jarFilename as final. You'll have to initialize jarFilename in each constructor then or initialize it to null in the default constructor and call this constructor from all the other ctors except for the one taking the jarFilename as param. src/java.base/share/classes/sun/net/util/SocketExceptions.java please add an empty line between 32 and 33 Line 39: I suggest an indentation of 8 chars src/java.base/share/classes/sun/security/util/SecurityProperties.java Line 35: change comment opener to /** (from /*), then it's a real Javadoc Furthermore I suggest to change the wording to "Returns the value of the security property propName, which can be overridden by a system property of the same name" Best regards Christoph > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 11. September 2018 13:29 > To: Weijun Wang > Cc: Langer, Christoph ; Sean Mullan > ; security-dev at openjdk.java.net; core-libs- > dev at openjdk.java.net > Subject: RE: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > > I don't have a strong opinion on making Manifest.jarFilename final > > Hi, just making it final leads to compile errors anyway. > > Best regards, Matthias > > > > -----Original Message----- > > From: Weijun Wang > > Sent: Dienstag, 11. September 2018 13:04 > > To: Baesken, Matthias > > Cc: Langer, Christoph ; Sean Mullan > > ; security-dev at openjdk.java.net; core-libs- > > dev at openjdk.java.net > > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > > parsing of jar archives > > > > Attributes.java: > > > > - Line 377: Too long, add a break. > > > > Otherwise fine. > > > > I don't have a strong opinion on making Manifest.jarFilename final or a > > different property name. > > > > Thanks > > Max > > > > > On Sep 11, 2018, at 5:07 PM, Baesken, Matthias > > wrote: > > > > > > Hello, please check the new webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.10/ > > > > > > I kept the jarPath category name . > > > > > > Best regards, Matthias > > > > > > > > >> -----Original Message----- > > >> From: Langer, Christoph > > >> Sent: Montag, 10. September 2018 21:30 > > >> To: Weijun Wang ; Baesken, Matthias > > >> > > >> Cc: Sean Mullan ; security- > > >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net > > >> Subject: RE: [RFR] 8205525 : Improve exception messages during > manifest > > >> parsing of jar archives > > >> > > >> Hi, > > >> > > >>>> do you think we need property > jdk.includeInExceptions=jar > > at > > >>> all, if we don't resolve the absolute path? > > >>> > > >>> I think so. File path is still sensitive. > > >>> > > >>> In fact, I tend to believe people usually use absolute paths for JAR files > > (or > > >>> maybe made absolute by using a file:// URL somewhere inside JDK). > Do > > >> you > > >>> really see relative jar paths while testing this code change? > > >> > > >> I agree. > > >> > > >>>> small remark to the code: > > >>>> src/java.base/share/classes/sun/security/util/SecurityProperties.java > > >>>> 36 public static String privilegeGetOverridable(String propName) { > > >>>> > > >>>> Should that method really be public? At the moment it doesn't seem > to > > >> be > > >>> used outside of SecurityProperties. > > >>> > > >>> I like it to be public. There are quite some other such system/security > > >>> properties (Ex: jdk.serialFilter) that can make use of this method. > > >> > > >> Ok, maybe it should be named "priviledgedGetOverridable" then. > > >> > > >> @Matthias: > > >> Further small cleanups, as you touch the files: > > >> src/java.base/share/classes/java/util/jar/Manifest.java: line 35: you can > > >> remove "import java.util.Iterator;" > > >> > > >> src/java.base/share/classes/sun/net/util/SocketExceptions.java: > > >> line 41: indentation is ridiculously long, I think it should be 8 chars > > >> > > >> src/java.base/share/classes/sun/security/util/SecurityProperties.java: > > >> Indentation of lines 38-45 is too deep, should be 12. > > >> The 2 methods could use a brief Javadoc. > > >> > > >> Best regards > > >> Christoph > > > > From xuelei.fan at oracle.com Tue Sep 11 14:44:34 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Sep 2018 07:44:34 -0700 Subject: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well In-Reply-To: <9D5DC438-0D54-4A88-9711-19C7B5A34A87@googlemail.com> References: <9D5DC438-0D54-4A88-9711-19C7B5A34A87@googlemail.com> Message-ID: Hi Norman, It may be doable by adding a delegation mode to public TrustManagerFactory: TrustManagerFactory.init(X509TrustManager proxy) However, the X509ExtendedTrustManager should be recommended for now since its introducing in JDK 7. Do you know how many users are still using the X509TrustManager implementation? Thanks, Xuelei On 9/11/2018 3:32 AM, Norman Maurer wrote: > Hi all, > > Would it be possible to consider exposing SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible to reuse it when a custom SSLEngine / SSLContextSpi is provided ? > > I am asking because it provides really nice extra functionality by wrapping for X509TrustManager implementation and do extra hostname checks etc. At the moment we can not make use of this extra functionality in netty with our custom SSLEngine implementation as there is no way to access this. Which means depending on if the user use our implementation or the default implementation the behaviour if quite different when using a X509TrustManager in the sense that when using the default implementation a lot of extra checks are done. > > As the extra checks done in AbstractTrustManagerWrapper is not really depending on the underlying SSLContextSpi implementation (at least as far as I was able to understand it so far) it would be nice to be able to make use of it. > > Bye > Norman > From mbalao at redhat.com Tue Sep 11 14:54:01 2018 From: mbalao at redhat.com (Martin Balao) Date: Tue, 11 Sep 2018 16:54:01 +0200 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> <7203910f-333f-89d5-ea04-ffb4b42ac542@oracle.com> <2d949ed6-5089-1cae-0960-2790afcb25d2@oracle.com> <8c273087-e41d-3978-4d93-8cb5f7cc9bb8@redhat.com> Message-ID: Hi Valerie, On Fri, Aug 31, 2018 at 9:16 PM, Valerie Peng wrote: > Hi Martin, > > In TestTLS12.java, you call the initSecmod() inside initialize() and when > initSecmod() returns false, you return from initialize() and continue down > the main(). Is this intentional? Other tests seems to be skipping execution > when initSecmod() return false. > This test skips execution too. That's because shouldRun method returns false if sunPKCS11NSSProvider variable is null (which it is if initSecmod returns false). > > Changes in webrev.08 resolves 2 out of the 4 failure cases for > TestTLS12.java. However, when I submit the changes for testing, it failed > on some OS (see below): > > macosx-x64: > > jib > STDOUT: >> jib > nssLibDir: /scratch/mesos/jib-master/inst >> all/jpg/tests/jdk/nsslib/nsslib-macosx_x64/3.35/nsslib-macos >> x_x64-3.35.zip/nsslib/ >> jib > STDERR: >> jib > java.security.ProviderException: Could not initialize NSS >> jib > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.( >> SunPKCS11.java:218) >> jib > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run( >> SunPKCS11.java:113) >> jib > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run( >> SunPKCS11.java:110) >> jib > at java.base/java.security.AccessController.doPrivileged(Native >> Method) >> jib > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure( >> SunPKCS11.java:110) >> jib > at PKCS11Test.getSunPKCS11(PKCS11Test.java:156) >> jib > at TestTLS12.initialize(TestTLS12.java:416) >> jib > at TestTLS12.main(TestTLS12.java:84) >> jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo >> ke(NativeMethodAccessorImpl.java:62) >> jib > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. >> invoke(DelegatingMethodAccessorImpl.java:43) >> jib > at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> jib > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run( >> MainWrapper.java:127) >> jib > at java.base/java.lang.Thread.run(Thread.java:834) >> jib > Caused by: java.io.IOException: NSS initialization failed >> jib > at jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.initialize( >> Secmod.java:234) >> jib > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.( >> SunPKCS11.java:213) >> jib > ... 13 more >> jib > >> jib > JavaTest Message: Test threw exception: >> java.security.ProviderException: Could not initialize NSS >> > > windows-x64: > > jib > STDOUT: >> jib > nssLibDir: C:\ADE\mesos\work_dir\jib-mast >> er\install\jpg\tests\jdk\nsslib\nsslib-windows_x64\3.35\ >> nsslib-windows_x64-3.35.zip\nsslib\ >> jib > SunPKCS11 provider: SunPKCS11-NSSKeyStore version 12 >> jib > STDERR: >> jib > java.security.ProviderException: SunJSSE already initialized in >> non-FIPS mode >> jib > at java.base/sun.security.ssl.SunJSSE.ensureFIPS(SunJSSE.java:94) >> jib > at java.base/sun.security.ssl.SunJSSE.(SunJSSE.java:146) >> jib > at java.base/sun.security.ssl.SunJSSE.(SunJSSE.java:118) >> jib > at java.base/com.sun.net.ssl.internal.ssl.Provider.(Provi >> der.java:47) >> jib > at TestTLS12.initialize(TestTLS12.java:424) >> jib > at TestTLS12.main(TestTLS12.java:84) >> jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo >> ke(NativeMethodAccessorImpl.java:62) >> jib > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. >> invoke(DelegatingMethodAccessorImpl.java:43) >> jib > at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> jib > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run( >> MainWrapper.java:127) >> jib > at java.base/java.lang.Thread.run(Thread.java:834) >> jib > >> jib > JavaTest Message: Test threw exception: >> java.security.ProviderException: SunJSSE already initialized in non-FIPS >> mode >> > > The 2 tests that initialize NSS in FIPS mode (TrustManagerTest and ClientJSSEServerJSSE) only run on Solaris. My guess is that these failures are not particular to TestTLS12 but to NSS + FIPS support on these setups. I won't be able to reproduce the macOS failure and I'm not sure if I'll be able to reproduce in my Windows x86_64 environment. I propose the following options: 1) Make the test skip macOS & Windows x86_64 (and any other platform that fails to initialize the SunPKCS11 provider) 2) If you can provide access to a testing environment where I can reproduce these failures, I can see what's happening I intentionally want to use FIPS in NSS configuration because it represents a real use case, and is what motivated us to support TLS 1.2 in SunPKCS11. So, even though removing FIPS would be an option, I prefer not to take it. Kind regards, Martin.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman.maurer at googlemail.com Tue Sep 11 15:01:29 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Tue, 11 Sep 2018 17:01:29 +0200 Subject: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well In-Reply-To: References: <9D5DC438-0D54-4A88-9711-19C7B5A34A87@googlemail.com> Message-ID: <684F48EB-AC55-436F-9B2E-1401E2731E21@googlemail.com> This sounds great. I have no idea how many people still use X509TrustManager, sorry. It may be a good idea to add something to the java docs to tell people to prefer X509ExtendedTrustManager as well. Bye Norman > Am 11.09.2018 um 16:44 schrieb Xuelei Fan : > > Hi Norman, > > > It may be doable by adding a delegation mode to public TrustManagerFactory: > TrustManagerFactory.init(X509TrustManager proxy) > > However, the X509ExtendedTrustManager should be recommended for now since its introducing in JDK 7. > > Do you know how many users are still using the X509TrustManager implementation? > > Thanks, > Xuelei > >> On 9/11/2018 3:32 AM, Norman Maurer wrote: >> Hi all, >> Would it be possible to consider exposing SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible to reuse it when a custom SSLEngine / SSLContextSpi is provided ? >> I am asking because it provides really nice extra functionality by wrapping for X509TrustManager implementation and do extra hostname checks etc. At the moment we can not make use of this extra functionality in netty with our custom SSLEngine implementation as there is no way to access this. Which means depending on if the user use our implementation or the default implementation the behaviour if quite different when using a X509TrustManager in the sense that when using the default implementation a lot of extra checks are done. >> As the extra checks done in AbstractTrustManagerWrapper is not really depending on the underlying SSLContextSpi implementation (at least as far as I was able to understand it so far) it would be nice to be able to make use of it. >> Bye >> Norman From adam.petcher at oracle.com Tue Sep 11 15:07:27 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 11 Sep 2018 11:07:27 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <59eb69e2-4f55-1ed2-b505-0304160122dc@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <81dd5ea3-5d0b-5f4d-9e8d-bd8d98fcc49f@oracle.com> <59eb69e2-4f55-1ed2-b505-0304160122dc@oracle.com> Message-ID: On 9/10/2018 7:49 PM, Xuelei Fan wrote: > The motivation of the JEP is that some formulas may be more easier to > expose attacks.? It's true that the formulas impact the security level > of the implementation.? I was just wondering if the JEP proposed > formulas have been well analyze.? A standard or formal recommendation > may indicate the good quality of the formulas. Thanks. I added this comment to the JEP under "Risks and Assumptions". As far as I know, the exact EC formulas that are usually implemented have never been standardized. The standards give a specification for point addition in affine coordinates, but that is not what is implemented. I admit that the novelty of the proposed formulas presents some additional risk, but the formulas in SunEC were novel when they were implemented, too. I'd like to hear more opinions about the perceived risk of using formulas from the academic literature, if anyone has them. It's worth noting that some of these academic formulas have already been implemented in other crypto/TLS libraries. > > It's a concern to me that interoperability is listed as "non-goals".? > In general,? it may introduce a lot of problems in the current JCE > framework.? I don't know your detailed design yet, and not sure if you > are able to mitigate the impact. > > Looks like the debate was mainly about the BigInteger.?? If the keys > are used in the same provider, I don't think the BigInteger is a > problem as you can extend a private BigInteger that you like.? If the > keys are use between two providers, add a thine clue to export/import > BigInteger may be worthy for provider interoperability. I reworded that part of the JEP, because it was misleading. Now it more clearly indicates that interoperability with providers that only support BigInteger private keys is out of scope. I still haven't been convinced that this lack of interoperability is a significant problem. In the proposed design, the new KeyFactory will not support ECPrivateKeySpec, and the implementation will produce private keys that inherit from PrivateKey, but not ECPrivateKey. Specifically, what problems in JCE are introduced by this design? How are these interoperability issues different from the ones you encounter with a PKCS11 provider that doesn't export private keys? If the developer wants more interoperability, why not use SunEC? If we decide that we want the new implementation to have better interoperability in the future, does something prevent us from enhancing it? These questions are for anyone who can help me understand the objections that have been raised related to interoperability. > > I'm a little bit nervous about the two providers design.? It simplify > the initial crypto implementation, but left the complexity to > developers and sustaining.?? I don't have a good sense about how to > use them in JSSE.? What if the proposed formulas is vulnerable in the > future? I don't see any reason for a two-provider design to be more complex than a one-provider design. The two providers could even share code, but I don't think that is necessarily a good idea. Also, I'm not opposed to putting everything in one provider, with some sort of property to choose the behavior. But the provider system already exists, and it seems to work fine for this purpose, so I would rather use it. Here is a proposal for how we can make the two-provider design work in JSSE: 1) We add the new provider to the list, with lower priority than SunEC 2) We add a "Branchless" property to the provider 3) We modify SunJSSE so that it sends all EC private keys to the provider using an encoded key spec. PKCS8EncodedKeySpec would work, but perhaps we could add a new type for raw encoded private keys, if necessary. 4) We add some provider selection code to SunJSSE that is used for EC, ECDH, and ECDSA. This code will loop through the providers (in priority order), looking for the first "Branchless" provider that supports the desired curve. If it doesn't find one, it will use the first provider that supports the desired curve. I'm not sure how your question about vulnerability fits in here. If the formulas are vulnerable, we will fix them, if possible. Maybe if you restate the question, I'll have a better idea of what you are asking. From sean.mullan at oracle.com Tue Sep 11 16:02:44 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Sep 2018 12:02:44 -0400 Subject: SSL session cache default maximum number of entries In-Reply-To: <7BB7D5C5-2B63-4451-AC8B-3C65D231BBDC@amazon.com> References: <7BB7D5C5-2B63-4451-AC8B-3C65D231BBDC@amazon.com> Message-ID: <65e68e95-dac4-7443-02ad-0e2375b740cb@oracle.com> cross-posting to security-dev since this is related to SSL/TLS. On 9/11/18 11:41 AM, Hohensee, Paul wrote: > The default value for the maximum number of entries in the SSL session cache (which is a SoftReference cache) is infinite, and the entry timeout is 24 hours. With larger heaps, we?re running into situations where the cache ends up with several million entries when the 24 hours are up. They?re then all invalidated at the same time, resulting in multi-minute pauses (effectively service failures). We?ve experimented with using 10k as the default maximum number of entries with good results (i.e., no latency increases due to sessions falling out of the cache). It?s late and a long shot for JDK11: we?d love to see it changed there because 11 is an LTS release and this is, at least nominally, a behavior change which might not be acceptable in 11u. What do people think? > > Thanks, > > Paul > From jonathan.gibbons at oracle.com Tue Sep 11 18:42:05 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 11 Sep 2018 11:42:05 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <8dee0eec-9357-f688-676a-46a72c0c7de4@oracle.com> References: <5B96D5F5.7010800@oracle.com> <8dee0eec-9357-f688-676a-46a72c0c7de4@oracle.com> Message-ID: <8f2ff168-d2a1-f62f-ad91-ba6b8c01a645@oracle.com> On 9/11/18 12:58 AM, Alan Bateman wrote: > On 10/09/2018 21:37, Jonathan Gibbons wrote: >> Please review a patch to have the Source Launcher be able to work >> when a security manager is enabled. > It's not clear to me that this is an interesting use-case but in any > case I think you've got two scenarios to test. One is setting > java.security.manager on the command line, the other is the launched > code's main method calling System.setSecurityManager which amounts to > setting a security manager in a running VM. You might want to add a > test case for the latter. I agree that this may not be a very interesting use case, and I have no strong feelings about whether or not to support it, except to say that I think we should specify the interaction between Source Launcher and the use of a security manager.? I note that this piece of work was triggered by the recent change to support the getResource* family of methods in the classloader used to run the user classes. At that time, it was noted that creating the URL involved directly calling a method that needed a privilege to be available (NetPermission specifyStreamHandler) (as compared to all the permissions indirectly required when invoking the compiler.) As regards the interaction between Source Launcher and the use of a security manager, I see 3 possibilities: 1. Specifically support it, as provided in this webrev 2. No code change, but update JEP 330 to specify the behavior 3. Explicitly reject the combination of Source Launcher and the security manager. > > Is there any way (spi.ToolProvider or some means) for untrusted code > to indirectly run the source launcher? This question is important > because the updated source launcher could be abused to probe anywhere > on the file system. Untrusted code can only run the source launcher by breaking encapsulation on the command line.? The source launcher is a combination of native code in the launcher itself and a class in an unexported package of jdk.compiler.? Even if you could access the source launcher, the compilation command line (i.e. the args for the internal call to javac) is highly constrained, and so it is difficult to see how the source launcher could be abused. > > What are the implications for uses of javax.tools and > com.sun.tools.javac.Main in code running with a security manager? > Maybe that is a separate project but I would have expected to see > privileged blocks in places that need permissions. The intent was to stay clear (in this changeset) of all other ways of invoking javac, meaning javax.tools, com.sun.tools.javac.Main and spi.ToolProvider. While there are relatively few ways to invoke javac, these ways all permit the use of annotation processors and other callbacks, and so we would need privileged blocks in all places where callbacks could re-enter javac. > > -Alan If we were to drop the support for a security manager from the source launcher, would you still consider it worthwhile to update the policy file to enumerate the privileges required to run javac? Setting aside the updates for the Source Launcher tests, I think the work to improve all the other tests to function better when a security manager is involved is also worth while. -- Jon From sean.mullan at oracle.com Tue Sep 11 18:44:07 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Sep 2018 14:44:07 -0400 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com> <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com> Message-ID: <95de743b-4b00-91ac-9fd4-1cd77acdb5ab@oracle.com> On 9/11/18 8:14 AM, Langer, Christoph wrote: > Hi, > > first of all, I suggest to use "jarDetails" instead of "jarPath" as category name. Because with this contribution we add the notion of jar file plus line of manifest to Exceptions occurring when parsing jar manifests. And if there were further Exception details to be added in the area of jar files, they could go under a category "jarDetails" as well. Would you agree? Then, in Manifest.java, the field "jarPathInExceptionText" could be renamed to "detailedExceptions". Or just "jar" would be my preference. I don't like "jarPath" as that sounds too much like a file pathname to me, which we have now removed. --Sean From Alan.Bateman at oracle.com Tue Sep 11 19:34:35 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Sep 2018 20:34:35 +0100 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <8f2ff168-d2a1-f62f-ad91-ba6b8c01a645@oracle.com> References: <5B96D5F5.7010800@oracle.com> <8dee0eec-9357-f688-676a-46a72c0c7de4@oracle.com> <8f2ff168-d2a1-f62f-ad91-ba6b8c01a645@oracle.com> Message-ID: <0d57cc5e-a897-eab4-77c0-ad4b192866d3@oracle.com> On 11/09/2018 19:42, Jonathan Gibbons wrote: > : > > As regards the interaction between Source Launcher and the use of a > security manager, I see 3 possibilities: > > 1. Specifically support it, as provided in this webrev > 2. No code change, but update JEP 330 to specify the behavior > 3. Explicitly reject the combination of Source Launcher and the > security manager. Since you've started into this then it's probably best to just continue with #1 and get it done. My main point here was the test in the webrev sets the security manager on the command line and I think you also need another test that sets in the test main method. >> >> Is there any way (spi.ToolProvider or some means) for untrusted code >> to indirectly run the source launcher? This question is important >> because the updated source launcher could be abused to probe anywhere >> on the file system. > Untrusted code can only run the source launcher by breaking > encapsulation on the command line.? The source launcher is a > combination of native code in the launcher itself and a class in an > unexported package of jdk.compiler.? Even if you could access the > source launcher, the compilation command line (i.e. the args for the > internal call to javac) is highly constrained, and so it is difficult > to see how the source launcher could be abused. Thanks, the question had to be asked because the privileged block in the source launcher main means it can access any file. >> >> What are the implications for uses of javax.tools and >> com.sun.tools.javac.Main in code running with a security manager? >> Maybe that is a separate project but I would have expected to see >> privileged blocks in places that need permissions. > The intent was to stay clear (in this changeset) of all other ways of > invoking javac, meaning javax.tools, com.sun.tools.javac.Main and > spi.ToolProvider. While there are relatively few ways to invoke javac, > these ways all permit the use of annotation processors and other > callbacks, and so we would need privileged blocks in all places where > callbacks could re-enter javac. That is what I was wondering about it. I don't see a queue at the door of developers looking to run javac with a security manager but at the same time it is possible to configure many app servers with JSP support to run with a security manager. I assume they must have historically granted at least some permissions to "tools.jar" for this to work. > > If we were to drop the support for a security manager from the source > launcher, would you still consider it worthwhile to update the policy > file to enumerate the privileges required to run javac? Setting aside > the updates for the Source Launcher tests, I think the work to improve > all the other tests to function better when a security manager is > involved is also worth while. It took a lot of work in JDK 9 to identify the minimum permissions needed by several modules. The java.xml.bind and java.xml.ws modules took a lot of effort because of the callbacks and missing privileged blocks. It does take a lot of effort and testing to be confident. So my personal view (and not my call) is that it's probably not high priority to do the same for jdk.compiler at this time. -Alan From jonathan.gibbons at oracle.com Tue Sep 11 19:44:32 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 11 Sep 2018 12:44:32 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <0d57cc5e-a897-eab4-77c0-ad4b192866d3@oracle.com> References: <5B96D5F5.7010800@oracle.com> <8dee0eec-9357-f688-676a-46a72c0c7de4@oracle.com> <8f2ff168-d2a1-f62f-ad91-ba6b8c01a645@oracle.com> <0d57cc5e-a897-eab4-77c0-ad4b192866d3@oracle.com> Message-ID: <5B981B20.2070309@oracle.com> Alan, Thanks for all the feedback. I'll add the extra test case you suggest. -- Jon On 09/11/2018 12:34 PM, Alan Bateman wrote: > On 11/09/2018 19:42, Jonathan Gibbons wrote: >> : >> >> As regards the interaction between Source Launcher and the use of a >> security manager, I see 3 possibilities: >> >> 1. Specifically support it, as provided in this webrev >> 2. No code change, but update JEP 330 to specify the behavior >> 3. Explicitly reject the combination of Source Launcher and the >> security manager. > Since you've started into this then it's probably best to just > continue with #1 and get it done. My main point here was the test in > the webrev sets the security manager on the command line and I think > you also need another test that sets in the test main method. > > >>> >>> Is there any way (spi.ToolProvider or some means) for untrusted code >>> to indirectly run the source launcher? This question is important >>> because the updated source launcher could be abused to probe >>> anywhere on the file system. >> Untrusted code can only run the source launcher by breaking >> encapsulation on the command line. The source launcher is a >> combination of native code in the launcher itself and a class in an >> unexported package of jdk.compiler. Even if you could access the >> source launcher, the compilation command line (i.e. the args for the >> internal call to javac) is highly constrained, and so it is difficult >> to see how the source launcher could be abused. > Thanks, the question had to be asked because the privileged block in > the source launcher main means it can access any file. > >>> >>> What are the implications for uses of javax.tools and >>> com.sun.tools.javac.Main in code running with a security manager? >>> Maybe that is a separate project but I would have expected to see >>> privileged blocks in places that need permissions. >> The intent was to stay clear (in this changeset) of all other ways of >> invoking javac, meaning javax.tools, com.sun.tools.javac.Main and >> spi.ToolProvider. While there are relatively few ways to invoke >> javac, these ways all permit the use of annotation processors and >> other callbacks, and so we would need privileged blocks in all places >> where callbacks could re-enter javac. > That is what I was wondering about it. I don't see a queue at the door > of developers looking to run javac with a security manager but at the > same time it is possible to configure many app servers with JSP > support to run with a security manager. I assume they must have > historically granted at least some permissions to "tools.jar" for this > to work. > >> >> If we were to drop the support for a security manager from the source >> launcher, would you still consider it worthwhile to update the policy >> file to enumerate the privileges required to run javac? Setting aside >> the updates for the Source Launcher tests, I think the work to >> improve all the other tests to function better when a security >> manager is involved is also worth while. > It took a lot of work in JDK 9 to identify the minimum permissions > needed by several modules. The java.xml.bind and java.xml.ws modules > took a lot of effort because of the callbacks and missing privileged > blocks. It does take a lot of effort and testing to be confident. So > my personal view (and not my call) is that it's probably not high > priority to do the same for jdk.compiler at this time. > > -Alan > From sean.mullan at oracle.com Tue Sep 11 19:48:30 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Sep 2018 15:48:30 -0400 Subject: SSL session cache default maximum number of entries In-Reply-To: <65e68e95-dac4-7443-02ad-0e2375b740cb@oracle.com> References: <7BB7D5C5-2B63-4451-AC8B-3C65D231BBDC@amazon.com> <65e68e95-dac4-7443-02ad-0e2375b740cb@oracle.com> Message-ID: Hi Paul, Thank you for bringing this issue to our attention. While we agree that this does indeed seem like an issue that should be addressed, it is quite late in the JDK 11 schedule, and it does not appear to be a new issue introduced in JDK 11. We will be investigating this offline and will get back to you as soon as we can with more details. Offhand, I think that we would be able to change the default in an update release. Also, you are probably already be aware of this, but you can use the SSLSessionContext.setSessionCacheSize() API as well as the "javax.net.ssl.sessionCacheSize" system property to customize the cache size. --Sean On 9/11/18 12:02 PM, Sean Mullan wrote: > cross-posting to security-dev since this is related to SSL/TLS. > > On 9/11/18 11:41 AM, Hohensee, Paul wrote: >> The default value for the maximum number of entries in the SSL session >> cache (which is a SoftReference cache) is infinite, and the entry >> timeout is 24 hours. With larger heaps, we?re running into situations >> where the cache ends up with several million entries when the 24 hours >> are up. They?re then all invalidated at the same time, resulting in >> multi-minute pauses (effectively service failures). We?ve experimented >> with using 10k as the default maximum number of entries with good >> results (i.e., no latency increases due to sessions falling out of the >> cache). It?s late and a long shot for JDK11: we?d love to see it >> changed there because 11 is an LTS release and this is, at least >> nominally, a behavior change which might not be acceptable in 11u. >> What do people think? >> >> Thanks, >> >> Paul >> From sean.mullan at oracle.com Tue Sep 11 19:53:24 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Sep 2018 15:53:24 -0400 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <5B96D5F5.7010800@oracle.com> References: <5B96D5F5.7010800@oracle.com> Message-ID: I have looked over the changes and they look reasonable, though I am not very familiar with this code. I was wondering, when running with the PermissiveTestSecurityManager did you also have to enable security debugging (ex: java.security.debug=access) so that you log the permissions that were required? If so, it might be helpful to add that to the comments in the test. If not, how did you figure that out? - it's not immediately apparent when looking at the code. --Sean On 9/10/18 4:37 PM, Jonathan Gibbons wrote: > Please review a patch to have the Source Launcher be able to work when a > security manager is enabled. > > There are 4 parts to the work: an update to the default policy file, an > update to the source launcher itself, updates to tests, and a custom > security manager to help with testing. > > 1. src/java.base/share/lib/security/default.policy > > Add reasonably fine-grain permissions to give javac the permissions it > needs to run when a security manager is enabled. These permissions were > determined by running all javac tests under with a special security > manager installed: more on that later. There is one anomalous property > which was detected, which is a property to control some internal javac > behavior. Arguably, it should eventually be renamed with at least a > "javac.*" prefix. > > 2. src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java > > Update the source launcher to use doPrivileged in a couple of places: > most notably around the main invocation of javac. Generally, it > continues to be the policy that command-line tools like javac, javadoc > do not use fine-grained doPrivileged blocks throughout the tool, and > this update does not change that.? It is worth noting that when javac is > invoked from the Source Launcher, it does not support callbacks like > annotation processors, task listeners, and other plugin code, so that > eliminates any issues relating to using callbacks from code in a > doPrivileged block. > > 3. test/langtools/tools/lib/security/PermissiveTestSecurityManager.java > > This is a custom new security manager for manual testing purposes in > conjunction with jtreg, so that we can run a large subset of tests under > the influence of a security manager. . It is a design characteristic of > jtreg that almost all tests have their own distinct codebase, and so it > is impractical to use a modified policy file to grant all necessary > permissions to all necessary tests, so this security manager installs a > custom Policy object that grants permissions to test code while > deferring to the system policy for everything else (and for javac in > particular.)?? Using this security manager, it is possible to run all > the javac tests to detect with high probability all the permissions that > it requires. Using a custom security manager to install a custom Policy > object allows the feature to be easily enabled on the jtreg command line. > > There is one workaround in this security manager: a bug was uncovered > such that the jdk.zipfs module needs permission to access the user.dir > system property.? ( https://bugs.openjdk.java.net/browse/JDK-8210469 ) A > temporary workaround is used to get a clean test run. > > Note: this code is not directly used in any normal/automated test runs > for javac; nevertheless, it is deemed worthwhile to save the code for > use in similar situations in the future. > > 4. Minor updates to tests. > > Some new test cases are added to Source Launcher tests. > > Although most tests are not directly affected by the use of a security > manager, there are some exceptions. Some tests manipulate the security > manager and/or expect the security manager to be unset.? These tests are > modified to "pass by default" if the runtime conditions are not suitable > (i.e. a security manager has been installed.) > > Although it is not a requirement to be able to run annotation processing > tests when a security manager is enabled (because that condition cannot > arise with the Source Launcher), most annotation processing tests do run > successfully. There were 3 exceptions, where the test required more > permissions than granted to javac in code being called from javac. These > permissions were to access test.* system properties and the setIO > runtime permission. Rather than grant unnecessary properties to javac, > it was enough to use doPrivileged in a couple of places in the javac > "toolbox" test library, and to refactor those tests to better use toolbox. > > In conjunction with these changes,ignoring any tests on the ProblemList, > all javac tests pass, with and without a security manager being present. > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210274 > Webrev: http://cr.openjdk.java.net/~jjg/8210274/webrev.00/ > > > -- Jon From jonathan.gibbons at oracle.com Tue Sep 11 20:33:48 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 11 Sep 2018 13:33:48 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: References: <5B96D5F5.7010800@oracle.com> Message-ID: <5B9826AC.9080507@oracle.com> On 09/11/2018 12:53 PM, Sean Mullan wrote: > I have looked over the changes and they look reasonable, though I am > not very familiar with this code. > > I was wondering, when running with the PermissiveTestSecurityManager > did you also have to enable security debugging (ex: > java.security.debug=access) so that you log the permissions that were > required? If so, it might be helpful to add that to the comments in > the test. If not, how did you figure that out? - it's not immediately > apparent when looking at the code. > > --Sean Sean, Thanks for looking at this. I did not need to enable any security debugging when using the PermissiveTestSecurityManager. For the most part, the basic security infrastructure was good enough by itself, since it reported enough information in the SecurityExceptions to be able to easily determine the missing but required permissions. It helped to have a sense of what permissions might be required, such file access, system properties, and permissions for class loaders and reflections in some limited parts of javac, and the corresponding tests in the test suite. The most "tedious" part was just running the tests until all the issues had been found and fixed, but that being said, the overall process converged pretty quickly. I will note that PermissiveTestSecurityManager arrived late in the game for this work. For the most part, I was using the plain standard security manager, and was adding permissions for tests as needed in a custom policy file that I also specified on the jtreg command line. That work could never have been checked in, since it involved lots of host-specific paths in the additional policy file. It was only later on that I came up with the idea of using first a custom security manager, and from there, the idea of using a custom policy in the custom security manager. The use of PermissiveTestSecurityManager made it much faster to find and fix all remaining issues and enabled me to achieve the goal of getting all javac tests to work, instead of settling for most tests. (I had previously been prepared to set aside and ignore the main block of annotation processing tests.) -- Jon From mandy.chung at oracle.com Tue Sep 11 20:56:56 2018 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 11 Sep 2018 13:56:56 -0700 Subject: RFR: JDK-8210274: Source Launcher should work with a security manager In-Reply-To: <0d57cc5e-a897-eab4-77c0-ad4b192866d3@oracle.com> References: <5B96D5F5.7010800@oracle.com> <8dee0eec-9357-f688-676a-46a72c0c7de4@oracle.com> <8f2ff168-d2a1-f62f-ad91-ba6b8c01a645@oracle.com> <0d57cc5e-a897-eab4-77c0-ad4b192866d3@oracle.com> Message-ID: On 9/11/18 12:34 PM, Alan Bateman wrote: >>> >>> What are the implications for uses of javax.tools and >>> com.sun.tools.javac.Main in code running with a security manager? >>> Maybe that is a separate project but I would have expected to see >>> privileged blocks in places that need permissions. >> The intent was to stay clear (in this changeset) of all other ways of >> invoking javac, meaning javax.tools, com.sun.tools.javac.Main and >> spi.ToolProvider. While there are relatively few ways to invoke >> javac, these ways all permit the use of annotation processors and >> other callbacks, and so we would need privileged blocks in all places >> where callbacks could re-enter javac. > That is what I was wondering about it. I don't see a queue at the door > of developers looking to run javac with a security manager but at the > same time it is possible to configure many app servers with JSP > support to run with a security manager. I assume they must have > historically granted at least some permissions to "tools.jar" for this > to work. > Probably.? Also they might also wrap their call to javac with doPrivileged. >> >> If we were to drop the support for a security manager from the source >> launcher, would you still consider it worthwhile to update the policy >> file to enumerate the privileges required to run javac? Setting aside >> the updates for the Source Launcher tests, I think the work to >> improve all the other tests to function better when a security >> manager is involved is also worth while. > It took a lot of work in JDK 9 to identify the minimum permissions > needed by several modules. The java.xml.bind and java.xml.ws modules > took a lot of effort because of the callbacks and missing privileged > blocks. It does take a lot of effort and testing to be confident. So > my personal view (and not my call) is that it's probably not high > priority to do the same for jdk.compiler at this time. I see this changeset is to get the source launcher to work with security manager so that launching in class file mode and source mode can specify the same runtime options. You are right that it'd be a lot of effort to get jdk.compiler to work with callbacks and missing privileged blocks.? The minimum permissions are good for source launcher support.?? If we were to drop the support for a security manager from the source launcher, I think jdk.compiler would need AllPermission due to callback. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed Sep 12 00:20:59 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 11 Sep 2018 17:20:59 -0700 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> <7203910f-333f-89d5-ea04-ffb4b42ac542@oracle.com> <2d949ed6-5089-1cae-0960-2790afcb25d2@oracle.com> <8c273087-e41d-3978-4d93-8cb5f7cc9bb8@redhat.com> Message-ID: <99cc28cf-4550-1894-b366-9da2a49e70f8@oracle.com> Hi, Martin, I am ok with your option#1. Note that your test fails at different places of the code, so you will need to check and skip test execution before those exception are thrown. Valerie On 9/11/2018 7:54 AM, Martin Balao wrote: > Hi Valerie, > > On Fri, Aug 31, 2018 at 9:16 PM, Valerie Peng > wrote: > > Hi Martin, > > In TestTLS12.java, you call the initSecmod() inside initialize() > and when initSecmod() returns false, you return from initialize() > and continue down the main(). Is this intentional? Other tests > seems to be skipping execution when initSecmod() return false. > > > This test skips execution too. That's because?shouldRun method returns > false if?sunPKCS11NSSProvider variable is null (which it is if > initSecmod returns false). > > > Changes in webrev.08 resolves 2 out of the 4 failure cases for > TestTLS12.java. However, when I submit the changes for testing, it > failed on some OS (see below): > > macosx-x64: > > jib > STDOUT: > jib > nssLibDir: > /scratch/mesos/jib-master/install/jpg/tests/jdk/nsslib/nsslib-macosx_x64/3.35/nsslib-macosx_x64-3.35.zip/nsslib/ > jib > STDERR: > jib > java.security.ProviderException: Could not initialize NSS > jib >? ?at > jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:218) > jib >? ?at > jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:113) > jib >? ?at > jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:110) > jib >? ?at > java.base/java.security.AccessController.doPrivileged(Native > Method) > jib >? ?at > jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:110) > jib >? ?at PKCS11Test.getSunPKCS11(PKCS11Test.java:156) > jib >? ?at TestTLS12.initialize(TestTLS12.java:416) > jib >? ?at TestTLS12.main(TestTLS12.java:84) > jib >? ?at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > jib >? ?at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > jib >? ?at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > jib >? ?at java.base/java.lang.reflect.Me > thod.invoke(Method.java:566) > jib >? ?at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > jib >? ?at java.base/java.lang.Thread.run(Thread.java:834) > jib > Caused by: java.io.IOException: NSS initialization failed > jib >? ?at > jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.initialize(Secmod.java:234) > jib >? ?at > jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:213) > jib >? ?... 13 more > jib > > jib > JavaTest Message: Test threw exception: > java.security.ProviderException: Could not initialize NSS > > > windows-x64: > > jib > STDOUT: > jib > nssLibDir: > C:\ADE\mesos\work_dir\jib-master\install\jpg\tests\jdk\nsslib\nsslib-windows_x64\3.35\nsslib-windows_x64-3.35.zip\nsslib\ > jib > SunPKCS11 provider: SunPKCS11-NSSKeyStore version 12 > jib > STDERR: > jib > java.security.ProviderException: SunJSSE already > initialized in non-FIPS mode > jib >? ?at > java.base/sun.security.ssl.SunJSSE.ensureFIPS(SunJSSE.java:94) > jib >? ?at > java.base/sun.security.ssl.SunJSSE.(SunJSSE.java:146) > jib >? ?at > java.base/sun.security.ssl.SunJSSE.(SunJSSE.java:118) > jib >? ?at > java.base/com.sun.net.ssl.internal.ssl.Provider.(Provider.java:47) > jib >? ?at TestTLS12.initialize(TestTLS12.java:424) > jib >? ?at TestTLS12.main(TestTLS12.java:84) > jib >? ?at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > jib >? ?at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > jib >? ?at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > jib >? ?at java.base/java.lang.reflect.Me > thod.invoke(Method.java:566) > jib >? ?at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > jib >? ?at java.base/java.lang.Thread.run(Thread.java:834) > jib > > jib > JavaTest Message: Test threw exception: > java.security.ProviderException: SunJSSE already initialized > in non-FIPS mode > > > > The 2 tests that initialize NSS in FIPS mode (TrustManagerTest and > ClientJSSEServerJSSE) only run on Solaris. My guess is that these > failures are not particular to TestTLS12 but to NSS + FIPS support on > these setups. I won't be able to reproduce the macOS failure and I'm > not sure if I'll be able to reproduce in my Windows x86_64 environment. > > I propose the following options: > > ?1) Make the test skip macOS & Windows x86_64 (and any other platform > that fails to initialize the SunPKCS11 provider) > > ?2) If you can provide access to a testing environment where I can > reproduce these failures, I can see what's happening > > I intentionally want to use FIPS in NSS configuration because it > represents a real use case, and is what motivated us to support TLS > 1.2 in SunPKCS11. So, even though removing FIPS would be an option, I > prefer not to take it. > > Kind regards, > Martin.- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Sep 12 02:22:49 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 11 Sep 2018 19:22:49 -0700 Subject: Code Review Request, JDK-8209916 : NPE in SupportedGroupsExtension Message-ID: <5eda7e87-8872-c336-c3bc-4f8d65541567@oracle.com> Hi Jamil, Would you please review the fix for the NPE issue: http://cr.openjdk.java.net/~xuelei/8209916/webrev.00/ The issue may happen if the client supports a SunJSSE provider known but not supported named group. Thanks, Xuelei From jamil.j.nimeh at oracle.com Wed Sep 12 03:11:40 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 11 Sep 2018 20:11:40 -0700 Subject: Code Review Request, JDK-8209916 : NPE in SupportedGroupsExtension In-Reply-To: <5eda7e87-8872-c336-c3bc-4f8d65541567@oracle.com> Message-ID: <201809120311.w8C3Bn02020536@aserv0121.oracle.com> Yes I will take a look at this tonight. --Jamil -------- Original message --------From: Xuelei Fan Date: 9/11/18 7:22 PM (GMT-08:00) To: security-dev at openjdk.java.net, Jamil Nimeh Subject: Code Review Request, JDK-8209916 : NPE in SupportedGroupsExtension Hi Jamil, Would you please review the fix for the NPE issue: ??? http://cr.openjdk.java.net/~xuelei/8209916/webrev.00/ The issue may happen if the client supports a SunJSSE provider known but not supported named group. Thanks, Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Wed Sep 12 03:43:44 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 11 Sep 2018 20:43:44 -0700 Subject: Code Review Request, JDK-8209916 : NPE in SupportedGroupsExtension In-Reply-To: <5eda7e87-8872-c336-c3bc-4f8d65541567@oracle.com> References: <5eda7e87-8872-c336-c3bc-4f8d65541567@oracle.com> Message-ID: Looks good to me. Thanks, --Jamil On 9/11/2018 7:22 PM, Xuelei Fan wrote: > Hi Jamil, > > Would you please review the fix for the NPE issue: > ?? http://cr.openjdk.java.net/~xuelei/8209916/webrev.00/ > > The issue may happen if the client supports a SunJSSE provider known > but not supported named group. > > Thanks, > Xuelei From weijun.wang at oracle.com Wed Sep 12 08:23:46 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 12 Sep 2018 16:23:46 +0800 Subject: RSACore$BlindingParameters not using user-provided SecureRandom Message-ID: <823E2072-8D00-4766-8FB9-F3AB15B07064@oracle.com> In src/java.base/share/classes/sun/security/rsa/RSACore.java: 353 BlindingParameters(BigInteger e, BigInteger d, BigInteger n) { 354 this.u = null; 355 this.v = null; 356 this.e = e; 357 this.d = d; 358 359 int len = n.bitLength(); ** 360 SecureRandom random = JCAUtil.getSecureRandom(); 361 u = new BigInteger(len, random).mod(n); Here, it is not using the SecureRandom passed into init() of either Signature or Cipher. Is this a bug we should fix? Thanks Max From matthias.baesken at sap.com Wed Sep 12 09:27:15 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 12 Sep 2018 09:27:15 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: <95de743b-4b00-91ac-9fd4-1cd77acdb5ab@oracle.com> References: <0cee5b67a5d1476d8318837b770de382@sap.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com> <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com> <95de743b-4b00-91ac-9fd4-1cd77acdb5ab@oracle.com> Message-ID: Hello I changed it to jar , also added some minor adjustments suggested by Christoph . http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.12/ Regards, Matthias > -----Original Message----- > From: Sean Mullan > Sent: Dienstag, 11. September 2018 20:44 > To: Langer, Christoph ; Baesken, Matthias > ; Weijun Wang > Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > On 9/11/18 8:14 AM, Langer, Christoph wrote: > > Hi, > > > > first of all, I suggest to use "jarDetails" instead of "jarPath" as category > name. Because with this contribution we add the notion of jar file plus line of > manifest to Exceptions occurring when parsing jar manifests. And if there > were further Exception details to be added in the area of jar files, they could > go under a category "jarDetails" as well. Would you agree? Then, in > Manifest.java, the field "jarPathInExceptionText" could be renamed to > "detailedExceptions". > > Or just "jar" would be my preference. I don't like "jarPath" as that > sounds too much like a file pathname to me, which we have now removed. > > --Sean From mbalao at redhat.com Wed Sep 12 11:22:58 2018 From: mbalao at redhat.com (Martin Balao) Date: Wed, 12 Sep 2018 13:22:58 +0200 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: <99cc28cf-4550-1894-b366-9da2a49e70f8@oracle.com> References: <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com> <7203910f-333f-89d5-ea04-ffb4b42ac542@oracle.com> <2d949ed6-5089-1cae-0960-2790afcb25d2@oracle.com> <8c273087-e41d-3978-4d93-8cb5f7cc9bb8@redhat.com> <99cc28cf-4550-1894-b366-9da2a49e70f8@oracle.com> Message-ID: Hi Valerie, Thanks for your answer. Webrev.09: * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.09/ * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.09.zip In TestTLS12.java, we now capture any exception during initialization phase and skip test execution if that happens. Kind regards, Martin.- On Wed, Sep 12, 2018 at 2:20 AM, Valerie Peng wrote: > Hi, Martin, > I am ok with your option#1. > Note that your test fails at different places of the code, so you will > need to check and skip test execution before those exception are thrown. > > Valerie > > > On 9/11/2018 7:54 AM, Martin Balao wrote: > > Hi Valerie, > > On Fri, Aug 31, 2018 at 9:16 PM, Valerie Peng > wrote: > >> Hi Martin, >> >> In TestTLS12.java, you call the initSecmod() inside initialize() and when >> initSecmod() returns false, you return from initialize() and continue down >> the main(). Is this intentional? Other tests seems to be skipping execution >> when initSecmod() return false. >> > > This test skips execution too. That's because shouldRun method returns > false if sunPKCS11NSSProvider variable is null (which it is if initSecmod > returns false). > > >> >> Changes in webrev.08 resolves 2 out of the 4 failure cases for >> TestTLS12.java. However, when I submit the changes for testing, it failed >> on some OS (see below): >> >> macosx-x64: >> >> jib > STDOUT: >>> jib > nssLibDir: /scratch/mesos/jib-master/inst >>> all/jpg/tests/jdk/nsslib/nsslib-macosx_x64/3.35/nsslib-macos >>> x_x64-3.35.zip/nsslib/ >>> jib > STDERR: >>> jib > java.security.ProviderException: Could not initialize NSS >>> jib > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(Sun >>> PKCS11.java:218) >>> jib > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunP >>> KCS11.java:113) >>> jib > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunP >>> KCS11.java:110) >>> jib > at java.base/java.security.AccessController.doPrivileged(Native >>> Method) >>> jib > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure( >>> SunPKCS11.java:110) >>> jib > at PKCS11Test.getSunPKCS11(PKCS11Test.java:156) >>> jib > at TestTLS12.initialize(TestTLS12.java:416) >>> jib > at TestTLS12.main(TestTLS12.java:84) >>> jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>> jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo >>> ke(NativeMethodAccessorImpl.java:62) >>> jib > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. >>> invoke(DelegatingMethodAccessorImpl.java:43) >>> jib > at java.base/java.lang.reflect.Method.invoke(Method.java:566) >>> jib > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(Ma >>> inWrapper.java:127) >>> jib > at java.base/java.lang.Thread.run(Thread.java:834) >>> jib > Caused by: java.io.IOException: NSS initialization failed >>> jib > at jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.initialize(Se >>> cmod.java:234) >>> jib > at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(Sun >>> PKCS11.java:213) >>> jib > ... 13 more >>> jib > >>> jib > JavaTest Message: Test threw exception: >>> java.security.ProviderException: Could not initialize NSS >>> >> > > >> windows-x64: >> >> jib > STDOUT: >>> jib > nssLibDir: C:\ADE\mesos\work_dir\jib-mast >>> er\install\jpg\tests\jdk\nsslib\nsslib-windows_x64\3.35\nssl >>> ib-windows_x64-3.35.zip\nsslib\ >>> jib > SunPKCS11 provider: SunPKCS11-NSSKeyStore version 12 >>> jib > STDERR: >>> jib > java.security.ProviderException: SunJSSE already initialized in >>> non-FIPS mode >>> jib > at java.base/sun.security.ssl.SunJSSE.ensureFIPS(SunJSSE.java:9 >>> 4) >>> jib > at java.base/sun.security.ssl.SunJSSE.(SunJSSE.java:146) >>> jib > at java.base/sun.security.ssl.SunJSSE.(SunJSSE.java:118) >>> jib > at java.base/com.sun.net.ssl.internal.ssl.Provider.(Provi >>> der.java:47) >>> jib > at TestTLS12.initialize(TestTLS12.java:424) >>> jib > at TestTLS12.main(TestTLS12.java:84) >>> jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>> jib > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo >>> ke(NativeMethodAccessorImpl.java:62) >>> jib > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. >>> invoke(DelegatingMethodAccessorImpl.java:43) >>> jib > at java.base/java.lang.reflect.Method.invoke(Method.java:566) >>> jib > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(Ma >>> inWrapper.java:127) >>> jib > at java.base/java.lang.Thread.run(Thread.java:834) >>> jib > >>> jib > JavaTest Message: Test threw exception: >>> java.security.ProviderException: SunJSSE already initialized in >>> non-FIPS mode >>> >> >> > The 2 tests that initialize NSS in FIPS mode (TrustManagerTest and > ClientJSSEServerJSSE) only run on Solaris. My guess is that these failures > are not particular to TestTLS12 but to NSS + FIPS support on these setups. > I won't be able to reproduce the macOS failure and I'm not sure if I'll be > able to reproduce in my Windows x86_64 environment. > > I propose the following options: > > 1) Make the test skip macOS & Windows x86_64 (and any other platform that > fails to initialize the SunPKCS11 provider) > > 2) If you can provide access to a testing environment where I can > reproduce these failures, I can see what's happening > > I intentionally want to use FIPS in NSS configuration because it > represents a real use case, and is what motivated us to support TLS 1.2 in > SunPKCS11. So, even though removing FIPS would be an option, I prefer not > to take it. > > Kind regards, > Martin.- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Sep 12 11:34:15 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 12 Sep 2018 11:34:15 +0000 Subject: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives In-Reply-To: References: <0cee5b67a5d1476d8318837b770de382@sap.com> <41e8d677-f916-ac48-0422-9e2c595ab544@oracle.com> <74E52AF0-69F0-4F07-8211-399C253588C0@oracle.co! m> <8C51BB89-7F70-47D7-83BB-6FED26ACF839@oracle.com> <71ef76a6-6279-66eb-388a-a0ba13d5742e@oracle.com> <4E5B75C0-548B-4C59-9A26-C5BDD9779E57@oracle.com> <14B182E9-1751-4D95-9B3D-6211E1CB9659@oracle.com> <7e1c5f50a2f0425980d21f76f23d1dd8@sap.com> <95de743b-4b00-91ac-9fd4-1cd77acdb5ab@oracle.com> Message-ID: <1f624224baf540d193d053af4f650e96@sap.com> Looks good to me. > -----Original Message----- > From: Baesken, Matthias > Sent: Mittwoch, 12. September 2018 11:27 > To: Sean Mullan ; Langer, Christoph > ; Weijun Wang > Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: RE: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > Hello I changed it to jar , also added some minor adjustments suggested by > Christoph . > > http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.12/ > > > Regards, Matthias > > > > -----Original Message----- > > From: Sean Mullan > > Sent: Dienstag, 11. September 2018 20:44 > > To: Langer, Christoph ; Baesken, Matthias > > ; Weijun Wang > > Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > > parsing of jar archives > > > > On 9/11/18 8:14 AM, Langer, Christoph wrote: > > > Hi, > > > > > > first of all, I suggest to use "jarDetails" instead of "jarPath" as category > > name. Because with this contribution we add the notion of jar file plus line > of > > manifest to Exceptions occurring when parsing jar manifests. And if there > > were further Exception details to be added in the area of jar files, they > could > > go under a category "jarDetails" as well. Would you agree? Then, in > > Manifest.java, the field "jarPathInExceptionText" could be renamed to > > "detailedExceptions". > > > > Or just "jar" would be my preference. I don't like "jarPath" as that > > sounds too much like a file pathname to me, which we have now removed. > > > > --Sean From jai.forums2013 at gmail.com Wed Sep 12 15:41:41 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 12 Sep 2018 21:11:41 +0530 Subject: Java 11 RC - Handshake failure in certain specific cases throws a different exception than previous versions Message-ID: <5a20a75d-d5b0-56d9-af7e-4be2cb23098c@gmail.com> Please consider the code that's at the end of this mail. It is a simple client/server code where a HTTPS server is created and set to "needClientAuth". The client then uses HttpsURLConnection and (in this case intentionally) doesn't present any certificate, expecting the handshake to fail. In previous versions of Java, the handshake failure in this code would throw a java.net.SocketException as below: Exception in thread "main" java.net.SocketException: Connection reset ??? at java.net.SocketInputStream.read(SocketInputStream.java:210) ??? at java.net.SocketInputStream.read(SocketInputStream.java:141) ??? at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) ??? at sun.security.ssl.InputRecord.read(InputRecord.java:503) ??? at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983) ??? at sun.security.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1779) ??? at sun.security.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:124) ??? at sun.security.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:1156) ??? at sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:1266) ??? at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1178) ??? at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:348) ??? at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) ??? at sun.security.ssl.Handshaker.process_record(Handshaker.java:987) ??? at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072) ??? at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385) ??? at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413) ??? at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397) ??? at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559) ??? at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) ??? at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564) ??? at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492) ??? at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263) ??? at ClientCertTest.main(ClientCertTest.java:26) However, in the Java 11 (release candidate) as well as Java 12 (upstream), this code now throws a javax.net.ssl.SSLProtocolException with the java.net.SocketException wrapped in it: Exception in thread "main" javax.net.ssl.SSLProtocolException: Connection reset ??? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) ??? at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321) ??? at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) ??? at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259) ??? at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1314) ??? at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:839) ??? at java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:252) ??? at java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:292) ??? at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:351) ??? at java.base/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:746) ??? at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:689) ??? at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:717) ??? at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1604) ??? at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509) ??? at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245) ??? at ClientCertTest.main(ClientCertTest.java:26) Caused by: java.net.SocketException: Connection reset ??? at java.base/java.net.SocketInputStream.read(SocketInputStream.java:186) ??? at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140) ??? at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448) ??? at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:68) ??? at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1104) ??? at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) ??? ... 10 more Is this an intentional and expected change? As far as I could see, there isn't any specific API which says SocketException will be thrown in this case, so maybe the client applications which were catching this specific exception are expected to change their catch block to something more generic like a IOException? Here's the code to reproduce this: import java.io.*; import java.net.*; import javax.net.ssl.*; import java.util.*; import java.security.*; import com.sun.net.httpserver.*; import java.security.cert.*; public class ClientCertTest { ??? private static final String keyFilename = "keystore"; ??? private static final String keystorePass = "passphrase"; ??? public static void main(final String[] args) throws Exception { ??? ??? final int port = 12345; ??????? final HttpsServer server = startServer("localhost", port); ??????? try { ??? ??? ??? final URL targetURL = new URL("https://localhost:" + port + "/"); ??? ??? ??? final SSLContext sslctx = SSLContext.getInstance("TLS"); ??? ??????? sslctx.init(null, new TrustManager[] {new TrustAll()}, null); ??? ??? ??? HttpsURLConnection.setDefaultHostnameVerifier((h, s) -> {return true;}); ??? ??? ??? final HttpsURLConnection conn = (HttpsURLConnection) targetURL.openConnection(); ??? ??? ??? // setup the HTTPS connection to use our SocketFactory which doesn't present ??? ??? ??? // any cert when asked for (and thus is expected to fail handshake) ??? ??? ??? conn.setSSLSocketFactory(sslctx.getSocketFactory()); ??? ??? ??? try (final InputStream is = conn.getInputStream()) { ??? ??? ??????? is.read(); ??? ??? ??? } catch (SocketException se) { ??? ??? ??? ???? System.out.println("*** Received the expected SocketException: " + se.getMessage()); ??? ??? ??? ???? throw se; ??? ??? ??? } ??? ??? } finally { ??? ?? ??? ??? server.stop(0); ??? ??? ??? System.out.println("Stopped server"); ??? ??? } ??? } ??? private static HttpsServer startServer(final String host, final int port) throws Exception { ??????? final HttpsServer server = HttpsServer.create(new InetSocketAddress(host, port), 0); ??? ??? final Thread t = new Thread(() -> { ??? ??? ??? try { ??? ??? ??? ??? final SSLContext sslctx = SSLContext.getInstance("TLS"); ??? ??? ??????? final KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509"); ??? ??? ??????? final KeyStore ks = KeyStore.getInstance("JKS"); ??? ??? ??????? try (final FileInputStream fis = new FileInputStream(keyFilename)) { ??? ??? ??????????? ks.load(fis, keystorePass.toCharArray()); ??? ??? ??????? } ??? ??? ??????? kmf.init(ks, keystorePass.toCharArray()); ??? ??? ??????? sslctx.init(kmf.getKeyManagers(), null, null); ??? ??? ??????? final SSLParameters sslParameters = sslctx.getDefaultSSLParameters(); ??? ??? ??????? // need client auth ??? ??? ??????? sslParameters.setNeedClientAuth(true); ??? ??? ??????? server.setHttpsConfigurator(new HttpsConfigurator(sslctx) { ??? ??? ??????? ??? @Override ??? ??? ??????? ??? public void configure(final HttpsParameters params) { ??? ??? ??????? ??? ??? params.setSSLParameters(sslParameters); ??? ??? ??????? ??? } ??? ??? ??????? }); ??? ??? ??? ??? server.start(); ??? ??? ??? ??? System.out.println("Started server at " + server.getAddress()); ??? ??? ??? } catch(Exception e) { ??? ??? ??? ??? throw new RuntimeException(e); ??? ??? ??? } ??? ??? }); ??? ??? t.start(); ??? ??? return server; ??? } ??? private static class TrustAll implements X509TrustManager { ??? ??? @Override ??? ??? public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException { ??? ??? ??? return; ??????? } ??? ??? @Override ??? ??? public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { ??? ??? ??? return; ??? ??? } ??? ??? @Override ??? ??? public X509Certificate[] getAcceptedIssuers() { ??? ??? ??? return new X509Certificate[0]; ??? ??? } ??? } } P.S: The "keystore" file in this example is the same one that's present in the openjdk repo at test/jdk/javax/net/ssl/etc/keystore, so in order to run the above code, that file can just be placed in the current working dir. -Jaikiran From openjdk at suche.org Wed Sep 12 16:50:30 2018 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Wed, 12 Sep 2018 18:50:30 +0200 Subject: Code Review Request, JDK-8209916 : NPE in SupportedGroupsExtension In-Reply-To: <5eda7e87-8872-c336-c3bc-4f8d65541567@oracle.com> References: <5eda7e87-8872-c336-c3bc-4f8d65541567@oracle.com> Message-ID: <1fd400b0-caff-3737-0134-efafce8a6aaf@suche.org> Hi, does the fix work if there is only one unknown named group ? Not that the connection fails than with an better error text instead of skiping the unknown group. Gru? Thomas On 12.09.2018 04:22:49, Xuelei Fan wrote: > Hi Jamil, > > Would you please review the fix for the NPE issue: > ?? http://cr.openjdk.java.net/~xuelei/8209916/webrev.00/ > > The issue may happen if the client supports a SunJSSE provider known > but not supported named group. > > Thanks, > Xuelei From hohensee at amazon.com Wed Sep 12 18:25:54 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 12 Sep 2018 18:25:54 +0000 Subject: SSL session cache default maximum number of entries In-Reply-To: References: <7BB7D5C5-2B63-4451-AC8B-3C65D231BBDC@amazon.com> <65e68e95-dac4-7443-02ad-0e2375b740cb@oracle.com> Message-ID: <4CCB1576-6BFA-430B-974D-86DFD0D864E6@amazon.com> Thanks very much for investigating. We're aware that the cache size can be set by the user, but many of our users haven't done so because it hasn't been necessary, and boom. Paul ?On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan" wrote: Hi Paul, Thank you for bringing this issue to our attention. While we agree that this does indeed seem like an issue that should be addressed, it is quite late in the JDK 11 schedule, and it does not appear to be a new issue introduced in JDK 11. We will be investigating this offline and will get back to you as soon as we can with more details. Offhand, I think that we would be able to change the default in an update release. Also, you are probably already be aware of this, but you can use the SSLSessionContext.setSessionCacheSize() API as well as the "javax.net.ssl.sessionCacheSize" system property to customize the cache size. --Sean On 9/11/18 12:02 PM, Sean Mullan wrote: > cross-posting to security-dev since this is related to SSL/TLS. > > On 9/11/18 11:41 AM, Hohensee, Paul wrote: >> The default value for the maximum number of entries in the SSL session >> cache (which is a SoftReference cache) is infinite, and the entry >> timeout is 24 hours. With larger heaps, we?re running into situations >> where the cache ends up with several million entries when the 24 hours >> are up. They?re then all invalidated at the same time, resulting in >> multi-minute pauses (effectively service failures). We?ve experimented >> with using 10k as the default maximum number of entries with good >> results (i.e., no latency increases due to sessions falling out of the >> cache). It?s late and a long shot for JDK11: we?d love to see it >> changed there because 11 is an LTS release and this is, at least >> nominally, a behavior change which might not be acceptable in 11u. >> What do people think? >> >> Thanks, >> >> Paul >> From bradford.wetmore at oracle.com Thu Sep 13 01:17:46 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 12 Sep 2018 18:17:46 -0700 Subject: NPE in SupportedGroupsExtension In-Reply-To: <9438e88e-9a29-8898-7181-1a5c95190e47@oracle.com> References: <82966446-732a-c992-0c7d-c8d6c8cba8c8@oracle.com> <1e80314f-2594-4d98-2638-f29f2fa25f2c@suche.org> <9438e88e-9a29-8898-7181-1a5c95190e47@oracle.com> Message-ID: Thomas, >> i found another bug with firefox nigthly "64.0a1 (2018-09-08) >> (64-bit)" and "OpenJDK Runtime Environment 18.9 (build 11+28)". Max/I are running a slightly later builds, 64.0a1 (2018-09-10) and (2018-09-12) respectively, and we're now seeing the psk_key_exchange_modes extension. Can you confirm if you're seeing this (or not) with a more recent build of FF 64.0a1? "psk_key_exchange_modes (45)": { "ke_modes": [psk_dhe_ke] } Thanks much, Brad On 9/9/2018 9:11 PM, Jamil Nimeh wrote: > Hi Thomas, > > This is a known issue captured in JDK-8210334 and the fix for it was > committed to JDK 12 a few days ago.? Looks like the backport of the fix > is planned for 11.0.2.? The backport ID is JDK-8210445 in case you're > interested. > > --Jamil > > On 9/9/2018 2:44 PM, Thomas Lu?nig wrote: >> Hi, >> >> i found another bug with firefox nigthly "64.0a1 (2018-09-08) >> (64-bit)" and "OpenJDK Runtime Environment 18.9 (build 11+28)". >> It is not possible to establish an connection. The exception i receive >> is "pre_shared_key key extension is offered without a >> psk_key_exchange_modes extension". >> If there is an PSK without an matching extension this should not kill >> the connection i think. Nearly all other server accept this. >> >> Gru? Thomas Lu?nig >> >> javax.net.ssl.SSLHandshakeException: pre_shared_key key extension is >> offered without a psk_key_exchange_modes extension >> >> ?? ?at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >> ?? ?at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> ?? ?at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >> >> ?? ?at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) >> >> ?? ?at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) >> >> ?? ?at >> java.base/sun.security.ssl.PskKeyExchangeModesExtension$PskKeyExchangeModesOnTradeAbsence.absent(PskKeyExchangeModesExtension.java:327) >> >> ?? ?at >> java.base/sun.security.ssl.SSLExtension.absentOnTrade(SSLExtension.java:572) >> >> ?? ?at >> java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:180) >> >> ?? ?at >> java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:522) >> >> ?? ?at >> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) >> ?? ?at >> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1189) >> >> ?? ?at >> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1125) >> >> ?? ?at >> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:831) >> >> ?? ?at >> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:792) >> >> ?? ?at >> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >> ?? ?at >> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) >> >> ?? ?at >> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1065) >> >> ?? ?at >> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1052) >> >> ?? ?at java.base/java.security.AccessController.doPrivileged(Native >> Method) >> ?? ?at >> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:999) >> >> > From bradford.wetmore at oracle.com Thu Sep 13 01:37:52 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 12 Sep 2018 18:37:52 -0700 Subject: NPE in SupportedGroupsExtension In-Reply-To: References: <82966446-732a-c992-0c7d-c8d6c8cba8c8@oracle.com> <1e80314f-2594-4d98-2638-f29f2fa25f2c@suche.org> <9438e88e-9a29-8898-7181-1a5c95190e47@oracle.com> Message-ID: <460c1028-27c9-3819-dc5b-849cb52e73f9@oracle.com> We finally found what I think are the 2018-09-08 nightly builds. https://download-origin.cdn.mozilla.net/pub/firefox/nightly/2018/09/ specifically: https://download-origin.cdn.mozilla.net/pub/firefox/nightly/2018/09/2018-09-08-10-04-02-mozilla-central/firefox-64.0a1.en-US.win64.installer.exe Max/I tried it on Windows-x64 with no problems. Can you confirm which build/architecture, etc.? Thanks, Brad On 9/12/2018 6:17 PM, Bradford Wetmore wrote: > Thomas, > > >> i found another bug with firefox nigthly "64.0a1 (2018-09-08) > >> (64-bit)" and "OpenJDK Runtime Environment 18.9 (build 11+28)". > > Max/I are running a slightly later builds, 64.0a1 (2018-09-10) and > (2018-09-12) respectively, and we're now seeing the > psk_key_exchange_modes extension. > > Can you confirm if you're seeing this (or not) with a more recent build > of FF 64.0a1? > > ??? "psk_key_exchange_modes (45)": { > ????? "ke_modes": [psk_dhe_ke] > ??? } > > Thanks much, > > Brad > > > > > On 9/9/2018 9:11 PM, Jamil Nimeh wrote: >> Hi Thomas, >> >> This is a known issue captured in JDK-8210334 and the fix for it was >> committed to JDK 12 a few days ago.? Looks like the backport of the >> fix is planned for 11.0.2.? The backport ID is JDK-8210445 in case >> you're interested. >> >> --Jamil >> >> On 9/9/2018 2:44 PM, Thomas Lu?nig wrote: >>> Hi, >>> >>> i found another bug with firefox nigthly "64.0a1 (2018-09-08) >>> (64-bit)" and "OpenJDK Runtime Environment 18.9 (build 11+28)". >>> It is not possible to establish an connection. The exception i >>> receive is "pre_shared_key key extension is offered without a >>> psk_key_exchange_modes extension". >>> If there is an PSK without an matching extension this should not kill >>> the connection i think. Nearly all other server accept this. >>> >>> Gru? Thomas Lu?nig >>> >>> javax.net.ssl.SSLHandshakeException: pre_shared_key key extension is >>> offered without a psk_key_exchange_modes extension >>> >>> ?? ?at >>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>> ?? ?at >>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>> ?? ?at >>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>> >>> ?? ?at >>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) >>> >>> ?? ?at >>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) >>> >>> ?? ?at >>> java.base/sun.security.ssl.PskKeyExchangeModesExtension$PskKeyExchangeModesOnTradeAbsence.absent(PskKeyExchangeModesExtension.java:327) >>> >>> ?? ?at >>> java.base/sun.security.ssl.SSLExtension.absentOnTrade(SSLExtension.java:572) >>> >>> ?? ?at >>> java.base/sun.security.ssl.SSLExtensions.consumeOnTrade(SSLExtensions.java:180) >>> >>> ?? ?at >>> java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:522) >>> >>> ?? ?at >>> java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) >>> ?? ?at >>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1189) >>> >>> ?? ?at >>> java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1125) >>> >>> ?? ?at >>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:831) >>> >>> ?? ?at >>> java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:792) >>> >>> ?? ?at >>> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >>> ?? ?at >>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) >>> >>> ?? ?at >>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1065) >>> >>> ?? ?at >>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1052) >>> >>> ?? ?at java.base/java.security.AccessController.doPrivileged(Native >>> Method) >>> ?? ?at >>> java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:999) >>> >>> >> From bradford.wetmore at oracle.com Thu Sep 13 17:37:45 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 13 Sep 2018 10:37:45 -0700 Subject: Code Review Request, JDK-8209916 : NPE in SupportedGroupsExtension In-Reply-To: References: <5eda7e87-8872-c336-c3bc-4f8d65541567@oracle.com> Message-ID: <03465d13-87f2-26d4-e979-32452171f846@oracle.com> Looks ok to me too. Brad On 9/11/2018 8:43 PM, Jamil Nimeh wrote: > Looks good to me. > > Thanks, > --Jamil > > On 9/11/2018 7:22 PM, Xuelei Fan wrote: >> Hi Jamil, >> >> Would you please review the fix for the NPE issue: >> ?? http://cr.openjdk.java.net/~xuelei/8209916/webrev.00/ >> >> The issue may happen if the client supports a SunJSSE provider known >> but not supported named group. >> >> Thanks, >> Xuelei > From norman.maurer at googlemail.com Thu Sep 13 19:07:35 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Thu, 13 Sep 2018 21:07:35 +0200 Subject: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth Message-ID: 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)) 0000 - 16 03 03 01 60 ....` read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160)) 0000 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 ...\..".... at 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..o....K...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)) 0000 - 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|J....n....] 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..o....K.. 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 MT....B5S[...... 00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65 .(.m...8.wrs%&.e 00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96 X........P...... 0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9 .;<..AX...:(..a. 0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5 .h...f.[..... .. 0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb .RD...c=........ 0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6 .*O[J.wx.u. .... 0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee ...VV._.e.~n=.f. 0150 - 10 4c f7 6d 9b 73 86 14-7a 81 f8 b1 27 af 08 ee .L.m.s..z...'... 0160 - ce 26 90 34 73 3d b7 45-8d 85 29 a8 65 19 e7 02 .&.4s=.E..).e... 0170 - e5 55 4a 27 f1 b1 6a a4-11 cc 6c af 78 6d 22 5c .UJ'..j...l.xm"\ 0180 - 33 73 e3 ad 7f 8d 1b d3-75 95 66 64 2d 0e f1 3e 3s......u.fd-..> 0190 - c2 30 df a1 7e ce a3 50-c3 4e 68 f6 36 b3 4e 45 .0..~..P.Nh.6.NE 01a0 - 9c ac e9 f2 0d 7c e3 73-6a 40 ab 6e 6e f9 d8 20 .....|.sj at .nn.. 01b0 - 9c f3 04 32 cd 1d df 18-e5 4d e3 e8 b1 38 59 f8 ...2.....M...8Y. 01c0 - 28 67 2e ca af a2 8b 88-ce ca 48 a6 07 2b a6 9a (g........H..+.. 01d0 - 0e 88 5b d7 0b d9 31 77-97 8d 6c 2b f5 60 24 61 ..[...1w..l+.`$a 01e0 - a8 5c 47 5d 7c 66 f0 9b-1f e4 76 93 38 f6 78 3e .\G]|f....v.8.x> 01f0 - 69 29 72 f9 d9 4b cb 05-03 e4 f2 d6 24 e1 91 ee i)r..K......$... 0200 - 85 37 d7 7b c3 5c 35 90-08 cd b1 cc 76 11 fc 00 .7.{.\5.....v... 0210 - 12 7e 89 7b 70 e6 ca fe-0b 26 b6 bb ac fe 4b 9f .~.{p....&....K. 0220 - ec cf 41 69 42 3a 3e 41-f9 b0 c0 93 5b 70 1f c7 ..AiB:>A....[p.. 0230 - 11 00 3d ec 66 5a 1a ca-31 89 22 27 02 dd a0 cb ..=.fZ..1."'.... 0240 - 39 14 25 ee 30 44 e8 62-97 bf 8e 16 63 40 c4 11 9.%.0D.b....c at .. 0250 - a6 d9 32 b1 3c 86 35 bb-9f f1 4d 71 9f a5 4f 78 ..2.<.5...Mq..Ox 0260 - 0a e8 96 dd 4d 10 c3 48-f2 db 67 57 2d cd dc 23 ....M..H..gW-..# 0270 - 3a 8d 6a 61 47 20 ff c8-33 cd e9 f7 47 4c 68 4f :.jaG ..3...GLhO 0280 - 19 2f 8b e3 b1 90 ac 66-a7 cf 5c e6 d2 05 21 25 ./.....f..\...!% 0290 - d2 d8 f0 43 8c 55 01 ef-d6 8f c0 27 87 0d 21 d5 ...C.U.....'..!. 02a0 - 2b 2b 6f db e8 85 ea cd-6e 9c 5d 56 d5 31 c1 f2 ++o.....n.]V.1.. 02b0 - 97 2f 5a 83 7a 2b 71 03-65 e0 b6 4a 56 37 de e1 ./Z.z+q.e..JV7.. 02c0 - 80 3a c4 cc 5a ac 3b 9a-7a bf f7 6b fe a8 69 e9 .:..Z.;.z..k..i. 02d0 - 58 09 59 bd 46 bd d2 a3-bc ad 1c 10 53 c8 29 7b X.Y.F.......S.){ 02e0 - be 63 00 d6 e5 a8 d6 ab-b2 bc 8b e1 2c 0e 24 2a .c..........,.$* 02f0 - c2 31 2d d8 6e 1f 19 93-d7 54 e1 1e 28 ce 72 83 .1-.n....T..(.r. 0300 - ff 05 18 f2 fc e9 0c b3-0c 1b d5 96 c2 d8 fc 76 ...............v 0310 - 37 a9 5a ef 8e e9 b6 71-21 f3 bd c1 85 23 85 22 7.Z....q!....#." 0320 - 3d c4 1c c9 31 8b 7e 00-8f 8e b4 9f 05 d4 80 6b =...1.~........k 0330 - 98 4c a8 82 68 ff 1a a5-28 e2 9b 03 a1 a7 b1 00 .L..h...(....... 0340 - 02 2b 2d e2 e1 87 8c e8-0a fb 0b 79 54 ca 3d d5 .+-........yT.=. 0350 - 6a dd b7 b7 87 42 2b 47-49 da e9 0a 82 0a c9 8f j....B+GI....... 0360 - 57 f7 1e 03 ca 8d 16 bc-21 3a 6a ee b9 b8 fa f0 W.......!:j..... 0370 - d9 18 35 9f 35 ac d8 6e-9a 8a 0d 56 10 1e 1f 5a ..5.5..n...V...Z 0380 - ba ec e4 fe 1a 92 b4 31-35 43 1d 99 b9 12 fa ff .......15C...... 0390 - 99 2b 88 e0 58 ec 9c dc-8f 67 ef 2a c2 e2 64 5d .+..X....g.*..d] 03a0 - 66 76 1c d0 aa 00 30 59-b1 f5 b1 55 9f ad 60 e9 fv....0Y...U..`. 03b0 - 3d 03 1e d0 8b 4d bf 74-ac bc bb 1c 83 14 c5 e0 =....M.t........ 03c0 - f4 fc 70 9e f4 22 a0 78-04 fe c8 b1 17 65 f6 94 ..p..".x.....e.. 03d0 - 47 82 50 4a b6 32 74 ae-5b 38 5a 2e d9 b0 6a 45 G.PJ.2t.[8Z...jE 03e0 - 74 e8 f0 22 fe d3 b0 11-c3 fd 72 4f da 77 7a ba t.."......rO.wz. 03f0 - 26 3e 61 0c 63 21 17 a6-b2 13 6e 71 5c f2 0d ad &>a.c!....nq\... 0400 - f2 d1 19 71 51 9e a4 1b-b0 30 24 e0 71 7d 87 80 ...qQ....0$.q}.. 0410 - a9 5a e9 bc db e4 4f 50-4d a1 bc bc 2c 4b 66 98 .Z....OPM...,Kf. 0420 - d4 e4 b0 76 0f d2 db a5-a5 39 9e f2 5b ea 34 c1 ...v.....9..[.4. 0430 - 62 ab 47 51 3b 37 17 45-54 31 18 f3 f1 ca 17 03 b.GQ;7.ET1...... 0440 - 03 01 19 dd 50 50 f5 0c-f2 c9 3c b4 8f 63 cc 4a ....PP....<..c.J 0450 - a7 50 c9 91 9b 79 9a 2a-5c 47 d3 77 f6 56 69 90 .P...y.*\G.w.Vi. 0460 - 98 cd ff bd c1 2a 49 fc-0d d4 7e cc 7e 44 af c4 .....*I...~.~D.. 0470 - 61 47 e0 c1 76 b1 8c 2e-df 7e d0 82 e1 89 1f 04 aG..v....~...... 0480 - ae 64 bd 71 4d ae 1c 3c-e3 d3 39 5d 61 2a ea 70 .d.qM..<..9]a*.p 0490 - 8c 31 6d a0 b1 72 a8 7a-5c 9c 11 08 b8 4d a5 c4 .1m..r.z\....M.. 04a0 - ad 1b 38 4a 6a 02 28 d4-d1 0f c8 9f 0b b3 02 18 ..8Jj.(......... 04b0 - 82 2b bd 46 82 04 64 f0-41 b2 da f5 cd 9c f7 f3 .+.F..d.A....... 04c0 - 73 30 58 ca 12 ec ea 90-85 1c 75 09 0a 70 b8 80 s0X.......u..p.. 04d0 - 3d 02 17 3e 9b 83 04 b5-dd 9e e6 18 17 65 83 a5 =..>.........e.. 04e0 - 59 7d 4b 98 da bd 8b aa-d6 aa c5 1c 7d 87 56 e3 Y}K.........}.V. 04f0 - 74 d8 e9 7b eb b3 3d f7-7c 3c 0a e9 a8 2e 04 0d t..{..=.|<...... 0500 - 6a e7 83 e0 ec 99 43 6a-8b 1c 73 59 7a c8 cd 6e j.....Cj..sYz..n 0510 - 4a 14 73 ff 9a fb 71 94-d5 50 a9 d9 e0 dd 02 4c J.s...q..P.....L 0520 - 2b 67 9e da 9e fa 2d 67-49 df 13 10 ed 35 3e 73 +g....-gI....5>s 0530 - 07 20 17 fb 0b ef f6 d0-b7 68 1c 65 21 a6 e3 3b . .......h.e!..; 0540 - bf 7b 84 cd 9e f5 76 2a-0d 4f b8 c3 c8 15 08 e9 .{....v*.O...... 0550 - 0f 3c 50 49 12 97 a8 d7-f1 a3 16 da 17 03 03 00 . 5 (0x5)) 0000 - 14 03 03 00 01 ..... read from 0x7fe400f050c0 [0x7fe40300f608] (1 bytes => 1 (0x1)) 0000 - 01 . read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) 0000 - 17 03 03 00 3d ....= read from 0x7fe400f050c0 [0x7fe40300f608] (61 bytes => 61 (0x3D)) 0000 - 38 e7 bb 2c 5b af b6 5f-37 d8 3e 7e bb f4 04 f5 8..,[.._7.>~.... 0010 - e1 28 b5 e5 07 5a ec ce-da 2f f3 b6 45 61 cf ef .(...Z.../..Ea.. 0020 - 90 fb 57 b8 f3 20 45 27-60 d4 26 51 38 77 e4 bc ..W.. E'`.&Q8w.. 0030 - b7 64 d4 8b 73 25 41 9e-fe d3 9d 5f 53 .d..s%A...._S SSL_accept:TLSv1.3 early data write to 0x7fe400f050c0 [0x7fe403018a00] (24 bytes => 24 (0x18)) 0000 - 17 03 03 00 13 25 85 60-eb 7d c1 a8 15 49 d5 63 .....%.`.}...I.c 0010 - 18 7f c6 ac ed 7f df 77- .......w SSL3 alert write:fatal:unknown SSL_accept:error in error ERROR 140736092021632:error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate:ssl/statem/statem_srvr.c:3654: shutting down SSL CONNECTION CLOSED When using openssl s_client all works as expected tho (thats also true if I use my native implementation on the client and server side that uses openssl): ./bin/openssl s_client -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 -state -tls1_3 -connect localhost:8443 The interesting thing is if I use ?-verify 1? and not ?-Verify 1? with openssl which tells it I want to request a certificate but will also process if none is provided I receive the certificate at some point as seen here: SSL_accept:before SSL initialization read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) 0000 - 16 03 03 01 60 ....` read from 0x7fdc58809fb0 [0x7fdc5901da08] (352 bytes => 352 (0x160)) 0000 - 01 00 01 5c 03 03 61 c0-b3 ed 88 65 e6 cf 11 3f ...\..a....e...? 0010 - c0 e0 f8 df a6 63 32 c2-ab 3d 61 6f 41 ed b1 4b .....c2..=aoA..K 0020 - 53 0e 83 e5 a1 b8 20 c7-1b 8c b8 e6 b5 da 4e 4e S..... .......NN 0030 - 3f 3c 61 7a ad 58 23 94-a7 32 79 2f db 9f 21 c0 ? 1430 (0x596)) 0000 - 16 03 03 00 9b 02 00 00-97 03 03 8b c8 62 48 6c .............bHl 0010 - f5 7c 73 d9 17 f8 63 a2-11 27 40 93 09 26 53 06 .|s...c..'@..&S. 0020 - b3 62 df 46 26 b6 dc 59-29 b5 58 20 c7 1b 8c b8 .b.F&..Y).X .... 0030 - e6 b5 da 4e 4e 3f 3c 61-7a ad 58 23 94 a7 32 79 ...NN?'.a.. 0200 - 47 c7 79 e4 ee 9d ba c0-ea 62 f1 0d 8e 4a 91 30 G.y......b...J.0 0210 - bc 4f 5a 98 26 30 66 ec-c4 63 8f 28 d5 1c 61 23 .OZ.&0f..c.(..a# 0220 - ea e9 90 4e 36 d9 fa 31-7b 14 27 22 0a ae 9f 64 ...N6..1{.'"...d 0230 - 40 3d e5 a0 5c 9d 3c 04-71 09 b0 7a 6b 51 a0 9c @=..\.<.q..zkQ.. 0240 - c0 61 32 ce 15 62 8e 29-b1 59 91 c0 17 2c b3 c5 .a2..b.).Y...,.. 0250 - f9 ed 07 65 3d 11 de 98-de 62 36 50 74 37 af 2d ...e=....b6Pt7.- 0260 - 7d 86 55 c4 3e a2 83 ab-47 8d f2 b2 8d 1d 75 83 }.U.>...G.....u. 0270 - b5 e4 41 87 a7 a3 85 b0-5e 4e 2e 9c 8c b0 1b 83 ..A.....^N...... 0280 - 7b 54 79 c9 60 ea 7d ed-06 fa dd 24 40 f1 53 9e {Ty.`.}....$@.S. 0290 - 43 79 25 53 9c c7 6e 95-ab 9f 96 59 cd b9 7b a8 Cy%S..n....Y..{. 02a0 - a0 23 13 69 db a9 c9 e7-1a 8e e1 9b 54 94 1c 44 .#.i........T..D 02b0 - 50 08 8b dd eb 4e 2b bb-d7 c9 c2 33 8c a1 b3 65 P....N+....3...e 02c0 - 06 e6 9d ac 11 16 21 58-40 8d 59 e6 67 e5 31 02 ......!X at .Y.g.1. 02d0 - 15 8d 29 80 20 66 ba c3-56 93 95 5c 65 4b 41 00 ..). f..V..\eKA. 02e0 - c5 71 12 12 f5 20 4f 59-be 77 06 10 6e 48 85 5c .q... OY.w..nH.\ 02f0 - ff a2 c4 ae fb 4d 95 f5-cc f6 61 20 33 b7 92 1d .....M....a 3... 0300 - ac a8 f1 b2 b0 88 c6 7b-8b 00 53 30 6d 4a d1 42 .......{..S0mJ.B 0310 - b3 3e 85 f5 84 e1 c6 ab-10 9d 61 03 46 ff 2d 81 .>........a.F.-. 0320 - 15 4f 84 d1 4c ee f4 a6-a0 ec 50 60 a0 d1 ff df .O..L.....P`.... 0330 - 8a 97 f6 7d fb 8f fb 60-18 d4 f1 1f 92 4d d8 69 ...}...`.....M.i 0340 - b1 92 97 44 0f 3c 8a aa-47 07 48 d4 07 2d 3e f2 ...D.<..G.H..->. 0350 - c4 a7 16 35 a7 17 71 ef-98 84 24 67 12 58 30 3b ...5..q...$g.X0; 0360 - 1d 41 8d e5 12 52 95 64-e5 88 35 99 d7 c3 58 40 .A...R.d..5...X@ 0370 - f9 55 9b 9f e5 33 15 70-41 d7 45 ba a4 fc 75 ea .U...3.pA.E...u. 0380 - a4 ae f0 68 ea 64 d8 f5-06 68 a9 75 22 4d 43 cc ...h.d...h.u"MC. 0390 - ff 50 cc ac 6e fd 43 dd-eb e4 c8 dd 4b 6c 12 bb .P..n.C.....Kl.. 03a0 - f1 d4 5e 11 4a 86 90 0b-f8 3a 2e 23 db 61 5a 1f ..^.J....:.#.aZ. 03b0 - 7e 11 00 92 21 68 1f b5-ab f2 f8 38 5e 62 ea f8 ~...!h.....8^b.. 03c0 - da ef c2 6e a0 b8 20 e4-69 49 b3 1f 15 84 0b 9b ...n.. .iI...... 03d0 - ce b0 6f 36 32 7f 7e bf-e8 d7 18 7a 58 60 f4 04 ..o62.~....zX`.. 03e0 - cc 36 bf 06 cd ec e5 9b-19 03 96 09 fb af 8f c3 .6.............. 03f0 - 98 b4 02 aa e8 55 81 aa-c4 fe 06 81 30 a0 c7 b2 .....U......0... 0400 - f8 e2 30 00 d7 a0 54 7f-5f d7 ef a6 f8 41 58 34 ..0...T._....AX4 0410 - f5 f0 18 69 8d e6 7a 23-78 90 8f b1 05 c5 b5 7f ...i..z#x....... 0420 - e0 f2 c7 fa c8 36 5b 53-7e cf e6 75 d3 54 b4 69 .....6[S~..u.T.i 0430 - 68 43 0d 6a d2 83 cc 13-6d ca bf 83 3c 90 17 03 hC.j....m...<... 0440 - 03 01 19 96 dc 49 26 ce-1d 8e 86 3d bd cb 00 5e .....I&....=...^ 0450 - ee f6 e7 1d 16 7a ca ef-fa 6d 16 40 b6 99 d0 c1 .....z...m. at .... 0460 - df 0b 5f 51 60 a8 24 e0-61 82 13 40 da 88 38 3a .._Q`.$.a.. at ..8: 0470 - 26 1d 80 51 c4 b1 95 35-95 3c 91 35 28 17 49 d8 &..Q...5.<.5(.I. 0480 - c3 45 be 32 98 3e 02 07-3b 01 20 2b 51 e1 1a 94 .E.2.>..;. +Q... 0490 - b9 be 96 aa 7a 13 09 ff-d5 a9 63 d4 6f 49 cb b5 ....z.....c.oI.. 04a0 - 23 ab 7f 8c e2 63 f0 5c-5c 27 1e 04 a8 71 0c c0 #....c.\\'...q.. 04b0 - 89 cd ed 18 8d 5b 75 ac-af f3 68 6d cc ba 20 38 .....[u...hm.. 8 04c0 - b5 7c 09 47 29 28 e2 26-57 57 1f f0 f3 18 fd 6f .|.G)(.&WW.....o 04d0 - 27 42 a4 e3 de bb e5 d6-09 7d 25 b1 98 97 ad 33 'B.......}%....3 04e0 - 68 35 92 07 80 23 f1 66-20 5d 74 f3 02 c5 51 ff h5...#.f ]t...Q. 04f0 - 07 a9 e9 0e 3e 74 da 2e-8f 3b 16 be e6 94 1b 66 ....>t...;.....f 0500 - bb b2 a2 1e 7c 7b ff 5e-a4 36 2a ba 0b cd 7f e9 ....|{.^.6*..... 0510 - 86 bb 5e 30 f5 57 92 52-82 b6 2e da 71 b7 22 c2 ..^0.W.R....q.". 0520 - 90 c4 69 46 07 df 6c 3f-05 8b 19 3e ce b9 75 0d ..iF..l?...>..u. 0530 - 4b 97 37 ae 94 e2 d6 3c-91 e6 82 c7 a1 78 79 2c K.7....<.....xy, 0540 - 9a a3 d5 45 94 ad e2 c8-ab fd 81 ec 62 87 f7 75 ...E........b..u 0550 - e3 70 79 8e 82 3b c5 45-0d d0 33 5f 17 03 03 00 .py..;.E..3_.... 0560 - 35 da e0 74 2a 06 41 5a-64 1e 54 94 29 73 43 3f 5..t*.AZd.T.)sC? 0570 - e5 24 a8 ba b2 7e 6b 26-82 fc d9 f6 dd 19 05 4a .$...~k&.......J 0580 - 2c 1a f3 bb 16 1d 38 95-a6 d3 a8 58 f6 a3 41 c7 ,.....8....X..A. 0590 - 92 44 35 24 25 0e .D5$%. SSL_accept:SSLv3/TLS write finished SSL_accept:TLSv1.3 early data read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) 0000 - 14 03 03 00 01 ..... read from 0x7fdc58809fb0 [0x7fdc5901da08] (1 bytes => 1 (0x1)) 0000 - 01 . read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) 0000 - 17 03 03 00 3d ....= read from 0x7fdc58809fb0 [0x7fdc5901da08] (61 bytes => 61 (0x3D)) 0000 - ad dd 3e d9 ee ab 56 65-50 1c 72 2a d8 62 7f 90 ..>...VeP.r*.b.. 0010 - 13 71 7d 37 39 40 fb 89-8f 05 4b 39 44 9d 4d 67 .q}79 at ....K9D.Mg 0020 - e3 41 29 b6 3e e8 fe 04-1b 8e eb 7a 4c e2 14 a0 .A).>......zL... 0030 - b1 c2 47 3f 94 35 ed ab-8a d1 75 3b ba ..G?.5....u;. SSL_accept:TLSv1.3 early data SSL_accept:SSLv3/TLS read client certificate SSL_accept:SSLv3/TLS read finished write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) 0000 - 17 03 03 00 da 52 1f 48-00 f4 31 13 90 7f 9c c2 .....R.H..1..... 0010 - fc 70 1a fc f7 4a 48 e7-31 ad 37 ab b5 2b 4e 5c .p...JH.1.7..+N\ 0020 - e8 d8 6d e9 af 6c 4f c1-9e 7b ea ff ef b3 eb 74 ..m..lO..{.....t 0030 - 27 67 10 21 66 5b 32 13-31 bc 99 d5 1c 6c 79 55 'g.!f[2.1....lyU 0040 - f3 3e f6 4b 07 4d a9 78-3d 12 8a f5 38 ef d9 f4 .>.K.M.x=...8... 0050 - 48 e0 2c 35 94 06 4f eb-09 e6 70 fb 59 95 7a c8 H.,5..O...p.Y.z. 0060 - 24 dd 24 e2 f9 63 b9 3c-f2 66 86 c4 73 44 53 fd $.$..c.<.f..sDS. 0070 - ca 67 8f 01 d6 db 70 f9-60 bc 50 11 51 72 dc 63 .g....p.`.P.Qr.c 0080 - 12 ca 4f 23 e2 c5 d1 1d-e5 b0 d4 ec 89 ca 28 be ..O#..........(. 0090 - 9c 30 83 40 02 a4 62 a8-5c b3 20 1a ab 39 b7 7b .0. at ..b.\. ..9.{ 00a0 - 89 13 39 87 73 be a8 f8-60 13 31 0a 48 5c 79 b9 ..9.s...`.1.H\y. 00b0 - cc 4a 51 e3 0d d2 b4 93-c0 1f 3a 22 b3 fa 24 a0 .JQ.......:"..$. 00c0 - 7c f6 76 79 d0 2d 5b 1a-ff a6 e9 e1 40 d3 b1 8c |.vy.-[..... at ... 00d0 - 0a fa fa de f3 8e d6 ad-9a 22 6b 67 0b 88 18 ........."kg... SSL_accept:SSLv3/TLS write session ticket write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) 0000 - 17 03 03 00 da 46 aa ea-6a 37 b1 35 e8 41 c8 b3 .....F..j7.5.A.. 0010 - 84 25 af 1c 36 a3 6d 78-a4 44 4a 83 52 ef 13 7c .%..6.mx.DJ.R..| 0020 - 8f 18 d3 4c f8 22 c8 b3-ad d0 d0 5b 47 a0 43 da ...L.".....[G.C. 0030 - d2 6e 04 8f dc c9 56 90-58 87 62 63 4c cc 31 ec .n....V.X.bcL.1. 0040 - b8 c9 18 be 41 32 e1 3c-00 41 2a f1 4d 5c 2d 44 ....A2.<.A*.M\-D 0050 - 8c aa e1 f0 ed 38 ee 44-64 e5 fd ea 58 3b 84 5d .....8.Dd...X;.] 0060 - 83 39 21 2e fe 79 4d 76-10 65 87 0f 3c ac df 28 .9!..yMv.e..<..( 0070 - 49 f8 60 eb be 49 e4 0a-0b 6a 03 2b 9d cf 9b a5 I.`..I...j.+.... 0080 - 03 56 58 32 c2 b2 59 f9-0a 0d f0 ae af ff 20 19 .VX2..Y....... . 0090 - e5 6e e4 86 2f 5e 3f 7d-47 d5 73 ae 89 48 a7 66 .n../^?}G.s..H.f 00a0 - fb 2d 83 60 e8 8b ab 27-12 db 24 78 54 eb 14 2d .-.`...'..$xT..- 00b0 - b7 c6 17 2d 3c 91 57 ac-6e 35 b8 c3 fa c2 42 48 ...-<.W.n5....BH 00c0 - 2a cb aa 98 32 89 8a ce-0c f7 cd 5e fb bf 6d 33 *...2......^..m3 00d0 - 08 50 cf 1e 06 bb a1 98-be a4 a9 51 9a b0 34 .P.........Q..4 SSL_accept:SSLv3/TLS write session ticket write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) 0000 - 17 03 03 00 12 c5 9b 73-cc 91 7e 48 cb 25 31 a0 .......s..~H.%1. 0010 - 67 41 db bb 0f 62 d8 gA...b. write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) 0000 - 17 03 03 00 12 0f dd 3f-c1 7c e6 b0 cc ea f0 13 .......?.|...... 0010 - 00 d8 01 de ef 7c bb .....|. read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) 0000 - 17 03 03 00 1e ..... read from 0x7fdc58809fb0 [0x7fdc5901da08] (30 bytes => 30 (0x1E)) 0000 - d6 88 44 82 cb 23 16 ba-c9 a4 fb 55 51 08 90 c1 ..D..#.....UQ... 0010 - bf bd a1 7f 0e 37 b0 b4-b5 df f1 07 6c 07 .....7......l. I am a clientwrite to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) 0000 - 17 03 03 00 12 c0 70 5d-14 e7 69 57 0a d8 64 16 ......p]..iW..d. 0010 - 0c 90 06 0f c3 4d 1d .....M. read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) 0000 - 17 03 03 00 13 ..... read from 0x7fdc58809fb0 [0x7fdc5901da08] (19 bytes => 19 (0x13)) 0000 - 60 28 5b ff bb 0d 9f 96-9a 2d cb fd 60 eb 96 62 `([......-..`..b 0010 - 53 e6 25 S.% SSL3 alert read:warning:close notify DONE shutting down SSL CONNECTION CLOSED I am using the following JDK version on MacOS: ssl git:(cert_cb_openssl_1_1_1) ? /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java -version java version "11" 2018-09-25 Java(TM) SE Runtime Environment 18.9 (build 11+28) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) For this to work you will need to have openssl 1.1.1 installed. Any help would be welcome, Norman [1] https://github.com/netty/netty-tcnative From sean.mullan at oracle.com Thu Sep 13 20:02:19 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 13 Sep 2018 16:02:19 -0400 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable Message-ID: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> 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. 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. There are essentially two main parts to this change: 1. Deprecation of System.securityManager() Going forward, we want to discourage applications from calling System.setSecurityManager(). Instead they should enable a SecurityManager using the java.security.manager system property on the command-line. 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. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 (I will likely also send this to core-libs for additional review later) --Sean From ecki at zusammenkunft.net Thu Sep 13 23:19:55 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 13 Sep 2018 23:19:55 +0000 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: Hallo Sean, The change looks fine to me, but if you have to roll another version maybe you could add a comment on this line to explain its purpose. Since this line is changed in the patch it would be a good time: System.java:350 sm.checkPackageAccess("java.lang"); Is that some kind of warm-up? (It cant be a sanity or security check as its result is ignored. I am curious, did you verify that the compiler will actually optimize the getSecurityManager null check in case allow=never? Is that happening in C1? Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: -995614032m Auftrag von Gesendet: Donnerstag, September 13, 2018 10:14 PM An: security Dev OpenJDK Betreff: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable 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. 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. There are essentially two main parts to this change: 1. Deprecation of System.securityManager() Going forward, we want to discourage applications from calling System.setSecurityManager(). Instead they should enable a SecurityManager using the java.security.manager system property on the command-line. 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. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 (I will likely also send this to core-libs for additional review later) --Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Thu Sep 13 23:50:46 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 13 Sep 2018 16:50:46 -0700 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: <688a7f42-d536-ba0c-eb53-d621bcaaa512@oracle.com> Hi Sean, Looks sensible to me. On 9/13/18 1:02 PM, Sean Mullan wrote: > 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. I guess the default value is true? The behavior makes sense, though the name I think is misleading. It seems not to disallow a security manager, but to disallow the capability to *set* the security manager. Maybe "jdk.allowSetSecurityManager" ? s'marks From stuart.marks at oracle.com Thu Sep 13 23:52:16 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 13 Sep 2018 16:52:16 -0700 Subject: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped In-Reply-To: References: Message-ID: I'd guess that security-dev would have reviewers for the change to default.policy. Cc'd. 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". > > From mandy.chung at oracle.com Fri Sep 14 02:20:17 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 13 Sep 2018 19:20:17 -0700 Subject: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped In-Reply-To: References: Message-ID: <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com> 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". > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Fri Sep 14 02:41:53 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 13 Sep 2018 19:41:53 -0700 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: <75a35271-2acb-4d07-5828-9334f02cb072@oracle.com> On 9/13/18 1:02 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. > > : > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 > JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 This is a welcoming change as many applications run without security manager and they will benefit the performance improvement.?? This patch makes the private System::security field @Stable hich is the first installment of perf optimization.?? I hope to see further optimization can be done for example speed up of doPrivileged block in the no-security manager case. This patch looks good.? It may be good to add one test case to launch with -Djava.security.manager and -Djdk.allowSecurityManager=false to show that no security manager is installed; essential -Djava.security.manager is ignored.? Maybe @implNote should mention such case where -Djava.security.manager is ignored if -Djdk.allowSecurityManager=false. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Sep 14 02:40:43 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 14 Sep 2018 10:40:43 +0800 Subject: RFR 8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux Message-ID: <5349E25A-27B9-4D91-A47E-AA097DA662D8@oracle.com> The test runs very slow on Linux and turns out reading from the embedded HTTP server is the bottleneck. Here is the fix: diff --git a/test/jdk/javax/xml/crypto/dsig/GenerationTests.java b/test/jdk/javax/xml/crypto/dsig/GenerationTests.java --- a/test/jdk/javax/xml/crypto/dsig/GenerationTests.java +++ b/test/jdk/javax/xml/crypto/dsig/GenerationTests.java @@ -24,7 +24,7 @@ /** * @test * @bug 4635230 6283345 6303830 6824440 6867348 7094155 8038184 8038349 8046949 - * 8046724 8079693 8177334 8205507 + * 8046724 8079693 8177334 8205507 8210736 * @summary Basic unit tests for generating XML Signatures with JSR 105 * @modules java.base/sun.security.util * java.base/sun.security.x509 @@ -32,7 +32,7 @@ * jdk.httpserver/com.sun.net.httpserver * @compile -XDignore.symbol.file KeySelectors.java SignatureValidator.java * X509KeySelector.java GenerationTests.java - * @run main/othervm/timeout=300 GenerationTests + * @run main/othervm/timeout=300 -Dsun.net.httpserver.nodelay=true GenerationTests * @author Sean Mullan */ I've run the test hundreds of times. With the system property set, the longest duration is 1m 58s; without it, the shortest is 15m 45s. That's a huge difference. I don't see significant change on other platforms. Thanks Max From mandy.chung at oracle.com Fri Sep 14 02:45:40 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 13 Sep 2018 19:45:40 -0700 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <688a7f42-d536-ba0c-eb53-d621bcaaa512@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <688a7f42-d536-ba0c-eb53-d621bcaaa512@oracle.com> Message-ID: <5947ec33-3195-e57b-ff7a-4cfe3c74e9c3@oracle.com> On 9/13/18 4:50 PM, Stuart Marks wrote: > Hi Sean, > > Looks sensible to me. > > On 9/13/18 1:02 PM, Sean Mullan wrote: >> 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. > > I guess the default value is true? > > The behavior makes sense, though the name I think is misleading. It > seems not to disallow a security manager, but to disallow the > capability to *set* the security manager. Maybe > "jdk.allowSetSecurityManager" ? > When -Djdk.allowSecurityManager is set at startup, no security manager is allowed.? Most cases a security manager is started via -Djava.security.manager on the command-line. This name also prepares for the future to potentially flip the default (no security manager by default) and allow a security manager at runtime. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Sep 14 03:01:31 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 14 Sep 2018 11:01:31 +0800 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: <1CF6D841-617D-4256-8867-B76393C86330@oracle.com> > On Sep 14, 2018, at 4:02 AM, Sean Mullan wrote: > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ public static SecurityManager getSecurityManager() { + if (allowSecurityManager()) { return security; + } else { + return null; + } } Is this change really necessary? You have to call a method here. > CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 Still having @Deprecated(since="11"). Thanks Max From Alan.Bateman at oracle.com Fri Sep 14 10:12:58 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Sep 2018 11:12:58 +0100 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: <495b9113-6800-aa4f-26d9-24a1f8463ddf@oracle.com> On 14/09/2018 00:19, Bernd Eckenfels wrote: > : > > I am curious, did you verify that the compiler will actually optimize > the getSecurityManager null check in case allow=never? Yes, and the reason the allowSecurityManager field is an int rather than a boolean is so that it get sets to a value other than its default. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Sep 14 10:20:55 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Sep 2018 11:20:55 +0100 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: <2a39b0b3-a73e-8d56-33ed-a6d1ec393d96@oracle.com> On 13/09/2018 21:02, Sean Mullan wrote: > : > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 > JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 > This is inline with the discussion we had on this mailing list last year about deprecating the ability to enable a SM in a running VM and then profiting in several areas of the JDK. The changes look good and I'm really happy to see this moving. -Alan From daniel.fuchs at oracle.com Fri Sep 14 11:31:52 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Sep 2018 12:31:52 +0100 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <5947ec33-3195-e57b-ff7a-4cfe3c74e9c3@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <688a7f42-d536-ba0c-eb53-d621bcaaa512@oracle.com> <5947ec33-3195-e57b-ff7a-4cfe3c74e9c3@oracle.com> Message-ID: On 14/09/2018 03:45, mandy chung wrote: >> The behavior makes sense, though the name I think is misleading. It >> seems not to disallow a security manager, but to disallow the >> capability to *set* the security manager. Maybe >> "jdk.allowSetSecurityManager" ? >> > > When -Djdk.allowSecurityManager is set at startup, no security manager > is allowed.? Most cases a security manager is started via > -Djava.security.manager on the command-line. Maybe it would be less confusing if the property was named -Djdk.disableSecurityManager, because AFAICT, it's what it does? best regards, -- daniel From daniel.fuchs at oracle.com Fri Sep 14 11:52:24 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Sep 2018 12:52:24 +0100 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <688a7f42-d536-ba0c-eb53-d621bcaaa512@oracle.com> <5947ec33-3195-e57b-ff7a-4cfe3c74e9c3@oracle.com> Message-ID: <59b96dce-83b0-359c-1dcf-8b9cee32387c@oracle.com> On 14/09/2018 12:31, Daniel Fuchs wrote: > Maybe it would be less confusing if the property was named > -Djdk.disableSecurityManager, because AFAICT, it's what it does? Forget I said that ;-) The name "jdk.allowSecurityManager" is actually fine. I was also confused at first because I believed the property, if set to false, would just prevent someone to call System::setSecurityManager at runtime, whereas it also prevents to set a security manager on the command line. Maybe emphasizing this would remove any confusion. I wonder if the VM should fail to start if both -Djdk.allowSecurityManager=false and -Djava.security.manager are supplied? best regards and apologies for the noise of my previous mail... -- daniel From Alan.Bateman at oracle.com Fri Sep 14 12:14:56 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Sep 2018 13:14:56 +0100 Subject: RFR 8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux In-Reply-To: <5349E25A-27B9-4D91-A47E-AA097DA662D8@oracle.com> References: <5349E25A-27B9-4D91-A47E-AA097DA662D8@oracle.com> Message-ID: <682fccd2-dc18-0c57-1726-c3972e4abbc9@oracle.com> On 14/09/2018 03:40, Weijun Wang wrote: > The test runs very slow on Linux and turns out reading from the embedded HTTP server is the bottleneck. Here is the fix: > > > diff --git a/test/jdk/javax/xml/crypto/dsig/GenerationTests.java b/test/jdk/javax/xml/crypto/dsig/GenerationTests.java > --- a/test/jdk/javax/xml/crypto/dsig/GenerationTests.java > +++ b/test/jdk/javax/xml/crypto/dsig/GenerationTests.java > @@ -24,7 +24,7 @@ > /** > * @test > * @bug 4635230 6283345 6303830 6824440 6867348 7094155 8038184 8038349 8046949 > - * 8046724 8079693 8177334 8205507 > + * 8046724 8079693 8177334 8205507 8210736 > * @summary Basic unit tests for generating XML Signatures with JSR 105 > * @modules java.base/sun.security.util > * java.base/sun.security.x509 > @@ -32,7 +32,7 @@ > * jdk.httpserver/com.sun.net.httpserver > * @compile -XDignore.symbol.file KeySelectors.java SignatureValidator.java > * X509KeySelector.java GenerationTests.java > - * @run main/othervm/timeout=300 GenerationTests > + * @run main/othervm/timeout=300 -Dsun.net.httpserver.nodelay=true GenerationTests > * @author Sean Mullan > */ > > I've run the test hundreds of times. With the system property set, the longest duration is 1m 58s; without it, the shortest is 15m 45s. That's a huge difference. This property sets TCP_NODELAY which seems okay here (although it may be working around an issue that the HTTP server should address). In any case, the change looks okay and maybe /timeout=300 is not needed now. -Alan From david.lloyd at redhat.com Fri Sep 14 12:46:00 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 14 Sep 2018 07:46:00 -0500 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: 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? > 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. -- - DML From Alan.Bateman at oracle.com Fri Sep 14 13:22:25 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Sep 2018 14:22:25 +0100 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> 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). -Alan From david.lloyd at redhat.com Fri Sep 14 13:28:09 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 14 Sep 2018 08:28:09 -0500 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> Message-ID: On Fri, Sep 14, 2018 at 8:22 AM 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). I can say that this explanation would be more palatable by far if the security manager as a whole could be deprecated all at once. I for one would certainly be happy to remove support for it in the software that I maintain (it's a considerable amount of code and other gymnastics to be sure). However, I'm not sure that our users and customers will be so easily convinced. My understanding is that there are plenty of corporate and perhaps government security standards that dictate security manager usage. If the security manager itself is not yet to be deprecated, then I have a much harder time accepting this argument. It's not really a stepping stone in any practical sense, at least not from our perspective, unless that step is "break JBoss first, and then break everyone else later"; to be fair though I'm approximately 200% more cynical in the morning. :) -- - DML From Alan.Bateman at oracle.com Fri Sep 14 13:46:42 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Sep 2018 14:46:42 +0100 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> Message-ID: <07c7fbd4-a1a8-742d-9b6e-04879cac2888@oracle.com> On 14/09/2018 14:28, David Lloyd wrote: > : > I can say that this explanation would be more palatable by far if the > security manager as a whole could be deprecated all at once. I for > one would certainly be happy to remove support for it in the software > that I maintain (it's a considerable amount of code and other > gymnastics to be sure). However, I'm not sure that our users and > customers will be so easily convinced. My understanding is that there > are plenty of corporate and perhaps government security standards that > dictate security manager usage. > > If the security manager itself is not yet to be deprecated, then I > have a much harder time accepting this argument. It's not really a > stepping stone in any practical sense, at least not from our > perspective, unless that step is "break JBoss first, and then break > everyone else later"; to be fair though I'm approximately 200% more > cynical in the morning. :) If the proposed patch goes into jdk/jdk then it just means that code using System.setSecurityManager gets a deprecation warning at compile-time, nothing more. I agree it would be nice to able to go further and deprecate SecurityManager, also emit a warning if -Djava.security.manager is set on the command line. These seem like possible future disruptive steps in a multi-release plan. -Alan From weijun.wang at oracle.com Fri Sep 14 14:33:04 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 14 Sep 2018 22:33:04 +0800 Subject: RFR 8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux In-Reply-To: <682fccd2-dc18-0c57-1726-c3972e4abbc9@oracle.com> References: <5349E25A-27B9-4D91-A47E-AA097DA662D8@oracle.com> <682fccd2-dc18-0c57-1726-c3972e4abbc9@oracle.com> Message-ID: In my latest test that repeats 100 times, the slowest one runs for 208 seconds. This test runs tens of thousands of signing and verifying and I'd like to keep that timeout. Thanks Max > On Sep 14, 2018, at 8:14 PM, Alan Bateman wrote: > > On 14/09/2018 03:40, Weijun Wang wrote: >> The test runs very slow on Linux and turns out reading from the embedded HTTP server is the bottleneck. Here is the fix: >> >> >> diff --git a/test/jdk/javax/xml/crypto/dsig/GenerationTests.java b/test/jdk/javax/xml/crypto/dsig/GenerationTests.java >> --- a/test/jdk/javax/xml/crypto/dsig/GenerationTests.java >> +++ b/test/jdk/javax/xml/crypto/dsig/GenerationTests.java >> @@ -24,7 +24,7 @@ >> /** >> * @test >> * @bug 4635230 6283345 6303830 6824440 6867348 7094155 8038184 8038349 8046949 >> - * 8046724 8079693 8177334 8205507 >> + * 8046724 8079693 8177334 8205507 8210736 >> * @summary Basic unit tests for generating XML Signatures with JSR 105 >> * @modules java.base/sun.security.util >> * java.base/sun.security.x509 >> @@ -32,7 +32,7 @@ >> * jdk.httpserver/com.sun.net.httpserver >> * @compile -XDignore.symbol.file KeySelectors.java SignatureValidator.java >> * X509KeySelector.java GenerationTests.java >> - * @run main/othervm/timeout=300 GenerationTests >> + * @run main/othervm/timeout=300 -Dsun.net.httpserver.nodelay=true GenerationTests >> * @author Sean Mullan >> */ >> >> I've run the test hundreds of times. With the system property set, the longest duration is 1m 58s; without it, the shortest is 15m 45s. That's a huge difference. > This property sets TCP_NODELAY which seems okay here (although it may be working around an issue that the HTTP server should address). In any case, the change looks okay and maybe /timeout=300 is not needed now. > > -Alan From stuart.marks at oracle.com Fri Sep 14 16:23:12 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 14 Sep 2018 09:23:12 -0700 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <59b96dce-83b0-359c-1dcf-8b9cee32387c@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <688a7f42-d536-ba0c-eb53-d621bcaaa512@oracle.com> <5947ec33-3195-e57b-ff7a-4cfe3c74e9c3@oracle.com> <59b96dce-83b0-359c-1dcf-8b9cee32387c@oracle.com> Message-ID: <9cda4784-0566-5d4f-64b4-2f55f587525d@oracle.com> On 9/14/18 4:52 AM, Daniel Fuchs wrote: > The name "jdk.allowSecurityManager" is actually fine. > > I was also confused at first because I believed the > property, if set to false, would just prevent someone > to call System::setSecurityManager at runtime, whereas > it also prevents to set a security manager on the command > line. > > Maybe emphasizing this would remove any confusion. Yes, I was confused about this too -- I didn't realize that the jdk.allowSecurityManager property also disallowed setting the security manager via the java.security.manager property. I thought it just applied to the System.setSecurityManager() method. (Well, it turns out that setting the java.security.manager property on the command line ends up calling System.setSecurityManager(), but this is buried inside the implementation.) So yes, the effect of setting jdk.allowSecurityManager needs to be specified more explicitly. > I wonder if the VM should fail to start if both > -Djdk.allowSecurityManager=false and -Djava.security.manager > are supplied? Maybe, but I don't know that this is necessary. Again, if it's made clear enough that the java.security.manager property is IGNORED if jdk.allowSecurityManager=false, then that's OK with me. s'marks From sean.mullan at oracle.com Fri Sep 14 16:44:22 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Sep 2018 12:44:22 -0400 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <1CF6D841-617D-4256-8867-B76393C86330@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <1CF6D841-617D-4256-8867-B76393C86330@oracle.com> Message-ID: <950922c1-dbff-1928-b0e3-7118c8f03d5b@oracle.com> On 9/13/18 11:01 PM, Weijun Wang wrote: > > >> On Sep 14, 2018, at 4:02 AM, Sean Mullan wrote: >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ > > public static SecurityManager getSecurityManager() { > + if (allowSecurityManager()) { > return security; > + } else { > + return null; > + } > } > > Is this change really necessary? You have to call a method here. I'll defer to a compiler expert, but I believe this is necessary to cause the constant-folding of this method since the allowSecurityManager field has an @Stable annotation. >> CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 > > Still having @Deprecated(since="11"). Fixed. Good catch. --Sean From sean.mullan at oracle.com Fri Sep 14 16:58:39 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Sep 2018 12:58:39 -0400 Subject: RFR 8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux In-Reply-To: References: <5349E25A-27B9-4D91-A47E-AA097DA662D8@oracle.com> <682fccd2-dc18-0c57-1726-c3972e4abbc9@oracle.com> Message-ID: <522bb4d4-ab90-6c29-cd7d-cb0572c375c8@oracle.com> Just curious, but why is this not an issue on platforms other than linux? Seems like we are working around a problem that maybe should be fixed somewhere else ... --Sean On 9/14/18 10:33 AM, Weijun Wang wrote: > In my latest test that repeats 100 times, the slowest one runs for 208 seconds. This test runs tens of thousands of signing and verifying and I'd like to keep that timeout. > > Thanks > Max > >> On Sep 14, 2018, at 8:14 PM, Alan Bateman wrote: >> >> On 14/09/2018 03:40, Weijun Wang wrote: >>> The test runs very slow on Linux and turns out reading from the embedded HTTP server is the bottleneck. Here is the fix: >>> >>> >>> diff --git a/test/jdk/javax/xml/crypto/dsig/GenerationTests.java b/test/jdk/javax/xml/crypto/dsig/GenerationTests.java >>> --- a/test/jdk/javax/xml/crypto/dsig/GenerationTests.java >>> +++ b/test/jdk/javax/xml/crypto/dsig/GenerationTests.java >>> @@ -24,7 +24,7 @@ >>> /** >>> * @test >>> * @bug 4635230 6283345 6303830 6824440 6867348 7094155 8038184 8038349 8046949 >>> - * 8046724 8079693 8177334 8205507 >>> + * 8046724 8079693 8177334 8205507 8210736 >>> * @summary Basic unit tests for generating XML Signatures with JSR 105 >>> * @modules java.base/sun.security.util >>> * java.base/sun.security.x509 >>> @@ -32,7 +32,7 @@ >>> * jdk.httpserver/com.sun.net.httpserver >>> * @compile -XDignore.symbol.file KeySelectors.java SignatureValidator.java >>> * X509KeySelector.java GenerationTests.java >>> - * @run main/othervm/timeout=300 GenerationTests >>> + * @run main/othervm/timeout=300 -Dsun.net.httpserver.nodelay=true GenerationTests >>> * @author Sean Mullan >>> */ >>> >>> I've run the test hundreds of times. With the system property set, the longest duration is 1m 58s; without it, the shortest is 15m 45s. That's a huge difference. >> This property sets TCP_NODELAY which seems okay here (although it may be working around an issue that the HTTP server should address). In any case, the change looks okay and maybe /timeout=300 is not needed now. >> >> -Alan > From sean.mullan at oracle.com Fri Sep 14 17:16:10 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Sep 2018 13:16:10 -0400 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: <877eafcc-c7ad-c994-a8ba-ec38f1ca7c83@oracle.com> On 9/13/18 7:19 PM, Bernd Eckenfels wrote: > Hallo Sean, > > The change looks fine to me, but if you have to roll another version > maybe you could add a comment on this line to explain its purpose. Since > this line is changed in the patch it would be a good time: > > System.java:350 > ???sm.checkPackageAccess("java.lang"); > > Is that some kind of warm-up? (It cant be a sanity or security check as > its result is ignored. Yes. If I recall, that forces the Policy implementation to be loaded early and avoids potential class loading and/or stack recursion issues if done later on. I played around with removing this a while back and all sorts of things broke, so I'll do that again but this time add some meaningful comments as to why it is needed. > I am curious, did you verify that the compiler will actually optimize > the getSecurityManager null check in case allow=never? Is that happening > in C1? Yes, Claes did some initial testing and confirmed that the constant-folded is occurring. See the comment in JDK-8191053 for more info and some results: https://bugs.openjdk.java.net/browse/JDK-8191053?focusedCommentId=14186619&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14186619 --Sean > > Gruss > Bernd > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* -995614032m Auftrag von > *Gesendet:* Donnerstag, September 13, 2018 10:14 PM > *An:* security Dev OpenJDK > *Betreff:* RFR (12): 8191053: Provide a mechanism to make system's > security manager immutable > 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. > > 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. > > There are essentially two main parts to this change: > > 1. Deprecation of System.securityManager() > > Going forward, we want to discourage applications from calling > System.setSecurityManager(). Instead they should enable a > SecurityManager using the java.security.manager system property on the > command-line. > > 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. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 > JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 > > (I will likely also send this to core-libs for additional review later) > > --Sean From roger.riggs at oracle.com Fri Sep 14 17:17:47 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 14 Sep 2018 13:17:47 -0400 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: <6f4e1180-40e7-74e6-bfbd-56469fdde925@oracle.com> Hi Sean, Looks good. I would quibble with System.java:335-6 "Java virtual machine does not allow a security manager" I would say only "a security manager is not allowed to be set dynamically." There is no need to identify the Java virtual machine.? The VM itself has nothing to do with it. Also remove the same phrase in SecurityManager class javadoc. Regards, Roger On 9/13/18 4:02 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. > > 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. > > There are essentially two main parts to this change: > > 1. Deprecation of System.securityManager() > > Going forward, we want to discourage applications from calling > System.setSecurityManager(). Instead they should enable a > SecurityManager using the java.security.manager system property on the > command-line. > > 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. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 > JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 > > (I will likely also send this to core-libs for additional review later) > > --Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Sep 14 18:41:58 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Sep 2018 14:41:58 -0400 Subject: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped In-Reply-To: References: Message-ID: 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". >> >> From ecki at zusammenkunft.net Fri Sep 14 18:54:23 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 14 Sep 2018 18:54:23 +0000 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <9cda4784-0566-5d4f-64b4-2f55f587525d@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <688a7f42-d536-ba0c-eb53-d621bcaaa512@oracle.com> <5947ec33-3195-e57b-ff7a-4cfe3c74e9c3@oracle.com> <59b96dce-83b0-359c-1dcf-8b9cee32387c@oracle.com>, <9cda4784-0566-5d4f-64b4-2f55f587525d@oracle.com> Message-ID: There is another way, by reusing the existing security manager property with a new keyword (?default? is already a well known value) one could implement the stable suppression of the SM without actually needing a new property. It also avoids unclear meaning of denied but specified SM: java.security.manager=disabled // or ?denied? or ?forbidden? or simply ?false? This would also allow an ?ignored? (setSM does nothing). Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: -1056361920m Auftrag von Gesendet: Freitag, September 14, 2018 8:23 PM An: Daniel Fuchs Cc: security Dev OpenJDK Betreff: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable On 9/14/18 4:52 AM, Daniel Fuchs wrote: > The name "jdk.allowSecurityManager" is actually fine. > > I was also confused at first because I believed the > property, if set to false, would just prevent someone > to call System::setSecurityManager at runtime, whereas > it also prevents to set a security manager on the command > line. > > Maybe emphasizing this would remove any confusion. Yes, I was confused about this too -- I didn't realize that the jdk.allowSecurityManager property also disallowed setting the security manager via the java.security.manager property. I thought it just applied to the System.setSecurityManager() method. (Well, it turns out that setting the java.security.manager property on the command line ends up calling System.setSecurityManager(), but this is buried inside the implementation.) So yes, the effect of setting jdk.allowSecurityManager needs to be specified more explicitly. > I wonder if the VM should fail to start if both > -Djdk.allowSecurityManager=false and -Djava.security.manager > are supplied? Maybe, but I don't know that this is necessary. Again, if it's made clear enough that the java.security.manager property is IGNORED if jdk.allowSecurityManager=false, then that's OK with me. s'marks -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Sep 14 19:18:36 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Sep 2018 15:18:36 -0400 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <9cda4784-0566-5d4f-64b4-2f55f587525d@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <688a7f42-d536-ba0c-eb53-d621bcaaa512@oracle.com> <5947ec33-3195-e57b-ff7a-4cfe3c74e9c3@oracle.com> <59b96dce-83b0-359c-1dcf-8b9cee32387c@oracle.com> <9cda4784-0566-5d4f-64b4-2f55f587525d@oracle.com> Message-ID: <8b62b020-415d-f390-4b53-45278cd92af0@oracle.com> On 9/14/18 12:23 PM, Stuart Marks wrote: > > > On 9/14/18 4:52 AM, Daniel Fuchs wrote: >> The name "jdk.allowSecurityManager" is actually fine. >> >> I was also confused at first because I believed the >> property, if set to false, would just prevent someone >> to call System::setSecurityManager at runtime, whereas >> it also prevents to set a security manager on the command >> line. >> >> Maybe emphasizing this would remove any confusion. > > Yes, I was confused about this too -- I didn't realize that the > jdk.allowSecurityManager property also disallowed setting the security > manager via the java.security.manager property. I thought it just > applied to the System.setSecurityManager() method. > > (Well, it turns out that setting the java.security.manager property on > the command line ends up calling System.setSecurityManager(), but this > is buried inside the implementation.) > > So yes, the effect of setting jdk.allowSecurityManager needs to be > specified more explicitly. Yes, agreed. >> I wonder if the VM should fail to start if both >> -Djdk.allowSecurityManager=false and -Djava.security.manager >> are supplied? > > Maybe, but I don't know that this is necessary. Again, if it's made > clear enough that the java.security.manager property is IGNORED if > jdk.allowSecurityManager=false, then that's OK with me. The current implementation ignores the java.security.manager property if jdk.allowSecurityManager=false if both are specified on the command-line. However, that is mostly a side-effect of how the VM currently handles exceptions in it's initialization phases. System.setSecurityManager() does throw an UnsupportedOperationException, but the VM ignores/swallows it. From a usability standpoint, I think it makes more sense for the VM to exit instead because it does not make sense to specify the properties as above and this to me is clearly a configuration error. If the user really wanted to enable a SecurityManager it may also lead to things being deployed insecurely when they really should not be. So, I am leaning towards catching the Exception and rethrowing it as an Error. --Sean From sean.mullan at oracle.com Fri Sep 14 20:15:35 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Sep 2018 16:15:35 -0400 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <688a7f42-d536-ba0c-eb53-d621bcaaa512@oracle.com> <5947ec33-3195-e57b-ff7a-4cfe3c74e9c3@oracle.com> <59b96dce-83b0-359c-1dcf-8b9cee32387c@oracle.com> <9cda4784-0566-5d4f-64b4-2f55f587525d@oracle.com> Message-ID: <42f2070f-943e-50df-b777-d400e0524f4d@oracle.com> On 9/14/18 2:54 PM, Bernd Eckenfels wrote: > There is another way, by reusing the existing security manager property > with a new keyword (?default? is already a well known value) one could > implement the stable suppression of the SM without actually needing a > new property. It also avoids unclear meaning of denied but specified SM: > > java.security.manager=disabled // or ?denied? or ?forbidden? or simply > ?false? > > This would also allow an ?ignored? (setSM does nothing). You probably know this already, but the value of the java.security.manager property is a classname, and you specify that when you want to use your own SM implementation. But that is probably not a big deal - we could still work around that and have a keyword that means as you say above with a pretty low risk of breaking anyone. But as Mandy suggested, we want to work towards a point where you can run an app without an SM and you automatically get the optimizations without having to specify any property. In that case, it seems cleaner to have a separate property to control that behavior. Overloading the java.security.manager property which has been around for a really long time (since JDK 1.0 I think?) might end up being more confusing. --Sean From jai.forums2013 at gmail.com Sat Sep 15 02:58:18 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 15 Sep 2018 08:28:18 +0530 Subject: [PATCH] Trivial typo fix in X509ExtendedKeyManager javadoc Message-ID: I was looking at some key management code and noticed this typo in X509ExtendedKeyManager. Attached is a trivial patch which fixes it. I'm not a committer but have a signed OCA, so I'll need help from a sponsor. -Jaikiran -------------- next part -------------- # HG changeset patch # User Jaikiran Pai # Date 1536980065 -19800 # Sat Sep 15 08:24:25 2018 +0530 # Node ID 91fb2256bc89b1857ecfb1ea7e3dd565a0c1c311 # Parent 594919232b8fdeb77b5e45b8826362975a61e824 fix typo in javadoc of X509ExtendedKeyManager diff --git a/src/java.base/share/classes/javax/net/ssl/X509ExtendedKeyManager.java b/src/java.base/share/classes/javax/net/ssl/X509ExtendedKeyManager.java --- a/src/java.base/share/classes/javax/net/ssl/X509ExtendedKeyManager.java +++ b/src/java.base/share/classes/javax/net/ssl/X509ExtendedKeyManager.java @@ -31,7 +31,7 @@ * Abstract class that provides for extension of the X509KeyManager * interface. *

- * Methods in this class should be overriden to provide actual + * Methods in this class should be overridden to provide actual * implementations. * * @since 1.5 From xuelei.fan at oracle.com Sat Sep 15 03:33:54 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 14 Sep 2018 20:33:54 -0700 Subject: [PATCH] Trivial typo fix in X509ExtendedKeyManager javadoc In-Reply-To: References: Message-ID: <971b1dd2-efd4-8cba-00f4-de9c0f746bc1@oracle.com> Hi Jaikiran, Thanks for the find and the patch. The patch looks fine to me, and I sponsored the committing and now it is in the JDK repository. http://hg.openjdk.java.net/jdk/jdk/rev/6c394ed56b07 Thanks, Xuelei On 9/14/2018 7:58 PM, Jaikiran Pai wrote: > I was looking at some key management code and noticed this typo in > X509ExtendedKeyManager. Attached is a trivial patch which fixes it. I'm > not a committer but have a signed OCA, so I'll need help from a sponsor. > > -Jaikiran > From jai.forums2013 at gmail.com Sat Sep 15 05:13:44 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 15 Sep 2018 10:43:44 +0530 Subject: [PATCH] Trivial typo fix in X509ExtendedKeyManager javadoc In-Reply-To: <971b1dd2-efd4-8cba-00f4-de9c0f746bc1@oracle.com> References: <971b1dd2-efd4-8cba-00f4-de9c0f746bc1@oracle.com> Message-ID: <572ba883-b7dd-c6a4-8986-7f9aa38cd010@gmail.com> Thank you Xuelei. -Jaikiran On 15/09/18 9:03 AM, Xuelei Fan wrote: > Hi Jaikiran, > > Thanks for the find and the patch.? The patch looks fine to me, and I > sponsored the committing and now it is in the JDK repository. > > http://hg.openjdk.java.net/jdk/jdk/rev/6c394ed56b07 > > Thanks, > Xuelei > > On 9/14/2018 7:58 PM, Jaikiran Pai wrote: >> I was looking at some key management code and noticed this typo in >> X509ExtendedKeyManager. Attached is a trivial patch which fixes it. I'm >> not a committer but have a signed OCA, so I'll need help from a sponsor. >> >> -Jaikiran >> From norman.maurer at googlemail.com Sat Sep 15 05:29:02 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Sat, 15 Sep 2018 07:29:02 +0200 Subject: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: References: Message-ID: 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)) > 0000 - 16 03 03 01 60 ....` > read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160)) > 0000 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 ...\..".... at 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..o....K...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)) > 0000 - 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|J....n....] > 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..o....K.. > 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 MT....B5S[...... > 00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65 .(.m...8.wrs%&.e > 00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96 X........P...... > 0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9 .;<..AX...:(..a. > 0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5 .h...f.[..... .. > 0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb .RD...c=........ > 0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6 .*O[J.wx.u. .... > 0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee ...VV._.e.~n=.f. > 0150 - 10 4c f7 6d 9b 73 86 14-7a 81 f8 b1 27 af 08 ee .L.m.s..z...'... > 0160 - ce 26 90 34 73 3d b7 45-8d 85 29 a8 65 19 e7 02 .&.4s=.E..).e... > 0170 - e5 55 4a 27 f1 b1 6a a4-11 cc 6c af 78 6d 22 5c .UJ'..j...l.xm"\ > 0180 - 33 73 e3 ad 7f 8d 1b d3-75 95 66 64 2d 0e f1 3e 3s......u.fd-..> > 0190 - c2 30 df a1 7e ce a3 50-c3 4e 68 f6 36 b3 4e 45 .0..~..P.Nh.6.NE > 01a0 - 9c ac e9 f2 0d 7c e3 73-6a 40 ab 6e 6e f9 d8 20 .....|.sj at .nn.. > 01b0 - 9c f3 04 32 cd 1d df 18-e5 4d e3 e8 b1 38 59 f8 ...2.....M...8Y. > 01c0 - 28 67 2e ca af a2 8b 88-ce ca 48 a6 07 2b a6 9a (g........H..+.. > 01d0 - 0e 88 5b d7 0b d9 31 77-97 8d 6c 2b f5 60 24 61 ..[...1w..l+.`$a > 01e0 - a8 5c 47 5d 7c 66 f0 9b-1f e4 76 93 38 f6 78 3e .\G]|f....v.8.x> > 01f0 - 69 29 72 f9 d9 4b cb 05-03 e4 f2 d6 24 e1 91 ee i)r..K......$... > 0200 - 85 37 d7 7b c3 5c 35 90-08 cd b1 cc 76 11 fc 00 .7.{.\5.....v... > 0210 - 12 7e 89 7b 70 e6 ca fe-0b 26 b6 bb ac fe 4b 9f .~.{p....&....K. > 0220 - ec cf 41 69 42 3a 3e 41-f9 b0 c0 93 5b 70 1f c7 ..AiB:>A....[p.. > 0230 - 11 00 3d ec 66 5a 1a ca-31 89 22 27 02 dd a0 cb ..=.fZ..1."'.... > 0240 - 39 14 25 ee 30 44 e8 62-97 bf 8e 16 63 40 c4 11 9.%.0D.b....c at .. > 0250 - a6 d9 32 b1 3c 86 35 bb-9f f1 4d 71 9f a5 4f 78 ..2.<.5...Mq..Ox > 0260 - 0a e8 96 dd 4d 10 c3 48-f2 db 67 57 2d cd dc 23 ....M..H..gW-..# > 0270 - 3a 8d 6a 61 47 20 ff c8-33 cd e9 f7 47 4c 68 4f :.jaG ..3...GLhO > 0280 - 19 2f 8b e3 b1 90 ac 66-a7 cf 5c e6 d2 05 21 25 ./.....f..\...!% > 0290 - d2 d8 f0 43 8c 55 01 ef-d6 8f c0 27 87 0d 21 d5 ...C.U.....'..!. > 02a0 - 2b 2b 6f db e8 85 ea cd-6e 9c 5d 56 d5 31 c1 f2 ++o.....n.]V.1.. > 02b0 - 97 2f 5a 83 7a 2b 71 03-65 e0 b6 4a 56 37 de e1 ./Z.z+q.e..JV7.. > 02c0 - 80 3a c4 cc 5a ac 3b 9a-7a bf f7 6b fe a8 69 e9 .:..Z.;.z..k..i. > 02d0 - 58 09 59 bd 46 bd d2 a3-bc ad 1c 10 53 c8 29 7b X.Y.F.......S.){ > 02e0 - be 63 00 d6 e5 a8 d6 ab-b2 bc 8b e1 2c 0e 24 2a .c..........,.$* > 02f0 - c2 31 2d d8 6e 1f 19 93-d7 54 e1 1e 28 ce 72 83 .1-.n....T..(.r. > 0300 - ff 05 18 f2 fc e9 0c b3-0c 1b d5 96 c2 d8 fc 76 ...............v > 0310 - 37 a9 5a ef 8e e9 b6 71-21 f3 bd c1 85 23 85 22 7.Z....q!....#." > 0320 - 3d c4 1c c9 31 8b 7e 00-8f 8e b4 9f 05 d4 80 6b =...1.~........k > 0330 - 98 4c a8 82 68 ff 1a a5-28 e2 9b 03 a1 a7 b1 00 .L..h...(....... > 0340 - 02 2b 2d e2 e1 87 8c e8-0a fb 0b 79 54 ca 3d d5 .+-........yT.=. > 0350 - 6a dd b7 b7 87 42 2b 47-49 da e9 0a 82 0a c9 8f j....B+GI....... > 0360 - 57 f7 1e 03 ca 8d 16 bc-21 3a 6a ee b9 b8 fa f0 W.......!:j..... > 0370 - d9 18 35 9f 35 ac d8 6e-9a 8a 0d 56 10 1e 1f 5a ..5.5..n...V...Z > 0380 - ba ec e4 fe 1a 92 b4 31-35 43 1d 99 b9 12 fa ff .......15C...... > 0390 - 99 2b 88 e0 58 ec 9c dc-8f 67 ef 2a c2 e2 64 5d .+..X....g.*..d] > 03a0 - 66 76 1c d0 aa 00 30 59-b1 f5 b1 55 9f ad 60 e9 fv....0Y...U..`. > 03b0 - 3d 03 1e d0 8b 4d bf 74-ac bc bb 1c 83 14 c5 e0 =....M.t........ > 03c0 - f4 fc 70 9e f4 22 a0 78-04 fe c8 b1 17 65 f6 94 ..p..".x.....e.. > 03d0 - 47 82 50 4a b6 32 74 ae-5b 38 5a 2e d9 b0 6a 45 G.PJ.2t.[8Z...jE > 03e0 - 74 e8 f0 22 fe d3 b0 11-c3 fd 72 4f da 77 7a ba t.."......rO.wz. > 03f0 - 26 3e 61 0c 63 21 17 a6-b2 13 6e 71 5c f2 0d ad &>a.c!....nq\... > 0400 - f2 d1 19 71 51 9e a4 1b-b0 30 24 e0 71 7d 87 80 ...qQ....0$.q}.. > 0410 - a9 5a e9 bc db e4 4f 50-4d a1 bc bc 2c 4b 66 98 .Z....OPM...,Kf. > 0420 - d4 e4 b0 76 0f d2 db a5-a5 39 9e f2 5b ea 34 c1 ...v.....9..[.4. > 0430 - 62 ab 47 51 3b 37 17 45-54 31 18 f3 f1 ca 17 03 b.GQ;7.ET1...... > 0440 - 03 01 19 dd 50 50 f5 0c-f2 c9 3c b4 8f 63 cc 4a ....PP....<..c.J > 0450 - a7 50 c9 91 9b 79 9a 2a-5c 47 d3 77 f6 56 69 90 .P...y.*\G.w.Vi. > 0460 - 98 cd ff bd c1 2a 49 fc-0d d4 7e cc 7e 44 af c4 .....*I...~.~D.. > 0470 - 61 47 e0 c1 76 b1 8c 2e-df 7e d0 82 e1 89 1f 04 aG..v....~...... > 0480 - ae 64 bd 71 4d ae 1c 3c-e3 d3 39 5d 61 2a ea 70 .d.qM..<..9]a*.p > 0490 - 8c 31 6d a0 b1 72 a8 7a-5c 9c 11 08 b8 4d a5 c4 .1m..r.z\....M.. > 04a0 - ad 1b 38 4a 6a 02 28 d4-d1 0f c8 9f 0b b3 02 18 ..8Jj.(......... > 04b0 - 82 2b bd 46 82 04 64 f0-41 b2 da f5 cd 9c f7 f3 .+.F..d.A....... > 04c0 - 73 30 58 ca 12 ec ea 90-85 1c 75 09 0a 70 b8 80 s0X.......u..p.. > 04d0 - 3d 02 17 3e 9b 83 04 b5-dd 9e e6 18 17 65 83 a5 =..>.........e.. > 04e0 - 59 7d 4b 98 da bd 8b aa-d6 aa c5 1c 7d 87 56 e3 Y}K.........}.V. > 04f0 - 74 d8 e9 7b eb b3 3d f7-7c 3c 0a e9 a8 2e 04 0d t..{..=.|<...... > 0500 - 6a e7 83 e0 ec 99 43 6a-8b 1c 73 59 7a c8 cd 6e j.....Cj..sYz..n > 0510 - 4a 14 73 ff 9a fb 71 94-d5 50 a9 d9 e0 dd 02 4c J.s...q..P.....L > 0520 - 2b 67 9e da 9e fa 2d 67-49 df 13 10 ed 35 3e 73 +g....-gI....5>s > 0530 - 07 20 17 fb 0b ef f6 d0-b7 68 1c 65 21 a6 e3 3b . .......h.e!..; > 0540 - bf 7b 84 cd 9e f5 76 2a-0d 4f b8 c3 c8 15 08 e9 .{....v*.O...... > 0550 - 0f 3c 50 49 12 97 a8 d7-f1 a3 16 da 17 03 03 00 . 0560 - 35 22 dd a2 9d 25 98 2c-35 b8 00 29 fa a1 dd ba 5"...%.,5..).... > 0570 - 72 b9 fe e5 85 85 f0 f1-3b 4e f5 7c 58 c8 2a da r.......;N.|X.*. > 0580 - d2 75 94 3b c1 7a 7c 7e-db 5b fe 8a 2d 3f 8c 9a .u.;.z|~.[..-?.. > 0590 - 6e 79 ab 2b ff 1a ny.+.. > SSL_accept:SSLv3/TLS write finished > SSL_accept:TLSv1.3 early data > read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) > 0000 - 14 03 03 00 01 ..... > read from 0x7fe400f050c0 [0x7fe40300f608] (1 bytes => 1 (0x1)) > 0000 - 01 . > read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) > 0000 - 17 03 03 00 3d ....= > read from 0x7fe400f050c0 [0x7fe40300f608] (61 bytes => 61 (0x3D)) > 0000 - 38 e7 bb 2c 5b af b6 5f-37 d8 3e 7e bb f4 04 f5 8..,[.._7.>~.... > 0010 - e1 28 b5 e5 07 5a ec ce-da 2f f3 b6 45 61 cf ef .(...Z.../..Ea.. > 0020 - 90 fb 57 b8 f3 20 45 27-60 d4 26 51 38 77 e4 bc ..W.. E'`.&Q8w.. > 0030 - b7 64 d4 8b 73 25 41 9e-fe d3 9d 5f 53 .d..s%A...._S > SSL_accept:TLSv1.3 early data > write to 0x7fe400f050c0 [0x7fe403018a00] (24 bytes => 24 (0x18)) > 0000 - 17 03 03 00 13 25 85 60-eb 7d c1 a8 15 49 d5 63 .....%.`.}...I.c > 0010 - 18 7f c6 ac ed 7f df 77- .......w > SSL3 alert write:fatal:unknown > SSL_accept:error in error > ERROR > 140736092021632:error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate:ssl/statem/statem_srvr.c:3654: > shutting down SSL > CONNECTION CLOSED > > > > When using openssl s_client all works as expected tho (thats also true if I use my native implementation on the client and server side that uses openssl): > > ./bin/openssl s_client -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 -state -tls1_3 -connect localhost:8443 > > The interesting thing is if I use ?-verify 1? and not ?-Verify 1? with openssl which tells it I want to request a certificate but will also process if none is provided I receive the certificate at some point as seen here: > > SSL_accept:before SSL initialization > read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) > 0000 - 16 03 03 01 60 ....` > read from 0x7fdc58809fb0 [0x7fdc5901da08] (352 bytes => 352 (0x160)) > 0000 - 01 00 01 5c 03 03 61 c0-b3 ed 88 65 e6 cf 11 3f ...\..a....e...? > 0010 - c0 e0 f8 df a6 63 32 c2-ab 3d 61 6f 41 ed b1 4b .....c2..=aoA..K > 0020 - 53 0e 83 e5 a1 b8 20 c7-1b 8c b8 e6 b5 da 4e 4e S..... .......NN > 0030 - 3f 3c 61 7a ad 58 23 94-a7 32 79 2f db 9f 21 c0 ? 0040 - 8e 0c c5 ce b1 c2 a4 00-14 c0 2c c0 2b c0 2f c0 ..........,.+./. > 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 52 dc d6 47 6e .3.G.E...A.R..Gn > 0120 - a1 de 9c 71 c2 54 0e 5c-9b 57 fb c8 aa 3f 19 f7 ...q.T.\.W...?.. > 0130 - d3 a4 25 12 fa 3f 6c 6d-95 30 66 ca 63 b7 a1 dd ..%..?lm.0f.c... > 0140 - ae 9f 99 d6 a8 6b 20 4f-29 7a 74 58 ad 58 de 12 .....k O)ztX.X.. > 0150 - d7 a5 9b 69 dc 27 ac ec-9e d4 04 ff 01 00 01 00 ...i.'.......... > 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 0x7fdc58809fb0 [0x7fdc59025e00] (1430 bytes => 1430 (0x596)) > 0000 - 16 03 03 00 9b 02 00 00-97 03 03 8b c8 62 48 6c .............bHl > 0010 - f5 7c 73 d9 17 f8 63 a2-11 27 40 93 09 26 53 06 .|s...c..'@..&S. > 0020 - b3 62 df 46 26 b6 dc 59-29 b5 58 20 c7 1b 8c b8 .b.F&..Y).X .... > 0030 - e6 b5 da 4e 4e 3f 3c 61-7a ad 58 23 94 a7 32 79 ...NN? 0040 - 2f db 9f 21 c0 8e 0c c5-ce b1 c2 a4 13 01 00 00 /..!............ > 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 O.+.....3.E...A. > 0060 - 07 63 1c 19 53 89 68 a8-0f ea 9e 4c 18 6f 2a ad .c..S.h....L.o*. > 0070 - 2a df eb 17 a2 08 94 c6-e3 c5 97 ae 0f c1 1a d7 *............... > 0080 - 0d d7 2e 6d 77 3d 30 a0-07 db 70 35 bb 37 dd 1e ...mw=0...p5.7.. > 0090 - b6 f3 4d cb 13 97 7c 11-63 98 e8 64 2d a7 e6 cc ..M...|.c..d-... > 00a0 - 14 03 03 00 01 01 17 03-03 00 27 a3 73 d2 ee 2c ..........'.s.., > 00b0 - 2f 9c 8f 95 7f ca a3 89-bc b4 b3 b2 3c 8b 23 ef /...........<.#. > 00c0 - 36 66 23 c9 09 02 33 0d-dc 5d 36 61 44 89 8b ef 6f#...3..]6aD... > 00d0 - fd 13 17 03 03 00 42 f2-5b 3c 0c 27 5e 7f 97 4f ......B.[<.'^..O > 00e0 - 0f de 8c b9 0a a1 41 c7-c2 1e 92 99 6a d5 bd 12 ......A.....j... > 00f0 - 38 b6 b7 93 33 e9 8e 0f-44 93 f0 69 58 b6 41 22 8...3...D..iX.A" > 0100 - 46 e2 4a d5 d6 32 2b b8-a7 ae 3a c2 c5 2f e6 35 F.J..2+...:../.5 > 0110 - 11 0c f1 9a 35 2a 87 ed-9e 17 03 03 03 20 a7 e2 ....5*....... .. > 0120 - fe ba c7 10 5b 9c cd 94-67 19 37 2d 46 59 ab 56 ....[...g.7-FY.V > 0130 - 6b dd a4 10 61 cc ed f1-71 a7 2d 6a 41 2e 2b da k...a...q.-jA.+. > 0140 - d1 35 fc 01 df 49 e5 90-1d 9b b2 03 0a 81 58 18 .5...I........X. > 0150 - 96 a1 db 31 19 98 35 5c-87 8f 6e 32 0a e6 c0 aa ...1..5\..n2.... > 0160 - 9e 8e 72 e2 34 b3 b7 a3-d6 d1 66 c7 ce 93 fe 78 ..r.4.....f....x > 0170 - 17 c4 71 7c 42 15 c8 af-dc 4f 50 42 51 80 fc bf ..q|B....OPBQ... > 0180 - fc 54 d5 d8 59 20 9a 90-c4 78 97 9c 2d 4a d5 58 .T..Y ...x..-J.X > 0190 - be 81 79 23 59 22 9d 27-f8 bd a0 b2 98 b3 47 82 ..y#Y".'......G. > 01a0 - d3 52 b5 b5 91 ab 5c 76-52 c5 a5 95 2d 03 1c b7 .R....\vR...-... > 01b0 - 64 4d 0b 88 7f 15 0b c8-a8 90 50 9a b6 b1 9f b7 dM........P..... > 01c0 - 40 09 f2 5f 39 f8 9a 06-21 4d 67 10 0a 67 08 b6 @.._9...!Mg..g.. > 01d0 - b5 9a 25 8c d5 ca 31 6a-8a 6b 01 93 7d 6f 1e 52 ..%...1j.k..}o.R > 01e0 - 98 96 9d fb e8 c1 07 ab-57 98 2d 1e 75 77 ef c2 ........W.-.uw.. > 01f0 - 49 78 e0 b9 2b 32 23 7e-95 4d 3e 27 00 61 86 0c Ix..+2#~.M>'.a.. > 0200 - 47 c7 79 e4 ee 9d ba c0-ea 62 f1 0d 8e 4a 91 30 G.y......b...J.0 > 0210 - bc 4f 5a 98 26 30 66 ec-c4 63 8f 28 d5 1c 61 23 .OZ.&0f..c.(..a# > 0220 - ea e9 90 4e 36 d9 fa 31-7b 14 27 22 0a ae 9f 64 ...N6..1{.'"...d > 0230 - 40 3d e5 a0 5c 9d 3c 04-71 09 b0 7a 6b 51 a0 9c @=..\.<.q..zkQ.. > 0240 - c0 61 32 ce 15 62 8e 29-b1 59 91 c0 17 2c b3 c5 .a2..b.).Y...,.. > 0250 - f9 ed 07 65 3d 11 de 98-de 62 36 50 74 37 af 2d ...e=....b6Pt7.- > 0260 - 7d 86 55 c4 3e a2 83 ab-47 8d f2 b2 8d 1d 75 83 }.U.>...G.....u. > 0270 - b5 e4 41 87 a7 a3 85 b0-5e 4e 2e 9c 8c b0 1b 83 ..A.....^N...... > 0280 - 7b 54 79 c9 60 ea 7d ed-06 fa dd 24 40 f1 53 9e {Ty.`.}....$@.S. > 0290 - 43 79 25 53 9c c7 6e 95-ab 9f 96 59 cd b9 7b a8 Cy%S..n....Y..{. > 02a0 - a0 23 13 69 db a9 c9 e7-1a 8e e1 9b 54 94 1c 44 .#.i........T..D > 02b0 - 50 08 8b dd eb 4e 2b bb-d7 c9 c2 33 8c a1 b3 65 P....N+....3...e > 02c0 - 06 e6 9d ac 11 16 21 58-40 8d 59 e6 67 e5 31 02 ......!X at .Y.g.1. > 02d0 - 15 8d 29 80 20 66 ba c3-56 93 95 5c 65 4b 41 00 ..). f..V..\eKA. > 02e0 - c5 71 12 12 f5 20 4f 59-be 77 06 10 6e 48 85 5c .q... OY.w..nH.\ > 02f0 - ff a2 c4 ae fb 4d 95 f5-cc f6 61 20 33 b7 92 1d .....M....a 3... > 0300 - ac a8 f1 b2 b0 88 c6 7b-8b 00 53 30 6d 4a d1 42 .......{..S0mJ.B > 0310 - b3 3e 85 f5 84 e1 c6 ab-10 9d 61 03 46 ff 2d 81 .>........a.F.-. > 0320 - 15 4f 84 d1 4c ee f4 a6-a0 ec 50 60 a0 d1 ff df .O..L.....P`.... > 0330 - 8a 97 f6 7d fb 8f fb 60-18 d4 f1 1f 92 4d d8 69 ...}...`.....M.i > 0340 - b1 92 97 44 0f 3c 8a aa-47 07 48 d4 07 2d 3e f2 ...D.<..G.H..->. > 0350 - c4 a7 16 35 a7 17 71 ef-98 84 24 67 12 58 30 3b ...5..q...$g.X0; > 0360 - 1d 41 8d e5 12 52 95 64-e5 88 35 99 d7 c3 58 40 .A...R.d..5...X@ > 0370 - f9 55 9b 9f e5 33 15 70-41 d7 45 ba a4 fc 75 ea .U...3.pA.E...u. > 0380 - a4 ae f0 68 ea 64 d8 f5-06 68 a9 75 22 4d 43 cc ...h.d...h.u"MC. > 0390 - ff 50 cc ac 6e fd 43 dd-eb e4 c8 dd 4b 6c 12 bb .P..n.C.....Kl.. > 03a0 - f1 d4 5e 11 4a 86 90 0b-f8 3a 2e 23 db 61 5a 1f ..^.J....:.#.aZ. > 03b0 - 7e 11 00 92 21 68 1f b5-ab f2 f8 38 5e 62 ea f8 ~...!h.....8^b.. > 03c0 - da ef c2 6e a0 b8 20 e4-69 49 b3 1f 15 84 0b 9b ...n.. .iI...... > 03d0 - ce b0 6f 36 32 7f 7e bf-e8 d7 18 7a 58 60 f4 04 ..o62.~....zX`.. > 03e0 - cc 36 bf 06 cd ec e5 9b-19 03 96 09 fb af 8f c3 .6.............. > 03f0 - 98 b4 02 aa e8 55 81 aa-c4 fe 06 81 30 a0 c7 b2 .....U......0... > 0400 - f8 e2 30 00 d7 a0 54 7f-5f d7 ef a6 f8 41 58 34 ..0...T._....AX4 > 0410 - f5 f0 18 69 8d e6 7a 23-78 90 8f b1 05 c5 b5 7f ...i..z#x....... > 0420 - e0 f2 c7 fa c8 36 5b 53-7e cf e6 75 d3 54 b4 69 .....6[S~..u.T.i > 0430 - 68 43 0d 6a d2 83 cc 13-6d ca bf 83 3c 90 17 03 hC.j....m...<... > 0440 - 03 01 19 96 dc 49 26 ce-1d 8e 86 3d bd cb 00 5e .....I&....=...^ > 0450 - ee f6 e7 1d 16 7a ca ef-fa 6d 16 40 b6 99 d0 c1 .....z...m. at .... > 0460 - df 0b 5f 51 60 a8 24 e0-61 82 13 40 da 88 38 3a .._Q`.$.a.. at ..8: > 0470 - 26 1d 80 51 c4 b1 95 35-95 3c 91 35 28 17 49 d8 &..Q...5.<.5(.I. > 0480 - c3 45 be 32 98 3e 02 07-3b 01 20 2b 51 e1 1a 94 .E.2.>..;. +Q... > 0490 - b9 be 96 aa 7a 13 09 ff-d5 a9 63 d4 6f 49 cb b5 ....z.....c.oI.. > 04a0 - 23 ab 7f 8c e2 63 f0 5c-5c 27 1e 04 a8 71 0c c0 #....c.\\'...q.. > 04b0 - 89 cd ed 18 8d 5b 75 ac-af f3 68 6d cc ba 20 38 .....[u...hm.. 8 > 04c0 - b5 7c 09 47 29 28 e2 26-57 57 1f f0 f3 18 fd 6f .|.G)(.&WW.....o > 04d0 - 27 42 a4 e3 de bb e5 d6-09 7d 25 b1 98 97 ad 33 'B.......}%....3 > 04e0 - 68 35 92 07 80 23 f1 66-20 5d 74 f3 02 c5 51 ff h5...#.f ]t...Q. > 04f0 - 07 a9 e9 0e 3e 74 da 2e-8f 3b 16 be e6 94 1b 66 ....>t...;.....f > 0500 - bb b2 a2 1e 7c 7b ff 5e-a4 36 2a ba 0b cd 7f e9 ....|{.^.6*..... > 0510 - 86 bb 5e 30 f5 57 92 52-82 b6 2e da 71 b7 22 c2 ..^0.W.R....q.". > 0520 - 90 c4 69 46 07 df 6c 3f-05 8b 19 3e ce b9 75 0d ..iF..l?...>..u. > 0530 - 4b 97 37 ae 94 e2 d6 3c-91 e6 82 c7 a1 78 79 2c K.7....<.....xy, > 0540 - 9a a3 d5 45 94 ad e2 c8-ab fd 81 ec 62 87 f7 75 ...E........b..u > 0550 - e3 70 79 8e 82 3b c5 45-0d d0 33 5f 17 03 03 00 .py..;.E..3_.... > 0560 - 35 da e0 74 2a 06 41 5a-64 1e 54 94 29 73 43 3f 5..t*.AZd.T.)sC? > 0570 - e5 24 a8 ba b2 7e 6b 26-82 fc d9 f6 dd 19 05 4a .$...~k&.......J > 0580 - 2c 1a f3 bb 16 1d 38 95-a6 d3 a8 58 f6 a3 41 c7 ,.....8....X..A. > 0590 - 92 44 35 24 25 0e .D5$%. > SSL_accept:SSLv3/TLS write finished > SSL_accept:TLSv1.3 early data > read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) > 0000 - 14 03 03 00 01 ..... > read from 0x7fdc58809fb0 [0x7fdc5901da08] (1 bytes => 1 (0x1)) > 0000 - 01 . > read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) > 0000 - 17 03 03 00 3d ....= > read from 0x7fdc58809fb0 [0x7fdc5901da08] (61 bytes => 61 (0x3D)) > 0000 - ad dd 3e d9 ee ab 56 65-50 1c 72 2a d8 62 7f 90 ..>...VeP.r*.b.. > 0010 - 13 71 7d 37 39 40 fb 89-8f 05 4b 39 44 9d 4d 67 .q}79 at ....K9D.Mg > 0020 - e3 41 29 b6 3e e8 fe 04-1b 8e eb 7a 4c e2 14 a0 .A).>......zL... > 0030 - b1 c2 47 3f 94 35 ed ab-8a d1 75 3b ba ..G?.5....u;. > SSL_accept:TLSv1.3 early data > SSL_accept:SSLv3/TLS read client certificate > SSL_accept:SSLv3/TLS read finished > write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) > 0000 - 17 03 03 00 da 52 1f 48-00 f4 31 13 90 7f 9c c2 .....R.H..1..... > 0010 - fc 70 1a fc f7 4a 48 e7-31 ad 37 ab b5 2b 4e 5c .p...JH.1.7..+N\ > 0020 - e8 d8 6d e9 af 6c 4f c1-9e 7b ea ff ef b3 eb 74 ..m..lO..{.....t > 0030 - 27 67 10 21 66 5b 32 13-31 bc 99 d5 1c 6c 79 55 'g.!f[2.1....lyU > 0040 - f3 3e f6 4b 07 4d a9 78-3d 12 8a f5 38 ef d9 f4 .>.K.M.x=...8... > 0050 - 48 e0 2c 35 94 06 4f eb-09 e6 70 fb 59 95 7a c8 H.,5..O...p.Y.z. > 0060 - 24 dd 24 e2 f9 63 b9 3c-f2 66 86 c4 73 44 53 fd $.$..c.<.f..sDS. > 0070 - ca 67 8f 01 d6 db 70 f9-60 bc 50 11 51 72 dc 63 .g....p.`.P.Qr.c > 0080 - 12 ca 4f 23 e2 c5 d1 1d-e5 b0 d4 ec 89 ca 28 be ..O#..........(. > 0090 - 9c 30 83 40 02 a4 62 a8-5c b3 20 1a ab 39 b7 7b .0. at ..b.\. ..9.{ > 00a0 - 89 13 39 87 73 be a8 f8-60 13 31 0a 48 5c 79 b9 ..9.s...`.1.H\y. > 00b0 - cc 4a 51 e3 0d d2 b4 93-c0 1f 3a 22 b3 fa 24 a0 .JQ.......:"..$. > 00c0 - 7c f6 76 79 d0 2d 5b 1a-ff a6 e9 e1 40 d3 b1 8c |.vy.-[..... at ... > 00d0 - 0a fa fa de f3 8e d6 ad-9a 22 6b 67 0b 88 18 ........."kg... > SSL_accept:SSLv3/TLS write session ticket > write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) > 0000 - 17 03 03 00 da 46 aa ea-6a 37 b1 35 e8 41 c8 b3 .....F..j7.5.A.. > 0010 - 84 25 af 1c 36 a3 6d 78-a4 44 4a 83 52 ef 13 7c .%..6.mx.DJ.R..| > 0020 - 8f 18 d3 4c f8 22 c8 b3-ad d0 d0 5b 47 a0 43 da ...L.".....[G.C. > 0030 - d2 6e 04 8f dc c9 56 90-58 87 62 63 4c cc 31 ec .n....V.X.bcL.1. > 0040 - b8 c9 18 be 41 32 e1 3c-00 41 2a f1 4d 5c 2d 44 ....A2.<.A*.M\-D > 0050 - 8c aa e1 f0 ed 38 ee 44-64 e5 fd ea 58 3b 84 5d .....8.Dd...X;.] > 0060 - 83 39 21 2e fe 79 4d 76-10 65 87 0f 3c ac df 28 .9!..yMv.e..<..( > 0070 - 49 f8 60 eb be 49 e4 0a-0b 6a 03 2b 9d cf 9b a5 I.`..I...j.+.... > 0080 - 03 56 58 32 c2 b2 59 f9-0a 0d f0 ae af ff 20 19 .VX2..Y....... . > 0090 - e5 6e e4 86 2f 5e 3f 7d-47 d5 73 ae 89 48 a7 66 .n../^?}G.s..H.f > 00a0 - fb 2d 83 60 e8 8b ab 27-12 db 24 78 54 eb 14 2d .-.`...'..$xT..- > 00b0 - b7 c6 17 2d 3c 91 57 ac-6e 35 b8 c3 fa c2 42 48 ...-<.W.n5....BH > 00c0 - 2a cb aa 98 32 89 8a ce-0c f7 cd 5e fb bf 6d 33 *...2......^..m3 > 00d0 - 08 50 cf 1e 06 bb a1 98-be a4 a9 51 9a b0 34 .P.........Q..4 > SSL_accept:SSLv3/TLS write session ticket > write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) > 0000 - 17 03 03 00 12 c5 9b 73-cc 91 7e 48 cb 25 31 a0 .......s..~H.%1. > 0010 - 67 41 db bb 0f 62 d8 gA...b. > write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) > 0000 - 17 03 03 00 12 0f dd 3f-c1 7c e6 b0 cc ea f0 13 .......?.|...... > 0010 - 00 d8 01 de ef 7c bb .....|. > read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) > 0000 - 17 03 03 00 1e ..... > read from 0x7fdc58809fb0 [0x7fdc5901da08] (30 bytes => 30 (0x1E)) > 0000 - d6 88 44 82 cb 23 16 ba-c9 a4 fb 55 51 08 90 c1 ..D..#.....UQ... > 0010 - bf bd a1 7f 0e 37 b0 b4-b5 df f1 07 6c 07 .....7......l. > I am a clientwrite to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) > 0000 - 17 03 03 00 12 c0 70 5d-14 e7 69 57 0a d8 64 16 ......p]..iW..d. > 0010 - 0c 90 06 0f c3 4d 1d .....M. > read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) > 0000 - 17 03 03 00 13 ..... > read from 0x7fdc58809fb0 [0x7fdc5901da08] (19 bytes => 19 (0x13)) > 0000 - 60 28 5b ff bb 0d 9f 96-9a 2d cb fd 60 eb 96 62 `([......-..`..b > 0010 - 53 e6 25 S.% > SSL3 alert read:warning:close notify > DONE > shutting down SSL > CONNECTION CLOSED > > > I am using the following JDK version on MacOS: > > ssl git:(cert_cb_openssl_1_1_1) ? /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java -version > java version "11" 2018-09-25 > Java(TM) SE Runtime Environment 18.9 (build 11+28) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) > > For this to work you will need to have openssl 1.1.1 installed. > > Any help would be welcome, > Norman > > [1] https://github.com/netty/netty-tcnative > > > From ivan.gerasimov at oracle.com Sat Sep 15 06:03:45 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 14 Sep 2018 23:03:45 -0700 Subject: RFR 8210786 : Typo s/overriden/overridden/ in several places Message-ID: <2ff4ae4c-4992-d468-e187-fc66808c9eeb@oracle.com> 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 From xuelei.fan at oracle.com Sat Sep 15 06:08:37 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 14 Sep 2018 23:08:37 -0700 Subject: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: References: Message-ID: <32bad254-1a8c-7933-d5a0-0b8ce3ed2f68@oracle.com> 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)) >> 0000 - 16 03 03 01 60 ....` >> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160)) >> 0000 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 ...\..".... at 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..o....K...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)) >> 0000 - 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|J....n....] >> 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..o....K.. >> 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 MT....B5S[...... >> 00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65 .(.m...8.wrs%&.e >> 00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96 X........P...... >> 0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9 .;<..AX...:(..a. >> 0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5 .h...f.[..... .. >> 0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb .RD...c=........ >> 0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6 .*O[J.wx.u. .... >> 0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee ...VV._.e.~n=.f. >> 0150 - 10 4c f7 6d 9b 73 86 14-7a 81 f8 b1 27 af 08 ee .L.m.s..z...'... >> 0160 - ce 26 90 34 73 3d b7 45-8d 85 29 a8 65 19 e7 02 .&.4s=.E..).e... >> 0170 - e5 55 4a 27 f1 b1 6a a4-11 cc 6c af 78 6d 22 5c .UJ'..j...l.xm"\ >> 0180 - 33 73 e3 ad 7f 8d 1b d3-75 95 66 64 2d 0e f1 3e 3s......u.fd-..> >> 0190 - c2 30 df a1 7e ce a3 50-c3 4e 68 f6 36 b3 4e 45 .0..~..P.Nh.6.NE >> 01a0 - 9c ac e9 f2 0d 7c e3 73-6a 40 ab 6e 6e f9 d8 20 .....|.sj at .nn.. >> 01b0 - 9c f3 04 32 cd 1d df 18-e5 4d e3 e8 b1 38 59 f8 ...2.....M...8Y. >> 01c0 - 28 67 2e ca af a2 8b 88-ce ca 48 a6 07 2b a6 9a (g........H..+.. >> 01d0 - 0e 88 5b d7 0b d9 31 77-97 8d 6c 2b f5 60 24 61 ..[...1w..l+.`$a >> 01e0 - a8 5c 47 5d 7c 66 f0 9b-1f e4 76 93 38 f6 78 3e .\G]|f....v.8.x> >> 01f0 - 69 29 72 f9 d9 4b cb 05-03 e4 f2 d6 24 e1 91 ee i)r..K......$... >> 0200 - 85 37 d7 7b c3 5c 35 90-08 cd b1 cc 76 11 fc 00 .7.{.\5.....v... >> 0210 - 12 7e 89 7b 70 e6 ca fe-0b 26 b6 bb ac fe 4b 9f .~.{p....&....K. >> 0220 - ec cf 41 69 42 3a 3e 41-f9 b0 c0 93 5b 70 1f c7 ..AiB:>A....[p.. >> 0230 - 11 00 3d ec 66 5a 1a ca-31 89 22 27 02 dd a0 cb ..=.fZ..1."'.... >> 0240 - 39 14 25 ee 30 44 e8 62-97 bf 8e 16 63 40 c4 11 9.%.0D.b....c at .. >> 0250 - a6 d9 32 b1 3c 86 35 bb-9f f1 4d 71 9f a5 4f 78 ..2.<.5...Mq..Ox >> 0260 - 0a e8 96 dd 4d 10 c3 48-f2 db 67 57 2d cd dc 23 ....M..H..gW-..# >> 0270 - 3a 8d 6a 61 47 20 ff c8-33 cd e9 f7 47 4c 68 4f :.jaG ..3...GLhO >> 0280 - 19 2f 8b e3 b1 90 ac 66-a7 cf 5c e6 d2 05 21 25 ./.....f..\...!% >> 0290 - d2 d8 f0 43 8c 55 01 ef-d6 8f c0 27 87 0d 21 d5 ...C.U.....'..!. >> 02a0 - 2b 2b 6f db e8 85 ea cd-6e 9c 5d 56 d5 31 c1 f2 ++o.....n.]V.1.. >> 02b0 - 97 2f 5a 83 7a 2b 71 03-65 e0 b6 4a 56 37 de e1 ./Z.z+q.e..JV7.. >> 02c0 - 80 3a c4 cc 5a ac 3b 9a-7a bf f7 6b fe a8 69 e9 .:..Z.;.z..k..i. >> 02d0 - 58 09 59 bd 46 bd d2 a3-bc ad 1c 10 53 c8 29 7b X.Y.F.......S.){ >> 02e0 - be 63 00 d6 e5 a8 d6 ab-b2 bc 8b e1 2c 0e 24 2a .c..........,.$* >> 02f0 - c2 31 2d d8 6e 1f 19 93-d7 54 e1 1e 28 ce 72 83 .1-.n....T..(.r. >> 0300 - ff 05 18 f2 fc e9 0c b3-0c 1b d5 96 c2 d8 fc 76 ...............v >> 0310 - 37 a9 5a ef 8e e9 b6 71-21 f3 bd c1 85 23 85 22 7.Z....q!....#." >> 0320 - 3d c4 1c c9 31 8b 7e 00-8f 8e b4 9f 05 d4 80 6b =...1.~........k >> 0330 - 98 4c a8 82 68 ff 1a a5-28 e2 9b 03 a1 a7 b1 00 .L..h...(....... >> 0340 - 02 2b 2d e2 e1 87 8c e8-0a fb 0b 79 54 ca 3d d5 .+-........yT.=. >> 0350 - 6a dd b7 b7 87 42 2b 47-49 da e9 0a 82 0a c9 8f j....B+GI....... >> 0360 - 57 f7 1e 03 ca 8d 16 bc-21 3a 6a ee b9 b8 fa f0 W.......!:j..... >> 0370 - d9 18 35 9f 35 ac d8 6e-9a 8a 0d 56 10 1e 1f 5a ..5.5..n...V...Z >> 0380 - ba ec e4 fe 1a 92 b4 31-35 43 1d 99 b9 12 fa ff .......15C...... >> 0390 - 99 2b 88 e0 58 ec 9c dc-8f 67 ef 2a c2 e2 64 5d .+..X....g.*..d] >> 03a0 - 66 76 1c d0 aa 00 30 59-b1 f5 b1 55 9f ad 60 e9 fv....0Y...U..`. >> 03b0 - 3d 03 1e d0 8b 4d bf 74-ac bc bb 1c 83 14 c5 e0 =....M.t........ >> 03c0 - f4 fc 70 9e f4 22 a0 78-04 fe c8 b1 17 65 f6 94 ..p..".x.....e.. >> 03d0 - 47 82 50 4a b6 32 74 ae-5b 38 5a 2e d9 b0 6a 45 G.PJ.2t.[8Z...jE >> 03e0 - 74 e8 f0 22 fe d3 b0 11-c3 fd 72 4f da 77 7a ba t.."......rO.wz. >> 03f0 - 26 3e 61 0c 63 21 17 a6-b2 13 6e 71 5c f2 0d ad &>a.c!....nq\... >> 0400 - f2 d1 19 71 51 9e a4 1b-b0 30 24 e0 71 7d 87 80 ...qQ....0$.q}.. >> 0410 - a9 5a e9 bc db e4 4f 50-4d a1 bc bc 2c 4b 66 98 .Z....OPM...,Kf. >> 0420 - d4 e4 b0 76 0f d2 db a5-a5 39 9e f2 5b ea 34 c1 ...v.....9..[.4. >> 0430 - 62 ab 47 51 3b 37 17 45-54 31 18 f3 f1 ca 17 03 b.GQ;7.ET1...... >> 0440 - 03 01 19 dd 50 50 f5 0c-f2 c9 3c b4 8f 63 cc 4a ....PP....<..c.J >> 0450 - a7 50 c9 91 9b 79 9a 2a-5c 47 d3 77 f6 56 69 90 .P...y.*\G.w.Vi. >> 0460 - 98 cd ff bd c1 2a 49 fc-0d d4 7e cc 7e 44 af c4 .....*I...~.~D.. >> 0470 - 61 47 e0 c1 76 b1 8c 2e-df 7e d0 82 e1 89 1f 04 aG..v....~...... >> 0480 - ae 64 bd 71 4d ae 1c 3c-e3 d3 39 5d 61 2a ea 70 .d.qM..<..9]a*.p >> 0490 - 8c 31 6d a0 b1 72 a8 7a-5c 9c 11 08 b8 4d a5 c4 .1m..r.z\....M.. >> 04a0 - ad 1b 38 4a 6a 02 28 d4-d1 0f c8 9f 0b b3 02 18 ..8Jj.(......... >> 04b0 - 82 2b bd 46 82 04 64 f0-41 b2 da f5 cd 9c f7 f3 .+.F..d.A....... >> 04c0 - 73 30 58 ca 12 ec ea 90-85 1c 75 09 0a 70 b8 80 s0X.......u..p.. >> 04d0 - 3d 02 17 3e 9b 83 04 b5-dd 9e e6 18 17 65 83 a5 =..>.........e.. >> 04e0 - 59 7d 4b 98 da bd 8b aa-d6 aa c5 1c 7d 87 56 e3 Y}K.........}.V. >> 04f0 - 74 d8 e9 7b eb b3 3d f7-7c 3c 0a e9 a8 2e 04 0d t..{..=.|<...... >> 0500 - 6a e7 83 e0 ec 99 43 6a-8b 1c 73 59 7a c8 cd 6e j.....Cj..sYz..n >> 0510 - 4a 14 73 ff 9a fb 71 94-d5 50 a9 d9 e0 dd 02 4c J.s...q..P.....L >> 0520 - 2b 67 9e da 9e fa 2d 67-49 df 13 10 ed 35 3e 73 +g....-gI....5>s >> 0530 - 07 20 17 fb 0b ef f6 d0-b7 68 1c 65 21 a6 e3 3b . .......h.e!..; >> 0540 - bf 7b 84 cd 9e f5 76 2a-0d 4f b8 c3 c8 15 08 e9 .{....v*.O...... >> 0550 - 0f 3c 50 49 12 97 a8 d7-f1 a3 16 da 17 03 03 00 .> 0560 - 35 22 dd a2 9d 25 98 2c-35 b8 00 29 fa a1 dd ba 5"...%.,5..).... >> 0570 - 72 b9 fe e5 85 85 f0 f1-3b 4e f5 7c 58 c8 2a da r.......;N.|X.*. >> 0580 - d2 75 94 3b c1 7a 7c 7e-db 5b fe 8a 2d 3f 8c 9a .u.;.z|~.[..-?.. >> 0590 - 6e 79 ab 2b ff 1a ny.+.. >> SSL_accept:SSLv3/TLS write finished >> SSL_accept:TLSv1.3 early data >> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >> 0000 - 14 03 03 00 01 ..... >> read from 0x7fe400f050c0 [0x7fe40300f608] (1 bytes => 1 (0x1)) >> 0000 - 01 . >> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >> 0000 - 17 03 03 00 3d ....= >> read from 0x7fe400f050c0 [0x7fe40300f608] (61 bytes => 61 (0x3D)) >> 0000 - 38 e7 bb 2c 5b af b6 5f-37 d8 3e 7e bb f4 04 f5 8..,[.._7.>~.... >> 0010 - e1 28 b5 e5 07 5a ec ce-da 2f f3 b6 45 61 cf ef .(...Z.../..Ea.. >> 0020 - 90 fb 57 b8 f3 20 45 27-60 d4 26 51 38 77 e4 bc ..W.. E'`.&Q8w.. >> 0030 - b7 64 d4 8b 73 25 41 9e-fe d3 9d 5f 53 .d..s%A...._S >> SSL_accept:TLSv1.3 early data >> write to 0x7fe400f050c0 [0x7fe403018a00] (24 bytes => 24 (0x18)) >> 0000 - 17 03 03 00 13 25 85 60-eb 7d c1 a8 15 49 d5 63 .....%.`.}...I.c >> 0010 - 18 7f c6 ac ed 7f df 77- .......w >> SSL3 alert write:fatal:unknown >> SSL_accept:error in error >> ERROR >> 140736092021632:error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate:ssl/statem/statem_srvr.c:3654: >> shutting down SSL >> CONNECTION CLOSED >> >> >> >> When using openssl s_client all works as expected tho (thats also true if I use my native implementation on the client and server side that uses openssl): >> >> ./bin/openssl s_client -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 -state -tls1_3 -connect localhost:8443 >> >> The interesting thing is if I use ?-verify 1? and not ?-Verify 1? with openssl which tells it I want to request a certificate but will also process if none is provided I receive the certificate at some point as seen here: >> >> SSL_accept:before SSL initialization >> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >> 0000 - 16 03 03 01 60 ....` >> read from 0x7fdc58809fb0 [0x7fdc5901da08] (352 bytes => 352 (0x160)) >> 0000 - 01 00 01 5c 03 03 61 c0-b3 ed 88 65 e6 cf 11 3f ...\..a....e...? >> 0010 - c0 e0 f8 df a6 63 32 c2-ab 3d 61 6f 41 ed b1 4b .....c2..=aoA..K >> 0020 - 53 0e 83 e5 a1 b8 20 c7-1b 8c b8 e6 b5 da 4e 4e S..... .......NN >> 0030 - 3f 3c 61 7a ad 58 23 94-a7 32 79 2f db 9f 21 c0 ?> 0040 - 8e 0c c5 ce b1 c2 a4 00-14 c0 2c c0 2b c0 2f c0 ..........,.+./. >> 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 52 dc d6 47 6e .3.G.E...A.R..Gn >> 0120 - a1 de 9c 71 c2 54 0e 5c-9b 57 fb c8 aa 3f 19 f7 ...q.T.\.W...?.. >> 0130 - d3 a4 25 12 fa 3f 6c 6d-95 30 66 ca 63 b7 a1 dd ..%..?lm.0f.c... >> 0140 - ae 9f 99 d6 a8 6b 20 4f-29 7a 74 58 ad 58 de 12 .....k O)ztX.X.. >> 0150 - d7 a5 9b 69 dc 27 ac ec-9e d4 04 ff 01 00 01 00 ...i.'.......... >> 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 0x7fdc58809fb0 [0x7fdc59025e00] (1430 bytes => 1430 (0x596)) >> 0000 - 16 03 03 00 9b 02 00 00-97 03 03 8b c8 62 48 6c .............bHl >> 0010 - f5 7c 73 d9 17 f8 63 a2-11 27 40 93 09 26 53 06 .|s...c..'@..&S. >> 0020 - b3 62 df 46 26 b6 dc 59-29 b5 58 20 c7 1b 8c b8 .b.F&..Y).X .... >> 0030 - e6 b5 da 4e 4e 3f 3c 61-7a ad 58 23 94 a7 32 79 ...NN?> 0040 - 2f db 9f 21 c0 8e 0c c5-ce b1 c2 a4 13 01 00 00 /..!............ >> 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 O.+.....3.E...A. >> 0060 - 07 63 1c 19 53 89 68 a8-0f ea 9e 4c 18 6f 2a ad .c..S.h....L.o*. >> 0070 - 2a df eb 17 a2 08 94 c6-e3 c5 97 ae 0f c1 1a d7 *............... >> 0080 - 0d d7 2e 6d 77 3d 30 a0-07 db 70 35 bb 37 dd 1e ...mw=0...p5.7.. >> 0090 - b6 f3 4d cb 13 97 7c 11-63 98 e8 64 2d a7 e6 cc ..M...|.c..d-... >> 00a0 - 14 03 03 00 01 01 17 03-03 00 27 a3 73 d2 ee 2c ..........'.s.., >> 00b0 - 2f 9c 8f 95 7f ca a3 89-bc b4 b3 b2 3c 8b 23 ef /...........<.#. >> 00c0 - 36 66 23 c9 09 02 33 0d-dc 5d 36 61 44 89 8b ef 6f#...3..]6aD... >> 00d0 - fd 13 17 03 03 00 42 f2-5b 3c 0c 27 5e 7f 97 4f ......B.[<.'^..O >> 00e0 - 0f de 8c b9 0a a1 41 c7-c2 1e 92 99 6a d5 bd 12 ......A.....j... >> 00f0 - 38 b6 b7 93 33 e9 8e 0f-44 93 f0 69 58 b6 41 22 8...3...D..iX.A" >> 0100 - 46 e2 4a d5 d6 32 2b b8-a7 ae 3a c2 c5 2f e6 35 F.J..2+...:../.5 >> 0110 - 11 0c f1 9a 35 2a 87 ed-9e 17 03 03 03 20 a7 e2 ....5*....... .. >> 0120 - fe ba c7 10 5b 9c cd 94-67 19 37 2d 46 59 ab 56 ....[...g.7-FY.V >> 0130 - 6b dd a4 10 61 cc ed f1-71 a7 2d 6a 41 2e 2b da k...a...q.-jA.+. >> 0140 - d1 35 fc 01 df 49 e5 90-1d 9b b2 03 0a 81 58 18 .5...I........X. >> 0150 - 96 a1 db 31 19 98 35 5c-87 8f 6e 32 0a e6 c0 aa ...1..5\..n2.... >> 0160 - 9e 8e 72 e2 34 b3 b7 a3-d6 d1 66 c7 ce 93 fe 78 ..r.4.....f....x >> 0170 - 17 c4 71 7c 42 15 c8 af-dc 4f 50 42 51 80 fc bf ..q|B....OPBQ... >> 0180 - fc 54 d5 d8 59 20 9a 90-c4 78 97 9c 2d 4a d5 58 .T..Y ...x..-J.X >> 0190 - be 81 79 23 59 22 9d 27-f8 bd a0 b2 98 b3 47 82 ..y#Y".'......G. >> 01a0 - d3 52 b5 b5 91 ab 5c 76-52 c5 a5 95 2d 03 1c b7 .R....\vR...-... >> 01b0 - 64 4d 0b 88 7f 15 0b c8-a8 90 50 9a b6 b1 9f b7 dM........P..... >> 01c0 - 40 09 f2 5f 39 f8 9a 06-21 4d 67 10 0a 67 08 b6 @.._9...!Mg..g.. >> 01d0 - b5 9a 25 8c d5 ca 31 6a-8a 6b 01 93 7d 6f 1e 52 ..%...1j.k..}o.R >> 01e0 - 98 96 9d fb e8 c1 07 ab-57 98 2d 1e 75 77 ef c2 ........W.-.uw.. >> 01f0 - 49 78 e0 b9 2b 32 23 7e-95 4d 3e 27 00 61 86 0c Ix..+2#~.M>'.a.. >> 0200 - 47 c7 79 e4 ee 9d ba c0-ea 62 f1 0d 8e 4a 91 30 G.y......b...J.0 >> 0210 - bc 4f 5a 98 26 30 66 ec-c4 63 8f 28 d5 1c 61 23 .OZ.&0f..c.(..a# >> 0220 - ea e9 90 4e 36 d9 fa 31-7b 14 27 22 0a ae 9f 64 ...N6..1{.'"...d >> 0230 - 40 3d e5 a0 5c 9d 3c 04-71 09 b0 7a 6b 51 a0 9c @=..\.<.q..zkQ.. >> 0240 - c0 61 32 ce 15 62 8e 29-b1 59 91 c0 17 2c b3 c5 .a2..b.).Y...,.. >> 0250 - f9 ed 07 65 3d 11 de 98-de 62 36 50 74 37 af 2d ...e=....b6Pt7.- >> 0260 - 7d 86 55 c4 3e a2 83 ab-47 8d f2 b2 8d 1d 75 83 }.U.>...G.....u. >> 0270 - b5 e4 41 87 a7 a3 85 b0-5e 4e 2e 9c 8c b0 1b 83 ..A.....^N...... >> 0280 - 7b 54 79 c9 60 ea 7d ed-06 fa dd 24 40 f1 53 9e {Ty.`.}....$@.S. >> 0290 - 43 79 25 53 9c c7 6e 95-ab 9f 96 59 cd b9 7b a8 Cy%S..n....Y..{. >> 02a0 - a0 23 13 69 db a9 c9 e7-1a 8e e1 9b 54 94 1c 44 .#.i........T..D >> 02b0 - 50 08 8b dd eb 4e 2b bb-d7 c9 c2 33 8c a1 b3 65 P....N+....3...e >> 02c0 - 06 e6 9d ac 11 16 21 58-40 8d 59 e6 67 e5 31 02 ......!X at .Y.g.1. >> 02d0 - 15 8d 29 80 20 66 ba c3-56 93 95 5c 65 4b 41 00 ..). f..V..\eKA. >> 02e0 - c5 71 12 12 f5 20 4f 59-be 77 06 10 6e 48 85 5c .q... OY.w..nH.\ >> 02f0 - ff a2 c4 ae fb 4d 95 f5-cc f6 61 20 33 b7 92 1d .....M....a 3... >> 0300 - ac a8 f1 b2 b0 88 c6 7b-8b 00 53 30 6d 4a d1 42 .......{..S0mJ.B >> 0310 - b3 3e 85 f5 84 e1 c6 ab-10 9d 61 03 46 ff 2d 81 .>........a.F.-. >> 0320 - 15 4f 84 d1 4c ee f4 a6-a0 ec 50 60 a0 d1 ff df .O..L.....P`.... >> 0330 - 8a 97 f6 7d fb 8f fb 60-18 d4 f1 1f 92 4d d8 69 ...}...`.....M.i >> 0340 - b1 92 97 44 0f 3c 8a aa-47 07 48 d4 07 2d 3e f2 ...D.<..G.H..->. >> 0350 - c4 a7 16 35 a7 17 71 ef-98 84 24 67 12 58 30 3b ...5..q...$g.X0; >> 0360 - 1d 41 8d e5 12 52 95 64-e5 88 35 99 d7 c3 58 40 .A...R.d..5...X@ >> 0370 - f9 55 9b 9f e5 33 15 70-41 d7 45 ba a4 fc 75 ea .U...3.pA.E...u. >> 0380 - a4 ae f0 68 ea 64 d8 f5-06 68 a9 75 22 4d 43 cc ...h.d...h.u"MC. >> 0390 - ff 50 cc ac 6e fd 43 dd-eb e4 c8 dd 4b 6c 12 bb .P..n.C.....Kl.. >> 03a0 - f1 d4 5e 11 4a 86 90 0b-f8 3a 2e 23 db 61 5a 1f ..^.J....:.#.aZ. >> 03b0 - 7e 11 00 92 21 68 1f b5-ab f2 f8 38 5e 62 ea f8 ~...!h.....8^b.. >> 03c0 - da ef c2 6e a0 b8 20 e4-69 49 b3 1f 15 84 0b 9b ...n.. .iI...... >> 03d0 - ce b0 6f 36 32 7f 7e bf-e8 d7 18 7a 58 60 f4 04 ..o62.~....zX`.. >> 03e0 - cc 36 bf 06 cd ec e5 9b-19 03 96 09 fb af 8f c3 .6.............. >> 03f0 - 98 b4 02 aa e8 55 81 aa-c4 fe 06 81 30 a0 c7 b2 .....U......0... >> 0400 - f8 e2 30 00 d7 a0 54 7f-5f d7 ef a6 f8 41 58 34 ..0...T._....AX4 >> 0410 - f5 f0 18 69 8d e6 7a 23-78 90 8f b1 05 c5 b5 7f ...i..z#x....... >> 0420 - e0 f2 c7 fa c8 36 5b 53-7e cf e6 75 d3 54 b4 69 .....6[S~..u.T.i >> 0430 - 68 43 0d 6a d2 83 cc 13-6d ca bf 83 3c 90 17 03 hC.j....m...<... >> 0440 - 03 01 19 96 dc 49 26 ce-1d 8e 86 3d bd cb 00 5e .....I&....=...^ >> 0450 - ee f6 e7 1d 16 7a ca ef-fa 6d 16 40 b6 99 d0 c1 .....z...m. at .... >> 0460 - df 0b 5f 51 60 a8 24 e0-61 82 13 40 da 88 38 3a .._Q`.$.a.. at ..8: >> 0470 - 26 1d 80 51 c4 b1 95 35-95 3c 91 35 28 17 49 d8 &..Q...5.<.5(.I. >> 0480 - c3 45 be 32 98 3e 02 07-3b 01 20 2b 51 e1 1a 94 .E.2.>..;. +Q... >> 0490 - b9 be 96 aa 7a 13 09 ff-d5 a9 63 d4 6f 49 cb b5 ....z.....c.oI.. >> 04a0 - 23 ab 7f 8c e2 63 f0 5c-5c 27 1e 04 a8 71 0c c0 #....c.\\'...q.. >> 04b0 - 89 cd ed 18 8d 5b 75 ac-af f3 68 6d cc ba 20 38 .....[u...hm.. 8 >> 04c0 - b5 7c 09 47 29 28 e2 26-57 57 1f f0 f3 18 fd 6f .|.G)(.&WW.....o >> 04d0 - 27 42 a4 e3 de bb e5 d6-09 7d 25 b1 98 97 ad 33 'B.......}%....3 >> 04e0 - 68 35 92 07 80 23 f1 66-20 5d 74 f3 02 c5 51 ff h5...#.f ]t...Q. >> 04f0 - 07 a9 e9 0e 3e 74 da 2e-8f 3b 16 be e6 94 1b 66 ....>t...;.....f >> 0500 - bb b2 a2 1e 7c 7b ff 5e-a4 36 2a ba 0b cd 7f e9 ....|{.^.6*..... >> 0510 - 86 bb 5e 30 f5 57 92 52-82 b6 2e da 71 b7 22 c2 ..^0.W.R....q.". >> 0520 - 90 c4 69 46 07 df 6c 3f-05 8b 19 3e ce b9 75 0d ..iF..l?...>..u. >> 0530 - 4b 97 37 ae 94 e2 d6 3c-91 e6 82 c7 a1 78 79 2c K.7....<.....xy, >> 0540 - 9a a3 d5 45 94 ad e2 c8-ab fd 81 ec 62 87 f7 75 ...E........b..u >> 0550 - e3 70 79 8e 82 3b c5 45-0d d0 33 5f 17 03 03 00 .py..;.E..3_.... >> 0560 - 35 da e0 74 2a 06 41 5a-64 1e 54 94 29 73 43 3f 5..t*.AZd.T.)sC? >> 0570 - e5 24 a8 ba b2 7e 6b 26-82 fc d9 f6 dd 19 05 4a .$...~k&.......J >> 0580 - 2c 1a f3 bb 16 1d 38 95-a6 d3 a8 58 f6 a3 41 c7 ,.....8....X..A. >> 0590 - 92 44 35 24 25 0e .D5$%. >> SSL_accept:SSLv3/TLS write finished >> SSL_accept:TLSv1.3 early data >> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >> 0000 - 14 03 03 00 01 ..... >> read from 0x7fdc58809fb0 [0x7fdc5901da08] (1 bytes => 1 (0x1)) >> 0000 - 01 . >> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >> 0000 - 17 03 03 00 3d ....= >> read from 0x7fdc58809fb0 [0x7fdc5901da08] (61 bytes => 61 (0x3D)) >> 0000 - ad dd 3e d9 ee ab 56 65-50 1c 72 2a d8 62 7f 90 ..>...VeP.r*.b.. >> 0010 - 13 71 7d 37 39 40 fb 89-8f 05 4b 39 44 9d 4d 67 .q}79 at ....K9D.Mg >> 0020 - e3 41 29 b6 3e e8 fe 04-1b 8e eb 7a 4c e2 14 a0 .A).>......zL... >> 0030 - b1 c2 47 3f 94 35 ed ab-8a d1 75 3b ba ..G?.5....u;. >> SSL_accept:TLSv1.3 early data >> SSL_accept:SSLv3/TLS read client certificate >> SSL_accept:SSLv3/TLS read finished >> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >> 0000 - 17 03 03 00 da 52 1f 48-00 f4 31 13 90 7f 9c c2 .....R.H..1..... >> 0010 - fc 70 1a fc f7 4a 48 e7-31 ad 37 ab b5 2b 4e 5c .p...JH.1.7..+N\ >> 0020 - e8 d8 6d e9 af 6c 4f c1-9e 7b ea ff ef b3 eb 74 ..m..lO..{.....t >> 0030 - 27 67 10 21 66 5b 32 13-31 bc 99 d5 1c 6c 79 55 'g.!f[2.1....lyU >> 0040 - f3 3e f6 4b 07 4d a9 78-3d 12 8a f5 38 ef d9 f4 .>.K.M.x=...8... >> 0050 - 48 e0 2c 35 94 06 4f eb-09 e6 70 fb 59 95 7a c8 H.,5..O...p.Y.z. >> 0060 - 24 dd 24 e2 f9 63 b9 3c-f2 66 86 c4 73 44 53 fd $.$..c.<.f..sDS. >> 0070 - ca 67 8f 01 d6 db 70 f9-60 bc 50 11 51 72 dc 63 .g....p.`.P.Qr.c >> 0080 - 12 ca 4f 23 e2 c5 d1 1d-e5 b0 d4 ec 89 ca 28 be ..O#..........(. >> 0090 - 9c 30 83 40 02 a4 62 a8-5c b3 20 1a ab 39 b7 7b .0. at ..b.\. ..9.{ >> 00a0 - 89 13 39 87 73 be a8 f8-60 13 31 0a 48 5c 79 b9 ..9.s...`.1.H\y. >> 00b0 - cc 4a 51 e3 0d d2 b4 93-c0 1f 3a 22 b3 fa 24 a0 .JQ.......:"..$. >> 00c0 - 7c f6 76 79 d0 2d 5b 1a-ff a6 e9 e1 40 d3 b1 8c |.vy.-[..... at ... >> 00d0 - 0a fa fa de f3 8e d6 ad-9a 22 6b 67 0b 88 18 ........."kg... >> SSL_accept:SSLv3/TLS write session ticket >> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >> 0000 - 17 03 03 00 da 46 aa ea-6a 37 b1 35 e8 41 c8 b3 .....F..j7.5.A.. >> 0010 - 84 25 af 1c 36 a3 6d 78-a4 44 4a 83 52 ef 13 7c .%..6.mx.DJ.R..| >> 0020 - 8f 18 d3 4c f8 22 c8 b3-ad d0 d0 5b 47 a0 43 da ...L.".....[G.C. >> 0030 - d2 6e 04 8f dc c9 56 90-58 87 62 63 4c cc 31 ec .n....V.X.bcL.1. >> 0040 - b8 c9 18 be 41 32 e1 3c-00 41 2a f1 4d 5c 2d 44 ....A2.<.A*.M\-D >> 0050 - 8c aa e1 f0 ed 38 ee 44-64 e5 fd ea 58 3b 84 5d .....8.Dd...X;.] >> 0060 - 83 39 21 2e fe 79 4d 76-10 65 87 0f 3c ac df 28 .9!..yMv.e..<..( >> 0070 - 49 f8 60 eb be 49 e4 0a-0b 6a 03 2b 9d cf 9b a5 I.`..I...j.+.... >> 0080 - 03 56 58 32 c2 b2 59 f9-0a 0d f0 ae af ff 20 19 .VX2..Y....... . >> 0090 - e5 6e e4 86 2f 5e 3f 7d-47 d5 73 ae 89 48 a7 66 .n../^?}G.s..H.f >> 00a0 - fb 2d 83 60 e8 8b ab 27-12 db 24 78 54 eb 14 2d .-.`...'..$xT..- >> 00b0 - b7 c6 17 2d 3c 91 57 ac-6e 35 b8 c3 fa c2 42 48 ...-<.W.n5....BH >> 00c0 - 2a cb aa 98 32 89 8a ce-0c f7 cd 5e fb bf 6d 33 *...2......^..m3 >> 00d0 - 08 50 cf 1e 06 bb a1 98-be a4 a9 51 9a b0 34 .P.........Q..4 >> SSL_accept:SSLv3/TLS write session ticket >> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >> 0000 - 17 03 03 00 12 c5 9b 73-cc 91 7e 48 cb 25 31 a0 .......s..~H.%1. >> 0010 - 67 41 db bb 0f 62 d8 gA...b. >> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >> 0000 - 17 03 03 00 12 0f dd 3f-c1 7c e6 b0 cc ea f0 13 .......?.|...... >> 0010 - 00 d8 01 de ef 7c bb .....|. >> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >> 0000 - 17 03 03 00 1e ..... >> read from 0x7fdc58809fb0 [0x7fdc5901da08] (30 bytes => 30 (0x1E)) >> 0000 - d6 88 44 82 cb 23 16 ba-c9 a4 fb 55 51 08 90 c1 ..D..#.....UQ... >> 0010 - bf bd a1 7f 0e 37 b0 b4-b5 df f1 07 6c 07 .....7......l. >> I am a clientwrite to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >> 0000 - 17 03 03 00 12 c0 70 5d-14 e7 69 57 0a d8 64 16 ......p]..iW..d. >> 0010 - 0c 90 06 0f c3 4d 1d .....M. >> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >> 0000 - 17 03 03 00 13 ..... >> read from 0x7fdc58809fb0 [0x7fdc5901da08] (19 bytes => 19 (0x13)) >> 0000 - 60 28 5b ff bb 0d 9f 96-9a 2d cb fd 60 eb 96 62 `([......-..`..b >> 0010 - 53 e6 25 S.% >> SSL3 alert read:warning:close notify >> DONE >> shutting down SSL >> CONNECTION CLOSED >> >> >> I am using the following JDK version on MacOS: >> >> ssl git:(cert_cb_openssl_1_1_1) ? /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java -version >> java version "11" 2018-09-25 >> Java(TM) SE Runtime Environment 18.9 (build 11+28) >> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) >> >> For this to work you will need to have openssl 1.1.1 installed. >> >> Any help would be welcome, >> Norman >> >> [1] https://github.com/netty/netty-tcnative >> >> >> From norman.maurer at googlemail.com Sat Sep 15 06:18:34 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Sat, 15 Sep 2018 08:18:34 +0200 Subject: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: <32bad254-1a8c-7933-d5a0-0b8ce3ed2f68@oracle.com> References: <32bad254-1a8c-7933-d5a0-0b8ce3ed2f68@oracle.com> Message-ID: <05EF82F5-6506-4928-8030-B9BEEE64E1F1@googlemail.com> 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)) >>> 0000 - 16 03 03 01 60 ....` >>> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160)) >>> 0000 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 ...\..".... at 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..o....K...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)) >>> 0000 - 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|J....n....] >>> 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..o....K.. >>> 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 MT....B5S[...... >>> 00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65 .(.m...8.wrs%&.e >>> 00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96 X........P...... >>> 0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9 .;<..AX...:(..a. >>> 0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5 .h...f.[..... .. >>> 0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb .RD...c=........ >>> 0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6 .*O[J.wx.u. .... >>> 0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee ...VV._.e.~n=.f. >>> 0150 - 10 4c f7 6d 9b 73 86 14-7a 81 f8 b1 27 af 08 ee .L.m.s..z...'... >>> 0160 - ce 26 90 34 73 3d b7 45-8d 85 29 a8 65 19 e7 02 .&.4s=.E..).e... >>> 0170 - e5 55 4a 27 f1 b1 6a a4-11 cc 6c af 78 6d 22 5c .UJ'..j...l.xm"\ >>> 0180 - 33 73 e3 ad 7f 8d 1b d3-75 95 66 64 2d 0e f1 3e 3s......u.fd-..> >>> 0190 - c2 30 df a1 7e ce a3 50-c3 4e 68 f6 36 b3 4e 45 .0..~..P.Nh.6.NE >>> 01a0 - 9c ac e9 f2 0d 7c e3 73-6a 40 ab 6e 6e f9 d8 20 .....|.sj at .nn.. >>> 01b0 - 9c f3 04 32 cd 1d df 18-e5 4d e3 e8 b1 38 59 f8 ...2.....M...8Y. >>> 01c0 - 28 67 2e ca af a2 8b 88-ce ca 48 a6 07 2b a6 9a (g........H..+.. >>> 01d0 - 0e 88 5b d7 0b d9 31 77-97 8d 6c 2b f5 60 24 61 ..[...1w..l+.`$a >>> 01e0 - a8 5c 47 5d 7c 66 f0 9b-1f e4 76 93 38 f6 78 3e .\G]|f....v.8.x> >>> 01f0 - 69 29 72 f9 d9 4b cb 05-03 e4 f2 d6 24 e1 91 ee i)r..K......$... >>> 0200 - 85 37 d7 7b c3 5c 35 90-08 cd b1 cc 76 11 fc 00 .7.{.\5.....v... >>> 0210 - 12 7e 89 7b 70 e6 ca fe-0b 26 b6 bb ac fe 4b 9f .~.{p....&....K. >>> 0220 - ec cf 41 69 42 3a 3e 41-f9 b0 c0 93 5b 70 1f c7 ..AiB:>A....[p.. >>> 0230 - 11 00 3d ec 66 5a 1a ca-31 89 22 27 02 dd a0 cb ..=.fZ..1."'.... >>> 0240 - 39 14 25 ee 30 44 e8 62-97 bf 8e 16 63 40 c4 11 9.%.0D.b....c at .. >>> 0250 - a6 d9 32 b1 3c 86 35 bb-9f f1 4d 71 9f a5 4f 78 ..2.<.5...Mq..Ox >>> 0260 - 0a e8 96 dd 4d 10 c3 48-f2 db 67 57 2d cd dc 23 ....M..H..gW-..# >>> 0270 - 3a 8d 6a 61 47 20 ff c8-33 cd e9 f7 47 4c 68 4f :.jaG ..3...GLhO >>> 0280 - 19 2f 8b e3 b1 90 ac 66-a7 cf 5c e6 d2 05 21 25 ./.....f..\...!% >>> 0290 - d2 d8 f0 43 8c 55 01 ef-d6 8f c0 27 87 0d 21 d5 ...C.U.....'..!. >>> 02a0 - 2b 2b 6f db e8 85 ea cd-6e 9c 5d 56 d5 31 c1 f2 ++o.....n.]V.1.. >>> 02b0 - 97 2f 5a 83 7a 2b 71 03-65 e0 b6 4a 56 37 de e1 ./Z.z+q.e..JV7.. >>> 02c0 - 80 3a c4 cc 5a ac 3b 9a-7a bf f7 6b fe a8 69 e9 .:..Z.;.z..k..i. >>> 02d0 - 58 09 59 bd 46 bd d2 a3-bc ad 1c 10 53 c8 29 7b X.Y.F.......S.){ >>> 02e0 - be 63 00 d6 e5 a8 d6 ab-b2 bc 8b e1 2c 0e 24 2a .c..........,.$* >>> 02f0 - c2 31 2d d8 6e 1f 19 93-d7 54 e1 1e 28 ce 72 83 .1-.n....T..(.r. >>> 0300 - ff 05 18 f2 fc e9 0c b3-0c 1b d5 96 c2 d8 fc 76 ...............v >>> 0310 - 37 a9 5a ef 8e e9 b6 71-21 f3 bd c1 85 23 85 22 7.Z....q!....#." >>> 0320 - 3d c4 1c c9 31 8b 7e 00-8f 8e b4 9f 05 d4 80 6b =...1.~........k >>> 0330 - 98 4c a8 82 68 ff 1a a5-28 e2 9b 03 a1 a7 b1 00 .L..h...(....... >>> 0340 - 02 2b 2d e2 e1 87 8c e8-0a fb 0b 79 54 ca 3d d5 .+-........yT.=. >>> 0350 - 6a dd b7 b7 87 42 2b 47-49 da e9 0a 82 0a c9 8f j....B+GI....... >>> 0360 - 57 f7 1e 03 ca 8d 16 bc-21 3a 6a ee b9 b8 fa f0 W.......!:j..... >>> 0370 - d9 18 35 9f 35 ac d8 6e-9a 8a 0d 56 10 1e 1f 5a ..5.5..n...V...Z >>> 0380 - ba ec e4 fe 1a 92 b4 31-35 43 1d 99 b9 12 fa ff .......15C...... >>> 0390 - 99 2b 88 e0 58 ec 9c dc-8f 67 ef 2a c2 e2 64 5d .+..X....g.*..d] >>> 03a0 - 66 76 1c d0 aa 00 30 59-b1 f5 b1 55 9f ad 60 e9 fv....0Y...U..`. >>> 03b0 - 3d 03 1e d0 8b 4d bf 74-ac bc bb 1c 83 14 c5 e0 =....M.t........ >>> 03c0 - f4 fc 70 9e f4 22 a0 78-04 fe c8 b1 17 65 f6 94 ..p..".x.....e.. >>> 03d0 - 47 82 50 4a b6 32 74 ae-5b 38 5a 2e d9 b0 6a 45 G.PJ.2t.[8Z...jE >>> 03e0 - 74 e8 f0 22 fe d3 b0 11-c3 fd 72 4f da 77 7a ba t.."......rO.wz. >>> 03f0 - 26 3e 61 0c 63 21 17 a6-b2 13 6e 71 5c f2 0d ad &>a.c!....nq\... >>> 0400 - f2 d1 19 71 51 9e a4 1b-b0 30 24 e0 71 7d 87 80 ...qQ....0$.q}.. >>> 0410 - a9 5a e9 bc db e4 4f 50-4d a1 bc bc 2c 4b 66 98 .Z....OPM...,Kf. >>> 0420 - d4 e4 b0 76 0f d2 db a5-a5 39 9e f2 5b ea 34 c1 ...v.....9..[.4. >>> 0430 - 62 ab 47 51 3b 37 17 45-54 31 18 f3 f1 ca 17 03 b.GQ;7.ET1...... >>> 0440 - 03 01 19 dd 50 50 f5 0c-f2 c9 3c b4 8f 63 cc 4a ....PP....<..c.J >>> 0450 - a7 50 c9 91 9b 79 9a 2a-5c 47 d3 77 f6 56 69 90 .P...y.*\G.w.Vi. >>> 0460 - 98 cd ff bd c1 2a 49 fc-0d d4 7e cc 7e 44 af c4 .....*I...~.~D.. >>> 0470 - 61 47 e0 c1 76 b1 8c 2e-df 7e d0 82 e1 89 1f 04 aG..v....~...... >>> 0480 - ae 64 bd 71 4d ae 1c 3c-e3 d3 39 5d 61 2a ea 70 .d.qM..<..9]a*.p >>> 0490 - 8c 31 6d a0 b1 72 a8 7a-5c 9c 11 08 b8 4d a5 c4 .1m..r.z\....M.. >>> 04a0 - ad 1b 38 4a 6a 02 28 d4-d1 0f c8 9f 0b b3 02 18 ..8Jj.(......... >>> 04b0 - 82 2b bd 46 82 04 64 f0-41 b2 da f5 cd 9c f7 f3 .+.F..d.A....... >>> 04c0 - 73 30 58 ca 12 ec ea 90-85 1c 75 09 0a 70 b8 80 s0X.......u..p.. >>> 04d0 - 3d 02 17 3e 9b 83 04 b5-dd 9e e6 18 17 65 83 a5 =..>.........e.. >>> 04e0 - 59 7d 4b 98 da bd 8b aa-d6 aa c5 1c 7d 87 56 e3 Y}K.........}.V. >>> 04f0 - 74 d8 e9 7b eb b3 3d f7-7c 3c 0a e9 a8 2e 04 0d t..{..=.|<...... >>> 0500 - 6a e7 83 e0 ec 99 43 6a-8b 1c 73 59 7a c8 cd 6e j.....Cj..sYz..n >>> 0510 - 4a 14 73 ff 9a fb 71 94-d5 50 a9 d9 e0 dd 02 4c J.s...q..P.....L >>> 0520 - 2b 67 9e da 9e fa 2d 67-49 df 13 10 ed 35 3e 73 +g....-gI....5>s >>> 0530 - 07 20 17 fb 0b ef f6 d0-b7 68 1c 65 21 a6 e3 3b . .......h.e!..; >>> 0540 - bf 7b 84 cd 9e f5 76 2a-0d 4f b8 c3 c8 15 08 e9 .{....v*.O...... >>> 0550 - 0f 3c 50 49 12 97 a8 d7-f1 a3 16 da 17 03 03 00 .>> 0560 - 35 22 dd a2 9d 25 98 2c-35 b8 00 29 fa a1 dd ba 5"...%.,5..).... >>> 0570 - 72 b9 fe e5 85 85 f0 f1-3b 4e f5 7c 58 c8 2a da r.......;N.|X.*. >>> 0580 - d2 75 94 3b c1 7a 7c 7e-db 5b fe 8a 2d 3f 8c 9a .u.;.z|~.[..-?.. >>> 0590 - 6e 79 ab 2b ff 1a ny.+.. >>> SSL_accept:SSLv3/TLS write finished >>> SSL_accept:TLSv1.3 early data >>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>> 0000 - 14 03 03 00 01 ..... >>> read from 0x7fe400f050c0 [0x7fe40300f608] (1 bytes => 1 (0x1)) >>> 0000 - 01 . >>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>> 0000 - 17 03 03 00 3d ....= >>> read from 0x7fe400f050c0 [0x7fe40300f608] (61 bytes => 61 (0x3D)) >>> 0000 - 38 e7 bb 2c 5b af b6 5f-37 d8 3e 7e bb f4 04 f5 8..,[.._7.>~.... >>> 0010 - e1 28 b5 e5 07 5a ec ce-da 2f f3 b6 45 61 cf ef .(...Z.../..Ea.. >>> 0020 - 90 fb 57 b8 f3 20 45 27-60 d4 26 51 38 77 e4 bc ..W.. E'`.&Q8w.. >>> 0030 - b7 64 d4 8b 73 25 41 9e-fe d3 9d 5f 53 .d..s%A...._S >>> SSL_accept:TLSv1.3 early data >>> write to 0x7fe400f050c0 [0x7fe403018a00] (24 bytes => 24 (0x18)) >>> 0000 - 17 03 03 00 13 25 85 60-eb 7d c1 a8 15 49 d5 63 .....%.`.}...I.c >>> 0010 - 18 7f c6 ac ed 7f df 77- .......w >>> SSL3 alert write:fatal:unknown >>> SSL_accept:error in error >>> ERROR >>> 140736092021632:error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate:ssl/statem/statem_srvr.c:3654: >>> shutting down SSL >>> CONNECTION CLOSED >>> >>> >>> >>> When using openssl s_client all works as expected tho (thats also true if I use my native implementation on the client and server side that uses openssl): >>> >>> ./bin/openssl s_client -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 -state -tls1_3 -connect localhost:8443 >>> >>> The interesting thing is if I use ?-verify 1? and not ?-Verify 1? with openssl which tells it I want to request a certificate but will also process if none is provided I receive the certificate at some point as seen here: >>> >>> SSL_accept:before SSL initialization >>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>> 0000 - 16 03 03 01 60 ....` >>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (352 bytes => 352 (0x160)) >>> 0000 - 01 00 01 5c 03 03 61 c0-b3 ed 88 65 e6 cf 11 3f ...\..a....e...? >>> 0010 - c0 e0 f8 df a6 63 32 c2-ab 3d 61 6f 41 ed b1 4b .....c2..=aoA..K >>> 0020 - 53 0e 83 e5 a1 b8 20 c7-1b 8c b8 e6 b5 da 4e 4e S..... .......NN >>> 0030 - 3f 3c 61 7a ad 58 23 94-a7 32 79 2f db 9f 21 c0 ?>> 0040 - 8e 0c c5 ce b1 c2 a4 00-14 c0 2c c0 2b c0 2f c0 ..........,.+./. >>> 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 52 dc d6 47 6e .3.G.E...A.R..Gn >>> 0120 - a1 de 9c 71 c2 54 0e 5c-9b 57 fb c8 aa 3f 19 f7 ...q.T.\.W...?.. >>> 0130 - d3 a4 25 12 fa 3f 6c 6d-95 30 66 ca 63 b7 a1 dd ..%..?lm.0f.c... >>> 0140 - ae 9f 99 d6 a8 6b 20 4f-29 7a 74 58 ad 58 de 12 .....k O)ztX.X.. >>> 0150 - d7 a5 9b 69 dc 27 ac ec-9e d4 04 ff 01 00 01 00 ...i.'.......... >>> 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 0x7fdc58809fb0 [0x7fdc59025e00] (1430 bytes => 1430 (0x596)) >>> 0000 - 16 03 03 00 9b 02 00 00-97 03 03 8b c8 62 48 6c .............bHl >>> 0010 - f5 7c 73 d9 17 f8 63 a2-11 27 40 93 09 26 53 06 .|s...c..'@..&S. >>> 0020 - b3 62 df 46 26 b6 dc 59-29 b5 58 20 c7 1b 8c b8 .b.F&..Y).X .... >>> 0030 - e6 b5 da 4e 4e 3f 3c 61-7a ad 58 23 94 a7 32 79 ...NN?>> 0040 - 2f db 9f 21 c0 8e 0c c5-ce b1 c2 a4 13 01 00 00 /..!............ >>> 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 O.+.....3.E...A. >>> 0060 - 07 63 1c 19 53 89 68 a8-0f ea 9e 4c 18 6f 2a ad .c..S.h....L.o*. >>> 0070 - 2a df eb 17 a2 08 94 c6-e3 c5 97 ae 0f c1 1a d7 *............... >>> 0080 - 0d d7 2e 6d 77 3d 30 a0-07 db 70 35 bb 37 dd 1e ...mw=0...p5.7.. >>> 0090 - b6 f3 4d cb 13 97 7c 11-63 98 e8 64 2d a7 e6 cc ..M...|.c..d-... >>> 00a0 - 14 03 03 00 01 01 17 03-03 00 27 a3 73 d2 ee 2c ..........'.s.., >>> 00b0 - 2f 9c 8f 95 7f ca a3 89-bc b4 b3 b2 3c 8b 23 ef /...........<.#. >>> 00c0 - 36 66 23 c9 09 02 33 0d-dc 5d 36 61 44 89 8b ef 6f#...3..]6aD... >>> 00d0 - fd 13 17 03 03 00 42 f2-5b 3c 0c 27 5e 7f 97 4f ......B.[<.'^..O >>> 00e0 - 0f de 8c b9 0a a1 41 c7-c2 1e 92 99 6a d5 bd 12 ......A.....j... >>> 00f0 - 38 b6 b7 93 33 e9 8e 0f-44 93 f0 69 58 b6 41 22 8...3...D..iX.A" >>> 0100 - 46 e2 4a d5 d6 32 2b b8-a7 ae 3a c2 c5 2f e6 35 F.J..2+...:../.5 >>> 0110 - 11 0c f1 9a 35 2a 87 ed-9e 17 03 03 03 20 a7 e2 ....5*....... .. >>> 0120 - fe ba c7 10 5b 9c cd 94-67 19 37 2d 46 59 ab 56 ....[...g.7-FY.V >>> 0130 - 6b dd a4 10 61 cc ed f1-71 a7 2d 6a 41 2e 2b da k...a...q.-jA.+. >>> 0140 - d1 35 fc 01 df 49 e5 90-1d 9b b2 03 0a 81 58 18 .5...I........X. >>> 0150 - 96 a1 db 31 19 98 35 5c-87 8f 6e 32 0a e6 c0 aa ...1..5\..n2.... >>> 0160 - 9e 8e 72 e2 34 b3 b7 a3-d6 d1 66 c7 ce 93 fe 78 ..r.4.....f....x >>> 0170 - 17 c4 71 7c 42 15 c8 af-dc 4f 50 42 51 80 fc bf ..q|B....OPBQ... >>> 0180 - fc 54 d5 d8 59 20 9a 90-c4 78 97 9c 2d 4a d5 58 .T..Y ...x..-J.X >>> 0190 - be 81 79 23 59 22 9d 27-f8 bd a0 b2 98 b3 47 82 ..y#Y".'......G. >>> 01a0 - d3 52 b5 b5 91 ab 5c 76-52 c5 a5 95 2d 03 1c b7 .R....\vR...-... >>> 01b0 - 64 4d 0b 88 7f 15 0b c8-a8 90 50 9a b6 b1 9f b7 dM........P..... >>> 01c0 - 40 09 f2 5f 39 f8 9a 06-21 4d 67 10 0a 67 08 b6 @.._9...!Mg..g.. >>> 01d0 - b5 9a 25 8c d5 ca 31 6a-8a 6b 01 93 7d 6f 1e 52 ..%...1j.k..}o.R >>> 01e0 - 98 96 9d fb e8 c1 07 ab-57 98 2d 1e 75 77 ef c2 ........W.-.uw.. >>> 01f0 - 49 78 e0 b9 2b 32 23 7e-95 4d 3e 27 00 61 86 0c Ix..+2#~.M>'.a.. >>> 0200 - 47 c7 79 e4 ee 9d ba c0-ea 62 f1 0d 8e 4a 91 30 G.y......b...J.0 >>> 0210 - bc 4f 5a 98 26 30 66 ec-c4 63 8f 28 d5 1c 61 23 .OZ.&0f..c.(..a# >>> 0220 - ea e9 90 4e 36 d9 fa 31-7b 14 27 22 0a ae 9f 64 ...N6..1{.'"...d >>> 0230 - 40 3d e5 a0 5c 9d 3c 04-71 09 b0 7a 6b 51 a0 9c @=..\.<.q..zkQ.. >>> 0240 - c0 61 32 ce 15 62 8e 29-b1 59 91 c0 17 2c b3 c5 .a2..b.).Y...,.. >>> 0250 - f9 ed 07 65 3d 11 de 98-de 62 36 50 74 37 af 2d ...e=....b6Pt7.- >>> 0260 - 7d 86 55 c4 3e a2 83 ab-47 8d f2 b2 8d 1d 75 83 }.U.>...G.....u. >>> 0270 - b5 e4 41 87 a7 a3 85 b0-5e 4e 2e 9c 8c b0 1b 83 ..A.....^N...... >>> 0280 - 7b 54 79 c9 60 ea 7d ed-06 fa dd 24 40 f1 53 9e {Ty.`.}....$@.S. >>> 0290 - 43 79 25 53 9c c7 6e 95-ab 9f 96 59 cd b9 7b a8 Cy%S..n....Y..{. >>> 02a0 - a0 23 13 69 db a9 c9 e7-1a 8e e1 9b 54 94 1c 44 .#.i........T..D >>> 02b0 - 50 08 8b dd eb 4e 2b bb-d7 c9 c2 33 8c a1 b3 65 P....N+....3...e >>> 02c0 - 06 e6 9d ac 11 16 21 58-40 8d 59 e6 67 e5 31 02 ......!X at .Y.g.1. >>> 02d0 - 15 8d 29 80 20 66 ba c3-56 93 95 5c 65 4b 41 00 ..). f..V..\eKA. >>> 02e0 - c5 71 12 12 f5 20 4f 59-be 77 06 10 6e 48 85 5c .q... OY.w..nH.\ >>> 02f0 - ff a2 c4 ae fb 4d 95 f5-cc f6 61 20 33 b7 92 1d .....M....a 3... >>> 0300 - ac a8 f1 b2 b0 88 c6 7b-8b 00 53 30 6d 4a d1 42 .......{..S0mJ.B >>> 0310 - b3 3e 85 f5 84 e1 c6 ab-10 9d 61 03 46 ff 2d 81 .>........a.F.-. >>> 0320 - 15 4f 84 d1 4c ee f4 a6-a0 ec 50 60 a0 d1 ff df .O..L.....P`.... >>> 0330 - 8a 97 f6 7d fb 8f fb 60-18 d4 f1 1f 92 4d d8 69 ...}...`.....M.i >>> 0340 - b1 92 97 44 0f 3c 8a aa-47 07 48 d4 07 2d 3e f2 ...D.<..G.H..->. >>> 0350 - c4 a7 16 35 a7 17 71 ef-98 84 24 67 12 58 30 3b ...5..q...$g.X0; >>> 0360 - 1d 41 8d e5 12 52 95 64-e5 88 35 99 d7 c3 58 40 .A...R.d..5...X@ >>> 0370 - f9 55 9b 9f e5 33 15 70-41 d7 45 ba a4 fc 75 ea .U...3.pA.E...u. >>> 0380 - a4 ae f0 68 ea 64 d8 f5-06 68 a9 75 22 4d 43 cc ...h.d...h.u"MC. >>> 0390 - ff 50 cc ac 6e fd 43 dd-eb e4 c8 dd 4b 6c 12 bb .P..n.C.....Kl.. >>> 03a0 - f1 d4 5e 11 4a 86 90 0b-f8 3a 2e 23 db 61 5a 1f ..^.J....:.#.aZ. >>> 03b0 - 7e 11 00 92 21 68 1f b5-ab f2 f8 38 5e 62 ea f8 ~...!h.....8^b.. >>> 03c0 - da ef c2 6e a0 b8 20 e4-69 49 b3 1f 15 84 0b 9b ...n.. .iI...... >>> 03d0 - ce b0 6f 36 32 7f 7e bf-e8 d7 18 7a 58 60 f4 04 ..o62.~....zX`.. >>> 03e0 - cc 36 bf 06 cd ec e5 9b-19 03 96 09 fb af 8f c3 .6.............. >>> 03f0 - 98 b4 02 aa e8 55 81 aa-c4 fe 06 81 30 a0 c7 b2 .....U......0... >>> 0400 - f8 e2 30 00 d7 a0 54 7f-5f d7 ef a6 f8 41 58 34 ..0...T._....AX4 >>> 0410 - f5 f0 18 69 8d e6 7a 23-78 90 8f b1 05 c5 b5 7f ...i..z#x....... >>> 0420 - e0 f2 c7 fa c8 36 5b 53-7e cf e6 75 d3 54 b4 69 .....6[S~..u.T.i >>> 0430 - 68 43 0d 6a d2 83 cc 13-6d ca bf 83 3c 90 17 03 hC.j....m...<... >>> 0440 - 03 01 19 96 dc 49 26 ce-1d 8e 86 3d bd cb 00 5e .....I&....=...^ >>> 0450 - ee f6 e7 1d 16 7a ca ef-fa 6d 16 40 b6 99 d0 c1 .....z...m. at .... >>> 0460 - df 0b 5f 51 60 a8 24 e0-61 82 13 40 da 88 38 3a .._Q`.$.a.. at ..8: >>> 0470 - 26 1d 80 51 c4 b1 95 35-95 3c 91 35 28 17 49 d8 &..Q...5.<.5(.I. >>> 0480 - c3 45 be 32 98 3e 02 07-3b 01 20 2b 51 e1 1a 94 .E.2.>..;. +Q... >>> 0490 - b9 be 96 aa 7a 13 09 ff-d5 a9 63 d4 6f 49 cb b5 ....z.....c.oI.. >>> 04a0 - 23 ab 7f 8c e2 63 f0 5c-5c 27 1e 04 a8 71 0c c0 #....c.\\'...q.. >>> 04b0 - 89 cd ed 18 8d 5b 75 ac-af f3 68 6d cc ba 20 38 .....[u...hm.. 8 >>> 04c0 - b5 7c 09 47 29 28 e2 26-57 57 1f f0 f3 18 fd 6f .|.G)(.&WW.....o >>> 04d0 - 27 42 a4 e3 de bb e5 d6-09 7d 25 b1 98 97 ad 33 'B.......}%....3 >>> 04e0 - 68 35 92 07 80 23 f1 66-20 5d 74 f3 02 c5 51 ff h5...#.f ]t...Q. >>> 04f0 - 07 a9 e9 0e 3e 74 da 2e-8f 3b 16 be e6 94 1b 66 ....>t...;.....f >>> 0500 - bb b2 a2 1e 7c 7b ff 5e-a4 36 2a ba 0b cd 7f e9 ....|{.^.6*..... >>> 0510 - 86 bb 5e 30 f5 57 92 52-82 b6 2e da 71 b7 22 c2 ..^0.W.R....q.". >>> 0520 - 90 c4 69 46 07 df 6c 3f-05 8b 19 3e ce b9 75 0d ..iF..l?...>..u. >>> 0530 - 4b 97 37 ae 94 e2 d6 3c-91 e6 82 c7 a1 78 79 2c K.7....<.....xy, >>> 0540 - 9a a3 d5 45 94 ad e2 c8-ab fd 81 ec 62 87 f7 75 ...E........b..u >>> 0550 - e3 70 79 8e 82 3b c5 45-0d d0 33 5f 17 03 03 00 .py..;.E..3_.... >>> 0560 - 35 da e0 74 2a 06 41 5a-64 1e 54 94 29 73 43 3f 5..t*.AZd.T.)sC? >>> 0570 - e5 24 a8 ba b2 7e 6b 26-82 fc d9 f6 dd 19 05 4a .$...~k&.......J >>> 0580 - 2c 1a f3 bb 16 1d 38 95-a6 d3 a8 58 f6 a3 41 c7 ,.....8....X..A. >>> 0590 - 92 44 35 24 25 0e .D5$%. >>> SSL_accept:SSLv3/TLS write finished >>> SSL_accept:TLSv1.3 early data >>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>> 0000 - 14 03 03 00 01 ..... >>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (1 bytes => 1 (0x1)) >>> 0000 - 01 . >>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>> 0000 - 17 03 03 00 3d ....= >>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (61 bytes => 61 (0x3D)) >>> 0000 - ad dd 3e d9 ee ab 56 65-50 1c 72 2a d8 62 7f 90 ..>...VeP.r*.b.. >>> 0010 - 13 71 7d 37 39 40 fb 89-8f 05 4b 39 44 9d 4d 67 .q}79 at ....K9D.Mg >>> 0020 - e3 41 29 b6 3e e8 fe 04-1b 8e eb 7a 4c e2 14 a0 .A).>......zL... >>> 0030 - b1 c2 47 3f 94 35 ed ab-8a d1 75 3b ba ..G?.5....u;. >>> SSL_accept:TLSv1.3 early data >>> SSL_accept:SSLv3/TLS read client certificate >>> SSL_accept:SSLv3/TLS read finished >>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>> 0000 - 17 03 03 00 da 52 1f 48-00 f4 31 13 90 7f 9c c2 .....R.H..1..... >>> 0010 - fc 70 1a fc f7 4a 48 e7-31 ad 37 ab b5 2b 4e 5c .p...JH.1.7..+N\ >>> 0020 - e8 d8 6d e9 af 6c 4f c1-9e 7b ea ff ef b3 eb 74 ..m..lO..{.....t >>> 0030 - 27 67 10 21 66 5b 32 13-31 bc 99 d5 1c 6c 79 55 'g.!f[2.1....lyU >>> 0040 - f3 3e f6 4b 07 4d a9 78-3d 12 8a f5 38 ef d9 f4 .>.K.M.x=...8... >>> 0050 - 48 e0 2c 35 94 06 4f eb-09 e6 70 fb 59 95 7a c8 H.,5..O...p.Y.z. >>> 0060 - 24 dd 24 e2 f9 63 b9 3c-f2 66 86 c4 73 44 53 fd $.$..c.<.f..sDS. >>> 0070 - ca 67 8f 01 d6 db 70 f9-60 bc 50 11 51 72 dc 63 .g....p.`.P.Qr.c >>> 0080 - 12 ca 4f 23 e2 c5 d1 1d-e5 b0 d4 ec 89 ca 28 be ..O#..........(. >>> 0090 - 9c 30 83 40 02 a4 62 a8-5c b3 20 1a ab 39 b7 7b .0. at ..b.\. ..9.{ >>> 00a0 - 89 13 39 87 73 be a8 f8-60 13 31 0a 48 5c 79 b9 ..9.s...`.1.H\y. >>> 00b0 - cc 4a 51 e3 0d d2 b4 93-c0 1f 3a 22 b3 fa 24 a0 .JQ.......:"..$. >>> 00c0 - 7c f6 76 79 d0 2d 5b 1a-ff a6 e9 e1 40 d3 b1 8c |.vy.-[..... at ... >>> 00d0 - 0a fa fa de f3 8e d6 ad-9a 22 6b 67 0b 88 18 ........."kg... >>> SSL_accept:SSLv3/TLS write session ticket >>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>> 0000 - 17 03 03 00 da 46 aa ea-6a 37 b1 35 e8 41 c8 b3 .....F..j7.5.A.. >>> 0010 - 84 25 af 1c 36 a3 6d 78-a4 44 4a 83 52 ef 13 7c .%..6.mx.DJ.R..| >>> 0020 - 8f 18 d3 4c f8 22 c8 b3-ad d0 d0 5b 47 a0 43 da ...L.".....[G.C. >>> 0030 - d2 6e 04 8f dc c9 56 90-58 87 62 63 4c cc 31 ec .n....V.X.bcL.1. >>> 0040 - b8 c9 18 be 41 32 e1 3c-00 41 2a f1 4d 5c 2d 44 ....A2.<.A*.M\-D >>> 0050 - 8c aa e1 f0 ed 38 ee 44-64 e5 fd ea 58 3b 84 5d .....8.Dd...X;.] >>> 0060 - 83 39 21 2e fe 79 4d 76-10 65 87 0f 3c ac df 28 .9!..yMv.e..<..( >>> 0070 - 49 f8 60 eb be 49 e4 0a-0b 6a 03 2b 9d cf 9b a5 I.`..I...j.+.... >>> 0080 - 03 56 58 32 c2 b2 59 f9-0a 0d f0 ae af ff 20 19 .VX2..Y....... . >>> 0090 - e5 6e e4 86 2f 5e 3f 7d-47 d5 73 ae 89 48 a7 66 .n../^?}G.s..H.f >>> 00a0 - fb 2d 83 60 e8 8b ab 27-12 db 24 78 54 eb 14 2d .-.`...'..$xT..- >>> 00b0 - b7 c6 17 2d 3c 91 57 ac-6e 35 b8 c3 fa c2 42 48 ...-<.W.n5....BH >>> 00c0 - 2a cb aa 98 32 89 8a ce-0c f7 cd 5e fb bf 6d 33 *...2......^..m3 >>> 00d0 - 08 50 cf 1e 06 bb a1 98-be a4 a9 51 9a b0 34 .P.........Q..4 >>> SSL_accept:SSLv3/TLS write session ticket >>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>> 0000 - 17 03 03 00 12 c5 9b 73-cc 91 7e 48 cb 25 31 a0 .......s..~H.%1. >>> 0010 - 67 41 db bb 0f 62 d8 gA...b. >>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>> 0000 - 17 03 03 00 12 0f dd 3f-c1 7c e6 b0 cc ea f0 13 .......?.|...... >>> 0010 - 00 d8 01 de ef 7c bb .....|. >>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>> 0000 - 17 03 03 00 1e ..... >>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (30 bytes => 30 (0x1E)) >>> 0000 - d6 88 44 82 cb 23 16 ba-c9 a4 fb 55 51 08 90 c1 ..D..#.....UQ... >>> 0010 - bf bd a1 7f 0e 37 b0 b4-b5 df f1 07 6c 07 .....7......l. >>> I am a clientwrite to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>> 0000 - 17 03 03 00 12 c0 70 5d-14 e7 69 57 0a d8 64 16 ......p]..iW..d. >>> 0010 - 0c 90 06 0f c3 4d 1d .....M. >>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>> 0000 - 17 03 03 00 13 ..... >>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (19 bytes => 19 (0x13)) >>> 0000 - 60 28 5b ff bb 0d 9f 96-9a 2d cb fd 60 eb 96 62 `([......-..`..b >>> 0010 - 53 e6 25 S.% >>> SSL3 alert read:warning:close notify >>> DONE >>> shutting down SSL >>> CONNECTION CLOSED >>> >>> >>> I am using the following JDK version on MacOS: >>> >>> ssl git:(cert_cb_openssl_1_1_1) ? /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java -version >>> java version "11" 2018-09-25 >>> Java(TM) SE Runtime Environment 18.9 (build 11+28) >>> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) >>> >>> For this to work you will need to have openssl 1.1.1 installed. >>> >>> Any help would be welcome, >>> Norman >>> >>> [1] https://github.com/netty/netty-tcnative >>> >>> >>> From bradford.wetmore at oracle.com Sat Sep 15 06:26:01 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 14 Sep 2018 23:26:01 -0700 Subject: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: <05EF82F5-6506-4928-8030-B9BEEE64E1F1@googlemail.com> References: <32bad254-1a8c-7933-d5a0-0b8ce3ed2f68@oracle.com> <05EF82F5-6506-4928-8030-B9BEEE64E1F1@googlemail.com> Message-ID: 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)) >>>> 0000 - 16 03 03 01 60 ....` >>>> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160)) >>>> 0000 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 ...\..".... at 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..o....K...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)) >>>> 0000 - 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|J....n....] >>>> 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..o....K.. >>>> 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 MT....B5S[...... >>>> 00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65 .(.m...8.wrs%&.e >>>> 00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96 X........P...... >>>> 0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9 .;<..AX...:(..a. >>>> 0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5 .h...f.[..... .. >>>> 0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb .RD...c=........ >>>> 0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6 .*O[J.wx.u. .... >>>> 0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee ...VV._.e.~n=.f. >>>> 0150 - 10 4c f7 6d 9b 73 86 14-7a 81 f8 b1 27 af 08 ee .L.m.s..z...'... >>>> 0160 - ce 26 90 34 73 3d b7 45-8d 85 29 a8 65 19 e7 02 .&.4s=.E..).e... >>>> 0170 - e5 55 4a 27 f1 b1 6a a4-11 cc 6c af 78 6d 22 5c .UJ'..j...l.xm"\ >>>> 0180 - 33 73 e3 ad 7f 8d 1b d3-75 95 66 64 2d 0e f1 3e 3s......u.fd-..> >>>> 0190 - c2 30 df a1 7e ce a3 50-c3 4e 68 f6 36 b3 4e 45 .0..~..P.Nh.6.NE >>>> 01a0 - 9c ac e9 f2 0d 7c e3 73-6a 40 ab 6e 6e f9 d8 20 .....|.sj at .nn.. >>>> 01b0 - 9c f3 04 32 cd 1d df 18-e5 4d e3 e8 b1 38 59 f8 ...2.....M...8Y. >>>> 01c0 - 28 67 2e ca af a2 8b 88-ce ca 48 a6 07 2b a6 9a (g........H..+.. >>>> 01d0 - 0e 88 5b d7 0b d9 31 77-97 8d 6c 2b f5 60 24 61 ..[...1w..l+.`$a >>>> 01e0 - a8 5c 47 5d 7c 66 f0 9b-1f e4 76 93 38 f6 78 3e .\G]|f....v.8.x> >>>> 01f0 - 69 29 72 f9 d9 4b cb 05-03 e4 f2 d6 24 e1 91 ee i)r..K......$... >>>> 0200 - 85 37 d7 7b c3 5c 35 90-08 cd b1 cc 76 11 fc 00 .7.{.\5.....v... >>>> 0210 - 12 7e 89 7b 70 e6 ca fe-0b 26 b6 bb ac fe 4b 9f .~.{p....&....K. >>>> 0220 - ec cf 41 69 42 3a 3e 41-f9 b0 c0 93 5b 70 1f c7 ..AiB:>A....[p.. >>>> 0230 - 11 00 3d ec 66 5a 1a ca-31 89 22 27 02 dd a0 cb ..=.fZ..1."'.... >>>> 0240 - 39 14 25 ee 30 44 e8 62-97 bf 8e 16 63 40 c4 11 9.%.0D.b....c at .. >>>> 0250 - a6 d9 32 b1 3c 86 35 bb-9f f1 4d 71 9f a5 4f 78 ..2.<.5...Mq..Ox >>>> 0260 - 0a e8 96 dd 4d 10 c3 48-f2 db 67 57 2d cd dc 23 ....M..H..gW-..# >>>> 0270 - 3a 8d 6a 61 47 20 ff c8-33 cd e9 f7 47 4c 68 4f :.jaG ..3...GLhO >>>> 0280 - 19 2f 8b e3 b1 90 ac 66-a7 cf 5c e6 d2 05 21 25 ./.....f..\...!% >>>> 0290 - d2 d8 f0 43 8c 55 01 ef-d6 8f c0 27 87 0d 21 d5 ...C.U.....'..!. >>>> 02a0 - 2b 2b 6f db e8 85 ea cd-6e 9c 5d 56 d5 31 c1 f2 ++o.....n.]V.1.. >>>> 02b0 - 97 2f 5a 83 7a 2b 71 03-65 e0 b6 4a 56 37 de e1 ./Z.z+q.e..JV7.. >>>> 02c0 - 80 3a c4 cc 5a ac 3b 9a-7a bf f7 6b fe a8 69 e9 .:..Z.;.z..k..i. >>>> 02d0 - 58 09 59 bd 46 bd d2 a3-bc ad 1c 10 53 c8 29 7b X.Y.F.......S.){ >>>> 02e0 - be 63 00 d6 e5 a8 d6 ab-b2 bc 8b e1 2c 0e 24 2a .c..........,.$* >>>> 02f0 - c2 31 2d d8 6e 1f 19 93-d7 54 e1 1e 28 ce 72 83 .1-.n....T..(.r. >>>> 0300 - ff 05 18 f2 fc e9 0c b3-0c 1b d5 96 c2 d8 fc 76 ...............v >>>> 0310 - 37 a9 5a ef 8e e9 b6 71-21 f3 bd c1 85 23 85 22 7.Z....q!....#." >>>> 0320 - 3d c4 1c c9 31 8b 7e 00-8f 8e b4 9f 05 d4 80 6b =...1.~........k >>>> 0330 - 98 4c a8 82 68 ff 1a a5-28 e2 9b 03 a1 a7 b1 00 .L..h...(....... >>>> 0340 - 02 2b 2d e2 e1 87 8c e8-0a fb 0b 79 54 ca 3d d5 .+-........yT.=. >>>> 0350 - 6a dd b7 b7 87 42 2b 47-49 da e9 0a 82 0a c9 8f j....B+GI....... >>>> 0360 - 57 f7 1e 03 ca 8d 16 bc-21 3a 6a ee b9 b8 fa f0 W.......!:j..... >>>> 0370 - d9 18 35 9f 35 ac d8 6e-9a 8a 0d 56 10 1e 1f 5a ..5.5..n...V...Z >>>> 0380 - ba ec e4 fe 1a 92 b4 31-35 43 1d 99 b9 12 fa ff .......15C...... >>>> 0390 - 99 2b 88 e0 58 ec 9c dc-8f 67 ef 2a c2 e2 64 5d .+..X....g.*..d] >>>> 03a0 - 66 76 1c d0 aa 00 30 59-b1 f5 b1 55 9f ad 60 e9 fv....0Y...U..`. >>>> 03b0 - 3d 03 1e d0 8b 4d bf 74-ac bc bb 1c 83 14 c5 e0 =....M.t........ >>>> 03c0 - f4 fc 70 9e f4 22 a0 78-04 fe c8 b1 17 65 f6 94 ..p..".x.....e.. >>>> 03d0 - 47 82 50 4a b6 32 74 ae-5b 38 5a 2e d9 b0 6a 45 G.PJ.2t.[8Z...jE >>>> 03e0 - 74 e8 f0 22 fe d3 b0 11-c3 fd 72 4f da 77 7a ba t.."......rO.wz. >>>> 03f0 - 26 3e 61 0c 63 21 17 a6-b2 13 6e 71 5c f2 0d ad &>a.c!....nq\... >>>> 0400 - f2 d1 19 71 51 9e a4 1b-b0 30 24 e0 71 7d 87 80 ...qQ....0$.q}.. >>>> 0410 - a9 5a e9 bc db e4 4f 50-4d a1 bc bc 2c 4b 66 98 .Z....OPM...,Kf. >>>> 0420 - d4 e4 b0 76 0f d2 db a5-a5 39 9e f2 5b ea 34 c1 ...v.....9..[.4. >>>> 0430 - 62 ab 47 51 3b 37 17 45-54 31 18 f3 f1 ca 17 03 b.GQ;7.ET1...... >>>> 0440 - 03 01 19 dd 50 50 f5 0c-f2 c9 3c b4 8f 63 cc 4a ....PP....<..c.J >>>> 0450 - a7 50 c9 91 9b 79 9a 2a-5c 47 d3 77 f6 56 69 90 .P...y.*\G.w.Vi. >>>> 0460 - 98 cd ff bd c1 2a 49 fc-0d d4 7e cc 7e 44 af c4 .....*I...~.~D.. >>>> 0470 - 61 47 e0 c1 76 b1 8c 2e-df 7e d0 82 e1 89 1f 04 aG..v....~...... >>>> 0480 - ae 64 bd 71 4d ae 1c 3c-e3 d3 39 5d 61 2a ea 70 .d.qM..<..9]a*.p >>>> 0490 - 8c 31 6d a0 b1 72 a8 7a-5c 9c 11 08 b8 4d a5 c4 .1m..r.z\....M.. >>>> 04a0 - ad 1b 38 4a 6a 02 28 d4-d1 0f c8 9f 0b b3 02 18 ..8Jj.(......... >>>> 04b0 - 82 2b bd 46 82 04 64 f0-41 b2 da f5 cd 9c f7 f3 .+.F..d.A....... >>>> 04c0 - 73 30 58 ca 12 ec ea 90-85 1c 75 09 0a 70 b8 80 s0X.......u..p.. >>>> 04d0 - 3d 02 17 3e 9b 83 04 b5-dd 9e e6 18 17 65 83 a5 =..>.........e.. >>>> 04e0 - 59 7d 4b 98 da bd 8b aa-d6 aa c5 1c 7d 87 56 e3 Y}K.........}.V. >>>> 04f0 - 74 d8 e9 7b eb b3 3d f7-7c 3c 0a e9 a8 2e 04 0d t..{..=.|<...... >>>> 0500 - 6a e7 83 e0 ec 99 43 6a-8b 1c 73 59 7a c8 cd 6e j.....Cj..sYz..n >>>> 0510 - 4a 14 73 ff 9a fb 71 94-d5 50 a9 d9 e0 dd 02 4c J.s...q..P.....L >>>> 0520 - 2b 67 9e da 9e fa 2d 67-49 df 13 10 ed 35 3e 73 +g....-gI....5>s >>>> 0530 - 07 20 17 fb 0b ef f6 d0-b7 68 1c 65 21 a6 e3 3b . .......h.e!..; >>>> 0540 - bf 7b 84 cd 9e f5 76 2a-0d 4f b8 c3 c8 15 08 e9 .{....v*.O...... >>>> 0550 - 0f 3c 50 49 12 97 a8 d7-f1 a3 16 da 17 03 03 00 .>>> 0560 - 35 22 dd a2 9d 25 98 2c-35 b8 00 29 fa a1 dd ba 5"...%.,5..).... >>>> 0570 - 72 b9 fe e5 85 85 f0 f1-3b 4e f5 7c 58 c8 2a da r.......;N.|X.*. >>>> 0580 - d2 75 94 3b c1 7a 7c 7e-db 5b fe 8a 2d 3f 8c 9a .u.;.z|~.[..-?.. >>>> 0590 - 6e 79 ab 2b ff 1a ny.+.. >>>> SSL_accept:SSLv3/TLS write finished >>>> SSL_accept:TLSv1.3 early data >>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>> 0000 - 14 03 03 00 01 ..... >>>> read from 0x7fe400f050c0 [0x7fe40300f608] (1 bytes => 1 (0x1)) >>>> 0000 - 01 . >>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>> 0000 - 17 03 03 00 3d ....= >>>> read from 0x7fe400f050c0 [0x7fe40300f608] (61 bytes => 61 (0x3D)) >>>> 0000 - 38 e7 bb 2c 5b af b6 5f-37 d8 3e 7e bb f4 04 f5 8..,[.._7.>~.... >>>> 0010 - e1 28 b5 e5 07 5a ec ce-da 2f f3 b6 45 61 cf ef .(...Z.../..Ea.. >>>> 0020 - 90 fb 57 b8 f3 20 45 27-60 d4 26 51 38 77 e4 bc ..W.. E'`.&Q8w.. >>>> 0030 - b7 64 d4 8b 73 25 41 9e-fe d3 9d 5f 53 .d..s%A...._S >>>> SSL_accept:TLSv1.3 early data >>>> write to 0x7fe400f050c0 [0x7fe403018a00] (24 bytes => 24 (0x18)) >>>> 0000 - 17 03 03 00 13 25 85 60-eb 7d c1 a8 15 49 d5 63 .....%.`.}...I.c >>>> 0010 - 18 7f c6 ac ed 7f df 77- .......w >>>> SSL3 alert write:fatal:unknown >>>> SSL_accept:error in error >>>> ERROR >>>> 140736092021632:error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate:ssl/statem/statem_srvr.c:3654: >>>> shutting down SSL >>>> CONNECTION CLOSED >>>> >>>> >>>> >>>> When using openssl s_client all works as expected tho (thats also true if I use my native implementation on the client and server side that uses openssl): >>>> >>>> ./bin/openssl s_client -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 -state -tls1_3 -connect localhost:8443 >>>> >>>> The interesting thing is if I use ?-verify 1? and not ?-Verify 1? with openssl which tells it I want to request a certificate but will also process if none is provided I receive the certificate at some point as seen here: >>>> >>>> SSL_accept:before SSL initialization >>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>> 0000 - 16 03 03 01 60 ....` >>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (352 bytes => 352 (0x160)) >>>> 0000 - 01 00 01 5c 03 03 61 c0-b3 ed 88 65 e6 cf 11 3f ...\..a....e...? >>>> 0010 - c0 e0 f8 df a6 63 32 c2-ab 3d 61 6f 41 ed b1 4b .....c2..=aoA..K >>>> 0020 - 53 0e 83 e5 a1 b8 20 c7-1b 8c b8 e6 b5 da 4e 4e S..... .......NN >>>> 0030 - 3f 3c 61 7a ad 58 23 94-a7 32 79 2f db 9f 21 c0 ?>>> 0040 - 8e 0c c5 ce b1 c2 a4 00-14 c0 2c c0 2b c0 2f c0 ..........,.+./. >>>> 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 52 dc d6 47 6e .3.G.E...A.R..Gn >>>> 0120 - a1 de 9c 71 c2 54 0e 5c-9b 57 fb c8 aa 3f 19 f7 ...q.T.\.W...?.. >>>> 0130 - d3 a4 25 12 fa 3f 6c 6d-95 30 66 ca 63 b7 a1 dd ..%..?lm.0f.c... >>>> 0140 - ae 9f 99 d6 a8 6b 20 4f-29 7a 74 58 ad 58 de 12 .....k O)ztX.X.. >>>> 0150 - d7 a5 9b 69 dc 27 ac ec-9e d4 04 ff 01 00 01 00 ...i.'.......... >>>> 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 0x7fdc58809fb0 [0x7fdc59025e00] (1430 bytes => 1430 (0x596)) >>>> 0000 - 16 03 03 00 9b 02 00 00-97 03 03 8b c8 62 48 6c .............bHl >>>> 0010 - f5 7c 73 d9 17 f8 63 a2-11 27 40 93 09 26 53 06 .|s...c..'@..&S. >>>> 0020 - b3 62 df 46 26 b6 dc 59-29 b5 58 20 c7 1b 8c b8 .b.F&..Y).X .... >>>> 0030 - e6 b5 da 4e 4e 3f 3c 61-7a ad 58 23 94 a7 32 79 ...NN?>>> 0040 - 2f db 9f 21 c0 8e 0c c5-ce b1 c2 a4 13 01 00 00 /..!............ >>>> 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 O.+.....3.E...A. >>>> 0060 - 07 63 1c 19 53 89 68 a8-0f ea 9e 4c 18 6f 2a ad .c..S.h....L.o*. >>>> 0070 - 2a df eb 17 a2 08 94 c6-e3 c5 97 ae 0f c1 1a d7 *............... >>>> 0080 - 0d d7 2e 6d 77 3d 30 a0-07 db 70 35 bb 37 dd 1e ...mw=0...p5.7.. >>>> 0090 - b6 f3 4d cb 13 97 7c 11-63 98 e8 64 2d a7 e6 cc ..M...|.c..d-... >>>> 00a0 - 14 03 03 00 01 01 17 03-03 00 27 a3 73 d2 ee 2c ..........'.s.., >>>> 00b0 - 2f 9c 8f 95 7f ca a3 89-bc b4 b3 b2 3c 8b 23 ef /...........<.#. >>>> 00c0 - 36 66 23 c9 09 02 33 0d-dc 5d 36 61 44 89 8b ef 6f#...3..]6aD... >>>> 00d0 - fd 13 17 03 03 00 42 f2-5b 3c 0c 27 5e 7f 97 4f ......B.[<.'^..O >>>> 00e0 - 0f de 8c b9 0a a1 41 c7-c2 1e 92 99 6a d5 bd 12 ......A.....j... >>>> 00f0 - 38 b6 b7 93 33 e9 8e 0f-44 93 f0 69 58 b6 41 22 8...3...D..iX.A" >>>> 0100 - 46 e2 4a d5 d6 32 2b b8-a7 ae 3a c2 c5 2f e6 35 F.J..2+...:../.5 >>>> 0110 - 11 0c f1 9a 35 2a 87 ed-9e 17 03 03 03 20 a7 e2 ....5*....... .. >>>> 0120 - fe ba c7 10 5b 9c cd 94-67 19 37 2d 46 59 ab 56 ....[...g.7-FY.V >>>> 0130 - 6b dd a4 10 61 cc ed f1-71 a7 2d 6a 41 2e 2b da k...a...q.-jA.+. >>>> 0140 - d1 35 fc 01 df 49 e5 90-1d 9b b2 03 0a 81 58 18 .5...I........X. >>>> 0150 - 96 a1 db 31 19 98 35 5c-87 8f 6e 32 0a e6 c0 aa ...1..5\..n2.... >>>> 0160 - 9e 8e 72 e2 34 b3 b7 a3-d6 d1 66 c7 ce 93 fe 78 ..r.4.....f....x >>>> 0170 - 17 c4 71 7c 42 15 c8 af-dc 4f 50 42 51 80 fc bf ..q|B....OPBQ... >>>> 0180 - fc 54 d5 d8 59 20 9a 90-c4 78 97 9c 2d 4a d5 58 .T..Y ...x..-J.X >>>> 0190 - be 81 79 23 59 22 9d 27-f8 bd a0 b2 98 b3 47 82 ..y#Y".'......G. >>>> 01a0 - d3 52 b5 b5 91 ab 5c 76-52 c5 a5 95 2d 03 1c b7 .R....\vR...-... >>>> 01b0 - 64 4d 0b 88 7f 15 0b c8-a8 90 50 9a b6 b1 9f b7 dM........P..... >>>> 01c0 - 40 09 f2 5f 39 f8 9a 06-21 4d 67 10 0a 67 08 b6 @.._9...!Mg..g.. >>>> 01d0 - b5 9a 25 8c d5 ca 31 6a-8a 6b 01 93 7d 6f 1e 52 ..%...1j.k..}o.R >>>> 01e0 - 98 96 9d fb e8 c1 07 ab-57 98 2d 1e 75 77 ef c2 ........W.-.uw.. >>>> 01f0 - 49 78 e0 b9 2b 32 23 7e-95 4d 3e 27 00 61 86 0c Ix..+2#~.M>'.a.. >>>> 0200 - 47 c7 79 e4 ee 9d ba c0-ea 62 f1 0d 8e 4a 91 30 G.y......b...J.0 >>>> 0210 - bc 4f 5a 98 26 30 66 ec-c4 63 8f 28 d5 1c 61 23 .OZ.&0f..c.(..a# >>>> 0220 - ea e9 90 4e 36 d9 fa 31-7b 14 27 22 0a ae 9f 64 ...N6..1{.'"...d >>>> 0230 - 40 3d e5 a0 5c 9d 3c 04-71 09 b0 7a 6b 51 a0 9c @=..\.<.q..zkQ.. >>>> 0240 - c0 61 32 ce 15 62 8e 29-b1 59 91 c0 17 2c b3 c5 .a2..b.).Y...,.. >>>> 0250 - f9 ed 07 65 3d 11 de 98-de 62 36 50 74 37 af 2d ...e=....b6Pt7.- >>>> 0260 - 7d 86 55 c4 3e a2 83 ab-47 8d f2 b2 8d 1d 75 83 }.U.>...G.....u. >>>> 0270 - b5 e4 41 87 a7 a3 85 b0-5e 4e 2e 9c 8c b0 1b 83 ..A.....^N...... >>>> 0280 - 7b 54 79 c9 60 ea 7d ed-06 fa dd 24 40 f1 53 9e {Ty.`.}....$@.S. >>>> 0290 - 43 79 25 53 9c c7 6e 95-ab 9f 96 59 cd b9 7b a8 Cy%S..n....Y..{. >>>> 02a0 - a0 23 13 69 db a9 c9 e7-1a 8e e1 9b 54 94 1c 44 .#.i........T..D >>>> 02b0 - 50 08 8b dd eb 4e 2b bb-d7 c9 c2 33 8c a1 b3 65 P....N+....3...e >>>> 02c0 - 06 e6 9d ac 11 16 21 58-40 8d 59 e6 67 e5 31 02 ......!X at .Y.g.1. >>>> 02d0 - 15 8d 29 80 20 66 ba c3-56 93 95 5c 65 4b 41 00 ..). f..V..\eKA. >>>> 02e0 - c5 71 12 12 f5 20 4f 59-be 77 06 10 6e 48 85 5c .q... OY.w..nH.\ >>>> 02f0 - ff a2 c4 ae fb 4d 95 f5-cc f6 61 20 33 b7 92 1d .....M....a 3... >>>> 0300 - ac a8 f1 b2 b0 88 c6 7b-8b 00 53 30 6d 4a d1 42 .......{..S0mJ.B >>>> 0310 - b3 3e 85 f5 84 e1 c6 ab-10 9d 61 03 46 ff 2d 81 .>........a.F.-. >>>> 0320 - 15 4f 84 d1 4c ee f4 a6-a0 ec 50 60 a0 d1 ff df .O..L.....P`.... >>>> 0330 - 8a 97 f6 7d fb 8f fb 60-18 d4 f1 1f 92 4d d8 69 ...}...`.....M.i >>>> 0340 - b1 92 97 44 0f 3c 8a aa-47 07 48 d4 07 2d 3e f2 ...D.<..G.H..->. >>>> 0350 - c4 a7 16 35 a7 17 71 ef-98 84 24 67 12 58 30 3b ...5..q...$g.X0; >>>> 0360 - 1d 41 8d e5 12 52 95 64-e5 88 35 99 d7 c3 58 40 .A...R.d..5...X@ >>>> 0370 - f9 55 9b 9f e5 33 15 70-41 d7 45 ba a4 fc 75 ea .U...3.pA.E...u. >>>> 0380 - a4 ae f0 68 ea 64 d8 f5-06 68 a9 75 22 4d 43 cc ...h.d...h.u"MC. >>>> 0390 - ff 50 cc ac 6e fd 43 dd-eb e4 c8 dd 4b 6c 12 bb .P..n.C.....Kl.. >>>> 03a0 - f1 d4 5e 11 4a 86 90 0b-f8 3a 2e 23 db 61 5a 1f ..^.J....:.#.aZ. >>>> 03b0 - 7e 11 00 92 21 68 1f b5-ab f2 f8 38 5e 62 ea f8 ~...!h.....8^b.. >>>> 03c0 - da ef c2 6e a0 b8 20 e4-69 49 b3 1f 15 84 0b 9b ...n.. .iI...... >>>> 03d0 - ce b0 6f 36 32 7f 7e bf-e8 d7 18 7a 58 60 f4 04 ..o62.~....zX`.. >>>> 03e0 - cc 36 bf 06 cd ec e5 9b-19 03 96 09 fb af 8f c3 .6.............. >>>> 03f0 - 98 b4 02 aa e8 55 81 aa-c4 fe 06 81 30 a0 c7 b2 .....U......0... >>>> 0400 - f8 e2 30 00 d7 a0 54 7f-5f d7 ef a6 f8 41 58 34 ..0...T._....AX4 >>>> 0410 - f5 f0 18 69 8d e6 7a 23-78 90 8f b1 05 c5 b5 7f ...i..z#x....... >>>> 0420 - e0 f2 c7 fa c8 36 5b 53-7e cf e6 75 d3 54 b4 69 .....6[S~..u.T.i >>>> 0430 - 68 43 0d 6a d2 83 cc 13-6d ca bf 83 3c 90 17 03 hC.j....m...<... >>>> 0440 - 03 01 19 96 dc 49 26 ce-1d 8e 86 3d bd cb 00 5e .....I&....=...^ >>>> 0450 - ee f6 e7 1d 16 7a ca ef-fa 6d 16 40 b6 99 d0 c1 .....z...m. at .... >>>> 0460 - df 0b 5f 51 60 a8 24 e0-61 82 13 40 da 88 38 3a .._Q`.$.a.. at ..8: >>>> 0470 - 26 1d 80 51 c4 b1 95 35-95 3c 91 35 28 17 49 d8 &..Q...5.<.5(.I. >>>> 0480 - c3 45 be 32 98 3e 02 07-3b 01 20 2b 51 e1 1a 94 .E.2.>..;. +Q... >>>> 0490 - b9 be 96 aa 7a 13 09 ff-d5 a9 63 d4 6f 49 cb b5 ....z.....c.oI.. >>>> 04a0 - 23 ab 7f 8c e2 63 f0 5c-5c 27 1e 04 a8 71 0c c0 #....c.\\'...q.. >>>> 04b0 - 89 cd ed 18 8d 5b 75 ac-af f3 68 6d cc ba 20 38 .....[u...hm.. 8 >>>> 04c0 - b5 7c 09 47 29 28 e2 26-57 57 1f f0 f3 18 fd 6f .|.G)(.&WW.....o >>>> 04d0 - 27 42 a4 e3 de bb e5 d6-09 7d 25 b1 98 97 ad 33 'B.......}%....3 >>>> 04e0 - 68 35 92 07 80 23 f1 66-20 5d 74 f3 02 c5 51 ff h5...#.f ]t...Q. >>>> 04f0 - 07 a9 e9 0e 3e 74 da 2e-8f 3b 16 be e6 94 1b 66 ....>t...;.....f >>>> 0500 - bb b2 a2 1e 7c 7b ff 5e-a4 36 2a ba 0b cd 7f e9 ....|{.^.6*..... >>>> 0510 - 86 bb 5e 30 f5 57 92 52-82 b6 2e da 71 b7 22 c2 ..^0.W.R....q.". >>>> 0520 - 90 c4 69 46 07 df 6c 3f-05 8b 19 3e ce b9 75 0d ..iF..l?...>..u. >>>> 0530 - 4b 97 37 ae 94 e2 d6 3c-91 e6 82 c7 a1 78 79 2c K.7....<.....xy, >>>> 0540 - 9a a3 d5 45 94 ad e2 c8-ab fd 81 ec 62 87 f7 75 ...E........b..u >>>> 0550 - e3 70 79 8e 82 3b c5 45-0d d0 33 5f 17 03 03 00 .py..;.E..3_.... >>>> 0560 - 35 da e0 74 2a 06 41 5a-64 1e 54 94 29 73 43 3f 5..t*.AZd.T.)sC? >>>> 0570 - e5 24 a8 ba b2 7e 6b 26-82 fc d9 f6 dd 19 05 4a .$...~k&.......J >>>> 0580 - 2c 1a f3 bb 16 1d 38 95-a6 d3 a8 58 f6 a3 41 c7 ,.....8....X..A. >>>> 0590 - 92 44 35 24 25 0e .D5$%. >>>> SSL_accept:SSLv3/TLS write finished >>>> SSL_accept:TLSv1.3 early data >>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>> 0000 - 14 03 03 00 01 ..... >>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (1 bytes => 1 (0x1)) >>>> 0000 - 01 . >>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>> 0000 - 17 03 03 00 3d ....= >>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (61 bytes => 61 (0x3D)) >>>> 0000 - ad dd 3e d9 ee ab 56 65-50 1c 72 2a d8 62 7f 90 ..>...VeP.r*.b.. >>>> 0010 - 13 71 7d 37 39 40 fb 89-8f 05 4b 39 44 9d 4d 67 .q}79 at ....K9D.Mg >>>> 0020 - e3 41 29 b6 3e e8 fe 04-1b 8e eb 7a 4c e2 14 a0 .A).>......zL... >>>> 0030 - b1 c2 47 3f 94 35 ed ab-8a d1 75 3b ba ..G?.5....u;. >>>> SSL_accept:TLSv1.3 early data >>>> SSL_accept:SSLv3/TLS read client certificate >>>> SSL_accept:SSLv3/TLS read finished >>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>> 0000 - 17 03 03 00 da 52 1f 48-00 f4 31 13 90 7f 9c c2 .....R.H..1..... >>>> 0010 - fc 70 1a fc f7 4a 48 e7-31 ad 37 ab b5 2b 4e 5c .p...JH.1.7..+N\ >>>> 0020 - e8 d8 6d e9 af 6c 4f c1-9e 7b ea ff ef b3 eb 74 ..m..lO..{.....t >>>> 0030 - 27 67 10 21 66 5b 32 13-31 bc 99 d5 1c 6c 79 55 'g.!f[2.1....lyU >>>> 0040 - f3 3e f6 4b 07 4d a9 78-3d 12 8a f5 38 ef d9 f4 .>.K.M.x=...8... >>>> 0050 - 48 e0 2c 35 94 06 4f eb-09 e6 70 fb 59 95 7a c8 H.,5..O...p.Y.z. >>>> 0060 - 24 dd 24 e2 f9 63 b9 3c-f2 66 86 c4 73 44 53 fd $.$..c.<.f..sDS. >>>> 0070 - ca 67 8f 01 d6 db 70 f9-60 bc 50 11 51 72 dc 63 .g....p.`.P.Qr.c >>>> 0080 - 12 ca 4f 23 e2 c5 d1 1d-e5 b0 d4 ec 89 ca 28 be ..O#..........(. >>>> 0090 - 9c 30 83 40 02 a4 62 a8-5c b3 20 1a ab 39 b7 7b .0. at ..b.\. ..9.{ >>>> 00a0 - 89 13 39 87 73 be a8 f8-60 13 31 0a 48 5c 79 b9 ..9.s...`.1.H\y. >>>> 00b0 - cc 4a 51 e3 0d d2 b4 93-c0 1f 3a 22 b3 fa 24 a0 .JQ.......:"..$. >>>> 00c0 - 7c f6 76 79 d0 2d 5b 1a-ff a6 e9 e1 40 d3 b1 8c |.vy.-[..... at ... >>>> 00d0 - 0a fa fa de f3 8e d6 ad-9a 22 6b 67 0b 88 18 ........."kg... >>>> SSL_accept:SSLv3/TLS write session ticket >>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>> 0000 - 17 03 03 00 da 46 aa ea-6a 37 b1 35 e8 41 c8 b3 .....F..j7.5.A.. >>>> 0010 - 84 25 af 1c 36 a3 6d 78-a4 44 4a 83 52 ef 13 7c .%..6.mx.DJ.R..| >>>> 0020 - 8f 18 d3 4c f8 22 c8 b3-ad d0 d0 5b 47 a0 43 da ...L.".....[G.C. >>>> 0030 - d2 6e 04 8f dc c9 56 90-58 87 62 63 4c cc 31 ec .n....V.X.bcL.1. >>>> 0040 - b8 c9 18 be 41 32 e1 3c-00 41 2a f1 4d 5c 2d 44 ....A2.<.A*.M\-D >>>> 0050 - 8c aa e1 f0 ed 38 ee 44-64 e5 fd ea 58 3b 84 5d .....8.Dd...X;.] >>>> 0060 - 83 39 21 2e fe 79 4d 76-10 65 87 0f 3c ac df 28 .9!..yMv.e..<..( >>>> 0070 - 49 f8 60 eb be 49 e4 0a-0b 6a 03 2b 9d cf 9b a5 I.`..I...j.+.... >>>> 0080 - 03 56 58 32 c2 b2 59 f9-0a 0d f0 ae af ff 20 19 .VX2..Y....... . >>>> 0090 - e5 6e e4 86 2f 5e 3f 7d-47 d5 73 ae 89 48 a7 66 .n../^?}G.s..H.f >>>> 00a0 - fb 2d 83 60 e8 8b ab 27-12 db 24 78 54 eb 14 2d .-.`...'..$xT..- >>>> 00b0 - b7 c6 17 2d 3c 91 57 ac-6e 35 b8 c3 fa c2 42 48 ...-<.W.n5....BH >>>> 00c0 - 2a cb aa 98 32 89 8a ce-0c f7 cd 5e fb bf 6d 33 *...2......^..m3 >>>> 00d0 - 08 50 cf 1e 06 bb a1 98-be a4 a9 51 9a b0 34 .P.........Q..4 >>>> SSL_accept:SSLv3/TLS write session ticket >>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>> 0000 - 17 03 03 00 12 c5 9b 73-cc 91 7e 48 cb 25 31 a0 .......s..~H.%1. >>>> 0010 - 67 41 db bb 0f 62 d8 gA...b. >>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>> 0000 - 17 03 03 00 12 0f dd 3f-c1 7c e6 b0 cc ea f0 13 .......?.|...... >>>> 0010 - 00 d8 01 de ef 7c bb .....|. >>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>> 0000 - 17 03 03 00 1e ..... >>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (30 bytes => 30 (0x1E)) >>>> 0000 - d6 88 44 82 cb 23 16 ba-c9 a4 fb 55 51 08 90 c1 ..D..#.....UQ... >>>> 0010 - bf bd a1 7f 0e 37 b0 b4-b5 df f1 07 6c 07 .....7......l. >>>> I am a clientwrite to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>> 0000 - 17 03 03 00 12 c0 70 5d-14 e7 69 57 0a d8 64 16 ......p]..iW..d. >>>> 0010 - 0c 90 06 0f c3 4d 1d .....M. >>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>> 0000 - 17 03 03 00 13 ..... >>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (19 bytes => 19 (0x13)) >>>> 0000 - 60 28 5b ff bb 0d 9f 96-9a 2d cb fd 60 eb 96 62 `([......-..`..b >>>> 0010 - 53 e6 25 S.% >>>> SSL3 alert read:warning:close notify >>>> DONE >>>> shutting down SSL >>>> CONNECTION CLOSED >>>> >>>> >>>> I am using the following JDK version on MacOS: >>>> >>>> ssl git:(cert_cb_openssl_1_1_1) ? /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java -version >>>> java version "11" 2018-09-25 >>>> Java(TM) SE Runtime Environment 18.9 (build 11+28) >>>> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) >>>> >>>> For this to work you will need to have openssl 1.1.1 installed. >>>> >>>> Any help would be welcome, >>>> Norman >>>> >>>> [1] https://github.com/netty/netty-tcnative >>>> >>>> >>>> From weijun.wang at oracle.com Sat Sep 15 13:28:55 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 15 Sep 2018 21:28:55 +0800 Subject: RFR 8210786 : Typo s/overriden/overridden/ in several places In-Reply-To: <2ff4ae4c-4992-d468-e187-fc66808c9eeb@oracle.com> References: <2ff4ae4c-4992-d468-e187-fc66808c9eeb@oracle.com> Message-ID: <2463260A-DF9D-410F-A8DD-32D51678D03D@oracle.com> 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 > From philip.race at oracle.com Sat Sep 15 20:59:22 2018 From: philip.race at oracle.com (Philip Race) Date: Sat, 15 Sep 2018 13:59:22 -0700 Subject: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped In-Reply-To: References: Message-ID: <5B9D72AA.9060507@oracle.com> 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". >>> >>> From philip.race at oracle.com Sat Sep 15 21:00:48 2018 From: philip.race at oracle.com (Philip Race) Date: Sat, 15 Sep 2018 14:00:48 -0700 Subject: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped In-Reply-To: <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com> References: <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com> Message-ID: <5B9D7300.8080207@oracle.com> 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". >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Sat Sep 15 21:10:08 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 15 Sep 2018 14:10:08 -0700 Subject: RFR 8210786 : Typo s/overriden/overridden/ in several places In-Reply-To: <2463260A-DF9D-410F-A8DD-32D51678D03D@oracle.com> References: <2ff4ae4c-4992-d468-e187-fc66808c9eeb@oracle.com> <2463260A-DF9D-410F-A8DD-32D51678D03D@oracle.com> Message-ID: <9e51fa8e-d741-9f5a-ce76-df29d1d6de38@oracle.com> 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 From weijun.wang at oracle.com Sat Sep 15 22:41:40 2018 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 16 Sep 2018 06:41:40 +0800 Subject: RFR 8210786 : Typo s/overriden/overridden/ in several places In-Reply-To: <9e51fa8e-d741-9f5a-ce76-df29d1d6de38@oracle.com> References: <2ff4ae4c-4992-d468-e187-fc66808c9eeb@oracle.com> <2463260A-DF9D-410F-A8DD-32D51678D03D@oracle.com> <9e51fa8e-d741-9f5a-ce76-df29d1d6de38@oracle.com> Message-ID: 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 > From dblack at atlassian.com Sun Sep 16 05:05:45 2018 From: dblack at atlassian.com (David Black) Date: Sun, 16 Sep 2018 07:05:45 +0200 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: 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. From dblack at atlassian.com Sun Sep 16 05:09:48 2018 From: dblack at atlassian.com (David Black) Date: Sun, 16 Sep 2018 07:09:48 +0200 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> Message-ID: 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. From Alan.Bateman at oracle.com Sun Sep 16 07:48:57 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 16 Sep 2018 08:48:57 +0100 Subject: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped In-Reply-To: <5B9D7300.8080207@oracle.com> References: <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com> <5B9D7300.8080207@oracle.com> Message-ID: <6cea33e2-db84-46df-10f2-d9d3d570062f@oracle.com> On 15/09/2018 22:00, Philip Race wrote: > 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. I think Sergey's changes are okay. The main issue with com.sun.awt API is that it tried to be both an exported and internal/unsupported API at the same time (it's javadoc reads "This class is an implementation detail and only meant for limited use outside of the core platform"). This doesn't work for modules. In addition the design principles in JEP 200 make it clear that standard modules should not export a non-standard package to all modules. If there has been extensive use of this API then I could imagine it being refactored and moved into a JDK-specific module but there was little evidence of usage. So where we ended up in JDK 9 is that the API is not exported. This means, as Mandy hinted, you can't compile against this API (at least not without --add-exports to the compiler). Existing code using this API will continue to run on JDK 9, 10, 11 or until the java.desktop module is fully encapsulated or the SecurityWarning class is removed. Sergey got there first. -Alan From norman.maurer at googlemail.com Sun Sep 16 13:54:17 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Sun, 16 Sep 2018 15:54:17 +0200 Subject: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: References: <32bad254-1a8c-7933-d5a0-0b8ce3ed2f68@oracle.com> <05EF82F5-6506-4928-8030-B9BEEE64E1F1@googlemail.com> Message-ID: Will do, but not before tomorrow (I will also share the client side code). That said there is nothing special about the keymanager. Like I said before it sends the cert when using ?want client with?, it just seems it may be too late. Bye Norman > Am 15.09.2018 um 08:26 schrieb Bradford Wetmore : > > 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)) >>>>> 0000 - 16 03 03 01 60 ....` >>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160)) >>>>> 0000 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 ...\..".... at 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..o....K...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)) >>>>> 0000 - 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|J....n....] >>>>> 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..o....K.. >>>>> 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 MT....B5S[...... >>>>> 00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65 .(.m...8.wrs%&.e >>>>> 00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96 X........P...... >>>>> 0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9 .;<..AX...:(..a. >>>>> 0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5 .h...f.[..... .. >>>>> 0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb .RD...c=........ >>>>> 0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6 .*O[J.wx.u. .... >>>>> 0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee ...VV._.e.~n=.f. >>>>> 0150 - 10 4c f7 6d 9b 73 86 14-7a 81 f8 b1 27 af 08 ee .L.m.s..z...'... >>>>> 0160 - ce 26 90 34 73 3d b7 45-8d 85 29 a8 65 19 e7 02 .&.4s=.E..).e... >>>>> 0170 - e5 55 4a 27 f1 b1 6a a4-11 cc 6c af 78 6d 22 5c .UJ'..j...l.xm"\ >>>>> 0180 - 33 73 e3 ad 7f 8d 1b d3-75 95 66 64 2d 0e f1 3e 3s......u.fd-..> >>>>> 0190 - c2 30 df a1 7e ce a3 50-c3 4e 68 f6 36 b3 4e 45 .0..~..P.Nh.6.NE >>>>> 01a0 - 9c ac e9 f2 0d 7c e3 73-6a 40 ab 6e 6e f9 d8 20 .....|.sj at .nn.. >>>>> 01b0 - 9c f3 04 32 cd 1d df 18-e5 4d e3 e8 b1 38 59 f8 ...2.....M...8Y. >>>>> 01c0 - 28 67 2e ca af a2 8b 88-ce ca 48 a6 07 2b a6 9a (g........H..+.. >>>>> 01d0 - 0e 88 5b d7 0b d9 31 77-97 8d 6c 2b f5 60 24 61 ..[...1w..l+.`$a >>>>> 01e0 - a8 5c 47 5d 7c 66 f0 9b-1f e4 76 93 38 f6 78 3e .\G]|f....v.8.x> >>>>> 01f0 - 69 29 72 f9 d9 4b cb 05-03 e4 f2 d6 24 e1 91 ee i)r..K......$... >>>>> 0200 - 85 37 d7 7b c3 5c 35 90-08 cd b1 cc 76 11 fc 00 .7.{.\5.....v... >>>>> 0210 - 12 7e 89 7b 70 e6 ca fe-0b 26 b6 bb ac fe 4b 9f .~.{p....&....K. >>>>> 0220 - ec cf 41 69 42 3a 3e 41-f9 b0 c0 93 5b 70 1f c7 ..AiB:>A....[p.. >>>>> 0230 - 11 00 3d ec 66 5a 1a ca-31 89 22 27 02 dd a0 cb ..=.fZ..1."'.... >>>>> 0240 - 39 14 25 ee 30 44 e8 62-97 bf 8e 16 63 40 c4 11 9.%.0D.b....c at .. >>>>> 0250 - a6 d9 32 b1 3c 86 35 bb-9f f1 4d 71 9f a5 4f 78 ..2.<.5...Mq..Ox >>>>> 0260 - 0a e8 96 dd 4d 10 c3 48-f2 db 67 57 2d cd dc 23 ....M..H..gW-..# >>>>> 0270 - 3a 8d 6a 61 47 20 ff c8-33 cd e9 f7 47 4c 68 4f :.jaG ..3...GLhO >>>>> 0280 - 19 2f 8b e3 b1 90 ac 66-a7 cf 5c e6 d2 05 21 25 ./.....f..\...!% >>>>> 0290 - d2 d8 f0 43 8c 55 01 ef-d6 8f c0 27 87 0d 21 d5 ...C.U.....'..!. >>>>> 02a0 - 2b 2b 6f db e8 85 ea cd-6e 9c 5d 56 d5 31 c1 f2 ++o.....n.]V.1.. >>>>> 02b0 - 97 2f 5a 83 7a 2b 71 03-65 e0 b6 4a 56 37 de e1 ./Z.z+q.e..JV7.. >>>>> 02c0 - 80 3a c4 cc 5a ac 3b 9a-7a bf f7 6b fe a8 69 e9 .:..Z.;.z..k..i. >>>>> 02d0 - 58 09 59 bd 46 bd d2 a3-bc ad 1c 10 53 c8 29 7b X.Y.F.......S.){ >>>>> 02e0 - be 63 00 d6 e5 a8 d6 ab-b2 bc 8b e1 2c 0e 24 2a .c..........,.$* >>>>> 02f0 - c2 31 2d d8 6e 1f 19 93-d7 54 e1 1e 28 ce 72 83 .1-.n....T..(.r. >>>>> 0300 - ff 05 18 f2 fc e9 0c b3-0c 1b d5 96 c2 d8 fc 76 ...............v >>>>> 0310 - 37 a9 5a ef 8e e9 b6 71-21 f3 bd c1 85 23 85 22 7.Z....q!....#." >>>>> 0320 - 3d c4 1c c9 31 8b 7e 00-8f 8e b4 9f 05 d4 80 6b =...1.~........k >>>>> 0330 - 98 4c a8 82 68 ff 1a a5-28 e2 9b 03 a1 a7 b1 00 .L..h...(....... >>>>> 0340 - 02 2b 2d e2 e1 87 8c e8-0a fb 0b 79 54 ca 3d d5 .+-........yT.=. >>>>> 0350 - 6a dd b7 b7 87 42 2b 47-49 da e9 0a 82 0a c9 8f j....B+GI....... >>>>> 0360 - 57 f7 1e 03 ca 8d 16 bc-21 3a 6a ee b9 b8 fa f0 W.......!:j..... >>>>> 0370 - d9 18 35 9f 35 ac d8 6e-9a 8a 0d 56 10 1e 1f 5a ..5.5..n...V...Z >>>>> 0380 - ba ec e4 fe 1a 92 b4 31-35 43 1d 99 b9 12 fa ff .......15C...... >>>>> 0390 - 99 2b 88 e0 58 ec 9c dc-8f 67 ef 2a c2 e2 64 5d .+..X....g.*..d] >>>>> 03a0 - 66 76 1c d0 aa 00 30 59-b1 f5 b1 55 9f ad 60 e9 fv....0Y...U..`. >>>>> 03b0 - 3d 03 1e d0 8b 4d bf 74-ac bc bb 1c 83 14 c5 e0 =....M.t........ >>>>> 03c0 - f4 fc 70 9e f4 22 a0 78-04 fe c8 b1 17 65 f6 94 ..p..".x.....e.. >>>>> 03d0 - 47 82 50 4a b6 32 74 ae-5b 38 5a 2e d9 b0 6a 45 G.PJ.2t.[8Z...jE >>>>> 03e0 - 74 e8 f0 22 fe d3 b0 11-c3 fd 72 4f da 77 7a ba t.."......rO.wz. >>>>> 03f0 - 26 3e 61 0c 63 21 17 a6-b2 13 6e 71 5c f2 0d ad &>a.c!....nq\... >>>>> 0400 - f2 d1 19 71 51 9e a4 1b-b0 30 24 e0 71 7d 87 80 ...qQ....0$.q}.. >>>>> 0410 - a9 5a e9 bc db e4 4f 50-4d a1 bc bc 2c 4b 66 98 .Z....OPM...,Kf. >>>>> 0420 - d4 e4 b0 76 0f d2 db a5-a5 39 9e f2 5b ea 34 c1 ...v.....9..[.4. >>>>> 0430 - 62 ab 47 51 3b 37 17 45-54 31 18 f3 f1 ca 17 03 b.GQ;7.ET1...... >>>>> 0440 - 03 01 19 dd 50 50 f5 0c-f2 c9 3c b4 8f 63 cc 4a ....PP....<..c.J >>>>> 0450 - a7 50 c9 91 9b 79 9a 2a-5c 47 d3 77 f6 56 69 90 .P...y.*\G.w.Vi. >>>>> 0460 - 98 cd ff bd c1 2a 49 fc-0d d4 7e cc 7e 44 af c4 .....*I...~.~D.. >>>>> 0470 - 61 47 e0 c1 76 b1 8c 2e-df 7e d0 82 e1 89 1f 04 aG..v....~...... >>>>> 0480 - ae 64 bd 71 4d ae 1c 3c-e3 d3 39 5d 61 2a ea 70 .d.qM..<..9]a*.p >>>>> 0490 - 8c 31 6d a0 b1 72 a8 7a-5c 9c 11 08 b8 4d a5 c4 .1m..r.z\....M.. >>>>> 04a0 - ad 1b 38 4a 6a 02 28 d4-d1 0f c8 9f 0b b3 02 18 ..8Jj.(......... >>>>> 04b0 - 82 2b bd 46 82 04 64 f0-41 b2 da f5 cd 9c f7 f3 .+.F..d.A....... >>>>> 04c0 - 73 30 58 ca 12 ec ea 90-85 1c 75 09 0a 70 b8 80 s0X.......u..p.. >>>>> 04d0 - 3d 02 17 3e 9b 83 04 b5-dd 9e e6 18 17 65 83 a5 =..>.........e.. >>>>> 04e0 - 59 7d 4b 98 da bd 8b aa-d6 aa c5 1c 7d 87 56 e3 Y}K.........}.V. >>>>> 04f0 - 74 d8 e9 7b eb b3 3d f7-7c 3c 0a e9 a8 2e 04 0d t..{..=.|<...... >>>>> 0500 - 6a e7 83 e0 ec 99 43 6a-8b 1c 73 59 7a c8 cd 6e j.....Cj..sYz..n >>>>> 0510 - 4a 14 73 ff 9a fb 71 94-d5 50 a9 d9 e0 dd 02 4c J.s...q..P.....L >>>>> 0520 - 2b 67 9e da 9e fa 2d 67-49 df 13 10 ed 35 3e 73 +g....-gI....5>s >>>>> 0530 - 07 20 17 fb 0b ef f6 d0-b7 68 1c 65 21 a6 e3 3b . .......h.e!..; >>>>> 0540 - bf 7b 84 cd 9e f5 76 2a-0d 4f b8 c3 c8 15 08 e9 .{....v*.O...... >>>>> 0550 - 0f 3c 50 49 12 97 a8 d7-f1 a3 16 da 17 03 03 00 .>>>> 0560 - 35 22 dd a2 9d 25 98 2c-35 b8 00 29 fa a1 dd ba 5"...%.,5..).... >>>>> 0570 - 72 b9 fe e5 85 85 f0 f1-3b 4e f5 7c 58 c8 2a da r.......;N.|X.*. >>>>> 0580 - d2 75 94 3b c1 7a 7c 7e-db 5b fe 8a 2d 3f 8c 9a .u.;.z|~.[..-?.. >>>>> 0590 - 6e 79 ab 2b ff 1a ny.+.. >>>>> SSL_accept:SSLv3/TLS write finished >>>>> SSL_accept:TLSv1.3 early data >>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>> 0000 - 14 03 03 00 01 ..... >>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (1 bytes => 1 (0x1)) >>>>> 0000 - 01 . >>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>> 0000 - 17 03 03 00 3d ....= >>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (61 bytes => 61 (0x3D)) >>>>> 0000 - 38 e7 bb 2c 5b af b6 5f-37 d8 3e 7e bb f4 04 f5 8..,[.._7.>~.... >>>>> 0010 - e1 28 b5 e5 07 5a ec ce-da 2f f3 b6 45 61 cf ef .(...Z.../..Ea.. >>>>> 0020 - 90 fb 57 b8 f3 20 45 27-60 d4 26 51 38 77 e4 bc ..W.. E'`.&Q8w.. >>>>> 0030 - b7 64 d4 8b 73 25 41 9e-fe d3 9d 5f 53 .d..s%A...._S >>>>> SSL_accept:TLSv1.3 early data >>>>> write to 0x7fe400f050c0 [0x7fe403018a00] (24 bytes => 24 (0x18)) >>>>> 0000 - 17 03 03 00 13 25 85 60-eb 7d c1 a8 15 49 d5 63 .....%.`.}...I.c >>>>> 0010 - 18 7f c6 ac ed 7f df 77- .......w >>>>> SSL3 alert write:fatal:unknown >>>>> SSL_accept:error in error >>>>> ERROR >>>>> 140736092021632:error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate:ssl/statem/statem_srvr.c:3654: >>>>> shutting down SSL >>>>> CONNECTION CLOSED >>>>> >>>>> >>>>> >>>>> When using openssl s_client all works as expected tho (thats also true if I use my native implementation on the client and server side that uses openssl): >>>>> >>>>> ./bin/openssl s_client -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 -state -tls1_3 -connect localhost:8443 >>>>> >>>>> The interesting thing is if I use ?-verify 1? and not ?-Verify 1? with openssl which tells it I want to request a certificate but will also process if none is provided I receive the certificate at some point as seen here: >>>>> >>>>> SSL_accept:before SSL initialization >>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>> 0000 - 16 03 03 01 60 ....` >>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (352 bytes => 352 (0x160)) >>>>> 0000 - 01 00 01 5c 03 03 61 c0-b3 ed 88 65 e6 cf 11 3f ...\..a....e...? >>>>> 0010 - c0 e0 f8 df a6 63 32 c2-ab 3d 61 6f 41 ed b1 4b .....c2..=aoA..K >>>>> 0020 - 53 0e 83 e5 a1 b8 20 c7-1b 8c b8 e6 b5 da 4e 4e S..... .......NN >>>>> 0030 - 3f 3c 61 7a ad 58 23 94-a7 32 79 2f db 9f 21 c0 ?>>>> 0040 - 8e 0c c5 ce b1 c2 a4 00-14 c0 2c c0 2b c0 2f c0 ..........,.+./. >>>>> 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 52 dc d6 47 6e .3.G.E...A.R..Gn >>>>> 0120 - a1 de 9c 71 c2 54 0e 5c-9b 57 fb c8 aa 3f 19 f7 ...q.T.\.W...?.. >>>>> 0130 - d3 a4 25 12 fa 3f 6c 6d-95 30 66 ca 63 b7 a1 dd ..%..?lm.0f.c... >>>>> 0140 - ae 9f 99 d6 a8 6b 20 4f-29 7a 74 58 ad 58 de 12 .....k O)ztX.X.. >>>>> 0150 - d7 a5 9b 69 dc 27 ac ec-9e d4 04 ff 01 00 01 00 ...i.'.......... >>>>> 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 0x7fdc58809fb0 [0x7fdc59025e00] (1430 bytes => 1430 (0x596)) >>>>> 0000 - 16 03 03 00 9b 02 00 00-97 03 03 8b c8 62 48 6c .............bHl >>>>> 0010 - f5 7c 73 d9 17 f8 63 a2-11 27 40 93 09 26 53 06 .|s...c..'@..&S. >>>>> 0020 - b3 62 df 46 26 b6 dc 59-29 b5 58 20 c7 1b 8c b8 .b.F&..Y).X .... >>>>> 0030 - e6 b5 da 4e 4e 3f 3c 61-7a ad 58 23 94 a7 32 79 ...NN?>>>> 0040 - 2f db 9f 21 c0 8e 0c c5-ce b1 c2 a4 13 01 00 00 /..!............ >>>>> 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 O.+.....3.E...A. >>>>> 0060 - 07 63 1c 19 53 89 68 a8-0f ea 9e 4c 18 6f 2a ad .c..S.h....L.o*. >>>>> 0070 - 2a df eb 17 a2 08 94 c6-e3 c5 97 ae 0f c1 1a d7 *............... >>>>> 0080 - 0d d7 2e 6d 77 3d 30 a0-07 db 70 35 bb 37 dd 1e ...mw=0...p5.7.. >>>>> 0090 - b6 f3 4d cb 13 97 7c 11-63 98 e8 64 2d a7 e6 cc ..M...|.c..d-... >>>>> 00a0 - 14 03 03 00 01 01 17 03-03 00 27 a3 73 d2 ee 2c ..........'.s.., >>>>> 00b0 - 2f 9c 8f 95 7f ca a3 89-bc b4 b3 b2 3c 8b 23 ef /...........<.#. >>>>> 00c0 - 36 66 23 c9 09 02 33 0d-dc 5d 36 61 44 89 8b ef 6f#...3..]6aD... >>>>> 00d0 - fd 13 17 03 03 00 42 f2-5b 3c 0c 27 5e 7f 97 4f ......B.[<.'^..O >>>>> 00e0 - 0f de 8c b9 0a a1 41 c7-c2 1e 92 99 6a d5 bd 12 ......A.....j... >>>>> 00f0 - 38 b6 b7 93 33 e9 8e 0f-44 93 f0 69 58 b6 41 22 8...3...D..iX.A" >>>>> 0100 - 46 e2 4a d5 d6 32 2b b8-a7 ae 3a c2 c5 2f e6 35 F.J..2+...:../.5 >>>>> 0110 - 11 0c f1 9a 35 2a 87 ed-9e 17 03 03 03 20 a7 e2 ....5*....... .. >>>>> 0120 - fe ba c7 10 5b 9c cd 94-67 19 37 2d 46 59 ab 56 ....[...g.7-FY.V >>>>> 0130 - 6b dd a4 10 61 cc ed f1-71 a7 2d 6a 41 2e 2b da k...a...q.-jA.+. >>>>> 0140 - d1 35 fc 01 df 49 e5 90-1d 9b b2 03 0a 81 58 18 .5...I........X. >>>>> 0150 - 96 a1 db 31 19 98 35 5c-87 8f 6e 32 0a e6 c0 aa ...1..5\..n2.... >>>>> 0160 - 9e 8e 72 e2 34 b3 b7 a3-d6 d1 66 c7 ce 93 fe 78 ..r.4.....f....x >>>>> 0170 - 17 c4 71 7c 42 15 c8 af-dc 4f 50 42 51 80 fc bf ..q|B....OPBQ... >>>>> 0180 - fc 54 d5 d8 59 20 9a 90-c4 78 97 9c 2d 4a d5 58 .T..Y ...x..-J.X >>>>> 0190 - be 81 79 23 59 22 9d 27-f8 bd a0 b2 98 b3 47 82 ..y#Y".'......G. >>>>> 01a0 - d3 52 b5 b5 91 ab 5c 76-52 c5 a5 95 2d 03 1c b7 .R....\vR...-... >>>>> 01b0 - 64 4d 0b 88 7f 15 0b c8-a8 90 50 9a b6 b1 9f b7 dM........P..... >>>>> 01c0 - 40 09 f2 5f 39 f8 9a 06-21 4d 67 10 0a 67 08 b6 @.._9...!Mg..g.. >>>>> 01d0 - b5 9a 25 8c d5 ca 31 6a-8a 6b 01 93 7d 6f 1e 52 ..%...1j.k..}o.R >>>>> 01e0 - 98 96 9d fb e8 c1 07 ab-57 98 2d 1e 75 77 ef c2 ........W.-.uw.. >>>>> 01f0 - 49 78 e0 b9 2b 32 23 7e-95 4d 3e 27 00 61 86 0c Ix..+2#~.M>'.a.. >>>>> 0200 - 47 c7 79 e4 ee 9d ba c0-ea 62 f1 0d 8e 4a 91 30 G.y......b...J.0 >>>>> 0210 - bc 4f 5a 98 26 30 66 ec-c4 63 8f 28 d5 1c 61 23 .OZ.&0f..c.(..a# >>>>> 0220 - ea e9 90 4e 36 d9 fa 31-7b 14 27 22 0a ae 9f 64 ...N6..1{.'"...d >>>>> 0230 - 40 3d e5 a0 5c 9d 3c 04-71 09 b0 7a 6b 51 a0 9c @=..\.<.q..zkQ.. >>>>> 0240 - c0 61 32 ce 15 62 8e 29-b1 59 91 c0 17 2c b3 c5 .a2..b.).Y...,.. >>>>> 0250 - f9 ed 07 65 3d 11 de 98-de 62 36 50 74 37 af 2d ...e=....b6Pt7.- >>>>> 0260 - 7d 86 55 c4 3e a2 83 ab-47 8d f2 b2 8d 1d 75 83 }.U.>...G.....u. >>>>> 0270 - b5 e4 41 87 a7 a3 85 b0-5e 4e 2e 9c 8c b0 1b 83 ..A.....^N...... >>>>> 0280 - 7b 54 79 c9 60 ea 7d ed-06 fa dd 24 40 f1 53 9e {Ty.`.}....$@.S. >>>>> 0290 - 43 79 25 53 9c c7 6e 95-ab 9f 96 59 cd b9 7b a8 Cy%S..n....Y..{. >>>>> 02a0 - a0 23 13 69 db a9 c9 e7-1a 8e e1 9b 54 94 1c 44 .#.i........T..D >>>>> 02b0 - 50 08 8b dd eb 4e 2b bb-d7 c9 c2 33 8c a1 b3 65 P....N+....3...e >>>>> 02c0 - 06 e6 9d ac 11 16 21 58-40 8d 59 e6 67 e5 31 02 ......!X at .Y.g.1. >>>>> 02d0 - 15 8d 29 80 20 66 ba c3-56 93 95 5c 65 4b 41 00 ..). f..V..\eKA. >>>>> 02e0 - c5 71 12 12 f5 20 4f 59-be 77 06 10 6e 48 85 5c .q... OY.w..nH.\ >>>>> 02f0 - ff a2 c4 ae fb 4d 95 f5-cc f6 61 20 33 b7 92 1d .....M....a 3... >>>>> 0300 - ac a8 f1 b2 b0 88 c6 7b-8b 00 53 30 6d 4a d1 42 .......{..S0mJ.B >>>>> 0310 - b3 3e 85 f5 84 e1 c6 ab-10 9d 61 03 46 ff 2d 81 .>........a.F.-. >>>>> 0320 - 15 4f 84 d1 4c ee f4 a6-a0 ec 50 60 a0 d1 ff df .O..L.....P`.... >>>>> 0330 - 8a 97 f6 7d fb 8f fb 60-18 d4 f1 1f 92 4d d8 69 ...}...`.....M.i >>>>> 0340 - b1 92 97 44 0f 3c 8a aa-47 07 48 d4 07 2d 3e f2 ...D.<..G.H..->. >>>>> 0350 - c4 a7 16 35 a7 17 71 ef-98 84 24 67 12 58 30 3b ...5..q...$g.X0; >>>>> 0360 - 1d 41 8d e5 12 52 95 64-e5 88 35 99 d7 c3 58 40 .A...R.d..5...X@ >>>>> 0370 - f9 55 9b 9f e5 33 15 70-41 d7 45 ba a4 fc 75 ea .U...3.pA.E...u. >>>>> 0380 - a4 ae f0 68 ea 64 d8 f5-06 68 a9 75 22 4d 43 cc ...h.d...h.u"MC. >>>>> 0390 - ff 50 cc ac 6e fd 43 dd-eb e4 c8 dd 4b 6c 12 bb .P..n.C.....Kl.. >>>>> 03a0 - f1 d4 5e 11 4a 86 90 0b-f8 3a 2e 23 db 61 5a 1f ..^.J....:.#.aZ. >>>>> 03b0 - 7e 11 00 92 21 68 1f b5-ab f2 f8 38 5e 62 ea f8 ~...!h.....8^b.. >>>>> 03c0 - da ef c2 6e a0 b8 20 e4-69 49 b3 1f 15 84 0b 9b ...n.. .iI...... >>>>> 03d0 - ce b0 6f 36 32 7f 7e bf-e8 d7 18 7a 58 60 f4 04 ..o62.~....zX`.. >>>>> 03e0 - cc 36 bf 06 cd ec e5 9b-19 03 96 09 fb af 8f c3 .6.............. >>>>> 03f0 - 98 b4 02 aa e8 55 81 aa-c4 fe 06 81 30 a0 c7 b2 .....U......0... >>>>> 0400 - f8 e2 30 00 d7 a0 54 7f-5f d7 ef a6 f8 41 58 34 ..0...T._....AX4 >>>>> 0410 - f5 f0 18 69 8d e6 7a 23-78 90 8f b1 05 c5 b5 7f ...i..z#x....... >>>>> 0420 - e0 f2 c7 fa c8 36 5b 53-7e cf e6 75 d3 54 b4 69 .....6[S~..u.T.i >>>>> 0430 - 68 43 0d 6a d2 83 cc 13-6d ca bf 83 3c 90 17 03 hC.j....m...<... >>>>> 0440 - 03 01 19 96 dc 49 26 ce-1d 8e 86 3d bd cb 00 5e .....I&....=...^ >>>>> 0450 - ee f6 e7 1d 16 7a ca ef-fa 6d 16 40 b6 99 d0 c1 .....z...m. at .... >>>>> 0460 - df 0b 5f 51 60 a8 24 e0-61 82 13 40 da 88 38 3a .._Q`.$.a.. at ..8: >>>>> 0470 - 26 1d 80 51 c4 b1 95 35-95 3c 91 35 28 17 49 d8 &..Q...5.<.5(.I. >>>>> 0480 - c3 45 be 32 98 3e 02 07-3b 01 20 2b 51 e1 1a 94 .E.2.>..;. +Q... >>>>> 0490 - b9 be 96 aa 7a 13 09 ff-d5 a9 63 d4 6f 49 cb b5 ....z.....c.oI.. >>>>> 04a0 - 23 ab 7f 8c e2 63 f0 5c-5c 27 1e 04 a8 71 0c c0 #....c.\\'...q.. >>>>> 04b0 - 89 cd ed 18 8d 5b 75 ac-af f3 68 6d cc ba 20 38 .....[u...hm.. 8 >>>>> 04c0 - b5 7c 09 47 29 28 e2 26-57 57 1f f0 f3 18 fd 6f .|.G)(.&WW.....o >>>>> 04d0 - 27 42 a4 e3 de bb e5 d6-09 7d 25 b1 98 97 ad 33 'B.......}%....3 >>>>> 04e0 - 68 35 92 07 80 23 f1 66-20 5d 74 f3 02 c5 51 ff h5...#.f ]t...Q. >>>>> 04f0 - 07 a9 e9 0e 3e 74 da 2e-8f 3b 16 be e6 94 1b 66 ....>t...;.....f >>>>> 0500 - bb b2 a2 1e 7c 7b ff 5e-a4 36 2a ba 0b cd 7f e9 ....|{.^.6*..... >>>>> 0510 - 86 bb 5e 30 f5 57 92 52-82 b6 2e da 71 b7 22 c2 ..^0.W.R....q.". >>>>> 0520 - 90 c4 69 46 07 df 6c 3f-05 8b 19 3e ce b9 75 0d ..iF..l?...>..u. >>>>> 0530 - 4b 97 37 ae 94 e2 d6 3c-91 e6 82 c7 a1 78 79 2c K.7....<.....xy, >>>>> 0540 - 9a a3 d5 45 94 ad e2 c8-ab fd 81 ec 62 87 f7 75 ...E........b..u >>>>> 0550 - e3 70 79 8e 82 3b c5 45-0d d0 33 5f 17 03 03 00 .py..;.E..3_.... >>>>> 0560 - 35 da e0 74 2a 06 41 5a-64 1e 54 94 29 73 43 3f 5..t*.AZd.T.)sC? >>>>> 0570 - e5 24 a8 ba b2 7e 6b 26-82 fc d9 f6 dd 19 05 4a .$...~k&.......J >>>>> 0580 - 2c 1a f3 bb 16 1d 38 95-a6 d3 a8 58 f6 a3 41 c7 ,.....8....X..A. >>>>> 0590 - 92 44 35 24 25 0e .D5$%. >>>>> SSL_accept:SSLv3/TLS write finished >>>>> SSL_accept:TLSv1.3 early data >>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>> 0000 - 14 03 03 00 01 ..... >>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (1 bytes => 1 (0x1)) >>>>> 0000 - 01 . >>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>> 0000 - 17 03 03 00 3d ....= >>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (61 bytes => 61 (0x3D)) >>>>> 0000 - ad dd 3e d9 ee ab 56 65-50 1c 72 2a d8 62 7f 90 ..>...VeP.r*.b.. >>>>> 0010 - 13 71 7d 37 39 40 fb 89-8f 05 4b 39 44 9d 4d 67 .q}79 at ....K9D.Mg >>>>> 0020 - e3 41 29 b6 3e e8 fe 04-1b 8e eb 7a 4c e2 14 a0 .A).>......zL... >>>>> 0030 - b1 c2 47 3f 94 35 ed ab-8a d1 75 3b ba ..G?.5....u;. >>>>> SSL_accept:TLSv1.3 early data >>>>> SSL_accept:SSLv3/TLS read client certificate >>>>> SSL_accept:SSLv3/TLS read finished >>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>> 0000 - 17 03 03 00 da 52 1f 48-00 f4 31 13 90 7f 9c c2 .....R.H..1..... >>>>> 0010 - fc 70 1a fc f7 4a 48 e7-31 ad 37 ab b5 2b 4e 5c .p...JH.1.7..+N\ >>>>> 0020 - e8 d8 6d e9 af 6c 4f c1-9e 7b ea ff ef b3 eb 74 ..m..lO..{.....t >>>>> 0030 - 27 67 10 21 66 5b 32 13-31 bc 99 d5 1c 6c 79 55 'g.!f[2.1....lyU >>>>> 0040 - f3 3e f6 4b 07 4d a9 78-3d 12 8a f5 38 ef d9 f4 .>.K.M.x=...8... >>>>> 0050 - 48 e0 2c 35 94 06 4f eb-09 e6 70 fb 59 95 7a c8 H.,5..O...p.Y.z. >>>>> 0060 - 24 dd 24 e2 f9 63 b9 3c-f2 66 86 c4 73 44 53 fd $.$..c.<.f..sDS. >>>>> 0070 - ca 67 8f 01 d6 db 70 f9-60 bc 50 11 51 72 dc 63 .g....p.`.P.Qr.c >>>>> 0080 - 12 ca 4f 23 e2 c5 d1 1d-e5 b0 d4 ec 89 ca 28 be ..O#..........(. >>>>> 0090 - 9c 30 83 40 02 a4 62 a8-5c b3 20 1a ab 39 b7 7b .0. at ..b.\. ..9.{ >>>>> 00a0 - 89 13 39 87 73 be a8 f8-60 13 31 0a 48 5c 79 b9 ..9.s...`.1.H\y. >>>>> 00b0 - cc 4a 51 e3 0d d2 b4 93-c0 1f 3a 22 b3 fa 24 a0 .JQ.......:"..$. >>>>> 00c0 - 7c f6 76 79 d0 2d 5b 1a-ff a6 e9 e1 40 d3 b1 8c |.vy.-[..... at ... >>>>> 00d0 - 0a fa fa de f3 8e d6 ad-9a 22 6b 67 0b 88 18 ........."kg... >>>>> SSL_accept:SSLv3/TLS write session ticket >>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>> 0000 - 17 03 03 00 da 46 aa ea-6a 37 b1 35 e8 41 c8 b3 .....F..j7.5.A.. >>>>> 0010 - 84 25 af 1c 36 a3 6d 78-a4 44 4a 83 52 ef 13 7c .%..6.mx.DJ.R..| >>>>> 0020 - 8f 18 d3 4c f8 22 c8 b3-ad d0 d0 5b 47 a0 43 da ...L.".....[G.C. >>>>> 0030 - d2 6e 04 8f dc c9 56 90-58 87 62 63 4c cc 31 ec .n....V.X.bcL.1. >>>>> 0040 - b8 c9 18 be 41 32 e1 3c-00 41 2a f1 4d 5c 2d 44 ....A2.<.A*.M\-D >>>>> 0050 - 8c aa e1 f0 ed 38 ee 44-64 e5 fd ea 58 3b 84 5d .....8.Dd...X;.] >>>>> 0060 - 83 39 21 2e fe 79 4d 76-10 65 87 0f 3c ac df 28 .9!..yMv.e..<..( >>>>> 0070 - 49 f8 60 eb be 49 e4 0a-0b 6a 03 2b 9d cf 9b a5 I.`..I...j.+.... >>>>> 0080 - 03 56 58 32 c2 b2 59 f9-0a 0d f0 ae af ff 20 19 .VX2..Y....... . >>>>> 0090 - e5 6e e4 86 2f 5e 3f 7d-47 d5 73 ae 89 48 a7 66 .n../^?}G.s..H.f >>>>> 00a0 - fb 2d 83 60 e8 8b ab 27-12 db 24 78 54 eb 14 2d .-.`...'..$xT..- >>>>> 00b0 - b7 c6 17 2d 3c 91 57 ac-6e 35 b8 c3 fa c2 42 48 ...-<.W.n5....BH >>>>> 00c0 - 2a cb aa 98 32 89 8a ce-0c f7 cd 5e fb bf 6d 33 *...2......^..m3 >>>>> 00d0 - 08 50 cf 1e 06 bb a1 98-be a4 a9 51 9a b0 34 .P.........Q..4 >>>>> SSL_accept:SSLv3/TLS write session ticket >>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>> 0000 - 17 03 03 00 12 c5 9b 73-cc 91 7e 48 cb 25 31 a0 .......s..~H.%1. >>>>> 0010 - 67 41 db bb 0f 62 d8 gA...b. >>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>> 0000 - 17 03 03 00 12 0f dd 3f-c1 7c e6 b0 cc ea f0 13 .......?.|...... >>>>> 0010 - 00 d8 01 de ef 7c bb .....|. >>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>> 0000 - 17 03 03 00 1e ..... >>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (30 bytes => 30 (0x1E)) >>>>> 0000 - d6 88 44 82 cb 23 16 ba-c9 a4 fb 55 51 08 90 c1 ..D..#.....UQ... >>>>> 0010 - bf bd a1 7f 0e 37 b0 b4-b5 df f1 07 6c 07 .....7......l. >>>>> I am a clientwrite to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>> 0000 - 17 03 03 00 12 c0 70 5d-14 e7 69 57 0a d8 64 16 ......p]..iW..d. >>>>> 0010 - 0c 90 06 0f c3 4d 1d .....M. >>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>> 0000 - 17 03 03 00 13 ..... >>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (19 bytes => 19 (0x13)) >>>>> 0000 - 60 28 5b ff bb 0d 9f 96-9a 2d cb fd 60 eb 96 62 `([......-..`..b >>>>> 0010 - 53 e6 25 S.% >>>>> SSL3 alert read:warning:close notify >>>>> DONE >>>>> shutting down SSL >>>>> CONNECTION CLOSED >>>>> >>>>> >>>>> I am using the following JDK version on MacOS: >>>>> >>>>> ssl git:(cert_cb_openssl_1_1_1) ? /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java -version >>>>> java version "11" 2018-09-25 >>>>> Java(TM) SE Runtime Environment 18.9 (build 11+28) >>>>> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) >>>>> >>>>> For this to work you will need to have openssl 1.1.1 installed. >>>>> >>>>> Any help would be welcome, >>>>> Norman >>>>> >>>>> [1] https://github.com/netty/netty-tcnative >>>>> >>>>> >>>>> From will.sargent at gmail.com Sun Sep 16 19:37:21 2018 From: will.sargent at gmail.com (Will Sargent) Date: Sun, 16 Sep 2018 12:37:21 -0700 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> Message-ID: > 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 don't know of any research or papers that explicitly say that SecurityManager is "legacy". I did some research into this a while ago, and while SecurityManager has some major flaws, I don't know of any other way to sandbox a Java application. I went through two sample projects and found a way to use Byte Buddy to disable SecurityManager so that it could not be disabled: https://tersesystems.com/blog/2015/12/22/an-easy-way-to-secure-java-applications/ https://tersesystems.com/blog/2015/12/29/sandbox-experiment/ https://github.com/johnlcox/sandbox-runtime If there is a way to do this without involving the security manager that would be great -- likewise, if there's any docs on how it's just not up to the task, that would be good too. Thanks, Will Sargent. On Fri, Sep 14, 2018 at 6:22 AM 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). > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Sep 17 08:17:02 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 17 Sep 2018 16:17:02 +0800 Subject: RFR 8210821: Support dns_canonicalize_hostname in krb5.conf Message-ID: <49DF7170-4E18-431D-A733-10507625BCB9@oracle.com> Please review the code change and CSR at http://cr.openjdk.java.net/~weijun/8210821/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8210822 Thanks Max From Alan.Bateman at oracle.com Mon Sep 17 09:09:48 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 17 Sep 2018 10:09:48 +0100 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> Message-ID: On 16/09/2018 20:37, Will Sargent wrote: > > 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 don't know of any research or papers that explicitly say that > SecurityManager is "legacy".? I did some research into this a while > ago, and while SecurityManager has some major flaws, I don't know of > any other way to sandbox a Java application. > Have you looked into native containers? It's easy to find examples of applications running in a docker container for example. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman.maurer at googlemail.com Mon Sep 17 10:39:05 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 17 Sep 2018 12:39:05 +0200 Subject: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: References: <32bad254-1a8c-7933-d5a0-0b8ce3ed2f68@oracle.com> <05EF82F5-6506-4928-8030-B9BEEE64E1F1@googlemail.com> Message-ID: <0EB21A4C-7DFF-4878-9446-182DA35F0A8C@googlemail.com> Hi all, As requested I pushed a pure JDK reproducer to GitHub which you can easily use to reproduce the problem. All the details how to run it etc are in the README.md file. I also included a server to show that all works if we use the JDK on the client side and server side. Also as stated before you will see that the cert will be send even if you use OpenSSL on the serverside if you replace ?-Verify 1? with ?-verify 1? (which is kind of the same as setWantClientAuth(true)). Please don't hesitate to ping me if you need any more details or have any more questions. https://github.com/normanmaurer/jdktls13bugreproducer Here is the output with debugging enabled on the client side. javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.515 CEST|SSLContextImpl.java:427|System property jdk.tls.client.cipherSuites is set to 'null' javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.529 CEST|SSLContextImpl.java:427|System property jdk.tls.server.cipherSuites is set to 'null' javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.563 CEST|SSLCipher.java:437|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.577 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.577 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.580 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.580 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_RC4_128_MD5 javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_RC4_128_MD5 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_WITH_RC4_128_MD5 javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_WITH_RC4_128_MD5 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5 javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.591 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.593 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.593 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.599 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.599 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.642 CEST|SunX509KeyManagerImpl.java:164|found key for : 1 ( "certificate" : { "version" : "v3", "serial number" : "20 C3 8D C4 49 66 D0 02", "signature algorithm": "SHA256withRSA", "issuer" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", "not before" : "2013-08-02 09:51:36.000 CEST", "not after" : "10000-01-01 24:59:59.000 CET", "subject" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", "subject public key" : "RSA"} ) javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 CEST|SSLContextImpl.java:115|trigger seeding of SecureRandom javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 CEST|SSLContextImpl.java:119|done seeding of SecureRandom javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.665 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_128_GCM_SHA256 for TLS12 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.666 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_256_GCM_SHA384 for TLS12 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_128_GCM_SHA256 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_256_GCM_SHA384 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS11 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_128_GCM_SHA256 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_256_GCM_SHA384 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS10 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS10 javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.690 CEST|ServerNameExtension.java:255|Unable to indicate server name javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.690 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: server_name javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.701 CEST|SignatureScheme.java:282|Signature algorithm, ed25519, is not supported by the underlying providers javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.702 CEST|SignatureScheme.java:282|Signature algorithm, ed448, is not supported by the underlying providers javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.706 CEST|SignatureScheme.java:358|Ignore disabled signature sheme: rsa_md5 javax.net.ssl|INFO|01|main|2018-09-17 11:51:54.706 CEST|AlpnExtension.java:161|No available application protocols javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.706 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: application_layer_protocol_negotiation javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.707 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: cookie javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: renegotiation_info javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 CEST|PreSharedKeyExtension.java:606|No session to resume. javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: pre_shared_key javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 CEST|ClientHello.java:633|Produced ClientHello handshake message ( "ClientHello": { "client version" : "TLSv1.2", "random" : "66 2E BE D3 8A 77 39 06 3B 5A 34 03 7D EE 74 BB 08 D2 19 FD 50 17 2D 84 29 AA FB E0 EE ED 50 69", "session id" : "0B 03 C8 E2 D2 A5 CD 3A 22 C5 85 17 06 64 A9 30 14 62 C0 AF AB 67 CE 63 50 41 50 7F 6B FD 4C 9F", "cipher suites" : "[TLS_AES_128_GCM_SHA256(0x1301), TLS_AES_256_GCM_SHA384(0x1302), TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]", "compression methods" : "00", "extensions" : [ "status_request (5)": { "certificate status type": ocsp "OCSP status request": { "responder_id": "request extensions": { } } }, "supported_groups (10)": { "versions": [secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] }, "ec_point_formats (11)": { "formats": [uncompressed] }, "signature_algorithms (13)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] }, "signature_algorithms_cert (50)": { "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] }, "status_request_v2 (17)": { "cert status request": { "certificate status type": ocsp_multi "OCSP status request": { "responder_id": "request extensions": { } } } }, "extended_master_secret (23)": { }, "supported_versions (43)": { "versions": [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1] }, "psk_key_exchange_modes (45)": { "ke_modes": [psk_dhe_ke] }, "key_share (51)": { "client_shares": [ { "named group": secp256r1 "key_exchange": { 0000: 04 A3 9F B9 05 27 00 38 C4 D7 61 6C 66 1F 4A 8D .....'.8..alf.J. 0010: B1 02 6F 0B F6 E1 BD 50 93 52 86 2C D2 3C 8D 1A ..o....P.R.,.<.. 0020: 10 A9 CD F0 40 F4 CD 04 25 A1 11 E2 58 23 A3 24 .... at ...%...X#.$ 0030: CA E8 8F 28 F7 2B 65 96 B2 E3 A1 AE 99 24 94 28 ...(.+e......$.( 0040: 83 } }, ] } ] } ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 417 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.719 CEST|SSLSocketOutputRecord.java:255|Raw write ( 0000: 16 03 03 01 A1 01 00 01 9D 03 03 66 2E BE D3 8A ...........f.... 0010: 77 39 06 3B 5A 34 03 7D EE 74 BB 08 D2 19 FD 50 w9.;Z4...t.....P 0020: 17 2D 84 29 AA FB E0 EE ED 50 69 20 0B 03 C8 E2 .-.).....Pi .... 0030: D2 A5 CD 3A 22 C5 85 17 06 64 A9 30 14 62 C0 AF ...:"....d.0.b.. 0040: AB 67 CE 63 50 41 50 7F 6B FD 4C 9F 00 5A 13 01 .g.cPAP.k.L..Z.. 0050: 13 02 C0 2C C0 2B C0 30 00 9D C0 2E C0 32 00 9F ...,.+.0.....2.. 0060: 00 A3 C0 2F 00 9C C0 2D C0 31 00 9E 00 A2 C0 24 .../...-.1.....$ 0070: C0 28 00 3D C0 26 C0 2A 00 6B 00 6A C0 0A C0 14 .(.=.&.*.k.j.... 0080: 00 35 C0 05 C0 0F 00 39 00 38 C0 23 C0 27 00 3C .5.....9.8.#.'.< 0090: C0 25 C0 29 00 67 00 40 C0 09 C0 13 00 2F C0 04 .%.).g. at ...../.. 00A0: C0 0E 00 33 00 32 00 FF 01 00 00 FA 00 05 00 05 ...3.2.......... 00B0: 01 00 00 00 00 00 0A 00 20 00 1E 00 17 00 18 00 ........ ....... 00C0: 19 00 09 00 0A 00 0B 00 0C 00 0D 00 0E 00 16 01 ................ 00D0: 00 01 01 01 02 01 03 01 04 00 0B 00 02 01 00 00 ................ 00E0: 0D 00 28 00 26 04 03 05 03 06 03 08 04 08 05 08 ..(.&........... 00F0: 06 08 09 08 0A 08 0B 04 01 05 01 06 01 04 02 03 ................ 0100: 03 03 01 03 02 02 03 02 01 02 02 00 32 00 28 00 ............2.(. 0110: 26 04 03 05 03 06 03 08 04 08 05 08 06 08 09 08 &............... 0120: 0A 08 0B 04 01 05 01 06 01 04 02 03 03 03 01 03 ................ 0130: 02 02 03 02 01 02 02 00 11 00 09 00 07 02 00 04 ................ 0140: 00 00 00 00 00 17 00 00 00 2B 00 09 08 03 04 03 .........+...... 0150: 03 03 02 03 01 00 2D 00 02 01 01 00 33 00 47 00 ......-.....3.G. 0160: 45 00 17 00 41 04 A3 9F B9 05 27 00 38 C4 D7 61 E...A.....'.8..a 0170: 6C 66 1F 4A 8D B1 02 6F 0B F6 E1 BD 50 93 52 86 lf.J...o....P.R. 0180: 2C D2 3C 8D 1A 10 A9 CD F0 40 F4 CD 04 25 A1 11 ,.<...... at ...%.. 0190: E2 58 23 A3 24 CA E8 8F 28 F7 2B 65 96 B2 E3 A1 .X#.$...(.+e.... 01A0: AE 99 24 94 28 83 ..$.(. ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 CEST|SSLSocketInputRecord.java:458|Raw read ( 0000: 16 03 03 00 9B ..... ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length = 155 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.721 CEST|SSLSocketInputRecord.java:458|Raw read ( 0000: 02 00 00 97 03 03 AB 76 F1 BA F3 B1 F0 DD 53 AC .......v......S. 0010: 5B 54 E9 E4 2E F8 44 D2 5E B2 59 85 0D 16 79 EE [T....D.^.Y...y. 0020: A7 66 8A 84 69 2A 20 0B 03 C8 E2 D2 A5 CD 3A 22 .f..i* .......:" 0030: C5 85 17 06 64 A9 30 14 62 C0 AF AB 67 CE 63 50 ....d.0.b...g.cP 0040: 41 50 7F 6B FD 4C 9F 13 01 00 00 4F 00 2B 00 02 AP.k.L.....O.+.. 0050: 03 04 00 33 00 45 00 17 00 41 04 18 4A 46 BB 73 ...3.E...A..JF.s 0060: F4 6F 5D F0 3C 98 AD 70 7E 13 D6 C0 E5 C0 28 5A .o].<..p......(Z 0070: D7 42 78 95 68 E0 85 B7 06 CD DB 3C 35 DA AF E8 .Bx.h......<5... 0080: 95 D6 A2 3C 77 CF 7E 8E C8 94 50 BA CD 18 3F DA ....! 0170: DA 1F 71 07 59 C6 A2 F9 0B 4F C0 CD A4 85 A8 DB ..q.Y....O...... 0180: 77 F6 87 5E 09 16 49 5C 2C B8 C0 7B 39 81 65 FD w..^..I\,...9.e. 0190: 29 52 E2 C7 F5 C7 AD BC F6 A9 F9 6D D2 E9 A4 14 )R.........m.... 01A0: C9 D3 79 2E D2 BA 10 4C BD 44 65 2B A8 7E F1 3A ..y....L.De+...: 01B0: F3 F6 11 53 38 17 10 12 B4 CD C5 AD 72 3B 84 A2 ...S8.......r;.. 01C0: 1B F9 D7 BF 34 00 5A FE F4 CE 09 0C EA F2 27 9A ....4.Z.......'. 01D0: BD DD 93 37 E2 DF 60 CC 8A F7 C6 4B 08 30 0D 78 ...7..`....K.0.x 01E0: 5C EB 49 34 DB 8B EB 55 33 0C 82 03 07 FD 3D FC \.I4...U3.....=. 01F0: 49 11 88 1C F6 67 7F 0B 48 AA EC 1B AF 04 46 CF I....g..H.....F. 0200: 09 C5 8E B3 F8 92 C4 56 3D 8F 0E 1D 9F D3 0C FE .......V=....... 0210: 94 23 15 53 8E 1F 5E C4 FA 44 03 3B 1B B0 0A 2D .#.S..^..D.;...- 0220: 71 D4 B5 AC 1F 52 D7 25 9F A0 C8 4B 9B 32 B8 22 q....R.%...K.2." 0230: 3F AF B3 19 16 8C 2A 5C B4 89 BF 82 DC 4D AF 22 ?.....*\.....M." 0240: 2A 33 73 90 F3 C8 FF 2E C1 B3 83 D2 7A 29 4E 15 *3s.........z)N. 0250: 5D 87 86 F6 94 EA B0 B4 A4 41 B9 C5 BA 89 B8 E9 ]........A...... 0260: 26 E7 96 BC 4D 8A FD 86 C7 C9 2A 96 75 C3 07 EF &...M.....*.u... 0270: 5C 5A 4E 91 71 7D 1B A2 12 88 C5 D0 D2 5E 79 E1 \ZN.q........^y. 0280: 6C 65 35 5E 6C CC 56 47 FD F3 96 78 7A A0 08 7E le5^l.VG...xz... 0290: DB 3C CC 10 76 15 37 46 48 6B 2D 23 7B A3 44 5A .<..v.7FHk-#..DZ 02A0: A4 46 B3 CE E2 15 BA 4C D2 93 16 57 1F BA 75 72 .F.....L...W..ur 02B0: BF 8C 66 50 F2 A4 F6 05 84 E5 47 12 30 BE 34 70 ..fP......G.0.4p 02C0: 4D 0F BD FE 54 E8 B1 CE B5 7F 6E 97 38 09 29 1F M...T.....n.8.). 02D0: 41 2D 2E 9E 75 D8 77 0C 08 DB 5C B4 EE 3F FE E2 A-..u.w...\..?.. 02E0: DC CF D0 ED C8 02 50 C4 EE B3 1D 8A 9E 9B EE 5E ......P........^ 02F0: 14 BA C2 5A B0 83 8E 5C E5 7B 69 2B 69 8C F1 AA ...Z...\..i+i... 0300: 2D D5 D1 3D 9D 42 1B B2 50 5D BE 7E E4 11 D2 90 -..=.B..P]...... 0310: 0B 54 71 7F D6 13 88 E2 FE 37 9F 70 B5 0B 57 79 .Tq......7.p..Wy ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.753 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 800 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.755 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( 0000: 0B 00 03 0B 00 00 03 07 00 03 02 30 82 02 FE 30 ...........0...0 0010: 82 01 E6 A0 03 02 01 02 02 08 20 C3 8D C4 49 66 .......... ...If 0020: D0 02 30 0D 06 09 2A 86 48 86 F7 0D 01 01 0B 05 ..0...*.H....... 0030: 00 30 3E 31 3C 30 3A 06 03 55 04 03 0C 33 65 38 .0>1<0:..U...3e8 0040: 61 63 30 32 66 61 30 64 36 35 61 38 34 32 31 39 ac02fa0d65a84219 0050: 30 31 36 30 34 35 64 62 38 62 30 35 63 34 38 35 016045db8b05c485 0060: 62 34 65 63 64 66 2E 6E 65 74 74 79 2E 74 65 73 b4ecdf.netty.tes 0070: 74 30 20 17 0D 31 33 30 38 30 32 30 37 35 31 33 t0 ..13080207513 0080: 36 5A 18 0F 39 39 39 39 31 32 33 31 32 33 35 39 6Z..999912312359 0090: 35 39 5A 30 3E 31 3C 30 3A 06 03 55 04 03 0C 33 59Z0>1<0:..U...3 00A0: 65 38 61 63 30 32 66 61 30 64 36 35 61 38 34 32 e8ac02fa0d65a842 00B0: 31 39 30 31 36 30 34 35 64 62 38 62 30 35 63 34 19016045db8b05c4 00C0: 38 35 62 34 65 63 64 66 2E 6E 65 74 74 79 2E 74 85b4ecdf.netty.t 00D0: 65 73 74 30 82 01 22 30 0D 06 09 2A 86 48 86 F7 est0.."0...*.H.. 00E0: 0D 01 01 01 05 00 03 82 01 0F 00 30 82 01 0A 02 ...........0.... 00F0: 82 01 01 00 DB F8 70 4E DC 2D 14 44 12 AF 0D 48 ......pN.-.D...H 0100: 09 1D B8 48 94 1C 9E F1 7F DC 6C D1 F7 94 3A B7 ...H......l...:. 0110: 5C E3 85 07 3E CB E1 76 4A 2C 32 17 4B E1 5E 42 \...>..vJ,2.K.^B 0120: A4 80 50 CA 36 A2 D9 94 F9 59 23 D0 AA 2B B2 13 ..P.6....Y#..+.. 0130: 23 6D 45 DF 13 52 A4 4E 28 D3 30 99 5A 81 AD 8C #mE..R.N(.0.Z... 0140: DB 15 55 B7 6D 5F 44 89 09 35 66 C8 2F 47 56 14 ..U.m_D..5f./GV. 0150: B5 B2 46 AE CE 5D DC A0 C8 59 08 89 6F 5B DB F2 ..F..]...Y..o[.. 0160: D8 69 E3 C1 80 44 F6 DA 46 ED 1D 20 80 12 3F 81 .i...D..F.. ..?. 0170: 95 27 F6 EB 9F B5 AC DC 72 01 70 46 18 67 1C 08 .'......r.pF.g.. 0180: AC C4 6D CA 80 48 12 87 3A 05 69 EA 92 EA 95 00 ..m..H..:.i..... 0190: 1F B9 2C BA 83 F3 B3 1B 37 1E B3 7C D7 46 B1 AE ..,.....7....F.. 01A0: D4 DD E9 04 8C C0 23 00 96 E3 6F 67 E7 66 65 61 ......#...og.fea 01B0: F6 11 D2 7A FE 44 42 83 9D 1A CF 20 80 EC 58 04 ...z.DB.... ..X. 01C0: A6 10 78 41 7B 34 C3 FA FD 2A 08 94 72 2F 3D AE ..xA.4...*..r/=. 01D0: B0 58 16 63 EE DA 81 42 44 DB 21 C7 23 69 93 BB .X.c...BD.!.#i.. 01E0: 64 40 16 78 01 8A 52 57 94 C0 AD 57 04 F4 C4 6B d at .x..RW...W...k 01F0: 90 C6 46 C7 02 03 01 00 01 30 0D 06 09 2A 86 48 ..F......0...*.H 0200: 86 F7 0D 01 01 0B 05 00 03 82 01 01 00 4B FC 37 .............K.7 0210: B5 E6 F2 A6 98 D8 58 2B 39 CE 8F 6B 51 93 80 0F ......X+9..kQ... 0220: 80 39 BD DA 53 7D D3 1B 00 11 F3 A7 FE 9C B7 FA .9..S........... 0230: 05 23 DA A2 17 10 7C E7 89 89 DE C5 90 5B 98 22 .#...........[." 0240: 7B 97 97 EA 2A B3 E4 6A 33 F8 FC 47 41 39 06 E1 ....*..j3..GA9.. 0250: 98 63 6C 0E 2A 92 FF 3D B1 62 D7 27 FF 2B 2B DF .cl.*..=.b.'.++. 0260: B7 B2 95 87 C7 B5 21 45 1E 73 F8 B5 0D D6 13 0C ......!E.s...... 0270: 1D 25 35 6B D7 5F 18 DF 30 A1 8B 72 DD C6 31 B1 .%5k._..0..r..1. 0280: 07 2A F2 DF 1F 1E 36 23 0C FF F9 FB DA E8 B5 2B .*....6#.......+ 0290: 3B 8B B6 4C 37 EF D3 27 07 B9 1E D4 64 4B 82 D4 ;..L7..'....dK.. 02A0: 32 78 C6 D1 61 6E 9A BF 41 10 23 0B 27 CD C7 77 2x..an..A.#.'..w 02B0: 03 73 B2 F6 12 D2 56 9C 29 A2 BD 31 40 F6 5F 0C .s....V.)..1 at ._. 02C0: 17 56 4F 30 34 95 77 87 9C 43 B0 74 C5 92 05 43 .VO04.w..C.t...C 02D0: 97 12 48 5B 7B 58 66 89 0A C1 8C CD 89 14 E0 5A ..H[.Xf........Z 02E0: 78 23 29 10 71 6C 5D 94 D5 FB C0 96 51 C1 0D 93 x#).ql].....Q... 02F0: 64 91 45 82 5A 53 88 56 5D 7A AE 88 E8 07 7D 02 d.E.ZS.V]z...... 0300: 7D 44 9D CA 73 E5 6F 14 27 8B 6F 86 6C 00 00 .D..s.o.'.o.l.. ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 CEST|CertificateMessage.java:1148|Consuming server Certificate handshake message ( "Certificate": { "certificate_request_context": "", "certificate_list": [ { "certificate" : { "version" : "v3", "serial number" : "20 C3 8D C4 49 66 D0 02", "signature algorithm": "SHA256withRSA", "issuer" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", "not before" : "2013-08-02 09:51:36.000 CEST", "not after" : "10000-01-01 24:59:59.000 CET", "subject" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", "subject public key" : "RSA"} "extensions": { } }, ] } ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 CEST|SSLExtensions.java:148|Ignore unavailable extension: status_request javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 CEST|SSLSocketInputRecord.java:458|Raw read ( 0000: 17 03 03 01 19 ..... ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 281 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 CEST|SSLSocketInputRecord.java:458|Raw read ( 0000: DE 53 C0 74 78 C3 82 0D E8 46 C0 0A F4 56 6E 6B .S.tx....F...Vnk 0010: B5 39 77 41 20 21 BA 07 99 2B BF 8D 0A 41 C9 B8 .9wA !...+...A.. 0020: BC 0F C1 8E C5 76 36 F0 7A B6 9A F8 38 4D 4D 4D .....v6.z...8MMM 0030: 70 33 BE 8F 8C ED BE BC 60 49 B8 41 65 E9 04 D9 p3......`I.Ae... 0040: 45 43 AA 41 6D F7 67 7B 03 6D FF E0 4D 76 53 CE EC.Am.g..m..MvS. 0050: C1 73 3E 1C CD 87 40 B7 25 56 54 0C 3E CA D7 1D .s>... at .%VT.>... 0060: 45 80 41 E8 36 B7 FC 57 38 BB 21 EB E7 EA 19 A1 E.A.6..W8.!..... 0070: 39 25 B0 44 8B FD 30 87 86 7A 47 03 C1 02 AC FD 9%.D..0..zG..... 0080: 67 89 4B 27 34 04 20 AE 91 65 7C 8C 4A 58 C5 77 g.K'4. ..e..JX.w 0090: 46 2E DD A8 23 CA 5C 28 49 25 23 3D 8A 93 B9 10 F...#.\(I%#=.... 00A0: 24 0D DE DC 98 AC AA B0 CB 51 80 D7 F8 E7 20 23 $........Q.... # 00B0: 41 64 A6 44 93 A7 E1 A7 91 62 4F 3A 73 F6 24 04 Ad.D.....bO:s.$. 00C0: C3 E8 25 65 37 D9 1B 7A 65 AE DE C6 29 67 2E C1 ..%e7..ze...)g.. 00D0: F7 4C 5C 18 D7 14 98 90 ED 9D AD F5 98 A7 FD 93 .L\............. 00E0: 53 F4 B5 90 C9 CB FD 54 8E 5F 53 23 E3 73 94 BD S......T._S#.s.. 00F0: A4 07 B7 E3 C7 83 7B 17 CF 51 4A 9E 9C 05 3C 51 .........QJ....a7I8. 00A0: B0 15 C9 AD 0C 7A 05 8D B4 48 BB 03 2D DE 5E 49 .....z...H..-.^I 00B0: 99 8B 74 53 5F 73 9B 18 FD 95 2A C3 F9 A3 8B 59 ..tS_s....*....Y 00C0: 1A ED 2C 55 C2 22 10 1E 7A FC 38 0A 99 FC 30 89 ..,U."..z.8...0. 00D0: 03 89 1C CD A7 DE E5 35 FD E9 E0 05 96 09 AF DD .......5........ 00E0: 51 A3 7F C7 16 C5 96 8D CA CC 53 50 DC C5 C6 BA Q.........SP.... 00F0: D6 05 28 18 BA 99 F8 0F 7F 24 9F D5 6B 93 DE BC ..(......$..k... 0100: EB 23 85 D9 D3 41 56 44 .#...AVD ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 CEST|CertificateVerify.java:1128|Consuming CertificateVerify handshake message ( "CertificateVerify": { "signature algorithm": rsa_pss_rsae_sha256 "signature": { 0000: 30 11 28 CE 64 4E 08 BA A1 BE 46 D9 3D 14 29 1A 0.(.dN....F.=.). 0010: EB 5A B0 1A 09 B7 11 A5 9A F4 22 17 87 5F 87 D5 .Z........".._.. 0020: 63 04 8E 27 EC 3A F8 52 36 F4 2F CF 47 D2 5C CE c..'.:.R6./.G.\. 0030: 0A F0 29 EF 63 03 B1 64 B8 45 6E 39 71 E3 BD 25 ..).c..d.En9q..% 0040: 95 31 25 85 4C FB C6 AD C8 43 96 4E FA AD B9 98 .1%.L....C.N.... 0050: 17 43 61 FB 9B 87 CE 94 CF 74 6F 3B AA 6A C8 80 .Ca......to;.j.. 0060: 8F C7 C8 05 E4 EF 42 6C D4 01 9E 25 5E 34 E8 2D ......Bl...%^4.- 0070: 93 BD BB 05 49 2F 9D B6 F6 91 2F D1 E5 CB 1B 9E ....I/..../..... 0080: F6 DB 18 32 1D F5 66 A0 63 5D 25 01 B6 F6 1B 41 ...2..f.c]%....A 0090: 07 3E 90 61 37 49 38 17 B0 15 C9 AD 0C 7A 05 8D .>.a7I8......z.. 00A0: B4 48 BB 03 2D DE 5E 49 99 8B 74 53 5F 73 9B 18 .H..-.^I..tS_s.. 00B0: FD 95 2A C3 F9 A3 8B 59 1A ED 2C 55 C2 22 10 1E ..*....Y..,U.".. 00C0: 7A FC 38 0A 99 FC 30 89 03 89 1C CD A7 DE E5 35 z.8...0........5 00D0: FD E9 E0 05 96 09 AF DD 51 A3 7F C7 16 C5 96 8D ........Q....... 00E0: CA CC 53 50 DC C5 C6 BA D6 05 28 18 BA 99 F8 0F ..SP......(..... 00F0: 7F 24 9F D5 6B 93 DE BC EB 23 85 D9 D3 41 56 44 .$..k....#...AVD } } ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 CEST|SSLSocketInputRecord.java:458|Raw read ( 0000: 17 03 03 00 35 ....5 ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 53 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 CEST|SSLSocketInputRecord.java:458|Raw read ( 0000: F6 A7 CD EA 89 34 B2 DB C4 28 91 18 C9 03 98 B6 .....4...(...... 0010: DF 49 4E F5 2E 23 32 90 F8 13 C7 AE 18 E3 E5 64 .IN..#2........d 0020: D9 E4 A5 B0 5C F0 4A 3E AF EC 28 8D 09 78 AB EE ....\.J>..(..x.. 0030: 38 1B 9E 45 04 8..E. ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 53 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( 0000: 14 00 00 20 F2 93 6B 71 2B FA F3 1B BF 68 98 D1 ... ..kq+....h.. 0010: AA 5E B0 AF 5D 3B A6 B5 8F 79 BA 64 E8 A1 34 5F .^..];...y.d..4_ 0020: D4 2B ED 8C .+.. ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.764 CEST|Finished.java:860|Consuming server Finished handshake message ( "Finished": { "verify data": { 0000: F2 93 6B 71 2B FA F3 1B BF 68 98 D1 AA 5E B0 AF ..kq+....h...^.. 0010: 5D 3B A6 B5 8F 79 BA 64 E8 A1 34 5F D4 2B ED 8C ];...y.d..4_.+.. }'} ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.765 CEST|SSLCipher.java:1824|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE countdown value = 137438953472 javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.765 CEST|CertificateMessage.java:1015|No signature_algorithms(_cert) in ClientHello javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|CertificateMessage.java:1081|No available client authentication scheme javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|CertificateMessage.java:1116|Produced client Certificate message ( "Certificate": { "certificate_request_context": "", "certificate_list": [ ] } ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 8 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( 0000: 0B 00 00 04 00 00 00 00 16 00 00 00 00 00 00 00 ................ 0010: 00 00 00 00 00 00 00 00 00 ......... ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 CEST|SSLSocketOutputRecord.java:255|Raw write ( 0000: 17 03 03 00 29 E5 32 E4 5B 13 E7 D4 A1 78 FE 38 ....).2.[....x.8 0010: 26 22 CB C1 04 88 3A 3A 2D D4 A1 31 5A 78 65 50 &"....::-..1ZxeP 0020: 51 45 67 FA 9F 55 35 E1 49 C5 3B 3B 91 B1 QEg..U5.I.;;.. ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 CEST|CertificateVerify.java:1059|No X.509 credentials negotiated for CertificateVerify javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 CEST|Finished.java:658|Produced client Finished handshake message ( "Finished": { "verify data": { 0000: D8 47 0B A0 DF BB BF 49 E4 55 B9 D3 FB 3D B0 DD .G.....I.U...=.. 0010: 57 1E 08 28 20 7E E1 0B E3 EB 12 10 09 76 D1 8F W..( ........v.. }'} ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 36 javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( 0000: 14 00 00 20 D8 47 0B A0 DF BB BF 49 E4 55 B9 D3 ... .G.....I.U.. 0010: FB 3D B0 DD 57 1E 08 28 20 7E E1 0B E3 EB 12 10 .=..W..( ....... 0020: 09 76 D1 8F 16 00 00 00 00 00 00 00 00 00 00 00 .v.............. 0030: 00 00 00 00 00 ..... ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 CEST|SSLSocketOutputRecord.java:255|Raw write ( 0000: 17 03 03 00 45 0F 4D 84 52 28 59 96 92 52 D1 AB ....E.M.R(Y..R.. 0010: DB 86 64 25 31 FF 9D 8E D7 84 63 B5 03 E2 9E 06 ..d%1.....c..... 0020: 3C 8C C2 22 F3 7A EE 55 AD 8C F5 5C F6 04 9A E2 <..".z.U...\.... 0030: 6D BA E4 C4 9F 97 C3 DA BC D3 CB 8C 2C 9E BF FD m...........,... 0040: A3 9F C1 A2 79 51 75 B7 AE B6 ....yQu... ) javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.770 CEST|SSLCipher.java:1978|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE countdown value = 137438953472 javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:458|Raw read ( 0000: 17 03 03 00 13 ..... ) javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 19 javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:458|Raw read ( 0000: 4F 0D C7 65 8B 24 B4 92 A2 26 31 8C 81 AF 8F F7 O..e.$...&1..... 0010: AC C3 B3 ... ) javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 19 javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.773 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( 0000: 02 74 .t ) javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.774 CEST|Alert.java:232|Received alert message ( "Alert": { "level" : "fatal", "description": "certificate_required" } ) javax.net.ssl|ERROR|0C|Thread-0|2018-09-17 11:51:54.774 CEST|TransportContext.java:313|Fatal (CERTIFICATE_REQUIRED): Received fatal alert: certificate_required ( "throwable" : { javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_required at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) at ReproducerClient$1.run(ReproducerClient.java:33) at java.base/java.lang.Thread.run(Thread.java:834)} ) javax.net.ssl|ALL|0C|Thread-0|2018-09-17 11:51:54.775 CEST|SSLSessionImpl.java:753|Invalidated session: Session(1537177914725|TLS_AES_128_GCM_SHA256) javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 CEST|SSLSocketImpl.java:1361|close the underlying socket javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 CEST|SSLSocketImpl.java:1380|close the SSL connection (initiative) javax.net.ssl|WARNING|0C|Thread-0|2018-09-17 11:51:54.777 CEST|SSLSocketImpl.java:1289|handling exception ( "throwable" : { javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_required at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) at ReproducerClient$1.run(ReproducerClient.java:33) at java.base/java.lang.Thread.run(Thread.java:834)} ) Bye Norman > On 16. Sep 2018, at 15:54, Norman Maurer > wrote: > > Will do, but not before tomorrow (I will also share the client side code). That said there is nothing special about the keymanager. > Like I said before it sends the cert when using ?want client with?, it just seems it may be too late. > > > Bye > Norman > >> Am 15.09.2018 um 08:26 schrieb Bradford Wetmore >: >> >> 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)) >>>>>> 0000 - 16 03 03 01 60 ....` >>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160)) >>>>>> 0000 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 ...\..".... at 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..o....K...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)) >>>>>> 0000 - 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|J....n....] >>>>>> 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..o....K.. >>>>>> 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 MT....B5S[...... >>>>>> 00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65 .(.m...8.wrs%&.e >>>>>> 00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96 X........P...... >>>>>> 0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9 .;<..AX...:(..a. >>>>>> 0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5 .h...f.[..... .. >>>>>> 0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb .RD...c=........ >>>>>> 0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6 .*O[J.wx.u. .... >>>>>> 0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee ...VV._.e.~n=.f. >>>>>> 0150 - 10 4c f7 6d 9b 73 86 14-7a 81 f8 b1 27 af 08 ee .L.m.s..z...'... >>>>>> 0160 - ce 26 90 34 73 3d b7 45-8d 85 29 a8 65 19 e7 02 .&.4s=.E..).e... >>>>>> 0170 - e5 55 4a 27 f1 b1 6a a4-11 cc 6c af 78 6d 22 5c .UJ'..j...l.xm"\ >>>>>> 0180 - 33 73 e3 ad 7f 8d 1b d3-75 95 66 64 2d 0e f1 3e 3s......u.fd-..> >>>>>> 0190 - c2 30 df a1 7e ce a3 50-c3 4e 68 f6 36 b3 4e 45 .0..~..P.Nh.6.NE >>>>>> 01a0 - 9c ac e9 f2 0d 7c e3 73-6a 40 ab 6e 6e f9 d8 20 .....|.sj at .nn.. >>>>>> 01b0 - 9c f3 04 32 cd 1d df 18-e5 4d e3 e8 b1 38 59 f8 ...2.....M...8Y. >>>>>> 01c0 - 28 67 2e ca af a2 8b 88-ce ca 48 a6 07 2b a6 9a (g........H..+.. >>>>>> 01d0 - 0e 88 5b d7 0b d9 31 77-97 8d 6c 2b f5 60 24 61 ..[...1w..l+.`$a >>>>>> 01e0 - a8 5c 47 5d 7c 66 f0 9b-1f e4 76 93 38 f6 78 3e .\G]|f....v.8.x> >>>>>> 01f0 - 69 29 72 f9 d9 4b cb 05-03 e4 f2 d6 24 e1 91 ee i)r..K......$... >>>>>> 0200 - 85 37 d7 7b c3 5c 35 90-08 cd b1 cc 76 11 fc 00 .7.{.\5.....v... >>>>>> 0210 - 12 7e 89 7b 70 e6 ca fe-0b 26 b6 bb ac fe 4b 9f .~.{p....&....K. >>>>>> 0220 - ec cf 41 69 42 3a 3e 41-f9 b0 c0 93 5b 70 1f c7 ..AiB:>A....[p.. >>>>>> 0230 - 11 00 3d ec 66 5a 1a ca-31 89 22 27 02 dd a0 cb ..=.fZ..1."'.... >>>>>> 0240 - 39 14 25 ee 30 44 e8 62-97 bf 8e 16 63 40 c4 11 9.%.0D.b....c at .. >>>>>> 0250 - a6 d9 32 b1 3c 86 35 bb-9f f1 4d 71 9f a5 4f 78 ..2.<.5...Mq..Ox >>>>>> 0260 - 0a e8 96 dd 4d 10 c3 48-f2 db 67 57 2d cd dc 23 ....M..H..gW-..# >>>>>> 0270 - 3a 8d 6a 61 47 20 ff c8-33 cd e9 f7 47 4c 68 4f :.jaG ..3...GLhO >>>>>> 0280 - 19 2f 8b e3 b1 90 ac 66-a7 cf 5c e6 d2 05 21 25 ./.....f..\...!% >>>>>> 0290 - d2 d8 f0 43 8c 55 01 ef-d6 8f c0 27 87 0d 21 d5 ...C.U.....'..!. >>>>>> 02a0 - 2b 2b 6f db e8 85 ea cd-6e 9c 5d 56 d5 31 c1 f2 ++o.....n.]V.1.. >>>>>> 02b0 - 97 2f 5a 83 7a 2b 71 03-65 e0 b6 4a 56 37 de e1 ./Z.z+q.e..JV7.. >>>>>> 02c0 - 80 3a c4 cc 5a ac 3b 9a-7a bf f7 6b fe a8 69 e9 .:..Z.;.z..k..i. >>>>>> 02d0 - 58 09 59 bd 46 bd d2 a3-bc ad 1c 10 53 c8 29 7b X.Y.F.......S.){ >>>>>> 02e0 - be 63 00 d6 e5 a8 d6 ab-b2 bc 8b e1 2c 0e 24 2a .c..........,.$* >>>>>> 02f0 - c2 31 2d d8 6e 1f 19 93-d7 54 e1 1e 28 ce 72 83 .1-.n....T..(.r. >>>>>> 0300 - ff 05 18 f2 fc e9 0c b3-0c 1b d5 96 c2 d8 fc 76 ...............v >>>>>> 0310 - 37 a9 5a ef 8e e9 b6 71-21 f3 bd c1 85 23 85 22 7.Z....q!....#." >>>>>> 0320 - 3d c4 1c c9 31 8b 7e 00-8f 8e b4 9f 05 d4 80 6b =...1.~........k >>>>>> 0330 - 98 4c a8 82 68 ff 1a a5-28 e2 9b 03 a1 a7 b1 00 .L..h...(....... >>>>>> 0340 - 02 2b 2d e2 e1 87 8c e8-0a fb 0b 79 54 ca 3d d5 .+-........yT.=. >>>>>> 0350 - 6a dd b7 b7 87 42 2b 47-49 da e9 0a 82 0a c9 8f j....B+GI....... >>>>>> 0360 - 57 f7 1e 03 ca 8d 16 bc-21 3a 6a ee b9 b8 fa f0 W.......!:j..... >>>>>> 0370 - d9 18 35 9f 35 ac d8 6e-9a 8a 0d 56 10 1e 1f 5a ..5.5..n...V...Z >>>>>> 0380 - ba ec e4 fe 1a 92 b4 31-35 43 1d 99 b9 12 fa ff .......15C...... >>>>>> 0390 - 99 2b 88 e0 58 ec 9c dc-8f 67 ef 2a c2 e2 64 5d .+..X....g.*..d] >>>>>> 03a0 - 66 76 1c d0 aa 00 30 59-b1 f5 b1 55 9f ad 60 e9 fv....0Y...U..`. >>>>>> 03b0 - 3d 03 1e d0 8b 4d bf 74-ac bc bb 1c 83 14 c5 e0 =....M.t........ >>>>>> 03c0 - f4 fc 70 9e f4 22 a0 78-04 fe c8 b1 17 65 f6 94 ..p..".x.....e.. >>>>>> 03d0 - 47 82 50 4a b6 32 74 ae-5b 38 5a 2e d9 b0 6a 45 G.PJ.2t.[8Z...jE >>>>>> 03e0 - 74 e8 f0 22 fe d3 b0 11-c3 fd 72 4f da 77 7a ba t.."......rO.wz. >>>>>> 03f0 - 26 3e 61 0c 63 21 17 a6-b2 13 6e 71 5c f2 0d ad &>a.c!....nq\... >>>>>> 0400 - f2 d1 19 71 51 9e a4 1b-b0 30 24 e0 71 7d 87 80 ...qQ....0$.q}.. >>>>>> 0410 - a9 5a e9 bc db e4 4f 50-4d a1 bc bc 2c 4b 66 98 .Z....OPM...,Kf. >>>>>> 0420 - d4 e4 b0 76 0f d2 db a5-a5 39 9e f2 5b ea 34 c1 ...v.....9..[.4. >>>>>> 0430 - 62 ab 47 51 3b 37 17 45-54 31 18 f3 f1 ca 17 03 b.GQ;7.ET1...... >>>>>> 0440 - 03 01 19 dd 50 50 f5 0c-f2 c9 3c b4 8f 63 cc 4a ....PP....<..c.J >>>>>> 0450 - a7 50 c9 91 9b 79 9a 2a-5c 47 d3 77 f6 56 69 90 .P...y.*\G.w.Vi. >>>>>> 0460 - 98 cd ff bd c1 2a 49 fc-0d d4 7e cc 7e 44 af c4 .....*I...~.~D.. >>>>>> 0470 - 61 47 e0 c1 76 b1 8c 2e-df 7e d0 82 e1 89 1f 04 aG..v....~...... >>>>>> 0480 - ae 64 bd 71 4d ae 1c 3c-e3 d3 39 5d 61 2a ea 70 .d.qM..<..9]a*.p >>>>>> 0490 - 8c 31 6d a0 b1 72 a8 7a-5c 9c 11 08 b8 4d a5 c4 .1m..r.z\....M.. >>>>>> 04a0 - ad 1b 38 4a 6a 02 28 d4-d1 0f c8 9f 0b b3 02 18 ..8Jj.(......... >>>>>> 04b0 - 82 2b bd 46 82 04 64 f0-41 b2 da f5 cd 9c f7 f3 .+.F..d.A....... >>>>>> 04c0 - 73 30 58 ca 12 ec ea 90-85 1c 75 09 0a 70 b8 80 s0X.......u..p.. >>>>>> 04d0 - 3d 02 17 3e 9b 83 04 b5-dd 9e e6 18 17 65 83 a5 =..>.........e.. >>>>>> 04e0 - 59 7d 4b 98 da bd 8b aa-d6 aa c5 1c 7d 87 56 e3 Y}K.........}.V. >>>>>> 04f0 - 74 d8 e9 7b eb b3 3d f7-7c 3c 0a e9 a8 2e 04 0d t..{..=.|<...... >>>>>> 0500 - 6a e7 83 e0 ec 99 43 6a-8b 1c 73 59 7a c8 cd 6e j.....Cj..sYz..n >>>>>> 0510 - 4a 14 73 ff 9a fb 71 94-d5 50 a9 d9 e0 dd 02 4c J.s...q..P.....L >>>>>> 0520 - 2b 67 9e da 9e fa 2d 67-49 df 13 10 ed 35 3e 73 +g....-gI....5>s >>>>>> 0530 - 07 20 17 fb 0b ef f6 d0-b7 68 1c 65 21 a6 e3 3b . .......h.e!..; >>>>>> 0540 - bf 7b 84 cd 9e f5 76 2a-0d 4f b8 c3 c8 15 08 e9 .{....v*.O...... >>>>>> 0550 - 0f 3c 50 49 12 97 a8 d7-f1 a3 16 da 17 03 03 00 .>>>>> 0560 - 35 22 dd a2 9d 25 98 2c-35 b8 00 29 fa a1 dd ba 5"...%.,5..).... >>>>>> 0570 - 72 b9 fe e5 85 85 f0 f1-3b 4e f5 7c 58 c8 2a da r.......;N.|X.*. >>>>>> 0580 - d2 75 94 3b c1 7a 7c 7e-db 5b fe 8a 2d 3f 8c 9a .u.;.z|~.[..-?.. >>>>>> 0590 - 6e 79 ab 2b ff 1a ny.+.. >>>>>> SSL_accept:SSLv3/TLS write finished >>>>>> SSL_accept:TLSv1.3 early data >>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>> 0000 - 14 03 03 00 01 ..... >>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (1 bytes => 1 (0x1)) >>>>>> 0000 - 01 . >>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>> 0000 - 17 03 03 00 3d ....= >>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (61 bytes => 61 (0x3D)) >>>>>> 0000 - 38 e7 bb 2c 5b af b6 5f-37 d8 3e 7e bb f4 04 f5 8..,[.._7.>~.... >>>>>> 0010 - e1 28 b5 e5 07 5a ec ce-da 2f f3 b6 45 61 cf ef .(...Z.../..Ea.. >>>>>> 0020 - 90 fb 57 b8 f3 20 45 27-60 d4 26 51 38 77 e4 bc ..W.. E'`.&Q8w.. >>>>>> 0030 - b7 64 d4 8b 73 25 41 9e-fe d3 9d 5f 53 .d..s%A...._S >>>>>> SSL_accept:TLSv1.3 early data >>>>>> write to 0x7fe400f050c0 [0x7fe403018a00] (24 bytes => 24 (0x18)) >>>>>> 0000 - 17 03 03 00 13 25 85 60-eb 7d c1 a8 15 49 d5 63 .....%.`.}...I.c >>>>>> 0010 - 18 7f c6 ac ed 7f df 77- .......w >>>>>> SSL3 alert write:fatal:unknown >>>>>> SSL_accept:error in error >>>>>> ERROR >>>>>> 140736092021632:error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate:ssl/statem/statem_srvr.c:3654: >>>>>> shutting down SSL >>>>>> CONNECTION CLOSED >>>>>> >>>>>> >>>>>> >>>>>> When using openssl s_client all works as expected tho (thats also true if I use my native implementation on the client and server side that uses openssl): >>>>>> >>>>>> ./bin/openssl s_client -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 -state -tls1_3 -connect localhost:8443 >>>>>> >>>>>> The interesting thing is if I use ?-verify 1? and not ?-Verify 1? with openssl which tells it I want to request a certificate but will also process if none is provided I receive the certificate at some point as seen here: >>>>>> >>>>>> SSL_accept:before SSL initialization >>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>> 0000 - 16 03 03 01 60 ....` >>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (352 bytes => 352 (0x160)) >>>>>> 0000 - 01 00 01 5c 03 03 61 c0-b3 ed 88 65 e6 cf 11 3f ...\..a....e...? >>>>>> 0010 - c0 e0 f8 df a6 63 32 c2-ab 3d 61 6f 41 ed b1 4b .....c2..=aoA..K >>>>>> 0020 - 53 0e 83 e5 a1 b8 20 c7-1b 8c b8 e6 b5 da 4e 4e S..... .......NN >>>>>> 0030 - 3f 3c 61 7a ad 58 23 94-a7 32 79 2f db 9f 21 c0 ?>>>>> 0040 - 8e 0c c5 ce b1 c2 a4 00-14 c0 2c c0 2b c0 2f c0 ..........,.+./. >>>>>> 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 52 dc d6 47 6e .3.G.E...A.R..Gn >>>>>> 0120 - a1 de 9c 71 c2 54 0e 5c-9b 57 fb c8 aa 3f 19 f7 ...q.T.\.W...?.. >>>>>> 0130 - d3 a4 25 12 fa 3f 6c 6d-95 30 66 ca 63 b7 a1 dd ..%..?lm.0f.c... >>>>>> 0140 - ae 9f 99 d6 a8 6b 20 4f-29 7a 74 58 ad 58 de 12 .....k O)ztX.X.. >>>>>> 0150 - d7 a5 9b 69 dc 27 ac ec-9e d4 04 ff 01 00 01 00 ...i.'.......... >>>>>> 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 0x7fdc58809fb0 [0x7fdc59025e00] (1430 bytes => 1430 (0x596)) >>>>>> 0000 - 16 03 03 00 9b 02 00 00-97 03 03 8b c8 62 48 6c .............bHl >>>>>> 0010 - f5 7c 73 d9 17 f8 63 a2-11 27 40 93 09 26 53 06 .|s...c..'@..&S. >>>>>> 0020 - b3 62 df 46 26 b6 dc 59-29 b5 58 20 c7 1b 8c b8 .b.F&..Y).X .... >>>>>> 0030 - e6 b5 da 4e 4e 3f 3c 61-7a ad 58 23 94 a7 32 79 ...NN?>>>>> 0040 - 2f db 9f 21 c0 8e 0c c5-ce b1 c2 a4 13 01 00 00 /..!............ >>>>>> 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 O.+.....3.E...A. >>>>>> 0060 - 07 63 1c 19 53 89 68 a8-0f ea 9e 4c 18 6f 2a ad .c..S.h....L.o*. >>>>>> 0070 - 2a df eb 17 a2 08 94 c6-e3 c5 97 ae 0f c1 1a d7 *............... >>>>>> 0080 - 0d d7 2e 6d 77 3d 30 a0-07 db 70 35 bb 37 dd 1e ...mw=0...p5.7.. >>>>>> 0090 - b6 f3 4d cb 13 97 7c 11-63 98 e8 64 2d a7 e6 cc ..M...|.c..d-... >>>>>> 00a0 - 14 03 03 00 01 01 17 03-03 00 27 a3 73 d2 ee 2c ..........'.s.., >>>>>> 00b0 - 2f 9c 8f 95 7f ca a3 89-bc b4 b3 b2 3c 8b 23 ef /...........<.#. >>>>>> 00c0 - 36 66 23 c9 09 02 33 0d-dc 5d 36 61 44 89 8b ef 6f#...3..]6aD... >>>>>> 00d0 - fd 13 17 03 03 00 42 f2-5b 3c 0c 27 5e 7f 97 4f ......B.[<.'^..O >>>>>> 00e0 - 0f de 8c b9 0a a1 41 c7-c2 1e 92 99 6a d5 bd 12 ......A.....j... >>>>>> 00f0 - 38 b6 b7 93 33 e9 8e 0f-44 93 f0 69 58 b6 41 22 8...3...D..iX.A" >>>>>> 0100 - 46 e2 4a d5 d6 32 2b b8-a7 ae 3a c2 c5 2f e6 35 F.J..2+...:../.5 >>>>>> 0110 - 11 0c f1 9a 35 2a 87 ed-9e 17 03 03 03 20 a7 e2 ....5*....... .. >>>>>> 0120 - fe ba c7 10 5b 9c cd 94-67 19 37 2d 46 59 ab 56 ....[...g.7-FY.V >>>>>> 0130 - 6b dd a4 10 61 cc ed f1-71 a7 2d 6a 41 2e 2b da k...a...q.-jA.+. >>>>>> 0140 - d1 35 fc 01 df 49 e5 90-1d 9b b2 03 0a 81 58 18 .5...I........X. >>>>>> 0150 - 96 a1 db 31 19 98 35 5c-87 8f 6e 32 0a e6 c0 aa ...1..5\..n2.... >>>>>> 0160 - 9e 8e 72 e2 34 b3 b7 a3-d6 d1 66 c7 ce 93 fe 78 ..r.4.....f....x >>>>>> 0170 - 17 c4 71 7c 42 15 c8 af-dc 4f 50 42 51 80 fc bf ..q|B....OPBQ... >>>>>> 0180 - fc 54 d5 d8 59 20 9a 90-c4 78 97 9c 2d 4a d5 58 .T..Y ...x..-J.X >>>>>> 0190 - be 81 79 23 59 22 9d 27-f8 bd a0 b2 98 b3 47 82 ..y#Y".'......G. >>>>>> 01a0 - d3 52 b5 b5 91 ab 5c 76-52 c5 a5 95 2d 03 1c b7 .R....\vR...-... >>>>>> 01b0 - 64 4d 0b 88 7f 15 0b c8-a8 90 50 9a b6 b1 9f b7 dM........P..... >>>>>> 01c0 - 40 09 f2 5f 39 f8 9a 06-21 4d 67 10 0a 67 08 b6 @.._9...!Mg..g.. >>>>>> 01d0 - b5 9a 25 8c d5 ca 31 6a-8a 6b 01 93 7d 6f 1e 52 ..%...1j.k..}o.R >>>>>> 01e0 - 98 96 9d fb e8 c1 07 ab-57 98 2d 1e 75 77 ef c2 ........W.-.uw.. >>>>>> 01f0 - 49 78 e0 b9 2b 32 23 7e-95 4d 3e 27 00 61 86 0c Ix..+2#~.M>'.a.. >>>>>> 0200 - 47 c7 79 e4 ee 9d ba c0-ea 62 f1 0d 8e 4a 91 30 G.y......b...J.0 >>>>>> 0210 - bc 4f 5a 98 26 30 66 ec-c4 63 8f 28 d5 1c 61 23 .OZ.&0f..c.(..a# >>>>>> 0220 - ea e9 90 4e 36 d9 fa 31-7b 14 27 22 0a ae 9f 64 ...N6..1{.'"...d >>>>>> 0230 - 40 3d e5 a0 5c 9d 3c 04-71 09 b0 7a 6b 51 a0 9c @=..\.<.q..zkQ.. >>>>>> 0240 - c0 61 32 ce 15 62 8e 29-b1 59 91 c0 17 2c b3 c5 .a2..b.).Y...,.. >>>>>> 0250 - f9 ed 07 65 3d 11 de 98-de 62 36 50 74 37 af 2d ...e=....b6Pt7.- >>>>>> 0260 - 7d 86 55 c4 3e a2 83 ab-47 8d f2 b2 8d 1d 75 83 }.U.>...G.....u. >>>>>> 0270 - b5 e4 41 87 a7 a3 85 b0-5e 4e 2e 9c 8c b0 1b 83 ..A.....^N...... >>>>>> 0280 - 7b 54 79 c9 60 ea 7d ed-06 fa dd 24 40 f1 53 9e {Ty.`.}....$@.S. >>>>>> 0290 - 43 79 25 53 9c c7 6e 95-ab 9f 96 59 cd b9 7b a8 Cy%S..n....Y..{. >>>>>> 02a0 - a0 23 13 69 db a9 c9 e7-1a 8e e1 9b 54 94 1c 44 .#.i........T..D >>>>>> 02b0 - 50 08 8b dd eb 4e 2b bb-d7 c9 c2 33 8c a1 b3 65 P....N+....3...e >>>>>> 02c0 - 06 e6 9d ac 11 16 21 58-40 8d 59 e6 67 e5 31 02 ......!X at .Y.g.1. >>>>>> 02d0 - 15 8d 29 80 20 66 ba c3-56 93 95 5c 65 4b 41 00 ..). f..V..\eKA. >>>>>> 02e0 - c5 71 12 12 f5 20 4f 59-be 77 06 10 6e 48 85 5c .q... OY.w..nH.\ >>>>>> 02f0 - ff a2 c4 ae fb 4d 95 f5-cc f6 61 20 33 b7 92 1d .....M....a 3... >>>>>> 0300 - ac a8 f1 b2 b0 88 c6 7b-8b 00 53 30 6d 4a d1 42 .......{..S0mJ.B >>>>>> 0310 - b3 3e 85 f5 84 e1 c6 ab-10 9d 61 03 46 ff 2d 81 .>........a.F.-. >>>>>> 0320 - 15 4f 84 d1 4c ee f4 a6-a0 ec 50 60 a0 d1 ff df .O..L.....P`.... >>>>>> 0330 - 8a 97 f6 7d fb 8f fb 60-18 d4 f1 1f 92 4d d8 69 ...}...`.....M.i >>>>>> 0340 - b1 92 97 44 0f 3c 8a aa-47 07 48 d4 07 2d 3e f2 ...D.<..G.H..->. >>>>>> 0350 - c4 a7 16 35 a7 17 71 ef-98 84 24 67 12 58 30 3b ...5..q...$g.X0; >>>>>> 0360 - 1d 41 8d e5 12 52 95 64-e5 88 35 99 d7 c3 58 40 .A...R.d..5...X@ >>>>>> 0370 - f9 55 9b 9f e5 33 15 70-41 d7 45 ba a4 fc 75 ea .U...3.pA.E...u. >>>>>> 0380 - a4 ae f0 68 ea 64 d8 f5-06 68 a9 75 22 4d 43 cc ...h.d...h.u"MC. >>>>>> 0390 - ff 50 cc ac 6e fd 43 dd-eb e4 c8 dd 4b 6c 12 bb .P..n.C.....Kl.. >>>>>> 03a0 - f1 d4 5e 11 4a 86 90 0b-f8 3a 2e 23 db 61 5a 1f ..^.J....:.#.aZ. >>>>>> 03b0 - 7e 11 00 92 21 68 1f b5-ab f2 f8 38 5e 62 ea f8 ~...!h.....8^b.. >>>>>> 03c0 - da ef c2 6e a0 b8 20 e4-69 49 b3 1f 15 84 0b 9b ...n.. .iI...... >>>>>> 03d0 - ce b0 6f 36 32 7f 7e bf-e8 d7 18 7a 58 60 f4 04 ..o62.~....zX`.. >>>>>> 03e0 - cc 36 bf 06 cd ec e5 9b-19 03 96 09 fb af 8f c3 .6.............. >>>>>> 03f0 - 98 b4 02 aa e8 55 81 aa-c4 fe 06 81 30 a0 c7 b2 .....U......0... >>>>>> 0400 - f8 e2 30 00 d7 a0 54 7f-5f d7 ef a6 f8 41 58 34 ..0...T._....AX4 >>>>>> 0410 - f5 f0 18 69 8d e6 7a 23-78 90 8f b1 05 c5 b5 7f ...i..z#x....... >>>>>> 0420 - e0 f2 c7 fa c8 36 5b 53-7e cf e6 75 d3 54 b4 69 .....6[S~..u.T.i >>>>>> 0430 - 68 43 0d 6a d2 83 cc 13-6d ca bf 83 3c 90 17 03 hC.j....m...<... >>>>>> 0440 - 03 01 19 96 dc 49 26 ce-1d 8e 86 3d bd cb 00 5e .....I&....=...^ >>>>>> 0450 - ee f6 e7 1d 16 7a ca ef-fa 6d 16 40 b6 99 d0 c1 .....z...m. at .... >>>>>> 0460 - df 0b 5f 51 60 a8 24 e0-61 82 13 40 da 88 38 3a .._Q`.$.a.. at ..8: >>>>>> 0470 - 26 1d 80 51 c4 b1 95 35-95 3c 91 35 28 17 49 d8 &..Q...5.<.5(.I. >>>>>> 0480 - c3 45 be 32 98 3e 02 07-3b 01 20 2b 51 e1 1a 94 .E.2.>..;. +Q... >>>>>> 0490 - b9 be 96 aa 7a 13 09 ff-d5 a9 63 d4 6f 49 cb b5 ....z.....c.oI.. >>>>>> 04a0 - 23 ab 7f 8c e2 63 f0 5c-5c 27 1e 04 a8 71 0c c0 #....c.\\'...q.. >>>>>> 04b0 - 89 cd ed 18 8d 5b 75 ac-af f3 68 6d cc ba 20 38 .....[u...hm.. 8 >>>>>> 04c0 - b5 7c 09 47 29 28 e2 26-57 57 1f f0 f3 18 fd 6f .|.G)(.&WW.....o >>>>>> 04d0 - 27 42 a4 e3 de bb e5 d6-09 7d 25 b1 98 97 ad 33 'B.......}%....3 >>>>>> 04e0 - 68 35 92 07 80 23 f1 66-20 5d 74 f3 02 c5 51 ff h5...#.f ]t...Q. >>>>>> 04f0 - 07 a9 e9 0e 3e 74 da 2e-8f 3b 16 be e6 94 1b 66 ....>t...;.....f >>>>>> 0500 - bb b2 a2 1e 7c 7b ff 5e-a4 36 2a ba 0b cd 7f e9 ....|{.^.6*..... >>>>>> 0510 - 86 bb 5e 30 f5 57 92 52-82 b6 2e da 71 b7 22 c2 ..^0.W.R....q.". >>>>>> 0520 - 90 c4 69 46 07 df 6c 3f-05 8b 19 3e ce b9 75 0d ..iF..l?...>..u. >>>>>> 0530 - 4b 97 37 ae 94 e2 d6 3c-91 e6 82 c7 a1 78 79 2c K.7....<.....xy, >>>>>> 0540 - 9a a3 d5 45 94 ad e2 c8-ab fd 81 ec 62 87 f7 75 ...E........b..u >>>>>> 0550 - e3 70 79 8e 82 3b c5 45-0d d0 33 5f 17 03 03 00 .py..;.E..3_.... >>>>>> 0560 - 35 da e0 74 2a 06 41 5a-64 1e 54 94 29 73 43 3f 5..t*.AZd.T.)sC? >>>>>> 0570 - e5 24 a8 ba b2 7e 6b 26-82 fc d9 f6 dd 19 05 4a .$...~k&.......J >>>>>> 0580 - 2c 1a f3 bb 16 1d 38 95-a6 d3 a8 58 f6 a3 41 c7 ,.....8....X..A. >>>>>> 0590 - 92 44 35 24 25 0e .D5$%. >>>>>> SSL_accept:SSLv3/TLS write finished >>>>>> SSL_accept:TLSv1.3 early data >>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>> 0000 - 14 03 03 00 01 ..... >>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (1 bytes => 1 (0x1)) >>>>>> 0000 - 01 . >>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>> 0000 - 17 03 03 00 3d ....= >>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (61 bytes => 61 (0x3D)) >>>>>> 0000 - ad dd 3e d9 ee ab 56 65-50 1c 72 2a d8 62 7f 90 ..>...VeP.r*.b.. >>>>>> 0010 - 13 71 7d 37 39 40 fb 89-8f 05 4b 39 44 9d 4d 67 .q}79 at ....K9D.Mg >>>>>> 0020 - e3 41 29 b6 3e e8 fe 04-1b 8e eb 7a 4c e2 14 a0 .A).>......zL... >>>>>> 0030 - b1 c2 47 3f 94 35 ed ab-8a d1 75 3b ba ..G?.5....u;. >>>>>> SSL_accept:TLSv1.3 early data >>>>>> SSL_accept:SSLv3/TLS read client certificate >>>>>> SSL_accept:SSLv3/TLS read finished >>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>>> 0000 - 17 03 03 00 da 52 1f 48-00 f4 31 13 90 7f 9c c2 .....R.H..1..... >>>>>> 0010 - fc 70 1a fc f7 4a 48 e7-31 ad 37 ab b5 2b 4e 5c .p...JH.1.7..+N\ >>>>>> 0020 - e8 d8 6d e9 af 6c 4f c1-9e 7b ea ff ef b3 eb 74 ..m..lO..{.....t >>>>>> 0030 - 27 67 10 21 66 5b 32 13-31 bc 99 d5 1c 6c 79 55 'g.!f[2.1....lyU >>>>>> 0040 - f3 3e f6 4b 07 4d a9 78-3d 12 8a f5 38 ef d9 f4 .>.K.M.x=...8... >>>>>> 0050 - 48 e0 2c 35 94 06 4f eb-09 e6 70 fb 59 95 7a c8 H.,5..O...p.Y.z. >>>>>> 0060 - 24 dd 24 e2 f9 63 b9 3c-f2 66 86 c4 73 44 53 fd $.$..c.<.f..sDS. >>>>>> 0070 - ca 67 8f 01 d6 db 70 f9-60 bc 50 11 51 72 dc 63 .g....p.`.P.Qr.c >>>>>> 0080 - 12 ca 4f 23 e2 c5 d1 1d-e5 b0 d4 ec 89 ca 28 be ..O#..........(. >>>>>> 0090 - 9c 30 83 40 02 a4 62 a8-5c b3 20 1a ab 39 b7 7b .0. at ..b.\. ..9.{ >>>>>> 00a0 - 89 13 39 87 73 be a8 f8-60 13 31 0a 48 5c 79 b9 ..9.s...`.1.H\y. >>>>>> 00b0 - cc 4a 51 e3 0d d2 b4 93-c0 1f 3a 22 b3 fa 24 a0 .JQ.......:"..$. >>>>>> 00c0 - 7c f6 76 79 d0 2d 5b 1a-ff a6 e9 e1 40 d3 b1 8c |.vy.-[..... at ... >>>>>> 00d0 - 0a fa fa de f3 8e d6 ad-9a 22 6b 67 0b 88 18 ........."kg... >>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>>> 0000 - 17 03 03 00 da 46 aa ea-6a 37 b1 35 e8 41 c8 b3 .....F..j7.5.A.. >>>>>> 0010 - 84 25 af 1c 36 a3 6d 78-a4 44 4a 83 52 ef 13 7c .%..6.mx.DJ.R..| >>>>>> 0020 - 8f 18 d3 4c f8 22 c8 b3-ad d0 d0 5b 47 a0 43 da ...L.".....[G.C. >>>>>> 0030 - d2 6e 04 8f dc c9 56 90-58 87 62 63 4c cc 31 ec .n....V.X.bcL.1. >>>>>> 0040 - b8 c9 18 be 41 32 e1 3c-00 41 2a f1 4d 5c 2d 44 ....A2.<.A*.M\-D >>>>>> 0050 - 8c aa e1 f0 ed 38 ee 44-64 e5 fd ea 58 3b 84 5d .....8.Dd...X;.] >>>>>> 0060 - 83 39 21 2e fe 79 4d 76-10 65 87 0f 3c ac df 28 .9!..yMv.e..<..( >>>>>> 0070 - 49 f8 60 eb be 49 e4 0a-0b 6a 03 2b 9d cf 9b a5 I.`..I...j.+.... >>>>>> 0080 - 03 56 58 32 c2 b2 59 f9-0a 0d f0 ae af ff 20 19 .VX2..Y....... . >>>>>> 0090 - e5 6e e4 86 2f 5e 3f 7d-47 d5 73 ae 89 48 a7 66 .n../^?}G.s..H.f >>>>>> 00a0 - fb 2d 83 60 e8 8b ab 27-12 db 24 78 54 eb 14 2d .-.`...'..$xT..- >>>>>> 00b0 - b7 c6 17 2d 3c 91 57 ac-6e 35 b8 c3 fa c2 42 48 ...-<.W.n5....BH >>>>>> 00c0 - 2a cb aa 98 32 89 8a ce-0c f7 cd 5e fb bf 6d 33 *...2......^..m3 >>>>>> 00d0 - 08 50 cf 1e 06 bb a1 98-be a4 a9 51 9a b0 34 .P.........Q..4 >>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>> 0000 - 17 03 03 00 12 c5 9b 73-cc 91 7e 48 cb 25 31 a0 .......s..~H.%1. >>>>>> 0010 - 67 41 db bb 0f 62 d8 gA...b. >>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>> 0000 - 17 03 03 00 12 0f dd 3f-c1 7c e6 b0 cc ea f0 13 .......?.|...... >>>>>> 0010 - 00 d8 01 de ef 7c bb .....|. >>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>> 0000 - 17 03 03 00 1e ..... >>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (30 bytes => 30 (0x1E)) >>>>>> 0000 - d6 88 44 82 cb 23 16 ba-c9 a4 fb 55 51 08 90 c1 ..D..#.....UQ... >>>>>> 0010 - bf bd a1 7f 0e 37 b0 b4-b5 df f1 07 6c 07 .....7......l. >>>>>> I am a clientwrite to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>> 0000 - 17 03 03 00 12 c0 70 5d-14 e7 69 57 0a d8 64 16 ......p]..iW..d. >>>>>> 0010 - 0c 90 06 0f c3 4d 1d .....M. >>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>> 0000 - 17 03 03 00 13 ..... >>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (19 bytes => 19 (0x13)) >>>>>> 0000 - 60 28 5b ff bb 0d 9f 96-9a 2d cb fd 60 eb 96 62 `([......-..`..b >>>>>> 0010 - 53 e6 25 S.% >>>>>> SSL3 alert read:warning:close notify >>>>>> DONE >>>>>> shutting down SSL >>>>>> CONNECTION CLOSED >>>>>> >>>>>> >>>>>> I am using the following JDK version on MacOS: >>>>>> >>>>>> ssl git:(cert_cb_openssl_1_1_1) ? /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java -version >>>>>> java version "11" 2018-09-25 >>>>>> Java(TM) SE Runtime Environment 18.9 (build 11+28) >>>>>> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) >>>>>> >>>>>> For this to work you will need to have openssl 1.1.1 installed. >>>>>> >>>>>> Any help would be welcome, >>>>>> Norman >>>>>> >>>>>> [1] https://github.com/netty/netty-tcnative >>>>>> >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Mon Sep 17 12:12:35 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 17 Sep 2018 07:12:35 -0500 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> Message-ID: On Sun, Sep 16, 2018 at 2:38 PM Will Sargent wrote: > > > 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 don't know of any research or papers that explicitly say that SecurityManager is "legacy". I did some research into this a while ago, and while SecurityManager has some major flaws, I don't know of any other way to sandbox a Java application. Another interesting point is that, when it comes to the actual work of sandboxing, all of the difficult work is done by AccessController and AccessControlContext. However it's difficult to say that these should be legacy without addressing the problem of JAAS, which also uses these constructs to pass and check the current Subject. This aspect of JAAS seems to be known to be inherently defective by several (perhaps most) application server vendors, as those which use JAAS also tend to have a custom, thread-local-based solution for handling Subjects which is used in place of the ACC-attachment mechanism. With that in mind it's quite difficult to imagine a path that starts with deprecating SecurityManager and ends with its removal, unless JAAS is addressed. And if JAAS is successfully decoupled from AccessController, then maybe SecurityManager becomes a somewhat more viable technology again: based on some research I did a while back, it should be possible to reimplement it compatibly (and purely in Java) with less overhead and with more convenient constructs (once JAAS is out of the way). That said, the main security-oriented use of SecurityManager isn't around sandboxing fully untrusted code (since it cannot sandbox memory allocations or CPU usage), it's more about ensuring that your trusted code isn't inadvertently exploited, and (as Alan said) also occasionally about fencing in badly-behaved third-party code that (for whatever reason) cannot be modified. Though we've had AOP and similar technologies for quite a long time, as well as plenty of other frameworks that allow build-time and run-time bytecode rewriting, and it's not hard to argue that this is a better solution to this class of problem. Anyway I think that a better first move would have been to instead deal with the JAAS issue, one way or another. If this cannot be done, then the access controller is here to stay, and the security manager issue is moot. -- - DML From norman.maurer at googlemail.com Mon Sep 17 12:28:32 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 17 Sep 2018 14:28:32 +0200 Subject: sun.security.ssl.ProtocolVersion.valueOf(...) in Java8 and TLSv1.3 Message-ID: Hi all, In netty we support using OpenSSL for native SSL which recently added TLSv1.3 support as part of OpenSSL 1.1.1. In an ideal world we would be able to use this even with Java8 which is almost true except the fact that sun.security.ssl.ProtocolVersion.valueOf(?) will throw an IllegalArgumentException when the string ?TLSv1.3? is provided. This is problematic as this happens during validation in the default TrustManager used by the OpenJDK. The stack looks something like this: java.lang.IllegalArgumentException: TLSv1.3 at sun.security.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:187) at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:258) at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136) I could work around this by just wrap the SSLSession and return TLSv1.2 during validation as the same validation should be done as in the TLSv1.2 implementation but this is really just a hack.So I wonder if you would consider to either add support for parsing TLSv1.3 to the internal enum or just handle it more gracefully. Another thing that would work of course is to always provide a custom X509ExtendedTrustManager but I hoped to be able to re-use the default implementation as it already implements a lot of verification logic. WDYT ? Norman From jini at zeus.net.au Mon Sep 17 12:42:52 2018 From: jini at zeus.net.au (Peter) Date: Mon, 17 Sep 2018 22:42:52 +1000 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> Message-ID: <5B9FA14C.5060702@zeus.net.au> Has the attached regression been fixed "Re: -Djava.security.manager=problems for service provider"? I recently changed all our code to use System.setSecurityManager(), because of this regression, prior to that we used the command line option, it's going to take some time to revert... SecurityManager is of critical importance in our software, I wish it were simpler, we solved the performance issues about 8 years ago, but complexity is still a pain point. Thanks, Peter. On 17/09/2018 7:09 PM, Alan Bateman wrote: > On 16/09/2018 20:37, Will Sargent wrote: >> > 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 don't know of any research or papers that explicitly say that >> SecurityManager is "legacy". I did some research into this a while >> ago, and while SecurityManager has some major flaws, I don't know of >> any other way to sandbox a Java application. >> > Have you looked into native containers? It's easy to find examples of > applications running in a docker container for example. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: Naoto Sato Subject: Re: -Djava.security.manager=problems for service provider Date: Thu, 29 Mar 2018 11:02:41 -0700 Size: 44549 URL: From norman.maurer at googlemail.com Mon Sep 17 12:57:23 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 17 Sep 2018 14:57:23 +0200 Subject: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well In-Reply-To: <684F48EB-AC55-436F-9B2E-1401E2731E21@googlemail.com> References: <9D5DC438-0D54-4A88-9711-19C7B5A34A87@googlemail.com> <684F48EB-AC55-436F-9B2E-1401E2731E21@googlemail.com> Message-ID: <5F699E03-B781-469D-A4C4-B81E9FE4E3E2@googlemail.com> Should I open an issue somewhere to keep track of it or will you take care of it ? Bye Norman > On 11. Sep 2018, at 17:01, Norman Maurer wrote: > > This sounds great. > > I have no idea how many people still use X509TrustManager, sorry. > > It may be a good idea to add something to the java docs to tell people to prefer X509ExtendedTrustManager as well. > > Bye > Norman > >> Am 11.09.2018 um 16:44 schrieb Xuelei Fan : >> >> Hi Norman, >> >> >> It may be doable by adding a delegation mode to public TrustManagerFactory: >> TrustManagerFactory.init(X509TrustManager proxy) >> >> However, the X509ExtendedTrustManager should be recommended for now since its introducing in JDK 7. >> >> Do you know how many users are still using the X509TrustManager implementation? >> >> Thanks, >> Xuelei >> >>> On 9/11/2018 3:32 AM, Norman Maurer wrote: >>> Hi all, >>> Would it be possible to consider exposing SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible to reuse it when a custom SSLEngine / SSLContextSpi is provided ? >>> I am asking because it provides really nice extra functionality by wrapping for X509TrustManager implementation and do extra hostname checks etc. At the moment we can not make use of this extra functionality in netty with our custom SSLEngine implementation as there is no way to access this. Which means depending on if the user use our implementation or the default implementation the behaviour if quite different when using a X509TrustManager in the sense that when using the default implementation a lot of extra checks are done. >>> As the extra checks done in AbstractTrustManagerWrapper is not really depending on the underlying SSLContextSpi implementation (at least as far as I was able to understand it so far) it would be nice to be able to make use of it. >>> Bye >>> Norman From jini at zeus.net.au Mon Sep 17 13:04:05 2018 From: jini at zeus.net.au (Peter) Date: Mon, 17 Sep 2018 23:04:05 +1000 Subject: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well In-Reply-To: <5F699E03-B781-469D-A4C4-B81E9FE4E3E2@googlemail.com> References: <9D5DC438-0D54-4A88-9711-19C7B5A34A87@googlemail.com> <684F48EB-AC55-436F-9B2E-1401E2731E21@googlemail.com> <5F699E03-B781-469D-A4C4-B81E9FE4E3E2@googlemail.com> Message-ID: <5B9FA645.6010008@zeus.net.au> Just recently completed updating to X509ExtendedTrustManager, but not comprehensively yet, as some code is still using X509TrustManager, but will look into updating it too in the near future ... Thanks, Peter. On 17/09/2018 10:57 PM, Norman Maurer wrote: > Should I open an issue somewhere to keep track of it or will you take care of it ? > > Bye > Norman > > >> On 11. Sep 2018, at 17:01, Norman Maurer wrote: >> >> This sounds great. >> >> I have no idea how many people still use X509TrustManager, sorry. >> >> It may be a good idea to add something to the java docs to tell people to prefer X509ExtendedTrustManager as well. >> >> Bye >> Norman >> >>> Am 11.09.2018 um 16:44 schrieb Xuelei Fan: >>> >>> Hi Norman, >>> >>> >>> It may be doable by adding a delegation mode to public TrustManagerFactory: >>> TrustManagerFactory.init(X509TrustManager proxy) >>> >>> However, the X509ExtendedTrustManager should be recommended for now since its introducing in JDK 7. >>> >>> Do you know how many users are still using the X509TrustManager implementation? >>> >>> Thanks, >>> Xuelei >>> >>>> On 9/11/2018 3:32 AM, Norman Maurer wrote: >>>> Hi all, >>>> Would it be possible to consider exposing SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible to reuse it when a custom SSLEngine / SSLContextSpi is provided ? >>>> I am asking because it provides really nice extra functionality by wrapping for X509TrustManager implementation and do extra hostname checks etc. At the moment we can not make use of this extra functionality in netty with our custom SSLEngine implementation as there is no way to access this. Which means depending on if the user use our implementation or the default implementation the behaviour if quite different when using a X509TrustManager in the sense that when using the default implementation a lot of extra checks are done. >>>> As the extra checks done in AbstractTrustManagerWrapper is not really depending on the underlying SSLContextSpi implementation (at least as far as I was able to understand it so far) it would be nice to be able to make use of it. >>>> Bye >>>> Norman From will.sargent at gmail.com Mon Sep 17 15:10:57 2018 From: will.sargent at gmail.com (Will Sargent) Date: Mon, 17 Sep 2018 08:10:57 -0700 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> Message-ID: I'm talking about sandboxing from the perspective of object capability patterns, where you can contain some actor inside a constrained classloader context and only allow execution through proxies that may be revoked. The JEE model, in theory, allows you to run several web applications without them stepping on each others toes, although I don't know how well implemented that is in practice. BTW, Docker runs as root, so the virtual machine is where you get additional security: https://github.com/wsargent/docker-cheat-sheet#security On Mon, Sep 17, 2018 at 2:09 AM Alan Bateman wrote: > On 16/09/2018 20:37, Will Sargent wrote: > > > 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 don't know of any research or papers that explicitly say that > SecurityManager is "legacy". I did some research into this a while ago, > and while SecurityManager has some major flaws, I don't know of any other > way to sandbox a Java application. > > Have you looked into native containers? It's easy to find examples of > applications running in a docker container for example. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Mon Sep 17 15:31:47 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 17 Sep 2018 08:31:47 -0700 Subject: [12] Review Request: 8210692 The "com.sun.awt.SecurityWarning" class can be dropped In-Reply-To: <6cea33e2-db84-46df-10f2-d9d3d570062f@oracle.com> References: <5dd78e90-dce5-2722-195e-1e266b7086ba@oracle.com> <5B9D7300.8080207@oracle.com> <6cea33e2-db84-46df-10f2-d9d3d570062f@oracle.com> Message-ID: <933c7bc3-5ba3-bb63-2df8-20de1a877115@oracle.com> On 9/16/18 12:48 AM, Alan Bateman wrote: > On 15/09/2018 22:00, Philip Race wrote: >> 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. > I think Sergey's changes are okay. > > The main issue with com.sun.awt API is that it tried to be both an > exported and internal/unsupported API at the same time (it's javadoc > reads "This class is an implementation detail and only meant for > limited use outside of the core platform"). This doesn't work for > modules. In addition the design principles in JEP 200 make it clear > that standard modules should not export a non-standard package to all > modules. If there has been extensive use of this API then I could > imagine it being refactored and moved into a JDK-specific module but > there was little evidence of usage. So where we ended up in JDK 9 is > that the API is not exported. This means, as Mandy hinted, you can't > compile against this API (at least not without --add-exports to the > compiler). Existing code using this API will continue to run on JDK 9, > 10, 11 or until the java.desktop module is fully encapsulated or the > SecurityWarning class is removed. Sergey got there first. > Yes.? Since it was decided not to export com.sun.awt API (JDK-8051640), they are no longer supported.? Is there a CSR filed officially declaring com.sun.awt APIs are no longer supported? Since it's already deprecated for removal, it may be worth to have a release note for JDK-8205588 if we didn't officially declare it unsupported. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Sep 17 15:37:21 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 17 Sep 2018 11:37:21 -0400 Subject: SSL session cache default maximum number of entries In-Reply-To: <4CCB1576-6BFA-430B-974D-86DFD0D864E6@amazon.com> References: <7BB7D5C5-2B63-4451-AC8B-3C65D231BBDC@amazon.com> <65e68e95-dac4-7443-02ad-0e2375b740cb@oracle.com> <4CCB1576-6BFA-430B-974D-86DFD0D864E6@amazon.com> Message-ID: <6208f73e-2a3a-896c-15dd-4ee608cfc235@oracle.com> On 9/12/18 2:25 PM, Hohensee, Paul wrote: > Thanks very much for investigating. We're aware that the cache size can be set by the user, but many of our users haven't done so because it hasn't been necessary, and boom. Would you mind filing a bug and we will look into it? Thanks, Sean > > Paul > > ?On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan" wrote: > > Hi Paul, > > Thank you for bringing this issue to our attention. While we agree that > this does indeed seem like an issue that should be addressed, it is > quite late in the JDK 11 schedule, and it does not appear to be a new > issue introduced in JDK 11. We will be investigating this offline and > will get back to you as soon as we can with more details. Offhand, I > think that we would be able to change the default in an update release. > > Also, you are probably already be aware of this, but you can use the > SSLSessionContext.setSessionCacheSize() API as well as the > "javax.net.ssl.sessionCacheSize" system property to customize the cache > size. > > --Sean > > On 9/11/18 12:02 PM, Sean Mullan wrote: > > cross-posting to security-dev since this is related to SSL/TLS. > > > > On 9/11/18 11:41 AM, Hohensee, Paul wrote: > >> The default value for the maximum number of entries in the SSL session > >> cache (which is a SoftReference cache) is infinite, and the entry > >> timeout is 24 hours. With larger heaps, we?re running into situations > >> where the cache ends up with several million entries when the 24 hours > >> are up. They?re then all invalidated at the same time, resulting in > >> multi-minute pauses (effectively service failures). We?ve experimented > >> with using 10k as the default maximum number of entries with good > >> results (i.e., no latency increases due to sessions falling out of the > >> cache). It?s late and a long shot for JDK11: we?d love to see it > >> changed there because 11 is an LTS release and this is, at least > >> nominally, a behavior change which might not be acceptable in 11u. > >> What do people think? > >> > >> Thanks, > >> > >> Paul > >> > > From xuelei.fan at oracle.com Mon Sep 17 16:51:33 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Sep 2018 09:51:33 -0700 Subject: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well In-Reply-To: <5F699E03-B781-469D-A4C4-B81E9FE4E3E2@googlemail.com> References: <9D5DC438-0D54-4A88-9711-19C7B5A34A87@googlemail.com> <684F48EB-AC55-436F-9B2E-1401E2731E21@googlemail.com> <5F699E03-B781-469D-A4C4-B81E9FE4E3E2@googlemail.com> Message-ID: <85362754-2b4d-da78-cbe2-89052b71b44b@oracle.com> Hi Norman, Please file an issue for the tracking. Thanks, Xuelei On 9/17/2018 5:57 AM, Norman Maurer wrote: > Should I open an issue somewhere to keep track of it or will you take care of it ? > > Bye > Norman > > >> On 11. Sep 2018, at 17:01, Norman Maurer wrote: >> >> This sounds great. >> >> I have no idea how many people still use X509TrustManager, sorry. >> >> It may be a good idea to add something to the java docs to tell people to prefer X509ExtendedTrustManager as well. >> >> Bye >> Norman >> >>> Am 11.09.2018 um 16:44 schrieb Xuelei Fan : >>> >>> Hi Norman, >>> >>> >>> It may be doable by adding a delegation mode to public TrustManagerFactory: >>> TrustManagerFactory.init(X509TrustManager proxy) >>> >>> However, the X509ExtendedTrustManager should be recommended for now since its introducing in JDK 7. >>> >>> Do you know how many users are still using the X509TrustManager implementation? >>> >>> Thanks, >>> Xuelei >>> >>>> On 9/11/2018 3:32 AM, Norman Maurer wrote: >>>> Hi all, >>>> Would it be possible to consider exposing SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible to reuse it when a custom SSLEngine / SSLContextSpi is provided ? >>>> I am asking because it provides really nice extra functionality by wrapping for X509TrustManager implementation and do extra hostname checks etc. At the moment we can not make use of this extra functionality in netty with our custom SSLEngine implementation as there is no way to access this. Which means depending on if the user use our implementation or the default implementation the behaviour if quite different when using a X509TrustManager in the sense that when using the default implementation a lot of extra checks are done. >>>> As the extra checks done in AbstractTrustManagerWrapper is not really depending on the underlying SSLContextSpi implementation (at least as far as I was able to understand it so far) it would be nice to be able to make use of it. >>>> Bye >>>> Norman > From norman.maurer at googlemail.com Mon Sep 17 17:11:10 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 17 Sep 2018 19:11:10 +0200 Subject: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well In-Reply-To: <85362754-2b4d-da78-cbe2-89052b71b44b@oracle.com> References: <9D5DC438-0D54-4A88-9711-19C7B5A34A87@googlemail.com> <684F48EB-AC55-436F-9B2E-1401E2731E21@googlemail.com> <5F699E03-B781-469D-A4C4-B81E9FE4E3E2@googlemail.com> <85362754-2b4d-da78-cbe2-89052b71b44b@oracle.com> Message-ID: <87281E2B-CAA4-49DE-86EC-EB1EB878D15F@googlemail.com> Done.. ID: 9057278 Thanks Norman > On 17. Sep 2018, at 18:51, Xuelei Fan wrote: > > Hi Norman, > > Please file an issue for the tracking. > > Thanks, > Xuelei > > On 9/17/2018 5:57 AM, Norman Maurer wrote: >> Should I open an issue somewhere to keep track of it or will you take care of it ? >> Bye >> Norman >>> On 11. Sep 2018, at 17:01, Norman Maurer wrote: >>> >>> This sounds great. >>> >>> I have no idea how many people still use X509TrustManager, sorry. >>> >>> It may be a good idea to add something to the java docs to tell people to prefer X509ExtendedTrustManager as well. >>> >>> Bye >>> Norman >>> >>>> Am 11.09.2018 um 16:44 schrieb Xuelei Fan : >>>> >>>> Hi Norman, >>>> >>>> >>>> It may be doable by adding a delegation mode to public TrustManagerFactory: >>>> TrustManagerFactory.init(X509TrustManager proxy) >>>> >>>> However, the X509ExtendedTrustManager should be recommended for now since its introducing in JDK 7. >>>> >>>> Do you know how many users are still using the X509TrustManager implementation? >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> On 9/11/2018 3:32 AM, Norman Maurer wrote: >>>>> Hi all, >>>>> Would it be possible to consider exposing SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible to reuse it when a custom SSLEngine / SSLContextSpi is provided ? >>>>> I am asking because it provides really nice extra functionality by wrapping for X509TrustManager implementation and do extra hostname checks etc. At the moment we can not make use of this extra functionality in netty with our custom SSLEngine implementation as there is no way to access this. Which means depending on if the user use our implementation or the default implementation the behaviour if quite different when using a X509TrustManager in the sense that when using the default implementation a lot of extra checks are done. >>>>> As the extra checks done in AbstractTrustManagerWrapper is not really depending on the underlying SSLContextSpi implementation (at least as far as I was able to understand it so far) it would be nice to be able to make use of it. >>>>> Bye >>>>> Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Sep 17 17:35:03 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Sep 2018 10:35:03 -0700 Subject: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: <0EB21A4C-7DFF-4878-9446-182DA35F0A8C@googlemail.com> References: <32bad254-1a8c-7933-d5a0-0b8ce3ed2f68@oracle.com> <05EF82F5-6506-4928-8030-B9BEEE64E1F1@googlemail.com> <0EB21A4C-7DFF-4878-9446-182DA35F0A8C@googlemail.com> Message-ID: <2dea4403-e019-613d-373e-75c789029cef@oracle.com> Hi Norman, Thank you so much for the reproducing code. Would you mind file a bug for this issue? Thanks, Xuelei On 9/17/2018 3:39 AM, Norman Maurer wrote: > Hi all, > > > As requested I pushed a pure JDK reproducer to GitHub which you can > easily use to reproduce the problem. All the details how to run it etc > are in the README.md file. I also included a server to show that all > works if we use the JDK on the client side and server side. > Also as stated before you will see that the cert will be send even if > you use OpenSSL on the serverside if you replace ?-Verify 1? with > ?-verify 1? (which is kind of the same as setWantClientAuth(true)). > Please don't hesitate to ping me if you need any more details or have > any more questions. > > https://github.com/normanmaurer/jdktls13bugreproducer > > > Here is the output with debugging enabled on the client side. > > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.515 > CEST|SSLContextImpl.java:427|System property jdk.tls.client.cipherSuites > is set to 'null' > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.529 > CEST|SSLContextImpl.java:427|System property jdk.tls.server.cipherSuites > is set to 'null' > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.563 > CEST|SSLCipher.java:437|jdk.tls.keyLimits: ?entry = AES/GCM/NoPadding > KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.577 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.577 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.580 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.580 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DH_anon_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DH_anon_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDHE_ECDSA_WITH_RC4_128_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDHE_ECDSA_WITH_RC4_128_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDHE_RSA_WITH_RC4_128_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDHE_RSA_WITH_RC4_128_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_RSA_WITH_RC4_128_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_RSA_WITH_RC4_128_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDH_ECDSA_WITH_RC4_128_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDH_ECDSA_WITH_RC4_128_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDH_RSA_WITH_RC4_128_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDH_RSA_WITH_RC4_128_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_RSA_WITH_RC4_128_MD5 > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_RSA_WITH_RC4_128_MD5 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDH_anon_WITH_RC4_128_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDH_anon_WITH_RC4_128_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DH_anon_WITH_RC4_128_MD5 > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DH_anon_WITH_RC4_128_MD5 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_RSA_EXPORT_WITH_DES40_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_RSA_EXPORT_WITH_DES40_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_RSA_EXPORT_WITH_RC4_40_MD5 > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_RSA_EXPORT_WITH_RC4_40_MD5 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.591 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.593 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.593 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.599 > CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: > SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.599 > CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: > SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.642 > CEST|SunX509KeyManagerImpl.java:164|found key for : 1 ( > ? "certificate" : { > ? ? "version" ? ? ? ? ? ?: "v3", > ? ? "serial number" ? ? ?: "20 C3 8D C4 49 66 D0 02", > ? ? "signature algorithm": "SHA256withRSA", > ? ? "issuer" ? ? ? ? ? ? : > "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", > ? ? "not before" ? ? ? ? : "2013-08-02 09:51:36.000 CEST", > ? ? "not ?after" ? ? ? ? : "10000-01-01 24:59:59.000 CET", > ? ? "subject" ? ? ? ? ? ?: > "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", > ? ? "subject public key" : "RSA"} > ) > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 > CEST|SSLContextImpl.java:115|trigger seeding of SecureRandom > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 > CEST|SSLContextImpl.java:119|done seeding of SecureRandom > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.665 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_AES_128_GCM_SHA256 for TLS12 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.666 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_AES_256_GCM_SHA384 for TLS12 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_AES_128_GCM_SHA256 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_AES_256_GCM_SHA384 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS11 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_AES_128_GCM_SHA256 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_AES_256_GCM_SHA384 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS10 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 > CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS10 > javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.690 > CEST|ServerNameExtension.java:255|Unable to indicate server name > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.690 > CEST|SSLExtensions.java:235|Ignore, context unavailable extension: > server_name > javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.701 > CEST|SignatureScheme.java:282|Signature algorithm, ed25519, is not > supported by the underlying providers > javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.702 > CEST|SignatureScheme.java:282|Signature algorithm, ed448, is not > supported by the underlying providers > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.706 > CEST|SignatureScheme.java:358|Ignore disabled signature sheme: rsa_md5 > javax.net.ssl|INFO|01|main|2018-09-17 11:51:54.706 > CEST|AlpnExtension.java:161|No available application protocols > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.706 > CEST|SSLExtensions.java:235|Ignore, context unavailable extension: > application_layer_protocol_negotiation > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.707 > CEST|SSLExtensions.java:235|Ignore, context unavailable extension: cookie > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 > CEST|SSLExtensions.java:235|Ignore, context unavailable extension: > renegotiation_info > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 > CEST|PreSharedKeyExtension.java:606|No session to resume. > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 > CEST|SSLExtensions.java:235|Ignore, context unavailable extension: > pre_shared_key > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 > CEST|ClientHello.java:633|Produced ClientHello handshake message ( > "ClientHello": { > ? "client version" ? ? ?: "TLSv1.2", > ? "random" ? ? ? ? ? ? ?: "66 2E BE D3 8A 77 39 06 3B 5A 34 03 7D EE 74 > BB 08 D2 19 FD 50 17 2D 84 29 AA FB E0 EE ED 50 69", > ? "session id" ? ? ? ? ?: "0B 03 C8 E2 D2 A5 CD 3A 22 C5 85 17 06 64 A9 > 30 14 62 C0 AF AB 67 CE 63 50 41 50 7F 6B FD 4C 9F", > ? "cipher suites" ? ? ? : "[TLS_AES_128_GCM_SHA256(0x1301), > TLS_AES_256_GCM_SHA384(0x1302), > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), > TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), > TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), > TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), > TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), > TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), > TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), > TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), > TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), > TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), > TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), > TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), > TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), > TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), > TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), > TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]", > ? "compression methods" : "00", > ? "extensions" ? ? ? ? ?: [ > ? ? "status_request (5)": { > ? ? ? "certificate status type": ocsp > ? ? ? "OCSP status request": { > ? ? ? ? "responder_id": > ? ? ? ? "request extensions": { > ? ? ? ? ? > ? ? ? ? } > ? ? ? } > ? ? }, > ? ? "supported_groups (10)": { > ? ? ? "versions": [secp256r1, secp384r1, secp521r1, sect283k1, > sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, > ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] > ? ? }, > ? ? "ec_point_formats (11)": { > ? ? ? "formats": [uncompressed] > ? ? }, > ? ? "signature_algorithms (13)": { > ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, > rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, > rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] > ? ? }, > ? ? "signature_algorithms_cert (50)": { > ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, > rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, > rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, > rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] > ? ? }, > ? ? "status_request_v2 (17)": { > ? ? ? "cert status request": { > ? ? ? ? "certificate status type": ocsp_multi > ? ? ? ? "OCSP status request": { > ? ? ? ? ? "responder_id": > ? ? ? ? ? "request extensions": { > ? ? ? ? ? ? > ? ? ? ? ? } > ? ? ? ? } > ? ? ? } > ? ? }, > ? ? "extended_master_secret (23)": { > ? ? ? > ? ? }, > ? ? "supported_versions (43)": { > ? ? ? "versions": [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1] > ? ? }, > ? ? "psk_key_exchange_modes (45)": { > ? ? ? "ke_modes": [psk_dhe_ke] > ? ? }, > ? ? "key_share (51)": { > ? ? ? "client_shares": [ > ? ? ? ? { > ? ? ? ? ? "named group": secp256r1 > ? ? ? ? ? "key_exchange": { > ? ? ? ? ? ? 0000: 04 A3 9F B9 05 27 00 38 ? C4 D7 61 6C 66 1F 4A 8D > ?.....'.8..alf.J. > ? ? ? ? ? ? 0010: B1 02 6F 0B F6 E1 BD 50 ? 93 52 86 2C D2 3C 8D 1A > ?..o....P.R.,.<.. > ? ? ? ? ? ? 0020: 10 A9 CD F0 40 F4 CD 04 ? 25 A1 11 E2 58 23 A3 24 > ?.... at ...%...X#.$ > ? ? ? ? ? ? 0030: CA E8 8F 28 F7 2B 65 96 ? B2 E3 A1 AE 99 24 94 28 > ?...(.+e......$.( > ? ? ? ? ? ? 0040: 83 > ? ? ? ? ? } > ? ? ? ? }, > ? ? ? ] > ? ? } > ? ] > } > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 > CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 417 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.719 > CEST|SSLSocketOutputRecord.java:255|Raw write ( > ? 0000: 16 03 03 01 A1 01 00 01 ? 9D 03 03 66 2E BE D3 8A ?...........f.... > ? 0010: 77 39 06 3B 5A 34 03 7D ? EE 74 BB 08 D2 19 FD 50 ?w9.;Z4...t.....P > ? 0020: 17 2D 84 29 AA FB E0 EE ? ED 50 69 20 0B 03 C8 E2 ?.-.).....Pi .... > ? 0030: D2 A5 CD 3A 22 C5 85 17 ? 06 64 A9 30 14 62 C0 AF ?...:"....d.0.b.. > ? 0040: AB 67 CE 63 50 41 50 7F ? 6B FD 4C 9F 00 5A 13 01 ?.g.cPAP.k.L..Z.. > ? 0050: 13 02 C0 2C C0 2B C0 30 ? 00 9D C0 2E C0 32 00 9F ?...,.+.0.....2.. > ? 0060: 00 A3 C0 2F 00 9C C0 2D ? C0 31 00 9E 00 A2 C0 24 ?.../...-.1.....$ > ? 0070: C0 28 00 3D C0 26 C0 2A ? 00 6B 00 6A C0 0A C0 14 ?.(.=.&.*.k.j.... > ? 0080: 00 35 C0 05 C0 0F 00 39 ? 00 38 C0 23 C0 27 00 3C ?.5.....9.8.#.'.< > ? 0090: C0 25 C0 29 00 67 00 40 ? C0 09 C0 13 00 2F C0 04 ?.%.).g. at ...../.. > ? 00A0: C0 0E 00 33 00 32 00 FF ? 01 00 00 FA 00 05 00 05 ?...3.2.......... > ? 00B0: 01 00 00 00 00 00 0A 00 ? 20 00 1E 00 17 00 18 00 ?........ ....... > ? 00C0: 19 00 09 00 0A 00 0B 00 ? 0C 00 0D 00 0E 00 16 01 ?................ > ? 00D0: 00 01 01 01 02 01 03 01 ? 04 00 0B 00 02 01 00 00 ?................ > ? 00E0: 0D 00 28 00 26 04 03 05 ? 03 06 03 08 04 08 05 08 ?..(.&........... > ? 00F0: 06 08 09 08 0A 08 0B 04 ? 01 05 01 06 01 04 02 03 ?................ > ? 0100: 03 03 01 03 02 02 03 02 ? 01 02 02 00 32 00 28 00 ?............2.(. > ? 0110: 26 04 03 05 03 06 03 08 ? 04 08 05 08 06 08 09 08 ?&............... > ? 0120: 0A 08 0B 04 01 05 01 06 ? 01 04 02 03 03 03 01 03 ?................ > ? 0130: 02 02 03 02 01 02 02 00 ? 11 00 09 00 07 02 00 04 ?................ > ? 0140: 00 00 00 00 00 17 00 00 ? 00 2B 00 09 08 03 04 03 ?.........+...... > ? 0150: 03 03 02 03 01 00 2D 00 ? 02 01 01 00 33 00 47 00 ?......-.....3.G. > ? 0160: 45 00 17 00 41 04 A3 9F ? B9 05 27 00 38 C4 D7 61 ?E...A.....'.8..a > ? 0170: 6C 66 1F 4A 8D B1 02 6F ? 0B F6 E1 BD 50 93 52 86 ?lf.J...o....P.R. > ? 0180: 2C D2 3C 8D 1A 10 A9 CD ? F0 40 F4 CD 04 25 A1 11 ?,.<...... at ...%.. > ? 0190: E2 58 23 A3 24 CA E8 8F ? 28 F7 2B 65 96 B2 E3 A1 ?.X#.$...(.+e.... > ? 01A0: AE 99 24 94 28 83 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?..$.(. > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: 16 03 03 00 9B ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 > CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length = 155 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.721 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: 02 00 00 97 03 03 AB 76 ? F1 BA F3 B1 F0 DD 53 AC ?.......v......S. > ? 0010: 5B 54 E9 E4 2E F8 44 D2 ? 5E B2 59 85 0D 16 79 EE ?[T....D.^.Y...y. > ? 0020: A7 66 8A 84 69 2A 20 0B ? 03 C8 E2 D2 A5 CD 3A 22 ?.f..i* .......:" > ? 0030: C5 85 17 06 64 A9 30 14 ? 62 C0 AF AB 67 CE 63 50 ?....d.0.b...g.cP > ? 0040: 41 50 7F 6B FD 4C 9F 13 ? 01 00 00 4F 00 2B 00 02 ?AP.k.L.....O.+.. > ? 0050: 03 04 00 33 00 45 00 17 ? 00 41 04 18 4A 46 BB 73 ?...3.E...A..JF.s > ? 0060: F4 6F 5D F0 3C 98 AD 70 ? 7E 13 D6 C0 E5 C0 28 5A ?.o].<..p......(Z > ? 0070: D7 42 78 95 68 E0 85 B7 ? 06 CD DB 3C 35 DA AF E8 ?.Bx.h......<5... > ? 0080: 95 D6 A2 3C 77 CF 7E 8E ? C8 94 50 BA CD 18 3F DA ?... ? 0090: E3 A3 25 E9 F3 C9 A9 7F ? 4E B6 A9 ? ? ? ? ? ? ? ? ..%.....N.. > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.721 > CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 handshake, length = 155 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.722 > CEST|ServerHello.java:866|Consuming ServerHello handshake message ( > "ServerHello": { > ? "server version" ? ? ?: "TLSv1.2", > ? "random" ? ? ? ? ? ? ?: "AB 76 F1 BA F3 B1 F0 DD 53 AC 5B 54 E9 E4 2E > F8 44 D2 5E B2 59 85 0D 16 79 EE A7 66 8A 84 69 2A", > ? "session id" ? ? ? ? ?: "0B 03 C8 E2 D2 A5 CD 3A 22 C5 85 17 06 64 A9 > 30 14 62 C0 AF AB 67 CE 63 50 41 50 7F 6B FD 4C 9F", > ? "cipher suite" ? ? ? ?: "TLS_AES_128_GCM_SHA256(0x1301)", > ? "compression methods" : "00", > ? "extensions" ? ? ? ? ?: [ > ? ? "supported_versions (43)": { > ? ? ? "selected version": [TLSv1.3] > ? ? }, > ? ? "key_share (51)": { > ? ? ? "server_share": { > ? ? ? ? "named group": secp256r1 > ? ? ? ? "key_exchange": { > ? ? ? ? ? 0000: 04 18 4A 46 BB 73 F4 6F ? 5D F0 3C 98 AD 70 7E 13 > ?..JF.s.o].<..p.. > ? ? ? ? ? 0010: D6 C0 E5 C0 28 5A D7 42 ? 78 95 68 E0 85 B7 06 CD > ?....(Z.Bx.h..... > ? ? ? ? ? 0020: DB 3C 35 DA AF E8 95 D6 ? A2 3C 77 CF 7E 8E C8 94 > ?.<5...... ? ? ? ? ? 0030: 50 BA CD 18 3F DA E3 A3 ? 25 E9 F3 C9 A9 7F 4E B6 > ?P...?...%.....N. > ? ? ? ? ? 0040: A9 > ? ? ? ? } > ? ? ? }, > ? ? } > ? ] > } > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 > CEST|SSLExtensions.java:167|Consumed extension: supported_versions > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 > CEST|ServerHello.java:962|Negotiated protocol version: TLSv1.3 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 > CEST|SSLExtensions.java:138|Ignore unsupported extension: server_name > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 > CEST|SSLExtensions.java:138|Ignore unsupported extension: > max_fragment_length > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 > CEST|SSLExtensions.java:138|Ignore unsupported extension: status_request > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 > CEST|SSLExtensions.java:138|Ignore unsupported extension: ec_point_formats > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 > CEST|SSLExtensions.java:138|Ignore unsupported extension: > application_layer_protocol_negotiation > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 > CEST|SSLExtensions.java:138|Ignore unsupported extension: status_request_v2 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 > CEST|SSLExtensions.java:138|Ignore unsupported extension: > extended_master_secret > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 > CEST|SSLExtensions.java:167|Consumed extension: supported_versions > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 > CEST|SSLExtensions.java:167|Consumed extension: key_share > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 > CEST|SSLExtensions.java:138|Ignore unsupported extension: renegotiation_info > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 > CEST|PreSharedKeyExtension.java:832|Handling pre_shared_key absence. > javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.725 > CEST|SSLSessionImpl.java:203|Session initialized: > ?Session(1537177914725|TLS_AES_128_GCM_SHA256) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 > CEST|SSLExtensions.java:182|Ignore unavailable extension: server_name > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 > CEST|SSLExtensions.java:182|Ignore unavailable extension: > max_fragment_length > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 > CEST|SSLExtensions.java:182|Ignore unavailable extension: status_request > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 > CEST|SSLExtensions.java:182|Ignore unavailable extension: ec_point_formats > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 > CEST|SSLExtensions.java:182|Ignore unavailable extension: > application_layer_protocol_negotiation > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 > CEST|SSLExtensions.java:182|Ignore unavailable extension: status_request_v2 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 > CEST|SSLExtensions.java:182|Ignore unavailable extension: > extended_master_secret > javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.726 > CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: > supported_versions > javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.726 > CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: > key_share > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 > CEST|SSLExtensions.java:182|Ignore unavailable extension: renegotiation_info > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 > CEST|SSLExtensions.java:182|Ignore unavailable extension: pre_shared_key > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.732 > CEST|SSLCipher.java:1824|KeyLimit read side: algorithm = > AES/GCM/NOPADDING:KEYUPDATE > countdown value = 137438953472 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.735 > CEST|SSLCipher.java:1978|KeyLimit write side: algorithm = > AES/GCM/NOPADDING:KEYUPDATE > countdown value = 137438953472 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.736 > CEST|SSLSocketOutputRecord.java:225|Raw write ( > ? 0000: 14 03 03 00 01 01 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...... > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.736 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: 14 03 03 00 01 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 > CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 change_cipher_spec, > length = 1 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: 01 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? . > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 > CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 change_cipher_spec, > length = 1 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 > CEST|ChangeCipherSpec.java:232|Consuming ChangeCipherSpec message > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: 17 03 03 00 27 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ....' > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 > CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, > length = 39 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: D5 B7 25 6F AF E9 D6 6F ? 7C 61 98 90 3F FE BA 9A ?..%o...o.a..?... > ? 0010: A8 5B 94 5E 3A 47 38 62 ? 36 90 9A 1D BE BF 87 18 ?.[.^:G8b6....... > ? 0020: 56 8C E3 AA CE AD AA ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? V...... > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 > CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, > length = 39 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.746 > CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( > ? 0000: 08 00 00 12 00 10 00 0A ? 00 0C 00 0A 00 1D 00 17 ?................ > ? 0010: 00 1E 00 19 00 18 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...... > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 > CEST|EncryptedExtensions.java:171|Consuming EncryptedExtensions > handshake message ( > "EncryptedExtensions": [ > ? "supported_groups (10)": { > ? ? "versions": [x25519, secp256r1, x448, secp521r1, secp384r1] > ? } > ] > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 > CEST|SSLExtensions.java:148|Ignore unavailable extension: server_name > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 > CEST|SSLExtensions.java:148|Ignore unavailable extension: > max_fragment_length > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 > CEST|SSLExtensions.java:167|Consumed extension: supported_groups > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 > CEST|SSLExtensions.java:182|Ignore unavailable extension: server_name > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 > CEST|SSLExtensions.java:182|Ignore unavailable extension: > max_fragment_length > javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.748 > CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: > supported_groups > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 > CEST|SSLExtensions.java:182|Ignore unavailable extension: > application_layer_protocol_negotiation > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: 17 03 03 00 42 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ....B > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 > CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, > length = 66 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: 63 F7 54 24 11 6A 91 1F ? 1F C5 70 9A 26 AD CE 98 ?c.T$.j....p.&... > ? 0010: D0 A9 7A 84 AF 39 7C A0 ? AD F6 6B B2 10 88 27 8B ?..z..9....k...'. > ? 0020: 79 E0 F4 5A 9F 68 AA F0 ? 56 D3 45 72 7C 7F 22 03 ?y..Z.h..V.Er..". > ? 0030: 0A 53 F6 24 68 CB 0B E1 ? 3B DD D4 78 B5 AC 1E D7 ?.S.$h...;..x.... > ? 0040: 03 FB ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.. > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 > CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, > length = 66 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 > CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( > ? 0000: 0D 00 00 2D 00 00 2A 00 ? 0D 00 26 00 24 04 03 05 ?...-..*...&.$... > ? 0010: 03 06 03 08 07 08 08 08 ? 09 08 0A 08 0B 08 04 08 ?................ > ? 0020: 05 08 06 04 01 05 01 06 ? 01 03 03 02 03 03 01 02 ?................ > ? 0030: 01 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? . > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 > CEST|CertificateRequest.java:864|Consuming CertificateRequest handshake > message ( > "CertificateRequest": { > ? "certificate_request_context": "", > ? "extensions": [ > ? ? "signature_algorithms (13)": { > ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, ed25519, ed448, > rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, > rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, > rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha224, > ecdsa_sha1, rsa_sha224, rsa_pkcs1_sha1] > ? ? } > ? ] > } > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 > CEST|SSLExtensions.java:167|Consumed extension: signature_algorithms > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 > CEST|SSLExtensions.java:148|Ignore unavailable extension: > signature_algorithms_cert > javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 > CEST|SignatureScheme.java:390|Unsupported signature scheme: ed25519 > javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 > CEST|SignatureScheme.java:390|Unsupported signature scheme: ed448 > javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 > CEST|SignatureScheme.java:390|Unsupported signature scheme: ecdsa_sha224 > javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 > CEST|SignatureScheme.java:390|Unsupported signature scheme: rsa_sha224 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 > CEST|SSLExtensions.java:199|Populated with extension: signature_algorithms > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 > CEST|SSLExtensions.java:182|Ignore unavailable extension: > signature_algorithms_cert > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: 17 03 03 03 20 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .... > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 > CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, > length = 800 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.753 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: FE BB B2 07 BA CE A6 32 ? AA 58 66 2F 6D 87 16 75 ?.......2.Xf/m..u > ? 0010: CF 71 13 53 FB 45 AE DC ? 84 F4 AA 33 08 08 DF B5 ?.q.S.E.....3.... > ? 0020: 97 C5 79 40 4A 28 F4 9D ? 0F 5A 86 4E C4 5F C7 2E ?..y at J(...Z.N._.. > ? 0030: AA AA 42 F7 8A FF 6B C1 ? 28 75 9B A3 25 F0 23 81 ?..B...k.(u..%.#. > ? 0040: 74 BB 9A EA A8 8D 89 BE ? E9 80 AE 31 C3 3A FC 35 ?t..........1.:.5 > ? 0050: E6 CA C5 77 BF C7 0E ED ? 64 26 DB 4E C3 3D F5 AD ?...w....d&.N.=.. > ? 0060: 5E EB A8 37 AA 81 EF 39 ? 24 84 C9 C4 C7 A2 D7 DB ?^..7...9$....... > ? 0070: 7F 82 01 7A 02 E7 23 A3 ? 6E C9 68 B8 E5 C3 9F 53 ?...z..#.n.h....S > ? 0080: 16 6E EF B0 54 D2 67 4C ? FF 22 E6 78 B1 A0 DB BE ?.n..T.gL.".x.... > ? 0090: 97 23 FC C8 D8 92 86 3D ? C6 6B E4 C1 AC EF B8 46 ?.#.....=.k.....F > ? 00A0: 75 3C 00 08 8B 34 5F 59 ? 05 49 25 97 BE A8 61 8E ?u<...4_Y.I%...a. > ? 00B0: B0 5F 25 91 7A FE 79 53 ? 7A C1 A7 E7 70 7B A5 53 ?._%.z.ySz...p..S > ? 00C0: 5A 63 8B 8E B9 92 2D B3 ? 80 DC AA 75 BE 0F 47 F3 ?Zc....-....u..G. > ? 00D0: E8 D9 0D 7D D9 C3 B6 00 ? AD 2A 43 CC 66 87 88 AF ?.........*C.f... > ? 00E0: 35 87 74 2F 87 2F 3C A6 ? FB 12 1A 9C 46 62 1C DC ?5.t/./<.....Fb.. > ? 00F0: 4E 4E DC 16 70 7E 08 74 ? FB F7 E6 5F 4D D9 20 F9 ?NN..p..t..._M. . > ? 0100: CA F3 91 45 D6 1A B3 BA ? FA 4E BD A4 74 9E 4C 78 ?...E.....N..t.Lx > ? 0110: 03 18 2C 70 35 42 68 F3 ? 9A 1D 24 3F A7 27 DF 29 ?..,p5Bh...$?.'.) > ? 0120: D5 58 7C CB 19 2F D1 DF ? 8A 6D B2 85 52 B5 78 19 ?.X.../...m..R.x. > ? 0130: EA 5C E2 7A 23 42 9E D7 ? A3 DC D0 DE D8 33 47 2B ?.\.z#B.......3G+ > ? 0140: 0C D8 6E 77 25 DB E6 12 ? B0 7A AD A5 C9 96 AC A9 ?..nw%....z...... > ? 0150: 1D CD 73 39 AC 6A 9F E2 ? 0A F7 17 F1 F0 FF 75 9C ?..s9.j........u. > ? 0160: B2 05 9E 7A F4 18 4F FC ? 9D 42 69 4C E0 3E A1 21 ?...z..O..BiL.>.! > ? 0170: DA 1F 71 07 59 C6 A2 F9 ? 0B 4F C0 CD A4 85 A8 DB ?..q.Y....O...... > ? 0180: 77 F6 87 5E 09 16 49 5C ? 2C B8 C0 7B 39 81 65 FD ?w..^..I\,...9.e. > ? 0190: 29 52 E2 C7 F5 C7 AD BC ? F6 A9 F9 6D D2 E9 A4 14 ?)R.........m.... > ? 01A0: C9 D3 79 2E D2 BA 10 4C ? BD 44 65 2B A8 7E F1 3A ?..y....L.De+...: > ? 01B0: F3 F6 11 53 38 17 10 12 ? B4 CD C5 AD 72 3B 84 A2 ?...S8.......r;.. > ? 01C0: 1B F9 D7 BF 34 00 5A FE ? F4 CE 09 0C EA F2 27 9A ?....4.Z.......'. > ? 01D0: BD DD 93 37 E2 DF 60 CC ? 8A F7 C6 4B 08 30 0D 78 ?...7..`....K.0.x > ? 01E0: 5C EB 49 34 DB 8B EB 55 ? 33 0C 82 03 07 FD 3D FC ?\.I4...U3.....=. > ? 01F0: 49 11 88 1C F6 67 7F 0B ? 48 AA EC 1B AF 04 46 CF ?I....g..H.....F. > ? 0200: 09 C5 8E B3 F8 92 C4 56 ? 3D 8F 0E 1D 9F D3 0C FE ?.......V=....... > ? 0210: 94 23 15 53 8E 1F 5E C4 ? FA 44 03 3B 1B B0 0A 2D ?.#.S..^..D.;...- > ? 0220: 71 D4 B5 AC 1F 52 D7 25 ? 9F A0 C8 4B 9B 32 B8 22 ?q....R.%...K.2." > ? 0230: 3F AF B3 19 16 8C 2A 5C ? B4 89 BF 82 DC 4D AF 22 ??.....*\.....M." > ? 0240: 2A 33 73 90 F3 C8 FF 2E ? C1 B3 83 D2 7A 29 4E 15 ?*3s.........z)N. > ? 0250: 5D 87 86 F6 94 EA B0 B4 ? A4 41 B9 C5 BA 89 B8 E9 ?]........A...... > ? 0260: 26 E7 96 BC 4D 8A FD 86 ? C7 C9 2A 96 75 C3 07 EF ?&...M.....*.u... > ? 0270: 5C 5A 4E 91 71 7D 1B A2 ? 12 88 C5 D0 D2 5E 79 E1 ?\ZN.q........^y. > ? 0280: 6C 65 35 5E 6C CC 56 47 ? FD F3 96 78 7A A0 08 7E ?le5^l.VG...xz... > ? 0290: DB 3C CC 10 76 15 37 46 ? 48 6B 2D 23 7B A3 44 5A ?.<..v.7FHk-#..DZ > ? 02A0: A4 46 B3 CE E2 15 BA 4C ? D2 93 16 57 1F BA 75 72 ?.F.....L...W..ur > ? 02B0: BF 8C 66 50 F2 A4 F6 05 ? 84 E5 47 12 30 BE 34 70 ?..fP......G.0.4p > ? 02C0: 4D 0F BD FE 54 E8 B1 CE ? B5 7F 6E 97 38 09 29 1F ?M...T.....n.8.). > ? 02D0: 41 2D 2E 9E 75 D8 77 0C ? 08 DB 5C B4 EE 3F FE E2 ?A-..u.w...\..?.. > ? 02E0: DC CF D0 ED C8 02 50 C4 ? EE B3 1D 8A 9E 9B EE 5E ?......P........^ > ? 02F0: 14 BA C2 5A B0 83 8E 5C ? E5 7B 69 2B 69 8C F1 AA ?...Z...\..i+i... > ? 0300: 2D D5 D1 3D 9D 42 1B B2 ? 50 5D BE 7E E4 11 D2 90 ?-..=.B..P]...... > ? 0310: 0B 54 71 7F D6 13 88 E2 ? FE 37 9F 70 B5 0B 57 79 ?.Tq......7.p..Wy > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.753 > CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, > length = 800 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.755 > CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( > ? 0000: 0B 00 03 0B 00 00 03 07 ? 00 03 02 30 82 02 FE 30 ?...........0...0 > ? 0010: 82 01 E6 A0 03 02 01 02 ? 02 08 20 C3 8D C4 49 66 ?.......... ...If > ? 0020: D0 02 30 0D 06 09 2A 86 ? 48 86 F7 0D 01 01 0B 05 ?..0...*.H....... > ? 0030: 00 30 3E 31 3C 30 3A 06 ? 03 55 04 03 0C 33 65 38 ?.0>1<0:..U...3e8 > ? 0040: 61 63 30 32 66 61 30 64 ? 36 35 61 38 34 32 31 39 ?ac02fa0d65a84219 > ? 0050: 30 31 36 30 34 35 64 62 ? 38 62 30 35 63 34 38 35 ?016045db8b05c485 > ? 0060: 62 34 65 63 64 66 2E 6E ? 65 74 74 79 2E 74 65 73 ?b4ecdf.netty.tes > ? 0070: 74 30 20 17 0D 31 33 30 ? 38 30 32 30 37 35 31 33 ?t0 ..13080207513 > ? 0080: 36 5A 18 0F 39 39 39 39 ? 31 32 33 31 32 33 35 39 ?6Z..999912312359 > ? 0090: 35 39 5A 30 3E 31 3C 30 ? 3A 06 03 55 04 03 0C 33 ?59Z0>1<0:..U...3 > ? 00A0: 65 38 61 63 30 32 66 61 ? 30 64 36 35 61 38 34 32 ?e8ac02fa0d65a842 > ? 00B0: 31 39 30 31 36 30 34 35 ? 64 62 38 62 30 35 63 34 ?19016045db8b05c4 > ? 00C0: 38 35 62 34 65 63 64 66 ? 2E 6E 65 74 74 79 2E 74 ?85b4ecdf.netty.t > ? 00D0: 65 73 74 30 82 01 22 30 ? 0D 06 09 2A 86 48 86 F7 ?est0.."0...*.H.. > ? 00E0: 0D 01 01 01 05 00 03 82 ? 01 0F 00 30 82 01 0A 02 ?...........0.... > ? 00F0: 82 01 01 00 DB F8 70 4E ? DC 2D 14 44 12 AF 0D 48 ?......pN.-.D...H > ? 0100: 09 1D B8 48 94 1C 9E F1 ? 7F DC 6C D1 F7 94 3A B7 ?...H......l...:. > ? 0110: 5C E3 85 07 3E CB E1 76 ? 4A 2C 32 17 4B E1 5E 42 ?\...>..vJ,2.K.^B > ? 0120: A4 80 50 CA 36 A2 D9 94 ? F9 59 23 D0 AA 2B B2 13 ?..P.6....Y#..+.. > ? 0130: 23 6D 45 DF 13 52 A4 4E ? 28 D3 30 99 5A 81 AD 8C ?#mE..R.N(.0.Z... > ? 0140: DB 15 55 B7 6D 5F 44 89 ? 09 35 66 C8 2F 47 56 14 ?..U.m_D..5f./GV. > ? 0150: B5 B2 46 AE CE 5D DC A0 ? C8 59 08 89 6F 5B DB F2 ?..F..]...Y..o[.. > ? 0160: D8 69 E3 C1 80 44 F6 DA ? 46 ED 1D 20 80 12 3F 81 ?.i...D..F.. ..?. > ? 0170: 95 27 F6 EB 9F B5 AC DC ? 72 01 70 46 18 67 1C 08 ?.'......r.pF.g.. > ? 0180: AC C4 6D CA 80 48 12 87 ? 3A 05 69 EA 92 EA 95 00 ?..m..H..:.i..... > ? 0190: 1F B9 2C BA 83 F3 B3 1B ? 37 1E B3 7C D7 46 B1 AE ?..,.....7....F.. > ? 01A0: D4 DD E9 04 8C C0 23 00 ? 96 E3 6F 67 E7 66 65 61 ?......#...og.fea > ? 01B0: F6 11 D2 7A FE 44 42 83 ? 9D 1A CF 20 80 EC 58 04 ?...z.DB.... ..X. > ? 01C0: A6 10 78 41 7B 34 C3 FA ? FD 2A 08 94 72 2F 3D AE ?..xA.4...*..r/=. > ? 01D0: B0 58 16 63 EE DA 81 42 ? 44 DB 21 C7 23 69 93 BB ?.X.c...BD.!.#i.. > ? 01E0: 64 40 16 78 01 8A 52 57 ? 94 C0 AD 57 04 F4 C4 6B ?d at .x..RW...W...k > ? 01F0: 90 C6 46 C7 02 03 01 00 ? 01 30 0D 06 09 2A 86 48 ?..F......0...*.H > ? 0200: 86 F7 0D 01 01 0B 05 00 ? 03 82 01 01 00 4B FC 37 ?.............K.7 > ? 0210: B5 E6 F2 A6 98 D8 58 2B ? 39 CE 8F 6B 51 93 80 0F ?......X+9..kQ... > ? 0220: 80 39 BD DA 53 7D D3 1B ? 00 11 F3 A7 FE 9C B7 FA ?.9..S........... > ? 0230: 05 23 DA A2 17 10 7C E7 ? 89 89 DE C5 90 5B 98 22 ?.#...........[." > ? 0240: 7B 97 97 EA 2A B3 E4 6A ? 33 F8 FC 47 41 39 06 E1 ?....*..j3..GA9.. > ? 0250: 98 63 6C 0E 2A 92 FF 3D ? B1 62 D7 27 FF 2B 2B DF ?.cl.*..=.b.'.++. > ? 0260: B7 B2 95 87 C7 B5 21 45 ? 1E 73 F8 B5 0D D6 13 0C ?......!E.s...... > ? 0270: 1D 25 35 6B D7 5F 18 DF ? 30 A1 8B 72 DD C6 31 B1 ?.%5k._..0..r..1. > ? 0280: 07 2A F2 DF 1F 1E 36 23 ? 0C FF F9 FB DA E8 B5 2B ?.*....6#.......+ > ? 0290: 3B 8B B6 4C 37 EF D3 27 ? 07 B9 1E D4 64 4B 82 D4 ?;..L7..'....dK.. > ? 02A0: 32 78 C6 D1 61 6E 9A BF ? 41 10 23 0B 27 CD C7 77 ?2x..an..A.#.'..w > ? 02B0: 03 73 B2 F6 12 D2 56 9C ? 29 A2 BD 31 40 F6 5F 0C ?.s....V.)..1 at ._. > ? 02C0: 17 56 4F 30 34 95 77 87 ? 9C 43 B0 74 C5 92 05 43 ?.VO04.w..C.t...C > ? 02D0: 97 12 48 5B 7B 58 66 89 ? 0A C1 8C CD 89 14 E0 5A ?..H[.Xf........Z > ? 02E0: 78 23 29 10 71 6C 5D 94 ? D5 FB C0 96 51 C1 0D 93 ?x#).ql].....Q... > ? 02F0: 64 91 45 82 5A 53 88 56 ? 5D 7A AE 88 E8 07 7D 02 ?d.E.ZS.V]z...... > ? 0300: 7D 44 9D CA 73 E5 6F 14 ? 27 8B 6F 86 6C 00 00 ? ? .D..s.o.'.o.l.. > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 > CEST|CertificateMessage.java:1148|Consuming server Certificate handshake > message ( > "Certificate": { > ? "certificate_request_context": "", > ? "certificate_list": [ > ? { > ? ? "certificate" : { > ? ? ? "version" ? ? ? ? ? ?: "v3", > ? ? ? "serial number" ? ? ?: "20 C3 8D C4 49 66 D0 02", > ? ? ? "signature algorithm": "SHA256withRSA", > ? ? ? "issuer" ? ? ? ? ? ? : > "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", > ? ? ? "not before" ? ? ? ? : "2013-08-02 09:51:36.000 CEST", > ? ? ? "not ?after" ? ? ? ? : "10000-01-01 24:59:59.000 CET", > ? ? ? "subject" ? ? ? ? ? ?: > "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", > ? ? ? "subject public key" : "RSA"} > ? ? "extensions": { > ? ? ? > ? ? } > ? }, > ] > } > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 > CEST|SSLExtensions.java:148|Ignore unavailable extension: status_request > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: 17 03 03 01 19 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 > CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, > length = 281 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: DE 53 C0 74 78 C3 82 0D ? E8 46 C0 0A F4 56 6E 6B ?.S.tx....F...Vnk > ? 0010: B5 39 77 41 20 21 BA 07 ? 99 2B BF 8D 0A 41 C9 B8 ?.9wA !...+...A.. > ? 0020: BC 0F C1 8E C5 76 36 F0 ? 7A B6 9A F8 38 4D 4D 4D ?.....v6.z...8MMM > ? 0030: 70 33 BE 8F 8C ED BE BC ? 60 49 B8 41 65 E9 04 D9 ?p3......`I.Ae... > ? 0040: 45 43 AA 41 6D F7 67 7B ? 03 6D FF E0 4D 76 53 CE ?EC.Am.g..m..MvS. > ? 0050: C1 73 3E 1C CD 87 40 B7 ? 25 56 54 0C 3E CA D7 1D ?.s>... at .%VT.>... > ? 0060: 45 80 41 E8 36 B7 FC 57 ? 38 BB 21 EB E7 EA 19 A1 ?E.A.6..W8.!..... > ? 0070: 39 25 B0 44 8B FD 30 87 ? 86 7A 47 03 C1 02 AC FD ?9%.D..0..zG..... > ? 0080: 67 89 4B 27 34 04 20 AE ? 91 65 7C 8C 4A 58 C5 77 ?g.K'4. ..e..JX.w > ? 0090: 46 2E DD A8 23 CA 5C 28 ? 49 25 23 3D 8A 93 B9 10 ?F...#.\(I%#=.... > ? 00A0: 24 0D DE DC 98 AC AA B0 ? CB 51 80 D7 F8 E7 20 23 ?$........Q.... # > ? 00B0: 41 64 A6 44 93 A7 E1 A7 ? 91 62 4F 3A 73 F6 24 04 ?Ad.D.....bO:s.$. > ? 00C0: C3 E8 25 65 37 D9 1B 7A ? 65 AE DE C6 29 67 2E C1 ?..%e7..ze...)g.. > ? 00D0: F7 4C 5C 18 D7 14 98 90 ? ED 9D AD F5 98 A7 FD 93 ?.L\............. > ? 00E0: 53 F4 B5 90 C9 CB FD 54 ? 8E 5F 53 23 E3 73 94 BD ?S......T._S#.s.. > ? 00F0: A4 07 B7 E3 C7 83 7B 17 ? CF 51 4A 9E 9C 05 3C 51 ?.........QJ... ? 0100: 4D C7 A1 7A D6 4D A6 58 ? E5 3A D4 12 B9 B9 46 9C ?M..z.M.X.:....F. > ? 0110: AB 1D C5 6B F9 6A 85 CB ? E2 ? ? ? ? ? ? ? ? ? ? ? ...k.j... > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.758 > CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, > length = 281 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.758 > CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( > ? 0000: 0F 00 01 04 08 04 01 00 ? 30 11 28 CE 64 4E 08 BA ?........0.(.dN.. > ? 0010: A1 BE 46 D9 3D 14 29 1A ? EB 5A B0 1A 09 B7 11 A5 ?..F.=.)..Z...... > ? 0020: 9A F4 22 17 87 5F 87 D5 ? 63 04 8E 27 EC 3A F8 52 ?..".._..c..'.:.R > ? 0030: 36 F4 2F CF 47 D2 5C CE ? 0A F0 29 EF 63 03 B1 64 ?6./.G.\...).c..d > ? 0040: B8 45 6E 39 71 E3 BD 25 ? 95 31 25 85 4C FB C6 AD ?.En9q..%.1%.L... > ? 0050: C8 43 96 4E FA AD B9 98 ? 17 43 61 FB 9B 87 CE 94 ?.C.N.....Ca..... > ? 0060: CF 74 6F 3B AA 6A C8 80 ? 8F C7 C8 05 E4 EF 42 6C ?.to;.j........Bl > ? 0070: D4 01 9E 25 5E 34 E8 2D ? 93 BD BB 05 49 2F 9D B6 ?...%^4.-....I/.. > ? 0080: F6 91 2F D1 E5 CB 1B 9E ? F6 DB 18 32 1D F5 66 A0 ?../........2..f. > ? 0090: 63 5D 25 01 B6 F6 1B 41 ? 07 3E 90 61 37 49 38 17 ?c]%....A.>.a7I8. > ? 00A0: B0 15 C9 AD 0C 7A 05 8D ? B4 48 BB 03 2D DE 5E 49 ?.....z...H..-.^I > ? 00B0: 99 8B 74 53 5F 73 9B 18 ? FD 95 2A C3 F9 A3 8B 59 ?..tS_s....*....Y > ? 00C0: 1A ED 2C 55 C2 22 10 1E ? 7A FC 38 0A 99 FC 30 89 ?..,U."..z.8...0. > ? 00D0: 03 89 1C CD A7 DE E5 35 ? FD E9 E0 05 96 09 AF DD ?.......5........ > ? 00E0: 51 A3 7F C7 16 C5 96 8D ? CA CC 53 50 DC C5 C6 BA ?Q.........SP.... > ? 00F0: D6 05 28 18 BA 99 F8 0F ? 7F 24 9F D5 6B 93 DE BC ?..(......$..k... > ? 0100: EB 23 85 D9 D3 41 56 44 ? ? ? ? ? ? ? ? ? ? ? ? ? ?.#...AVD > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 > CEST|CertificateVerify.java:1128|Consuming CertificateVerify handshake > message ( > "CertificateVerify": { > ? "signature algorithm": rsa_pss_rsae_sha256 > ? "signature": { > ? ? 0000: 30 11 28 CE 64 4E 08 BA ? A1 BE 46 D9 3D 14 29 1A > ?0.(.dN....F.=.). > ? ? 0010: EB 5A B0 1A 09 B7 11 A5 ? 9A F4 22 17 87 5F 87 D5 > ?.Z........".._.. > ? ? 0020: 63 04 8E 27 EC 3A F8 52 ? 36 F4 2F CF 47 D2 5C CE > ?c..'.:.R6./.G.\. > ? ? 0030: 0A F0 29 EF 63 03 B1 64 ? B8 45 6E 39 71 E3 BD 25 > ?..).c..d.En9q..% > ? ? 0040: 95 31 25 85 4C FB C6 AD ? C8 43 96 4E FA AD B9 98 > ?.1%.L....C.N.... > ? ? 0050: 17 43 61 FB 9B 87 CE 94 ? CF 74 6F 3B AA 6A C8 80 > ?.Ca......to;.j.. > ? ? 0060: 8F C7 C8 05 E4 EF 42 6C ? D4 01 9E 25 5E 34 E8 2D > ?......Bl...%^4.- > ? ? 0070: 93 BD BB 05 49 2F 9D B6 ? F6 91 2F D1 E5 CB 1B 9E > ?....I/..../..... > ? ? 0080: F6 DB 18 32 1D F5 66 A0 ? 63 5D 25 01 B6 F6 1B 41 > ?...2..f.c]%....A > ? ? 0090: 07 3E 90 61 37 49 38 17 ? B0 15 C9 AD 0C 7A 05 8D > ?.>.a7I8......z.. > ? ? 00A0: B4 48 BB 03 2D DE 5E 49 ? 99 8B 74 53 5F 73 9B 18 > ?.H..-.^I..tS_s.. > ? ? 00B0: FD 95 2A C3 F9 A3 8B 59 ? 1A ED 2C 55 C2 22 10 1E > ?..*....Y..,U.".. > ? ? 00C0: 7A FC 38 0A 99 FC 30 89 ? 03 89 1C CD A7 DE E5 35 > ?z.8...0........5 > ? ? 00D0: FD E9 E0 05 96 09 AF DD ? 51 A3 7F C7 16 C5 96 8D > ?........Q....... > ? ? 00E0: CA CC 53 50 DC C5 C6 BA ? D6 05 28 18 BA 99 F8 0F > ?..SP......(..... > ? ? 00F0: 7F 24 9F D5 6B 93 DE BC ? EB 23 85 D9 D3 41 56 44 > ?.$..k....#...AVD > ? } > } > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: 17 03 03 00 35 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ....5 > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 > CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, > length = 53 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: F6 A7 CD EA 89 34 B2 DB ? C4 28 91 18 C9 03 98 B6 ?.....4...(...... > ? 0010: DF 49 4E F5 2E 23 32 90 ? F8 13 C7 AE 18 E3 E5 64 ?.IN..#2........d > ? 0020: D9 E4 A5 B0 5C F0 4A 3E ? AF EC 28 8D 09 78 AB EE ?....\.J>..(..x.. > ? 0030: 38 1B 9E 45 04 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 8..E. > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 > CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, > length = 53 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 > CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( > ? 0000: 14 00 00 20 F2 93 6B 71 ? 2B FA F3 1B BF 68 98 D1 ?... ..kq+....h.. > ? 0010: AA 5E B0 AF 5D 3B A6 B5 ? 8F 79 BA 64 E8 A1 34 5F ?.^..];...y.d..4_ > ? 0020: D4 2B ED 8C ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.+.. > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.764 > CEST|Finished.java:860|Consuming server Finished handshake message ( > "Finished": { > ? "verify data": { > ? ? 0000: F2 93 6B 71 2B FA F3 1B ? BF 68 98 D1 AA 5E B0 AF > ?..kq+....h...^.. > ? ? 0010: 5D 3B A6 B5 8F 79 BA 64 ? E8 A1 34 5F D4 2B ED 8C > ?];...y.d..4_.+.. > ? }'} > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.765 > CEST|SSLCipher.java:1824|KeyLimit read side: algorithm = > AES/GCM/NOPADDING:KEYUPDATE > countdown value = 137438953472 > javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.765 > CEST|CertificateMessage.java:1015|No signature_algorithms(_cert) in > ClientHello > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 > CEST|CertificateMessage.java:1081|No available client authentication scheme > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 > CEST|CertificateMessage.java:1116|Produced client Certificate message ( > "Certificate": { > ? "certificate_request_context": "", > ? "certificate_list": [ > ] > } > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 > CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 8 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 > CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( > ? 0000: 0B 00 00 04 00 00 00 00 ? 16 00 00 00 00 00 00 00 ?................ > ? 0010: 00 00 00 00 00 00 00 00 ? 00 ? ? ? ? ? ? ? ? ? ? ? ......... > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 > CEST|SSLSocketOutputRecord.java:255|Raw write ( > ? 0000: 17 03 03 00 29 E5 32 E4 ? 5B 13 E7 D4 A1 78 FE 38 ?....).2.[....x.8 > ? 0010: 26 22 CB C1 04 88 3A 3A ? 2D D4 A1 31 5A 78 65 50 ?&"....::-..1ZxeP > ? 0020: 51 45 67 FA 9F 55 35 E1 ? 49 C5 3B 3B 91 B1 ? ? ? ?QEg..U5.I.;;.. > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 > CEST|CertificateVerify.java:1059|No X.509 credentials negotiated for > CertificateVerify > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 > CEST|Finished.java:658|Produced client Finished handshake message ( > "Finished": { > ? "verify data": { > ? ? 0000: D8 47 0B A0 DF BB BF 49 ? E4 55 B9 D3 FB 3D B0 DD > ?.G.....I.U...=.. > ? ? 0010: 57 1E 08 28 20 7E E1 0B ? E3 EB 12 10 09 76 D1 8F ?W..( > ........v.. > ? }'} > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 > CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 36 > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 > CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( > ? 0000: 14 00 00 20 D8 47 0B A0 ? DF BB BF 49 E4 55 B9 D3 ?... .G.....I.U.. > ? 0010: FB 3D B0 DD 57 1E 08 28 ? 20 7E E1 0B E3 EB 12 10 ?.=..W..( ....... > ? 0020: 09 76 D1 8F 16 00 00 00 ? 00 00 00 00 00 00 00 00 ?.v.............. > ? 0030: 00 00 00 00 00 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 > CEST|SSLSocketOutputRecord.java:255|Raw write ( > ? 0000: 17 03 03 00 45 0F 4D 84 ? 52 28 59 96 92 52 D1 AB ?....E.M.R(Y..R.. > ? 0010: DB 86 64 25 31 FF 9D 8E ? D7 84 63 B5 03 E2 9E 06 ?..d%1.....c..... > ? 0020: 3C 8C C2 22 F3 7A EE 55 ? AD 8C F5 5C F6 04 9A E2 ?<..".z.U...\.... > ? 0030: 6D BA E4 C4 9F 97 C3 DA ? BC D3 CB 8C 2C 9E BF FD ?m...........,... > ? 0040: A3 9F C1 A2 79 51 75 B7 ? AE B6 ? ? ? ? ? ? ? ? ? ?....yQu... > ) > javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.770 > CEST|SSLCipher.java:1978|KeyLimit write side: algorithm = > AES/GCM/NOPADDING:KEYUPDATE > countdown value = 137438953472 > javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: 17 03 03 00 13 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... > ) > javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 > CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, > length = 19 > javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 > CEST|SSLSocketInputRecord.java:458|Raw read ( > ? 0000: 4F 0D C7 65 8B 24 B4 92 ? A2 26 31 8C 81 AF 8F F7 ?O..e.$...&1..... > ? 0010: AC C3 B3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ... > ) > javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 > CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, > length = 19 > javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.773 > CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( > ? 0000: 02 74 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.t > ) > javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.774 > CEST|Alert.java:232|Received alert message ( > "Alert": { > ? "level" ? ? ?: "fatal", > ? "description": "certificate_required" > } > ) > javax.net.ssl|ERROR|0C|Thread-0|2018-09-17 11:51:54.774 > CEST|TransportContext.java:313|Fatal (CERTIFICATE_REQUIRED): Received > fatal alert: certificate_required ( > "throwable" : { > ? javax.net.ssl.SSLHandshakeException: Received fatal alert: > certificate_required > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) > at > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) > at > java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) > at > java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) > at > java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) > at ReproducerClient$1.run(ReproducerClient.java:33) > at java.base/java.lang.Thread.run(Thread.java:834)} > > ) > javax.net.ssl|ALL|0C|Thread-0|2018-09-17 11:51:54.775 > CEST|SSLSessionImpl.java:753|Invalidated session: > ?Session(1537177914725|TLS_AES_128_GCM_SHA256) > javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 > CEST|SSLSocketImpl.java:1361|close the underlying socket > javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 > CEST|SSLSocketImpl.java:1380|close the SSL connection (initiative) > javax.net.ssl|WARNING|0C|Thread-0|2018-09-17 11:51:54.777 > CEST|SSLSocketImpl.java:1289|handling exception ( > "throwable" : { > ? javax.net.ssl.SSLHandshakeException: Received fatal alert: > certificate_required > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) > at > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) > at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) > at > java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) > at > java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) > at > java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) > at ReproducerClient$1.run(ReproducerClient.java:33) > at java.base/java.lang.Thread.run(Thread.java:834)} > > ) > > > Bye > Norman > >> On 16. Sep 2018, at 15:54, Norman Maurer > > wrote: >> >> Will do, ?but not before tomorrow (I will also share the client side >> code). That said there is nothing special about the keymanager. >> Like I said before it sends the cert when using ?want client with?, it >> just seems it may be too late. >> >> >> Bye >> Norman >> >>> Am 15.09.2018 um 08:26 schrieb Bradford Wetmore >>> >: >>> >>> 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)) >>>>>>> 0000 - 16 03 03 01 60 ???????????????????????????????????....` >>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160)) >>>>>>> 0000 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 >>>>>>> ??...\..".... at 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..o....K...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)) >>>>>>> 0000 - 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|J....n....] >>>>>>> 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..o....K.. >>>>>>> 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 >>>>>>> ??MT....B5S[...... >>>>>>> 00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65 >>>>>>> ??.(.m...8.wrs%&.e >>>>>>> 00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96 >>>>>>> ??X........P...... >>>>>>> 0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9 >>>>>>> ??.;<..AX...:(..a. >>>>>>> 0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5 >>>>>>> ??.h...f.[..... .. >>>>>>> 0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb >>>>>>> ??.RD...c=........ >>>>>>> 0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6 >>>>>>> ??.*O[J.wx.u. .... >>>>>>> 0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee >>>>>>> ??...VV._.e.~n=.f. >>>>>>> 0150 - 10 4c f7 6d 9b 73 86 14-7a 81 f8 b1 27 af 08 ee >>>>>>> ??.L.m.s..z...'... >>>>>>> 0160 - ce 26 90 34 73 3d b7 45-8d 85 29 a8 65 19 e7 02 >>>>>>> ??.&.4s=.E..).e... >>>>>>> 0170 - e5 55 4a 27 f1 b1 6a a4-11 cc 6c af 78 6d 22 5c >>>>>>> ??.UJ'..j...l.xm"\ >>>>>>> 0180 - 33 73 e3 ad 7f 8d 1b d3-75 95 66 64 2d 0e f1 3e >>>>>>> ??3s......u.fd-..> >>>>>>> 0190 - c2 30 df a1 7e ce a3 50-c3 4e 68 f6 36 b3 4e 45 >>>>>>> ??.0..~..P.Nh.6.NE >>>>>>> 01a0 - 9c ac e9 f2 0d 7c e3 73-6a 40 ab 6e 6e f9 d8 20 >>>>>>> ??.....|.sj at .nn.. >>>>>>> 01b0 - 9c f3 04 32 cd 1d df 18-e5 4d e3 e8 b1 38 59 f8 >>>>>>> ??...2.....M...8Y. >>>>>>> 01c0 - 28 67 2e ca af a2 8b 88-ce ca 48 a6 07 2b a6 9a >>>>>>> ??(g........H..+.. >>>>>>> 01d0 - 0e 88 5b d7 0b d9 31 77-97 8d 6c 2b f5 60 24 61 >>>>>>> ??..[...1w..l+.`$a >>>>>>> 01e0 - a8 5c 47 5d 7c 66 f0 9b-1f e4 76 93 38 f6 78 3e >>>>>>> ??.\G]|f....v.8.x> >>>>>>> 01f0 - 69 29 72 f9 d9 4b cb 05-03 e4 f2 d6 24 e1 91 ee >>>>>>> ??i)r..K......$... >>>>>>> 0200 - 85 37 d7 7b c3 5c 35 90-08 cd b1 cc 76 11 fc 00 >>>>>>> ??.7.{.\5.....v... >>>>>>> 0210 - 12 7e 89 7b 70 e6 ca fe-0b 26 b6 bb ac fe 4b 9f >>>>>>> ??.~.{p....&....K. >>>>>>> 0220 - ec cf 41 69 42 3a 3e 41-f9 b0 c0 93 5b 70 1f c7 >>>>>>> ??..AiB:>A....[p.. >>>>>>> 0230 - 11 00 3d ec 66 5a 1a ca-31 89 22 27 02 dd a0 cb >>>>>>> ??..=.fZ..1."'.... >>>>>>> 0240 - 39 14 25 ee 30 44 e8 62-97 bf 8e 16 63 40 c4 11 >>>>>>> ??9.%.0D.b....c at .. >>>>>>> 0250 - a6 d9 32 b1 3c 86 35 bb-9f f1 4d 71 9f a5 4f 78 >>>>>>> ??..2.<.5...Mq..Ox >>>>>>> 0260 - 0a e8 96 dd 4d 10 c3 48-f2 db 67 57 2d cd dc 23 >>>>>>> ??....M..H..gW-..# >>>>>>> 0270 - 3a 8d 6a 61 47 20 ff c8-33 cd e9 f7 47 4c 68 4f ??:.jaG >>>>>>> ..3...GLhO >>>>>>> 0280 - 19 2f 8b e3 b1 90 ac 66-a7 cf 5c e6 d2 05 21 25 >>>>>>> ??./.....f..\...!% >>>>>>> 0290 - d2 d8 f0 43 8c 55 01 ef-d6 8f c0 27 87 0d 21 d5 >>>>>>> ??...C.U.....'..!. >>>>>>> 02a0 - 2b 2b 6f db e8 85 ea cd-6e 9c 5d 56 d5 31 c1 f2 >>>>>>> ??++o.....n.]V.1.. >>>>>>> 02b0 - 97 2f 5a 83 7a 2b 71 03-65 e0 b6 4a 56 37 de e1 >>>>>>> ??./Z.z+q.e..JV7.. >>>>>>> 02c0 - 80 3a c4 cc 5a ac 3b 9a-7a bf f7 6b fe a8 69 e9 >>>>>>> ??.:..Z.;.z..k..i. >>>>>>> 02d0 - 58 09 59 bd 46 bd d2 a3-bc ad 1c 10 53 c8 29 7b >>>>>>> ??X.Y.F.......S.){ >>>>>>> 02e0 - be 63 00 d6 e5 a8 d6 ab-b2 bc 8b e1 2c 0e 24 2a >>>>>>> ??.c..........,.$* >>>>>>> 02f0 - c2 31 2d d8 6e 1f 19 93-d7 54 e1 1e 28 ce 72 83 >>>>>>> ??.1-.n....T..(.r. >>>>>>> 0300 - ff 05 18 f2 fc e9 0c b3-0c 1b d5 96 c2 d8 fc 76 >>>>>>> ??...............v >>>>>>> 0310 - 37 a9 5a ef 8e e9 b6 71-21 f3 bd c1 85 23 85 22 >>>>>>> ??7.Z....q!....#." >>>>>>> 0320 - 3d c4 1c c9 31 8b 7e 00-8f 8e b4 9f 05 d4 80 6b >>>>>>> ??=...1.~........k >>>>>>> 0330 - 98 4c a8 82 68 ff 1a a5-28 e2 9b 03 a1 a7 b1 00 >>>>>>> ??.L..h...(....... >>>>>>> 0340 - 02 2b 2d e2 e1 87 8c e8-0a fb 0b 79 54 ca 3d d5 >>>>>>> ??.+-........yT.=. >>>>>>> 0350 - 6a dd b7 b7 87 42 2b 47-49 da e9 0a 82 0a c9 8f >>>>>>> ??j....B+GI....... >>>>>>> 0360 - 57 f7 1e 03 ca 8d 16 bc-21 3a 6a ee b9 b8 fa f0 >>>>>>> ??W.......!:j..... >>>>>>> 0370 - d9 18 35 9f 35 ac d8 6e-9a 8a 0d 56 10 1e 1f 5a >>>>>>> ??..5.5..n...V...Z >>>>>>> 0380 - ba ec e4 fe 1a 92 b4 31-35 43 1d 99 b9 12 fa ff >>>>>>> ??.......15C...... >>>>>>> 0390 - 99 2b 88 e0 58 ec 9c dc-8f 67 ef 2a c2 e2 64 5d >>>>>>> ??.+..X....g.*..d] >>>>>>> 03a0 - 66 76 1c d0 aa 00 30 59-b1 f5 b1 55 9f ad 60 e9 >>>>>>> ??fv....0Y...U..`. >>>>>>> 03b0 - 3d 03 1e d0 8b 4d bf 74-ac bc bb 1c 83 14 c5 e0 >>>>>>> ??=....M.t........ >>>>>>> 03c0 - f4 fc 70 9e f4 22 a0 78-04 fe c8 b1 17 65 f6 94 >>>>>>> ??..p..".x.....e.. >>>>>>> 03d0 - 47 82 50 4a b6 32 74 ae-5b 38 5a 2e d9 b0 6a 45 >>>>>>> ??G.PJ.2t.[8Z...jE >>>>>>> 03e0 - 74 e8 f0 22 fe d3 b0 11-c3 fd 72 4f da 77 7a ba >>>>>>> ??t.."......rO.wz. >>>>>>> 03f0 - 26 3e 61 0c 63 21 17 a6-b2 13 6e 71 5c f2 0d ad >>>>>>> ??&>a.c!....nq\... >>>>>>> 0400 - f2 d1 19 71 51 9e a4 1b-b0 30 24 e0 71 7d 87 80 >>>>>>> ??...qQ....0$.q}.. >>>>>>> 0410 - a9 5a e9 bc db e4 4f 50-4d a1 bc bc 2c 4b 66 98 >>>>>>> ??.Z....OPM...,Kf. >>>>>>> 0420 - d4 e4 b0 76 0f d2 db a5-a5 39 9e f2 5b ea 34 c1 >>>>>>> ??...v.....9..[.4. >>>>>>> 0430 - 62 ab 47 51 3b 37 17 45-54 31 18 f3 f1 ca 17 03 >>>>>>> ??b.GQ;7.ET1...... >>>>>>> 0440 - 03 01 19 dd 50 50 f5 0c-f2 c9 3c b4 8f 63 cc 4a >>>>>>> ??....PP....<..c.J >>>>>>> 0450 - a7 50 c9 91 9b 79 9a 2a-5c 47 d3 77 f6 56 69 90 >>>>>>> ??.P...y.*\G.w.Vi. >>>>>>> 0460 - 98 cd ff bd c1 2a 49 fc-0d d4 7e cc 7e 44 af c4 >>>>>>> ??.....*I...~.~D.. >>>>>>> 0470 - 61 47 e0 c1 76 b1 8c 2e-df 7e d0 82 e1 89 1f 04 >>>>>>> ??aG..v....~...... >>>>>>> 0480 - ae 64 bd 71 4d ae 1c 3c-e3 d3 39 5d 61 2a ea 70 >>>>>>> ??.d.qM..<..9]a*.p >>>>>>> 0490 - 8c 31 6d a0 b1 72 a8 7a-5c 9c 11 08 b8 4d a5 c4 >>>>>>> ??.1m..r.z\....M.. >>>>>>> 04a0 - ad 1b 38 4a 6a 02 28 d4-d1 0f c8 9f 0b b3 02 18 >>>>>>> ??..8Jj.(......... >>>>>>> 04b0 - 82 2b bd 46 82 04 64 f0-41 b2 da f5 cd 9c f7 f3 >>>>>>> ??.+.F..d.A....... >>>>>>> 04c0 - 73 30 58 ca 12 ec ea 90-85 1c 75 09 0a 70 b8 80 >>>>>>> ??s0X.......u..p.. >>>>>>> 04d0 - 3d 02 17 3e 9b 83 04 b5-dd 9e e6 18 17 65 83 a5 >>>>>>> ??=..>.........e.. >>>>>>> 04e0 - 59 7d 4b 98 da bd 8b aa-d6 aa c5 1c 7d 87 56 e3 >>>>>>> ??Y}K.........}.V. >>>>>>> 04f0 - 74 d8 e9 7b eb b3 3d f7-7c 3c 0a e9 a8 2e 04 0d >>>>>>> ??t..{..=.|<...... >>>>>>> 0500 - 6a e7 83 e0 ec 99 43 6a-8b 1c 73 59 7a c8 cd 6e >>>>>>> ??j.....Cj..sYz..n >>>>>>> 0510 - 4a 14 73 ff 9a fb 71 94-d5 50 a9 d9 e0 dd 02 4c >>>>>>> ??J.s...q..P.....L >>>>>>> 0520 - 2b 67 9e da 9e fa 2d 67-49 df 13 10 ed 35 3e 73 >>>>>>> ??+g....-gI....5>s >>>>>>> 0530 - 07 20 17 fb 0b ef f6 d0-b7 68 1c 65 21 a6 e3 3b ??. >>>>>>> .......h.e!..; >>>>>>> 0540 - bf 7b 84 cd 9e f5 76 2a-0d 4f b8 c3 c8 15 08 e9 >>>>>>> ??.{....v*.O...... >>>>>>> 0550 - 0f 3c 50 49 12 97 a8 d7-f1 a3 16 da 17 03 03 00 >>>>>>> ??.>>>>>> 0560 - 35 22 dd a2 9d 25 98 2c-35 b8 00 29 fa a1 dd ba >>>>>>> ??5"...%.,5..).... >>>>>>> 0570 - 72 b9 fe e5 85 85 f0 f1-3b 4e f5 7c 58 c8 2a da >>>>>>> ??r.......;N.|X.*. >>>>>>> 0580 - d2 75 94 3b c1 7a 7c 7e-db 5b fe 8a 2d 3f 8c 9a >>>>>>> ??.u.;.z|~.[..-?.. >>>>>>> 0590 - 6e 79 ab 2b ff 1a ????????????????????????????????ny.+.. >>>>>>> SSL_accept:SSLv3/TLS write finished >>>>>>> SSL_accept:TLSv1.3 early data >>>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>>> 0000 - 14 03 03 00 01 ???????????????????????????????????..... >>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (1 bytes => 1 (0x1)) >>>>>>> 0000 - 01 ???????????????????????????????????????????????. >>>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>>> 0000 - 17 03 03 00 3d ???????????????????????????????????....= >>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (61 bytes => 61 (0x3D)) >>>>>>> 0000 - 38 e7 bb 2c 5b af b6 5f-37 d8 3e 7e bb f4 04 f5 >>>>>>> ??8..,[.._7.>~.... >>>>>>> 0010 - e1 28 b5 e5 07 5a ec ce-da 2f f3 b6 45 61 cf ef >>>>>>> ??.(...Z.../..Ea.. >>>>>>> 0020 - 90 fb 57 b8 f3 20 45 27-60 d4 26 51 38 77 e4 bc ??..W.. >>>>>>> E'`.&Q8w.. >>>>>>> 0030 - b7 64 d4 8b 73 25 41 9e-fe d3 9d 5f 53 >>>>>>> ???????????.d..s%A...._S >>>>>>> SSL_accept:TLSv1.3 early data >>>>>>> write to 0x7fe400f050c0 [0x7fe403018a00] (24 bytes => 24 (0x18)) >>>>>>> 0000 - 17 03 03 00 13 25 85 60-eb 7d c1 a8 15 49 d5 63 >>>>>>> ??.....%.`.}...I.c >>>>>>> 0010 - 18 7f c6 ac ed 7f df 77- ?????????????????????????.......w >>>>>>> SSL3 alert write:fatal:unknown >>>>>>> SSL_accept:error in error >>>>>>> ERROR >>>>>>> 140736092021632:error:1417C0C7:SSL >>>>>>> routines:tls_process_client_certificate:peer did not return a >>>>>>> certificate:ssl/statem/statem_srvr.c:3654: >>>>>>> shutting down SSL >>>>>>> CONNECTION CLOSED >>>>>>> >>>>>>> >>>>>>> >>>>>>> When using openssl s_client all works as expected tho (thats also >>>>>>> true if I use my native implementation on the client and server >>>>>>> side that uses openssl): >>>>>>> >>>>>>> ./bin/openssl s_client -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 >>>>>>> ?-state -tls1_3 -connect localhost:8443 >>>>>>> >>>>>>> The interesting thing is if I use ?-verify 1? and not ?-Verify 1? >>>>>>> with openssl which tells it I want to request a certificate but >>>>>>> will also process if none is provided I receive the certificate >>>>>>> at some point as seen here: >>>>>>> >>>>>>> SSL_accept:before SSL initialization >>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>> 0000 - 16 03 03 01 60 ???????????????????????????????????....` >>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (352 bytes => 352 (0x160)) >>>>>>> 0000 - 01 00 01 5c 03 03 61 c0-b3 ed 88 65 e6 cf 11 3f >>>>>>> ??...\..a....e...? >>>>>>> 0010 - c0 e0 f8 df a6 63 32 c2-ab 3d 61 6f 41 ed b1 4b >>>>>>> ??.....c2..=aoA..K >>>>>>> 0020 - 53 0e 83 e5 a1 b8 20 c7-1b 8c b8 e6 b5 da 4e 4e ??S..... >>>>>>> .......NN >>>>>>> 0030 - 3f 3c 61 7a ad 58 23 94-a7 32 79 2f db 9f 21 c0 >>>>>>> ???>>>>>> 0040 - 8e 0c c5 ce b1 c2 a4 00-14 c0 2c c0 2b c0 2f c0 >>>>>>> ??..........,.+./. >>>>>>> 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 52 dc d6 47 6e >>>>>>> ??.3.G.E...A.R..Gn >>>>>>> 0120 - a1 de 9c 71 c2 54 0e 5c-9b 57 fb c8 aa 3f 19 f7 >>>>>>> ??...q.T.\.W...?.. >>>>>>> 0130 - d3 a4 25 12 fa 3f 6c 6d-95 30 66 ca 63 b7 a1 dd >>>>>>> ??..%..?lm.0f.c... >>>>>>> 0140 - ae 9f 99 d6 a8 6b 20 4f-29 7a 74 58 ad 58 de 12 ??.....k >>>>>>> O)ztX.X.. >>>>>>> 0150 - d7 a5 9b 69 dc 27 ac ec-9e d4 04 ff 01 00 01 00 >>>>>>> ??...i.'.......... >>>>>>> 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 0x7fdc58809fb0 [0x7fdc59025e00] (1430 bytes => 1430 (0x596)) >>>>>>> 0000 - 16 03 03 00 9b 02 00 00-97 03 03 8b c8 62 48 6c >>>>>>> ??.............bHl >>>>>>> 0010 - f5 7c 73 d9 17 f8 63 a2-11 27 40 93 09 26 53 06 >>>>>>> ??.|s...c..'@..&S. >>>>>>> 0020 - b3 62 df 46 26 b6 dc 59-29 b5 58 20 c7 1b 8c b8 >>>>>>> ??.b.F&..Y).X .... >>>>>>> 0030 - e6 b5 da 4e 4e 3f 3c 61-7a ad 58 23 94 a7 32 79 >>>>>>> ??...NN?>>>>>> 0040 - 2f db 9f 21 c0 8e 0c c5-ce b1 c2 a4 13 01 00 00 >>>>>>> ??/..!............ >>>>>>> 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 >>>>>>> ??O.+.....3.E...A. >>>>>>> 0060 - 07 63 1c 19 53 89 68 a8-0f ea 9e 4c 18 6f 2a ad >>>>>>> ??.c..S.h....L.o*. >>>>>>> 0070 - 2a df eb 17 a2 08 94 c6-e3 c5 97 ae 0f c1 1a d7 >>>>>>> ??*............... >>>>>>> 0080 - 0d d7 2e 6d 77 3d 30 a0-07 db 70 35 bb 37 dd 1e >>>>>>> ??...mw=0...p5.7.. >>>>>>> 0090 - b6 f3 4d cb 13 97 7c 11-63 98 e8 64 2d a7 e6 cc >>>>>>> ??..M...|.c..d-... >>>>>>> 00a0 - 14 03 03 00 01 01 17 03-03 00 27 a3 73 d2 ee 2c >>>>>>> ??..........'.s.., >>>>>>> 00b0 - 2f 9c 8f 95 7f ca a3 89-bc b4 b3 b2 3c 8b 23 ef >>>>>>> ??/...........<.#. >>>>>>> 00c0 - 36 66 23 c9 09 02 33 0d-dc 5d 36 61 44 89 8b ef >>>>>>> ??6f#...3..]6aD... >>>>>>> 00d0 - fd 13 17 03 03 00 42 f2-5b 3c 0c 27 5e 7f 97 4f >>>>>>> ??......B.[<.'^..O >>>>>>> 00e0 - 0f de 8c b9 0a a1 41 c7-c2 1e 92 99 6a d5 bd 12 >>>>>>> ??......A.....j... >>>>>>> 00f0 - 38 b6 b7 93 33 e9 8e 0f-44 93 f0 69 58 b6 41 22 >>>>>>> ??8...3...D..iX.A" >>>>>>> 0100 - 46 e2 4a d5 d6 32 2b b8-a7 ae 3a c2 c5 2f e6 35 >>>>>>> ??F.J..2+...:../.5 >>>>>>> 0110 - 11 0c f1 9a 35 2a 87 ed-9e 17 03 03 03 20 a7 e2 >>>>>>> ??....5*....... .. >>>>>>> 0120 - fe ba c7 10 5b 9c cd 94-67 19 37 2d 46 59 ab 56 >>>>>>> ??....[...g.7-FY.V >>>>>>> 0130 - 6b dd a4 10 61 cc ed f1-71 a7 2d 6a 41 2e 2b da >>>>>>> ??k...a...q.-jA.+. >>>>>>> 0140 - d1 35 fc 01 df 49 e5 90-1d 9b b2 03 0a 81 58 18 >>>>>>> ??.5...I........X. >>>>>>> 0150 - 96 a1 db 31 19 98 35 5c-87 8f 6e 32 0a e6 c0 aa >>>>>>> ??...1..5\..n2.... >>>>>>> 0160 - 9e 8e 72 e2 34 b3 b7 a3-d6 d1 66 c7 ce 93 fe 78 >>>>>>> ??..r.4.....f....x >>>>>>> 0170 - 17 c4 71 7c 42 15 c8 af-dc 4f 50 42 51 80 fc bf >>>>>>> ??..q|B....OPBQ... >>>>>>> 0180 - fc 54 d5 d8 59 20 9a 90-c4 78 97 9c 2d 4a d5 58 ??.T..Y >>>>>>> ...x..-J.X >>>>>>> 0190 - be 81 79 23 59 22 9d 27-f8 bd a0 b2 98 b3 47 82 >>>>>>> ??..y#Y".'......G. >>>>>>> 01a0 - d3 52 b5 b5 91 ab 5c 76-52 c5 a5 95 2d 03 1c b7 >>>>>>> ??.R....\vR...-... >>>>>>> 01b0 - 64 4d 0b 88 7f 15 0b c8-a8 90 50 9a b6 b1 9f b7 >>>>>>> ??dM........P..... >>>>>>> 01c0 - 40 09 f2 5f 39 f8 9a 06-21 4d 67 10 0a 67 08 b6 >>>>>>> ??@.._9...!Mg..g.. >>>>>>> 01d0 - b5 9a 25 8c d5 ca 31 6a-8a 6b 01 93 7d 6f 1e 52 >>>>>>> ??..%...1j.k..}o.R >>>>>>> 01e0 - 98 96 9d fb e8 c1 07 ab-57 98 2d 1e 75 77 ef c2 >>>>>>> ??........W.-.uw.. >>>>>>> 01f0 - 49 78 e0 b9 2b 32 23 7e-95 4d 3e 27 00 61 86 0c >>>>>>> ??Ix..+2#~.M>'.a.. >>>>>>> 0200 - 47 c7 79 e4 ee 9d ba c0-ea 62 f1 0d 8e 4a 91 30 >>>>>>> ??G.y......b...J.0 >>>>>>> 0210 - bc 4f 5a 98 26 30 66 ec-c4 63 8f 28 d5 1c 61 23 >>>>>>> ??.OZ.&0f..c.(..a# >>>>>>> 0220 - ea e9 90 4e 36 d9 fa 31-7b 14 27 22 0a ae 9f 64 >>>>>>> ??...N6..1{.'"...d >>>>>>> 0230 - 40 3d e5 a0 5c 9d 3c 04-71 09 b0 7a 6b 51 a0 9c >>>>>>> ??@=..\.<.q..zkQ.. >>>>>>> 0240 - c0 61 32 ce 15 62 8e 29-b1 59 91 c0 17 2c b3 c5 >>>>>>> ??.a2..b.).Y...,.. >>>>>>> 0250 - f9 ed 07 65 3d 11 de 98-de 62 36 50 74 37 af 2d >>>>>>> ??...e=....b6Pt7.- >>>>>>> 0260 - 7d 86 55 c4 3e a2 83 ab-47 8d f2 b2 8d 1d 75 83 >>>>>>> ??}.U.>...G.....u. >>>>>>> 0270 - b5 e4 41 87 a7 a3 85 b0-5e 4e 2e 9c 8c b0 1b 83 >>>>>>> ??..A.....^N...... >>>>>>> 0280 - 7b 54 79 c9 60 ea 7d ed-06 fa dd 24 40 f1 53 9e >>>>>>> ??{Ty.`.}....$@.S. >>>>>>> 0290 - 43 79 25 53 9c c7 6e 95-ab 9f 96 59 cd b9 7b a8 >>>>>>> ??Cy%S..n....Y..{. >>>>>>> 02a0 - a0 23 13 69 db a9 c9 e7-1a 8e e1 9b 54 94 1c 44 >>>>>>> ??.#.i........T..D >>>>>>> 02b0 - 50 08 8b dd eb 4e 2b bb-d7 c9 c2 33 8c a1 b3 65 >>>>>>> ??P....N+....3...e >>>>>>> 02c0 - 06 e6 9d ac 11 16 21 58-40 8d 59 e6 67 e5 31 02 >>>>>>> ??......!X at .Y.g.1. >>>>>>> 02d0 - 15 8d 29 80 20 66 ba c3-56 93 95 5c 65 4b 41 00 ??..). >>>>>>> f..V..\eKA. >>>>>>> 02e0 - c5 71 12 12 f5 20 4f 59-be 77 06 10 6e 48 85 5c ??.q... >>>>>>> OY.w..nH.\ >>>>>>> 02f0 - ff a2 c4 ae fb 4d 95 f5-cc f6 61 20 33 b7 92 1d >>>>>>> ??.....M....a 3... >>>>>>> 0300 - ac a8 f1 b2 b0 88 c6 7b-8b 00 53 30 6d 4a d1 42 >>>>>>> ??.......{..S0mJ.B >>>>>>> 0310 - b3 3e 85 f5 84 e1 c6 ab-10 9d 61 03 46 ff 2d 81 >>>>>>> ??.>........a.F.-. >>>>>>> 0320 - 15 4f 84 d1 4c ee f4 a6-a0 ec 50 60 a0 d1 ff df >>>>>>> ??.O..L.....P`.... >>>>>>> 0330 - 8a 97 f6 7d fb 8f fb 60-18 d4 f1 1f 92 4d d8 69 >>>>>>> ??...}...`.....M.i >>>>>>> 0340 - b1 92 97 44 0f 3c 8a aa-47 07 48 d4 07 2d 3e f2 >>>>>>> ??...D.<..G.H..->. >>>>>>> 0350 - c4 a7 16 35 a7 17 71 ef-98 84 24 67 12 58 30 3b >>>>>>> ??...5..q...$g.X0; >>>>>>> 0360 - 1d 41 8d e5 12 52 95 64-e5 88 35 99 d7 c3 58 40 >>>>>>> ??.A...R.d..5...X@ >>>>>>> 0370 - f9 55 9b 9f e5 33 15 70-41 d7 45 ba a4 fc 75 ea >>>>>>> ??.U...3.pA.E...u. >>>>>>> 0380 - a4 ae f0 68 ea 64 d8 f5-06 68 a9 75 22 4d 43 cc >>>>>>> ??...h.d...h.u"MC. >>>>>>> 0390 - ff 50 cc ac 6e fd 43 dd-eb e4 c8 dd 4b 6c 12 bb >>>>>>> ??.P..n.C.....Kl.. >>>>>>> 03a0 - f1 d4 5e 11 4a 86 90 0b-f8 3a 2e 23 db 61 5a 1f >>>>>>> ??..^.J....:.#.aZ. >>>>>>> 03b0 - 7e 11 00 92 21 68 1f b5-ab f2 f8 38 5e 62 ea f8 >>>>>>> ??~...!h.....8^b.. >>>>>>> 03c0 - da ef c2 6e a0 b8 20 e4-69 49 b3 1f 15 84 0b 9b ??...n.. >>>>>>> .iI...... >>>>>>> 03d0 - ce b0 6f 36 32 7f 7e bf-e8 d7 18 7a 58 60 f4 04 >>>>>>> ??..o62.~....zX`.. >>>>>>> 03e0 - cc 36 bf 06 cd ec e5 9b-19 03 96 09 fb af 8f c3 >>>>>>> ??.6.............. >>>>>>> 03f0 - 98 b4 02 aa e8 55 81 aa-c4 fe 06 81 30 a0 c7 b2 >>>>>>> ??.....U......0... >>>>>>> 0400 - f8 e2 30 00 d7 a0 54 7f-5f d7 ef a6 f8 41 58 34 >>>>>>> ??..0...T._....AX4 >>>>>>> 0410 - f5 f0 18 69 8d e6 7a 23-78 90 8f b1 05 c5 b5 7f >>>>>>> ??...i..z#x....... >>>>>>> 0420 - e0 f2 c7 fa c8 36 5b 53-7e cf e6 75 d3 54 b4 69 >>>>>>> ??.....6[S~..u.T.i >>>>>>> 0430 - 68 43 0d 6a d2 83 cc 13-6d ca bf 83 3c 90 17 03 >>>>>>> ??hC.j....m...<... >>>>>>> 0440 - 03 01 19 96 dc 49 26 ce-1d 8e 86 3d bd cb 00 5e >>>>>>> ??.....I&....=...^ >>>>>>> 0450 - ee f6 e7 1d 16 7a ca ef-fa 6d 16 40 b6 99 d0 c1 >>>>>>> ??.....z...m. at .... >>>>>>> 0460 - df 0b 5f 51 60 a8 24 e0-61 82 13 40 da 88 38 3a >>>>>>> ??.._Q`.$.a.. at ..8: >>>>>>> 0470 - 26 1d 80 51 c4 b1 95 35-95 3c 91 35 28 17 49 d8 >>>>>>> ??&..Q...5.<.5(.I. >>>>>>> 0480 - c3 45 be 32 98 3e 02 07-3b 01 20 2b 51 e1 1a 94 >>>>>>> ??.E.2.>..;. +Q... >>>>>>> 0490 - b9 be 96 aa 7a 13 09 ff-d5 a9 63 d4 6f 49 cb b5 >>>>>>> ??....z.....c.oI.. >>>>>>> 04a0 - 23 ab 7f 8c e2 63 f0 5c-5c 27 1e 04 a8 71 0c c0 >>>>>>> ??#....c.\\'...q.. >>>>>>> 04b0 - 89 cd ed 18 8d 5b 75 ac-af f3 68 6d cc ba 20 38 >>>>>>> ??.....[u...hm.. 8 >>>>>>> 04c0 - b5 7c 09 47 29 28 e2 26-57 57 1f f0 f3 18 fd 6f >>>>>>> ??.|.G)(.&WW.....o >>>>>>> 04d0 - 27 42 a4 e3 de bb e5 d6-09 7d 25 b1 98 97 ad 33 >>>>>>> ??'B.......}%....3 >>>>>>> 04e0 - 68 35 92 07 80 23 f1 66-20 5d 74 f3 02 c5 51 ff ??h5...#.f >>>>>>> ]t...Q. >>>>>>> 04f0 - 07 a9 e9 0e 3e 74 da 2e-8f 3b 16 be e6 94 1b 66 >>>>>>> ??....>t...;.....f >>>>>>> 0500 - bb b2 a2 1e 7c 7b ff 5e-a4 36 2a ba 0b cd 7f e9 >>>>>>> ??....|{.^.6*..... >>>>>>> 0510 - 86 bb 5e 30 f5 57 92 52-82 b6 2e da 71 b7 22 c2 >>>>>>> ??..^0.W.R....q.". >>>>>>> 0520 - 90 c4 69 46 07 df 6c 3f-05 8b 19 3e ce b9 75 0d >>>>>>> ??..iF..l?...>..u. >>>>>>> 0530 - 4b 97 37 ae 94 e2 d6 3c-91 e6 82 c7 a1 78 79 2c >>>>>>> ??K.7....<.....xy, >>>>>>> 0540 - 9a a3 d5 45 94 ad e2 c8-ab fd 81 ec 62 87 f7 75 >>>>>>> ??...E........b..u >>>>>>> 0550 - e3 70 79 8e 82 3b c5 45-0d d0 33 5f 17 03 03 00 >>>>>>> ??.py..;.E..3_.... >>>>>>> 0560 - 35 da e0 74 2a 06 41 5a-64 1e 54 94 29 73 43 3f >>>>>>> ??5..t*.AZd.T.)sC? >>>>>>> 0570 - e5 24 a8 ba b2 7e 6b 26-82 fc d9 f6 dd 19 05 4a >>>>>>> ??.$...~k&.......J >>>>>>> 0580 - 2c 1a f3 bb 16 1d 38 95-a6 d3 a8 58 f6 a3 41 c7 >>>>>>> ??,.....8....X..A. >>>>>>> 0590 - 92 44 35 24 25 0e ????????????????????????????????.D5$%. >>>>>>> SSL_accept:SSLv3/TLS write finished >>>>>>> SSL_accept:TLSv1.3 early data >>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>> 0000 - 14 03 03 00 01 ???????????????????????????????????..... >>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (1 bytes => 1 (0x1)) >>>>>>> 0000 - 01 ???????????????????????????????????????????????. >>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>> 0000 - 17 03 03 00 3d ???????????????????????????????????....= >>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (61 bytes => 61 (0x3D)) >>>>>>> 0000 - ad dd 3e d9 ee ab 56 65-50 1c 72 2a d8 62 7f 90 >>>>>>> ??..>...VeP.r*.b.. >>>>>>> 0010 - 13 71 7d 37 39 40 fb 89-8f 05 4b 39 44 9d 4d 67 >>>>>>> ??.q}79 at ....K9D.Mg >>>>>>> 0020 - e3 41 29 b6 3e e8 fe 04-1b 8e eb 7a 4c e2 14 a0 >>>>>>> ??.A).>......zL... >>>>>>> 0030 - b1 c2 47 3f 94 35 ed ab-8a d1 75 3b ba >>>>>>> ???????????..G?.5....u;. >>>>>>> SSL_accept:TLSv1.3 early data >>>>>>> SSL_accept:SSLv3/TLS read client certificate >>>>>>> SSL_accept:SSLv3/TLS read finished >>>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>>>> 0000 - 17 03 03 00 da 52 1f 48-00 f4 31 13 90 7f 9c c2 >>>>>>> ??.....R.H..1..... >>>>>>> 0010 - fc 70 1a fc f7 4a 48 e7-31 ad 37 ab b5 2b 4e 5c >>>>>>> ??.p...JH.1.7..+N\ >>>>>>> 0020 - e8 d8 6d e9 af 6c 4f c1-9e 7b ea ff ef b3 eb 74 >>>>>>> ??..m..lO..{.....t >>>>>>> 0030 - 27 67 10 21 66 5b 32 13-31 bc 99 d5 1c 6c 79 55 >>>>>>> ??'g.!f[2.1....lyU >>>>>>> 0040 - f3 3e f6 4b 07 4d a9 78-3d 12 8a f5 38 ef d9 f4 >>>>>>> ??.>.K.M.x=...8... >>>>>>> 0050 - 48 e0 2c 35 94 06 4f eb-09 e6 70 fb 59 95 7a c8 >>>>>>> ??H.,5..O...p.Y.z. >>>>>>> 0060 - 24 dd 24 e2 f9 63 b9 3c-f2 66 86 c4 73 44 53 fd >>>>>>> ??$.$..c.<.f..sDS. >>>>>>> 0070 - ca 67 8f 01 d6 db 70 f9-60 bc 50 11 51 72 dc 63 >>>>>>> ??.g....p.`.P.Qr.c >>>>>>> 0080 - 12 ca 4f 23 e2 c5 d1 1d-e5 b0 d4 ec 89 ca 28 be >>>>>>> ??..O#..........(. >>>>>>> 0090 - 9c 30 83 40 02 a4 62 a8-5c b3 20 1a ab 39 b7 7b >>>>>>> ??.0. at ..b.\. ..9.{ >>>>>>> 00a0 - 89 13 39 87 73 be a8 f8-60 13 31 0a 48 5c 79 b9 >>>>>>> ??..9.s...`.1.H\y. >>>>>>> 00b0 - cc 4a 51 e3 0d d2 b4 93-c0 1f 3a 22 b3 fa 24 a0 >>>>>>> ??.JQ.......:"..$. >>>>>>> 00c0 - 7c f6 76 79 d0 2d 5b 1a-ff a6 e9 e1 40 d3 b1 8c >>>>>>> ??|.vy.-[..... at ... >>>>>>> 00d0 - 0a fa fa de f3 8e d6 ad-9a 22 6b 67 0b 88 18 >>>>>>> ?????........."kg... >>>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>>>> 0000 - 17 03 03 00 da 46 aa ea-6a 37 b1 35 e8 41 c8 b3 >>>>>>> ??.....F..j7.5.A.. >>>>>>> 0010 - 84 25 af 1c 36 a3 6d 78-a4 44 4a 83 52 ef 13 7c >>>>>>> ??.%..6.mx.DJ.R..| >>>>>>> 0020 - 8f 18 d3 4c f8 22 c8 b3-ad d0 d0 5b 47 a0 43 da >>>>>>> ??...L.".....[G.C. >>>>>>> 0030 - d2 6e 04 8f dc c9 56 90-58 87 62 63 4c cc 31 ec >>>>>>> ??.n....V.X.bcL.1. >>>>>>> 0040 - b8 c9 18 be 41 32 e1 3c-00 41 2a f1 4d 5c 2d 44 >>>>>>> ??....A2.<.A*.M\-D >>>>>>> 0050 - 8c aa e1 f0 ed 38 ee 44-64 e5 fd ea 58 3b 84 5d >>>>>>> ??.....8.Dd...X;.] >>>>>>> 0060 - 83 39 21 2e fe 79 4d 76-10 65 87 0f 3c ac df 28 >>>>>>> ??.9!..yMv.e..<..( >>>>>>> 0070 - 49 f8 60 eb be 49 e4 0a-0b 6a 03 2b 9d cf 9b a5 >>>>>>> ??I.`..I...j.+.... >>>>>>> 0080 - 03 56 58 32 c2 b2 59 f9-0a 0d f0 ae af ff 20 19 >>>>>>> ??.VX2..Y....... . >>>>>>> 0090 - e5 6e e4 86 2f 5e 3f 7d-47 d5 73 ae 89 48 a7 66 >>>>>>> ??.n../^?}G.s..H.f >>>>>>> 00a0 - fb 2d 83 60 e8 8b ab 27-12 db 24 78 54 eb 14 2d >>>>>>> ??.-.`...'..$xT..- >>>>>>> 00b0 - b7 c6 17 2d 3c 91 57 ac-6e 35 b8 c3 fa c2 42 48 >>>>>>> ??...-<.W.n5....BH >>>>>>> 00c0 - 2a cb aa 98 32 89 8a ce-0c f7 cd 5e fb bf 6d 33 >>>>>>> ??*...2......^..m3 >>>>>>> 00d0 - 08 50 cf 1e 06 bb a1 98-be a4 a9 51 9a b0 34 >>>>>>> ?????.P.........Q..4 >>>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>> 0000 - 17 03 03 00 12 c5 9b 73-cc 91 7e 48 cb 25 31 a0 >>>>>>> ??.......s..~H.%1. >>>>>>> 0010 - 67 41 db bb 0f 62 d8 ?????????????????????????????gA...b. >>>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>> 0000 - 17 03 03 00 12 0f dd 3f-c1 7c e6 b0 cc ea f0 13 >>>>>>> ??.......?.|...... >>>>>>> 0010 - 00 d8 01 de ef 7c bb ?????????????????????????????.....|. >>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>> 0000 - 17 03 03 00 1e ???????????????????????????????????..... >>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (30 bytes => 30 (0x1E)) >>>>>>> 0000 - d6 88 44 82 cb 23 16 ba-c9 a4 fb 55 51 08 90 c1 >>>>>>> ??..D..#.....UQ... >>>>>>> 0010 - bf bd a1 7f 0e 37 b0 b4-b5 df f1 07 6c 07 >>>>>>> ????????.....7......l. >>>>>>> I am a clientwrite to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes >>>>>>> => 23 (0x17)) >>>>>>> 0000 - 17 03 03 00 12 c0 70 5d-14 e7 69 57 0a d8 64 16 >>>>>>> ??......p]..iW..d. >>>>>>> 0010 - 0c 90 06 0f c3 4d 1d ?????????????????????????????.....M. >>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>> 0000 - 17 03 03 00 13 ???????????????????????????????????..... >>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (19 bytes => 19 (0x13)) >>>>>>> 0000 - 60 28 5b ff bb 0d 9f 96-9a 2d cb fd 60 eb 96 62 >>>>>>> ??`([......-..`..b >>>>>>> 0010 - 53 e6 25 ?????????????????????????????????????????S.% >>>>>>> SSL3 alert read:warning:close notify >>>>>>> DONE >>>>>>> shutting down SSL >>>>>>> CONNECTION CLOSED >>>>>>> >>>>>>> >>>>>>> I am using the following JDK version on MacOS: >>>>>>> >>>>>>> ssl git:(cert_cb_openssl_1_1_1) ? >>>>>>> /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java >>>>>>> -version >>>>>>> java version "11" 2018-09-25 >>>>>>> Java(TM) SE Runtime Environment 18.9 (build 11+28) >>>>>>> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) >>>>>>> >>>>>>> For this to work you will need to have openssl 1.1.1 installed. >>>>>>> >>>>>>> Any help would be welcome, >>>>>>> Norman >>>>>>> >>>>>>> [1] https://github.com/netty/netty-tcnative >>>>>>> >>>>>>> >>>>>>> > From norman.maurer at googlemail.com Mon Sep 17 17:44:14 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 17 Sep 2018 19:44:14 +0200 Subject: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: <2dea4403-e019-613d-373e-75c789029cef@oracle.com> References: <32bad254-1a8c-7933-d5a0-0b8ce3ed2f68@oracle.com> <05EF82F5-6506-4928-8030-B9BEEE64E1F1@googlemail.com> <0EB21A4C-7DFF-4878-9446-182DA35F0A8C@googlemail.com> <2dea4403-e019-613d-373e-75c789029cef@oracle.com> Message-ID: <422BC150-FBAE-4829-B375-637F27C671C4@googlemail.com> Of course not? ID: 9057280 Thanks Norman > On 17. Sep 2018, at 19:35, Xuelei Fan wrote: > > Hi Norman, > > Thank you so much for the reproducing code. Would you mind file a bug for this issue? > > Thanks, > Xuelei > > On 9/17/2018 3:39 AM, Norman Maurer wrote: >> Hi all, >> As requested I pushed a pure JDK reproducer to GitHub which you can easily use to reproduce the problem. All the details how to run it etc are in the README.md file. I also included a server to show that all works if we use the JDK on the client side and server side. >> Also as stated before you will see that the cert will be send even if you use OpenSSL on the serverside if you replace ?-Verify 1? with ?-verify 1? (which is kind of the same as setWantClientAuth(true)). >> Please don't hesitate to ping me if you need any more details or have any more questions. >> https://github.com/normanmaurer/jdktls13bugreproducer >> Here is the output with debugging enabled on the client side. >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.515 CEST|SSLContextImpl.java:427|System property jdk.tls.client.cipherSuites is set to 'null' >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.529 CEST|SSLContextImpl.java:427|System property jdk.tls.server.cipherSuites is set to 'null' >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.563 CEST|SSLCipher.java:437|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.577 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.577 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.580 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.580 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_RC4_128_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_RC4_128_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_RC4_128_MD5 >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_RC4_128_MD5 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_WITH_RC4_128_MD5 >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_WITH_RC4_128_MD5 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5 >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.591 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.593 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.593 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.599 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.599 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.642 CEST|SunX509KeyManagerImpl.java:164|found key for : 1 ( >> "certificate" : { >> "version" : "v3", >> "serial number" : "20 C3 8D C4 49 66 D0 02", >> "signature algorithm": "SHA256withRSA", >> "issuer" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >> "not before" : "2013-08-02 09:51:36.000 CEST", >> "not after" : "10000-01-01 24:59:59.000 CET", >> "subject" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >> "subject public key" : "RSA"} >> ) >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 CEST|SSLContextImpl.java:115|trigger seeding of SecureRandom >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 CEST|SSLContextImpl.java:119|done seeding of SecureRandom >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.665 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_128_GCM_SHA256 for TLS12 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.666 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_256_GCM_SHA384 for TLS12 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_128_GCM_SHA256 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_256_GCM_SHA384 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS11 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_128_GCM_SHA256 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_256_GCM_SHA384 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS10 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS10 >> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.690 CEST|ServerNameExtension.java:255|Unable to indicate server name >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.690 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: server_name >> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.701 CEST|SignatureScheme.java:282|Signature algorithm, ed25519, is not supported by the underlying providers >> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.702 CEST|SignatureScheme.java:282|Signature algorithm, ed448, is not supported by the underlying providers >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.706 CEST|SignatureScheme.java:358|Ignore disabled signature sheme: rsa_md5 >> javax.net.ssl|INFO|01|main|2018-09-17 11:51:54.706 CEST|AlpnExtension.java:161|No available application protocols >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.706 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: application_layer_protocol_negotiation >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.707 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: cookie >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: renegotiation_info >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 CEST|PreSharedKeyExtension.java:606|No session to resume. >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: pre_shared_key >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 CEST|ClientHello.java:633|Produced ClientHello handshake message ( >> "ClientHello": { >> "client version" : "TLSv1.2", >> "random" : "66 2E BE D3 8A 77 39 06 3B 5A 34 03 7D EE 74 BB 08 D2 19 FD 50 17 2D 84 29 AA FB E0 EE ED 50 69", >> "session id" : "0B 03 C8 E2 D2 A5 CD 3A 22 C5 85 17 06 64 A9 30 14 62 C0 AF AB 67 CE 63 50 41 50 7F 6B FD 4C 9F", >> "cipher suites" : "[TLS_AES_128_GCM_SHA256(0x1301), TLS_AES_256_GCM_SHA384(0x1302), TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]", >> "compression methods" : "00", >> "extensions" : [ >> "status_request (5)": { >> "certificate status type": ocsp >> "OCSP status request": { >> "responder_id": >> "request extensions": { >> >> } >> } >> }, >> "supported_groups (10)": { >> "versions": [secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] >> }, >> "ec_point_formats (11)": { >> "formats": [uncompressed] >> }, >> "signature_algorithms (13)": { >> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] >> }, >> "signature_algorithms_cert (50)": { >> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] >> }, >> "status_request_v2 (17)": { >> "cert status request": { >> "certificate status type": ocsp_multi >> "OCSP status request": { >> "responder_id": >> "request extensions": { >> >> } >> } >> } >> }, >> "extended_master_secret (23)": { >> >> }, >> "supported_versions (43)": { >> "versions": [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1] >> }, >> "psk_key_exchange_modes (45)": { >> "ke_modes": [psk_dhe_ke] >> }, >> "key_share (51)": { >> "client_shares": [ >> { >> "named group": secp256r1 >> "key_exchange": { >> 0000: 04 A3 9F B9 05 27 00 38 C4 D7 61 6C 66 1F 4A 8D .....'.8..alf.J. >> 0010: B1 02 6F 0B F6 E1 BD 50 93 52 86 2C D2 3C 8D 1A ..o....P.R.,.<.. >> 0020: 10 A9 CD F0 40 F4 CD 04 25 A1 11 E2 58 23 A3 24 .... at ...%...X#.$ >> 0030: CA E8 8F 28 F7 2B 65 96 B2 E3 A1 AE 99 24 94 28 ...(.+e......$.( >> 0040: 83 >> } >> }, >> ] >> } >> ] >> } >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 417 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.719 CEST|SSLSocketOutputRecord.java:255|Raw write ( >> 0000: 16 03 03 01 A1 01 00 01 9D 03 03 66 2E BE D3 8A ...........f.... >> 0010: 77 39 06 3B 5A 34 03 7D EE 74 BB 08 D2 19 FD 50 w9.;Z4...t.....P >> 0020: 17 2D 84 29 AA FB E0 EE ED 50 69 20 0B 03 C8 E2 .-.).....Pi .... >> 0030: D2 A5 CD 3A 22 C5 85 17 06 64 A9 30 14 62 C0 AF ...:"....d.0.b.. >> 0040: AB 67 CE 63 50 41 50 7F 6B FD 4C 9F 00 5A 13 01 .g.cPAP.k.L..Z.. >> 0050: 13 02 C0 2C C0 2B C0 30 00 9D C0 2E C0 32 00 9F ...,.+.0.....2.. >> 0060: 00 A3 C0 2F 00 9C C0 2D C0 31 00 9E 00 A2 C0 24 .../...-.1.....$ >> 0070: C0 28 00 3D C0 26 C0 2A 00 6B 00 6A C0 0A C0 14 .(.=.&.*.k.j.... >> 0080: 00 35 C0 05 C0 0F 00 39 00 38 C0 23 C0 27 00 3C .5.....9.8.#.'.< >> 0090: C0 25 C0 29 00 67 00 40 C0 09 C0 13 00 2F C0 04 .%.).g. at ...../.. >> 00A0: C0 0E 00 33 00 32 00 FF 01 00 00 FA 00 05 00 05 ...3.2.......... >> 00B0: 01 00 00 00 00 00 0A 00 20 00 1E 00 17 00 18 00 ........ ....... >> 00C0: 19 00 09 00 0A 00 0B 00 0C 00 0D 00 0E 00 16 01 ................ >> 00D0: 00 01 01 01 02 01 03 01 04 00 0B 00 02 01 00 00 ................ >> 00E0: 0D 00 28 00 26 04 03 05 03 06 03 08 04 08 05 08 ..(.&........... >> 00F0: 06 08 09 08 0A 08 0B 04 01 05 01 06 01 04 02 03 ................ >> 0100: 03 03 01 03 02 02 03 02 01 02 02 00 32 00 28 00 ............2.(. >> 0110: 26 04 03 05 03 06 03 08 04 08 05 08 06 08 09 08 &............... >> 0120: 0A 08 0B 04 01 05 01 06 01 04 02 03 03 03 01 03 ................ >> 0130: 02 02 03 02 01 02 02 00 11 00 09 00 07 02 00 04 ................ >> 0140: 00 00 00 00 00 17 00 00 00 2B 00 09 08 03 04 03 .........+...... >> 0150: 03 03 02 03 01 00 2D 00 02 01 01 00 33 00 47 00 ......-.....3.G. >> 0160: 45 00 17 00 41 04 A3 9F B9 05 27 00 38 C4 D7 61 E...A.....'.8..a >> 0170: 6C 66 1F 4A 8D B1 02 6F 0B F6 E1 BD 50 93 52 86 lf.J...o....P.R. >> 0180: 2C D2 3C 8D 1A 10 A9 CD F0 40 F4 CD 04 25 A1 11 ,.<...... at ...%.. >> 0190: E2 58 23 A3 24 CA E8 8F 28 F7 2B 65 96 B2 E3 A1 .X#.$...(.+e.... >> 01A0: AE 99 24 94 28 83 ..$.(. >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: 16 03 03 00 9B ..... >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length = 155 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.721 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: 02 00 00 97 03 03 AB 76 F1 BA F3 B1 F0 DD 53 AC .......v......S. >> 0010: 5B 54 E9 E4 2E F8 44 D2 5E B2 59 85 0D 16 79 EE [T....D.^.Y...y. >> 0020: A7 66 8A 84 69 2A 20 0B 03 C8 E2 D2 A5 CD 3A 22 .f..i* .......:" >> 0030: C5 85 17 06 64 A9 30 14 62 C0 AF AB 67 CE 63 50 ....d.0.b...g.cP >> 0040: 41 50 7F 6B FD 4C 9F 13 01 00 00 4F 00 2B 00 02 AP.k.L.....O.+.. >> 0050: 03 04 00 33 00 45 00 17 00 41 04 18 4A 46 BB 73 ...3.E...A..JF.s >> 0060: F4 6F 5D F0 3C 98 AD 70 7E 13 D6 C0 E5 C0 28 5A .o].<..p......(Z >> 0070: D7 42 78 95 68 E0 85 B7 06 CD DB 3C 35 DA AF E8 .Bx.h......<5... >> 0080: 95 D6 A2 3C 77 CF 7E 8E C8 94 50 BA CD 18 3F DA ...> 0090: E3 A3 25 E9 F3 C9 A9 7F 4E B6 A9 ..%.....N.. >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.721 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 handshake, length = 155 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.722 CEST|ServerHello.java:866|Consuming ServerHello handshake message ( >> "ServerHello": { >> "server version" : "TLSv1.2", >> "random" : "AB 76 F1 BA F3 B1 F0 DD 53 AC 5B 54 E9 E4 2E F8 44 D2 5E B2 59 85 0D 16 79 EE A7 66 8A 84 69 2A", >> "session id" : "0B 03 C8 E2 D2 A5 CD 3A 22 C5 85 17 06 64 A9 30 14 62 C0 AF AB 67 CE 63 50 41 50 7F 6B FD 4C 9F", >> "cipher suite" : "TLS_AES_128_GCM_SHA256(0x1301)", >> "compression methods" : "00", >> "extensions" : [ >> "supported_versions (43)": { >> "selected version": [TLSv1.3] >> }, >> "key_share (51)": { >> "server_share": { >> "named group": secp256r1 >> "key_exchange": { >> 0000: 04 18 4A 46 BB 73 F4 6F 5D F0 3C 98 AD 70 7E 13 ..JF.s.o].<..p.. >> 0010: D6 C0 E5 C0 28 5A D7 42 78 95 68 E0 85 B7 06 CD ....(Z.Bx.h..... >> 0020: DB 3C 35 DA AF E8 95 D6 A2 3C 77 CF 7E 8E C8 94 .<5......> 0030: 50 BA CD 18 3F DA E3 A3 25 E9 F3 C9 A9 7F 4E B6 P...?...%.....N. >> 0040: A9 >> } >> }, >> } >> ] >> } >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|SSLExtensions.java:167|Consumed extension: supported_versions >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|ServerHello.java:962|Negotiated protocol version: TLSv1.3 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|SSLExtensions.java:138|Ignore unsupported extension: server_name >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|SSLExtensions.java:138|Ignore unsupported extension: max_fragment_length >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|SSLExtensions.java:138|Ignore unsupported extension: status_request >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:138|Ignore unsupported extension: ec_point_formats >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:138|Ignore unsupported extension: application_layer_protocol_negotiation >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:138|Ignore unsupported extension: status_request_v2 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:138|Ignore unsupported extension: extended_master_secret >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:167|Consumed extension: supported_versions >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 CEST|SSLExtensions.java:167|Consumed extension: key_share >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 CEST|SSLExtensions.java:138|Ignore unsupported extension: renegotiation_info >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 CEST|PreSharedKeyExtension.java:832|Handling pre_shared_key absence. >> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.725 CEST|SSLSessionImpl.java:203|Session initialized: Session(1537177914725|TLS_AES_128_GCM_SHA256) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 CEST|SSLExtensions.java:182|Ignore unavailable extension: server_name >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: max_fragment_length >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: status_request >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: ec_point_formats >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: application_layer_protocol_negotiation >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: status_request_v2 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: extended_master_secret >> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: supported_versions >> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: key_share >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: renegotiation_info >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: pre_shared_key >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.732 CEST|SSLCipher.java:1824|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE >> countdown value = 137438953472 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.735 CEST|SSLCipher.java:1978|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE >> countdown value = 137438953472 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.736 CEST|SSLSocketOutputRecord.java:225|Raw write ( >> 0000: 14 03 03 00 01 01 ...... >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.736 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: 14 03 03 00 01 ..... >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 change_cipher_spec, length = 1 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: 01 . >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 change_cipher_spec, length = 1 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|ChangeCipherSpec.java:232|Consuming ChangeCipherSpec message >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: 17 03 03 00 27 ....' >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 39 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: D5 B7 25 6F AF E9 D6 6F 7C 61 98 90 3F FE BA 9A ..%o...o.a..?... >> 0010: A8 5B 94 5E 3A 47 38 62 36 90 9A 1D BE BF 87 18 .[.^:G8b6....... >> 0020: 56 8C E3 AA CE AD AA V...... >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 39 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.746 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >> 0000: 08 00 00 12 00 10 00 0A 00 0C 00 0A 00 1D 00 17 ................ >> 0010: 00 1E 00 19 00 18 ...... >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 CEST|EncryptedExtensions.java:171|Consuming EncryptedExtensions handshake message ( >> "EncryptedExtensions": [ >> "supported_groups (10)": { >> "versions": [x25519, secp256r1, x448, secp521r1, secp384r1] >> } >> ] >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 CEST|SSLExtensions.java:148|Ignore unavailable extension: server_name >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 CEST|SSLExtensions.java:148|Ignore unavailable extension: max_fragment_length >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:167|Consumed extension: supported_groups >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:182|Ignore unavailable extension: server_name >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:182|Ignore unavailable extension: max_fragment_length >> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: supported_groups >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:182|Ignore unavailable extension: application_layer_protocol_negotiation >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: 17 03 03 00 42 ....B >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 66 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: 63 F7 54 24 11 6A 91 1F 1F C5 70 9A 26 AD CE 98 c.T$.j....p.&... >> 0010: D0 A9 7A 84 AF 39 7C A0 AD F6 6B B2 10 88 27 8B ..z..9....k...'. >> 0020: 79 E0 F4 5A 9F 68 AA F0 56 D3 45 72 7C 7F 22 03 y..Z.h..V.Er..". >> 0030: 0A 53 F6 24 68 CB 0B E1 3B DD D4 78 B5 AC 1E D7 .S.$h...;..x.... >> 0040: 03 FB .. >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 66 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >> 0000: 0D 00 00 2D 00 00 2A 00 0D 00 26 00 24 04 03 05 ...-..*...&.$... >> 0010: 03 06 03 08 07 08 08 08 09 08 0A 08 0B 08 04 08 ................ >> 0020: 05 08 06 04 01 05 01 06 01 03 03 02 03 03 01 02 ................ >> 0030: 01 . >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 CEST|CertificateRequest.java:864|Consuming CertificateRequest handshake message ( >> "CertificateRequest": { >> "certificate_request_context": "", >> "extensions": [ >> "signature_algorithms (13)": { >> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, ed25519, ed448, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha224, ecdsa_sha1, rsa_sha224, rsa_pkcs1_sha1] >> } >> ] >> } >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 CEST|SSLExtensions.java:167|Consumed extension: signature_algorithms >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 CEST|SSLExtensions.java:148|Ignore unavailable extension: signature_algorithms_cert >> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 CEST|SignatureScheme.java:390|Unsupported signature scheme: ed25519 >> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 CEST|SignatureScheme.java:390|Unsupported signature scheme: ed448 >> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 CEST|SignatureScheme.java:390|Unsupported signature scheme: ecdsa_sha224 >> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 CEST|SignatureScheme.java:390|Unsupported signature scheme: rsa_sha224 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 CEST|SSLExtensions.java:199|Populated with extension: signature_algorithms >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 CEST|SSLExtensions.java:182|Ignore unavailable extension: signature_algorithms_cert >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: 17 03 03 03 20 .... >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 800 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.753 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: FE BB B2 07 BA CE A6 32 AA 58 66 2F 6D 87 16 75 .......2.Xf/m..u >> 0010: CF 71 13 53 FB 45 AE DC 84 F4 AA 33 08 08 DF B5 .q.S.E.....3.... >> 0020: 97 C5 79 40 4A 28 F4 9D 0F 5A 86 4E C4 5F C7 2E ..y at J(...Z.N._.. >> 0030: AA AA 42 F7 8A FF 6B C1 28 75 9B A3 25 F0 23 81 ..B...k.(u..%.#. >> 0040: 74 BB 9A EA A8 8D 89 BE E9 80 AE 31 C3 3A FC 35 t..........1.:.5 >> 0050: E6 CA C5 77 BF C7 0E ED 64 26 DB 4E C3 3D F5 AD ...w....d&.N.=.. >> 0060: 5E EB A8 37 AA 81 EF 39 24 84 C9 C4 C7 A2 D7 DB ^..7...9$....... >> 0070: 7F 82 01 7A 02 E7 23 A3 6E C9 68 B8 E5 C3 9F 53 ...z..#.n.h....S >> 0080: 16 6E EF B0 54 D2 67 4C FF 22 E6 78 B1 A0 DB BE .n..T.gL.".x.... >> 0090: 97 23 FC C8 D8 92 86 3D C6 6B E4 C1 AC EF B8 46 .#.....=.k.....F >> 00A0: 75 3C 00 08 8B 34 5F 59 05 49 25 97 BE A8 61 8E u<...4_Y.I%...a. >> 00B0: B0 5F 25 91 7A FE 79 53 7A C1 A7 E7 70 7B A5 53 ._%.z.ySz...p..S >> 00C0: 5A 63 8B 8E B9 92 2D B3 80 DC AA 75 BE 0F 47 F3 Zc....-....u..G. >> 00D0: E8 D9 0D 7D D9 C3 B6 00 AD 2A 43 CC 66 87 88 AF .........*C.f... >> 00E0: 35 87 74 2F 87 2F 3C A6 FB 12 1A 9C 46 62 1C DC 5.t/./<.....Fb.. >> 00F0: 4E 4E DC 16 70 7E 08 74 FB F7 E6 5F 4D D9 20 F9 NN..p..t..._M. . >> 0100: CA F3 91 45 D6 1A B3 BA FA 4E BD A4 74 9E 4C 78 ...E.....N..t.Lx >> 0110: 03 18 2C 70 35 42 68 F3 9A 1D 24 3F A7 27 DF 29 ..,p5Bh...$?.'.) >> 0120: D5 58 7C CB 19 2F D1 DF 8A 6D B2 85 52 B5 78 19 .X.../...m..R.x. >> 0130: EA 5C E2 7A 23 42 9E D7 A3 DC D0 DE D8 33 47 2B .\.z#B.......3G+ >> 0140: 0C D8 6E 77 25 DB E6 12 B0 7A AD A5 C9 96 AC A9 ..nw%....z...... >> 0150: 1D CD 73 39 AC 6A 9F E2 0A F7 17 F1 F0 FF 75 9C ..s9.j........u. >> 0160: B2 05 9E 7A F4 18 4F FC 9D 42 69 4C E0 3E A1 21 ...z..O..BiL.>.! >> 0170: DA 1F 71 07 59 C6 A2 F9 0B 4F C0 CD A4 85 A8 DB ..q.Y....O...... >> 0180: 77 F6 87 5E 09 16 49 5C 2C B8 C0 7B 39 81 65 FD w..^..I\,...9.e. >> 0190: 29 52 E2 C7 F5 C7 AD BC F6 A9 F9 6D D2 E9 A4 14 )R.........m.... >> 01A0: C9 D3 79 2E D2 BA 10 4C BD 44 65 2B A8 7E F1 3A ..y....L.De+...: >> 01B0: F3 F6 11 53 38 17 10 12 B4 CD C5 AD 72 3B 84 A2 ...S8.......r;.. >> 01C0: 1B F9 D7 BF 34 00 5A FE F4 CE 09 0C EA F2 27 9A ....4.Z.......'. >> 01D0: BD DD 93 37 E2 DF 60 CC 8A F7 C6 4B 08 30 0D 78 ...7..`....K.0.x >> 01E0: 5C EB 49 34 DB 8B EB 55 33 0C 82 03 07 FD 3D FC \.I4...U3.....=. >> 01F0: 49 11 88 1C F6 67 7F 0B 48 AA EC 1B AF 04 46 CF I....g..H.....F. >> 0200: 09 C5 8E B3 F8 92 C4 56 3D 8F 0E 1D 9F D3 0C FE .......V=....... >> 0210: 94 23 15 53 8E 1F 5E C4 FA 44 03 3B 1B B0 0A 2D .#.S..^..D.;...- >> 0220: 71 D4 B5 AC 1F 52 D7 25 9F A0 C8 4B 9B 32 B8 22 q....R.%...K.2." >> 0230: 3F AF B3 19 16 8C 2A 5C B4 89 BF 82 DC 4D AF 22 ?.....*\.....M." >> 0240: 2A 33 73 90 F3 C8 FF 2E C1 B3 83 D2 7A 29 4E 15 *3s.........z)N. >> 0250: 5D 87 86 F6 94 EA B0 B4 A4 41 B9 C5 BA 89 B8 E9 ]........A...... >> 0260: 26 E7 96 BC 4D 8A FD 86 C7 C9 2A 96 75 C3 07 EF &...M.....*.u... >> 0270: 5C 5A 4E 91 71 7D 1B A2 12 88 C5 D0 D2 5E 79 E1 \ZN.q........^y. >> 0280: 6C 65 35 5E 6C CC 56 47 FD F3 96 78 7A A0 08 7E le5^l.VG...xz... >> 0290: DB 3C CC 10 76 15 37 46 48 6B 2D 23 7B A3 44 5A .<..v.7FHk-#..DZ >> 02A0: A4 46 B3 CE E2 15 BA 4C D2 93 16 57 1F BA 75 72 .F.....L...W..ur >> 02B0: BF 8C 66 50 F2 A4 F6 05 84 E5 47 12 30 BE 34 70 ..fP......G.0.4p >> 02C0: 4D 0F BD FE 54 E8 B1 CE B5 7F 6E 97 38 09 29 1F M...T.....n.8.). >> 02D0: 41 2D 2E 9E 75 D8 77 0C 08 DB 5C B4 EE 3F FE E2 A-..u.w...\..?.. >> 02E0: DC CF D0 ED C8 02 50 C4 EE B3 1D 8A 9E 9B EE 5E ......P........^ >> 02F0: 14 BA C2 5A B0 83 8E 5C E5 7B 69 2B 69 8C F1 AA ...Z...\..i+i... >> 0300: 2D D5 D1 3D 9D 42 1B B2 50 5D BE 7E E4 11 D2 90 -..=.B..P]...... >> 0310: 0B 54 71 7F D6 13 88 E2 FE 37 9F 70 B5 0B 57 79 .Tq......7.p..Wy >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.753 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 800 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.755 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >> 0000: 0B 00 03 0B 00 00 03 07 00 03 02 30 82 02 FE 30 ...........0...0 >> 0010: 82 01 E6 A0 03 02 01 02 02 08 20 C3 8D C4 49 66 .......... ...If >> 0020: D0 02 30 0D 06 09 2A 86 48 86 F7 0D 01 01 0B 05 ..0...*.H....... >> 0030: 00 30 3E 31 3C 30 3A 06 03 55 04 03 0C 33 65 38 .0>1<0:..U...3e8 >> 0040: 61 63 30 32 66 61 30 64 36 35 61 38 34 32 31 39 ac02fa0d65a84219 >> 0050: 30 31 36 30 34 35 64 62 38 62 30 35 63 34 38 35 016045db8b05c485 >> 0060: 62 34 65 63 64 66 2E 6E 65 74 74 79 2E 74 65 73 b4ecdf.netty.tes >> 0070: 74 30 20 17 0D 31 33 30 38 30 32 30 37 35 31 33 t0 ..13080207513 >> 0080: 36 5A 18 0F 39 39 39 39 31 32 33 31 32 33 35 39 6Z..999912312359 >> 0090: 35 39 5A 30 3E 31 3C 30 3A 06 03 55 04 03 0C 33 59Z0>1<0:..U...3 >> 00A0: 65 38 61 63 30 32 66 61 30 64 36 35 61 38 34 32 e8ac02fa0d65a842 >> 00B0: 31 39 30 31 36 30 34 35 64 62 38 62 30 35 63 34 19016045db8b05c4 >> 00C0: 38 35 62 34 65 63 64 66 2E 6E 65 74 74 79 2E 74 85b4ecdf.netty.t >> 00D0: 65 73 74 30 82 01 22 30 0D 06 09 2A 86 48 86 F7 est0.."0...*.H.. >> 00E0: 0D 01 01 01 05 00 03 82 01 0F 00 30 82 01 0A 02 ...........0.... >> 00F0: 82 01 01 00 DB F8 70 4E DC 2D 14 44 12 AF 0D 48 ......pN.-.D...H >> 0100: 09 1D B8 48 94 1C 9E F1 7F DC 6C D1 F7 94 3A B7 ...H......l...:. >> 0110: 5C E3 85 07 3E CB E1 76 4A 2C 32 17 4B E1 5E 42 \...>..vJ,2.K.^B >> 0120: A4 80 50 CA 36 A2 D9 94 F9 59 23 D0 AA 2B B2 13 ..P.6....Y#..+.. >> 0130: 23 6D 45 DF 13 52 A4 4E 28 D3 30 99 5A 81 AD 8C #mE..R.N(.0.Z... >> 0140: DB 15 55 B7 6D 5F 44 89 09 35 66 C8 2F 47 56 14 ..U.m_D..5f./GV. >> 0150: B5 B2 46 AE CE 5D DC A0 C8 59 08 89 6F 5B DB F2 ..F..]...Y..o[.. >> 0160: D8 69 E3 C1 80 44 F6 DA 46 ED 1D 20 80 12 3F 81 .i...D..F.. ..?. >> 0170: 95 27 F6 EB 9F B5 AC DC 72 01 70 46 18 67 1C 08 .'......r.pF.g.. >> 0180: AC C4 6D CA 80 48 12 87 3A 05 69 EA 92 EA 95 00 ..m..H..:.i..... >> 0190: 1F B9 2C BA 83 F3 B3 1B 37 1E B3 7C D7 46 B1 AE ..,.....7....F.. >> 01A0: D4 DD E9 04 8C C0 23 00 96 E3 6F 67 E7 66 65 61 ......#...og.fea >> 01B0: F6 11 D2 7A FE 44 42 83 9D 1A CF 20 80 EC 58 04 ...z.DB.... ..X. >> 01C0: A6 10 78 41 7B 34 C3 FA FD 2A 08 94 72 2F 3D AE ..xA.4...*..r/=. >> 01D0: B0 58 16 63 EE DA 81 42 44 DB 21 C7 23 69 93 BB .X.c...BD.!.#i.. >> 01E0: 64 40 16 78 01 8A 52 57 94 C0 AD 57 04 F4 C4 6B d at .x..RW...W...k >> 01F0: 90 C6 46 C7 02 03 01 00 01 30 0D 06 09 2A 86 48 ..F......0...*.H >> 0200: 86 F7 0D 01 01 0B 05 00 03 82 01 01 00 4B FC 37 .............K.7 >> 0210: B5 E6 F2 A6 98 D8 58 2B 39 CE 8F 6B 51 93 80 0F ......X+9..kQ... >> 0220: 80 39 BD DA 53 7D D3 1B 00 11 F3 A7 FE 9C B7 FA .9..S........... >> 0230: 05 23 DA A2 17 10 7C E7 89 89 DE C5 90 5B 98 22 .#...........[." >> 0240: 7B 97 97 EA 2A B3 E4 6A 33 F8 FC 47 41 39 06 E1 ....*..j3..GA9.. >> 0250: 98 63 6C 0E 2A 92 FF 3D B1 62 D7 27 FF 2B 2B DF .cl.*..=.b.'.++. >> 0260: B7 B2 95 87 C7 B5 21 45 1E 73 F8 B5 0D D6 13 0C ......!E.s...... >> 0270: 1D 25 35 6B D7 5F 18 DF 30 A1 8B 72 DD C6 31 B1 .%5k._..0..r..1. >> 0280: 07 2A F2 DF 1F 1E 36 23 0C FF F9 FB DA E8 B5 2B .*....6#.......+ >> 0290: 3B 8B B6 4C 37 EF D3 27 07 B9 1E D4 64 4B 82 D4 ;..L7..'....dK.. >> 02A0: 32 78 C6 D1 61 6E 9A BF 41 10 23 0B 27 CD C7 77 2x..an..A.#.'..w >> 02B0: 03 73 B2 F6 12 D2 56 9C 29 A2 BD 31 40 F6 5F 0C .s....V.)..1 at ._. >> 02C0: 17 56 4F 30 34 95 77 87 9C 43 B0 74 C5 92 05 43 .VO04.w..C.t...C >> 02D0: 97 12 48 5B 7B 58 66 89 0A C1 8C CD 89 14 E0 5A ..H[.Xf........Z >> 02E0: 78 23 29 10 71 6C 5D 94 D5 FB C0 96 51 C1 0D 93 x#).ql].....Q... >> 02F0: 64 91 45 82 5A 53 88 56 5D 7A AE 88 E8 07 7D 02 d.E.ZS.V]z...... >> 0300: 7D 44 9D CA 73 E5 6F 14 27 8B 6F 86 6C 00 00 .D..s.o.'.o.l.. >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 CEST|CertificateMessage.java:1148|Consuming server Certificate handshake message ( >> "Certificate": { >> "certificate_request_context": "", >> "certificate_list": [ >> { >> "certificate" : { >> "version" : "v3", >> "serial number" : "20 C3 8D C4 49 66 D0 02", >> "signature algorithm": "SHA256withRSA", >> "issuer" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >> "not before" : "2013-08-02 09:51:36.000 CEST", >> "not after" : "10000-01-01 24:59:59.000 CET", >> "subject" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >> "subject public key" : "RSA"} >> "extensions": { >> >> } >> }, >> ] >> } >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 CEST|SSLExtensions.java:148|Ignore unavailable extension: status_request >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: 17 03 03 01 19 ..... >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 281 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: DE 53 C0 74 78 C3 82 0D E8 46 C0 0A F4 56 6E 6B .S.tx....F...Vnk >> 0010: B5 39 77 41 20 21 BA 07 99 2B BF 8D 0A 41 C9 B8 .9wA !...+...A.. >> 0020: BC 0F C1 8E C5 76 36 F0 7A B6 9A F8 38 4D 4D 4D .....v6.z...8MMM >> 0030: 70 33 BE 8F 8C ED BE BC 60 49 B8 41 65 E9 04 D9 p3......`I.Ae... >> 0040: 45 43 AA 41 6D F7 67 7B 03 6D FF E0 4D 76 53 CE EC.Am.g..m..MvS. >> 0050: C1 73 3E 1C CD 87 40 B7 25 56 54 0C 3E CA D7 1D .s>... at .%VT.>... >> 0060: 45 80 41 E8 36 B7 FC 57 38 BB 21 EB E7 EA 19 A1 E.A.6..W8.!..... >> 0070: 39 25 B0 44 8B FD 30 87 86 7A 47 03 C1 02 AC FD 9%.D..0..zG..... >> 0080: 67 89 4B 27 34 04 20 AE 91 65 7C 8C 4A 58 C5 77 g.K'4. ..e..JX.w >> 0090: 46 2E DD A8 23 CA 5C 28 49 25 23 3D 8A 93 B9 10 F...#.\(I%#=.... >> 00A0: 24 0D DE DC 98 AC AA B0 CB 51 80 D7 F8 E7 20 23 $........Q.... # >> 00B0: 41 64 A6 44 93 A7 E1 A7 91 62 4F 3A 73 F6 24 04 Ad.D.....bO:s.$. >> 00C0: C3 E8 25 65 37 D9 1B 7A 65 AE DE C6 29 67 2E C1 ..%e7..ze...)g.. >> 00D0: F7 4C 5C 18 D7 14 98 90 ED 9D AD F5 98 A7 FD 93 .L\............. >> 00E0: 53 F4 B5 90 C9 CB FD 54 8E 5F 53 23 E3 73 94 BD S......T._S#.s.. >> 00F0: A4 07 B7 E3 C7 83 7B 17 CF 51 4A 9E 9C 05 3C 51 .........QJ...> 0100: 4D C7 A1 7A D6 4D A6 58 E5 3A D4 12 B9 B9 46 9C M..z.M.X.:....F. >> 0110: AB 1D C5 6B F9 6A 85 CB E2 ...k.j... >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.758 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 281 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.758 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >> 0000: 0F 00 01 04 08 04 01 00 30 11 28 CE 64 4E 08 BA ........0.(.dN.. >> 0010: A1 BE 46 D9 3D 14 29 1A EB 5A B0 1A 09 B7 11 A5 ..F.=.)..Z...... >> 0020: 9A F4 22 17 87 5F 87 D5 63 04 8E 27 EC 3A F8 52 ..".._..c..'.:.R >> 0030: 36 F4 2F CF 47 D2 5C CE 0A F0 29 EF 63 03 B1 64 6./.G.\...).c..d >> 0040: B8 45 6E 39 71 E3 BD 25 95 31 25 85 4C FB C6 AD .En9q..%.1%.L... >> 0050: C8 43 96 4E FA AD B9 98 17 43 61 FB 9B 87 CE 94 .C.N.....Ca..... >> 0060: CF 74 6F 3B AA 6A C8 80 8F C7 C8 05 E4 EF 42 6C .to;.j........Bl >> 0070: D4 01 9E 25 5E 34 E8 2D 93 BD BB 05 49 2F 9D B6 ...%^4.-....I/.. >> 0080: F6 91 2F D1 E5 CB 1B 9E F6 DB 18 32 1D F5 66 A0 ../........2..f. >> 0090: 63 5D 25 01 B6 F6 1B 41 07 3E 90 61 37 49 38 17 c]%....A.>.a7I8. >> 00A0: B0 15 C9 AD 0C 7A 05 8D B4 48 BB 03 2D DE 5E 49 .....z...H..-.^I >> 00B0: 99 8B 74 53 5F 73 9B 18 FD 95 2A C3 F9 A3 8B 59 ..tS_s....*....Y >> 00C0: 1A ED 2C 55 C2 22 10 1E 7A FC 38 0A 99 FC 30 89 ..,U."..z.8...0. >> 00D0: 03 89 1C CD A7 DE E5 35 FD E9 E0 05 96 09 AF DD .......5........ >> 00E0: 51 A3 7F C7 16 C5 96 8D CA CC 53 50 DC C5 C6 BA Q.........SP.... >> 00F0: D6 05 28 18 BA 99 F8 0F 7F 24 9F D5 6B 93 DE BC ..(......$..k... >> 0100: EB 23 85 D9 D3 41 56 44 .#...AVD >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 CEST|CertificateVerify.java:1128|Consuming CertificateVerify handshake message ( >> "CertificateVerify": { >> "signature algorithm": rsa_pss_rsae_sha256 >> "signature": { >> 0000: 30 11 28 CE 64 4E 08 BA A1 BE 46 D9 3D 14 29 1A 0.(.dN....F.=.). >> 0010: EB 5A B0 1A 09 B7 11 A5 9A F4 22 17 87 5F 87 D5 .Z........".._.. >> 0020: 63 04 8E 27 EC 3A F8 52 36 F4 2F CF 47 D2 5C CE c..'.:.R6./.G.\. >> 0030: 0A F0 29 EF 63 03 B1 64 B8 45 6E 39 71 E3 BD 25 ..).c..d.En9q..% >> 0040: 95 31 25 85 4C FB C6 AD C8 43 96 4E FA AD B9 98 .1%.L....C.N.... >> 0050: 17 43 61 FB 9B 87 CE 94 CF 74 6F 3B AA 6A C8 80 .Ca......to;.j.. >> 0060: 8F C7 C8 05 E4 EF 42 6C D4 01 9E 25 5E 34 E8 2D ......Bl...%^4.- >> 0070: 93 BD BB 05 49 2F 9D B6 F6 91 2F D1 E5 CB 1B 9E ....I/..../..... >> 0080: F6 DB 18 32 1D F5 66 A0 63 5D 25 01 B6 F6 1B 41 ...2..f.c]%....A >> 0090: 07 3E 90 61 37 49 38 17 B0 15 C9 AD 0C 7A 05 8D .>.a7I8......z.. >> 00A0: B4 48 BB 03 2D DE 5E 49 99 8B 74 53 5F 73 9B 18 .H..-.^I..tS_s.. >> 00B0: FD 95 2A C3 F9 A3 8B 59 1A ED 2C 55 C2 22 10 1E ..*....Y..,U.".. >> 00C0: 7A FC 38 0A 99 FC 30 89 03 89 1C CD A7 DE E5 35 z.8...0........5 >> 00D0: FD E9 E0 05 96 09 AF DD 51 A3 7F C7 16 C5 96 8D ........Q....... >> 00E0: CA CC 53 50 DC C5 C6 BA D6 05 28 18 BA 99 F8 0F ..SP......(..... >> 00F0: 7F 24 9F D5 6B 93 DE BC EB 23 85 D9 D3 41 56 44 .$..k....#...AVD >> } >> } >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: 17 03 03 00 35 ....5 >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 53 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: F6 A7 CD EA 89 34 B2 DB C4 28 91 18 C9 03 98 B6 .....4...(...... >> 0010: DF 49 4E F5 2E 23 32 90 F8 13 C7 AE 18 E3 E5 64 .IN..#2........d >> 0020: D9 E4 A5 B0 5C F0 4A 3E AF EC 28 8D 09 78 AB EE ....\.J>..(..x.. >> 0030: 38 1B 9E 45 04 8..E. >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 53 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >> 0000: 14 00 00 20 F2 93 6B 71 2B FA F3 1B BF 68 98 D1 ... ..kq+....h.. >> 0010: AA 5E B0 AF 5D 3B A6 B5 8F 79 BA 64 E8 A1 34 5F .^..];...y.d..4_ >> 0020: D4 2B ED 8C .+.. >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.764 CEST|Finished.java:860|Consuming server Finished handshake message ( >> "Finished": { >> "verify data": { >> 0000: F2 93 6B 71 2B FA F3 1B BF 68 98 D1 AA 5E B0 AF ..kq+....h...^.. >> 0010: 5D 3B A6 B5 8F 79 BA 64 E8 A1 34 5F D4 2B ED 8C ];...y.d..4_.+.. >> }'} >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.765 CEST|SSLCipher.java:1824|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE >> countdown value = 137438953472 >> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.765 CEST|CertificateMessage.java:1015|No signature_algorithms(_cert) in ClientHello >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|CertificateMessage.java:1081|No available client authentication scheme >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|CertificateMessage.java:1116|Produced client Certificate message ( >> "Certificate": { >> "certificate_request_context": "", >> "certificate_list": [ >> ] >> } >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 8 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( >> 0000: 0B 00 00 04 00 00 00 00 16 00 00 00 00 00 00 00 ................ >> 0010: 00 00 00 00 00 00 00 00 00 ......... >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 CEST|SSLSocketOutputRecord.java:255|Raw write ( >> 0000: 17 03 03 00 29 E5 32 E4 5B 13 E7 D4 A1 78 FE 38 ....).2.[....x.8 >> 0010: 26 22 CB C1 04 88 3A 3A 2D D4 A1 31 5A 78 65 50 &"....::-..1ZxeP >> 0020: 51 45 67 FA 9F 55 35 E1 49 C5 3B 3B 91 B1 QEg..U5.I.;;.. >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 CEST|CertificateVerify.java:1059|No X.509 credentials negotiated for CertificateVerify >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 CEST|Finished.java:658|Produced client Finished handshake message ( >> "Finished": { >> "verify data": { >> 0000: D8 47 0B A0 DF BB BF 49 E4 55 B9 D3 FB 3D B0 DD .G.....I.U...=.. >> 0010: 57 1E 08 28 20 7E E1 0B E3 EB 12 10 09 76 D1 8F W..( ........v.. >> }'} >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 36 >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( >> 0000: 14 00 00 20 D8 47 0B A0 DF BB BF 49 E4 55 B9 D3 ... .G.....I.U.. >> 0010: FB 3D B0 DD 57 1E 08 28 20 7E E1 0B E3 EB 12 10 .=..W..( ....... >> 0020: 09 76 D1 8F 16 00 00 00 00 00 00 00 00 00 00 00 .v.............. >> 0030: 00 00 00 00 00 ..... >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 CEST|SSLSocketOutputRecord.java:255|Raw write ( >> 0000: 17 03 03 00 45 0F 4D 84 52 28 59 96 92 52 D1 AB ....E.M.R(Y..R.. >> 0010: DB 86 64 25 31 FF 9D 8E D7 84 63 B5 03 E2 9E 06 ..d%1.....c..... >> 0020: 3C 8C C2 22 F3 7A EE 55 AD 8C F5 5C F6 04 9A E2 <..".z.U...\.... >> 0030: 6D BA E4 C4 9F 97 C3 DA BC D3 CB 8C 2C 9E BF FD m...........,... >> 0040: A3 9F C1 A2 79 51 75 B7 AE B6 ....yQu... >> ) >> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.770 CEST|SSLCipher.java:1978|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE >> countdown value = 137438953472 >> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: 17 03 03 00 13 ..... >> ) >> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 19 >> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:458|Raw read ( >> 0000: 4F 0D C7 65 8B 24 B4 92 A2 26 31 8C 81 AF 8F F7 O..e.$...&1..... >> 0010: AC C3 B3 ... >> ) >> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 19 >> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.773 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >> 0000: 02 74 .t >> ) >> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.774 CEST|Alert.java:232|Received alert message ( >> "Alert": { >> "level" : "fatal", >> "description": "certificate_required" >> } >> ) >> javax.net.ssl|ERROR|0C|Thread-0|2018-09-17 11:51:54.774 CEST|TransportContext.java:313|Fatal (CERTIFICATE_REQUIRED): Received fatal alert: certificate_required ( >> "throwable" : { >> javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_required >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >> at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >> at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >> at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) >> at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) >> at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) >> at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) >> at ReproducerClient$1.run(ReproducerClient.java:33) >> at java.base/java.lang.Thread.run(Thread.java:834)} >> ) >> javax.net.ssl|ALL|0C|Thread-0|2018-09-17 11:51:54.775 CEST|SSLSessionImpl.java:753|Invalidated session: Session(1537177914725|TLS_AES_128_GCM_SHA256) >> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 CEST|SSLSocketImpl.java:1361|close the underlying socket >> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 CEST|SSLSocketImpl.java:1380|close the SSL connection (initiative) >> javax.net.ssl|WARNING|0C|Thread-0|2018-09-17 11:51:54.777 CEST|SSLSocketImpl.java:1289|handling exception ( >> "throwable" : { >> javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_required >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >> at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >> at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >> at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) >> at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) >> at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) >> at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) >> at ReproducerClient$1.run(ReproducerClient.java:33) >> at java.base/java.lang.Thread.run(Thread.java:834)} >> ) >> Bye >> Norman >>> On 16. Sep 2018, at 15:54, Norman Maurer >> wrote: >>> >>> Will do, but not before tomorrow (I will also share the client side code). That said there is nothing special about the keymanager. >>> Like I said before it sends the cert when using ?want client with?, it just seems it may be too late. >>> >>> >>> Bye >>> Norman >>> >>>> Am 15.09.2018 um 08:26 schrieb Bradford Wetmore >>: >>>> >>>> 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)) >>>>>>>> 0000 - 16 03 03 01 60 ....` >>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160)) >>>>>>>> 0000 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 ...\..".... at 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..o....K...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)) >>>>>>>> 0000 - 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|J....n....] >>>>>>>> 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..o....K.. >>>>>>>> 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 MT....B5S[...... >>>>>>>> 00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65 .(.m...8.wrs%&.e >>>>>>>> 00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96 X........P...... >>>>>>>> 0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9 .;<..AX...:(..a. >>>>>>>> 0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5 .h...f.[..... .. >>>>>>>> 0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb .RD...c=........ >>>>>>>> 0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6 .*O[J.wx.u. .... >>>>>>>> 0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee ...VV._.e.~n=.f. >>>>>>>> 0150 - 10 4c f7 6d 9b 73 86 14-7a 81 f8 b1 27 af 08 ee .L.m.s..z...'... >>>>>>>> 0160 - ce 26 90 34 73 3d b7 45-8d 85 29 a8 65 19 e7 02 .&.4s=.E..).e... >>>>>>>> 0170 - e5 55 4a 27 f1 b1 6a a4-11 cc 6c af 78 6d 22 5c .UJ'..j...l.xm"\ >>>>>>>> 0180 - 33 73 e3 ad 7f 8d 1b d3-75 95 66 64 2d 0e f1 3e 3s......u.fd-..> >>>>>>>> 0190 - c2 30 df a1 7e ce a3 50-c3 4e 68 f6 36 b3 4e 45 .0..~..P.Nh.6.NE >>>>>>>> 01a0 - 9c ac e9 f2 0d 7c e3 73-6a 40 ab 6e 6e f9 d8 20 .....|.sj at .nn.. >>>>>>>> 01b0 - 9c f3 04 32 cd 1d df 18-e5 4d e3 e8 b1 38 59 f8 ...2.....M...8Y. >>>>>>>> 01c0 - 28 67 2e ca af a2 8b 88-ce ca 48 a6 07 2b a6 9a (g........H..+.. >>>>>>>> 01d0 - 0e 88 5b d7 0b d9 31 77-97 8d 6c 2b f5 60 24 61 ..[...1w..l+.`$a >>>>>>>> 01e0 - a8 5c 47 5d 7c 66 f0 9b-1f e4 76 93 38 f6 78 3e .\G]|f....v.8.x> >>>>>>>> 01f0 - 69 29 72 f9 d9 4b cb 05-03 e4 f2 d6 24 e1 91 ee i)r..K......$... >>>>>>>> 0200 - 85 37 d7 7b c3 5c 35 90-08 cd b1 cc 76 11 fc 00 .7.{.\5.....v... >>>>>>>> 0210 - 12 7e 89 7b 70 e6 ca fe-0b 26 b6 bb ac fe 4b 9f .~.{p....&....K. >>>>>>>> 0220 - ec cf 41 69 42 3a 3e 41-f9 b0 c0 93 5b 70 1f c7 ..AiB:>A....[p.. >>>>>>>> 0230 - 11 00 3d ec 66 5a 1a ca-31 89 22 27 02 dd a0 cb ..=.fZ..1."'.... >>>>>>>> 0240 - 39 14 25 ee 30 44 e8 62-97 bf 8e 16 63 40 c4 11 9.%.0D.b....c at .. >>>>>>>> 0250 - a6 d9 32 b1 3c 86 35 bb-9f f1 4d 71 9f a5 4f 78 ..2.<.5...Mq..Ox >>>>>>>> 0260 - 0a e8 96 dd 4d 10 c3 48-f2 db 67 57 2d cd dc 23 ....M..H..gW-..# >>>>>>>> 0270 - 3a 8d 6a 61 47 20 ff c8-33 cd e9 f7 47 4c 68 4f :.jaG ..3...GLhO >>>>>>>> 0280 - 19 2f 8b e3 b1 90 ac 66-a7 cf 5c e6 d2 05 21 25 ./.....f..\...!% >>>>>>>> 0290 - d2 d8 f0 43 8c 55 01 ef-d6 8f c0 27 87 0d 21 d5 ...C.U.....'..!. >>>>>>>> 02a0 - 2b 2b 6f db e8 85 ea cd-6e 9c 5d 56 d5 31 c1 f2 ++o.....n.]V.1.. >>>>>>>> 02b0 - 97 2f 5a 83 7a 2b 71 03-65 e0 b6 4a 56 37 de e1 ./Z.z+q.e..JV7.. >>>>>>>> 02c0 - 80 3a c4 cc 5a ac 3b 9a-7a bf f7 6b fe a8 69 e9 .:..Z.;.z..k..i. >>>>>>>> 02d0 - 58 09 59 bd 46 bd d2 a3-bc ad 1c 10 53 c8 29 7b X.Y.F.......S.){ >>>>>>>> 02e0 - be 63 00 d6 e5 a8 d6 ab-b2 bc 8b e1 2c 0e 24 2a .c..........,.$* >>>>>>>> 02f0 - c2 31 2d d8 6e 1f 19 93-d7 54 e1 1e 28 ce 72 83 .1-.n....T..(.r. >>>>>>>> 0300 - ff 05 18 f2 fc e9 0c b3-0c 1b d5 96 c2 d8 fc 76 ...............v >>>>>>>> 0310 - 37 a9 5a ef 8e e9 b6 71-21 f3 bd c1 85 23 85 22 7.Z....q!....#." >>>>>>>> 0320 - 3d c4 1c c9 31 8b 7e 00-8f 8e b4 9f 05 d4 80 6b =...1.~........k >>>>>>>> 0330 - 98 4c a8 82 68 ff 1a a5-28 e2 9b 03 a1 a7 b1 00 .L..h...(....... >>>>>>>> 0340 - 02 2b 2d e2 e1 87 8c e8-0a fb 0b 79 54 ca 3d d5 .+-........yT.=. >>>>>>>> 0350 - 6a dd b7 b7 87 42 2b 47-49 da e9 0a 82 0a c9 8f j....B+GI....... >>>>>>>> 0360 - 57 f7 1e 03 ca 8d 16 bc-21 3a 6a ee b9 b8 fa f0 W.......!:j..... >>>>>>>> 0370 - d9 18 35 9f 35 ac d8 6e-9a 8a 0d 56 10 1e 1f 5a ..5.5..n...V...Z >>>>>>>> 0380 - ba ec e4 fe 1a 92 b4 31-35 43 1d 99 b9 12 fa ff .......15C...... >>>>>>>> 0390 - 99 2b 88 e0 58 ec 9c dc-8f 67 ef 2a c2 e2 64 5d .+..X....g.*..d] >>>>>>>> 03a0 - 66 76 1c d0 aa 00 30 59-b1 f5 b1 55 9f ad 60 e9 fv....0Y...U..`. >>>>>>>> 03b0 - 3d 03 1e d0 8b 4d bf 74-ac bc bb 1c 83 14 c5 e0 =....M.t........ >>>>>>>> 03c0 - f4 fc 70 9e f4 22 a0 78-04 fe c8 b1 17 65 f6 94 ..p..".x.....e.. >>>>>>>> 03d0 - 47 82 50 4a b6 32 74 ae-5b 38 5a 2e d9 b0 6a 45 G.PJ.2t.[8Z...jE >>>>>>>> 03e0 - 74 e8 f0 22 fe d3 b0 11-c3 fd 72 4f da 77 7a ba t.."......rO.wz. >>>>>>>> 03f0 - 26 3e 61 0c 63 21 17 a6-b2 13 6e 71 5c f2 0d ad &>a.c!....nq\... >>>>>>>> 0400 - f2 d1 19 71 51 9e a4 1b-b0 30 24 e0 71 7d 87 80 ...qQ....0$.q}.. >>>>>>>> 0410 - a9 5a e9 bc db e4 4f 50-4d a1 bc bc 2c 4b 66 98 .Z....OPM...,Kf. >>>>>>>> 0420 - d4 e4 b0 76 0f d2 db a5-a5 39 9e f2 5b ea 34 c1 ...v.....9..[.4. >>>>>>>> 0430 - 62 ab 47 51 3b 37 17 45-54 31 18 f3 f1 ca 17 03 b.GQ;7.ET1...... >>>>>>>> 0440 - 03 01 19 dd 50 50 f5 0c-f2 c9 3c b4 8f 63 cc 4a ....PP....<..c.J >>>>>>>> 0450 - a7 50 c9 91 9b 79 9a 2a-5c 47 d3 77 f6 56 69 90 .P...y.*\G.w.Vi. >>>>>>>> 0460 - 98 cd ff bd c1 2a 49 fc-0d d4 7e cc 7e 44 af c4 .....*I...~.~D.. >>>>>>>> 0470 - 61 47 e0 c1 76 b1 8c 2e-df 7e d0 82 e1 89 1f 04 aG..v....~...... >>>>>>>> 0480 - ae 64 bd 71 4d ae 1c 3c-e3 d3 39 5d 61 2a ea 70 .d.qM..<..9]a*.p >>>>>>>> 0490 - 8c 31 6d a0 b1 72 a8 7a-5c 9c 11 08 b8 4d a5 c4 .1m..r.z\....M.. >>>>>>>> 04a0 - ad 1b 38 4a 6a 02 28 d4-d1 0f c8 9f 0b b3 02 18 ..8Jj.(......... >>>>>>>> 04b0 - 82 2b bd 46 82 04 64 f0-41 b2 da f5 cd 9c f7 f3 .+.F..d.A....... >>>>>>>> 04c0 - 73 30 58 ca 12 ec ea 90-85 1c 75 09 0a 70 b8 80 s0X.......u..p.. >>>>>>>> 04d0 - 3d 02 17 3e 9b 83 04 b5-dd 9e e6 18 17 65 83 a5 =..>.........e.. >>>>>>>> 04e0 - 59 7d 4b 98 da bd 8b aa-d6 aa c5 1c 7d 87 56 e3 Y}K.........}.V. >>>>>>>> 04f0 - 74 d8 e9 7b eb b3 3d f7-7c 3c 0a e9 a8 2e 04 0d t..{..=.|<...... >>>>>>>> 0500 - 6a e7 83 e0 ec 99 43 6a-8b 1c 73 59 7a c8 cd 6e j.....Cj..sYz..n >>>>>>>> 0510 - 4a 14 73 ff 9a fb 71 94-d5 50 a9 d9 e0 dd 02 4c J.s...q..P.....L >>>>>>>> 0520 - 2b 67 9e da 9e fa 2d 67-49 df 13 10 ed 35 3e 73 +g....-gI....5>s >>>>>>>> 0530 - 07 20 17 fb 0b ef f6 d0-b7 68 1c 65 21 a6 e3 3b . .......h.e!..; >>>>>>>> 0540 - bf 7b 84 cd 9e f5 76 2a-0d 4f b8 c3 c8 15 08 e9 .{....v*.O...... >>>>>>>> 0550 - 0f 3c 50 49 12 97 a8 d7-f1 a3 16 da 17 03 03 00 .>>>>>>> 0560 - 35 22 dd a2 9d 25 98 2c-35 b8 00 29 fa a1 dd ba 5"...%.,5..).... >>>>>>>> 0570 - 72 b9 fe e5 85 85 f0 f1-3b 4e f5 7c 58 c8 2a da r.......;N.|X.*. >>>>>>>> 0580 - d2 75 94 3b c1 7a 7c 7e-db 5b fe 8a 2d 3f 8c 9a .u.;.z|~.[..-?.. >>>>>>>> 0590 - 6e 79 ab 2b ff 1a ny.+.. >>>>>>>> SSL_accept:SSLv3/TLS write finished >>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>>>> 0000 - 14 03 03 00 01 ..... >>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (1 bytes => 1 (0x1)) >>>>>>>> 0000 - 01 . >>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>>>> 0000 - 17 03 03 00 3d ....= >>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (61 bytes => 61 (0x3D)) >>>>>>>> 0000 - 38 e7 bb 2c 5b af b6 5f-37 d8 3e 7e bb f4 04 f5 8..,[.._7.>~.... >>>>>>>> 0010 - e1 28 b5 e5 07 5a ec ce-da 2f f3 b6 45 61 cf ef .(...Z.../..Ea.. >>>>>>>> 0020 - 90 fb 57 b8 f3 20 45 27-60 d4 26 51 38 77 e4 bc ..W.. E'`.&Q8w.. >>>>>>>> 0030 - b7 64 d4 8b 73 25 41 9e-fe d3 9d 5f 53 .d..s%A...._S >>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>> write to 0x7fe400f050c0 [0x7fe403018a00] (24 bytes => 24 (0x18)) >>>>>>>> 0000 - 17 03 03 00 13 25 85 60-eb 7d c1 a8 15 49 d5 63 .....%.`.}...I.c >>>>>>>> 0010 - 18 7f c6 ac ed 7f df 77- .......w >>>>>>>> SSL3 alert write:fatal:unknown >>>>>>>> SSL_accept:error in error >>>>>>>> ERROR >>>>>>>> 140736092021632:error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate:ssl/statem/statem_srvr.c:3654: >>>>>>>> shutting down SSL >>>>>>>> CONNECTION CLOSED >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> When using openssl s_client all works as expected tho (thats also true if I use my native implementation on the client and server side that uses openssl): >>>>>>>> >>>>>>>> ./bin/openssl s_client -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 -state -tls1_3 -connect localhost:8443 >>>>>>>> >>>>>>>> The interesting thing is if I use ?-verify 1? and not ?-Verify 1? with openssl which tells it I want to request a certificate but will also process if none is provided I receive the certificate at some point as seen here: >>>>>>>> >>>>>>>> SSL_accept:before SSL initialization >>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>> 0000 - 16 03 03 01 60 ....` >>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (352 bytes => 352 (0x160)) >>>>>>>> 0000 - 01 00 01 5c 03 03 61 c0-b3 ed 88 65 e6 cf 11 3f ...\..a....e...? >>>>>>>> 0010 - c0 e0 f8 df a6 63 32 c2-ab 3d 61 6f 41 ed b1 4b .....c2..=aoA..K >>>>>>>> 0020 - 53 0e 83 e5 a1 b8 20 c7-1b 8c b8 e6 b5 da 4e 4e S..... .......NN >>>>>>>> 0030 - 3f 3c 61 7a ad 58 23 94-a7 32 79 2f db 9f 21 c0 ?>>>>>>> 0040 - 8e 0c c5 ce b1 c2 a4 00-14 c0 2c c0 2b c0 2f c0 ..........,.+./. >>>>>>>> 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 52 dc d6 47 6e .3.G.E...A.R..Gn >>>>>>>> 0120 - a1 de 9c 71 c2 54 0e 5c-9b 57 fb c8 aa 3f 19 f7 ...q.T.\.W...?.. >>>>>>>> 0130 - d3 a4 25 12 fa 3f 6c 6d-95 30 66 ca 63 b7 a1 dd ..%..?lm.0f.c... >>>>>>>> 0140 - ae 9f 99 d6 a8 6b 20 4f-29 7a 74 58 ad 58 de 12 .....k O)ztX.X.. >>>>>>>> 0150 - d7 a5 9b 69 dc 27 ac ec-9e d4 04 ff 01 00 01 00 ...i.'.......... >>>>>>>> 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 0x7fdc58809fb0 [0x7fdc59025e00] (1430 bytes => 1430 (0x596)) >>>>>>>> 0000 - 16 03 03 00 9b 02 00 00-97 03 03 8b c8 62 48 6c .............bHl >>>>>>>> 0010 - f5 7c 73 d9 17 f8 63 a2-11 27 40 93 09 26 53 06 .|s...c..'@..&S. >>>>>>>> 0020 - b3 62 df 46 26 b6 dc 59-29 b5 58 20 c7 1b 8c b8 .b.F&..Y).X .... >>>>>>>> 0030 - e6 b5 da 4e 4e 3f 3c 61-7a ad 58 23 94 a7 32 79 ...NN?>>>>>>> 0040 - 2f db 9f 21 c0 8e 0c c5-ce b1 c2 a4 13 01 00 00 /..!............ >>>>>>>> 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 O.+.....3.E...A. >>>>>>>> 0060 - 07 63 1c 19 53 89 68 a8-0f ea 9e 4c 18 6f 2a ad .c..S.h....L.o*. >>>>>>>> 0070 - 2a df eb 17 a2 08 94 c6-e3 c5 97 ae 0f c1 1a d7 *............... >>>>>>>> 0080 - 0d d7 2e 6d 77 3d 30 a0-07 db 70 35 bb 37 dd 1e ...mw=0...p5.7.. >>>>>>>> 0090 - b6 f3 4d cb 13 97 7c 11-63 98 e8 64 2d a7 e6 cc ..M...|.c..d-... >>>>>>>> 00a0 - 14 03 03 00 01 01 17 03-03 00 27 a3 73 d2 ee 2c ..........'.s.., >>>>>>>> 00b0 - 2f 9c 8f 95 7f ca a3 89-bc b4 b3 b2 3c 8b 23 ef /...........<.#. >>>>>>>> 00c0 - 36 66 23 c9 09 02 33 0d-dc 5d 36 61 44 89 8b ef 6f#...3..]6aD... >>>>>>>> 00d0 - fd 13 17 03 03 00 42 f2-5b 3c 0c 27 5e 7f 97 4f ......B.[<.'^..O >>>>>>>> 00e0 - 0f de 8c b9 0a a1 41 c7-c2 1e 92 99 6a d5 bd 12 ......A.....j... >>>>>>>> 00f0 - 38 b6 b7 93 33 e9 8e 0f-44 93 f0 69 58 b6 41 22 8...3...D..iX.A" >>>>>>>> 0100 - 46 e2 4a d5 d6 32 2b b8-a7 ae 3a c2 c5 2f e6 35 F.J..2+...:../.5 >>>>>>>> 0110 - 11 0c f1 9a 35 2a 87 ed-9e 17 03 03 03 20 a7 e2 ....5*....... .. >>>>>>>> 0120 - fe ba c7 10 5b 9c cd 94-67 19 37 2d 46 59 ab 56 ....[...g.7-FY.V >>>>>>>> 0130 - 6b dd a4 10 61 cc ed f1-71 a7 2d 6a 41 2e 2b da k...a...q.-jA.+. >>>>>>>> 0140 - d1 35 fc 01 df 49 e5 90-1d 9b b2 03 0a 81 58 18 .5...I........X. >>>>>>>> 0150 - 96 a1 db 31 19 98 35 5c-87 8f 6e 32 0a e6 c0 aa ...1..5\..n2.... >>>>>>>> 0160 - 9e 8e 72 e2 34 b3 b7 a3-d6 d1 66 c7 ce 93 fe 78 ..r.4.....f....x >>>>>>>> 0170 - 17 c4 71 7c 42 15 c8 af-dc 4f 50 42 51 80 fc bf ..q|B....OPBQ... >>>>>>>> 0180 - fc 54 d5 d8 59 20 9a 90-c4 78 97 9c 2d 4a d5 58 .T..Y ...x..-J.X >>>>>>>> 0190 - be 81 79 23 59 22 9d 27-f8 bd a0 b2 98 b3 47 82 ..y#Y".'......G. >>>>>>>> 01a0 - d3 52 b5 b5 91 ab 5c 76-52 c5 a5 95 2d 03 1c b7 .R....\vR...-... >>>>>>>> 01b0 - 64 4d 0b 88 7f 15 0b c8-a8 90 50 9a b6 b1 9f b7 dM........P..... >>>>>>>> 01c0 - 40 09 f2 5f 39 f8 9a 06-21 4d 67 10 0a 67 08 b6 @.._9...!Mg..g.. >>>>>>>> 01d0 - b5 9a 25 8c d5 ca 31 6a-8a 6b 01 93 7d 6f 1e 52 ..%...1j.k..}o.R >>>>>>>> 01e0 - 98 96 9d fb e8 c1 07 ab-57 98 2d 1e 75 77 ef c2 ........W.-.uw.. >>>>>>>> 01f0 - 49 78 e0 b9 2b 32 23 7e-95 4d 3e 27 00 61 86 0c Ix..+2#~.M>'.a.. >>>>>>>> 0200 - 47 c7 79 e4 ee 9d ba c0-ea 62 f1 0d 8e 4a 91 30 G.y......b...J.0 >>>>>>>> 0210 - bc 4f 5a 98 26 30 66 ec-c4 63 8f 28 d5 1c 61 23 .OZ.&0f..c.(..a# >>>>>>>> 0220 - ea e9 90 4e 36 d9 fa 31-7b 14 27 22 0a ae 9f 64 ...N6..1{.'"...d >>>>>>>> 0230 - 40 3d e5 a0 5c 9d 3c 04-71 09 b0 7a 6b 51 a0 9c @=..\.<.q..zkQ.. >>>>>>>> 0240 - c0 61 32 ce 15 62 8e 29-b1 59 91 c0 17 2c b3 c5 .a2..b.).Y...,.. >>>>>>>> 0250 - f9 ed 07 65 3d 11 de 98-de 62 36 50 74 37 af 2d ...e=....b6Pt7.- >>>>>>>> 0260 - 7d 86 55 c4 3e a2 83 ab-47 8d f2 b2 8d 1d 75 83 }.U.>...G.....u. >>>>>>>> 0270 - b5 e4 41 87 a7 a3 85 b0-5e 4e 2e 9c 8c b0 1b 83 ..A.....^N...... >>>>>>>> 0280 - 7b 54 79 c9 60 ea 7d ed-06 fa dd 24 40 f1 53 9e {Ty.`.}....$@.S. >>>>>>>> 0290 - 43 79 25 53 9c c7 6e 95-ab 9f 96 59 cd b9 7b a8 Cy%S..n....Y..{. >>>>>>>> 02a0 - a0 23 13 69 db a9 c9 e7-1a 8e e1 9b 54 94 1c 44 .#.i........T..D >>>>>>>> 02b0 - 50 08 8b dd eb 4e 2b bb-d7 c9 c2 33 8c a1 b3 65 P....N+....3...e >>>>>>>> 02c0 - 06 e6 9d ac 11 16 21 58-40 8d 59 e6 67 e5 31 02 ......!X at .Y.g.1. >>>>>>>> 02d0 - 15 8d 29 80 20 66 ba c3-56 93 95 5c 65 4b 41 00 ..). f..V..\eKA. >>>>>>>> 02e0 - c5 71 12 12 f5 20 4f 59-be 77 06 10 6e 48 85 5c .q... OY.w..nH.\ >>>>>>>> 02f0 - ff a2 c4 ae fb 4d 95 f5-cc f6 61 20 33 b7 92 1d .....M....a 3... >>>>>>>> 0300 - ac a8 f1 b2 b0 88 c6 7b-8b 00 53 30 6d 4a d1 42 .......{..S0mJ.B >>>>>>>> 0310 - b3 3e 85 f5 84 e1 c6 ab-10 9d 61 03 46 ff 2d 81 .>........a.F.-. >>>>>>>> 0320 - 15 4f 84 d1 4c ee f4 a6-a0 ec 50 60 a0 d1 ff df .O..L.....P`.... >>>>>>>> 0330 - 8a 97 f6 7d fb 8f fb 60-18 d4 f1 1f 92 4d d8 69 ...}...`.....M.i >>>>>>>> 0340 - b1 92 97 44 0f 3c 8a aa-47 07 48 d4 07 2d 3e f2 ...D.<..G.H..->. >>>>>>>> 0350 - c4 a7 16 35 a7 17 71 ef-98 84 24 67 12 58 30 3b ...5..q...$g.X0; >>>>>>>> 0360 - 1d 41 8d e5 12 52 95 64-e5 88 35 99 d7 c3 58 40 .A...R.d..5...X@ >>>>>>>> 0370 - f9 55 9b 9f e5 33 15 70-41 d7 45 ba a4 fc 75 ea .U...3.pA.E...u. >>>>>>>> 0380 - a4 ae f0 68 ea 64 d8 f5-06 68 a9 75 22 4d 43 cc ...h.d...h.u"MC. >>>>>>>> 0390 - ff 50 cc ac 6e fd 43 dd-eb e4 c8 dd 4b 6c 12 bb .P..n.C.....Kl.. >>>>>>>> 03a0 - f1 d4 5e 11 4a 86 90 0b-f8 3a 2e 23 db 61 5a 1f ..^.J....:.#.aZ. >>>>>>>> 03b0 - 7e 11 00 92 21 68 1f b5-ab f2 f8 38 5e 62 ea f8 ~...!h.....8^b.. >>>>>>>> 03c0 - da ef c2 6e a0 b8 20 e4-69 49 b3 1f 15 84 0b 9b ...n.. .iI...... >>>>>>>> 03d0 - ce b0 6f 36 32 7f 7e bf-e8 d7 18 7a 58 60 f4 04 ..o62.~....zX`.. >>>>>>>> 03e0 - cc 36 bf 06 cd ec e5 9b-19 03 96 09 fb af 8f c3 .6.............. >>>>>>>> 03f0 - 98 b4 02 aa e8 55 81 aa-c4 fe 06 81 30 a0 c7 b2 .....U......0... >>>>>>>> 0400 - f8 e2 30 00 d7 a0 54 7f-5f d7 ef a6 f8 41 58 34 ..0...T._....AX4 >>>>>>>> 0410 - f5 f0 18 69 8d e6 7a 23-78 90 8f b1 05 c5 b5 7f ...i..z#x....... >>>>>>>> 0420 - e0 f2 c7 fa c8 36 5b 53-7e cf e6 75 d3 54 b4 69 .....6[S~..u.T.i >>>>>>>> 0430 - 68 43 0d 6a d2 83 cc 13-6d ca bf 83 3c 90 17 03 hC.j....m...<... >>>>>>>> 0440 - 03 01 19 96 dc 49 26 ce-1d 8e 86 3d bd cb 00 5e .....I&....=...^ >>>>>>>> 0450 - ee f6 e7 1d 16 7a ca ef-fa 6d 16 40 b6 99 d0 c1 .....z...m. at .... >>>>>>>> 0460 - df 0b 5f 51 60 a8 24 e0-61 82 13 40 da 88 38 3a .._Q`.$.a.. at ..8: >>>>>>>> 0470 - 26 1d 80 51 c4 b1 95 35-95 3c 91 35 28 17 49 d8 &..Q...5.<.5(.I. >>>>>>>> 0480 - c3 45 be 32 98 3e 02 07-3b 01 20 2b 51 e1 1a 94 .E.2.>..;. +Q... >>>>>>>> 0490 - b9 be 96 aa 7a 13 09 ff-d5 a9 63 d4 6f 49 cb b5 ....z.....c.oI.. >>>>>>>> 04a0 - 23 ab 7f 8c e2 63 f0 5c-5c 27 1e 04 a8 71 0c c0 #....c.\\'...q.. >>>>>>>> 04b0 - 89 cd ed 18 8d 5b 75 ac-af f3 68 6d cc ba 20 38 .....[u...hm.. 8 >>>>>>>> 04c0 - b5 7c 09 47 29 28 e2 26-57 57 1f f0 f3 18 fd 6f .|.G)(.&WW.....o >>>>>>>> 04d0 - 27 42 a4 e3 de bb e5 d6-09 7d 25 b1 98 97 ad 33 'B.......}%....3 >>>>>>>> 04e0 - 68 35 92 07 80 23 f1 66-20 5d 74 f3 02 c5 51 ff h5...#.f ]t...Q. >>>>>>>> 04f0 - 07 a9 e9 0e 3e 74 da 2e-8f 3b 16 be e6 94 1b 66 ....>t...;.....f >>>>>>>> 0500 - bb b2 a2 1e 7c 7b ff 5e-a4 36 2a ba 0b cd 7f e9 ....|{.^.6*..... >>>>>>>> 0510 - 86 bb 5e 30 f5 57 92 52-82 b6 2e da 71 b7 22 c2 ..^0.W.R....q.". >>>>>>>> 0520 - 90 c4 69 46 07 df 6c 3f-05 8b 19 3e ce b9 75 0d ..iF..l?...>..u. >>>>>>>> 0530 - 4b 97 37 ae 94 e2 d6 3c-91 e6 82 c7 a1 78 79 2c K.7....<.....xy, >>>>>>>> 0540 - 9a a3 d5 45 94 ad e2 c8-ab fd 81 ec 62 87 f7 75 ...E........b..u >>>>>>>> 0550 - e3 70 79 8e 82 3b c5 45-0d d0 33 5f 17 03 03 00 .py..;.E..3_.... >>>>>>>> 0560 - 35 da e0 74 2a 06 41 5a-64 1e 54 94 29 73 43 3f 5..t*.AZd.T.)sC? >>>>>>>> 0570 - e5 24 a8 ba b2 7e 6b 26-82 fc d9 f6 dd 19 05 4a .$...~k&.......J >>>>>>>> 0580 - 2c 1a f3 bb 16 1d 38 95-a6 d3 a8 58 f6 a3 41 c7 ,.....8....X..A. >>>>>>>> 0590 - 92 44 35 24 25 0e .D5$%. >>>>>>>> SSL_accept:SSLv3/TLS write finished >>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>> 0000 - 14 03 03 00 01 ..... >>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (1 bytes => 1 (0x1)) >>>>>>>> 0000 - 01 . >>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>> 0000 - 17 03 03 00 3d ....= >>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (61 bytes => 61 (0x3D)) >>>>>>>> 0000 - ad dd 3e d9 ee ab 56 65-50 1c 72 2a d8 62 7f 90 ..>...VeP.r*.b.. >>>>>>>> 0010 - 13 71 7d 37 39 40 fb 89-8f 05 4b 39 44 9d 4d 67 .q}79 at ....K9D.Mg >>>>>>>> 0020 - e3 41 29 b6 3e e8 fe 04-1b 8e eb 7a 4c e2 14 a0 .A).>......zL... >>>>>>>> 0030 - b1 c2 47 3f 94 35 ed ab-8a d1 75 3b ba ..G?.5....u;. >>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>> SSL_accept:SSLv3/TLS read client certificate >>>>>>>> SSL_accept:SSLv3/TLS read finished >>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>>>>> 0000 - 17 03 03 00 da 52 1f 48-00 f4 31 13 90 7f 9c c2 .....R.H..1..... >>>>>>>> 0010 - fc 70 1a fc f7 4a 48 e7-31 ad 37 ab b5 2b 4e 5c .p...JH.1.7..+N\ >>>>>>>> 0020 - e8 d8 6d e9 af 6c 4f c1-9e 7b ea ff ef b3 eb 74 ..m..lO..{.....t >>>>>>>> 0030 - 27 67 10 21 66 5b 32 13-31 bc 99 d5 1c 6c 79 55 'g.!f[2.1....lyU >>>>>>>> 0040 - f3 3e f6 4b 07 4d a9 78-3d 12 8a f5 38 ef d9 f4 .>.K.M.x=...8... >>>>>>>> 0050 - 48 e0 2c 35 94 06 4f eb-09 e6 70 fb 59 95 7a c8 H.,5..O...p.Y.z. >>>>>>>> 0060 - 24 dd 24 e2 f9 63 b9 3c-f2 66 86 c4 73 44 53 fd $.$..c.<.f..sDS. >>>>>>>> 0070 - ca 67 8f 01 d6 db 70 f9-60 bc 50 11 51 72 dc 63 .g....p.`.P.Qr.c >>>>>>>> 0080 - 12 ca 4f 23 e2 c5 d1 1d-e5 b0 d4 ec 89 ca 28 be ..O#..........(. >>>>>>>> 0090 - 9c 30 83 40 02 a4 62 a8-5c b3 20 1a ab 39 b7 7b .0. at ..b.\. ..9.{ >>>>>>>> 00a0 - 89 13 39 87 73 be a8 f8-60 13 31 0a 48 5c 79 b9 ..9.s...`.1.H\y. >>>>>>>> 00b0 - cc 4a 51 e3 0d d2 b4 93-c0 1f 3a 22 b3 fa 24 a0 .JQ.......:"..$. >>>>>>>> 00c0 - 7c f6 76 79 d0 2d 5b 1a-ff a6 e9 e1 40 d3 b1 8c |.vy.-[..... at ... >>>>>>>> 00d0 - 0a fa fa de f3 8e d6 ad-9a 22 6b 67 0b 88 18 ........."kg... >>>>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>>>>> 0000 - 17 03 03 00 da 46 aa ea-6a 37 b1 35 e8 41 c8 b3 .....F..j7.5.A.. >>>>>>>> 0010 - 84 25 af 1c 36 a3 6d 78-a4 44 4a 83 52 ef 13 7c .%..6.mx.DJ.R..| >>>>>>>> 0020 - 8f 18 d3 4c f8 22 c8 b3-ad d0 d0 5b 47 a0 43 da ...L.".....[G.C. >>>>>>>> 0030 - d2 6e 04 8f dc c9 56 90-58 87 62 63 4c cc 31 ec .n....V.X.bcL.1. >>>>>>>> 0040 - b8 c9 18 be 41 32 e1 3c-00 41 2a f1 4d 5c 2d 44 ....A2.<.A*.M\-D >>>>>>>> 0050 - 8c aa e1 f0 ed 38 ee 44-64 e5 fd ea 58 3b 84 5d .....8.Dd...X;.] >>>>>>>> 0060 - 83 39 21 2e fe 79 4d 76-10 65 87 0f 3c ac df 28 .9!..yMv.e..<..( >>>>>>>> 0070 - 49 f8 60 eb be 49 e4 0a-0b 6a 03 2b 9d cf 9b a5 I.`..I...j.+.... >>>>>>>> 0080 - 03 56 58 32 c2 b2 59 f9-0a 0d f0 ae af ff 20 19 .VX2..Y....... . >>>>>>>> 0090 - e5 6e e4 86 2f 5e 3f 7d-47 d5 73 ae 89 48 a7 66 .n../^?}G.s..H.f >>>>>>>> 00a0 - fb 2d 83 60 e8 8b ab 27-12 db 24 78 54 eb 14 2d .-.`...'..$xT..- >>>>>>>> 00b0 - b7 c6 17 2d 3c 91 57 ac-6e 35 b8 c3 fa c2 42 48 ...-<.W.n5....BH >>>>>>>> 00c0 - 2a cb aa 98 32 89 8a ce-0c f7 cd 5e fb bf 6d 33 *...2......^..m3 >>>>>>>> 00d0 - 08 50 cf 1e 06 bb a1 98-be a4 a9 51 9a b0 34 .P.........Q..4 >>>>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>>> 0000 - 17 03 03 00 12 c5 9b 73-cc 91 7e 48 cb 25 31 a0 .......s..~H.%1. >>>>>>>> 0010 - 67 41 db bb 0f 62 d8 gA...b. >>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>>> 0000 - 17 03 03 00 12 0f dd 3f-c1 7c e6 b0 cc ea f0 13 .......?.|...... >>>>>>>> 0010 - 00 d8 01 de ef 7c bb .....|. >>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>> 0000 - 17 03 03 00 1e ..... >>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (30 bytes => 30 (0x1E)) >>>>>>>> 0000 - d6 88 44 82 cb 23 16 ba-c9 a4 fb 55 51 08 90 c1 ..D..#.....UQ... >>>>>>>> 0010 - bf bd a1 7f 0e 37 b0 b4-b5 df f1 07 6c 07 .....7......l. >>>>>>>> I am a clientwrite to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>>> 0000 - 17 03 03 00 12 c0 70 5d-14 e7 69 57 0a d8 64 16 ......p]..iW..d. >>>>>>>> 0010 - 0c 90 06 0f c3 4d 1d .....M. >>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>> 0000 - 17 03 03 00 13 ..... >>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (19 bytes => 19 (0x13)) >>>>>>>> 0000 - 60 28 5b ff bb 0d 9f 96-9a 2d cb fd 60 eb 96 62 `([......-..`..b >>>>>>>> 0010 - 53 e6 25 S.% >>>>>>>> SSL3 alert read:warning:close notify >>>>>>>> DONE >>>>>>>> shutting down SSL >>>>>>>> CONNECTION CLOSED >>>>>>>> >>>>>>>> >>>>>>>> I am using the following JDK version on MacOS: >>>>>>>> >>>>>>>> ssl git:(cert_cb_openssl_1_1_1) ? /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java -version >>>>>>>> java version "11" 2018-09-25 >>>>>>>> Java(TM) SE Runtime Environment 18.9 (build 11+28) >>>>>>>> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) >>>>>>>> >>>>>>>> For this to work you will need to have openssl 1.1.1 installed. >>>>>>>> >>>>>>>> Any help would be welcome, >>>>>>>> Norman >>>>>>>> >>>>>>>> [1] https://github.com/netty/netty-tcnative -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Mon Sep 17 12:41:06 2018 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 17 Sep 2018 22:41:06 +1000 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> Message-ID: <5B9FA0E2.7050607@zeus.net.au> Has the attached regression been fixed "Re: -Djava.security.manager=problems for service provider"? I recently changed all our code to use System.setSecurityManager(), because of this regression, prior to that we used the command line option, it's going to take some time to revert... SecurityManager is of critical importance in our software, I wish it were simpler, we solved the performance issues about 8 years ago, but complexity is still a pain point. Thanks, Peter. On 17/09/2018 7:09 PM, Alan Bateman wrote: > On 16/09/2018 20:37, Will Sargent wrote: >> > 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 don't know of any research or papers that explicitly say that >> SecurityManager is "legacy". I did some research into this a while >> ago, and while SecurityManager has some major flaws, I don't know of >> any other way to sandbox a Java application. >> > Have you looked into native containers? It's easy to find examples of > applications running in a docker container for example. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: Naoto Sato Subject: Re: -Djava.security.manager=problems for service provider Date: Thu, 29 Mar 2018 11:02:41 -0700 Size: 44548 URL: From anthony.scarpino at oracle.com Mon Sep 17 19:11:26 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 17 Sep 2018 12:11:26 -0700 Subject: RFR(s): 8208641: SSLSocket should throw an exception when configuring DTLS In-Reply-To: References: <8500ab4f-3f0a-6f4b-b4cc-b1508c08fec8@oracle.com> Message-ID: <49456fc3-f415-b224-d65e-be56eb64f5e7@oracle.com> Thanks.. I updated the copyright.. Tony On 08/29/2018 07:02 AM, Xuelei Fan wrote: > Looks fine to me.?? Please update the copyright years as well. > > Thanks, > Xuelei > > On 8/28/2018 9:47 PM, Anthony Scarpino wrote: >> I need a review of this fix.? Simple change to throw an >> UnsupportedOperationException using SSLSocket with DTLS.? Additionally >> use SSLEngine for some of the generic methods that were defaulting to >> SSLSocket? This is only for the JSSE provider. >> >> http://cr.openjdk.java.net/~ascarpino/8208641/webrev/ >> >> Tony >> From valerie.peng at oracle.com Tue Sep 18 00:52:22 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 17 Sep 2018 17:52:22 -0700 Subject: RFR 8210821: Support dns_canonicalize_hostname in krb5.conf In-Reply-To: <49DF7170-4E18-431D-A733-10507625BCB9@oracle.com> References: <49DF7170-4E18-431D-A733-10507625BCB9@oracle.com> Message-ID: Look fine to me. Added myself to CSR as reviewer. Thanks, Valerie On 9/17/2018 1:17 AM, Weijun Wang wrote: > Please review the code change and CSR at > > http://cr.openjdk.java.net/~weijun/8210821/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8210822 > > Thanks > Max > From xuelei.fan at oracle.com Tue Sep 18 01:04:40 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Sep 2018 18:04:40 -0700 Subject: sun.security.ssl.ProtocolVersion.valueOf(...) in Java8 and TLSv1.3 In-Reply-To: References: Message-ID: <2005a485-1cac-2049-223d-beaa45084dbe@oracle.com> Hi Norman, In general, it is risk to support unknown protocol version in the key/trust manager implementation. The trust manager implemented for TLS 1.2 and prior versions might not work with TLS 1.3 probably. Did you make the evaluation? Would you mind contribute a patch? Please feel free to file an enhancement request, for further evaluation when there is a chance. Thanks, Xuelei On 9/17/2018 5:28 AM, Norman Maurer wrote: > Hi all, > > In netty we support using OpenSSL for native SSL which recently added TLSv1.3 support as part of OpenSSL 1.1.1. In an ideal world we would be able to use this even with Java8 which is almost true except the fact that sun.security.ssl.ProtocolVersion.valueOf(?) will throw an IllegalArgumentException when the string ?TLSv1.3? is provided. This is problematic as this happens during validation in the default TrustManager used by the OpenJDK. > > The stack looks something like this: > java.lang.IllegalArgumentException: TLSv1.3 > at sun.security.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:187) > at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:258) > at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136) > > I could work around this by just wrap the SSLSession and return TLSv1.2 during validation as the same validation should be done as in the TLSv1.2 implementation but this is really just a hack.So I wonder if you would consider to either add support for parsing TLSv1.3 to the internal enum or just handle it more gracefully. Another thing that would work of course is to always provide a custom X509ExtendedTrustManager but I hoped to be able to re-use the default implementation as it already implements a lot of verification logic. > > WDYT ? > Norman > > > > From jai.forums2013 at gmail.com Tue Sep 18 01:30:35 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 18 Sep 2018 07:00:35 +0530 Subject: Java 11 RC - Handshake failure in certain specific cases throws a different exception than previous versions In-Reply-To: <5a20a75d-d5b0-56d9-af7e-4be2cb23098c@gmail.com> References: <5a20a75d-d5b0-56d9-af7e-4be2cb23098c@gmail.com> Message-ID: <2321275f-5d25-1d45-a979-c0ec132958cb@gmail.com> Just checking back on this one. Is this an expected change? Personally, it's not a big issue in the code where this is happening for me. I'll probably just change the catch block to a more generic IOException. However, for any other code which relied on the previous SocketException catch block, they will now have to expect a different exception depending on what version of Java runtime it's running against. -Jaikiran On 12/09/18 9:11 PM, Jaikiran Pai wrote: > Please consider the code that's at the end of this mail. It is a simple > client/server code where a HTTPS server is created and set to > "needClientAuth". The client then uses HttpsURLConnection and (in this > case intentionally) doesn't present any certificate, expecting the > handshake to fail. In previous versions of Java, the handshake failure > in this code would throw a java.net.SocketException as below: > > Exception in thread "main" java.net.SocketException: Connection reset > ??? at java.net.SocketInputStream.read(SocketInputStream.java:210) > ??? at java.net.SocketInputStream.read(SocketInputStream.java:141) > ??? at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) > ??? at sun.security.ssl.InputRecord.read(InputRecord.java:503) > ??? at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983) > ??? at sun.security.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1779) > ??? at > sun.security.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:124) > ??? at > sun.security.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:1156) > ??? at > sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:1266) > ??? at > sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1178) > ??? at > sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:348) > ??? at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) > ??? at sun.security.ssl.Handshaker.process_record(Handshaker.java:987) > ??? at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072) > ??? at > sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385) > ??? at > sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413) > ??? at > sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397) > ??? at > sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559) > ??? at > sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) > ??? at > sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564) > ??? at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492) > ??? at > sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263) > ??? at ClientCertTest.main(ClientCertTest.java:26) > > > However, in the Java 11 (release candidate) as well as Java 12 > (upstream), this code now throws a javax.net.ssl.SSLProtocolException > with the java.net.SocketException wrapped in it: > > Exception in thread "main" javax.net.ssl.SSLProtocolException: > Connection reset > ??? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) > ??? at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321) > ??? at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) > ??? at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259) > ??? at > java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1314) > ??? at > java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:839) > ??? at > java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:252) > ??? at > java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:292) > ??? at > java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:351) > ??? at > java.base/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:746) > ??? at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:689) > ??? at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:717) > ??? at > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1604) > ??? at > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509) > ??? at > java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245) > ??? at ClientCertTest.main(ClientCertTest.java:26) > Caused by: java.net.SocketException: Connection reset > ??? at java.base/java.net.SocketInputStream.read(SocketInputStream.java:186) > ??? at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140) > ??? at > java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448) > ??? at > java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:68) > ??? at > java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1104) > ??? at > java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) > ??? ... 10 more > > > Is this an intentional and expected change? As far as I could see, there > isn't any specific API which says SocketException will be thrown in this > case, so maybe the client applications which were catching this specific > exception are expected to change their catch block to something more > generic like a IOException? > > Here's the code to reproduce this: > > import java.io.*; > import java.net.*; > import javax.net.ssl.*; > import java.util.*; > import java.security.*; > import com.sun.net.httpserver.*; > import java.security.cert.*; > > > public class ClientCertTest { > ??? private static final String keyFilename = "keystore"; > ??? private static final String keystorePass = "passphrase"; > > ??? public static void main(final String[] args) throws Exception { > ??? ??? final int port = 12345; > ??????? final HttpsServer server = startServer("localhost", port); > ??????? try { > ??? ??? ??? final URL targetURL = new URL("https://localhost:" + port + > "/"); > ??? ??? ??? final SSLContext sslctx = SSLContext.getInstance("TLS"); > ??? ??????? sslctx.init(null, new TrustManager[] {new TrustAll()}, null); > ??? ??? ??? HttpsURLConnection.setDefaultHostnameVerifier((h, s) -> > {return true;}); > ??? ??? ??? final HttpsURLConnection conn = (HttpsURLConnection) > targetURL.openConnection(); > ??? ??? ??? // setup the HTTPS connection to use our SocketFactory which > doesn't present > ??? ??? ??? // any cert when asked for (and thus is expected to fail > handshake) > ??? ??? ??? conn.setSSLSocketFactory(sslctx.getSocketFactory()); > ??? ??? ??? try (final InputStream is = conn.getInputStream()) { > ??? ??? ??????? is.read(); > ??? ??? ??? } catch (SocketException se) { > ??? ??? ??? ???? System.out.println("*** Received the expected > SocketException: " + se.getMessage()); > ??? ??? ??? ???? throw se; > ??? ??? ??? } > ??? ??? } finally { > ??? ?? ??? ??? server.stop(0); > ??? ??? ??? System.out.println("Stopped server"); > ??? ??? } > ??? } > > ??? private static HttpsServer startServer(final String host, final int > port) throws Exception { > ??????? final HttpsServer server = HttpsServer.create(new > InetSocketAddress(host, port), 0); > ??? ??? final Thread t = new Thread(() -> { > ??? ??? ??? try { > ??? ??? ??? ??? final SSLContext sslctx = SSLContext.getInstance("TLS"); > ??? ??? ??????? final KeyManagerFactory kmf = > KeyManagerFactory.getInstance("SunX509"); > ??? ??? ??????? final KeyStore ks = KeyStore.getInstance("JKS"); > ??? ??? ??????? try (final FileInputStream fis = new > FileInputStream(keyFilename)) { > ??? ??? ??????????? ks.load(fis, keystorePass.toCharArray()); > ??? ??? ??????? } > ??? ??? ??????? kmf.init(ks, keystorePass.toCharArray()); > ??? ??? ??????? sslctx.init(kmf.getKeyManagers(), null, null); > ??? ??? ??????? final SSLParameters sslParameters = > sslctx.getDefaultSSLParameters(); > ??? ??? ??????? // need client auth > ??? ??? ??????? sslParameters.setNeedClientAuth(true); > ??? ??? ??????? server.setHttpsConfigurator(new HttpsConfigurator(sslctx) { > ??? ??? ??????? ??? @Override > ??? ??? ??????? ??? public void configure(final HttpsParameters params) { > ??? ??? ??????? ??? ??? params.setSSLParameters(sslParameters); > ??? ??? ??????? ??? } > ??? ??? ??????? }); > ??? ??? ??? ??? server.start(); > ??? ??? ??? ??? System.out.println("Started server at " + > server.getAddress()); > ??? ??? ??? } catch(Exception e) { > ??? ??? ??? ??? throw new RuntimeException(e); > ??? ??? ??? } > ??? ??? }); > ??? ??? t.start(); > ??? ??? return server; > ??? } > > ??? private static class TrustAll implements X509TrustManager { > > ??? ??? @Override > ??? ??? public void checkClientTrusted(X509Certificate[] chain, String > authType) throws CertificateException { > ??? ??? ??? return; > ??????? } > > ??? ??? @Override > ??? ??? public void checkServerTrusted(X509Certificate[] chain, String > authType) throws CertificateException { > ??? ??? ??? return; > ??? ??? } > > ??? ??? @Override > ??? ??? public X509Certificate[] getAcceptedIssuers() { > ??? ??? ??? return new X509Certificate[0]; > ??? ??? } > ??? } > } > > > P.S: The "keystore" file in this example is the same one that's present > in the openjdk repo at test/jdk/javax/net/ssl/etc/keystore, so in order > to run the above code, that file can just be placed in the current > working dir. > > -Jaikiran > From xuelei.fan at oracle.com Tue Sep 18 01:59:58 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 17 Sep 2018 18:59:58 -0700 Subject: Java 11 RC - Handshake failure in certain specific cases throws a different exception than previous versions In-Reply-To: <2321275f-5d25-1d45-a979-c0ec132958cb@gmail.com> References: <5a20a75d-d5b0-56d9-af7e-4be2cb23098c@gmail.com> <2321275f-5d25-1d45-a979-c0ec132958cb@gmail.com> Message-ID: <44f2aea8-5ef6-e60c-5060-5f0390ecfa26@oracle.com> Hi Jaikiran, Normally, the thrown exception class can be an implementation choice, and may be not reliable from version to version. We were trying to use the same exception, but we may miss the use cases. I may suggest to make the code independent from it. However, if the impact is significant, please feel free file a bug and we will evaluate if there is something we can do. Thanks, Xuelei On 9/17/2018 6:30 PM, Jaikiran Pai wrote: > Just checking back on this one. Is this an expected change? Personally, > it's not a big issue in the code where this is happening for me. I'll > probably just change the catch block to a more generic IOException. > However, for any other code which relied on the previous SocketException > catch block, they will now have to expect a different exception > depending on what version of Java runtime it's running against. > > -Jaikiran > > > On 12/09/18 9:11 PM, Jaikiran Pai wrote: >> Please consider the code that's at the end of this mail. It is a simple >> client/server code where a HTTPS server is created and set to >> "needClientAuth". The client then uses HttpsURLConnection and (in this >> case intentionally) doesn't present any certificate, expecting the >> handshake to fail. In previous versions of Java, the handshake failure >> in this code would throw a java.net.SocketException as below: >> >> Exception in thread "main" java.net.SocketException: Connection reset >> ??? at java.net.SocketInputStream.read(SocketInputStream.java:210) >> ??? at java.net.SocketInputStream.read(SocketInputStream.java:141) >> ??? at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) >> ??? at sun.security.ssl.InputRecord.read(InputRecord.java:503) >> ??? at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983) >> ??? at sun.security.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1779) >> ??? at >> sun.security.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:124) >> ??? at >> sun.security.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:1156) >> ??? at >> sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:1266) >> ??? at >> sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1178) >> ??? at >> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:348) >> ??? at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) >> ??? at sun.security.ssl.Handshaker.process_record(Handshaker.java:987) >> ??? at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072) >> ??? at >> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385) >> ??? at >> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413) >> ??? at >> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397) >> ??? at >> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559) >> ??? at >> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) >> ??? at >> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564) >> ??? at >> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492) >> ??? at >> sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263) >> ??? at ClientCertTest.main(ClientCertTest.java:26) >> >> >> However, in the Java 11 (release candidate) as well as Java 12 >> (upstream), this code now throws a javax.net.ssl.SSLProtocolException >> with the java.net.SocketException wrapped in it: >> >> Exception in thread "main" javax.net.ssl.SSLProtocolException: >> Connection reset >> ??? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) >> ??? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321) >> ??? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) >> ??? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259) >> ??? at >> java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1314) >> ??? at >> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:839) >> ??? at >> java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:252) >> ??? at >> java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:292) >> ??? at >> java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:351) >> ??? at >> java.base/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:746) >> ??? at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:689) >> ??? at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:717) >> ??? at >> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1604) >> ??? at >> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509) >> ??? at >> java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245) >> ??? at ClientCertTest.main(ClientCertTest.java:26) >> Caused by: java.net.SocketException: Connection reset >> ??? at java.base/java.net.SocketInputStream.read(SocketInputStream.java:186) >> ??? at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140) >> ??? at >> java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448) >> ??? at >> java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:68) >> ??? at >> java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1104) >> ??? at >> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) >> ??? ... 10 more >> >> >> Is this an intentional and expected change? As far as I could see, there >> isn't any specific API which says SocketException will be thrown in this >> case, so maybe the client applications which were catching this specific >> exception are expected to change their catch block to something more >> generic like a IOException? >> >> Here's the code to reproduce this: >> >> import java.io.*; >> import java.net.*; >> import javax.net.ssl.*; >> import java.util.*; >> import java.security.*; >> import com.sun.net.httpserver.*; >> import java.security.cert.*; >> >> >> public class ClientCertTest { >> ??? private static final String keyFilename = "keystore"; >> ??? private static final String keystorePass = "passphrase"; >> >> ??? public static void main(final String[] args) throws Exception { >> ??? ??? final int port = 12345; >> ??????? final HttpsServer server = startServer("localhost", port); >> ??????? try { >> ??? ??? ??? final URL targetURL = new URL("https://localhost:" + port + >> "/"); >> ??? ??? ??? final SSLContext sslctx = SSLContext.getInstance("TLS"); >> ??? ??????? sslctx.init(null, new TrustManager[] {new TrustAll()}, null); >> ??? ??? ??? HttpsURLConnection.setDefaultHostnameVerifier((h, s) -> >> {return true;}); >> ??? ??? ??? final HttpsURLConnection conn = (HttpsURLConnection) >> targetURL.openConnection(); >> ??? ??? ??? // setup the HTTPS connection to use our SocketFactory which >> doesn't present >> ??? ??? ??? // any cert when asked for (and thus is expected to fail >> handshake) >> ??? ??? ??? conn.setSSLSocketFactory(sslctx.getSocketFactory()); >> ??? ??? ??? try (final InputStream is = conn.getInputStream()) { >> ??? ??? ??????? is.read(); >> ??? ??? ??? } catch (SocketException se) { >> ??? ??? ??? ???? System.out.println("*** Received the expected >> SocketException: " + se.getMessage()); >> ??? ??? ??? ???? throw se; >> ??? ??? ??? } >> ??? ??? } finally { >> ??? ?? ??? ??? server.stop(0); >> ??? ??? ??? System.out.println("Stopped server"); >> ??? ??? } >> ??? } >> >> ??? private static HttpsServer startServer(final String host, final int >> port) throws Exception { >> ??????? final HttpsServer server = HttpsServer.create(new >> InetSocketAddress(host, port), 0); >> ??? ??? final Thread t = new Thread(() -> { >> ??? ??? ??? try { >> ??? ??? ??? ??? final SSLContext sslctx = SSLContext.getInstance("TLS"); >> ??? ??? ??????? final KeyManagerFactory kmf = >> KeyManagerFactory.getInstance("SunX509"); >> ??? ??? ??????? final KeyStore ks = KeyStore.getInstance("JKS"); >> ??? ??? ??????? try (final FileInputStream fis = new >> FileInputStream(keyFilename)) { >> ??? ??? ??????????? ks.load(fis, keystorePass.toCharArray()); >> ??? ??? ??????? } >> ??? ??? ??????? kmf.init(ks, keystorePass.toCharArray()); >> ??? ??? ??????? sslctx.init(kmf.getKeyManagers(), null, null); >> ??? ??? ??????? final SSLParameters sslParameters = >> sslctx.getDefaultSSLParameters(); >> ??? ??? ??????? // need client auth >> ??? ??? ??????? sslParameters.setNeedClientAuth(true); >> ??? ??? ??????? server.setHttpsConfigurator(new HttpsConfigurator(sslctx) { >> ??? ??? ??????? ??? @Override >> ??? ??? ??????? ??? public void configure(final HttpsParameters params) { >> ??? ??? ??????? ??? ??? params.setSSLParameters(sslParameters); >> ??? ??? ??????? ??? } >> ??? ??? ??????? }); >> ??? ??? ??? ??? server.start(); >> ??? ??? ??? ??? System.out.println("Started server at " + >> server.getAddress()); >> ??? ??? ??? } catch(Exception e) { >> ??? ??? ??? ??? throw new RuntimeException(e); >> ??? ??? ??? } >> ??? ??? }); >> ??? ??? t.start(); >> ??? ??? return server; >> ??? } >> >> ??? private static class TrustAll implements X509TrustManager { >> >> ??? ??? @Override >> ??? ??? public void checkClientTrusted(X509Certificate[] chain, String >> authType) throws CertificateException { >> ??? ??? ??? return; >> ??????? } >> >> ??? ??? @Override >> ??? ??? public void checkServerTrusted(X509Certificate[] chain, String >> authType) throws CertificateException { >> ??? ??? ??? return; >> ??? ??? } >> >> ??? ??? @Override >> ??? ??? public X509Certificate[] getAcceptedIssuers() { >> ??? ??? ??? return new X509Certificate[0]; >> ??? ??? } >> ??? } >> } >> >> >> P.S: The "keystore" file in this example is the same one that's present >> in the openjdk repo at test/jdk/javax/net/ssl/etc/keystore, so in order >> to run the above code, that file can just be placed in the current >> working dir. >> >> -Jaikiran >> > From jai.forums2013 at gmail.com Tue Sep 18 02:06:50 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 18 Sep 2018 07:36:50 +0530 Subject: Java 11 RC - Handshake failure in certain specific cases throws a different exception than previous versions In-Reply-To: <44f2aea8-5ef6-e60c-5060-5f0390ecfa26@oracle.com> References: <5a20a75d-d5b0-56d9-af7e-4be2cb23098c@gmail.com> <2321275f-5d25-1d45-a979-c0ec132958cb@gmail.com> <44f2aea8-5ef6-e60c-5060-5f0390ecfa26@oracle.com> Message-ID: <16c4e3a1-77b4-15bc-ccee-9e206f876d67@gmail.com> Hi Xuelei, This isn't a significant issue in our case (there isn't any functional difference in what was being done in that specific catch block, in the code where this happened). I was only just curious if this was an intentional. The SSLProtocolException which is now being thrown, I think is a better one (having read its javadoc). I'll leave it at this now and won't create a bug. Thank you for your inputs. -Jaikiran On 18/09/18 7:29 AM, Xuelei Fan wrote: > Hi Jaikiran, > > Normally, the thrown exception class can be an implementation choice, > and may be not reliable from version to version.? We were trying to > use the same exception, but we may miss the use cases.? I may suggest > to make the code independent from it.? However, if the impact is > significant, please feel free file a bug and we will evaluate if there > is something we can do. > > Thanks, > Xuelei > > On 9/17/2018 6:30 PM, Jaikiran Pai wrote: >> Just checking back on this one. Is this an expected change? Personally, >> it's not a big issue in the code where this is happening for me. I'll >> probably just change the catch block to a more generic IOException. >> However, for any other code which relied on the previous SocketException >> catch block, they will now have to expect a different exception >> depending on what version of Java runtime it's running against. >> >> -Jaikiran >> >> >> On 12/09/18 9:11 PM, Jaikiran Pai wrote: >>> Please consider the code that's at the end of this mail. It is a simple >>> client/server code where a HTTPS server is created and set to >>> "needClientAuth". The client then uses HttpsURLConnection and (in this >>> case intentionally) doesn't present any certificate, expecting the >>> handshake to fail. In previous versions of Java, the handshake failure >>> in this code would throw a java.net.SocketException as below: >>> >>> Exception in thread "main" java.net.SocketException: Connection reset >>> ???? at java.net.SocketInputStream.read(SocketInputStream.java:210) >>> ???? at java.net.SocketInputStream.read(SocketInputStream.java:141) >>> ???? at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) >>> ???? at sun.security.ssl.InputRecord.read(InputRecord.java:503) >>> ???? at >>> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983) >>> ???? at >>> sun.security.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1779) >>> ???? at >>> sun.security.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:124) >>> ???? at >>> sun.security.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:1156) >>> ???? at >>> sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:1266) >>> >>> ???? at >>> sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1178) >>> >>> ???? at >>> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:348) >>> >>> ???? at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) >>> ???? at sun.security.ssl.Handshaker.process_record(Handshaker.java:987) >>> ???? at >>> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072) >>> ???? at >>> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385) >>> >>> ???? at >>> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413) >>> ???? at >>> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397) >>> ???? at >>> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559) >>> >>> ???? at >>> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) >>> >>> ???? at >>> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564) >>> >>> ???? at >>> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492) >>> >>> ???? at >>> sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263) >>> >>> ???? at ClientCertTest.main(ClientCertTest.java:26) >>> >>> >>> However, in the Java 11 (release candidate) as well as Java 12 >>> (upstream), this code now throws a javax.net.ssl.SSLProtocolException >>> with the java.net.SocketException wrapped in it: >>> >>> Exception in thread "main" javax.net.ssl.SSLProtocolException: >>> Connection reset >>> ???? at >>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126) >>> ???? at >>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321) >>> >>> ???? at >>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) >>> >>> ???? at >>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259) >>> >>> ???? at >>> java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1314) >>> >>> ???? at >>> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:839) >>> >>> ???? at >>> java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:252) >>> >>> ???? at >>> java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:292) >>> >>> ???? at >>> java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:351) >>> >>> ???? at >>> java.base/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:746) >>> >>> ???? at >>> java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:689) >>> ???? at >>> java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:717) >>> ???? at >>> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1604) >>> >>> ???? at >>> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509) >>> >>> ???? at >>> java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245) >>> >>> ???? at ClientCertTest.main(ClientCertTest.java:26) >>> Caused by: java.net.SocketException: Connection reset >>> ???? at >>> java.base/java.net.SocketInputStream.read(SocketInputStream.java:186) >>> ???? at >>> java.base/java.net.SocketInputStream.read(SocketInputStream.java:140) >>> ???? at >>> java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448) >>> >>> ???? at >>> java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:68) >>> >>> ???? at >>> java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1104) >>> >>> ???? at >>> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) >>> >>> ???? ... 10 more >>> >>> >>> Is this an intentional and expected change? As far as I could see, >>> there >>> isn't any specific API which says SocketException will be thrown in >>> this >>> case, so maybe the client applications which were catching this >>> specific >>> exception are expected to change their catch block to something more >>> generic like a IOException? >>> >>> Here's the code to reproduce this: >>> >>> import java.io.*; >>> import java.net.*; >>> import javax.net.ssl.*; >>> import java.util.*; >>> import java.security.*; >>> import com.sun.net.httpserver.*; >>> import java.security.cert.*; >>> >>> >>> public class ClientCertTest { >>> ???? private static final String keyFilename = "keystore"; >>> ???? private static final String keystorePass = "passphrase"; >>> >>> ???? public static void main(final String[] args) throws Exception { >>> ???? ??? final int port = 12345; >>> ???????? final HttpsServer server = startServer("localhost", port); >>> ???????? try { >>> ???? ??? ??? final URL targetURL = new URL("https://localhost:" + >>> port + >>> "/"); >>> ???? ??? ??? final SSLContext sslctx = SSLContext.getInstance("TLS"); >>> ???? ??????? sslctx.init(null, new TrustManager[] {new TrustAll()}, >>> null); >>> ???? ??? ??? HttpsURLConnection.setDefaultHostnameVerifier((h, s) -> >>> {return true;}); >>> ???? ??? ??? final HttpsURLConnection conn = (HttpsURLConnection) >>> targetURL.openConnection(); >>> ???? ??? ??? // setup the HTTPS connection to use our SocketFactory >>> which >>> doesn't present >>> ???? ??? ??? // any cert when asked for (and thus is expected to fail >>> handshake) >>> ???? ??? ??? conn.setSSLSocketFactory(sslctx.getSocketFactory()); >>> ???? ??? ??? try (final InputStream is = conn.getInputStream()) { >>> ???? ??? ??????? is.read(); >>> ???? ??? ??? } catch (SocketException se) { >>> ???? ??? ??? ???? System.out.println("*** Received the expected >>> SocketException: " + se.getMessage()); >>> ???? ??? ??? ???? throw se; >>> ???? ??? ??? } >>> ???? ??? } finally { >>> ???? ?? ??? ??? server.stop(0); >>> ???? ??? ??? System.out.println("Stopped server"); >>> ???? ??? } >>> ???? } >>> >>> ???? private static HttpsServer startServer(final String host, final >>> int >>> port) throws Exception { >>> ???????? final HttpsServer server = HttpsServer.create(new >>> InetSocketAddress(host, port), 0); >>> ???? ??? final Thread t = new Thread(() -> { >>> ???? ??? ??? try { >>> ???? ??? ??? ??? final SSLContext sslctx = >>> SSLContext.getInstance("TLS"); >>> ???? ??? ??????? final KeyManagerFactory kmf = >>> KeyManagerFactory.getInstance("SunX509"); >>> ???? ??? ??????? final KeyStore ks = KeyStore.getInstance("JKS"); >>> ???? ??? ??????? try (final FileInputStream fis = new >>> FileInputStream(keyFilename)) { >>> ???? ??? ??????????? ks.load(fis, keystorePass.toCharArray()); >>> ???? ??? ??????? } >>> ???? ??? ??????? kmf.init(ks, keystorePass.toCharArray()); >>> ???? ??? ??????? sslctx.init(kmf.getKeyManagers(), null, null); >>> ???? ??? ??????? final SSLParameters sslParameters = >>> sslctx.getDefaultSSLParameters(); >>> ???? ??? ??????? // need client auth >>> ???? ??? ??????? sslParameters.setNeedClientAuth(true); >>> ???? ??? ??????? server.setHttpsConfigurator(new >>> HttpsConfigurator(sslctx) { >>> ???? ??? ??????? ??? @Override >>> ???? ??? ??????? ??? public void configure(final HttpsParameters >>> params) { >>> ???? ??? ??????? ??? ??? params.setSSLParameters(sslParameters); >>> ???? ??? ??????? ??? } >>> ???? ??? ??????? }); >>> ???? ??? ??? ??? server.start(); >>> ???? ??? ??? ??? System.out.println("Started server at " + >>> server.getAddress()); >>> ???? ??? ??? } catch(Exception e) { >>> ???? ??? ??? ??? throw new RuntimeException(e); >>> ???? ??? ??? } >>> ???? ??? }); >>> ???? ??? t.start(); >>> ???? ??? return server; >>> ???? } >>> >>> ???? private static class TrustAll implements X509TrustManager { >>> >>> ???? ??? @Override >>> ???? ??? public void checkClientTrusted(X509Certificate[] chain, String >>> authType) throws CertificateException { >>> ???? ??? ??? return; >>> ???????? } >>> >>> ???? ??? @Override >>> ???? ??? public void checkServerTrusted(X509Certificate[] chain, String >>> authType) throws CertificateException { >>> ???? ??? ??? return; >>> ???? ??? } >>> >>> ???? ??? @Override >>> ???? ??? public X509Certificate[] getAcceptedIssuers() { >>> ???? ??? ??? return new X509Certificate[0]; >>> ???? ??? } >>> ???? } >>> } >>> >>> >>> P.S: The "keystore" file in this example is the same one that's present >>> in the openjdk repo at test/jdk/javax/net/ssl/etc/keystore, so in order >>> to run the above code, that file can just be placed in the current >>> working dir. >>> >>> -Jaikiran >>> >> From weijun.wang at oracle.com Tue Sep 18 03:43:04 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 18 Sep 2018 11:43:04 +0800 Subject: RFR 8210821: Support dns_canonicalize_hostname in krb5.conf In-Reply-To: References: <49DF7170-4E18-431D-A733-10507625BCB9@oracle.com> Message-ID: <43C7200F-DB71-4675-950D-DF35DA2D834A@oracle.com> Thanks, I'll proposed the CSR next. --Max > On Sep 18, 2018, at 8:52 AM, Valerie Peng wrote: > > Look fine to me. Added myself to CSR as reviewer. > > Thanks, > > Valerie > > > On 9/17/2018 1:17 AM, Weijun Wang wrote: >> Please review the code change and CSR at >> >> http://cr.openjdk.java.net/~weijun/8210821/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8210822 >> >> Thanks >> Max >> > From pallavi.sonal at oracle.com Tue Sep 18 04:26:57 2018 From: pallavi.sonal at oracle.com (Pallavi Sonal) Date: Mon, 17 Sep 2018 21:26:57 -0700 (PDT) Subject: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well Message-ID: <046e244e-d0b0-4d82-bf0f-077c87f5b7f7@default> Hi Norman, The enhancement request has been moved to JDK and can be referred at : https://bugs.openjdk.java.net/browse/JDK-8210843 . Thanks, Pallavi Sonal ----------------------------------- Date: Mon, 17 Sep 2018 19:11:10 +0200 From: Norman Maurer To: Xuelei Fan Cc: security-dev at openjdk.java.net Subject: Re: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well Message-ID: <87281E2B-CAA4-49DE-86EC-EB1EB878D15F at googlemail.com> Content-Type: text/plain; charset="us-ascii" Done.. ID: 9057278 Thanks Norman > On 17. Sep 2018, at 18:51, Xuelei Fan wrote: > > Hi Norman, > > Please file an issue for the tracking. > > Thanks, > Xuelei > > On 9/17/2018 5:57 AM, Norman Maurer wrote: >> Should I open an issue somewhere to keep track of it or will you take care of it ? >> Bye >> Norman >>> On 11. Sep 2018, at 17:01, Norman Maurer wrote: >>> >>> This sounds great. >>> >>> I have no idea how many people still use X509TrustManager, sorry. >>> >>> It may be a good idea to add something to the java docs to tell people to prefer X509ExtendedTrustManager as well. >>> >>> Bye >>> Norman >>> >>>> Am 11.09.2018 um 16:44 schrieb Xuelei Fan : >>>> >>>> Hi Norman, >>>> >>>> >>>> It may be doable by adding a delegation mode to public TrustManagerFactory: >>>> TrustManagerFactory.init(X509TrustManager proxy) >>>> >>>> However, the X509ExtendedTrustManager should be recommended for now since its introducing in JDK 7. >>>> >>>> Do you know how many users are still using the X509TrustManager implementation? >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> On 9/11/2018 3:32 AM, Norman Maurer wrote: >>>>> Hi all, >>>>> Would it be possible to consider exposing SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible to reuse it when a custom SSLEngine / SSLContextSpi is provided ? >>>>> I am asking because it provides really nice extra functionality by wrapping for X509TrustManager implementation and do extra hostname checks etc. At the moment we can not make use of this extra functionality in netty with our custom SSLEngine implementation as there is no way to access this. Which means depending on if the user use our implementation or the default implementation the behaviour if quite different when using a X509TrustManager in the sense that when using the default implementation a lot of extra checks are done. >>>>> As the extra checks done in AbstractTrustManagerWrapper is not really depending on the underlying SSLContextSpi implementation (at least as far as I was able to understand it so far) it would be nice to be able to make use of it. >>>>> Bye >>>>> Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: From pallavi.sonal at oracle.com Tue Sep 18 04:29:11 2018 From: pallavi.sonal at oracle.com (Pallavi Sonal) Date: Mon, 17 Sep 2018 21:29:11 -0700 (PDT) Subject: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well In-Reply-To: <046e244e-d0b0-4d82-bf0f-077c87f5b7f7@default> References: <046e244e-d0b0-4d82-bf0f-077c87f5b7f7@default> Message-ID: <1ba52ea7-ddcd-40fd-a8c1-7611b1e3660c@default> Hi Norman, The enhancement request has been moved to JDK and can be referred at : https://bugs.openjdk.java.net/browse/JDK-8210843 . Thanks, Pallavi Sonal ----------------------------------- Date: Mon, 17 Sep 2018 19:11:10 +0200 From: Norman Maurer To: Xuelei Fan Cc: security-dev at openjdk.java.net Subject: Re: Expose SSLContextImpl#AbstractTrustManagerWrapper so it can be used with custom SSLEngine / SSLContextSPI implementations as well Message-ID: <87281E2B-CAA4-49DE-86EC-EB1EB878D15F at googlemail.com> Content-Type: text/plain; charset="us-ascii" Done.. ID: 9057278 Thanks Norman > On 17. Sep 2018, at 18:51, Xuelei Fan wrote: > > Hi Norman, > > Please file an issue for the tracking. > > Thanks, > Xuelei > > On 9/17/2018 5:57 AM, Norman Maurer wrote: >> Should I open an issue somewhere to keep track of it or will you take care of it ? >> Bye >> Norman >>> On 11. Sep 2018, at 17:01, Norman Maurer wrote: >>> >>> This sounds great. >>> >>> I have no idea how many people still use X509TrustManager, sorry. >>> >>> It may be a good idea to add something to the java docs to tell people to prefer X509ExtendedTrustManager as well. >>> >>> Bye >>> Norman >>> >>>> Am 11.09.2018 um 16:44 schrieb Xuelei Fan : >>>> >>>> Hi Norman, >>>> >>>> >>>> It may be doable by adding a delegation mode to public TrustManagerFactory: >>>> TrustManagerFactory.init(X509TrustManager proxy) >>>> >>>> However, the X509ExtendedTrustManager should be recommended for now since its introducing in JDK 7. >>>> >>>> Do you know how many users are still using the X509TrustManager implementation? >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> On 9/11/2018 3:32 AM, Norman Maurer wrote: >>>>> Hi all, >>>>> Would it be possible to consider exposing SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible to reuse it when a custom SSLEngine / SSLContextSpi is provided ? >>>>> I am asking because it provides really nice extra functionality by wrapping for X509TrustManager implementation and do extra hostname checks etc. At the moment we can not make use of this extra functionality in netty with our custom SSLEngine implementation as there is no way to access this. Which means depending on if the user use our implementation or the default implementation the behaviour if quite different when using a X509TrustManager in the sense that when using the default implementation a lot of extra checks are done. >>>>> As the extra checks done in AbstractTrustManagerWrapper is not really depending on the underlying SSLContextSpi implementation (at least as far as I was able to understand it so far) it would be nice to be able to make use of it. >>>>> Bye >>>>> Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Sep 18 07:39:36 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 18 Sep 2018 08:39:36 +0100 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <5B9FA0E2.7050607@zeus.net.au> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> <5B9FA0E2.7050607@zeus.net.au> Message-ID: <08f168e5-4c96-4946-77bf-5744a57f3921@oracle.com> On 17/09/2018 13:41, Peter Firmstone wrote: > Has the attached regression been fixed "Re: > -Djava.security.manager=problems for service provider"??? I recently > changed all our code to use System.setSecurityManager(), because of > this regression, prior to that we used the command line option, it's > going to take some time to revert... I think it would be better to start a new thread with a test case that demonstrates the issue with JDK 11 builds. As I think I noted in the original discussion (from March) there were several issues with recursive initialization and handling of resources that have been fixed in recent releases. I can't say if they address the the specific issue you were running into with JDK 8 but it would be useful to know if there is still an issue or not. -Alan From goetz.lindenmaier at sap.com Tue Sep 18 10:06:51 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 18 Sep 2018 10:06:51 +0000 Subject: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails in jdk In-Reply-To: <41263153-e2e1-f9e6-ab2d-010688b74d57@oracle.com> References: <1ce14de946914cf89ec60b5837e1129f@sap.com> <41263153-e2e1-f9e6-ab2d-010688b74d57@oracle.com> Message-ID: Hi Rajan, are you working on this issue? We have this test disabled, I would like to run it again. Best regards, Goetz. > -----Original Message----- > From: security-dev On Behalf Of > Rajan Halade > Sent: Mittwoch, 11. Juli 2018 17:42 > To: Baesken, Matthias ; security- > dev at openjdk.java.net > Subject: Re: > security/infra/java/security/cert/CertPathValidator/certification/QuoVadisC > A.java fails in jdk > > Thanks for the report, I have filed JDK-8207059. Yes, the test certificate used > here need to be updated. > > - Rajan > > > On 7/11/18 7:43 AM, Baesken, Matthias wrote: > > > > > ... and in stdout there is a better message that seems to show the > reason , a certificate is expected to be "GOOD" but it has been revoked > Fri Jan 19 15:39:57 CET 2018 . > > Should the test be updated with more recent certs (seems they > are hardwired in the test java source) ? > From jai.forums2013 at gmail.com Tue Sep 18 13:36:27 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 18 Sep 2018 19:06:27 +0530 Subject: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid ECDH ServerKeyExchange with non-default security provider Message-ID: <31ab966b-1f35-7cdd-3541-4b81e2d0bf01@gmail.com> I have been testing some projects that I know of, with Java 11 RC. There's one specific test that has been failing for me, for a while now, during SSL handshake. Took me a while to narrow it down given the size of the application and the nature of the exception. The exception occurs during SSL handshake between a client and a server (both Java and both using Java 11 RC) and it kept throwing: Exception in thread "main" javax.net.ssl.SSLHandshakeException: Invalid ECDH ServerKeyExchange signature ??? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) ??? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) ??? at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) ??? at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) ??? at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) ??? at java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.(ECDHServerKeyExchange.java:329) ??? at java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeConsumer.consume(ECDHServerKeyExchange.java:535) ??? at java.base/sun.security.ssl.ServerKeyExchange$ServerKeyExchangeConsumer.consume(ServerKeyExchange.java:103) ??? at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) ??? at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) ??? at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421) ??? at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178) ??? at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) ??? at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) ??? at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) ??? at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) ??? at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567) ??? at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) ??? at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581) ??? at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509) ??? at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245) ... This is consistently reproducible if, in the scheme of things: ?1. the cipher suite selected is a ECDHE one. For example TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. The TLS version itself is TLSv1.2 (both server and client). ?2. One side of the client/server, is backed by BouncyCastle as the security provider (very specifically for SignatureSpi). Assuming the server side is using BouncyCastle provider, what's happening is that during the handshake, the server side uses the RSASSA-PSS algorithm, backed by this provider and writes out the signature. The client side uses SunRsaSign (default provider) and tries to verify this RSASSA-PSS signature and fails with that above exception. FWIW, I don't believe the signature algorithm matters as long as the cipher is ECDHE backed and the client and server side use a different security provider. All this works perfectly fine when both the sides use the default provider and bouncycastle isn't involved. I was able to get this reproducible in a very simple server/client standalone program. I think this can even be demonstrated in a jtreg test but I don't have enough experience with it to see how to trigger a server in a separate JVM and then use a client for testing. The reproducer code (Server.java and Client.java) is at the end of this mail along with instructions on how to reproduce it. I was also able to narrow down this issue down to a specific part of the JDK code. sun.security.ssl.SignatureScheme#getSignature[1] inits the Signature instance for either signing or verifying. However it sets up the signature parameters _after_ the init is done and in fact, there's an explicit note[2] stating what/why it's doing it there. I admit, I don't have much knowledge of the Java SSL parts and none in these internal details and don't understand the details of that implementation notes. However, just to try it out, I switched the order of it by using this local patch: diff -r fbb71a7edc1a src/java.base/share/classes/sun/security/ssl/SignatureScheme.java --- a/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java??? Sat Aug 25 20:16:43 2018 +0530 +++ b/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java??? Tue Sep 18 18:47:52 2018 +0530 @@ -467,18 +467,16 @@ ???????? } ? ???????? Signature signer = JsseJce.getSignature(algorithm); +??????? if (signAlgParameter != null) { +??????????? signer.setParameter(signAlgParameter); +??????? } + ???????? if (key instanceof PublicKey) { ???????????? signer.initVerify((PublicKey)(key)); ???????? } else { ???????????? signer.initSign((PrivateKey)key); ???????? } ? -??????? // Important note:? Please don't set the parameters before signature -??????? // or verification initialization, so that the crypto provider can -??????? // be selected properly. -??????? if (signAlgParameter != null) { -??????????? signer.setParameter(signAlgParameter); -??????? } ? ???????? return signer; ???? } Built this version and gave it a try with the sample code below (and also against the actual application). Both worked fine. I tried cases: ?- where one side had default provider and other side had bouncycastle. ?- where both sides were default provider Any thoughts on this issue? Here's the code to reproduce it: Server.java ----------- import java.io.*; import java.net.*; import javax.net.ssl.*; import java.util.*; import java.util.concurrent.*; import java.security.*; import com.sun.net.httpserver.*; import java.security.cert.*; public class Server { ??? private static final String keyFilename = "keystore"; ??? private static final String keystorePass = "passphrase"; ??? private static final String WEB_APP_CONTEXT = "/test"; ??? public static void main(final String[] args) throws Exception { ??? ??? if (args.length == 1 && args[0].equals("--use-bouncy-castle")) { ??? ??? ??? // enable bouncycastle ??? ??? ??? Security.insertProviderAt(new org.bouncycastle.jce.provider.BouncyCastleProvider(), 2); ??? ??? ??? System.out.println("Using bouncycastle provider"); ??? ??? } else { ??? ??? ??? System.out.println("Using JRE security provider"); ??? ??? } ??? ??? final int port = 12345; ??? ??? // start the server ??????? final HttpsServer server = startServer("localhost", port); ??????? // stop server on shutdown ??????? Runtime.getRuntime().addShutdownHook(new Thread(() -> { ??????? ??? if (server != null) { ??????? ??? ??? server.stop(0); ??? ??? ??? ??? System.out.println("Stopped server"); ??????? ??? } ??????? })); ??? } ??? private static HttpsServer startServer(final String host, final int port) throws Exception { ??????? final HttpsServer server = HttpsServer.create(new InetSocketAddress(host, port), 0); ??? ??? final Thread t = new Thread(() -> { ??? ??? ??? try { ??? ??? ??? ??? final SSLContext sslctx = SSLContext.getInstance("TLSv1.2"); ??? ??? ??????? final KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509"); ??? ??? ??????? final KeyStore ks = KeyStore.getInstance("JKS"); ??? ??? ??????? try (final FileInputStream fis = new FileInputStream(keyFilename)) { ??? ??? ??????????? ks.load(fis, keystorePass.toCharArray()); ??? ??? ??????? } ??? ??? ??????? kmf.init(ks, keystorePass.toCharArray()); ??? ??? ??????? sslctx.init(kmf.getKeyManagers(), null, null); ??? ??? ??????? final SSLParameters sslParameters = sslctx.getDefaultSSLParameters(); ??? ??? ??????? sslParameters.setProtocols(new String[] { "TLSv1.2" }); ??? ??? ??????? // use ECDHE specific ciphersuite ??? ??? ??????? sslParameters.setCipherSuites(new String[] { "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"}); ??? ??? ??????? server.setHttpsConfigurator(new HttpsConfigurator(sslctx) { ??? ??? ??????? ??? @Override ??? ??? ??????? ??? public void configure(final HttpsParameters params) { ??? ??? ??????? ??? ??? params.setSSLParameters(sslParameters); ??? ??? ??????? ??? } ??? ??? ??????? }); ??? ??? ??????? server.createContext(WEB_APP_CONTEXT, (exchange)-> exchange.sendResponseHeaders(200, -1)); ??? ??? ??? ??? server.start(); ??? ??? ??? ??? System.out.println("Started server at " + server.getAddress()); ??? ??? ??? } catch(Exception e) { ??? ??? ??? ??? throw new RuntimeException(e); ??? ??? ??? } ??? ??? }); ??? ??? t.start(); ??? ??? return server; ??? } } To run this: (you'll need bouncycastle jar in your classpath. you can get it from[3]) java -cp bcprov-jdk15on-1.58.jar Server.java --use-bouncy-castle You should see output like: Using bouncycastle provider Started server at /127.0.0.1:12345 (not passing --use-bouncy-castle will start the server with the regular default JRE provided security provider). The server is now up and running and ready to accept the request. See how to run the client below. This server code uses a keystore file which is part of the OpenJDK repo and can be obtained from [4] and stored in the current working directory. Client.java ------------ import java.io.*; import java.net.*; import javax.net.ssl.*; import java.util.*; import java.util.concurrent.*; import java.security.*; import com.sun.net.httpserver.*; import java.security.cert.*; public class Client { ??? private static final String WEB_APP_CONTEXT = "/test"; ??? public static void main(final String[] args) throws Exception {??? ??? ??? ??? HttpsURLConnection.setDefaultHostnameVerifier((h, s) -> {return true;}); ??? ??? ??? ??? final int port = 12345; ??? ??? final URL targetURL = new URL("https://localhost:" + port + WEB_APP_CONTEXT); ??? ??? final HttpsURLConnection conn = (HttpsURLConnection) targetURL.openConnection(); ??? ??? ??? ??? // use a SSLSocketFactory which "trusts all" ??? ??? final SSLContext sslctx = SSLContext.getInstance("TLSv1.2"); ??????? sslctx.init(null, new TrustManager[] {new TrustAll()}, null); ??? ??? conn.setSSLSocketFactory(sslctx.getSocketFactory()); ??? ??? // read ??? ??? try (final InputStream is = conn.getInputStream()) { ??? ??????? is.read(); ??? ??? } ??? ??? System.out.println("Received status code " + conn.getResponseCode()); ??? } ??? private static class TrustAll implements X509TrustManager { ??? ??? @Override ??? ??? public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException { ??? ??? ??? return; ??????? } ??? ??? @Override ??? ??? public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { ??? ??? ??? return; ??? ??? } ??? ??? @Override ??? ??? public X509Certificate[] getAcceptedIssuers() { ??? ??? ??? return new X509Certificate[0]; ??? ??? } ??? } } To run the client: java Client.java A successful execution will show: Received status code 200 whereas a failed execution should throw the exception shown previously in the mail. [1] http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l463 [2] http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l476 [3] http://repo1.maven.org/maven2/org/bouncycastle/bcprov-jdk15on/1.58/bcprov-jdk15on-1.58.jar [4] http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/test/jdk/javax/net/ssl/etc/keystore -Jaikiran From jai.forums2013 at gmail.com Tue Sep 18 13:40:01 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 18 Sep 2018 19:10:01 +0530 Subject: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid ECDH ServerKeyExchange with non-default security provider In-Reply-To: <31ab966b-1f35-7cdd-3541-4b81e2d0bf01@gmail.com> References: <31ab966b-1f35-7cdd-3541-4b81e2d0bf01@gmail.com> Message-ID: <5e0078ba-a367-1b72-01a0-9267166ef541@gmail.com> On 18/09/18 7:06 PM, Jaikiran Pai wrote: > FWIW, I don't believe the signature algorithm matters That may not be accurate since I haven't tried it out with any other algorithm, so please ignore this bit from the original mail. -Jaikiran From jini at zeus.net.au Tue Sep 18 14:07:11 2018 From: jini at zeus.net.au (Peter) Date: Wed, 19 Sep 2018 00:07:11 +1000 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <08f168e5-4c96-4946-77bf-5744a57f3921@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> <5B9FA0E2.7050607@zeus.net.au> <08f168e5-4c96-4946-77bf-5744a57f3921@oracle.com> Message-ID: <5BA1068F.5000606@zeus.net.au> Hi Alan, I'm a little time poor presently, but will put it on my todo list. Admittedly this is one part of the JVM that could have better test coverage. Implementing a custom SecurityManager was fraught with recursion difficulties, I documented the pitfalls in our code. Anyone who's using a custom security manager with Java 8, will now be using System.setSecurityManager() instead of the command line option due to this bug, I don't think it's publicly documented, it's probably fine to deprecate System.setSecurityManager(), but not to remove at this time. Ironically we converted to the command line option with Java 6. I understand the need to make the SecurityManager reference immutable. Incidentally, our SecurityManager implementation is dynamic, it can grant and remove permissions, provided they haven't been allowed to escape the guards control, but it's also concurrent and high scaling, mostly because we do a lot of network calls, which invoke a lot of security checks. We also have a custom cache-less policy provider that's high scaling using immutability, thread confinement and garbage collection, it also orders permission checks for best performance. The sun policy provider performs poorly mostly due to it's blocking cache, loosing the cache makes a big performance improvement. Regards, Peter. On 18/09/2018 5:39 PM, Alan Bateman wrote: > On 17/09/2018 13:41, Peter Firmstone wrote: >> Has the attached regression been fixed "Re: >> -Djava.security.manager=problems for service provider"? I recently >> changed all our code to use System.setSecurityManager(), because of >> this regression, prior to that we used the command line option, it's >> going to take some time to revert... > I think it would be better to start a new thread with a test case that > demonstrates the issue with JDK 11 builds. As I think I noted in the > original discussion (from March) there were several issues with > recursive initialization and handling of resources that have been > fixed in recent releases. I can't say if they address the the specific > issue you were running into with JDK 8 but it would be useful to know > if there is still an issue or not. > > -Alan From mbalao at redhat.com Tue Sep 18 14:29:47 2018 From: mbalao at redhat.com (Martin Balao) Date: Tue, 18 Sep 2018 16:29:47 +0200 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> Message-ID: Hi Valerie, Thanks for your comments. Here it is Webrev.11: * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.11/ * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.11.zip L397: That's right. I was trying to simplify the code but missed this. Thanks. L471: The key reference counter has to be decremented under any exception (P11Key.decNativeKeyRef method call). But, yes, no exception different than PKCS11Exception should be thrown. Reverted this change. L99: Comment changed. It should be better now. L148-L149: In fact, I'd enforce this and disable the feature for all token keys. Token keys are permanent and extracting them is risky. This criteria was already applied when dealing with key stores (P11Keystore class). Yes, this feature is enabled for NSS only because it's the only backend we currently know that is affected by this memory "leak" issue. If there were any other software-token backend affected, we can try this feature there too. HSMs shouldn't have any problem. I prefer to take a more conservative approach and enable the feature only in those cases in which it's really necessary. All other cases, default to the previous mechanism for freeing memory. This does not replace the PhantomReference approach; both work together and are complementary. In cases where temporary keys feature is disabled or when a temporary key client is not behaving correctly (i.e.: leaking stateful operations like "cipher" or "signature" in an intermediate state with the native key initialized), PhantomReference approach will be the last chance to free memory. The native key object can be destroyed (C_DestroyObject call) either from the PhantomReference mechanism or from the temporary keys mechanism. There shouldn't be any conflict between them. If it's destroyed through temporary keys mechanism, then we know that the P11Key object is alive (refereced) and thus PhantomReference destruction won't be taking place at the same time. Once the key is deleted, keyID is set to 0 and session to null. Thus, PhantomReference destruction won't have any effect when executed later. If we think of the other case (when the key is freed by PhantomReference), we have a P11Key object with a native key initialized but with no references to it. Thus, destroyNativeKey method won't be called and SessionKeyRef.disposeNative is the only method that will delete the key. L157: that's right, synchronization has to be at class level. Fixed. L1343: It's not the same session: this.session was assigned a new value (this.session = session;) before calling addObject. L1363: removeObject is called for the session, inside setKeyIDAndSession: "this.session.removeObject();". Null is set to this.session instance variable after this call. In regards to the refactorings you proposed, the problem I see with moving key reference incrementing/decrementing to PKCS11.java is that some operations are stateful. I.e.: encryption. When we initialize the operation with C_EncryptInit, the key id is the 3rd parameter. Destroying the key id and then doing C_EncryptUpdate sounds incorrect to me. Have you tried the regression testing suite after this refactoring? (I see some parts commented). In regards to removing the tmpNativeKey parameter (used to explicitly disable the feature for new P11Key objects), how do you handle the P11KeyStore case? We don't want temporary keys there. Kind regards, Martin.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Tue Sep 18 15:31:55 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 18 Sep 2018 17:31:55 +0200 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: On 2018-09-16 07:05, David Black wrote: > 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). > You're right that this does not really say much about performance in a "standard application". The micro in the bug is simply a verification that constant folding does happen as hypothesized. It's plausible this can help the JIT optimize and inline more aggressively, possibly leading to "real" speedups higher up in the stack on some "real" applications. The problem, however, is that there's no such thing as a "standard application" benchmark. Most industry standard benchmarks are really microbenchmarks in disguise, where the score is determined by behavior in a limited number of bottlenecks, and the probability any of these bottlenecks will be affected by any particular optimization is disturbingly close to zero. Thus, using "we need to see a real performance difference on some real benchmark" as a criterion then very quickly becomes a strong filter against almost all optimizations. Implemented as a requirement that'd be devastating for the platform. Instead we've shifted towards treating an improvement in a targeted microbenchmarks while not causing any regressions on a wide range of standard benchmars as an accept criterion. It's not a perfect strategy, but for a complex and performance critical platform like the OpenJDK I think it's far better than the alternatives. /Claes From norman.maurer at googlemail.com Tue Sep 18 16:08:33 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Tue, 18 Sep 2018 09:08:33 -0700 Subject: sun.security.ssl.ProtocolVersion.valueOf(...) in Java8 and TLSv1.3 In-Reply-To: <2005a485-1cac-2049-223d-beaa45084dbe@oracle.com> References: <2005a485-1cac-2049-223d-beaa45084dbe@oracle.com> Message-ID: <3AB902DD-412B-4ECB-9772-529D5274EC52@googlemail.com> I did some testing and it seems to ?just work?. I will do a bit more and then come back you + filling the enhancement request. Bye Norman > On 17. Sep 2018, at 18:04, Xuelei Fan wrote: > > Hi Norman, > > In general, it is risk to support unknown protocol version in the key/trust manager implementation. The trust manager implemented for TLS 1.2 and prior versions might not work with TLS 1.3 probably. Did you make the evaluation? Would you mind contribute a patch? > > Please feel free to file an enhancement request, for further evaluation when there is a chance. > > Thanks, > Xuelei > > On 9/17/2018 5:28 AM, Norman Maurer wrote: >> Hi all, >> In netty we support using OpenSSL for native SSL which recently added TLSv1.3 support as part of OpenSSL 1.1.1. In an ideal world we would be able to use this even with Java8 which is almost true except the fact that sun.security.ssl.ProtocolVersion.valueOf(?) will throw an IllegalArgumentException when the string ?TLSv1.3? is provided. This is problematic as this happens during validation in the default TrustManager used by the OpenJDK. >> The stack looks something like this: >> java.lang.IllegalArgumentException: TLSv1.3 >> at sun.security.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:187) >> at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:258) >> at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136) >> I could work around this by just wrap the SSLSession and return TLSv1.2 during validation as the same validation should be done as in the TLSv1.2 implementation but this is really just a hack.So I wonder if you would consider to either add support for parsing TLSv1.3 to the internal enum or just handle it more gracefully. Another thing that would work of course is to always provide a custom X509ExtendedTrustManager but I hoped to be able to re-use the default implementation as it already implements a lot of verification logic. >> WDYT ? >> Norman From sean.mullan at oracle.com Tue Sep 18 16:22:19 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 18 Sep 2018 12:22:19 -0400 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <6f4e1180-40e7-74e6-bfbd-56469fdde925@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <6f4e1180-40e7-74e6-bfbd-56469fdde925@oracle.com> Message-ID: <04eed990-0147-6f4b-fa51-06f5e1a76aa7@oracle.com> On 9/14/18 1:17 PM, Roger Riggs wrote: > Hi Sean, > > Looks good. > > I would quibble with System.java:335-6 > > "Java virtual machine does not allow a security manager" > > I would say only "a security manager is not allowed to be set dynamically." > > There is no need to identify the Java virtual machine.? The VM itself > has nothing to do with it. > Also remove the same phrase in SecurityManager class javadoc. In this context "Java virtual machine" refers to the Java run-time, and is used similarly in other places in the javadoc. But I will change it as you suggested to avoid any confusion. --Sean From rajan.halade at oracle.com Tue Sep 18 17:05:16 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 18 Sep 2018 10:05:16 -0700 Subject: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails in jdk In-Reply-To: References: <1ce14de946914cf89ec60b5837e1129f@sap.com> <41263153-e2e1-f9e6-ab2d-010688b74d57@oracle.com> Message-ID: <6a50692c-7fa8-081e-e72e-05fd52b80104@oracle.com> We found an issue with revocation of intermedicate CA issued by QuoVadis which is fixed by CA now. I am waiting to get new test certificates to fix this bug. Thanks, Rajan On 9/18/18 3:06 AM, Lindenmaier, Goetz wrote: > Hi Rajan, > > are you working on this issue? We have this test disabled, I would like to run it again. > > Best regards, > Goetz. > >> -----Original Message----- >> From: security-dev On Behalf Of >> Rajan Halade >> Sent: Mittwoch, 11. Juli 2018 17:42 >> To: Baesken, Matthias ; security- >> dev at openjdk.java.net >> Subject: Re: >> security/infra/java/security/cert/CertPathValidator/certification/QuoVadisC >> A.java fails in jdk >> >> Thanks for the report, I have filed JDK-8207059. Yes, the test certificate used >> here need to be updated. >> >> - Rajan >> >> >> On 7/11/18 7:43 AM, Baesken, Matthias wrote: >> >> >> >> >> ... and in stdout there is a better message that seems to show the >> reason , a certificate is expected to be "GOOD" but it has been revoked >> Fri Jan 19 15:39:57 CET 2018 . >> >> Should the test be updated with more recent certs (seems they >> are hardwired in the test java source) ? >> From sean.mullan at oracle.com Tue Sep 18 17:35:23 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 18 Sep 2018 13:35:23 -0400 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> Message-ID: On 9/14/18 9:28 AM, David Lloyd wrote: >> 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). > I can say that this explanation would be more palatable by far if the > security manager as a whole could be deprecated all at once. I for > one would certainly be happy to remove support for it in the software > that I maintain (it's a considerable amount of code and other > gymnastics to be sure). However, I'm not sure that our users and > customers will be so easily convinced. My understanding is that there > are plenty of corporate and perhaps government security standards that > dictate security manager usage. > > If the security manager itself is not yet to be deprecated, then I > have a much harder time accepting this argument. It's not really a > stepping stone in any practical sense, at least not from our > perspective, unless that step is "break JBoss first, and then break > everyone else later"; to be fair though I'm approximately 200% more > cynical in the morning.:) Right now we are taking a long look at the Security Manager and what its future path should be. We started this initiative back in February with a survey [1] to better understand how people use the Security Manager (outside of applets and Web Start applications) and what challenges and issues they had in using it. In JDK 10 we removed some old methods that were not useful anymore [2]. This particular issue focuses on improving the performance of applications that never use the Security Manager. It is the first of potentially several enhancements in that area. As for the future of the Security Manager, deprecating and eventually removing it is one potential option; but there are other options we are looking at such as simplifying it. What we really don't want to do is continue with what we are doing today and keeping it going for what is probably a small percentage of users. And we also don't have the resources to enhance it to address everyone's needs. At the end of the day it takes a lot of effort to simply maintain the JDK code to run properly and securely under a Security Manager. With that said, I encourage everyone to have an open mind going forward as we request your input on different paths we may take. And keep sending the comments. We need more use cases and data. Thanks, Sean [1] https://www.surveymonkey.com/results/SM-PSJ6ZNMZ8/ [2] https://bugs.openjdk.java.net/browse/JDK-8186535 From Alan.Bateman at oracle.com Tue Sep 18 19:51:22 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 18 Sep 2018 20:51:22 +0100 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <5BA1068F.5000606@zeus.net.au> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> <5B9FA0E2.7050607@zeus.net.au> <08f168e5-4c96-4946-77bf-5744a57f3921@oracle.com> <5BA1068F.5000606@zeus.net.au> Message-ID: <69982972-2fc5-595e-695a-b47527c0d406@oracle.com> On 18/09/2018 15:07, Peter wrote: > Hi Alan, > > I'm a little time poor presently, but will put it on my todo list.? > Admittedly this is one part of the JVM that could have better test > coverage.?? Implementing a custom SecurityManager was fraught with > recursion difficulties, If you can get time to try to reproduce with a JDK 11 or 12 build then it would be useful. As things stand there are still issues with using lambda expressions in the checkPermission method [1] but I believe the other recursive initialization issues that arise with malformed policy files or lcating resources for exception messages have been resolved. -Alan. [1] https://bugs.openjdk.java.net/browse/JDK-8155659 From adam.petcher at oracle.com Tue Sep 18 20:01:22 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 18 Sep 2018 16:01:22 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <81dd5ea3-5d0b-5f4d-9e8d-bd8d98fcc49f@oracle.com> <59eb69e2-4f55-1ed2-b505-0304160122dc@oracle.com> Message-ID: On 9/11/2018 11:07 AM, Adam Petcher wrote: > > I still haven't been convinced that this lack of interoperability is a > significant problem. In the proposed design, the new KeyFactory will > not support ECPrivateKeySpec, and the implementation will produce > private keys that inherit from PrivateKey, but not ECPrivateKey. > Specifically, what problems in JCE are introduced by this design? How > are these interoperability issues different from the ones you > encounter with a PKCS11 provider that doesn't export private keys? If > the developer wants more interoperability, why not use SunEC? If we > decide that we want the new implementation to have better > interoperability in the future, does something prevent us from > enhancing it? These questions are for anyone who can help me > understand the objections that have been raised related to > interoperability. A week has passed since I asked these questions to the mailing list, and I haven't gotten any answers. Without additional information, I'm not motivated to change the interoperability goals in the draft JEP. From mstjohns at comcast.net Tue Sep 18 20:24:12 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 18 Sep 2018 16:24:12 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <81dd5ea3-5d0b-5f4d-9e8d-bd8d98fcc49f@oracle.com> <59eb69e2-4f55-1ed2-b505-0304160122dc@oracle.com> Message-ID: On 9/18/2018 4:01 PM, Adam Petcher wrote: > On 9/11/2018 11:07 AM, Adam Petcher wrote: > >> >> I still haven't been convinced that this lack of interoperability is >> a significant problem. In the proposed design, the new KeyFactory >> will not support ECPrivateKeySpec, and the implementation will >> produce private keys that inherit from PrivateKey, but not >> ECPrivateKey. Specifically, what problems in JCE are introduced by >> this design? How are these interoperability issues different from the >> ones you encounter with a PKCS11 provider that doesn't export private >> keys? If the developer wants more interoperability, why not use >> SunEC? If we decide that we want the new implementation to have >> better interoperability in the future, does something prevent us from >> enhancing it? These questions are for anyone who can help me >> understand the objections that have been raised related to >> interoperability. > > A week has passed since I asked these questions to the mailing list, > and I haven't gotten any answers. Without additional information, I'm > not motivated to change the interoperability goals in the draft JEP. Adam - Basically, the JCE is all about plugging in not about the implementations.? If this is truly an EC library, I should be able to get the benefit of your library with very minimal changes - e.g. specifying your provider in the various getInstance() calls.?? As it stands, I doubt this will end up in anyone's "must use" category because it will break existing code. You want folks to convince you that interoperability is a significant problem when what we (or at least I) want is for you to convince us that these interop breaks are warranted due to how wonderful your approach is and that they're absolutely necessary due the secret sauce of wonderfulness.? You're not there yet. As for PKCS11 - there are exportable and non-exportable private keys (e.g. PKCS11 with an accelerator vs an HSM for example).? The exportable ones show up as ECPrivateKeys, the non-exportable ones as PrivateKeys (and I think with an underlying type of PKCS11Key...).? So it follows the model for exportable keys.? And every PKCS11 provider I've used at least has a way of IMPORTING ECPrivateKeys. Later, Mike From valerie.peng at oracle.com Tue Sep 18 23:48:28 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 18 Sep 2018 16:48:28 -0700 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> Message-ID: <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> Hi Martin, I am ok with your conservation choice of only applying this when using NSS. If we are only applying this for NSS, we should really refactor the code to minimize the impact on callers and P11Key class. My prototype code may be on the extreme end of minimizing changes. But the current webrev can use some refactoring also. With your explanation, I now understand your model better. How about the refactoring in P11Key class? Is there a reason for not doing this? I did test my prototype code against existing regression tests (except the KeyStore ones as more API changes are needed for persistent keys which I have not covered in prototype) but I ran into some strange errors in some native p11 calls which I did not touch so I commented them out and just checked the part of reference count, etc. I will take a closer look at the KeyStore case and let you know. Thanks, Valerie On 9/18/2018 7:29 AM, Martin Balao wrote: > Hi Valerie, > > Thanks for your comments. > > Here it is Webrev.11: > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.11/ > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.11.zip > > > > L397: That's right. I was trying to simplify the code but missed this. > Thanks. > L471: The key reference counter has to be decremented under any > exception (P11Key.decNativeKeyRef method call). But, yes, no exception > different than PKCS11Exception should be thrown. Reverted this change. > > > L99: Comment changed. It should be better now. > L148-L149: In fact, I'd enforce this and disable the feature for all > token keys. Token keys are permanent and extracting them is risky. > This criteria was already applied when dealing with key stores > (P11Keystore class). > > Yes, this feature is enabled for NSS only because it's the only > backend we currently know that is affected by this memory "leak" > issue. If there were any other software-token backend affected, we can > try this feature there too. HSMs shouldn't have any problem. I prefer > to take a more conservative approach and enable the feature only in > those cases in which it's really necessary. All other cases, default > to the previous mechanism for freeing memory. > > This does not replace the PhantomReference approach; both work > together and are complementary. In cases where temporary keys feature > is disabled or when a temporary key client is not behaving correctly > (i.e.: leaking stateful operations like "cipher" or "signature" in an > intermediate state with the native key initialized), PhantomReference > approach will be the last chance to free memory. The native key object > can be destroyed (C_DestroyObject call) either from the > PhantomReference mechanism or from the temporary keys mechanism. There > shouldn't be any conflict between them. If it's destroyed through > temporary keys mechanism, then we know that the P11Key object is alive > (refereced) and thus PhantomReference destruction won't be taking > place at the same time. Once the key is deleted, keyID is set to 0 and > session to null. Thus, PhantomReference destruction won't have any > effect when executed later. If we think of the other case (when the > key is freed by PhantomReference), we have a P11Key object with a > native key initialized but with no references to it. Thus, > destroyNativeKey method won't be called and > SessionKeyRef.disposeNative is the only method that will delete the key. > > L157: that's right, synchronization has to be at class level. Fixed. > > L1343: It's not the same session: this.session was assigned a new > value (this.session = session;) before calling addObject. > > L1363: removeObject is called for the session, inside > setKeyIDAndSession: "this.session.removeObject();". Null is set to > this.session instance variable after this call. > > In regards to the refactorings you proposed, the problem I see with > moving key reference incrementing/decrementing to PKCS11.java is that > some operations are stateful. I.e.: encryption. When we initialize the > operation with C_EncryptInit, the key id is the 3rd parameter. > Destroying the key id and then doing C_EncryptUpdate sounds incorrect > to me. Have you tried the regression testing suite after this > refactoring? (I see some parts commented). In regards to removing the > tmpNativeKey parameter (used to explicitly disable the feature for new > P11Key objects), how do you handle the P11KeyStore case? We don't want > temporary keys there. > > Kind regards, > Martin.- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Sep 18 23:52:09 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 18 Sep 2018 16:52:09 -0700 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: <7203910f-333f-89d5-ea04-ffb4b42ac542@oracle.com> <2d949ed6-5089-1cae-0960-2790afcb25d2@oracle.com> <8c273087-e41d-3978-4d93-8cb5f7cc9bb8@redhat.com> <99cc28cf-4550-1894-b366-9da2a49e70f8@oracle.com> Message-ID: <17bb8a43-8fea-2676-d038-4bcbf0a6b3b1@oracle.com> Test update looks fine and regression test run is clear. I have no more comments. Thanks, Valerie On 9/12/2018 4:22 AM, Martin Balao wrote: > Hi Valerie, > > Thanks for your answer. > > Webrev.09: > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.09/ > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.09.zip > > > In TestTLS12.java, we now capture any exception during initialization > phase and skip test execution if that happens. > > Kind regards, > Martin.- > > On Wed, Sep 12, 2018 at 2:20 AM, Valerie Peng > wrote: > > Hi, Martin, > > I am ok with your option#1. > Note that your test fails at different places of the code, so you > will need to check and skip test execution before those exception > are thrown. > > Valerie > > > On 9/11/2018 7:54 AM, Martin Balao wrote: >> Hi Valerie, >> >> On Fri, Aug 31, 2018 at 9:16 PM, Valerie Peng >> > wrote: >> >> Hi Martin, >> >> In TestTLS12.java, you call the initSecmod() inside >> initialize() and when initSecmod() returns false, you return >> from initialize() and continue down the main(). Is this >> intentional? Other tests seems to be skipping execution when >> initSecmod() return false. >> >> >> This test skips execution too. That's because?shouldRun method >> returns false if?sunPKCS11NSSProvider variable is null (which it >> is if initSecmod returns false). >> >> >> Changes in webrev.08 resolves 2 out of the 4 failure cases >> for TestTLS12.java. However, when I submit the changes for >> testing, it failed on some OS (see below): >> >> macosx-x64: >> >> jib > STDOUT: >> jib > nssLibDir: >> /scratch/mesos/jib-master/install/jpg/tests/jdk/nsslib/nsslib-macosx_x64/3.35/nsslib-macosx_x64-3.35.zip/nsslib/ >> jib > STDERR: >> jib > java.security.ProviderException: Could not >> initialize NSS >> jib >? ?at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:218) >> jib >? ?at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:113) >> jib >? ?at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:110) >> jib >? ?at >> java.base/java.security.AccessController.doPrivileged(Native >> Method) >> jib >? ?at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:110) >> jib >? ?at PKCS11Test.getSunPKCS11(PKCS11Test.java:156) >> jib >? ?at TestTLS12.initialize(TestTLS12.java:416) >> jib >? ?at TestTLS12.main(TestTLS12.java:84) >> jib >? ?at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> jib >? ?at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> jib >? ?at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> jib >? ?at java.base/java.lang.reflect.Me >> thod.invoke(Method.java:566) >> jib >? ?at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> jib >? ?at java.base/java.lang.Thread.run(Thread.java:834) >> jib > Caused by: java.io.IOException: NSS initialization >> failed >> jib >? ?at >> jdk.crypto.cryptoki/sun.security.pkcs11.Secmod.initialize(Secmod.java:234) >> jib >? ?at >> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:213) >> jib >? ?... 13 more >> jib > >> jib > JavaTest Message: Test threw exception: >> java.security.ProviderException: Could not initialize NSS >> >> >> windows-x64: >> >> jib > STDOUT: >> jib > nssLibDir: >> C:\ADE\mesos\work_dir\jib-master\install\jpg\tests\jdk\nsslib\nsslib-windows_x64\3.35\nsslib-windows_x64-3.35.zip\nsslib\ >> jib > SunPKCS11 provider: SunPKCS11-NSSKeyStore version 12 >> jib > STDERR: >> jib > java.security.ProviderException: SunJSSE already >> initialized in non-FIPS mode >> jib >? ?at >> java.base/sun.security.ssl.SunJSSE.ensureFIPS(SunJSSE.java:94) >> jib >? ?at >> java.base/sun.security.ssl.SunJSSE.(SunJSSE.java:146) >> jib >? ?at >> java.base/sun.security.ssl.SunJSSE.(SunJSSE.java:118) >> jib >? ?at >> java.base/com.sun.net.ssl.internal.ssl.Provider.(Provider.java:47) >> jib >? ?at TestTLS12.initialize(TestTLS12.java:424) >> jib >? ?at TestTLS12.main(TestTLS12.java:84) >> jib >? ?at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> jib >? ?at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> jib >? ?at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> jib >? ?at java.base/java.lang.reflect.Me >> thod.invoke(Method.java:566) >> jib >? ?at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> jib >? ?at java.base/java.lang.Thread.run(Thread.java:834) >> jib > >> jib > JavaTest Message: Test threw exception: >> java.security.ProviderException: SunJSSE already >> initialized in non-FIPS mode >> >> >> >> The 2 tests that initialize NSS in FIPS mode (TrustManagerTest >> and ClientJSSEServerJSSE) only run on Solaris. My guess is that >> these failures are not particular to TestTLS12 but to NSS + FIPS >> support on these setups. I won't be able to reproduce the macOS >> failure and I'm not sure if I'll be able to reproduce in my >> Windows x86_64 environment. >> >> I propose the following options: >> >> ?1) Make the test skip macOS & Windows x86_64 (and any other >> platform that fails to initialize the SunPKCS11 provider) >> >> ?2) If you can provide access to a testing environment where I >> can reproduce these failures, I can see what's happening >> >> I intentionally want to use FIPS in NSS configuration because it >> represents a real use case, and is what motivated us to support >> TLS 1.2 in SunPKCS11. So, even though removing FIPS would be an >> option, I prefer not to take it. >> >> Kind regards, >> Martin.- >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Wed Sep 19 12:10:33 2018 From: mbalao at redhat.com (Martin Balao) Date: Wed, 19 Sep 2018 14:10:33 +0200 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: <17bb8a43-8fea-2676-d038-4bcbf0a6b3b1@oracle.com> References: <7203910f-333f-89d5-ea04-ffb4b42ac542@oracle.com> <2d949ed6-5089-1cae-0960-2790afcb25d2@oracle.com> <8c273087-e41d-3978-4d93-8cb5f7cc9bb8@redhat.com> <99cc28cf-4550-1894-b366-9da2a49e70f8@oracle.com> <17bb8a43-8fea-2676-d038-4bcbf0a6b3b1@oracle.com> Message-ID: On Wed, Sep 19, 2018 at 1:52 AM, Valerie Peng wrote: > Test update looks fine and regression test run is clear. I have no more > comments. > Thanks, > Valerie > Submit-repository tests passed. Integrated to baseline then: * http://hg.openjdk.java.net/jdk/jdk/rev/bccd9966f1ed Thanks Valerie for your review :-) I'll propose JDK8 and JDK7 backports now. Kind regards, Martin.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasadarao.koppula at oracle.com Wed Sep 19 14:40:00 2018 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Wed, 19 Sep 2018 07:40:00 -0700 (PDT) Subject: [8u-dev] RFR JDK-8187218 & JDK-8131051, two krb5 fixes on renewable Message-ID: <5574b292-1143-456d-b53d-88d650bcfb56@default> Could you please review the following fixes for 8u-dev? jbs: https://bugs.openjdk.java.net/browse/JDK-8187218, https://bugs.openjdk.java.net/browse/JDK-8131051 webrev: http://cr.openjdk.java.net/~pkoppula/8187218/webrev.00/ Thanks, Prasad.K -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Sep 19 15:38:33 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 19 Sep 2018 23:38:33 +0800 Subject: [8u-dev] RFR JDK-8187218 & JDK-8131051, two krb5 fixes on renewable In-Reply-To: <5574b292-1143-456d-b53d-88d650bcfb56@default> References: <5574b292-1143-456d-b53d-88d650bcfb56@default> Message-ID: Change looks fine, but the code style of lines 947-954 is quite different from normal, including, no space after keywords, wrong indentation of inner block and wrapped line, brace and else not on the same line, etc. --Max > On Sep 19, 2018, at 10:40 PM, Prasadrao Koppula wrote: > > Could you please review the following fixes for 8u-dev? > > jbs: https://bugs.openjdk.java.net/browse/JDK-8187218, > https://bugs.openjdk.java.net/browse/JDK-8131051 > webrev: http://cr.openjdk.java.net/~pkoppula/8187218/webrev.00/ > > Thanks, > Prasad.K From adam.petcher at oracle.com Wed Sep 19 15:45:49 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 19 Sep 2018 11:45:49 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <81dd5ea3-5d0b-5f4d-9e8d-bd8d98fcc49f@oracle.com> <59eb69e2-4f55-1ed2-b505-0304160122dc@oracle.com> Message-ID: <67dee2be-670a-9dc6-7e50-66e9c1af8698@oracle.com> On 9/18/2018 4:24 PM, Michael StJohns wrote: > > Adam - > > Basically, the JCE is all about plugging in not about the > implementations.? If this is truly an EC library, I should be able to > get the benefit of your library with very minimal changes - e.g. > specifying your provider in the various getInstance() calls.?? As it > stands, I doubt this will end up in anyone's "must use" category > because it will break existing code. Is this standard of being "truly an EC library" met by PKCS11 providers that don't export keys? > > You want folks to convince you that interoperability is a significant > problem when what we (or at least I) want is for you to convince us > that these interop breaks are warranted due to how wonderful your > approach is and that they're absolutely necessary due the secret sauce > of wonderfulness.? You're not there yet. I don't agree with this logic. Different providers have different levels of interoperability, and this interoperability is a feature that requires effort to develop and maintain. I don't want to commit myself or this community to this effort unless I/we think it is worthwhile. Some of the proposals to increase interoperability for this effort (e.g. subclassing BigInteger) would require a significant amount of additional effort, and I think this requires justification. Of course, if you know of a way to have more interoperability without reducing assurance or significantly increasing effort, I would love to hear about it. For assurance, an important property is that the implementation should not branch on secrets after the developer has put it in branchless mode (by selecting the branchless provider or by using some other interface to switch modes). > > As for PKCS11 - there are exportable and non-exportable private keys > (e.g. PKCS11 with an accelerator vs an HSM for example).? The > exportable ones show up as ECPrivateKeys, the non-exportable ones as > PrivateKeys (and I think with an underlying type of PKCS11Key...).? So > it follows the model for exportable keys.? And every PKCS11 provider > I've used at least has a way of IMPORTING ECPrivateKeys. My goal is for the new provider to be at least as interoperable as PKCS11 providers with non-exportable keys. Do all the PKCS11 providers that you have used allow importing private keys over JCA, or over some other API? Do you have to put the HSM in some sort of "import mode" in order for this import to be allowed? Is there any difference in the way that you can use keys that were loaded over this API vs keys that were generated on the device (or loaded securely)? From norman.maurer at googlemail.com Wed Sep 19 15:49:31 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Wed, 19 Sep 2018 08:49:31 -0700 Subject: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: <422BC150-FBAE-4829-B375-637F27C671C4@googlemail.com> References: <32bad254-1a8c-7933-d5a0-0b8ce3ed2f68@oracle.com> <05EF82F5-6506-4928-8030-B9BEEE64E1F1@googlemail.com> <0EB21A4C-7DFF-4878-9446-182DA35F0A8C@googlemail.com> <2dea4403-e019-613d-373e-75c789029cef@oracle.com> <422BC150-FBAE-4829-B375-637F27C671C4@googlemail.com> Message-ID: <499D9F15-3CF1-4FDC-80AB-5A73FCB744FD@googlemail.com> I see this is now tracked as https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8210846?filter=allopenissues :) Just one question, I saw it list 12 as fix version. Is this just the initial version set or do you not plan to fix it in Java11 ? IMHO this is a quite an important thing to fix as otherwise you may run into issues when using SSL on the client-side as most real-world apps use OpenSSL on the server-side. Bye Norman > On 17. Sep 2018, at 10:44, Norman Maurer wrote: > > Of course not? > > ID: 9057280 > > Thanks > Norman > > >> On 17. Sep 2018, at 19:35, Xuelei Fan > wrote: >> >> Hi Norman, >> >> Thank you so much for the reproducing code. Would you mind file a bug for this issue? >> >> Thanks, >> Xuelei >> >> On 9/17/2018 3:39 AM, Norman Maurer wrote: >>> Hi all, >>> As requested I pushed a pure JDK reproducer to GitHub which you can easily use to reproduce the problem. All the details how to run it etc are in the README.md file. I also included a server to show that all works if we use the JDK on the client side and server side. >>> Also as stated before you will see that the cert will be send even if you use OpenSSL on the serverside if you replace ?-Verify 1? with ?-verify 1? (which is kind of the same as setWantClientAuth(true)). >>> Please don't hesitate to ping me if you need any more details or have any more questions. >>> https://github.com/normanmaurer/jdktls13bugreproducer >>> Here is the output with debugging enabled on the client side. >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.515 CEST|SSLContextImpl.java:427|System property jdk.tls.client.cipherSuites is set to 'null' >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.529 CEST|SSLContextImpl.java:427|System property jdk.tls.server.cipherSuites is set to 'null' >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.563 CEST|SSLCipher.java:437|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.577 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.577 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.580 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.580 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_RC4_128_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_RC4_128_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_RC4_128_MD5 >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_RC4_128_MD5 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_WITH_RC4_128_MD5 >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_WITH_RC4_128_MD5 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5 >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.591 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.593 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.593 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.599 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.599 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.642 CEST|SunX509KeyManagerImpl.java:164|found key for : 1 ( >>> "certificate" : { >>> "version" : "v3", >>> "serial number" : "20 C3 8D C4 49 66 D0 02", >>> "signature algorithm": "SHA256withRSA", >>> "issuer" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>> "not before" : "2013-08-02 09:51:36.000 CEST", >>> "not after" : "10000-01-01 24:59:59.000 CET", >>> "subject" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>> "subject public key" : "RSA"} >>> ) >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 CEST|SSLContextImpl.java:115|trigger seeding of SecureRandom >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 CEST|SSLContextImpl.java:119|done seeding of SecureRandom >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.665 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_128_GCM_SHA256 for TLS12 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.666 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_256_GCM_SHA384 for TLS12 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_128_GCM_SHA256 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_256_GCM_SHA384 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS11 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_128_GCM_SHA256 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_256_GCM_SHA384 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS10 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS10 >>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.690 CEST|ServerNameExtension.java:255|Unable to indicate server name >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.690 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: server_name >>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.701 CEST|SignatureScheme.java:282|Signature algorithm, ed25519, is not supported by the underlying providers >>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.702 CEST|SignatureScheme.java:282|Signature algorithm, ed448, is not supported by the underlying providers >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.706 CEST|SignatureScheme.java:358|Ignore disabled signature sheme: rsa_md5 >>> javax.net.ssl|INFO|01|main|2018-09-17 11:51:54.706 CEST|AlpnExtension.java:161|No available application protocols >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.706 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: application_layer_protocol_negotiation >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.707 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: cookie >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: renegotiation_info >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 CEST|PreSharedKeyExtension.java:606|No session to resume. >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: pre_shared_key >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 CEST|ClientHello.java:633|Produced ClientHello handshake message ( >>> "ClientHello": { >>> "client version" : "TLSv1.2", >>> "random" : "66 2E BE D3 8A 77 39 06 3B 5A 34 03 7D EE 74 BB 08 D2 19 FD 50 17 2D 84 29 AA FB E0 EE ED 50 69", >>> "session id" : "0B 03 C8 E2 D2 A5 CD 3A 22 C5 85 17 06 64 A9 30 14 62 C0 AF AB 67 CE 63 50 41 50 7F 6B FD 4C 9F", >>> "cipher suites" : "[TLS_AES_128_GCM_SHA256(0x1301), TLS_AES_256_GCM_SHA384(0x1302), TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]", >>> "compression methods" : "00", >>> "extensions" : [ >>> "status_request (5)": { >>> "certificate status type": ocsp >>> "OCSP status request": { >>> "responder_id": >>> "request extensions": { >>> >>> } >>> } >>> }, >>> "supported_groups (10)": { >>> "versions": [secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] >>> }, >>> "ec_point_formats (11)": { >>> "formats": [uncompressed] >>> }, >>> "signature_algorithms (13)": { >>> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] >>> }, >>> "signature_algorithms_cert (50)": { >>> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] >>> }, >>> "status_request_v2 (17)": { >>> "cert status request": { >>> "certificate status type": ocsp_multi >>> "OCSP status request": { >>> "responder_id": >>> "request extensions": { >>> >>> } >>> } >>> } >>> }, >>> "extended_master_secret (23)": { >>> >>> }, >>> "supported_versions (43)": { >>> "versions": [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1] >>> }, >>> "psk_key_exchange_modes (45)": { >>> "ke_modes": [psk_dhe_ke] >>> }, >>> "key_share (51)": { >>> "client_shares": [ >>> { >>> "named group": secp256r1 >>> "key_exchange": { >>> 0000: 04 A3 9F B9 05 27 00 38 C4 D7 61 6C 66 1F 4A 8D .....'.8..alf.J. >>> 0010: B1 02 6F 0B F6 E1 BD 50 93 52 86 2C D2 3C 8D 1A ..o....P.R.,.<.. >>> 0020: 10 A9 CD F0 40 F4 CD 04 25 A1 11 E2 58 23 A3 24 .... at ...%...X#.$ >>> 0030: CA E8 8F 28 F7 2B 65 96 B2 E3 A1 AE 99 24 94 28 ...(.+e......$.( >>> 0040: 83 >>> } >>> }, >>> ] >>> } >>> ] >>> } >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 417 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.719 CEST|SSLSocketOutputRecord.java:255|Raw write ( >>> 0000: 16 03 03 01 A1 01 00 01 9D 03 03 66 2E BE D3 8A ...........f.... >>> 0010: 77 39 06 3B 5A 34 03 7D EE 74 BB 08 D2 19 FD 50 w9.;Z4...t.....P >>> 0020: 17 2D 84 29 AA FB E0 EE ED 50 69 20 0B 03 C8 E2 .-.).....Pi .... >>> 0030: D2 A5 CD 3A 22 C5 85 17 06 64 A9 30 14 62 C0 AF ...:"....d.0.b.. >>> 0040: AB 67 CE 63 50 41 50 7F 6B FD 4C 9F 00 5A 13 01 .g.cPAP.k.L..Z.. >>> 0050: 13 02 C0 2C C0 2B C0 30 00 9D C0 2E C0 32 00 9F ...,.+.0.....2.. >>> 0060: 00 A3 C0 2F 00 9C C0 2D C0 31 00 9E 00 A2 C0 24 .../...-.1.....$ >>> 0070: C0 28 00 3D C0 26 C0 2A 00 6B 00 6A C0 0A C0 14 .(.=.&.*.k.j.... >>> 0080: 00 35 C0 05 C0 0F 00 39 00 38 C0 23 C0 27 00 3C .5.....9.8.#.'.< >>> 0090: C0 25 C0 29 00 67 00 40 C0 09 C0 13 00 2F C0 04 .%.).g. at ...../.. >>> 00A0: C0 0E 00 33 00 32 00 FF 01 00 00 FA 00 05 00 05 ...3.2.......... >>> 00B0: 01 00 00 00 00 00 0A 00 20 00 1E 00 17 00 18 00 ........ ....... >>> 00C0: 19 00 09 00 0A 00 0B 00 0C 00 0D 00 0E 00 16 01 ................ >>> 00D0: 00 01 01 01 02 01 03 01 04 00 0B 00 02 01 00 00 ................ >>> 00E0: 0D 00 28 00 26 04 03 05 03 06 03 08 04 08 05 08 ..(.&........... >>> 00F0: 06 08 09 08 0A 08 0B 04 01 05 01 06 01 04 02 03 ................ >>> 0100: 03 03 01 03 02 02 03 02 01 02 02 00 32 00 28 00 ............2.(. >>> 0110: 26 04 03 05 03 06 03 08 04 08 05 08 06 08 09 08 &............... >>> 0120: 0A 08 0B 04 01 05 01 06 01 04 02 03 03 03 01 03 ................ >>> 0130: 02 02 03 02 01 02 02 00 11 00 09 00 07 02 00 04 ................ >>> 0140: 00 00 00 00 00 17 00 00 00 2B 00 09 08 03 04 03 .........+...... >>> 0150: 03 03 02 03 01 00 2D 00 02 01 01 00 33 00 47 00 ......-.....3.G. >>> 0160: 45 00 17 00 41 04 A3 9F B9 05 27 00 38 C4 D7 61 E...A.....'.8..a >>> 0170: 6C 66 1F 4A 8D B1 02 6F 0B F6 E1 BD 50 93 52 86 lf.J...o....P.R. >>> 0180: 2C D2 3C 8D 1A 10 A9 CD F0 40 F4 CD 04 25 A1 11 ,.<...... at ...%.. >>> 0190: E2 58 23 A3 24 CA E8 8F 28 F7 2B 65 96 B2 E3 A1 .X#.$...(.+e.... >>> 01A0: AE 99 24 94 28 83 ..$.(. >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: 16 03 03 00 9B ..... >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length = 155 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.721 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: 02 00 00 97 03 03 AB 76 F1 BA F3 B1 F0 DD 53 AC .......v......S. >>> 0010: 5B 54 E9 E4 2E F8 44 D2 5E B2 59 85 0D 16 79 EE [T....D.^.Y...y. >>> 0020: A7 66 8A 84 69 2A 20 0B 03 C8 E2 D2 A5 CD 3A 22 .f..i* .......:" >>> 0030: C5 85 17 06 64 A9 30 14 62 C0 AF AB 67 CE 63 50 ....d.0.b...g.cP >>> 0040: 41 50 7F 6B FD 4C 9F 13 01 00 00 4F 00 2B 00 02 AP.k.L.....O.+.. >>> 0050: 03 04 00 33 00 45 00 17 00 41 04 18 4A 46 BB 73 ...3.E...A..JF.s >>> 0060: F4 6F 5D F0 3C 98 AD 70 7E 13 D6 C0 E5 C0 28 5A .o].<..p......(Z >>> 0070: D7 42 78 95 68 E0 85 B7 06 CD DB 3C 35 DA AF E8 .Bx.h......<5... >>> 0080: 95 D6 A2 3C 77 CF 7E 8E C8 94 50 BA CD 18 3F DA ...>> 0090: E3 A3 25 E9 F3 C9 A9 7F 4E B6 A9 ..%.....N.. >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.721 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 handshake, length = 155 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.722 CEST|ServerHello.java:866|Consuming ServerHello handshake message ( >>> "ServerHello": { >>> "server version" : "TLSv1.2", >>> "random" : "AB 76 F1 BA F3 B1 F0 DD 53 AC 5B 54 E9 E4 2E F8 44 D2 5E B2 59 85 0D 16 79 EE A7 66 8A 84 69 2A", >>> "session id" : "0B 03 C8 E2 D2 A5 CD 3A 22 C5 85 17 06 64 A9 30 14 62 C0 AF AB 67 CE 63 50 41 50 7F 6B FD 4C 9F", >>> "cipher suite" : "TLS_AES_128_GCM_SHA256(0x1301)", >>> "compression methods" : "00", >>> "extensions" : [ >>> "supported_versions (43)": { >>> "selected version": [TLSv1.3] >>> }, >>> "key_share (51)": { >>> "server_share": { >>> "named group": secp256r1 >>> "key_exchange": { >>> 0000: 04 18 4A 46 BB 73 F4 6F 5D F0 3C 98 AD 70 7E 13 ..JF.s.o].<..p.. >>> 0010: D6 C0 E5 C0 28 5A D7 42 78 95 68 E0 85 B7 06 CD ....(Z.Bx.h..... >>> 0020: DB 3C 35 DA AF E8 95 D6 A2 3C 77 CF 7E 8E C8 94 .<5......>> 0030: 50 BA CD 18 3F DA E3 A3 25 E9 F3 C9 A9 7F 4E B6 P...?...%.....N. >>> 0040: A9 >>> } >>> }, >>> } >>> ] >>> } >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|SSLExtensions.java:167|Consumed extension: supported_versions >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|ServerHello.java:962|Negotiated protocol version: TLSv1.3 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|SSLExtensions.java:138|Ignore unsupported extension: server_name >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|SSLExtensions.java:138|Ignore unsupported extension: max_fragment_length >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|SSLExtensions.java:138|Ignore unsupported extension: status_request >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:138|Ignore unsupported extension: ec_point_formats >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:138|Ignore unsupported extension: application_layer_protocol_negotiation >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:138|Ignore unsupported extension: status_request_v2 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:138|Ignore unsupported extension: extended_master_secret >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:167|Consumed extension: supported_versions >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 CEST|SSLExtensions.java:167|Consumed extension: key_share >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 CEST|SSLExtensions.java:138|Ignore unsupported extension: renegotiation_info >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 CEST|PreSharedKeyExtension.java:832|Handling pre_shared_key absence. >>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.725 CEST|SSLSessionImpl.java:203|Session initialized: Session(1537177914725|TLS_AES_128_GCM_SHA256) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 CEST|SSLExtensions.java:182|Ignore unavailable extension: server_name >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: max_fragment_length >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: status_request >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: ec_point_formats >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: application_layer_protocol_negotiation >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: status_request_v2 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: extended_master_secret >>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: supported_versions >>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: key_share >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: renegotiation_info >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: pre_shared_key >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.732 CEST|SSLCipher.java:1824|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE >>> countdown value = 137438953472 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.735 CEST|SSLCipher.java:1978|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE >>> countdown value = 137438953472 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.736 CEST|SSLSocketOutputRecord.java:225|Raw write ( >>> 0000: 14 03 03 00 01 01 ...... >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.736 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: 14 03 03 00 01 ..... >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 change_cipher_spec, length = 1 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: 01 . >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 change_cipher_spec, length = 1 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|ChangeCipherSpec.java:232|Consuming ChangeCipherSpec message >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: 17 03 03 00 27 ....' >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 39 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: D5 B7 25 6F AF E9 D6 6F 7C 61 98 90 3F FE BA 9A ..%o...o.a..?... >>> 0010: A8 5B 94 5E 3A 47 38 62 36 90 9A 1D BE BF 87 18 .[.^:G8b6....... >>> 0020: 56 8C E3 AA CE AD AA V...... >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 39 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.746 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>> 0000: 08 00 00 12 00 10 00 0A 00 0C 00 0A 00 1D 00 17 ................ >>> 0010: 00 1E 00 19 00 18 ...... >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 CEST|EncryptedExtensions.java:171|Consuming EncryptedExtensions handshake message ( >>> "EncryptedExtensions": [ >>> "supported_groups (10)": { >>> "versions": [x25519, secp256r1, x448, secp521r1, secp384r1] >>> } >>> ] >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 CEST|SSLExtensions.java:148|Ignore unavailable extension: server_name >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 CEST|SSLExtensions.java:148|Ignore unavailable extension: max_fragment_length >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:167|Consumed extension: supported_groups >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:182|Ignore unavailable extension: server_name >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:182|Ignore unavailable extension: max_fragment_length >>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: supported_groups >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:182|Ignore unavailable extension: application_layer_protocol_negotiation >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: 17 03 03 00 42 ....B >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 66 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: 63 F7 54 24 11 6A 91 1F 1F C5 70 9A 26 AD CE 98 c.T$.j....p.&... >>> 0010: D0 A9 7A 84 AF 39 7C A0 AD F6 6B B2 10 88 27 8B ..z..9....k...'. >>> 0020: 79 E0 F4 5A 9F 68 AA F0 56 D3 45 72 7C 7F 22 03 y..Z.h..V.Er..". >>> 0030: 0A 53 F6 24 68 CB 0B E1 3B DD D4 78 B5 AC 1E D7 .S.$h...;..x.... >>> 0040: 03 FB .. >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 66 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>> 0000: 0D 00 00 2D 00 00 2A 00 0D 00 26 00 24 04 03 05 ...-..*...&.$... >>> 0010: 03 06 03 08 07 08 08 08 09 08 0A 08 0B 08 04 08 ................ >>> 0020: 05 08 06 04 01 05 01 06 01 03 03 02 03 03 01 02 ................ >>> 0030: 01 . >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 CEST|CertificateRequest.java:864|Consuming CertificateRequest handshake message ( >>> "CertificateRequest": { >>> "certificate_request_context": "", >>> "extensions": [ >>> "signature_algorithms (13)": { >>> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, ed25519, ed448, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha224, ecdsa_sha1, rsa_sha224, rsa_pkcs1_sha1] >>> } >>> ] >>> } >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 CEST|SSLExtensions.java:167|Consumed extension: signature_algorithms >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 CEST|SSLExtensions.java:148|Ignore unavailable extension: signature_algorithms_cert >>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 CEST|SignatureScheme.java:390|Unsupported signature scheme: ed25519 >>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 CEST|SignatureScheme.java:390|Unsupported signature scheme: ed448 >>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 CEST|SignatureScheme.java:390|Unsupported signature scheme: ecdsa_sha224 >>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 CEST|SignatureScheme.java:390|Unsupported signature scheme: rsa_sha224 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 CEST|SSLExtensions.java:199|Populated with extension: signature_algorithms >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 CEST|SSLExtensions.java:182|Ignore unavailable extension: signature_algorithms_cert >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: 17 03 03 03 20 .... >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 800 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.753 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: FE BB B2 07 BA CE A6 32 AA 58 66 2F 6D 87 16 75 .......2.Xf/m..u >>> 0010: CF 71 13 53 FB 45 AE DC 84 F4 AA 33 08 08 DF B5 .q.S.E.....3.... >>> 0020: 97 C5 79 40 4A 28 F4 9D 0F 5A 86 4E C4 5F C7 2E ..y at J(...Z.N._.. >>> 0030: AA AA 42 F7 8A FF 6B C1 28 75 9B A3 25 F0 23 81 ..B...k.(u..%.#. >>> 0040: 74 BB 9A EA A8 8D 89 BE E9 80 AE 31 C3 3A FC 35 t..........1.:.5 >>> 0050: E6 CA C5 77 BF C7 0E ED 64 26 DB 4E C3 3D F5 AD ...w....d&.N.=.. >>> 0060: 5E EB A8 37 AA 81 EF 39 24 84 C9 C4 C7 A2 D7 DB ^..7...9$....... >>> 0070: 7F 82 01 7A 02 E7 23 A3 6E C9 68 B8 E5 C3 9F 53 ...z..#.n.h....S >>> 0080: 16 6E EF B0 54 D2 67 4C FF 22 E6 78 B1 A0 DB BE .n..T.gL.".x.... >>> 0090: 97 23 FC C8 D8 92 86 3D C6 6B E4 C1 AC EF B8 46 .#.....=.k.....F >>> 00A0: 75 3C 00 08 8B 34 5F 59 05 49 25 97 BE A8 61 8E u<...4_Y.I%...a. >>> 00B0: B0 5F 25 91 7A FE 79 53 7A C1 A7 E7 70 7B A5 53 ._%.z.ySz...p..S >>> 00C0: 5A 63 8B 8E B9 92 2D B3 80 DC AA 75 BE 0F 47 F3 Zc....-....u..G. >>> 00D0: E8 D9 0D 7D D9 C3 B6 00 AD 2A 43 CC 66 87 88 AF .........*C.f... >>> 00E0: 35 87 74 2F 87 2F 3C A6 FB 12 1A 9C 46 62 1C DC 5.t/./<.....Fb.. >>> 00F0: 4E 4E DC 16 70 7E 08 74 FB F7 E6 5F 4D D9 20 F9 NN..p..t..._M. . >>> 0100: CA F3 91 45 D6 1A B3 BA FA 4E BD A4 74 9E 4C 78 ...E.....N..t.Lx >>> 0110: 03 18 2C 70 35 42 68 F3 9A 1D 24 3F A7 27 DF 29 ..,p5Bh...$?.'.) >>> 0120: D5 58 7C CB 19 2F D1 DF 8A 6D B2 85 52 B5 78 19 .X.../...m..R.x. >>> 0130: EA 5C E2 7A 23 42 9E D7 A3 DC D0 DE D8 33 47 2B .\.z#B.......3G+ >>> 0140: 0C D8 6E 77 25 DB E6 12 B0 7A AD A5 C9 96 AC A9 ..nw%....z...... >>> 0150: 1D CD 73 39 AC 6A 9F E2 0A F7 17 F1 F0 FF 75 9C ..s9.j........u. >>> 0160: B2 05 9E 7A F4 18 4F FC 9D 42 69 4C E0 3E A1 21 ...z..O..BiL.>.! >>> 0170: DA 1F 71 07 59 C6 A2 F9 0B 4F C0 CD A4 85 A8 DB ..q.Y....O...... >>> 0180: 77 F6 87 5E 09 16 49 5C 2C B8 C0 7B 39 81 65 FD w..^..I\,...9.e. >>> 0190: 29 52 E2 C7 F5 C7 AD BC F6 A9 F9 6D D2 E9 A4 14 )R.........m.... >>> 01A0: C9 D3 79 2E D2 BA 10 4C BD 44 65 2B A8 7E F1 3A ..y....L.De+...: >>> 01B0: F3 F6 11 53 38 17 10 12 B4 CD C5 AD 72 3B 84 A2 ...S8.......r;.. >>> 01C0: 1B F9 D7 BF 34 00 5A FE F4 CE 09 0C EA F2 27 9A ....4.Z.......'. >>> 01D0: BD DD 93 37 E2 DF 60 CC 8A F7 C6 4B 08 30 0D 78 ...7..`....K.0.x >>> 01E0: 5C EB 49 34 DB 8B EB 55 33 0C 82 03 07 FD 3D FC \.I4...U3.....=. >>> 01F0: 49 11 88 1C F6 67 7F 0B 48 AA EC 1B AF 04 46 CF I....g..H.....F. >>> 0200: 09 C5 8E B3 F8 92 C4 56 3D 8F 0E 1D 9F D3 0C FE .......V=....... >>> 0210: 94 23 15 53 8E 1F 5E C4 FA 44 03 3B 1B B0 0A 2D .#.S..^..D.;...- >>> 0220: 71 D4 B5 AC 1F 52 D7 25 9F A0 C8 4B 9B 32 B8 22 q....R.%...K.2." >>> 0230: 3F AF B3 19 16 8C 2A 5C B4 89 BF 82 DC 4D AF 22 ?.....*\.....M." >>> 0240: 2A 33 73 90 F3 C8 FF 2E C1 B3 83 D2 7A 29 4E 15 *3s.........z)N. >>> 0250: 5D 87 86 F6 94 EA B0 B4 A4 41 B9 C5 BA 89 B8 E9 ]........A...... >>> 0260: 26 E7 96 BC 4D 8A FD 86 C7 C9 2A 96 75 C3 07 EF &...M.....*.u... >>> 0270: 5C 5A 4E 91 71 7D 1B A2 12 88 C5 D0 D2 5E 79 E1 \ZN.q........^y. >>> 0280: 6C 65 35 5E 6C CC 56 47 FD F3 96 78 7A A0 08 7E le5^l.VG...xz... >>> 0290: DB 3C CC 10 76 15 37 46 48 6B 2D 23 7B A3 44 5A .<..v.7FHk-#..DZ >>> 02A0: A4 46 B3 CE E2 15 BA 4C D2 93 16 57 1F BA 75 72 .F.....L...W..ur >>> 02B0: BF 8C 66 50 F2 A4 F6 05 84 E5 47 12 30 BE 34 70 ..fP......G.0.4p >>> 02C0: 4D 0F BD FE 54 E8 B1 CE B5 7F 6E 97 38 09 29 1F M...T.....n.8.). >>> 02D0: 41 2D 2E 9E 75 D8 77 0C 08 DB 5C B4 EE 3F FE E2 A-..u.w...\..?.. >>> 02E0: DC CF D0 ED C8 02 50 C4 EE B3 1D 8A 9E 9B EE 5E ......P........^ >>> 02F0: 14 BA C2 5A B0 83 8E 5C E5 7B 69 2B 69 8C F1 AA ...Z...\..i+i... >>> 0300: 2D D5 D1 3D 9D 42 1B B2 50 5D BE 7E E4 11 D2 90 -..=.B..P]...... >>> 0310: 0B 54 71 7F D6 13 88 E2 FE 37 9F 70 B5 0B 57 79 .Tq......7.p..Wy >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.753 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 800 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.755 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>> 0000: 0B 00 03 0B 00 00 03 07 00 03 02 30 82 02 FE 30 ...........0...0 >>> 0010: 82 01 E6 A0 03 02 01 02 02 08 20 C3 8D C4 49 66 .......... ...If >>> 0020: D0 02 30 0D 06 09 2A 86 48 86 F7 0D 01 01 0B 05 ..0...*.H....... >>> 0030: 00 30 3E 31 3C 30 3A 06 03 55 04 03 0C 33 65 38 .0>1<0:..U...3e8 >>> 0040: 61 63 30 32 66 61 30 64 36 35 61 38 34 32 31 39 ac02fa0d65a84219 >>> 0050: 30 31 36 30 34 35 64 62 38 62 30 35 63 34 38 35 016045db8b05c485 >>> 0060: 62 34 65 63 64 66 2E 6E 65 74 74 79 2E 74 65 73 b4ecdf.netty.tes >>> 0070: 74 30 20 17 0D 31 33 30 38 30 32 30 37 35 31 33 t0 ..13080207513 >>> 0080: 36 5A 18 0F 39 39 39 39 31 32 33 31 32 33 35 39 6Z..999912312359 >>> 0090: 35 39 5A 30 3E 31 3C 30 3A 06 03 55 04 03 0C 33 59Z0>1<0:..U...3 >>> 00A0: 65 38 61 63 30 32 66 61 30 64 36 35 61 38 34 32 e8ac02fa0d65a842 >>> 00B0: 31 39 30 31 36 30 34 35 64 62 38 62 30 35 63 34 19016045db8b05c4 >>> 00C0: 38 35 62 34 65 63 64 66 2E 6E 65 74 74 79 2E 74 85b4ecdf.netty.t >>> 00D0: 65 73 74 30 82 01 22 30 0D 06 09 2A 86 48 86 F7 est0.."0...*.H.. >>> 00E0: 0D 01 01 01 05 00 03 82 01 0F 00 30 82 01 0A 02 ...........0.... >>> 00F0: 82 01 01 00 DB F8 70 4E DC 2D 14 44 12 AF 0D 48 ......pN.-.D...H >>> 0100: 09 1D B8 48 94 1C 9E F1 7F DC 6C D1 F7 94 3A B7 ...H......l...:. >>> 0110: 5C E3 85 07 3E CB E1 76 4A 2C 32 17 4B E1 5E 42 \...>..vJ,2.K.^B >>> 0120: A4 80 50 CA 36 A2 D9 94 F9 59 23 D0 AA 2B B2 13 ..P.6....Y#..+.. >>> 0130: 23 6D 45 DF 13 52 A4 4E 28 D3 30 99 5A 81 AD 8C #mE..R.N(.0.Z... >>> 0140: DB 15 55 B7 6D 5F 44 89 09 35 66 C8 2F 47 56 14 ..U.m_D..5f./GV. >>> 0150: B5 B2 46 AE CE 5D DC A0 C8 59 08 89 6F 5B DB F2 ..F..]...Y..o[.. >>> 0160: D8 69 E3 C1 80 44 F6 DA 46 ED 1D 20 80 12 3F 81 .i...D..F.. ..?. >>> 0170: 95 27 F6 EB 9F B5 AC DC 72 01 70 46 18 67 1C 08 .'......r.pF.g.. >>> 0180: AC C4 6D CA 80 48 12 87 3A 05 69 EA 92 EA 95 00 ..m..H..:.i..... >>> 0190: 1F B9 2C BA 83 F3 B3 1B 37 1E B3 7C D7 46 B1 AE ..,.....7....F.. >>> 01A0: D4 DD E9 04 8C C0 23 00 96 E3 6F 67 E7 66 65 61 ......#...og.fea >>> 01B0: F6 11 D2 7A FE 44 42 83 9D 1A CF 20 80 EC 58 04 ...z.DB.... ..X. >>> 01C0: A6 10 78 41 7B 34 C3 FA FD 2A 08 94 72 2F 3D AE ..xA.4...*..r/=. >>> 01D0: B0 58 16 63 EE DA 81 42 44 DB 21 C7 23 69 93 BB .X.c...BD.!.#i.. >>> 01E0: 64 40 16 78 01 8A 52 57 94 C0 AD 57 04 F4 C4 6B d at .x..RW...W...k >>> 01F0: 90 C6 46 C7 02 03 01 00 01 30 0D 06 09 2A 86 48 ..F......0...*.H >>> 0200: 86 F7 0D 01 01 0B 05 00 03 82 01 01 00 4B FC 37 .............K.7 >>> 0210: B5 E6 F2 A6 98 D8 58 2B 39 CE 8F 6B 51 93 80 0F ......X+9..kQ... >>> 0220: 80 39 BD DA 53 7D D3 1B 00 11 F3 A7 FE 9C B7 FA .9..S........... >>> 0230: 05 23 DA A2 17 10 7C E7 89 89 DE C5 90 5B 98 22 .#...........[." >>> 0240: 7B 97 97 EA 2A B3 E4 6A 33 F8 FC 47 41 39 06 E1 ....*..j3..GA9.. >>> 0250: 98 63 6C 0E 2A 92 FF 3D B1 62 D7 27 FF 2B 2B DF .cl.*..=.b.'.++. >>> 0260: B7 B2 95 87 C7 B5 21 45 1E 73 F8 B5 0D D6 13 0C ......!E.s...... >>> 0270: 1D 25 35 6B D7 5F 18 DF 30 A1 8B 72 DD C6 31 B1 .%5k._..0..r..1. >>> 0280: 07 2A F2 DF 1F 1E 36 23 0C FF F9 FB DA E8 B5 2B .*....6#.......+ >>> 0290: 3B 8B B6 4C 37 EF D3 27 07 B9 1E D4 64 4B 82 D4 ;..L7..'....dK.. >>> 02A0: 32 78 C6 D1 61 6E 9A BF 41 10 23 0B 27 CD C7 77 2x..an..A.#.'..w >>> 02B0: 03 73 B2 F6 12 D2 56 9C 29 A2 BD 31 40 F6 5F 0C .s....V.)..1 at ._. >>> 02C0: 17 56 4F 30 34 95 77 87 9C 43 B0 74 C5 92 05 43 .VO04.w..C.t...C >>> 02D0: 97 12 48 5B 7B 58 66 89 0A C1 8C CD 89 14 E0 5A ..H[.Xf........Z >>> 02E0: 78 23 29 10 71 6C 5D 94 D5 FB C0 96 51 C1 0D 93 x#).ql].....Q... >>> 02F0: 64 91 45 82 5A 53 88 56 5D 7A AE 88 E8 07 7D 02 d.E.ZS.V]z...... >>> 0300: 7D 44 9D CA 73 E5 6F 14 27 8B 6F 86 6C 00 00 .D..s.o.'.o.l.. >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 CEST|CertificateMessage.java:1148|Consuming server Certificate handshake message ( >>> "Certificate": { >>> "certificate_request_context": "", >>> "certificate_list": [ >>> { >>> "certificate" : { >>> "version" : "v3", >>> "serial number" : "20 C3 8D C4 49 66 D0 02", >>> "signature algorithm": "SHA256withRSA", >>> "issuer" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>> "not before" : "2013-08-02 09:51:36.000 CEST", >>> "not after" : "10000-01-01 24:59:59.000 CET", >>> "subject" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>> "subject public key" : "RSA"} >>> "extensions": { >>> >>> } >>> }, >>> ] >>> } >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 CEST|SSLExtensions.java:148|Ignore unavailable extension: status_request >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: 17 03 03 01 19 ..... >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 281 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: DE 53 C0 74 78 C3 82 0D E8 46 C0 0A F4 56 6E 6B .S.tx....F...Vnk >>> 0010: B5 39 77 41 20 21 BA 07 99 2B BF 8D 0A 41 C9 B8 .9wA !...+...A.. >>> 0020: BC 0F C1 8E C5 76 36 F0 7A B6 9A F8 38 4D 4D 4D .....v6.z...8MMM >>> 0030: 70 33 BE 8F 8C ED BE BC 60 49 B8 41 65 E9 04 D9 p3......`I.Ae... >>> 0040: 45 43 AA 41 6D F7 67 7B 03 6D FF E0 4D 76 53 CE EC.Am.g..m..MvS. >>> 0050: C1 73 3E 1C CD 87 40 B7 25 56 54 0C 3E CA D7 1D .s>... at .%VT.>... >>> 0060: 45 80 41 E8 36 B7 FC 57 38 BB 21 EB E7 EA 19 A1 E.A.6..W8.!..... >>> 0070: 39 25 B0 44 8B FD 30 87 86 7A 47 03 C1 02 AC FD 9%.D..0..zG..... >>> 0080: 67 89 4B 27 34 04 20 AE 91 65 7C 8C 4A 58 C5 77 g.K'4. ..e..JX.w >>> 0090: 46 2E DD A8 23 CA 5C 28 49 25 23 3D 8A 93 B9 10 F...#.\(I%#=.... >>> 00A0: 24 0D DE DC 98 AC AA B0 CB 51 80 D7 F8 E7 20 23 $........Q.... # >>> 00B0: 41 64 A6 44 93 A7 E1 A7 91 62 4F 3A 73 F6 24 04 Ad.D.....bO:s.$. >>> 00C0: C3 E8 25 65 37 D9 1B 7A 65 AE DE C6 29 67 2E C1 ..%e7..ze...)g.. >>> 00D0: F7 4C 5C 18 D7 14 98 90 ED 9D AD F5 98 A7 FD 93 .L\............. >>> 00E0: 53 F4 B5 90 C9 CB FD 54 8E 5F 53 23 E3 73 94 BD S......T._S#.s.. >>> 00F0: A4 07 B7 E3 C7 83 7B 17 CF 51 4A 9E 9C 05 3C 51 .........QJ...>> 0100: 4D C7 A1 7A D6 4D A6 58 E5 3A D4 12 B9 B9 46 9C M..z.M.X.:....F. >>> 0110: AB 1D C5 6B F9 6A 85 CB E2 ...k.j... >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.758 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 281 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.758 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>> 0000: 0F 00 01 04 08 04 01 00 30 11 28 CE 64 4E 08 BA ........0.(.dN.. >>> 0010: A1 BE 46 D9 3D 14 29 1A EB 5A B0 1A 09 B7 11 A5 ..F.=.)..Z...... >>> 0020: 9A F4 22 17 87 5F 87 D5 63 04 8E 27 EC 3A F8 52 ..".._..c..'.:.R >>> 0030: 36 F4 2F CF 47 D2 5C CE 0A F0 29 EF 63 03 B1 64 6./.G.\...).c..d >>> 0040: B8 45 6E 39 71 E3 BD 25 95 31 25 85 4C FB C6 AD .En9q..%.1%.L... >>> 0050: C8 43 96 4E FA AD B9 98 17 43 61 FB 9B 87 CE 94 .C.N.....Ca..... >>> 0060: CF 74 6F 3B AA 6A C8 80 8F C7 C8 05 E4 EF 42 6C .to;.j........Bl >>> 0070: D4 01 9E 25 5E 34 E8 2D 93 BD BB 05 49 2F 9D B6 ...%^4.-....I/.. >>> 0080: F6 91 2F D1 E5 CB 1B 9E F6 DB 18 32 1D F5 66 A0 ../........2..f. >>> 0090: 63 5D 25 01 B6 F6 1B 41 07 3E 90 61 37 49 38 17 c]%....A.>.a7I8. >>> 00A0: B0 15 C9 AD 0C 7A 05 8D B4 48 BB 03 2D DE 5E 49 .....z...H..-.^I >>> 00B0: 99 8B 74 53 5F 73 9B 18 FD 95 2A C3 F9 A3 8B 59 ..tS_s....*....Y >>> 00C0: 1A ED 2C 55 C2 22 10 1E 7A FC 38 0A 99 FC 30 89 ..,U."..z.8...0. >>> 00D0: 03 89 1C CD A7 DE E5 35 FD E9 E0 05 96 09 AF DD .......5........ >>> 00E0: 51 A3 7F C7 16 C5 96 8D CA CC 53 50 DC C5 C6 BA Q.........SP.... >>> 00F0: D6 05 28 18 BA 99 F8 0F 7F 24 9F D5 6B 93 DE BC ..(......$..k... >>> 0100: EB 23 85 D9 D3 41 56 44 .#...AVD >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 CEST|CertificateVerify.java:1128|Consuming CertificateVerify handshake message ( >>> "CertificateVerify": { >>> "signature algorithm": rsa_pss_rsae_sha256 >>> "signature": { >>> 0000: 30 11 28 CE 64 4E 08 BA A1 BE 46 D9 3D 14 29 1A 0.(.dN....F.=.). >>> 0010: EB 5A B0 1A 09 B7 11 A5 9A F4 22 17 87 5F 87 D5 .Z........".._.. >>> 0020: 63 04 8E 27 EC 3A F8 52 36 F4 2F CF 47 D2 5C CE c..'.:.R6./.G.\. >>> 0030: 0A F0 29 EF 63 03 B1 64 B8 45 6E 39 71 E3 BD 25 ..).c..d.En9q..% >>> 0040: 95 31 25 85 4C FB C6 AD C8 43 96 4E FA AD B9 98 .1%.L....C.N.... >>> 0050: 17 43 61 FB 9B 87 CE 94 CF 74 6F 3B AA 6A C8 80 .Ca......to;.j.. >>> 0060: 8F C7 C8 05 E4 EF 42 6C D4 01 9E 25 5E 34 E8 2D ......Bl...%^4.- >>> 0070: 93 BD BB 05 49 2F 9D B6 F6 91 2F D1 E5 CB 1B 9E ....I/..../..... >>> 0080: F6 DB 18 32 1D F5 66 A0 63 5D 25 01 B6 F6 1B 41 ...2..f.c]%....A >>> 0090: 07 3E 90 61 37 49 38 17 B0 15 C9 AD 0C 7A 05 8D .>.a7I8......z.. >>> 00A0: B4 48 BB 03 2D DE 5E 49 99 8B 74 53 5F 73 9B 18 .H..-.^I..tS_s.. >>> 00B0: FD 95 2A C3 F9 A3 8B 59 1A ED 2C 55 C2 22 10 1E ..*....Y..,U.".. >>> 00C0: 7A FC 38 0A 99 FC 30 89 03 89 1C CD A7 DE E5 35 z.8...0........5 >>> 00D0: FD E9 E0 05 96 09 AF DD 51 A3 7F C7 16 C5 96 8D ........Q....... >>> 00E0: CA CC 53 50 DC C5 C6 BA D6 05 28 18 BA 99 F8 0F ..SP......(..... >>> 00F0: 7F 24 9F D5 6B 93 DE BC EB 23 85 D9 D3 41 56 44 .$..k....#...AVD >>> } >>> } >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: 17 03 03 00 35 ....5 >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 53 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: F6 A7 CD EA 89 34 B2 DB C4 28 91 18 C9 03 98 B6 .....4...(...... >>> 0010: DF 49 4E F5 2E 23 32 90 F8 13 C7 AE 18 E3 E5 64 .IN..#2........d >>> 0020: D9 E4 A5 B0 5C F0 4A 3E AF EC 28 8D 09 78 AB EE ....\.J>..(..x.. >>> 0030: 38 1B 9E 45 04 8..E. >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 53 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>> 0000: 14 00 00 20 F2 93 6B 71 2B FA F3 1B BF 68 98 D1 ... ..kq+....h.. >>> 0010: AA 5E B0 AF 5D 3B A6 B5 8F 79 BA 64 E8 A1 34 5F .^..];...y.d..4_ >>> 0020: D4 2B ED 8C .+.. >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.764 CEST|Finished.java:860|Consuming server Finished handshake message ( >>> "Finished": { >>> "verify data": { >>> 0000: F2 93 6B 71 2B FA F3 1B BF 68 98 D1 AA 5E B0 AF ..kq+....h...^.. >>> 0010: 5D 3B A6 B5 8F 79 BA 64 E8 A1 34 5F D4 2B ED 8C ];...y.d..4_.+.. >>> }'} >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.765 CEST|SSLCipher.java:1824|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE >>> countdown value = 137438953472 >>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.765 CEST|CertificateMessage.java:1015|No signature_algorithms(_cert) in ClientHello >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|CertificateMessage.java:1081|No available client authentication scheme >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|CertificateMessage.java:1116|Produced client Certificate message ( >>> "Certificate": { >>> "certificate_request_context": "", >>> "certificate_list": [ >>> ] >>> } >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 8 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( >>> 0000: 0B 00 00 04 00 00 00 00 16 00 00 00 00 00 00 00 ................ >>> 0010: 00 00 00 00 00 00 00 00 00 ......... >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 CEST|SSLSocketOutputRecord.java:255|Raw write ( >>> 0000: 17 03 03 00 29 E5 32 E4 5B 13 E7 D4 A1 78 FE 38 ....).2.[....x.8 >>> 0010: 26 22 CB C1 04 88 3A 3A 2D D4 A1 31 5A 78 65 50 &"....::-..1ZxeP >>> 0020: 51 45 67 FA 9F 55 35 E1 49 C5 3B 3B 91 B1 QEg..U5.I.;;.. >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 CEST|CertificateVerify.java:1059|No X.509 credentials negotiated for CertificateVerify >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 CEST|Finished.java:658|Produced client Finished handshake message ( >>> "Finished": { >>> "verify data": { >>> 0000: D8 47 0B A0 DF BB BF 49 E4 55 B9 D3 FB 3D B0 DD .G.....I.U...=.. >>> 0010: 57 1E 08 28 20 7E E1 0B E3 EB 12 10 09 76 D1 8F W..( ........v.. >>> }'} >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 36 >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( >>> 0000: 14 00 00 20 D8 47 0B A0 DF BB BF 49 E4 55 B9 D3 ... .G.....I.U.. >>> 0010: FB 3D B0 DD 57 1E 08 28 20 7E E1 0B E3 EB 12 10 .=..W..( ....... >>> 0020: 09 76 D1 8F 16 00 00 00 00 00 00 00 00 00 00 00 .v.............. >>> 0030: 00 00 00 00 00 ..... >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 CEST|SSLSocketOutputRecord.java:255|Raw write ( >>> 0000: 17 03 03 00 45 0F 4D 84 52 28 59 96 92 52 D1 AB ....E.M.R(Y..R.. >>> 0010: DB 86 64 25 31 FF 9D 8E D7 84 63 B5 03 E2 9E 06 ..d%1.....c..... >>> 0020: 3C 8C C2 22 F3 7A EE 55 AD 8C F5 5C F6 04 9A E2 <..".z.U...\.... >>> 0030: 6D BA E4 C4 9F 97 C3 DA BC D3 CB 8C 2C 9E BF FD m...........,... >>> 0040: A3 9F C1 A2 79 51 75 B7 AE B6 ....yQu... >>> ) >>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.770 CEST|SSLCipher.java:1978|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE >>> countdown value = 137438953472 >>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: 17 03 03 00 13 ..... >>> ) >>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 19 >>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:458|Raw read ( >>> 0000: 4F 0D C7 65 8B 24 B4 92 A2 26 31 8C 81 AF 8F F7 O..e.$...&1..... >>> 0010: AC C3 B3 ... >>> ) >>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 19 >>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.773 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>> 0000: 02 74 .t >>> ) >>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.774 CEST|Alert.java:232|Received alert message ( >>> "Alert": { >>> "level" : "fatal", >>> "description": "certificate_required" >>> } >>> ) >>> javax.net.ssl|ERROR|0C|Thread-0|2018-09-17 11:51:54.774 CEST|TransportContext.java:313|Fatal (CERTIFICATE_REQUIRED): Received fatal alert: certificate_required ( >>> "throwable" : { >>> javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_required >>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>> at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >>> at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >>> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>> at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) >>> at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) >>> at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) >>> at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) >>> at ReproducerClient$1.run(ReproducerClient.java:33) >>> at java.base/java.lang.Thread.run(Thread.java:834)} >>> ) >>> javax.net.ssl|ALL|0C|Thread-0|2018-09-17 11:51:54.775 CEST|SSLSessionImpl.java:753|Invalidated session: Session(1537177914725|TLS_AES_128_GCM_SHA256) >>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 CEST|SSLSocketImpl.java:1361|close the underlying socket >>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 CEST|SSLSocketImpl.java:1380|close the SSL connection (initiative) >>> javax.net.ssl|WARNING|0C|Thread-0|2018-09-17 11:51:54.777 CEST|SSLSocketImpl.java:1289|handling exception ( >>> "throwable" : { >>> javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_required >>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>> at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >>> at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >>> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>> at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) >>> at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) >>> at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) >>> at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) >>> at ReproducerClient$1.run(ReproducerClient.java:33) >>> at java.base/java.lang.Thread.run(Thread.java:834)} >>> ) >>> Bye >>> Norman >>>> On 16. Sep 2018, at 15:54, Norman Maurer >> wrote: >>>> >>>> Will do, but not before tomorrow (I will also share the client side code). That said there is nothing special about the keymanager. >>>> Like I said before it sends the cert when using ?want client with?, it just seems it may be too late. >>>> >>>> >>>> Bye >>>> Norman >>>> >>>>> Am 15.09.2018 um 08:26 schrieb Bradford Wetmore >>: >>>>> >>>>> 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)) >>>>>>>>> 0000 - 16 03 03 01 60 ....` >>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160)) >>>>>>>>> 0000 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 ...\..".... at 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..o....K...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)) >>>>>>>>> 0000 - 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|J....n....] >>>>>>>>> 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..o....K.. >>>>>>>>> 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 MT....B5S[...... >>>>>>>>> 00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65 .(.m...8.wrs%&.e >>>>>>>>> 00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96 X........P...... >>>>>>>>> 0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9 .;<..AX...:(..a. >>>>>>>>> 0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5 .h...f.[..... .. >>>>>>>>> 0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb .RD...c=........ >>>>>>>>> 0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6 .*O[J.wx.u. .... >>>>>>>>> 0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee ...VV._.e.~n=.f. >>>>>>>>> 0150 - 10 4c f7 6d 9b 73 86 14-7a 81 f8 b1 27 af 08 ee .L.m.s..z...'... >>>>>>>>> 0160 - ce 26 90 34 73 3d b7 45-8d 85 29 a8 65 19 e7 02 .&.4s=.E..).e... >>>>>>>>> 0170 - e5 55 4a 27 f1 b1 6a a4-11 cc 6c af 78 6d 22 5c .UJ'..j...l.xm"\ >>>>>>>>> 0180 - 33 73 e3 ad 7f 8d 1b d3-75 95 66 64 2d 0e f1 3e 3s......u.fd-..> >>>>>>>>> 0190 - c2 30 df a1 7e ce a3 50-c3 4e 68 f6 36 b3 4e 45 .0..~..P.Nh.6.NE >>>>>>>>> 01a0 - 9c ac e9 f2 0d 7c e3 73-6a 40 ab 6e 6e f9 d8 20 .....|.sj at .nn.. >>>>>>>>> 01b0 - 9c f3 04 32 cd 1d df 18-e5 4d e3 e8 b1 38 59 f8 ...2.....M...8Y. >>>>>>>>> 01c0 - 28 67 2e ca af a2 8b 88-ce ca 48 a6 07 2b a6 9a (g........H..+.. >>>>>>>>> 01d0 - 0e 88 5b d7 0b d9 31 77-97 8d 6c 2b f5 60 24 61 ..[...1w..l+.`$a >>>>>>>>> 01e0 - a8 5c 47 5d 7c 66 f0 9b-1f e4 76 93 38 f6 78 3e .\G]|f....v.8.x> >>>>>>>>> 01f0 - 69 29 72 f9 d9 4b cb 05-03 e4 f2 d6 24 e1 91 ee i)r..K......$... >>>>>>>>> 0200 - 85 37 d7 7b c3 5c 35 90-08 cd b1 cc 76 11 fc 00 .7.{.\5.....v... >>>>>>>>> 0210 - 12 7e 89 7b 70 e6 ca fe-0b 26 b6 bb ac fe 4b 9f .~.{p....&....K. >>>>>>>>> 0220 - ec cf 41 69 42 3a 3e 41-f9 b0 c0 93 5b 70 1f c7 ..AiB:>A....[p.. >>>>>>>>> 0230 - 11 00 3d ec 66 5a 1a ca-31 89 22 27 02 dd a0 cb ..=.fZ..1."'.... >>>>>>>>> 0240 - 39 14 25 ee 30 44 e8 62-97 bf 8e 16 63 40 c4 11 9.%.0D.b....c at .. >>>>>>>>> 0250 - a6 d9 32 b1 3c 86 35 bb-9f f1 4d 71 9f a5 4f 78 ..2.<.5...Mq..Ox >>>>>>>>> 0260 - 0a e8 96 dd 4d 10 c3 48-f2 db 67 57 2d cd dc 23 ....M..H..gW-..# >>>>>>>>> 0270 - 3a 8d 6a 61 47 20 ff c8-33 cd e9 f7 47 4c 68 4f :.jaG ..3...GLhO >>>>>>>>> 0280 - 19 2f 8b e3 b1 90 ac 66-a7 cf 5c e6 d2 05 21 25 ./.....f..\...!% >>>>>>>>> 0290 - d2 d8 f0 43 8c 55 01 ef-d6 8f c0 27 87 0d 21 d5 ...C.U.....'..!. >>>>>>>>> 02a0 - 2b 2b 6f db e8 85 ea cd-6e 9c 5d 56 d5 31 c1 f2 ++o.....n.]V.1.. >>>>>>>>> 02b0 - 97 2f 5a 83 7a 2b 71 03-65 e0 b6 4a 56 37 de e1 ./Z.z+q.e..JV7.. >>>>>>>>> 02c0 - 80 3a c4 cc 5a ac 3b 9a-7a bf f7 6b fe a8 69 e9 .:..Z.;.z..k..i. >>>>>>>>> 02d0 - 58 09 59 bd 46 bd d2 a3-bc ad 1c 10 53 c8 29 7b X.Y.F.......S.){ >>>>>>>>> 02e0 - be 63 00 d6 e5 a8 d6 ab-b2 bc 8b e1 2c 0e 24 2a .c..........,.$* >>>>>>>>> 02f0 - c2 31 2d d8 6e 1f 19 93-d7 54 e1 1e 28 ce 72 83 .1-.n....T..(.r. >>>>>>>>> 0300 - ff 05 18 f2 fc e9 0c b3-0c 1b d5 96 c2 d8 fc 76 ...............v >>>>>>>>> 0310 - 37 a9 5a ef 8e e9 b6 71-21 f3 bd c1 85 23 85 22 7.Z....q!....#." >>>>>>>>> 0320 - 3d c4 1c c9 31 8b 7e 00-8f 8e b4 9f 05 d4 80 6b =...1.~........k >>>>>>>>> 0330 - 98 4c a8 82 68 ff 1a a5-28 e2 9b 03 a1 a7 b1 00 .L..h...(....... >>>>>>>>> 0340 - 02 2b 2d e2 e1 87 8c e8-0a fb 0b 79 54 ca 3d d5 .+-........yT.=. >>>>>>>>> 0350 - 6a dd b7 b7 87 42 2b 47-49 da e9 0a 82 0a c9 8f j....B+GI....... >>>>>>>>> 0360 - 57 f7 1e 03 ca 8d 16 bc-21 3a 6a ee b9 b8 fa f0 W.......!:j..... >>>>>>>>> 0370 - d9 18 35 9f 35 ac d8 6e-9a 8a 0d 56 10 1e 1f 5a ..5.5..n...V...Z >>>>>>>>> 0380 - ba ec e4 fe 1a 92 b4 31-35 43 1d 99 b9 12 fa ff .......15C...... >>>>>>>>> 0390 - 99 2b 88 e0 58 ec 9c dc-8f 67 ef 2a c2 e2 64 5d .+..X....g.*..d] >>>>>>>>> 03a0 - 66 76 1c d0 aa 00 30 59-b1 f5 b1 55 9f ad 60 e9 fv....0Y...U..`. >>>>>>>>> 03b0 - 3d 03 1e d0 8b 4d bf 74-ac bc bb 1c 83 14 c5 e0 =....M.t........ >>>>>>>>> 03c0 - f4 fc 70 9e f4 22 a0 78-04 fe c8 b1 17 65 f6 94 ..p..".x.....e.. >>>>>>>>> 03d0 - 47 82 50 4a b6 32 74 ae-5b 38 5a 2e d9 b0 6a 45 G.PJ.2t.[8Z...jE >>>>>>>>> 03e0 - 74 e8 f0 22 fe d3 b0 11-c3 fd 72 4f da 77 7a ba t.."......rO.wz. >>>>>>>>> 03f0 - 26 3e 61 0c 63 21 17 a6-b2 13 6e 71 5c f2 0d ad &>a.c!....nq\... >>>>>>>>> 0400 - f2 d1 19 71 51 9e a4 1b-b0 30 24 e0 71 7d 87 80 ...qQ....0$.q}.. >>>>>>>>> 0410 - a9 5a e9 bc db e4 4f 50-4d a1 bc bc 2c 4b 66 98 .Z....OPM...,Kf. >>>>>>>>> 0420 - d4 e4 b0 76 0f d2 db a5-a5 39 9e f2 5b ea 34 c1 ...v.....9..[.4. >>>>>>>>> 0430 - 62 ab 47 51 3b 37 17 45-54 31 18 f3 f1 ca 17 03 b.GQ;7.ET1...... >>>>>>>>> 0440 - 03 01 19 dd 50 50 f5 0c-f2 c9 3c b4 8f 63 cc 4a ....PP....<..c.J >>>>>>>>> 0450 - a7 50 c9 91 9b 79 9a 2a-5c 47 d3 77 f6 56 69 90 .P...y.*\G.w.Vi. >>>>>>>>> 0460 - 98 cd ff bd c1 2a 49 fc-0d d4 7e cc 7e 44 af c4 .....*I...~.~D.. >>>>>>>>> 0470 - 61 47 e0 c1 76 b1 8c 2e-df 7e d0 82 e1 89 1f 04 aG..v....~...... >>>>>>>>> 0480 - ae 64 bd 71 4d ae 1c 3c-e3 d3 39 5d 61 2a ea 70 .d.qM..<..9]a*.p >>>>>>>>> 0490 - 8c 31 6d a0 b1 72 a8 7a-5c 9c 11 08 b8 4d a5 c4 .1m..r.z\....M.. >>>>>>>>> 04a0 - ad 1b 38 4a 6a 02 28 d4-d1 0f c8 9f 0b b3 02 18 ..8Jj.(......... >>>>>>>>> 04b0 - 82 2b bd 46 82 04 64 f0-41 b2 da f5 cd 9c f7 f3 .+.F..d.A....... >>>>>>>>> 04c0 - 73 30 58 ca 12 ec ea 90-85 1c 75 09 0a 70 b8 80 s0X.......u..p.. >>>>>>>>> 04d0 - 3d 02 17 3e 9b 83 04 b5-dd 9e e6 18 17 65 83 a5 =..>.........e.. >>>>>>>>> 04e0 - 59 7d 4b 98 da bd 8b aa-d6 aa c5 1c 7d 87 56 e3 Y}K.........}.V. >>>>>>>>> 04f0 - 74 d8 e9 7b eb b3 3d f7-7c 3c 0a e9 a8 2e 04 0d t..{..=.|<...... >>>>>>>>> 0500 - 6a e7 83 e0 ec 99 43 6a-8b 1c 73 59 7a c8 cd 6e j.....Cj..sYz..n >>>>>>>>> 0510 - 4a 14 73 ff 9a fb 71 94-d5 50 a9 d9 e0 dd 02 4c J.s...q..P.....L >>>>>>>>> 0520 - 2b 67 9e da 9e fa 2d 67-49 df 13 10 ed 35 3e 73 +g....-gI....5>s >>>>>>>>> 0530 - 07 20 17 fb 0b ef f6 d0-b7 68 1c 65 21 a6 e3 3b . .......h.e!..; >>>>>>>>> 0540 - bf 7b 84 cd 9e f5 76 2a-0d 4f b8 c3 c8 15 08 e9 .{....v*.O...... >>>>>>>>> 0550 - 0f 3c 50 49 12 97 a8 d7-f1 a3 16 da 17 03 03 00 .>>>>>>>> 0560 - 35 22 dd a2 9d 25 98 2c-35 b8 00 29 fa a1 dd ba 5"...%.,5..).... >>>>>>>>> 0570 - 72 b9 fe e5 85 85 f0 f1-3b 4e f5 7c 58 c8 2a da r.......;N.|X.*. >>>>>>>>> 0580 - d2 75 94 3b c1 7a 7c 7e-db 5b fe 8a 2d 3f 8c 9a .u.;.z|~.[..-?.. >>>>>>>>> 0590 - 6e 79 ab 2b ff 1a ny.+.. >>>>>>>>> SSL_accept:SSLv3/TLS write finished >>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>>>>> 0000 - 14 03 03 00 01 ..... >>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (1 bytes => 1 (0x1)) >>>>>>>>> 0000 - 01 . >>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>>>>> 0000 - 17 03 03 00 3d ....= >>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (61 bytes => 61 (0x3D)) >>>>>>>>> 0000 - 38 e7 bb 2c 5b af b6 5f-37 d8 3e 7e bb f4 04 f5 8..,[.._7.>~.... >>>>>>>>> 0010 - e1 28 b5 e5 07 5a ec ce-da 2f f3 b6 45 61 cf ef .(...Z.../..Ea.. >>>>>>>>> 0020 - 90 fb 57 b8 f3 20 45 27-60 d4 26 51 38 77 e4 bc ..W.. E'`.&Q8w.. >>>>>>>>> 0030 - b7 64 d4 8b 73 25 41 9e-fe d3 9d 5f 53 .d..s%A...._S >>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>> write to 0x7fe400f050c0 [0x7fe403018a00] (24 bytes => 24 (0x18)) >>>>>>>>> 0000 - 17 03 03 00 13 25 85 60-eb 7d c1 a8 15 49 d5 63 .....%.`.}...I.c >>>>>>>>> 0010 - 18 7f c6 ac ed 7f df 77- .......w >>>>>>>>> SSL3 alert write:fatal:unknown >>>>>>>>> SSL_accept:error in error >>>>>>>>> ERROR >>>>>>>>> 140736092021632:error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate:ssl/statem/statem_srvr.c:3654: >>>>>>>>> shutting down SSL >>>>>>>>> CONNECTION CLOSED >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> When using openssl s_client all works as expected tho (thats also true if I use my native implementation on the client and server side that uses openssl): >>>>>>>>> >>>>>>>>> ./bin/openssl s_client -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 -state -tls1_3 -connect localhost:8443 >>>>>>>>> >>>>>>>>> The interesting thing is if I use ?-verify 1? and not ?-Verify 1? with openssl which tells it I want to request a certificate but will also process if none is provided I receive the certificate at some point as seen here: >>>>>>>>> >>>>>>>>> SSL_accept:before SSL initialization >>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>> 0000 - 16 03 03 01 60 ....` >>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (352 bytes => 352 (0x160)) >>>>>>>>> 0000 - 01 00 01 5c 03 03 61 c0-b3 ed 88 65 e6 cf 11 3f ...\..a....e...? >>>>>>>>> 0010 - c0 e0 f8 df a6 63 32 c2-ab 3d 61 6f 41 ed b1 4b .....c2..=aoA..K >>>>>>>>> 0020 - 53 0e 83 e5 a1 b8 20 c7-1b 8c b8 e6 b5 da 4e 4e S..... .......NN >>>>>>>>> 0030 - 3f 3c 61 7a ad 58 23 94-a7 32 79 2f db 9f 21 c0 ?>>>>>>>> 0040 - 8e 0c c5 ce b1 c2 a4 00-14 c0 2c c0 2b c0 2f c0 ..........,.+./. >>>>>>>>> 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 52 dc d6 47 6e .3.G.E...A.R..Gn >>>>>>>>> 0120 - a1 de 9c 71 c2 54 0e 5c-9b 57 fb c8 aa 3f 19 f7 ...q.T.\.W...?.. >>>>>>>>> 0130 - d3 a4 25 12 fa 3f 6c 6d-95 30 66 ca 63 b7 a1 dd ..%..?lm.0f.c... >>>>>>>>> 0140 - ae 9f 99 d6 a8 6b 20 4f-29 7a 74 58 ad 58 de 12 .....k O)ztX.X.. >>>>>>>>> 0150 - d7 a5 9b 69 dc 27 ac ec-9e d4 04 ff 01 00 01 00 ...i.'.......... >>>>>>>>> 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 0x7fdc58809fb0 [0x7fdc59025e00] (1430 bytes => 1430 (0x596)) >>>>>>>>> 0000 - 16 03 03 00 9b 02 00 00-97 03 03 8b c8 62 48 6c .............bHl >>>>>>>>> 0010 - f5 7c 73 d9 17 f8 63 a2-11 27 40 93 09 26 53 06 .|s...c..'@..&S. >>>>>>>>> 0020 - b3 62 df 46 26 b6 dc 59-29 b5 58 20 c7 1b 8c b8 .b.F&..Y).X .... >>>>>>>>> 0030 - e6 b5 da 4e 4e 3f 3c 61-7a ad 58 23 94 a7 32 79 ...NN?>>>>>>>> 0040 - 2f db 9f 21 c0 8e 0c c5-ce b1 c2 a4 13 01 00 00 /..!............ >>>>>>>>> 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 O.+.....3.E...A. >>>>>>>>> 0060 - 07 63 1c 19 53 89 68 a8-0f ea 9e 4c 18 6f 2a ad .c..S.h....L.o*. >>>>>>>>> 0070 - 2a df eb 17 a2 08 94 c6-e3 c5 97 ae 0f c1 1a d7 *............... >>>>>>>>> 0080 - 0d d7 2e 6d 77 3d 30 a0-07 db 70 35 bb 37 dd 1e ...mw=0...p5.7.. >>>>>>>>> 0090 - b6 f3 4d cb 13 97 7c 11-63 98 e8 64 2d a7 e6 cc ..M...|.c..d-... >>>>>>>>> 00a0 - 14 03 03 00 01 01 17 03-03 00 27 a3 73 d2 ee 2c ..........'.s.., >>>>>>>>> 00b0 - 2f 9c 8f 95 7f ca a3 89-bc b4 b3 b2 3c 8b 23 ef /...........<.#. >>>>>>>>> 00c0 - 36 66 23 c9 09 02 33 0d-dc 5d 36 61 44 89 8b ef 6f#...3..]6aD... >>>>>>>>> 00d0 - fd 13 17 03 03 00 42 f2-5b 3c 0c 27 5e 7f 97 4f ......B.[<.'^..O >>>>>>>>> 00e0 - 0f de 8c b9 0a a1 41 c7-c2 1e 92 99 6a d5 bd 12 ......A.....j... >>>>>>>>> 00f0 - 38 b6 b7 93 33 e9 8e 0f-44 93 f0 69 58 b6 41 22 8...3...D..iX.A" >>>>>>>>> 0100 - 46 e2 4a d5 d6 32 2b b8-a7 ae 3a c2 c5 2f e6 35 F.J..2+...:../.5 >>>>>>>>> 0110 - 11 0c f1 9a 35 2a 87 ed-9e 17 03 03 03 20 a7 e2 ....5*....... .. >>>>>>>>> 0120 - fe ba c7 10 5b 9c cd 94-67 19 37 2d 46 59 ab 56 ....[...g.7-FY.V >>>>>>>>> 0130 - 6b dd a4 10 61 cc ed f1-71 a7 2d 6a 41 2e 2b da k...a...q.-jA.+. >>>>>>>>> 0140 - d1 35 fc 01 df 49 e5 90-1d 9b b2 03 0a 81 58 18 .5...I........X. >>>>>>>>> 0150 - 96 a1 db 31 19 98 35 5c-87 8f 6e 32 0a e6 c0 aa ...1..5\..n2.... >>>>>>>>> 0160 - 9e 8e 72 e2 34 b3 b7 a3-d6 d1 66 c7 ce 93 fe 78 ..r.4.....f....x >>>>>>>>> 0170 - 17 c4 71 7c 42 15 c8 af-dc 4f 50 42 51 80 fc bf ..q|B....OPBQ... >>>>>>>>> 0180 - fc 54 d5 d8 59 20 9a 90-c4 78 97 9c 2d 4a d5 58 .T..Y ...x..-J.X >>>>>>>>> 0190 - be 81 79 23 59 22 9d 27-f8 bd a0 b2 98 b3 47 82 ..y#Y".'......G. >>>>>>>>> 01a0 - d3 52 b5 b5 91 ab 5c 76-52 c5 a5 95 2d 03 1c b7 .R....\vR...-... >>>>>>>>> 01b0 - 64 4d 0b 88 7f 15 0b c8-a8 90 50 9a b6 b1 9f b7 dM........P..... >>>>>>>>> 01c0 - 40 09 f2 5f 39 f8 9a 06-21 4d 67 10 0a 67 08 b6 @.._9...!Mg..g.. >>>>>>>>> 01d0 - b5 9a 25 8c d5 ca 31 6a-8a 6b 01 93 7d 6f 1e 52 ..%...1j.k..}o.R >>>>>>>>> 01e0 - 98 96 9d fb e8 c1 07 ab-57 98 2d 1e 75 77 ef c2 ........W.-.uw.. >>>>>>>>> 01f0 - 49 78 e0 b9 2b 32 23 7e-95 4d 3e 27 00 61 86 0c Ix..+2#~.M>'.a.. >>>>>>>>> 0200 - 47 c7 79 e4 ee 9d ba c0-ea 62 f1 0d 8e 4a 91 30 G.y......b...J.0 >>>>>>>>> 0210 - bc 4f 5a 98 26 30 66 ec-c4 63 8f 28 d5 1c 61 23 .OZ.&0f..c.(..a# >>>>>>>>> 0220 - ea e9 90 4e 36 d9 fa 31-7b 14 27 22 0a ae 9f 64 ...N6..1{.'"...d >>>>>>>>> 0230 - 40 3d e5 a0 5c 9d 3c 04-71 09 b0 7a 6b 51 a0 9c @=..\.<.q..zkQ.. >>>>>>>>> 0240 - c0 61 32 ce 15 62 8e 29-b1 59 91 c0 17 2c b3 c5 .a2..b.).Y...,.. >>>>>>>>> 0250 - f9 ed 07 65 3d 11 de 98-de 62 36 50 74 37 af 2d ...e=....b6Pt7.- >>>>>>>>> 0260 - 7d 86 55 c4 3e a2 83 ab-47 8d f2 b2 8d 1d 75 83 }.U.>...G.....u. >>>>>>>>> 0270 - b5 e4 41 87 a7 a3 85 b0-5e 4e 2e 9c 8c b0 1b 83 ..A.....^N...... >>>>>>>>> 0280 - 7b 54 79 c9 60 ea 7d ed-06 fa dd 24 40 f1 53 9e {Ty.`.}....$@.S. >>>>>>>>> 0290 - 43 79 25 53 9c c7 6e 95-ab 9f 96 59 cd b9 7b a8 Cy%S..n....Y..{. >>>>>>>>> 02a0 - a0 23 13 69 db a9 c9 e7-1a 8e e1 9b 54 94 1c 44 .#.i........T..D >>>>>>>>> 02b0 - 50 08 8b dd eb 4e 2b bb-d7 c9 c2 33 8c a1 b3 65 P....N+....3...e >>>>>>>>> 02c0 - 06 e6 9d ac 11 16 21 58-40 8d 59 e6 67 e5 31 02 ......!X at .Y.g.1. >>>>>>>>> 02d0 - 15 8d 29 80 20 66 ba c3-56 93 95 5c 65 4b 41 00 ..). f..V..\eKA. >>>>>>>>> 02e0 - c5 71 12 12 f5 20 4f 59-be 77 06 10 6e 48 85 5c .q... OY.w..nH.\ >>>>>>>>> 02f0 - ff a2 c4 ae fb 4d 95 f5-cc f6 61 20 33 b7 92 1d .....M....a 3... >>>>>>>>> 0300 - ac a8 f1 b2 b0 88 c6 7b-8b 00 53 30 6d 4a d1 42 .......{..S0mJ.B >>>>>>>>> 0310 - b3 3e 85 f5 84 e1 c6 ab-10 9d 61 03 46 ff 2d 81 .>........a.F.-. >>>>>>>>> 0320 - 15 4f 84 d1 4c ee f4 a6-a0 ec 50 60 a0 d1 ff df .O..L.....P`.... >>>>>>>>> 0330 - 8a 97 f6 7d fb 8f fb 60-18 d4 f1 1f 92 4d d8 69 ...}...`.....M.i >>>>>>>>> 0340 - b1 92 97 44 0f 3c 8a aa-47 07 48 d4 07 2d 3e f2 ...D.<..G.H..->. >>>>>>>>> 0350 - c4 a7 16 35 a7 17 71 ef-98 84 24 67 12 58 30 3b ...5..q...$g.X0; >>>>>>>>> 0360 - 1d 41 8d e5 12 52 95 64-e5 88 35 99 d7 c3 58 40 .A...R.d..5...X@ >>>>>>>>> 0370 - f9 55 9b 9f e5 33 15 70-41 d7 45 ba a4 fc 75 ea .U...3.pA.E...u. >>>>>>>>> 0380 - a4 ae f0 68 ea 64 d8 f5-06 68 a9 75 22 4d 43 cc ...h.d...h.u"MC. >>>>>>>>> 0390 - ff 50 cc ac 6e fd 43 dd-eb e4 c8 dd 4b 6c 12 bb .P..n.C.....Kl.. >>>>>>>>> 03a0 - f1 d4 5e 11 4a 86 90 0b-f8 3a 2e 23 db 61 5a 1f ..^.J....:.#.aZ. >>>>>>>>> 03b0 - 7e 11 00 92 21 68 1f b5-ab f2 f8 38 5e 62 ea f8 ~...!h.....8^b.. >>>>>>>>> 03c0 - da ef c2 6e a0 b8 20 e4-69 49 b3 1f 15 84 0b 9b ...n.. .iI...... >>>>>>>>> 03d0 - ce b0 6f 36 32 7f 7e bf-e8 d7 18 7a 58 60 f4 04 ..o62.~....zX`.. >>>>>>>>> 03e0 - cc 36 bf 06 cd ec e5 9b-19 03 96 09 fb af 8f c3 .6.............. >>>>>>>>> 03f0 - 98 b4 02 aa e8 55 81 aa-c4 fe 06 81 30 a0 c7 b2 .....U......0... >>>>>>>>> 0400 - f8 e2 30 00 d7 a0 54 7f-5f d7 ef a6 f8 41 58 34 ..0...T._....AX4 >>>>>>>>> 0410 - f5 f0 18 69 8d e6 7a 23-78 90 8f b1 05 c5 b5 7f ...i..z#x....... >>>>>>>>> 0420 - e0 f2 c7 fa c8 36 5b 53-7e cf e6 75 d3 54 b4 69 .....6[S~..u.T.i >>>>>>>>> 0430 - 68 43 0d 6a d2 83 cc 13-6d ca bf 83 3c 90 17 03 hC.j....m...<... >>>>>>>>> 0440 - 03 01 19 96 dc 49 26 ce-1d 8e 86 3d bd cb 00 5e .....I&....=...^ >>>>>>>>> 0450 - ee f6 e7 1d 16 7a ca ef-fa 6d 16 40 b6 99 d0 c1 .....z...m. at .... >>>>>>>>> 0460 - df 0b 5f 51 60 a8 24 e0-61 82 13 40 da 88 38 3a .._Q`.$.a.. at ..8: >>>>>>>>> 0470 - 26 1d 80 51 c4 b1 95 35-95 3c 91 35 28 17 49 d8 &..Q...5.<.5(.I. >>>>>>>>> 0480 - c3 45 be 32 98 3e 02 07-3b 01 20 2b 51 e1 1a 94 .E.2.>..;. +Q... >>>>>>>>> 0490 - b9 be 96 aa 7a 13 09 ff-d5 a9 63 d4 6f 49 cb b5 ....z.....c.oI.. >>>>>>>>> 04a0 - 23 ab 7f 8c e2 63 f0 5c-5c 27 1e 04 a8 71 0c c0 #....c.\\'...q.. >>>>>>>>> 04b0 - 89 cd ed 18 8d 5b 75 ac-af f3 68 6d cc ba 20 38 .....[u...hm.. 8 >>>>>>>>> 04c0 - b5 7c 09 47 29 28 e2 26-57 57 1f f0 f3 18 fd 6f .|.G)(.&WW.....o >>>>>>>>> 04d0 - 27 42 a4 e3 de bb e5 d6-09 7d 25 b1 98 97 ad 33 'B.......}%....3 >>>>>>>>> 04e0 - 68 35 92 07 80 23 f1 66-20 5d 74 f3 02 c5 51 ff h5...#.f ]t...Q. >>>>>>>>> 04f0 - 07 a9 e9 0e 3e 74 da 2e-8f 3b 16 be e6 94 1b 66 ....>t...;.....f >>>>>>>>> 0500 - bb b2 a2 1e 7c 7b ff 5e-a4 36 2a ba 0b cd 7f e9 ....|{.^.6*..... >>>>>>>>> 0510 - 86 bb 5e 30 f5 57 92 52-82 b6 2e da 71 b7 22 c2 ..^0.W.R....q.". >>>>>>>>> 0520 - 90 c4 69 46 07 df 6c 3f-05 8b 19 3e ce b9 75 0d ..iF..l?...>..u. >>>>>>>>> 0530 - 4b 97 37 ae 94 e2 d6 3c-91 e6 82 c7 a1 78 79 2c K.7....<.....xy, >>>>>>>>> 0540 - 9a a3 d5 45 94 ad e2 c8-ab fd 81 ec 62 87 f7 75 ...E........b..u >>>>>>>>> 0550 - e3 70 79 8e 82 3b c5 45-0d d0 33 5f 17 03 03 00 .py..;.E..3_.... >>>>>>>>> 0560 - 35 da e0 74 2a 06 41 5a-64 1e 54 94 29 73 43 3f 5..t*.AZd.T.)sC? >>>>>>>>> 0570 - e5 24 a8 ba b2 7e 6b 26-82 fc d9 f6 dd 19 05 4a .$...~k&.......J >>>>>>>>> 0580 - 2c 1a f3 bb 16 1d 38 95-a6 d3 a8 58 f6 a3 41 c7 ,.....8....X..A. >>>>>>>>> 0590 - 92 44 35 24 25 0e .D5$%. >>>>>>>>> SSL_accept:SSLv3/TLS write finished >>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>> 0000 - 14 03 03 00 01 ..... >>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (1 bytes => 1 (0x1)) >>>>>>>>> 0000 - 01 . >>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>> 0000 - 17 03 03 00 3d ....= >>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (61 bytes => 61 (0x3D)) >>>>>>>>> 0000 - ad dd 3e d9 ee ab 56 65-50 1c 72 2a d8 62 7f 90 ..>...VeP.r*.b.. >>>>>>>>> 0010 - 13 71 7d 37 39 40 fb 89-8f 05 4b 39 44 9d 4d 67 .q}79 at ....K9D.Mg >>>>>>>>> 0020 - e3 41 29 b6 3e e8 fe 04-1b 8e eb 7a 4c e2 14 a0 .A).>......zL... >>>>>>>>> 0030 - b1 c2 47 3f 94 35 ed ab-8a d1 75 3b ba ..G?.5....u;. >>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>> SSL_accept:SSLv3/TLS read client certificate >>>>>>>>> SSL_accept:SSLv3/TLS read finished >>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>>>>>> 0000 - 17 03 03 00 da 52 1f 48-00 f4 31 13 90 7f 9c c2 .....R.H..1..... >>>>>>>>> 0010 - fc 70 1a fc f7 4a 48 e7-31 ad 37 ab b5 2b 4e 5c .p...JH.1.7..+N\ >>>>>>>>> 0020 - e8 d8 6d e9 af 6c 4f c1-9e 7b ea ff ef b3 eb 74 ..m..lO..{.....t >>>>>>>>> 0030 - 27 67 10 21 66 5b 32 13-31 bc 99 d5 1c 6c 79 55 'g.!f[2.1....lyU >>>>>>>>> 0040 - f3 3e f6 4b 07 4d a9 78-3d 12 8a f5 38 ef d9 f4 .>.K.M.x=...8... >>>>>>>>> 0050 - 48 e0 2c 35 94 06 4f eb-09 e6 70 fb 59 95 7a c8 H.,5..O...p.Y.z. >>>>>>>>> 0060 - 24 dd 24 e2 f9 63 b9 3c-f2 66 86 c4 73 44 53 fd $.$..c.<.f..sDS. >>>>>>>>> 0070 - ca 67 8f 01 d6 db 70 f9-60 bc 50 11 51 72 dc 63 .g....p.`.P.Qr.c >>>>>>>>> 0080 - 12 ca 4f 23 e2 c5 d1 1d-e5 b0 d4 ec 89 ca 28 be ..O#..........(. >>>>>>>>> 0090 - 9c 30 83 40 02 a4 62 a8-5c b3 20 1a ab 39 b7 7b .0. at ..b.\. ..9.{ >>>>>>>>> 00a0 - 89 13 39 87 73 be a8 f8-60 13 31 0a 48 5c 79 b9 ..9.s...`.1.H\y. >>>>>>>>> 00b0 - cc 4a 51 e3 0d d2 b4 93-c0 1f 3a 22 b3 fa 24 a0 .JQ.......:"..$. >>>>>>>>> 00c0 - 7c f6 76 79 d0 2d 5b 1a-ff a6 e9 e1 40 d3 b1 8c |.vy.-[..... at ... >>>>>>>>> 00d0 - 0a fa fa de f3 8e d6 ad-9a 22 6b 67 0b 88 18 ........."kg... >>>>>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>>>>>> 0000 - 17 03 03 00 da 46 aa ea-6a 37 b1 35 e8 41 c8 b3 .....F..j7.5.A.. >>>>>>>>> 0010 - 84 25 af 1c 36 a3 6d 78-a4 44 4a 83 52 ef 13 7c .%..6.mx.DJ.R..| >>>>>>>>> 0020 - 8f 18 d3 4c f8 22 c8 b3-ad d0 d0 5b 47 a0 43 da ...L.".....[G.C. >>>>>>>>> 0030 - d2 6e 04 8f dc c9 56 90-58 87 62 63 4c cc 31 ec .n....V.X.bcL.1. >>>>>>>>> 0040 - b8 c9 18 be 41 32 e1 3c-00 41 2a f1 4d 5c 2d 44 ....A2.<.A*.M\-D >>>>>>>>> 0050 - 8c aa e1 f0 ed 38 ee 44-64 e5 fd ea 58 3b 84 5d .....8.Dd...X;.] >>>>>>>>> 0060 - 83 39 21 2e fe 79 4d 76-10 65 87 0f 3c ac df 28 .9!..yMv.e..<..( >>>>>>>>> 0070 - 49 f8 60 eb be 49 e4 0a-0b 6a 03 2b 9d cf 9b a5 I.`..I...j.+.... >>>>>>>>> 0080 - 03 56 58 32 c2 b2 59 f9-0a 0d f0 ae af ff 20 19 .VX2..Y....... . >>>>>>>>> 0090 - e5 6e e4 86 2f 5e 3f 7d-47 d5 73 ae 89 48 a7 66 .n../^?}G.s..H.f >>>>>>>>> 00a0 - fb 2d 83 60 e8 8b ab 27-12 db 24 78 54 eb 14 2d .-.`...'..$xT..- >>>>>>>>> 00b0 - b7 c6 17 2d 3c 91 57 ac-6e 35 b8 c3 fa c2 42 48 ...-<.W.n5....BH >>>>>>>>> 00c0 - 2a cb aa 98 32 89 8a ce-0c f7 cd 5e fb bf 6d 33 *...2......^..m3 >>>>>>>>> 00d0 - 08 50 cf 1e 06 bb a1 98-be a4 a9 51 9a b0 34 .P.........Q..4 >>>>>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>>>> 0000 - 17 03 03 00 12 c5 9b 73-cc 91 7e 48 cb 25 31 a0 .......s..~H.%1. >>>>>>>>> 0010 - 67 41 db bb 0f 62 d8 gA...b. >>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>>>> 0000 - 17 03 03 00 12 0f dd 3f-c1 7c e6 b0 cc ea f0 13 .......?.|...... >>>>>>>>> 0010 - 00 d8 01 de ef 7c bb .....|. >>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>> 0000 - 17 03 03 00 1e ..... >>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (30 bytes => 30 (0x1E)) >>>>>>>>> 0000 - d6 88 44 82 cb 23 16 ba-c9 a4 fb 55 51 08 90 c1 ..D..#.....UQ... >>>>>>>>> 0010 - bf bd a1 7f 0e 37 b0 b4-b5 df f1 07 6c 07 .....7......l. >>>>>>>>> I am a clientwrite to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>>>> 0000 - 17 03 03 00 12 c0 70 5d-14 e7 69 57 0a d8 64 16 ......p]..iW..d. >>>>>>>>> 0010 - 0c 90 06 0f c3 4d 1d .....M. >>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>> 0000 - 17 03 03 00 13 ..... >>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (19 bytes => 19 (0x13)) >>>>>>>>> 0000 - 60 28 5b ff bb 0d 9f 96-9a 2d cb fd 60 eb 96 62 `([......-..`..b >>>>>>>>> 0010 - 53 e6 25 S.% >>>>>>>>> SSL3 alert read:warning:close notify >>>>>>>>> DONE >>>>>>>>> shutting down SSL >>>>>>>>> CONNECTION CLOSED >>>>>>>>> >>>>>>>>> >>>>>>>>> I am using the following JDK version on MacOS: >>>>>>>>> >>>>>>>>> ssl git:(cert_cb_openssl_1_1_1) ? /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java -version >>>>>>>>> java version "11" 2018-09-25 >>>>>>>>> Java(TM) SE Runtime Environment 18.9 (build 11+28) >>>>>>>>> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) >>>>>>>>> >>>>>>>>> For this to work you will need to have openssl 1.1.1 installed. >>>>>>>>> >>>>>>>>> Any help would be welcome, >>>>>>>>> Norman >>>>>>>>> >>>>>>>>> [1] https://github.com/netty/netty-tcnative > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Wed Sep 19 16:05:17 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 19 Sep 2018 09:05:17 -0700 Subject: RFR(XS): 8210912: Build error in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c after JDK-8029661 Message-ID: <285A1522-F010-4AB5-8EDD-D63E901A2D89@oracle.com> Please review this change which fixes a Solaris/SPARC build issue: bug: https://bugs.openjdk.java.net/browse/JDK-8210912 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210912/webrev.00/open/webrev/ Testing: Tier1 test job (still in progress, but relevant builds passed). Cheers, Mikael -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Sep 19 16:13:32 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 19 Sep 2018 12:13:32 -0400 Subject: RFR(XS): 8210912: Build error in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c after JDK-8029661 In-Reply-To: <285A1522-F010-4AB5-8EDD-D63E901A2D89@oracle.com> References: <285A1522-F010-4AB5-8EDD-D63E901A2D89@oracle.com> Message-ID: <9aa1f00e-0a7e-c100-1de4-a8cb44e08f09@oracle.com> Looks ok to me. The bug needs an appropriate noreg label. --Sean On 9/19/18 12:05 PM, Mikael Vidstedt wrote: > > Please review this change which fixes a Solaris/SPARC build issue: > > bug: https://bugs.openjdk.java.net/browse/JDK-8210912 > webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8210912/webrev.00/open/webrev/ > > Testing: > > Tier1 test job (still in progress, but relevant builds passed). > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Wed Sep 19 16:28:23 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 19 Sep 2018 09:28:23 -0700 Subject: RFR(XS): 8210912: Build error in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c after JDK-8029661 In-Reply-To: <9aa1f00e-0a7e-c100-1de4-a8cb44e08f09@oracle.com> References: <285A1522-F010-4AB5-8EDD-D63E901A2D89@oracle.com> <9aa1f00e-0a7e-c100-1de4-a8cb44e08f09@oracle.com> Message-ID: Thank you! Change pushed and noreg-build label added. Cheers, Mikael > On Sep 19, 2018, at 9:13 AM, Sean Mullan wrote: > > Looks ok to me. The bug needs an appropriate noreg label. > > --Sean > > On 9/19/18 12:05 PM, Mikael Vidstedt wrote: >> Please review this change which fixes a Solaris/SPARC build issue: >> bug: https://bugs.openjdk.java.net/browse/JDK-8210912 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210912/webrev.00/open/webrev/ >> Testing: >> Tier1 test job (still in progress, but relevant builds passed). >> Cheers, >> Mikael From xuelei.fan at oracle.com Wed Sep 19 16:34:07 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 19 Sep 2018 09:34:07 -0700 Subject: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: <499D9F15-3CF1-4FDC-80AB-5A73FCB744FD@googlemail.com> References: <32bad254-1a8c-7933-d5a0-0b8ce3ed2f68@oracle.com> <05EF82F5-6506-4928-8030-B9BEEE64E1F1@googlemail.com> <0EB21A4C-7DFF-4878-9446-182DA35F0A8C@googlemail.com> <2dea4403-e019-613d-373e-75c789029cef@oracle.com> <422BC150-FBAE-4829-B375-637F27C671C4@googlemail.com> <499D9F15-3CF1-4FDC-80AB-5A73FCB744FD@googlemail.com> Message-ID: <9f43f386-ede9-3615-df30-19e0a851b991@oracle.com> Hi Norman, It is just a initial version set. Thanks, Xuelei On 9/19/2018 8:49 AM, Norman Maurer wrote: > I see this is now tracked as > https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8210846?filter=allopenissues?:) > > Just one question, I saw it list 12 as fix version. Is this just the > initial version set or do you not plan to fix it in Java11 ? IMHO this > is a quite an important thing to fix as otherwise you may run into > issues when using SSL on the client-side as most real-world apps use > OpenSSL on the server-side. > > Bye > Norman > > >> On 17. Sep 2018, at 10:44, Norman Maurer > > wrote: >> >> Of course not? >> >> ID: 9057280 >> >> Thanks >> Norman >> >> >>> On 17. Sep 2018, at 19:35, Xuelei Fan >> > wrote: >>> >>> Hi Norman, >>> >>> Thank you so much for the reproducing code. ?Would you mind file a >>> bug for this issue? >>> >>> Thanks, >>> Xuelei >>> >>> On 9/17/2018 3:39 AM, Norman Maurer wrote: >>>> Hi all, >>>> As requested I pushed a pure JDK reproducer to GitHub which you can >>>> easily use to reproduce the problem. All the details how to run it >>>> etc are in the README.md file. I also included a server to show that >>>> all works if we use the JDK on the client side and server side. >>>> Also as stated before you will see that the cert will be send even >>>> if you use OpenSSL on the serverside if you replace ?-Verify 1? with >>>> ?-verify 1? (which is kind of the same as setWantClientAuth(true)). >>>> Please don't hesitate to ping me if you need any more details or >>>> have any more questions. >>>> https://github.com/normanmaurer/jdktls13bugreproducer >>>> Here is the output with debugging enabled on the client side. >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.515 >>>> CEST|SSLContextImpl.java:427|System property >>>> jdk.tls.client.cipherSuites is set to 'null' >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.529 >>>> CEST|SSLContextImpl.java:427|System property >>>> jdk.tls.server.cipherSuites is set to 'null' >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.563 >>>> CEST|SSLCipher.java:437|jdk.tls.keyLimits: ?entry = >>>> AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = >>>> 137438953472 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.577 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.577 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.580 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.580 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_RC4_128_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_RC4_128_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDHE_RSA_WITH_RC4_128_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDHE_RSA_WITH_RC4_128_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_RSA_WITH_RC4_128_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_RSA_WITH_RC4_128_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDH_ECDSA_WITH_RC4_128_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDH_ECDSA_WITH_RC4_128_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDH_RSA_WITH_RC4_128_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDH_RSA_WITH_RC4_128_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_RSA_WITH_RC4_128_MD5 >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_RSA_WITH_RC4_128_MD5 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDH_anon_WITH_RC4_128_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDH_anon_WITH_RC4_128_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DH_anon_WITH_RC4_128_MD5 >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DH_anon_WITH_RC4_128_MD5 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_RSA_EXPORT_WITH_RC4_40_MD5 >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_RSA_EXPORT_WITH_RC4_40_MD5 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.591 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.593 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.593 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.599 >>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.599 >>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.642 >>>> CEST|SunX509KeyManagerImpl.java:164|found key for : 1 ( >>>> "certificate" : { >>>> "version" ? ? ? ? ? ?: "v3", >>>> "serial number" ? ? ?: "20 C3 8D C4 49 66 D0 02", >>>> "signature algorithm": "SHA256withRSA", >>>> "issuer" ? ? ? ? ? ? : >>>> "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>>> "not before" ? ? ? ? : "2013-08-02 09:51:36.000 CEST", >>>> "not ?after" ? ? ? ? : "10000-01-01 24:59:59.000 CET", >>>> "subject" ? ? ? ? ? ?: >>>> "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>>> "subject public key" : "RSA"} >>>> ) >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 >>>> CEST|SSLContextImpl.java:115|trigger seeding of SecureRandom >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 >>>> CEST|SSLContextImpl.java:119|done seeding of SecureRandom >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.665 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_AES_128_GCM_SHA256 for TLS12 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.666 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_AES_256_GCM_SHA384 for TLS12 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_AES_128_GCM_SHA256 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_AES_256_GCM_SHA384 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS11 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_AES_128_GCM_SHA256 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_AES_256_GCM_SHA384 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS10 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 >>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS10 >>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.690 >>>> CEST|ServerNameExtension.java:255|Unable to indicate server name >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.690 >>>> CEST|SSLExtensions.java:235|Ignore, context unavailable extension: >>>> server_name >>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.701 >>>> CEST|SignatureScheme.java:282|Signature algorithm, ed25519, is not >>>> supported by the underlying providers >>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.702 >>>> CEST|SignatureScheme.java:282|Signature algorithm, ed448, is not >>>> supported by the underlying providers >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.706 >>>> CEST|SignatureScheme.java:358|Ignore disabled signature sheme: rsa_md5 >>>> javax.net.ssl|INFO|01|main|2018-09-17 11:51:54.706 >>>> CEST|AlpnExtension.java:161|No available application protocols >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.706 >>>> CEST|SSLExtensions.java:235|Ignore, context unavailable extension: >>>> application_layer_protocol_negotiation >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.707 >>>> CEST|SSLExtensions.java:235|Ignore, context unavailable extension: >>>> cookie >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 >>>> CEST|SSLExtensions.java:235|Ignore, context unavailable extension: >>>> renegotiation_info >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 >>>> CEST|PreSharedKeyExtension.java:606|No session to resume. >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 >>>> CEST|SSLExtensions.java:235|Ignore, context unavailable extension: >>>> pre_shared_key >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 >>>> CEST|ClientHello.java:633|Produced ClientHello handshake message ( >>>> "ClientHello": { >>>> "client version" ? ? ?: "TLSv1.2", >>>> "random" ? ? ? ? ? ? ?: "66 2E BE D3 8A 77 39 06 3B 5A 34 03 7D EE >>>> 74 BB 08 D2 19 FD 50 17 2D 84 29 AA FB E0 EE ED 50 69", >>>> "session id" ? ? ? ? ?: "0B 03 C8 E2 D2 A5 CD 3A 22 C5 85 17 06 64 >>>> A9 30 14 62 C0 AF AB 67 CE 63 50 41 50 7F 6B FD 4C 9F", >>>> "cipher suites" ? ? ? : "[TLS_AES_128_GCM_SHA256(0x1301), >>>> TLS_AES_256_GCM_SHA384(0x1302), >>>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), >>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), >>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), >>>> TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), >>>> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), >>>> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), >>>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), >>>> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), >>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), >>>> TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), >>>> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), >>>> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), >>>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), >>>> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), >>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), >>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), >>>> TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), >>>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), >>>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), >>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), >>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), >>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), >>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), >>>> TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), >>>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), >>>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), >>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), >>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), >>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), >>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), >>>> TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), >>>> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), >>>> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), >>>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), >>>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), >>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), >>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), >>>> TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), >>>> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), >>>> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), >>>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), >>>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), >>>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]", >>>> "compression methods" : "00", >>>> "extensions" ? ? ? ? ?: [ >>>> "status_request (5)": { >>>> "certificate status type": ocsp >>>> "OCSP status request": { >>>> "responder_id": >>>> "request extensions": { >>>> >>>> } >>>> } >>>> }, >>>> "supported_groups (10)": { >>>> "versions": [secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, >>>> sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, >>>> ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] >>>> }, >>>> "ec_point_formats (11)": { >>>> "formats": [uncompressed] >>>> }, >>>> "signature_algorithms (13)": { >>>> "signature schemes": [ecdsa_secp256r1_sha256, >>>> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, >>>> rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, >>>> rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, >>>> rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, >>>> rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] >>>> }, >>>> "signature_algorithms_cert (50)": { >>>> "signature schemes": [ecdsa_secp256r1_sha256, >>>> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, >>>> rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, >>>> rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, >>>> rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, >>>> rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] >>>> }, >>>> "status_request_v2 (17)": { >>>> "cert status request": { >>>> "certificate status type": ocsp_multi >>>> "OCSP status request": { >>>> "responder_id": >>>> "request extensions": { >>>> >>>> } >>>> } >>>> } >>>> }, >>>> "extended_master_secret (23)": { >>>> >>>> }, >>>> "supported_versions (43)": { >>>> "versions": [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1] >>>> }, >>>> "psk_key_exchange_modes (45)": { >>>> "ke_modes": [psk_dhe_ke] >>>> }, >>>> "key_share (51)": { >>>> "client_shares": [ >>>> { >>>> "named group": secp256r1 >>>> "key_exchange": { >>>> 0000: 04 A3 9F B9 05 27 00 38 ? C4 D7 61 6C 66 1F 4A 8D >>>> ??.....'.8..alf.J. >>>> 0010: B1 02 6F 0B F6 E1 BD 50 ? 93 52 86 2C D2 3C 8D 1A >>>> ??..o....P.R.,.<.. >>>> 0020: 10 A9 CD F0 40 F4 CD 04 ? 25 A1 11 E2 58 23 A3 24 >>>> ??.... at ...%...X#.$ >>>> 0030: CA E8 8F 28 F7 2B 65 96 ? B2 E3 A1 AE 99 24 94 28 >>>> ??...(.+e......$.( >>>> 0040: 83 >>>> } >>>> }, >>>> ] >>>> } >>>> ] >>>> } >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 >>>> CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 417 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.719 >>>> CEST|SSLSocketOutputRecord.java:255|Raw write ( >>>> 0000: 16 03 03 01 A1 01 00 01 ? 9D 03 03 66 2E BE D3 8A >>>> ?...........f.... >>>> 0010: 77 39 06 3B 5A 34 03 7D ? EE 74 BB 08 D2 19 FD 50 >>>> ?w9.;Z4...t.....P >>>> 0020: 17 2D 84 29 AA FB E0 EE ? ED 50 69 20 0B 03 C8 E2 ?.-.).....Pi >>>> .... >>>> 0030: D2 A5 CD 3A 22 C5 85 17 ? 06 64 A9 30 14 62 C0 AF >>>> ?...:"....d.0.b.. >>>> 0040: AB 67 CE 63 50 41 50 7F ? 6B FD 4C 9F 00 5A 13 01 >>>> ?.g.cPAP.k.L..Z.. >>>> 0050: 13 02 C0 2C C0 2B C0 30 ? 00 9D C0 2E C0 32 00 9F >>>> ?...,.+.0.....2.. >>>> 0060: 00 A3 C0 2F 00 9C C0 2D ? C0 31 00 9E 00 A2 C0 24 >>>> ?.../...-.1.....$ >>>> 0070: C0 28 00 3D C0 26 C0 2A ? 00 6B 00 6A C0 0A C0 14 >>>> ?.(.=.&.*.k.j.... >>>> 0080: 00 35 C0 05 C0 0F 00 39 ? 00 38 C0 23 C0 27 00 3C >>>> ?.5.....9.8.#.'.< >>>> 0090: C0 25 C0 29 00 67 00 40 ? C0 09 C0 13 00 2F C0 04 >>>> ?.%.).g. at ...../.. >>>> 00A0: C0 0E 00 33 00 32 00 FF ? 01 00 00 FA 00 05 00 05 >>>> ?...3.2.......... >>>> 00B0: 01 00 00 00 00 00 0A 00 ? 20 00 1E 00 17 00 18 00 ?........ >>>> ....... >>>> 00C0: 19 00 09 00 0A 00 0B 00 ? 0C 00 0D 00 0E 00 16 01 >>>> ?................ >>>> 00D0: 00 01 01 01 02 01 03 01 ? 04 00 0B 00 02 01 00 00 >>>> ?................ >>>> 00E0: 0D 00 28 00 26 04 03 05 ? 03 06 03 08 04 08 05 08 >>>> ?..(.&........... >>>> 00F0: 06 08 09 08 0A 08 0B 04 ? 01 05 01 06 01 04 02 03 >>>> ?................ >>>> 0100: 03 03 01 03 02 02 03 02 ? 01 02 02 00 32 00 28 00 >>>> ?............2.(. >>>> 0110: 26 04 03 05 03 06 03 08 ? 04 08 05 08 06 08 09 08 >>>> ?&............... >>>> 0120: 0A 08 0B 04 01 05 01 06 ? 01 04 02 03 03 03 01 03 >>>> ?................ >>>> 0130: 02 02 03 02 01 02 02 00 ? 11 00 09 00 07 02 00 04 >>>> ?................ >>>> 0140: 00 00 00 00 00 17 00 00 ? 00 2B 00 09 08 03 04 03 >>>> ?.........+...... >>>> 0150: 03 03 02 03 01 00 2D 00 ? 02 01 01 00 33 00 47 00 >>>> ?......-.....3.G. >>>> 0160: 45 00 17 00 41 04 A3 9F ? B9 05 27 00 38 C4 D7 61 >>>> ?E...A.....'.8..a >>>> 0170: 6C 66 1F 4A 8D B1 02 6F ? 0B F6 E1 BD 50 93 52 86 >>>> ?lf.J...o....P.R. >>>> 0180: 2C D2 3C 8D 1A 10 A9 CD ? F0 40 F4 CD 04 25 A1 11 >>>> ?,.<...... at ...%.. >>>> 0190: E2 58 23 A3 24 CA E8 8F ? 28 F7 2B 65 96 B2 E3 A1 >>>> ?.X#.$...(.+e.... >>>> 01A0: AE 99 24 94 28 83 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?..$.(. >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: 16 03 03 00 9B ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 >>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length = 155 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.721 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: 02 00 00 97 03 03 AB 76 ? F1 BA F3 B1 F0 DD 53 AC >>>> ?.......v......S. >>>> 0010: 5B 54 E9 E4 2E F8 44 D2 ? 5E B2 59 85 0D 16 79 EE >>>> ?[T....D.^.Y...y. >>>> 0020: A7 66 8A 84 69 2A 20 0B ? 03 C8 E2 D2 A5 CD 3A 22 ?.f..i* >>>> .......:" >>>> 0030: C5 85 17 06 64 A9 30 14 ? 62 C0 AF AB 67 CE 63 50 >>>> ?....d.0.b...g.cP >>>> 0040: 41 50 7F 6B FD 4C 9F 13 ? 01 00 00 4F 00 2B 00 02 >>>> ?AP.k.L.....O.+.. >>>> 0050: 03 04 00 33 00 45 00 17 ? 00 41 04 18 4A 46 BB 73 >>>> ?...3.E...A..JF.s >>>> 0060: F4 6F 5D F0 3C 98 AD 70 ? 7E 13 D6 C0 E5 C0 28 5A >>>> ?.o].<..p......(Z >>>> 0070: D7 42 78 95 68 E0 85 B7 ? 06 CD DB 3C 35 DA AF E8 >>>> ?.Bx.h......<5... >>>> 0080: 95 D6 A2 3C 77 CF 7E 8E ? C8 94 50 BA CD 18 3F DA >>>> ?...>>> 0090: E3 A3 25 E9 F3 C9 A9 7F ? 4E B6 A9 ? ? ? ? ? ? ? ? ..%.....N.. >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.721 >>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 handshake, length = 155 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.722 >>>> CEST|ServerHello.java:866|Consuming ServerHello handshake message ( >>>> "ServerHello": { >>>> "server version" ? ? ?: "TLSv1.2", >>>> "random" ? ? ? ? ? ? ?: "AB 76 F1 BA F3 B1 F0 DD 53 AC 5B 54 E9 E4 >>>> 2E F8 44 D2 5E B2 59 85 0D 16 79 EE A7 66 8A 84 69 2A", >>>> "session id" ? ? ? ? ?: "0B 03 C8 E2 D2 A5 CD 3A 22 C5 85 17 06 64 >>>> A9 30 14 62 C0 AF AB 67 CE 63 50 41 50 7F 6B FD 4C 9F", >>>> "cipher suite" ? ? ? ?: "TLS_AES_128_GCM_SHA256(0x1301)", >>>> "compression methods" : "00", >>>> "extensions" ? ? ? ? ?: [ >>>> "supported_versions (43)": { >>>> "selected version": [TLSv1.3] >>>> }, >>>> "key_share (51)": { >>>> "server_share": { >>>> "named group": secp256r1 >>>> "key_exchange": { >>>> 0000: 04 18 4A 46 BB 73 F4 6F ? 5D F0 3C 98 AD 70 7E 13 >>>> ??..JF.s.o].<..p.. >>>> 0010: D6 C0 E5 C0 28 5A D7 42 ? 78 95 68 E0 85 B7 06 CD >>>> ??....(Z.Bx.h..... >>>> 0020: DB 3C 35 DA AF E8 95 D6 ? A2 3C 77 CF 7E 8E C8 94 >>>> ??.<5......>>> 0030: 50 BA CD 18 3F DA E3 A3 ? 25 E9 F3 C9 A9 7F 4E B6 >>>> ??P...?...%.....N. >>>> 0040: A9 >>>> } >>>> }, >>>> } >>>> ] >>>> } >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 >>>> CEST|SSLExtensions.java:167|Consumed extension: supported_versions >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 >>>> CEST|ServerHello.java:962|Negotiated protocol version: TLSv1.3 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 >>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: server_name >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 >>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: >>>> max_fragment_length >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 >>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: status_request >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 >>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: >>>> ec_point_formats >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 >>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: >>>> application_layer_protocol_negotiation >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 >>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: >>>> status_request_v2 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 >>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: >>>> extended_master_secret >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 >>>> CEST|SSLExtensions.java:167|Consumed extension: supported_versions >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 >>>> CEST|SSLExtensions.java:167|Consumed extension: key_share >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 >>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: >>>> renegotiation_info >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 >>>> CEST|PreSharedKeyExtension.java:832|Handling pre_shared_key absence. >>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.725 >>>> CEST|SSLSessionImpl.java:203|Session initialized: >>>> ??Session(1537177914725|TLS_AES_128_GCM_SHA256) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 >>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: server_name >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>> max_fragment_length >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: status_request >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>> ec_point_formats >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>> application_layer_protocol_negotiation >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>> status_request_v2 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>> extended_master_secret >>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.726 >>>> CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: >>>> supported_versions >>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.726 >>>> CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: >>>> key_share >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>> renegotiation_info >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: pre_shared_key >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.732 >>>> CEST|SSLCipher.java:1824|KeyLimit read side: algorithm = >>>> AES/GCM/NOPADDING:KEYUPDATE >>>> countdown value = 137438953472 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.735 >>>> CEST|SSLCipher.java:1978|KeyLimit write side: algorithm = >>>> AES/GCM/NOPADDING:KEYUPDATE >>>> countdown value = 137438953472 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.736 >>>> CEST|SSLSocketOutputRecord.java:225|Raw write ( >>>> 0000: 14 03 03 00 01 01 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...... >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.736 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: 14 03 03 00 01 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 >>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 change_cipher_spec, >>>> length = 1 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: 01 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? . >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 >>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 change_cipher_spec, >>>> length = 1 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 >>>> CEST|ChangeCipherSpec.java:232|Consuming ChangeCipherSpec message >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: 17 03 03 00 27 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ....' >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 >>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, >>>> length = 39 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: D5 B7 25 6F AF E9 D6 6F ? 7C 61 98 90 3F FE BA 9A >>>> ?..%o...o.a..?... >>>> 0010: A8 5B 94 5E 3A 47 38 62 ? 36 90 9A 1D BE BF 87 18 >>>> ?.[.^:G8b6....... >>>> 0020: 56 8C E3 AA CE AD AA ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? V...... >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 >>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, >>>> length = 39 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.746 >>>> CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>> 0000: 08 00 00 12 00 10 00 0A ? 00 0C 00 0A 00 1D 00 17 >>>> ?................ >>>> 0010: 00 1E 00 19 00 18 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...... >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 >>>> CEST|EncryptedExtensions.java:171|Consuming EncryptedExtensions >>>> handshake message ( >>>> "EncryptedExtensions": [ >>>> "supported_groups (10)": { >>>> "versions": [x25519, secp256r1, x448, secp521r1, secp384r1] >>>> } >>>> ] >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 >>>> CEST|SSLExtensions.java:148|Ignore unavailable extension: server_name >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 >>>> CEST|SSLExtensions.java:148|Ignore unavailable extension: >>>> max_fragment_length >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 >>>> CEST|SSLExtensions.java:167|Consumed extension: supported_groups >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 >>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: server_name >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 >>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>> max_fragment_length >>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.748 >>>> CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: >>>> supported_groups >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 >>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>> application_layer_protocol_negotiation >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: 17 03 03 00 42 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ....B >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 >>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, >>>> length = 66 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: 63 F7 54 24 11 6A 91 1F ? 1F C5 70 9A 26 AD CE 98 >>>> ?c.T$.j....p.&... >>>> 0010: D0 A9 7A 84 AF 39 7C A0 ? AD F6 6B B2 10 88 27 8B >>>> ?..z..9....k...'. >>>> 0020: 79 E0 F4 5A 9F 68 AA F0 ? 56 D3 45 72 7C 7F 22 03 >>>> ?y..Z.h..V.Er..". >>>> 0030: 0A 53 F6 24 68 CB 0B E1 ? 3B DD D4 78 B5 AC 1E D7 >>>> ?.S.$h...;..x.... >>>> 0040: 03 FB ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.. >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 >>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, >>>> length = 66 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 >>>> CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>> 0000: 0D 00 00 2D 00 00 2A 00 ? 0D 00 26 00 24 04 03 05 >>>> ?...-..*...&.$... >>>> 0010: 03 06 03 08 07 08 08 08 ? 09 08 0A 08 0B 08 04 08 >>>> ?................ >>>> 0020: 05 08 06 04 01 05 01 06 ? 01 03 03 02 03 03 01 02 >>>> ?................ >>>> 0030: 01 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? . >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 >>>> CEST|CertificateRequest.java:864|Consuming CertificateRequest >>>> handshake message ( >>>> "CertificateRequest": { >>>> "certificate_request_context": "", >>>> "extensions": [ >>>> "signature_algorithms (13)": { >>>> "signature schemes": [ecdsa_secp256r1_sha256, >>>> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, ed25519, ed448, >>>> rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, >>>> rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, >>>> rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha224, >>>> ecdsa_sha1, rsa_sha224, rsa_pkcs1_sha1] >>>> } >>>> ] >>>> } >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 >>>> CEST|SSLExtensions.java:167|Consumed extension: signature_algorithms >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 >>>> CEST|SSLExtensions.java:148|Ignore unavailable extension: >>>> signature_algorithms_cert >>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 >>>> CEST|SignatureScheme.java:390|Unsupported signature scheme: ed25519 >>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 >>>> CEST|SignatureScheme.java:390|Unsupported signature scheme: ed448 >>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 >>>> CEST|SignatureScheme.java:390|Unsupported signature scheme: ecdsa_sha224 >>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 >>>> CEST|SignatureScheme.java:390|Unsupported signature scheme: rsa_sha224 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 >>>> CEST|SSLExtensions.java:199|Populated with extension: >>>> signature_algorithms >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 >>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>> signature_algorithms_cert >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: 17 03 03 03 20 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .... >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 >>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, >>>> length = 800 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.753 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: FE BB B2 07 BA CE A6 32 ? AA 58 66 2F 6D 87 16 75 >>>> ?.......2.Xf/m..u >>>> 0010: CF 71 13 53 FB 45 AE DC ? 84 F4 AA 33 08 08 DF B5 >>>> ?.q.S.E.....3.... >>>> 0020: 97 C5 79 40 4A 28 F4 9D ? 0F 5A 86 4E C4 5F C7 2E >>>> ?..y at J(...Z.N._.. >>>> 0030: AA AA 42 F7 8A FF 6B C1 ? 28 75 9B A3 25 F0 23 81 >>>> ?..B...k.(u..%.#. >>>> 0040: 74 BB 9A EA A8 8D 89 BE ? E9 80 AE 31 C3 3A FC 35 >>>> ?t..........1.:.5 >>>> 0050: E6 CA C5 77 BF C7 0E ED ? 64 26 DB 4E C3 3D F5 AD >>>> ?...w....d&.N.=.. >>>> 0060: 5E EB A8 37 AA 81 EF 39 ? 24 84 C9 C4 C7 A2 D7 DB >>>> ?^..7...9$....... >>>> 0070: 7F 82 01 7A 02 E7 23 A3 ? 6E C9 68 B8 E5 C3 9F 53 >>>> ?...z..#.n.h....S >>>> 0080: 16 6E EF B0 54 D2 67 4C ? FF 22 E6 78 B1 A0 DB BE >>>> ?.n..T.gL.".x.... >>>> 0090: 97 23 FC C8 D8 92 86 3D ? C6 6B E4 C1 AC EF B8 46 >>>> ?.#.....=.k.....F >>>> 00A0: 75 3C 00 08 8B 34 5F 59 ? 05 49 25 97 BE A8 61 8E >>>> ?u<...4_Y.I%...a. >>>> 00B0: B0 5F 25 91 7A FE 79 53 ? 7A C1 A7 E7 70 7B A5 53 >>>> ?._%.z.ySz...p..S >>>> 00C0: 5A 63 8B 8E B9 92 2D B3 ? 80 DC AA 75 BE 0F 47 F3 >>>> ?Zc....-....u..G. >>>> 00D0: E8 D9 0D 7D D9 C3 B6 00 ? AD 2A 43 CC 66 87 88 AF >>>> ?.........*C.f... >>>> 00E0: 35 87 74 2F 87 2F 3C A6 ? FB 12 1A 9C 46 62 1C DC >>>> ?5.t/./<.....Fb.. >>>> 00F0: 4E 4E DC 16 70 7E 08 74 ? FB F7 E6 5F 4D D9 20 F9 >>>> ?NN..p..t..._M. . >>>> 0100: CA F3 91 45 D6 1A B3 BA ? FA 4E BD A4 74 9E 4C 78 >>>> ?...E.....N..t.Lx >>>> 0110: 03 18 2C 70 35 42 68 F3 ? 9A 1D 24 3F A7 27 DF 29 >>>> ?..,p5Bh...$?.'.) >>>> 0120: D5 58 7C CB 19 2F D1 DF ? 8A 6D B2 85 52 B5 78 19 >>>> ?.X.../...m..R.x. >>>> 0130: EA 5C E2 7A 23 42 9E D7 ? A3 DC D0 DE D8 33 47 2B >>>> ?.\.z#B.......3G+ >>>> 0140: 0C D8 6E 77 25 DB E6 12 ? B0 7A AD A5 C9 96 AC A9 >>>> ?..nw%....z...... >>>> 0150: 1D CD 73 39 AC 6A 9F E2 ? 0A F7 17 F1 F0 FF 75 9C >>>> ?..s9.j........u. >>>> 0160: B2 05 9E 7A F4 18 4F FC ? 9D 42 69 4C E0 3E A1 21 >>>> ?...z..O..BiL.>.! >>>> 0170: DA 1F 71 07 59 C6 A2 F9 ? 0B 4F C0 CD A4 85 A8 DB >>>> ?..q.Y....O...... >>>> 0180: 77 F6 87 5E 09 16 49 5C ? 2C B8 C0 7B 39 81 65 FD >>>> ?w..^..I\,...9.e. >>>> 0190: 29 52 E2 C7 F5 C7 AD BC ? F6 A9 F9 6D D2 E9 A4 14 >>>> ?)R.........m.... >>>> 01A0: C9 D3 79 2E D2 BA 10 4C ? BD 44 65 2B A8 7E F1 3A >>>> ?..y....L.De+...: >>>> 01B0: F3 F6 11 53 38 17 10 12 ? B4 CD C5 AD 72 3B 84 A2 >>>> ?...S8.......r;.. >>>> 01C0: 1B F9 D7 BF 34 00 5A FE ? F4 CE 09 0C EA F2 27 9A >>>> ?....4.Z.......'. >>>> 01D0: BD DD 93 37 E2 DF 60 CC ? 8A F7 C6 4B 08 30 0D 78 >>>> ?...7..`....K.0.x >>>> 01E0: 5C EB 49 34 DB 8B EB 55 ? 33 0C 82 03 07 FD 3D FC >>>> ?\.I4...U3.....=. >>>> 01F0: 49 11 88 1C F6 67 7F 0B ? 48 AA EC 1B AF 04 46 CF >>>> ?I....g..H.....F. >>>> 0200: 09 C5 8E B3 F8 92 C4 56 ? 3D 8F 0E 1D 9F D3 0C FE >>>> ?.......V=....... >>>> 0210: 94 23 15 53 8E 1F 5E C4 ? FA 44 03 3B 1B B0 0A 2D >>>> ?.#.S..^..D.;...- >>>> 0220: 71 D4 B5 AC 1F 52 D7 25 ? 9F A0 C8 4B 9B 32 B8 22 >>>> ?q....R.%...K.2." >>>> 0230: 3F AF B3 19 16 8C 2A 5C ? B4 89 BF 82 DC 4D AF 22 >>>> ??.....*\.....M." >>>> 0240: 2A 33 73 90 F3 C8 FF 2E ? C1 B3 83 D2 7A 29 4E 15 >>>> ?*3s.........z)N. >>>> 0250: 5D 87 86 F6 94 EA B0 B4 ? A4 41 B9 C5 BA 89 B8 E9 >>>> ?]........A...... >>>> 0260: 26 E7 96 BC 4D 8A FD 86 ? C7 C9 2A 96 75 C3 07 EF >>>> ?&...M.....*.u... >>>> 0270: 5C 5A 4E 91 71 7D 1B A2 ? 12 88 C5 D0 D2 5E 79 E1 >>>> ?\ZN.q........^y. >>>> 0280: 6C 65 35 5E 6C CC 56 47 ? FD F3 96 78 7A A0 08 7E >>>> ?le5^l.VG...xz... >>>> 0290: DB 3C CC 10 76 15 37 46 ? 48 6B 2D 23 7B A3 44 5A >>>> ?.<..v.7FHk-#..DZ >>>> 02A0: A4 46 B3 CE E2 15 BA 4C ? D2 93 16 57 1F BA 75 72 >>>> ?.F.....L...W..ur >>>> 02B0: BF 8C 66 50 F2 A4 F6 05 ? 84 E5 47 12 30 BE 34 70 >>>> ?..fP......G.0.4p >>>> 02C0: 4D 0F BD FE 54 E8 B1 CE ? B5 7F 6E 97 38 09 29 1F >>>> ?M...T.....n.8.). >>>> 02D0: 41 2D 2E 9E 75 D8 77 0C ? 08 DB 5C B4 EE 3F FE E2 >>>> ?A-..u.w...\..?.. >>>> 02E0: DC CF D0 ED C8 02 50 C4 ? EE B3 1D 8A 9E 9B EE 5E >>>> ?......P........^ >>>> 02F0: 14 BA C2 5A B0 83 8E 5C ? E5 7B 69 2B 69 8C F1 AA >>>> ?...Z...\..i+i... >>>> 0300: 2D D5 D1 3D 9D 42 1B B2 ? 50 5D BE 7E E4 11 D2 90 >>>> ?-..=.B..P]...... >>>> 0310: 0B 54 71 7F D6 13 88 E2 ? FE 37 9F 70 B5 0B 57 79 >>>> ?.Tq......7.p..Wy >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.753 >>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, >>>> length = 800 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.755 >>>> CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>> 0000: 0B 00 03 0B 00 00 03 07 ? 00 03 02 30 82 02 FE 30 >>>> ?...........0...0 >>>> 0010: 82 01 E6 A0 03 02 01 02 ? 02 08 20 C3 8D C4 49 66 ?.......... >>>> ...If >>>> 0020: D0 02 30 0D 06 09 2A 86 ? 48 86 F7 0D 01 01 0B 05 >>>> ?..0...*.H....... >>>> 0030: 00 30 3E 31 3C 30 3A 06 ? 03 55 04 03 0C 33 65 38 >>>> ?.0>1<0:..U...3e8 >>>> 0040: 61 63 30 32 66 61 30 64 ? 36 35 61 38 34 32 31 39 >>>> ?ac02fa0d65a84219 >>>> 0050: 30 31 36 30 34 35 64 62 ? 38 62 30 35 63 34 38 35 >>>> ?016045db8b05c485 >>>> 0060: 62 34 65 63 64 66 2E 6E ? 65 74 74 79 2E 74 65 73 >>>> ?b4ecdf.netty.tes >>>> 0070: 74 30 20 17 0D 31 33 30 ? 38 30 32 30 37 35 31 33 ?t0 >>>> ..13080207513 >>>> 0080: 36 5A 18 0F 39 39 39 39 ? 31 32 33 31 32 33 35 39 >>>> ?6Z..999912312359 >>>> 0090: 35 39 5A 30 3E 31 3C 30 ? 3A 06 03 55 04 03 0C 33 >>>> ?59Z0>1<0:..U...3 >>>> 00A0: 65 38 61 63 30 32 66 61 ? 30 64 36 35 61 38 34 32 >>>> ?e8ac02fa0d65a842 >>>> 00B0: 31 39 30 31 36 30 34 35 ? 64 62 38 62 30 35 63 34 >>>> ?19016045db8b05c4 >>>> 00C0: 38 35 62 34 65 63 64 66 ? 2E 6E 65 74 74 79 2E 74 >>>> ?85b4ecdf.netty.t >>>> 00D0: 65 73 74 30 82 01 22 30 ? 0D 06 09 2A 86 48 86 F7 >>>> ?est0.."0...*.H.. >>>> 00E0: 0D 01 01 01 05 00 03 82 ? 01 0F 00 30 82 01 0A 02 >>>> ?...........0.... >>>> 00F0: 82 01 01 00 DB F8 70 4E ? DC 2D 14 44 12 AF 0D 48 >>>> ?......pN.-.D...H >>>> 0100: 09 1D B8 48 94 1C 9E F1 ? 7F DC 6C D1 F7 94 3A B7 >>>> ?...H......l...:. >>>> 0110: 5C E3 85 07 3E CB E1 76 ? 4A 2C 32 17 4B E1 5E 42 >>>> ?\...>..vJ,2.K.^B >>>> 0120: A4 80 50 CA 36 A2 D9 94 ? F9 59 23 D0 AA 2B B2 13 >>>> ?..P.6....Y#..+.. >>>> 0130: 23 6D 45 DF 13 52 A4 4E ? 28 D3 30 99 5A 81 AD 8C >>>> ?#mE..R.N(.0.Z... >>>> 0140: DB 15 55 B7 6D 5F 44 89 ? 09 35 66 C8 2F 47 56 14 >>>> ?..U.m_D..5f./GV. >>>> 0150: B5 B2 46 AE CE 5D DC A0 ? C8 59 08 89 6F 5B DB F2 >>>> ?..F..]...Y..o[.. >>>> 0160: D8 69 E3 C1 80 44 F6 DA ? 46 ED 1D 20 80 12 3F 81 ?.i...D..F.. >>>> ..?. >>>> 0170: 95 27 F6 EB 9F B5 AC DC ? 72 01 70 46 18 67 1C 08 >>>> ?.'......r.pF.g.. >>>> 0180: AC C4 6D CA 80 48 12 87 ? 3A 05 69 EA 92 EA 95 00 >>>> ?..m..H..:.i..... >>>> 0190: 1F B9 2C BA 83 F3 B3 1B ? 37 1E B3 7C D7 46 B1 AE >>>> ?..,.....7....F.. >>>> 01A0: D4 DD E9 04 8C C0 23 00 ? 96 E3 6F 67 E7 66 65 61 >>>> ?......#...og.fea >>>> 01B0: F6 11 D2 7A FE 44 42 83 ? 9D 1A CF 20 80 EC 58 04 ?...z.DB.... >>>> ..X. >>>> 01C0: A6 10 78 41 7B 34 C3 FA ? FD 2A 08 94 72 2F 3D AE >>>> ?..xA.4...*..r/=. >>>> 01D0: B0 58 16 63 EE DA 81 42 ? 44 DB 21 C7 23 69 93 BB >>>> ?.X.c...BD.!.#i.. >>>> 01E0: 64 40 16 78 01 8A 52 57 ? 94 C0 AD 57 04 F4 C4 6B >>>> ?d at .x..RW...W...k >>>> 01F0: 90 C6 46 C7 02 03 01 00 ? 01 30 0D 06 09 2A 86 48 >>>> ?..F......0...*.H >>>> 0200: 86 F7 0D 01 01 0B 05 00 ? 03 82 01 01 00 4B FC 37 >>>> ?.............K.7 >>>> 0210: B5 E6 F2 A6 98 D8 58 2B ? 39 CE 8F 6B 51 93 80 0F >>>> ?......X+9..kQ... >>>> 0220: 80 39 BD DA 53 7D D3 1B ? 00 11 F3 A7 FE 9C B7 FA >>>> ?.9..S........... >>>> 0230: 05 23 DA A2 17 10 7C E7 ? 89 89 DE C5 90 5B 98 22 >>>> ?.#...........[." >>>> 0240: 7B 97 97 EA 2A B3 E4 6A ? 33 F8 FC 47 41 39 06 E1 >>>> ?....*..j3..GA9.. >>>> 0250: 98 63 6C 0E 2A 92 FF 3D ? B1 62 D7 27 FF 2B 2B DF >>>> ?.cl.*..=.b.'.++. >>>> 0260: B7 B2 95 87 C7 B5 21 45 ? 1E 73 F8 B5 0D D6 13 0C >>>> ?......!E.s...... >>>> 0270: 1D 25 35 6B D7 5F 18 DF ? 30 A1 8B 72 DD C6 31 B1 >>>> ?.%5k._..0..r..1. >>>> 0280: 07 2A F2 DF 1F 1E 36 23 ? 0C FF F9 FB DA E8 B5 2B >>>> ?.*....6#.......+ >>>> 0290: 3B 8B B6 4C 37 EF D3 27 ? 07 B9 1E D4 64 4B 82 D4 >>>> ?;..L7..'....dK.. >>>> 02A0: 32 78 C6 D1 61 6E 9A BF ? 41 10 23 0B 27 CD C7 77 >>>> ?2x..an..A.#.'..w >>>> 02B0: 03 73 B2 F6 12 D2 56 9C ? 29 A2 BD 31 40 F6 5F 0C >>>> ?.s....V.)..1 at ._. >>>> 02C0: 17 56 4F 30 34 95 77 87 ? 9C 43 B0 74 C5 92 05 43 >>>> ?.VO04.w..C.t...C >>>> 02D0: 97 12 48 5B 7B 58 66 89 ? 0A C1 8C CD 89 14 E0 5A >>>> ?..H[.Xf........Z >>>> 02E0: 78 23 29 10 71 6C 5D 94 ? D5 FB C0 96 51 C1 0D 93 >>>> ?x#).ql].....Q... >>>> 02F0: 64 91 45 82 5A 53 88 56 ? 5D 7A AE 88 E8 07 7D 02 >>>> ?d.E.ZS.V]z...... >>>> 0300: 7D 44 9D CA 73 E5 6F 14 ? 27 8B 6F 86 6C 00 00 ? ? .D..s.o.'.o.l.. >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 >>>> CEST|CertificateMessage.java:1148|Consuming server Certificate >>>> handshake message ( >>>> "Certificate": { >>>> "certificate_request_context": "", >>>> "certificate_list": [ >>>> { >>>> "certificate" : { >>>> "version" ? ? ? ? ? ?: "v3", >>>> "serial number" ? ? ?: "20 C3 8D C4 49 66 D0 02", >>>> "signature algorithm": "SHA256withRSA", >>>> "issuer" ? ? ? ? ? ? : >>>> "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>>> "not before" ? ? ? ? : "2013-08-02 09:51:36.000 CEST", >>>> "not ?after" ? ? ? ? : "10000-01-01 24:59:59.000 CET", >>>> "subject" ? ? ? ? ? ?: >>>> "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>>> "subject public key" : "RSA"} >>>> "extensions": { >>>> >>>> } >>>> }, >>>> ] >>>> } >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 >>>> CEST|SSLExtensions.java:148|Ignore unavailable extension: status_request >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: 17 03 03 01 19 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 >>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, >>>> length = 281 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: DE 53 C0 74 78 C3 82 0D ? E8 46 C0 0A F4 56 6E 6B >>>> ?.S.tx....F...Vnk >>>> 0010: B5 39 77 41 20 21 BA 07 ? 99 2B BF 8D 0A 41 C9 B8 ?.9wA >>>> !...+...A.. >>>> 0020: BC 0F C1 8E C5 76 36 F0 ? 7A B6 9A F8 38 4D 4D 4D >>>> ?.....v6.z...8MMM >>>> 0030: 70 33 BE 8F 8C ED BE BC ? 60 49 B8 41 65 E9 04 D9 >>>> ?p3......`I.Ae... >>>> 0040: 45 43 AA 41 6D F7 67 7B ? 03 6D FF E0 4D 76 53 CE >>>> ?EC.Am.g..m..MvS. >>>> 0050: C1 73 3E 1C CD 87 40 B7 ? 25 56 54 0C 3E CA D7 1D >>>> ?.s>... at .%VT.>... >>>> 0060: 45 80 41 E8 36 B7 FC 57 ? 38 BB 21 EB E7 EA 19 A1 >>>> ?E.A.6..W8.!..... >>>> 0070: 39 25 B0 44 8B FD 30 87 ? 86 7A 47 03 C1 02 AC FD >>>> ?9%.D..0..zG..... >>>> 0080: 67 89 4B 27 34 04 20 AE ? 91 65 7C 8C 4A 58 C5 77 ?g.K'4. >>>> ..e..JX.w >>>> 0090: 46 2E DD A8 23 CA 5C 28 ? 49 25 23 3D 8A 93 B9 10 >>>> ?F...#.\(I%#=.... >>>> 00A0: 24 0D DE DC 98 AC AA B0 ? CB 51 80 D7 F8 E7 20 23 >>>> ?$........Q.... # >>>> 00B0: 41 64 A6 44 93 A7 E1 A7 ? 91 62 4F 3A 73 F6 24 04 >>>> ?Ad.D.....bO:s.$. >>>> 00C0: C3 E8 25 65 37 D9 1B 7A ? 65 AE DE C6 29 67 2E C1 >>>> ?..%e7..ze...)g.. >>>> 00D0: F7 4C 5C 18 D7 14 98 90 ? ED 9D AD F5 98 A7 FD 93 >>>> ?.L\............. >>>> 00E0: 53 F4 B5 90 C9 CB FD 54 ? 8E 5F 53 23 E3 73 94 BD >>>> ?S......T._S#.s.. >>>> 00F0: A4 07 B7 E3 C7 83 7B 17 ? CF 51 4A 9E 9C 05 3C 51 >>>> ?.........QJ...>>> 0100: 4D C7 A1 7A D6 4D A6 58 ? E5 3A D4 12 B9 B9 46 9C >>>> ?M..z.M.X.:....F. >>>> 0110: AB 1D C5 6B F9 6A 85 CB ? E2 ? ? ? ? ? ? ? ? ? ? ? ...k.j... >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.758 >>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, >>>> length = 281 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.758 >>>> CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>> 0000: 0F 00 01 04 08 04 01 00 ? 30 11 28 CE 64 4E 08 BA >>>> ?........0.(.dN.. >>>> 0010: A1 BE 46 D9 3D 14 29 1A ? EB 5A B0 1A 09 B7 11 A5 >>>> ?..F.=.)..Z...... >>>> 0020: 9A F4 22 17 87 5F 87 D5 ? 63 04 8E 27 EC 3A F8 52 >>>> ?..".._..c..'.:.R >>>> 0030: 36 F4 2F CF 47 D2 5C CE ? 0A F0 29 EF 63 03 B1 64 >>>> ?6./.G.\...).c..d >>>> 0040: B8 45 6E 39 71 E3 BD 25 ? 95 31 25 85 4C FB C6 AD >>>> ?.En9q..%.1%.L... >>>> 0050: C8 43 96 4E FA AD B9 98 ? 17 43 61 FB 9B 87 CE 94 >>>> ?.C.N.....Ca..... >>>> 0060: CF 74 6F 3B AA 6A C8 80 ? 8F C7 C8 05 E4 EF 42 6C >>>> ?.to;.j........Bl >>>> 0070: D4 01 9E 25 5E 34 E8 2D ? 93 BD BB 05 49 2F 9D B6 >>>> ?...%^4.-....I/.. >>>> 0080: F6 91 2F D1 E5 CB 1B 9E ? F6 DB 18 32 1D F5 66 A0 >>>> ?../........2..f. >>>> 0090: 63 5D 25 01 B6 F6 1B 41 ? 07 3E 90 61 37 49 38 17 >>>> ?c]%....A.>.a7I8. >>>> 00A0: B0 15 C9 AD 0C 7A 05 8D ? B4 48 BB 03 2D DE 5E 49 >>>> ?.....z...H..-.^I >>>> 00B0: 99 8B 74 53 5F 73 9B 18 ? FD 95 2A C3 F9 A3 8B 59 >>>> ?..tS_s....*....Y >>>> 00C0: 1A ED 2C 55 C2 22 10 1E ? 7A FC 38 0A 99 FC 30 89 >>>> ?..,U."..z.8...0. >>>> 00D0: 03 89 1C CD A7 DE E5 35 ? FD E9 E0 05 96 09 AF DD >>>> ?.......5........ >>>> 00E0: 51 A3 7F C7 16 C5 96 8D ? CA CC 53 50 DC C5 C6 BA >>>> ?Q.........SP.... >>>> 00F0: D6 05 28 18 BA 99 F8 0F ? 7F 24 9F D5 6B 93 DE BC >>>> ?..(......$..k... >>>> 0100: EB 23 85 D9 D3 41 56 44 ? ? ? ? ? ? ? ? ? ? ? ? ? ?.#...AVD >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 >>>> CEST|CertificateVerify.java:1128|Consuming CertificateVerify >>>> handshake message ( >>>> "CertificateVerify": { >>>> "signature algorithm": rsa_pss_rsae_sha256 >>>> "signature": { >>>> 0000: 30 11 28 CE 64 4E 08 BA ? A1 BE 46 D9 3D 14 29 1A >>>> ??0.(.dN....F.=.). >>>> 0010: EB 5A B0 1A 09 B7 11 A5 ? 9A F4 22 17 87 5F 87 D5 >>>> ??.Z........".._.. >>>> 0020: 63 04 8E 27 EC 3A F8 52 ? 36 F4 2F CF 47 D2 5C CE >>>> ??c..'.:.R6./.G.\. >>>> 0030: 0A F0 29 EF 63 03 B1 64 ? B8 45 6E 39 71 E3 BD 25 >>>> ??..).c..d.En9q..% >>>> 0040: 95 31 25 85 4C FB C6 AD ? C8 43 96 4E FA AD B9 98 >>>> ??.1%.L....C.N.... >>>> 0050: 17 43 61 FB 9B 87 CE 94 ? CF 74 6F 3B AA 6A C8 80 >>>> ??.Ca......to;.j.. >>>> 0060: 8F C7 C8 05 E4 EF 42 6C ? D4 01 9E 25 5E 34 E8 2D >>>> ??......Bl...%^4.- >>>> 0070: 93 BD BB 05 49 2F 9D B6 ? F6 91 2F D1 E5 CB 1B 9E >>>> ??....I/..../..... >>>> 0080: F6 DB 18 32 1D F5 66 A0 ? 63 5D 25 01 B6 F6 1B 41 >>>> ??...2..f.c]%....A >>>> 0090: 07 3E 90 61 37 49 38 17 ? B0 15 C9 AD 0C 7A 05 8D >>>> ??.>.a7I8......z.. >>>> 00A0: B4 48 BB 03 2D DE 5E 49 ? 99 8B 74 53 5F 73 9B 18 >>>> ??.H..-.^I..tS_s.. >>>> 00B0: FD 95 2A C3 F9 A3 8B 59 ? 1A ED 2C 55 C2 22 10 1E >>>> ??..*....Y..,U.".. >>>> 00C0: 7A FC 38 0A 99 FC 30 89 ? 03 89 1C CD A7 DE E5 35 >>>> ??z.8...0........5 >>>> 00D0: FD E9 E0 05 96 09 AF DD ? 51 A3 7F C7 16 C5 96 8D >>>> ??........Q....... >>>> 00E0: CA CC 53 50 DC C5 C6 BA ? D6 05 28 18 BA 99 F8 0F >>>> ??..SP......(..... >>>> 00F0: 7F 24 9F D5 6B 93 DE BC ? EB 23 85 D9 D3 41 56 44 >>>> ??.$..k....#...AVD >>>> } >>>> } >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: 17 03 03 00 35 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ....5 >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 >>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, >>>> length = 53 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: F6 A7 CD EA 89 34 B2 DB ? C4 28 91 18 C9 03 98 B6 >>>> ?.....4...(...... >>>> 0010: DF 49 4E F5 2E 23 32 90 ? F8 13 C7 AE 18 E3 E5 64 >>>> ?.IN..#2........d >>>> 0020: D9 E4 A5 B0 5C F0 4A 3E ? AF EC 28 8D 09 78 AB EE >>>> ?....\.J>..(..x.. >>>> 0030: 38 1B 9E 45 04 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 8..E. >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 >>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, >>>> length = 53 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 >>>> CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>> 0000: 14 00 00 20 F2 93 6B 71 ? 2B FA F3 1B BF 68 98 D1 ?... >>>> ..kq+....h.. >>>> 0010: AA 5E B0 AF 5D 3B A6 B5 ? 8F 79 BA 64 E8 A1 34 5F >>>> ?.^..];...y.d..4_ >>>> 0020: D4 2B ED 8C ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.+.. >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.764 >>>> CEST|Finished.java:860|Consuming server Finished handshake message ( >>>> "Finished": { >>>> "verify data": { >>>> 0000: F2 93 6B 71 2B FA F3 1B ? BF 68 98 D1 AA 5E B0 AF >>>> ??..kq+....h...^.. >>>> 0010: 5D 3B A6 B5 8F 79 BA 64 ? E8 A1 34 5F D4 2B ED 8C >>>> ??];...y.d..4_.+.. >>>> }'} >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.765 >>>> CEST|SSLCipher.java:1824|KeyLimit read side: algorithm = >>>> AES/GCM/NOPADDING:KEYUPDATE >>>> countdown value = 137438953472 >>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.765 >>>> CEST|CertificateMessage.java:1015|No signature_algorithms(_cert) in >>>> ClientHello >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 >>>> CEST|CertificateMessage.java:1081|No available client authentication >>>> scheme >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 >>>> CEST|CertificateMessage.java:1116|Produced client Certificate message ( >>>> "Certificate": { >>>> "certificate_request_context": "", >>>> "certificate_list": [ >>>> ] >>>> } >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 >>>> CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 8 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 >>>> CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( >>>> 0000: 0B 00 00 04 00 00 00 00 ? 16 00 00 00 00 00 00 00 >>>> ?................ >>>> 0010: 00 00 00 00 00 00 00 00 ? 00 ? ? ? ? ? ? ? ? ? ? ? ......... >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 >>>> CEST|SSLSocketOutputRecord.java:255|Raw write ( >>>> 0000: 17 03 03 00 29 E5 32 E4 ? 5B 13 E7 D4 A1 78 FE 38 >>>> ?....).2.[....x.8 >>>> 0010: 26 22 CB C1 04 88 3A 3A ? 2D D4 A1 31 5A 78 65 50 >>>> ?&"....::-..1ZxeP >>>> 0020: 51 45 67 FA 9F 55 35 E1 ? 49 C5 3B 3B 91 B1 ? ? ? ?QEg..U5.I.;;.. >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 >>>> CEST|CertificateVerify.java:1059|No X.509 credentials negotiated for >>>> CertificateVerify >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 >>>> CEST|Finished.java:658|Produced client Finished handshake message ( >>>> "Finished": { >>>> "verify data": { >>>> 0000: D8 47 0B A0 DF BB BF 49 ? E4 55 B9 D3 FB 3D B0 DD >>>> ??.G.....I.U...=.. >>>> 0010: 57 1E 08 28 20 7E E1 0B ? E3 EB 12 10 09 76 D1 8F ?W..( >>>> ........v.. >>>> }'} >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 >>>> CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 36 >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 >>>> CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( >>>> 0000: 14 00 00 20 D8 47 0B A0 ? DF BB BF 49 E4 55 B9 D3 ?... >>>> .G.....I.U.. >>>> 0010: FB 3D B0 DD 57 1E 08 28 ? 20 7E E1 0B E3 EB 12 10 ?.=..W..( >>>> ....... >>>> 0020: 09 76 D1 8F 16 00 00 00 ? 00 00 00 00 00 00 00 00 >>>> ?.v.............. >>>> 0030: 00 00 00 00 00 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 >>>> CEST|SSLSocketOutputRecord.java:255|Raw write ( >>>> 0000: 17 03 03 00 45 0F 4D 84 ? 52 28 59 96 92 52 D1 AB >>>> ?....E.M.R(Y..R.. >>>> 0010: DB 86 64 25 31 FF 9D 8E ? D7 84 63 B5 03 E2 9E 06 >>>> ?..d%1.....c..... >>>> 0020: 3C 8C C2 22 F3 7A EE 55 ? AD 8C F5 5C F6 04 9A E2 >>>> ?<..".z.U...\.... >>>> 0030: 6D BA E4 C4 9F 97 C3 DA ? BC D3 CB 8C 2C 9E BF FD >>>> ?m...........,... >>>> 0040: A3 9F C1 A2 79 51 75 B7 ? AE B6 ? ? ? ? ? ? ? ? ? ?....yQu... >>>> ) >>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.770 >>>> CEST|SSLCipher.java:1978|KeyLimit write side: algorithm = >>>> AES/GCM/NOPADDING:KEYUPDATE >>>> countdown value = 137438953472 >>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: 17 03 03 00 13 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... >>>> ) >>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 >>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, >>>> length = 19 >>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 >>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>> 0000: 4F 0D C7 65 8B 24 B4 92 ? A2 26 31 8C 81 AF 8F F7 >>>> ?O..e.$...&1..... >>>> 0010: AC C3 B3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ... >>>> ) >>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 >>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, >>>> length = 19 >>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.773 >>>> CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>> 0000: 02 74 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.t >>>> ) >>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.774 >>>> CEST|Alert.java:232|Received alert message ( >>>> "Alert": { >>>> "level" ? ? ?: "fatal", >>>> "description": "certificate_required" >>>> } >>>> ) >>>> javax.net.ssl|ERROR|0C|Thread-0|2018-09-17 11:51:54.774 >>>> CEST|TransportContext.java:313|Fatal (CERTIFICATE_REQUIRED): >>>> Received fatal alert: certificate_required ( >>>> "throwable" : { >>>> javax.net.ssl.SSLHandshakeException: Received fatal alert: >>>> certificate_required >>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>> at >>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>>> at >>>> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >>>> at >>>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >>>> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>>> at >>>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) >>>> at >>>> java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) >>>> at >>>> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) >>>> at >>>> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) >>>> at ReproducerClient$1.run(ReproducerClient.java:33) >>>> at java.base/java.lang.Thread.run(Thread.java:834)} >>>> ) >>>> javax.net.ssl|ALL|0C|Thread-0|2018-09-17 11:51:54.775 >>>> CEST|SSLSessionImpl.java:753|Invalidated session: >>>> ??Session(1537177914725|TLS_AES_128_GCM_SHA256) >>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 >>>> CEST|SSLSocketImpl.java:1361|close the underlying socket >>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 >>>> CEST|SSLSocketImpl.java:1380|close the SSL connection (initiative) >>>> javax.net.ssl|WARNING|0C|Thread-0|2018-09-17 11:51:54.777 >>>> CEST|SSLSocketImpl.java:1289|handling exception ( >>>> "throwable" : { >>>> javax.net.ssl.SSLHandshakeException: Received fatal alert: >>>> certificate_required >>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>> at >>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>>> at >>>> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >>>> at >>>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >>>> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>>> at >>>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) >>>> at >>>> java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) >>>> at >>>> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) >>>> at >>>> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) >>>> at ReproducerClient$1.run(ReproducerClient.java:33) >>>> at java.base/java.lang.Thread.run(Thread.java:834)} >>>> ) >>>> Bye >>>> Norman >>>>> On 16. Sep 2018, at 15:54, Norman Maurer >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Will do, ?but not before tomorrow (I will also share the client >>>>> side code). That said there is nothing special about the keymanager. >>>>> Like I said before it sends the cert when using ?want client with?, >>>>> it just seems it may be too late. >>>>> >>>>> >>>>> Bye >>>>> Norman >>>>> >>>>>> Am 15.09.2018 um 08:26 schrieb Bradford Wetmore >>>>>> >>>>> >: >>>>>> >>>>>> 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)) >>>>>>>>>> 0000 - 16 03 03 01 60 ???????????????????????????????????....` >>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 >>>>>>>>>> (0x160)) >>>>>>>>>> 0000 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 >>>>>>>>>> ??...\..".... at 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..o....K...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)) >>>>>>>>>> 0000 - 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|J....n....] >>>>>>>>>> 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..o....K.. >>>>>>>>>> 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 >>>>>>>>>> ??MT....B5S[...... >>>>>>>>>> 00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65 >>>>>>>>>> ??.(.m...8.wrs%&.e >>>>>>>>>> 00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96 >>>>>>>>>> ??X........P...... >>>>>>>>>> 0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9 >>>>>>>>>> ??.;<..AX...:(..a. >>>>>>>>>> 0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5 >>>>>>>>>> ??.h...f.[..... .. >>>>>>>>>> 0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb >>>>>>>>>> ??.RD...c=........ >>>>>>>>>> 0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6 >>>>>>>>>> ??.*O[J.wx.u. .... >>>>>>>>>> 0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee >>>>>>>>>> ??...VV._.e.~n=.f. >>>>>>>>>> 0150 - 10 4c f7 6d 9b 73 86 14-7a 81 f8 b1 27 af 08 ee >>>>>>>>>> ??.L.m.s..z...'... >>>>>>>>>> 0160 - ce 26 90 34 73 3d b7 45-8d 85 29 a8 65 19 e7 02 >>>>>>>>>> ??.&.4s=.E..).e... >>>>>>>>>> 0170 - e5 55 4a 27 f1 b1 6a a4-11 cc 6c af 78 6d 22 5c >>>>>>>>>> ??.UJ'..j...l.xm"\ >>>>>>>>>> 0180 - 33 73 e3 ad 7f 8d 1b d3-75 95 66 64 2d 0e f1 3e >>>>>>>>>> ??3s......u.fd-..> >>>>>>>>>> 0190 - c2 30 df a1 7e ce a3 50-c3 4e 68 f6 36 b3 4e 45 >>>>>>>>>> ??.0..~..P.Nh.6.NE >>>>>>>>>> 01a0 - 9c ac e9 f2 0d 7c e3 73-6a 40 ab 6e 6e f9 d8 20 >>>>>>>>>> ??.....|.sj at .nn.. >>>>>>>>>> 01b0 - 9c f3 04 32 cd 1d df 18-e5 4d e3 e8 b1 38 59 f8 >>>>>>>>>> ??...2.....M...8Y. >>>>>>>>>> 01c0 - 28 67 2e ca af a2 8b 88-ce ca 48 a6 07 2b a6 9a >>>>>>>>>> ??(g........H..+.. >>>>>>>>>> 01d0 - 0e 88 5b d7 0b d9 31 77-97 8d 6c 2b f5 60 24 61 >>>>>>>>>> ??..[...1w..l+.`$a >>>>>>>>>> 01e0 - a8 5c 47 5d 7c 66 f0 9b-1f e4 76 93 38 f6 78 3e >>>>>>>>>> ??.\G]|f....v.8.x> >>>>>>>>>> 01f0 - 69 29 72 f9 d9 4b cb 05-03 e4 f2 d6 24 e1 91 ee >>>>>>>>>> ??i)r..K......$... >>>>>>>>>> 0200 - 85 37 d7 7b c3 5c 35 90-08 cd b1 cc 76 11 fc 00 >>>>>>>>>> ??.7.{.\5.....v... >>>>>>>>>> 0210 - 12 7e 89 7b 70 e6 ca fe-0b 26 b6 bb ac fe 4b 9f >>>>>>>>>> ??.~.{p....&....K. >>>>>>>>>> 0220 - ec cf 41 69 42 3a 3e 41-f9 b0 c0 93 5b 70 1f c7 >>>>>>>>>> ??..AiB:>A....[p.. >>>>>>>>>> 0230 - 11 00 3d ec 66 5a 1a ca-31 89 22 27 02 dd a0 cb >>>>>>>>>> ??..=.fZ..1."'.... >>>>>>>>>> 0240 - 39 14 25 ee 30 44 e8 62-97 bf 8e 16 63 40 c4 11 >>>>>>>>>> ??9.%.0D.b....c at .. >>>>>>>>>> 0250 - a6 d9 32 b1 3c 86 35 bb-9f f1 4d 71 9f a5 4f 78 >>>>>>>>>> ??..2.<.5...Mq..Ox >>>>>>>>>> 0260 - 0a e8 96 dd 4d 10 c3 48-f2 db 67 57 2d cd dc 23 >>>>>>>>>> ??....M..H..gW-..# >>>>>>>>>> 0270 - 3a 8d 6a 61 47 20 ff c8-33 cd e9 f7 47 4c 68 4f ??:.jaG >>>>>>>>>> ..3...GLhO >>>>>>>>>> 0280 - 19 2f 8b e3 b1 90 ac 66-a7 cf 5c e6 d2 05 21 25 >>>>>>>>>> ??./.....f..\...!% >>>>>>>>>> 0290 - d2 d8 f0 43 8c 55 01 ef-d6 8f c0 27 87 0d 21 d5 >>>>>>>>>> ??...C.U.....'..!. >>>>>>>>>> 02a0 - 2b 2b 6f db e8 85 ea cd-6e 9c 5d 56 d5 31 c1 f2 >>>>>>>>>> ??++o.....n.]V.1.. >>>>>>>>>> 02b0 - 97 2f 5a 83 7a 2b 71 03-65 e0 b6 4a 56 37 de e1 >>>>>>>>>> ??./Z.z+q.e..JV7.. >>>>>>>>>> 02c0 - 80 3a c4 cc 5a ac 3b 9a-7a bf f7 6b fe a8 69 e9 >>>>>>>>>> ??.:..Z.;.z..k..i. >>>>>>>>>> 02d0 - 58 09 59 bd 46 bd d2 a3-bc ad 1c 10 53 c8 29 7b >>>>>>>>>> ??X.Y.F.......S.){ >>>>>>>>>> 02e0 - be 63 00 d6 e5 a8 d6 ab-b2 bc 8b e1 2c 0e 24 2a >>>>>>>>>> ??.c..........,.$* >>>>>>>>>> 02f0 - c2 31 2d d8 6e 1f 19 93-d7 54 e1 1e 28 ce 72 83 >>>>>>>>>> ??.1-.n....T..(.r. >>>>>>>>>> 0300 - ff 05 18 f2 fc e9 0c b3-0c 1b d5 96 c2 d8 fc 76 >>>>>>>>>> ??...............v >>>>>>>>>> 0310 - 37 a9 5a ef 8e e9 b6 71-21 f3 bd c1 85 23 85 22 >>>>>>>>>> ??7.Z....q!....#." >>>>>>>>>> 0320 - 3d c4 1c c9 31 8b 7e 00-8f 8e b4 9f 05 d4 80 6b >>>>>>>>>> ??=...1.~........k >>>>>>>>>> 0330 - 98 4c a8 82 68 ff 1a a5-28 e2 9b 03 a1 a7 b1 00 >>>>>>>>>> ??.L..h...(....... >>>>>>>>>> 0340 - 02 2b 2d e2 e1 87 8c e8-0a fb 0b 79 54 ca 3d d5 >>>>>>>>>> ??.+-........yT.=. >>>>>>>>>> 0350 - 6a dd b7 b7 87 42 2b 47-49 da e9 0a 82 0a c9 8f >>>>>>>>>> ??j....B+GI....... >>>>>>>>>> 0360 - 57 f7 1e 03 ca 8d 16 bc-21 3a 6a ee b9 b8 fa f0 >>>>>>>>>> ??W.......!:j..... >>>>>>>>>> 0370 - d9 18 35 9f 35 ac d8 6e-9a 8a 0d 56 10 1e 1f 5a >>>>>>>>>> ??..5.5..n...V...Z >>>>>>>>>> 0380 - ba ec e4 fe 1a 92 b4 31-35 43 1d 99 b9 12 fa ff >>>>>>>>>> ??.......15C...... >>>>>>>>>> 0390 - 99 2b 88 e0 58 ec 9c dc-8f 67 ef 2a c2 e2 64 5d >>>>>>>>>> ??.+..X....g.*..d] >>>>>>>>>> 03a0 - 66 76 1c d0 aa 00 30 59-b1 f5 b1 55 9f ad 60 e9 >>>>>>>>>> ??fv....0Y...U..`. >>>>>>>>>> 03b0 - 3d 03 1e d0 8b 4d bf 74-ac bc bb 1c 83 14 c5 e0 >>>>>>>>>> ??=....M.t........ >>>>>>>>>> 03c0 - f4 fc 70 9e f4 22 a0 78-04 fe c8 b1 17 65 f6 94 >>>>>>>>>> ??..p..".x.....e.. >>>>>>>>>> 03d0 - 47 82 50 4a b6 32 74 ae-5b 38 5a 2e d9 b0 6a 45 >>>>>>>>>> ??G.PJ.2t.[8Z...jE >>>>>>>>>> 03e0 - 74 e8 f0 22 fe d3 b0 11-c3 fd 72 4f da 77 7a ba >>>>>>>>>> ??t.."......rO.wz. >>>>>>>>>> 03f0 - 26 3e 61 0c 63 21 17 a6-b2 13 6e 71 5c f2 0d ad >>>>>>>>>> ??&>a.c!....nq\... >>>>>>>>>> 0400 - f2 d1 19 71 51 9e a4 1b-b0 30 24 e0 71 7d 87 80 >>>>>>>>>> ??...qQ....0$.q}.. >>>>>>>>>> 0410 - a9 5a e9 bc db e4 4f 50-4d a1 bc bc 2c 4b 66 98 >>>>>>>>>> ??.Z....OPM...,Kf. >>>>>>>>>> 0420 - d4 e4 b0 76 0f d2 db a5-a5 39 9e f2 5b ea 34 c1 >>>>>>>>>> ??...v.....9..[.4. >>>>>>>>>> 0430 - 62 ab 47 51 3b 37 17 45-54 31 18 f3 f1 ca 17 03 >>>>>>>>>> ??b.GQ;7.ET1...... >>>>>>>>>> 0440 - 03 01 19 dd 50 50 f5 0c-f2 c9 3c b4 8f 63 cc 4a >>>>>>>>>> ??....PP....<..c.J >>>>>>>>>> 0450 - a7 50 c9 91 9b 79 9a 2a-5c 47 d3 77 f6 56 69 90 >>>>>>>>>> ??.P...y.*\G.w.Vi. >>>>>>>>>> 0460 - 98 cd ff bd c1 2a 49 fc-0d d4 7e cc 7e 44 af c4 >>>>>>>>>> ??.....*I...~.~D.. >>>>>>>>>> 0470 - 61 47 e0 c1 76 b1 8c 2e-df 7e d0 82 e1 89 1f 04 >>>>>>>>>> ??aG..v....~...... >>>>>>>>>> 0480 - ae 64 bd 71 4d ae 1c 3c-e3 d3 39 5d 61 2a ea 70 >>>>>>>>>> ??.d.qM..<..9]a*.p >>>>>>>>>> 0490 - 8c 31 6d a0 b1 72 a8 7a-5c 9c 11 08 b8 4d a5 c4 >>>>>>>>>> ??.1m..r.z\....M.. >>>>>>>>>> 04a0 - ad 1b 38 4a 6a 02 28 d4-d1 0f c8 9f 0b b3 02 18 >>>>>>>>>> ??..8Jj.(......... >>>>>>>>>> 04b0 - 82 2b bd 46 82 04 64 f0-41 b2 da f5 cd 9c f7 f3 >>>>>>>>>> ??.+.F..d.A....... >>>>>>>>>> 04c0 - 73 30 58 ca 12 ec ea 90-85 1c 75 09 0a 70 b8 80 >>>>>>>>>> ??s0X.......u..p.. >>>>>>>>>> 04d0 - 3d 02 17 3e 9b 83 04 b5-dd 9e e6 18 17 65 83 a5 >>>>>>>>>> ??=..>.........e.. >>>>>>>>>> 04e0 - 59 7d 4b 98 da bd 8b aa-d6 aa c5 1c 7d 87 56 e3 >>>>>>>>>> ??Y}K.........}.V. >>>>>>>>>> 04f0 - 74 d8 e9 7b eb b3 3d f7-7c 3c 0a e9 a8 2e 04 0d >>>>>>>>>> ??t..{..=.|<...... >>>>>>>>>> 0500 - 6a e7 83 e0 ec 99 43 6a-8b 1c 73 59 7a c8 cd 6e >>>>>>>>>> ??j.....Cj..sYz..n >>>>>>>>>> 0510 - 4a 14 73 ff 9a fb 71 94-d5 50 a9 d9 e0 dd 02 4c >>>>>>>>>> ??J.s...q..P.....L >>>>>>>>>> 0520 - 2b 67 9e da 9e fa 2d 67-49 df 13 10 ed 35 3e 73 >>>>>>>>>> ??+g....-gI....5>s >>>>>>>>>> 0530 - 07 20 17 fb 0b ef f6 d0-b7 68 1c 65 21 a6 e3 3b ??. >>>>>>>>>> .......h.e!..; >>>>>>>>>> 0540 - bf 7b 84 cd 9e f5 76 2a-0d 4f b8 c3 c8 15 08 e9 >>>>>>>>>> ??.{....v*.O...... >>>>>>>>>> 0550 - 0f 3c 50 49 12 97 a8 d7-f1 a3 16 da 17 03 03 00 >>>>>>>>>> ??.>>>>>>>>> 0560 - 35 22 dd a2 9d 25 98 2c-35 b8 00 29 fa a1 dd ba >>>>>>>>>> ??5"...%.,5..).... >>>>>>>>>> 0570 - 72 b9 fe e5 85 85 f0 f1-3b 4e f5 7c 58 c8 2a da >>>>>>>>>> ??r.......;N.|X.*. >>>>>>>>>> 0580 - d2 75 94 3b c1 7a 7c 7e-db 5b fe 8a 2d 3f 8c 9a >>>>>>>>>> ??.u.;.z|~.[..-?.. >>>>>>>>>> 0590 - 6e 79 ab 2b ff 1a ????????????????????????????????ny.+.. >>>>>>>>>> SSL_accept:SSLv3/TLS write finished >>>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>>>>>> 0000 - 14 03 03 00 01 ???????????????????????????????????..... >>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (1 bytes => 1 (0x1)) >>>>>>>>>> 0000 - 01 ???????????????????????????????????????????????. >>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>>>>>> 0000 - 17 03 03 00 3d ???????????????????????????????????....= >>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (61 bytes => 61 (0x3D)) >>>>>>>>>> 0000 - 38 e7 bb 2c 5b af b6 5f-37 d8 3e 7e bb f4 04 f5 >>>>>>>>>> ??8..,[.._7.>~.... >>>>>>>>>> 0010 - e1 28 b5 e5 07 5a ec ce-da 2f f3 b6 45 61 cf ef >>>>>>>>>> ??.(...Z.../..Ea.. >>>>>>>>>> 0020 - 90 fb 57 b8 f3 20 45 27-60 d4 26 51 38 77 e4 bc ??..W.. >>>>>>>>>> E'`.&Q8w.. >>>>>>>>>> 0030 - b7 64 d4 8b 73 25 41 9e-fe d3 9d 5f 53 >>>>>>>>>> ???????????.d..s%A...._S >>>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>>> write to 0x7fe400f050c0 [0x7fe403018a00] (24 bytes => 24 (0x18)) >>>>>>>>>> 0000 - 17 03 03 00 13 25 85 60-eb 7d c1 a8 15 49 d5 63 >>>>>>>>>> ??.....%.`.}...I.c >>>>>>>>>> 0010 - 18 7f c6 ac ed 7f df 77- ?????????????????????????.......w >>>>>>>>>> SSL3 alert write:fatal:unknown >>>>>>>>>> SSL_accept:error in error >>>>>>>>>> ERROR >>>>>>>>>> 140736092021632:error:1417C0C7:SSL >>>>>>>>>> routines:tls_process_client_certificate:peer did not return a >>>>>>>>>> certificate:ssl/statem/statem_srvr.c:3654: >>>>>>>>>> shutting down SSL >>>>>>>>>> CONNECTION CLOSED >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> When using openssl s_client all works as expected tho (thats >>>>>>>>>> also true if I use my native implementation on the client and >>>>>>>>>> server side that uses openssl): >>>>>>>>>> >>>>>>>>>> ./bin/openssl s_client -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 >>>>>>>>>> ?-state -tls1_3 -connect localhost:8443 >>>>>>>>>> >>>>>>>>>> The interesting thing is if I use ?-verify 1? and not ?-Verify >>>>>>>>>> 1? with openssl which tells it I want to request a certificate >>>>>>>>>> but will also process if none is provided I receive the >>>>>>>>>> certificate at some point as seen here: >>>>>>>>>> >>>>>>>>>> SSL_accept:before SSL initialization >>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>> 0000 - 16 03 03 01 60 ???????????????????????????????????....` >>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (352 bytes => 352 >>>>>>>>>> (0x160)) >>>>>>>>>> 0000 - 01 00 01 5c 03 03 61 c0-b3 ed 88 65 e6 cf 11 3f >>>>>>>>>> ??...\..a....e...? >>>>>>>>>> 0010 - c0 e0 f8 df a6 63 32 c2-ab 3d 61 6f 41 ed b1 4b >>>>>>>>>> ??.....c2..=aoA..K >>>>>>>>>> 0020 - 53 0e 83 e5 a1 b8 20 c7-1b 8c b8 e6 b5 da 4e 4e >>>>>>>>>> ??S..... .......NN >>>>>>>>>> 0030 - 3f 3c 61 7a ad 58 23 94-a7 32 79 2f db 9f 21 c0 >>>>>>>>>> ???>>>>>>>>> 0040 - 8e 0c c5 ce b1 c2 a4 00-14 c0 2c c0 2b c0 2f c0 >>>>>>>>>> ??..........,.+./. >>>>>>>>>> 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 52 dc d6 47 6e >>>>>>>>>> ??.3.G.E...A.R..Gn >>>>>>>>>> 0120 - a1 de 9c 71 c2 54 0e 5c-9b 57 fb c8 aa 3f 19 f7 >>>>>>>>>> ??...q.T.\.W...?.. >>>>>>>>>> 0130 - d3 a4 25 12 fa 3f 6c 6d-95 30 66 ca 63 b7 a1 dd >>>>>>>>>> ??..%..?lm.0f.c... >>>>>>>>>> 0140 - ae 9f 99 d6 a8 6b 20 4f-29 7a 74 58 ad 58 de 12 >>>>>>>>>> ??.....k O)ztX.X.. >>>>>>>>>> 0150 - d7 a5 9b 69 dc 27 ac ec-9e d4 04 ff 01 00 01 00 >>>>>>>>>> ??...i.'.......... >>>>>>>>>> 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 0x7fdc58809fb0 [0x7fdc59025e00] (1430 bytes => 1430 >>>>>>>>>> (0x596)) >>>>>>>>>> 0000 - 16 03 03 00 9b 02 00 00-97 03 03 8b c8 62 48 6c >>>>>>>>>> ??.............bHl >>>>>>>>>> 0010 - f5 7c 73 d9 17 f8 63 a2-11 27 40 93 09 26 53 06 >>>>>>>>>> ??.|s...c..'@..&S. >>>>>>>>>> 0020 - b3 62 df 46 26 b6 dc 59-29 b5 58 20 c7 1b 8c b8 >>>>>>>>>> ??.b.F&..Y).X .... >>>>>>>>>> 0030 - e6 b5 da 4e 4e 3f 3c 61-7a ad 58 23 94 a7 32 79 >>>>>>>>>> ??...NN?>>>>>>>>> 0040 - 2f db 9f 21 c0 8e 0c c5-ce b1 c2 a4 13 01 00 00 >>>>>>>>>> ??/..!............ >>>>>>>>>> 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 >>>>>>>>>> ??O.+.....3.E...A. >>>>>>>>>> 0060 - 07 63 1c 19 53 89 68 a8-0f ea 9e 4c 18 6f 2a ad >>>>>>>>>> ??.c..S.h....L.o*. >>>>>>>>>> 0070 - 2a df eb 17 a2 08 94 c6-e3 c5 97 ae 0f c1 1a d7 >>>>>>>>>> ??*............... >>>>>>>>>> 0080 - 0d d7 2e 6d 77 3d 30 a0-07 db 70 35 bb 37 dd 1e >>>>>>>>>> ??...mw=0...p5.7.. >>>>>>>>>> 0090 - b6 f3 4d cb 13 97 7c 11-63 98 e8 64 2d a7 e6 cc >>>>>>>>>> ??..M...|.c..d-... >>>>>>>>>> 00a0 - 14 03 03 00 01 01 17 03-03 00 27 a3 73 d2 ee 2c >>>>>>>>>> ??..........'.s.., >>>>>>>>>> 00b0 - 2f 9c 8f 95 7f ca a3 89-bc b4 b3 b2 3c 8b 23 ef >>>>>>>>>> ??/...........<.#. >>>>>>>>>> 00c0 - 36 66 23 c9 09 02 33 0d-dc 5d 36 61 44 89 8b ef >>>>>>>>>> ??6f#...3..]6aD... >>>>>>>>>> 00d0 - fd 13 17 03 03 00 42 f2-5b 3c 0c 27 5e 7f 97 4f >>>>>>>>>> ??......B.[<.'^..O >>>>>>>>>> 00e0 - 0f de 8c b9 0a a1 41 c7-c2 1e 92 99 6a d5 bd 12 >>>>>>>>>> ??......A.....j... >>>>>>>>>> 00f0 - 38 b6 b7 93 33 e9 8e 0f-44 93 f0 69 58 b6 41 22 >>>>>>>>>> ??8...3...D..iX.A" >>>>>>>>>> 0100 - 46 e2 4a d5 d6 32 2b b8-a7 ae 3a c2 c5 2f e6 35 >>>>>>>>>> ??F.J..2+...:../.5 >>>>>>>>>> 0110 - 11 0c f1 9a 35 2a 87 ed-9e 17 03 03 03 20 a7 e2 >>>>>>>>>> ??....5*....... .. >>>>>>>>>> 0120 - fe ba c7 10 5b 9c cd 94-67 19 37 2d 46 59 ab 56 >>>>>>>>>> ??....[...g.7-FY.V >>>>>>>>>> 0130 - 6b dd a4 10 61 cc ed f1-71 a7 2d 6a 41 2e 2b da >>>>>>>>>> ??k...a...q.-jA.+. >>>>>>>>>> 0140 - d1 35 fc 01 df 49 e5 90-1d 9b b2 03 0a 81 58 18 >>>>>>>>>> ??.5...I........X. >>>>>>>>>> 0150 - 96 a1 db 31 19 98 35 5c-87 8f 6e 32 0a e6 c0 aa >>>>>>>>>> ??...1..5\..n2.... >>>>>>>>>> 0160 - 9e 8e 72 e2 34 b3 b7 a3-d6 d1 66 c7 ce 93 fe 78 >>>>>>>>>> ??..r.4.....f....x >>>>>>>>>> 0170 - 17 c4 71 7c 42 15 c8 af-dc 4f 50 42 51 80 fc bf >>>>>>>>>> ??..q|B....OPBQ... >>>>>>>>>> 0180 - fc 54 d5 d8 59 20 9a 90-c4 78 97 9c 2d 4a d5 58 ??.T..Y >>>>>>>>>> ...x..-J.X >>>>>>>>>> 0190 - be 81 79 23 59 22 9d 27-f8 bd a0 b2 98 b3 47 82 >>>>>>>>>> ??..y#Y".'......G. >>>>>>>>>> 01a0 - d3 52 b5 b5 91 ab 5c 76-52 c5 a5 95 2d 03 1c b7 >>>>>>>>>> ??.R....\vR...-... >>>>>>>>>> 01b0 - 64 4d 0b 88 7f 15 0b c8-a8 90 50 9a b6 b1 9f b7 >>>>>>>>>> ??dM........P..... >>>>>>>>>> 01c0 - 40 09 f2 5f 39 f8 9a 06-21 4d 67 10 0a 67 08 b6 >>>>>>>>>> ??@.._9...!Mg..g.. >>>>>>>>>> 01d0 - b5 9a 25 8c d5 ca 31 6a-8a 6b 01 93 7d 6f 1e 52 >>>>>>>>>> ??..%...1j.k..}o.R >>>>>>>>>> 01e0 - 98 96 9d fb e8 c1 07 ab-57 98 2d 1e 75 77 ef c2 >>>>>>>>>> ??........W.-.uw.. >>>>>>>>>> 01f0 - 49 78 e0 b9 2b 32 23 7e-95 4d 3e 27 00 61 86 0c >>>>>>>>>> ??Ix..+2#~.M>'.a.. >>>>>>>>>> 0200 - 47 c7 79 e4 ee 9d ba c0-ea 62 f1 0d 8e 4a 91 30 >>>>>>>>>> ??G.y......b...J.0 >>>>>>>>>> 0210 - bc 4f 5a 98 26 30 66 ec-c4 63 8f 28 d5 1c 61 23 >>>>>>>>>> ??.OZ.&0f..c.(..a# >>>>>>>>>> 0220 - ea e9 90 4e 36 d9 fa 31-7b 14 27 22 0a ae 9f 64 >>>>>>>>>> ??...N6..1{.'"...d >>>>>>>>>> 0230 - 40 3d e5 a0 5c 9d 3c 04-71 09 b0 7a 6b 51 a0 9c >>>>>>>>>> ??@=..\.<.q..zkQ.. >>>>>>>>>> 0240 - c0 61 32 ce 15 62 8e 29-b1 59 91 c0 17 2c b3 c5 >>>>>>>>>> ??.a2..b.).Y...,.. >>>>>>>>>> 0250 - f9 ed 07 65 3d 11 de 98-de 62 36 50 74 37 af 2d >>>>>>>>>> ??...e=....b6Pt7.- >>>>>>>>>> 0260 - 7d 86 55 c4 3e a2 83 ab-47 8d f2 b2 8d 1d 75 83 >>>>>>>>>> ??}.U.>...G.....u. >>>>>>>>>> 0270 - b5 e4 41 87 a7 a3 85 b0-5e 4e 2e 9c 8c b0 1b 83 >>>>>>>>>> ??..A.....^N...... >>>>>>>>>> 0280 - 7b 54 79 c9 60 ea 7d ed-06 fa dd 24 40 f1 53 9e >>>>>>>>>> ??{Ty.`.}....$@.S. >>>>>>>>>> 0290 - 43 79 25 53 9c c7 6e 95-ab 9f 96 59 cd b9 7b a8 >>>>>>>>>> ??Cy%S..n....Y..{. >>>>>>>>>> 02a0 - a0 23 13 69 db a9 c9 e7-1a 8e e1 9b 54 94 1c 44 >>>>>>>>>> ??.#.i........T..D >>>>>>>>>> 02b0 - 50 08 8b dd eb 4e 2b bb-d7 c9 c2 33 8c a1 b3 65 >>>>>>>>>> ??P....N+....3...e >>>>>>>>>> 02c0 - 06 e6 9d ac 11 16 21 58-40 8d 59 e6 67 e5 31 02 >>>>>>>>>> ??......!X at .Y.g.1. >>>>>>>>>> 02d0 - 15 8d 29 80 20 66 ba c3-56 93 95 5c 65 4b 41 00 ??..). >>>>>>>>>> f..V..\eKA. >>>>>>>>>> 02e0 - c5 71 12 12 f5 20 4f 59-be 77 06 10 6e 48 85 5c ??.q... >>>>>>>>>> OY.w..nH.\ >>>>>>>>>> 02f0 - ff a2 c4 ae fb 4d 95 f5-cc f6 61 20 33 b7 92 1d >>>>>>>>>> ??.....M....a 3... >>>>>>>>>> 0300 - ac a8 f1 b2 b0 88 c6 7b-8b 00 53 30 6d 4a d1 42 >>>>>>>>>> ??.......{..S0mJ.B >>>>>>>>>> 0310 - b3 3e 85 f5 84 e1 c6 ab-10 9d 61 03 46 ff 2d 81 >>>>>>>>>> ??.>........a.F.-. >>>>>>>>>> 0320 - 15 4f 84 d1 4c ee f4 a6-a0 ec 50 60 a0 d1 ff df >>>>>>>>>> ??.O..L.....P`.... >>>>>>>>>> 0330 - 8a 97 f6 7d fb 8f fb 60-18 d4 f1 1f 92 4d d8 69 >>>>>>>>>> ??...}...`.....M.i >>>>>>>>>> 0340 - b1 92 97 44 0f 3c 8a aa-47 07 48 d4 07 2d 3e f2 >>>>>>>>>> ??...D.<..G.H..->. >>>>>>>>>> 0350 - c4 a7 16 35 a7 17 71 ef-98 84 24 67 12 58 30 3b >>>>>>>>>> ??...5..q...$g.X0; >>>>>>>>>> 0360 - 1d 41 8d e5 12 52 95 64-e5 88 35 99 d7 c3 58 40 >>>>>>>>>> ??.A...R.d..5...X@ >>>>>>>>>> 0370 - f9 55 9b 9f e5 33 15 70-41 d7 45 ba a4 fc 75 ea >>>>>>>>>> ??.U...3.pA.E...u. >>>>>>>>>> 0380 - a4 ae f0 68 ea 64 d8 f5-06 68 a9 75 22 4d 43 cc >>>>>>>>>> ??...h.d...h.u"MC. >>>>>>>>>> 0390 - ff 50 cc ac 6e fd 43 dd-eb e4 c8 dd 4b 6c 12 bb >>>>>>>>>> ??.P..n.C.....Kl.. >>>>>>>>>> 03a0 - f1 d4 5e 11 4a 86 90 0b-f8 3a 2e 23 db 61 5a 1f >>>>>>>>>> ??..^.J....:.#.aZ. >>>>>>>>>> 03b0 - 7e 11 00 92 21 68 1f b5-ab f2 f8 38 5e 62 ea f8 >>>>>>>>>> ??~...!h.....8^b.. >>>>>>>>>> 03c0 - da ef c2 6e a0 b8 20 e4-69 49 b3 1f 15 84 0b 9b >>>>>>>>>> ??...n.. .iI...... >>>>>>>>>> 03d0 - ce b0 6f 36 32 7f 7e bf-e8 d7 18 7a 58 60 f4 04 >>>>>>>>>> ??..o62.~....zX`.. >>>>>>>>>> 03e0 - cc 36 bf 06 cd ec e5 9b-19 03 96 09 fb af 8f c3 >>>>>>>>>> ??.6.............. >>>>>>>>>> 03f0 - 98 b4 02 aa e8 55 81 aa-c4 fe 06 81 30 a0 c7 b2 >>>>>>>>>> ??.....U......0... >>>>>>>>>> 0400 - f8 e2 30 00 d7 a0 54 7f-5f d7 ef a6 f8 41 58 34 >>>>>>>>>> ??..0...T._....AX4 >>>>>>>>>> 0410 - f5 f0 18 69 8d e6 7a 23-78 90 8f b1 05 c5 b5 7f >>>>>>>>>> ??...i..z#x....... >>>>>>>>>> 0420 - e0 f2 c7 fa c8 36 5b 53-7e cf e6 75 d3 54 b4 69 >>>>>>>>>> ??.....6[S~..u.T.i >>>>>>>>>> 0430 - 68 43 0d 6a d2 83 cc 13-6d ca bf 83 3c 90 17 03 >>>>>>>>>> ??hC.j....m...<... >>>>>>>>>> 0440 - 03 01 19 96 dc 49 26 ce-1d 8e 86 3d bd cb 00 5e >>>>>>>>>> ??.....I&....=...^ >>>>>>>>>> 0450 - ee f6 e7 1d 16 7a ca ef-fa 6d 16 40 b6 99 d0 c1 >>>>>>>>>> ??.....z...m. at .... >>>>>>>>>> 0460 - df 0b 5f 51 60 a8 24 e0-61 82 13 40 da 88 38 3a >>>>>>>>>> ??.._Q`.$.a.. at ..8: >>>>>>>>>> 0470 - 26 1d 80 51 c4 b1 95 35-95 3c 91 35 28 17 49 d8 >>>>>>>>>> ??&..Q...5.<.5(.I. >>>>>>>>>> 0480 - c3 45 be 32 98 3e 02 07-3b 01 20 2b 51 e1 1a 94 >>>>>>>>>> ??.E.2.>..;. +Q... >>>>>>>>>> 0490 - b9 be 96 aa 7a 13 09 ff-d5 a9 63 d4 6f 49 cb b5 >>>>>>>>>> ??....z.....c.oI.. >>>>>>>>>> 04a0 - 23 ab 7f 8c e2 63 f0 5c-5c 27 1e 04 a8 71 0c c0 >>>>>>>>>> ??#....c.\\'...q.. >>>>>>>>>> 04b0 - 89 cd ed 18 8d 5b 75 ac-af f3 68 6d cc ba 20 38 >>>>>>>>>> ??.....[u...hm.. 8 >>>>>>>>>> 04c0 - b5 7c 09 47 29 28 e2 26-57 57 1f f0 f3 18 fd 6f >>>>>>>>>> ??.|.G)(.&WW.....o >>>>>>>>>> 04d0 - 27 42 a4 e3 de bb e5 d6-09 7d 25 b1 98 97 ad 33 >>>>>>>>>> ??'B.......}%....3 >>>>>>>>>> 04e0 - 68 35 92 07 80 23 f1 66-20 5d 74 f3 02 c5 51 ff >>>>>>>>>> ??h5...#.f ]t...Q. >>>>>>>>>> 04f0 - 07 a9 e9 0e 3e 74 da 2e-8f 3b 16 be e6 94 1b 66 >>>>>>>>>> ??....>t...;.....f >>>>>>>>>> 0500 - bb b2 a2 1e 7c 7b ff 5e-a4 36 2a ba 0b cd 7f e9 >>>>>>>>>> ??....|{.^.6*..... >>>>>>>>>> 0510 - 86 bb 5e 30 f5 57 92 52-82 b6 2e da 71 b7 22 c2 >>>>>>>>>> ??..^0.W.R....q.". >>>>>>>>>> 0520 - 90 c4 69 46 07 df 6c 3f-05 8b 19 3e ce b9 75 0d >>>>>>>>>> ??..iF..l?...>..u. >>>>>>>>>> 0530 - 4b 97 37 ae 94 e2 d6 3c-91 e6 82 c7 a1 78 79 2c >>>>>>>>>> ??K.7....<.....xy, >>>>>>>>>> 0540 - 9a a3 d5 45 94 ad e2 c8-ab fd 81 ec 62 87 f7 75 >>>>>>>>>> ??...E........b..u >>>>>>>>>> 0550 - e3 70 79 8e 82 3b c5 45-0d d0 33 5f 17 03 03 00 >>>>>>>>>> ??.py..;.E..3_.... >>>>>>>>>> 0560 - 35 da e0 74 2a 06 41 5a-64 1e 54 94 29 73 43 3f >>>>>>>>>> ??5..t*.AZd.T.)sC? >>>>>>>>>> 0570 - e5 24 a8 ba b2 7e 6b 26-82 fc d9 f6 dd 19 05 4a >>>>>>>>>> ??.$...~k&.......J >>>>>>>>>> 0580 - 2c 1a f3 bb 16 1d 38 95-a6 d3 a8 58 f6 a3 41 c7 >>>>>>>>>> ??,.....8....X..A. >>>>>>>>>> 0590 - 92 44 35 24 25 0e ????????????????????????????????.D5$%. >>>>>>>>>> SSL_accept:SSLv3/TLS write finished >>>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>> 0000 - 14 03 03 00 01 ???????????????????????????????????..... >>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (1 bytes => 1 (0x1)) >>>>>>>>>> 0000 - 01 ???????????????????????????????????????????????. >>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>> 0000 - 17 03 03 00 3d ???????????????????????????????????....= >>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (61 bytes => 61 (0x3D)) >>>>>>>>>> 0000 - ad dd 3e d9 ee ab 56 65-50 1c 72 2a d8 62 7f 90 >>>>>>>>>> ??..>...VeP.r*.b.. >>>>>>>>>> 0010 - 13 71 7d 37 39 40 fb 89-8f 05 4b 39 44 9d 4d 67 >>>>>>>>>> ??.q}79 at ....K9D.Mg >>>>>>>>>> 0020 - e3 41 29 b6 3e e8 fe 04-1b 8e eb 7a 4c e2 14 a0 >>>>>>>>>> ??.A).>......zL... >>>>>>>>>> 0030 - b1 c2 47 3f 94 35 ed ab-8a d1 75 3b ba >>>>>>>>>> ???????????..G?.5....u;. >>>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>>> SSL_accept:SSLv3/TLS read client certificate >>>>>>>>>> SSL_accept:SSLv3/TLS read finished >>>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>>>>>>> 0000 - 17 03 03 00 da 52 1f 48-00 f4 31 13 90 7f 9c c2 >>>>>>>>>> ??.....R.H..1..... >>>>>>>>>> 0010 - fc 70 1a fc f7 4a 48 e7-31 ad 37 ab b5 2b 4e 5c >>>>>>>>>> ??.p...JH.1.7..+N\ >>>>>>>>>> 0020 - e8 d8 6d e9 af 6c 4f c1-9e 7b ea ff ef b3 eb 74 >>>>>>>>>> ??..m..lO..{.....t >>>>>>>>>> 0030 - 27 67 10 21 66 5b 32 13-31 bc 99 d5 1c 6c 79 55 >>>>>>>>>> ??'g.!f[2.1....lyU >>>>>>>>>> 0040 - f3 3e f6 4b 07 4d a9 78-3d 12 8a f5 38 ef d9 f4 >>>>>>>>>> ??.>.K.M.x=...8... >>>>>>>>>> 0050 - 48 e0 2c 35 94 06 4f eb-09 e6 70 fb 59 95 7a c8 >>>>>>>>>> ??H.,5..O...p.Y.z. >>>>>>>>>> 0060 - 24 dd 24 e2 f9 63 b9 3c-f2 66 86 c4 73 44 53 fd >>>>>>>>>> ??$.$..c.<.f..sDS. >>>>>>>>>> 0070 - ca 67 8f 01 d6 db 70 f9-60 bc 50 11 51 72 dc 63 >>>>>>>>>> ??.g....p.`.P.Qr.c >>>>>>>>>> 0080 - 12 ca 4f 23 e2 c5 d1 1d-e5 b0 d4 ec 89 ca 28 be >>>>>>>>>> ??..O#..........(. >>>>>>>>>> 0090 - 9c 30 83 40 02 a4 62 a8-5c b3 20 1a ab 39 b7 7b >>>>>>>>>> ??.0. at ..b.\. ..9.{ >>>>>>>>>> 00a0 - 89 13 39 87 73 be a8 f8-60 13 31 0a 48 5c 79 b9 >>>>>>>>>> ??..9.s...`.1.H\y. >>>>>>>>>> 00b0 - cc 4a 51 e3 0d d2 b4 93-c0 1f 3a 22 b3 fa 24 a0 >>>>>>>>>> ??.JQ.......:"..$. >>>>>>>>>> 00c0 - 7c f6 76 79 d0 2d 5b 1a-ff a6 e9 e1 40 d3 b1 8c >>>>>>>>>> ??|.vy.-[..... at ... >>>>>>>>>> 00d0 - 0a fa fa de f3 8e d6 ad-9a 22 6b 67 0b 88 18 >>>>>>>>>> ?????........."kg... >>>>>>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>>>>>>> 0000 - 17 03 03 00 da 46 aa ea-6a 37 b1 35 e8 41 c8 b3 >>>>>>>>>> ??.....F..j7.5.A.. >>>>>>>>>> 0010 - 84 25 af 1c 36 a3 6d 78-a4 44 4a 83 52 ef 13 7c >>>>>>>>>> ??.%..6.mx.DJ.R..| >>>>>>>>>> 0020 - 8f 18 d3 4c f8 22 c8 b3-ad d0 d0 5b 47 a0 43 da >>>>>>>>>> ??...L.".....[G.C. >>>>>>>>>> 0030 - d2 6e 04 8f dc c9 56 90-58 87 62 63 4c cc 31 ec >>>>>>>>>> ??.n....V.X.bcL.1. >>>>>>>>>> 0040 - b8 c9 18 be 41 32 e1 3c-00 41 2a f1 4d 5c 2d 44 >>>>>>>>>> ??....A2.<.A*.M\-D >>>>>>>>>> 0050 - 8c aa e1 f0 ed 38 ee 44-64 e5 fd ea 58 3b 84 5d >>>>>>>>>> ??.....8.Dd...X;.] >>>>>>>>>> 0060 - 83 39 21 2e fe 79 4d 76-10 65 87 0f 3c ac df 28 >>>>>>>>>> ??.9!..yMv.e..<..( >>>>>>>>>> 0070 - 49 f8 60 eb be 49 e4 0a-0b 6a 03 2b 9d cf 9b a5 >>>>>>>>>> ??I.`..I...j.+.... >>>>>>>>>> 0080 - 03 56 58 32 c2 b2 59 f9-0a 0d f0 ae af ff 20 19 >>>>>>>>>> ??.VX2..Y....... . >>>>>>>>>> 0090 - e5 6e e4 86 2f 5e 3f 7d-47 d5 73 ae 89 48 a7 66 >>>>>>>>>> ??.n../^?}G.s..H.f >>>>>>>>>> 00a0 - fb 2d 83 60 e8 8b ab 27-12 db 24 78 54 eb 14 2d >>>>>>>>>> ??.-.`...'..$xT..- >>>>>>>>>> 00b0 - b7 c6 17 2d 3c 91 57 ac-6e 35 b8 c3 fa c2 42 48 >>>>>>>>>> ??...-<.W.n5....BH >>>>>>>>>> 00c0 - 2a cb aa 98 32 89 8a ce-0c f7 cd 5e fb bf 6d 33 >>>>>>>>>> ??*...2......^..m3 >>>>>>>>>> 00d0 - 08 50 cf 1e 06 bb a1 98-be a4 a9 51 9a b0 34 >>>>>>>>>> ?????.P.........Q..4 >>>>>>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>>>>> 0000 - 17 03 03 00 12 c5 9b 73-cc 91 7e 48 cb 25 31 a0 >>>>>>>>>> ??.......s..~H.%1. >>>>>>>>>> 0010 - 67 41 db bb 0f 62 d8 ?????????????????????????????gA...b. >>>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>>>>> 0000 - 17 03 03 00 12 0f dd 3f-c1 7c e6 b0 cc ea f0 13 >>>>>>>>>> ??.......?.|...... >>>>>>>>>> 0010 - 00 d8 01 de ef 7c bb ?????????????????????????????.....|. >>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>> 0000 - 17 03 03 00 1e ???????????????????????????????????..... >>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (30 bytes => 30 (0x1E)) >>>>>>>>>> 0000 - d6 88 44 82 cb 23 16 ba-c9 a4 fb 55 51 08 90 c1 >>>>>>>>>> ??..D..#.....UQ... >>>>>>>>>> 0010 - bf bd a1 7f 0e 37 b0 b4-b5 df f1 07 6c 07 >>>>>>>>>> ????????.....7......l. >>>>>>>>>> I am a clientwrite to 0x7fdc58809fb0 [0x7fdc59021c03] (23 >>>>>>>>>> bytes => 23 (0x17)) >>>>>>>>>> 0000 - 17 03 03 00 12 c0 70 5d-14 e7 69 57 0a d8 64 16 >>>>>>>>>> ??......p]..iW..d. >>>>>>>>>> 0010 - 0c 90 06 0f c3 4d 1d ?????????????????????????????.....M. >>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>> 0000 - 17 03 03 00 13 ???????????????????????????????????..... >>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (19 bytes => 19 (0x13)) >>>>>>>>>> 0000 - 60 28 5b ff bb 0d 9f 96-9a 2d cb fd 60 eb 96 62 >>>>>>>>>> ??`([......-..`..b >>>>>>>>>> 0010 - 53 e6 25 ?????????????????????????????????????????S.% >>>>>>>>>> SSL3 alert read:warning:close notify >>>>>>>>>> DONE >>>>>>>>>> shutting down SSL >>>>>>>>>> CONNECTION CLOSED >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I am using the following JDK version on MacOS: >>>>>>>>>> >>>>>>>>>> ssl git:(cert_cb_openssl_1_1_1) ? >>>>>>>>>> /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java >>>>>>>>>> -version >>>>>>>>>> java version "11" 2018-09-25 >>>>>>>>>> Java(TM) SE Runtime Environment 18.9 (build 11+28) >>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) >>>>>>>>>> >>>>>>>>>> For this to work you will need to have openssl 1.1.1 installed. >>>>>>>>>> >>>>>>>>>> Any help would be welcome, >>>>>>>>>> Norman >>>>>>>>>> >>>>>>>>>> [1] https://github.com/netty/netty-tcnative >> > From mstjohns at comcast.net Wed Sep 19 16:51:41 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 19 Sep 2018 12:51:41 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <67dee2be-670a-9dc6-7e50-66e9c1af8698@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <81dd5ea3-5d0b-5f4d-9e8d-bd8d98fcc49f@oracle.com> <59eb69e2-4f55-1ed2-b505-0304160122dc@oracle.com> <67dee2be-670a-9dc6-7e50-66e9c1af8698@oracle.com> Message-ID: On 9/19/2018 11:45 AM, Adam Petcher wrote: > On 9/18/2018 4:24 PM, Michael StJohns wrote: > >> >> Adam - >> >> Basically, the JCE is all about plugging in not about the >> implementations.? If this is truly an EC library, I should be able to >> get the benefit of your library with very minimal changes - e.g. >> specifying your provider in the various getInstance() calls.?? As it >> stands, I doubt this will end up in anyone's "must use" category >> because it will break existing code. > > Is this standard of being "truly an EC library" met by PKCS11 > providers that don't export keys? This is what you want to hang your hat on??? If you want to implement your code inside an HSM and follow the PKCS11 rules, feel free.? Software libraries are not hardware libraries and the mapping between them is pretty good, but not perfect. And to be clear, it's not the provider that doesn't export the keys - its the underlying HSM and not for all keys.? It's perfectly OK to generate an exportable key on an HSM, but the usual default is the roach motel model.? The provider humors this reality by following the various interface contracts and only providing a PrivateKey object for non-exportable private keys, regardless of type. > >> >> You want folks to convince you that interoperability is a significant >> problem when what we (or at least I) want is for you to convince us >> that these interop breaks are warranted due to how wonderful your >> approach is and that they're absolutely necessary due the secret >> sauce of wonderfulness.? You're not there yet. > > I don't agree with this logic. Color me surprised. > Different providers have different levels of interoperability, No - different providers mostly provide different suites of crypto, but build to a well-defined interface or set of interfaces.?? E.g. I really don't give a damn about what you do inside your own country, but you need to have the same type of passport as everyone else once you leave those boundaries. > and this interoperability is a feature that requires effort to develop > and maintain. I don't want to commit myself or this community to this > effort unless I/we think it is worthwhile. Some of the proposals to > increase interoperability for this effort (e.g. subclassing > BigInteger) would require a significant amount of additional effort, > and I think this requires justification. Implementing to a defined interface is somewhat different than "maintaining interoperability" - at least if you do it right. AFAICT, you're balking at providing the getS() method of the ECPrivateKey interface because you're afraid that conversion to/from BigInteger will leak something.? Guess what... any time you border cross you leak something.? Even ?moving key material from software to hardware will cause you to leak something. > > Of course, if you know of a way to have more interoperability without > reducing assurance or significantly increasing effort, I would love to > hear about it. For assurance, an important property is that the > implementation should not branch on secrets after the developer has > put it in branchless mode (by selecting the branchless provider or by > using some other interface to switch modes). *bleah*? This is not a useful discussion - you've drawn a line in the sand without actually understanding the cost/benefit of that line. ? And I gave you several approaches - simplest is to clone BigInteger and de-branch it for the methods you need.? Actually, simplest is to use the existing BigInteger, because if the provider user is exporting the key material, they're probably going to be putting it into a whole different provider with "weaker" branchless protections. > >> >> As for PKCS11 - there are exportable and non-exportable private keys >> (e.g. PKCS11 with an accelerator vs an HSM for example). The >> exportable ones show up as ECPrivateKeys, the non-exportable ones as >> PrivateKeys (and I think with an underlying type of PKCS11Key...).? >> So it follows the model for exportable keys. And every PKCS11 >> provider I've used at least has a way of IMPORTING ECPrivateKeys. > > My goal is for the new provider to be at least as interoperable as > PKCS11 providers with non-exportable keys. Do all the PKCS11 providers > that you have used allow importing private keys over JCA, or over some > other API? Do you have to put the HSM in some sort of "import mode" in > order for this import to be allowed? Is there any difference in the > way that you can use keys that were loaded over this API vs keys that > were generated on the device (or loaded securely)? > Again - you seriously want to hang your hat on this?: 1) Yes.? Over the JCA.? (Umm.. PKCS11 provider is a JCA/JCE provider so of course this works). 2) No.? In fact, the store operation of the PKCS11 keystore implementation does this just fine. 3) Depends.? If you generate or load the HSM PKCS11 keys according to the JCA PKCS11 guidance (e.g. with the right set of attributes) using a direct PKCS11 driver, then it's seamless. Otherwise, the Sun PKCS11 keystore implementation mostly ignores them as it can't map them properly.??? I'd need to check the other two providers I'm aware of, but I think they implement the same scheme as the Sun provider.? There's also a scheme for twiddling the attributes as part of the provider configuration, but that's a bit more painful. See https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html and Appendix B. From ecki at zusammenkunft.net Wed Sep 19 17:37:14 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 19 Sep 2018 17:37:14 +0000 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <67dee2be-670a-9dc6-7e50-66e9c1af8698@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <81dd5ea3-5d0b-5f4d-9e8d-bd8d98fcc49f@oracle.com> <59eb69e2-4f55-1ed2-b505-0304160122dc@oracle.com> , <67dee2be-670a-9dc6-7e50-66e9c1af8698@oracle.com> Message-ID: Hello, I think I missed it, but where is the conversion on BigInteger branching on key material? Isn?t this only branching on effective constant values? Or are you concerned about Spectre-type problems? Besides that I totally agree on the idea of having a more secure implementation which can be activated by simply switching provider priorities. Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: -1001833328m Auftrag von Gesendet: Mittwoch, September 19, 2018 7:16 PM An: security-dev at openjdk.java.net Betreff: Re: Conceptual feedback on new ECC JEP On 9/18/2018 4:24 PM, Michael StJohns wrote: > > Adam - > > Basically, the JCE is all about plugging in not about the > implementations. If this is truly an EC library, I should be able to > get the benefit of your library with very minimal changes - e.g. > specifying your provider in the various getInstance() calls. As it > stands, I doubt this will end up in anyone's "must use" category > because it will break existing code. Is this standard of being "truly an EC library" met by PKCS11 providers that don't export keys? > > You want folks to convince you that interoperability is a significant > problem when what we (or at least I) want is for you to convince us > that these interop breaks are warranted due to how wonderful your > approach is and that they're absolutely necessary due the secret sauce > of wonderfulness. You're not there yet. I don't agree with this logic. Different providers have different levels of interoperability, and this interoperability is a feature that requires effort to develop and maintain. I don't want to commit myself or this community to this effort unless I/we think it is worthwhile. Some of the proposals to increase interoperability for this effort (e.g. subclassing BigInteger) would require a significant amount of additional effort, and I think this requires justification. Of course, if you know of a way to have more interoperability without reducing assurance or significantly increasing effort, I would love to hear about it. For assurance, an important property is that the implementation should not branch on secrets after the developer has put it in branchless mode (by selecting the branchless provider or by using some other interface to switch modes). > > As for PKCS11 - there are exportable and non-exportable private keys > (e.g. PKCS11 with an accelerator vs an HSM for example). The > exportable ones show up as ECPrivateKeys, the non-exportable ones as > PrivateKeys (and I think with an underlying type of PKCS11Key...). So > it follows the model for exportable keys. And every PKCS11 provider > I've used at least has a way of IMPORTING ECPrivateKeys. My goal is for the new provider to be at least as interoperable as PKCS11 providers with non-exportable keys. Do all the PKCS11 providers that you have used allow importing private keys over JCA, or over some other API? Do you have to put the HSM in some sort of "import mode" in order for this import to be allowed? Is there any difference in the way that you can use keys that were loaded over this API vs keys that were generated on the device (or loaded securely)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Wed Sep 19 19:34:57 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 19 Sep 2018 15:34:57 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <81dd5ea3-5d0b-5f4d-9e8d-bd8d98fcc49f@oracle.com> <59eb69e2-4f55-1ed2-b505-0304160122dc@oracle.com> <67dee2be-670a-9dc6-7e50-66e9c1af8698@oracle.com> Message-ID: <3cfeb348-0b4f-23bb-8618-d8aedc3f8920@oracle.com> On 9/19/2018 12:51 PM, Michael StJohns wrote: > On 9/19/2018 11:45 AM, Adam Petcher wrote: >> My goal is for the new provider to be at least as interoperable as >> PKCS11 providers with non-exportable keys. Do all the PKCS11 >> providers that you have used allow importing private keys over JCA, >> or over some other API? Do you have to put the HSM in some sort of >> "import mode" in order for this import to be allowed? Is there any >> difference in the way that you can use keys that were loaded over >> this API vs keys that were generated on the device (or loaded securely)? >> > Again - you seriously want to hang your hat on this?: > > 1) Yes.? Over the JCA.? (Umm.. PKCS11 provider is a JCA/JCE provider > so of course this works). > > 2) No.? In fact, the store operation of the PKCS11 keystore > implementation does this just fine. > > 3) Depends.? If you generate or load the HSM PKCS11 keys according to > the JCA PKCS11 guidance (e.g. with the right set of attributes) using > a direct PKCS11 driver, then it's seamless. Otherwise, the Sun PKCS11 > keystore implementation mostly ignores them as it can't map them > properly.??? I'd need to check the other two providers I'm aware of, > but I think they implement the same scheme as the Sun provider.? > There's also a scheme for twiddling the attributes as part of the > provider configuration, but that's a bit more painful. > > See > https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html > and Appendix B. > > Thanks for the information. I'm having trouble believing that there is no situation in which a PKCS11 provider/token/HSM would reject a key that it is asked to import. But this is mostly a detour in the discussion. If the API of the new ECC implementation is, in some ways, more restrictive than PKCS11 with non-extractable keys, then that is acceptable to me. From adam.petcher at oracle.com Wed Sep 19 20:03:39 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 19 Sep 2018 16:03:39 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <81dd5ea3-5d0b-5f4d-9e8d-bd8d98fcc49f@oracle.com> <59eb69e2-4f55-1ed2-b505-0304160122dc@oracle.com> <67dee2be-670a-9dc6-7e50-66e9c1af8698@oracle.com> Message-ID: <7fb2d93c-c3a6-0ad1-1b8e-0a18db3767fb@oracle.com> On 9/19/2018 1:37 PM, Bernd Eckenfels wrote: > Hello, > > I think I missed it, but where is the conversion on BigInteger > branching on key material? Isn?t this only branching on effective > constant values? > > Or are you concerned about Spectre-type problems? This is not for Spectre (etc.) issues, which effectively dump all memory contents, so there is nothing we can do to prevent it at this level. The proposed implementation defends against cache attacks like Flush+Reload[1], as well as timing attacks. Imagine an EC private key (i.e. a scalar) is stored in a fixed-length little-endian byte array in the key implementation class. I can perform the required EC operations directly on this byte array without branching on any part of its value. Now if I want to convert this key to an ECPrivateKeySpec using the KeyFactory, I need to convert this scalar to a BigInteger, which uses a variable-length representation. This conversion necessarily branches on the value of the private key, which we are trying to avoid. Branching on any non-secret value (including algorithm parameters and constants) is fine, but in the example above, we would be branching on the valud of the private key. [1] https://eprint.iacr.org/2013/448.pdf > > Besides that I totally agree on the idea of having a more secure > implementation which can be activated by simply switching provider > priorities. > > Gruss > Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Wed Sep 19 20:47:35 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 19 Sep 2018 13:47:35 -0700 Subject: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth Message-ID: <2c5b54d8-0596-4949-6a4b-5f19325c17c2@oracle.com> Hello all, This fix handles an issue in TLS client certificate authentication where our client was failing to send a certificate after consuming the CertificateRequest message.? Thanks to Norman Maurer for bringing this to our attention. Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8210846 --Jamil From norman.maurer at googlemail.com Wed Sep 19 20:59:19 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Wed, 19 Sep 2018 13:59:19 -0700 Subject: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: <2c5b54d8-0596-4949-6a4b-5f19325c17c2@oracle.com> References: <2c5b54d8-0596-4949-6a4b-5f19325c17c2@oracle.com> Message-ID: I will test and report back later today . Thanks for the quick turnaround > Am 19.09.2018 um 13:47 schrieb Jamil Nimeh : > > Hello all, > > This fix handles an issue in TLS client certificate authentication where our client was failing to send a certificate after consuming the CertificateRequest message. Thanks to Norman Maurer for bringing this to our attention. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210846 > > --Jamil > From bradford.wetmore at oracle.com Wed Sep 19 22:13:12 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 19 Sep 2018 15:13:12 -0700 Subject: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: References: <2c5b54d8-0596-4949-6a4b-5f19325c17c2@oracle.com> Message-ID: <51744230-a016-1772-df48-f1f603dfdb82@oracle.com> Looks good from a CR standpoint. Silly typos... Looking forward to hearing back from Norman. I believe we are running the same testbed, so I expect it will work. Jamil, be sure to include the specific interop test information in the bug, so that when SQE goes to verify, they can be sure to run it manually. Brad On 9/19/2018 1:59 PM, Norman Maurer wrote: > I will test and report back later today . Thanks for the quick turnaround > >> Am 19.09.2018 um 13:47 schrieb Jamil Nimeh : >> >> Hello all, >> >> This fix handles an issue in TLS client certificate authentication where our client was failing to send a certificate after consuming the CertificateRequest message. Thanks to Norman Maurer for bringing this to our attention. >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210846 >> >> --Jamil >> From jamil.j.nimeh at oracle.com Wed Sep 19 22:21:03 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 19 Sep 2018 15:21:03 -0700 Subject: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: <51744230-a016-1772-df48-f1f603dfdb82@oracle.com> Message-ID: <201809192221.w8JML70h014203@userv0122.oracle.com> I will add my test information to the bug.? Thanks for reviewing it. --Jamil -------- Original message --------From: Bradford Wetmore Date: 9/19/18 3:13 PM (GMT-08:00) To: Norman Maurer , Jamil Nimeh Cc: OpenJDK Dev list Subject: Re: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth Looks good from a CR standpoint.? Silly typos... Looking forward to hearing back from Norman.? I believe we are running the same testbed, so I expect it will work. Jamil, be sure to include the specific interop test information in the bug, so that when SQE goes to verify, they can be sure to run it manually. Brad On 9/19/2018 1:59 PM, Norman Maurer wrote: > I will test and report back later today . Thanks for the quick turnaround > >> Am 19.09.2018 um 13:47 schrieb Jamil Nimeh : >> >> Hello all, >> >> This fix handles an issue in TLS client certificate authentication where our client was failing to send a certificate after consuming the CertificateRequest message.? Thanks to Norman Maurer for bringing this to our attention. >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210846 >> >> --Jamil >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman.maurer at googlemail.com Wed Sep 19 23:32:03 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Wed, 19 Sep 2018 16:32:03 -0700 Subject: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: <51744230-a016-1772-df48-f1f603dfdb82@oracle.com> References: <2c5b54d8-0596-4949-6a4b-5f19325c17c2@oracle.com> <51744230-a016-1772-df48-f1f603dfdb82@oracle.com> Message-ID: <01E6EF5A-A2BE-4058-955A-434F2F15E8C2@googlemail.com> I can confirm that this patch fixes the issue I was seeing. After applying it it also passes all of the tests that we have in the SSL testsuite of netty. So +1 from me. Bye Norman > On 19. Sep 2018, at 15:13, Bradford Wetmore wrote: > > Looks good from a CR standpoint. Silly typos... > > Looking forward to hearing back from Norman. I believe we are running the same testbed, so I expect it will work. > > Jamil, be sure to include the specific interop test information in the bug, so that when SQE goes to verify, they can be sure to run it manually. > > Brad > > > On 9/19/2018 1:59 PM, Norman Maurer wrote: >> I will test and report back later today . Thanks for the quick turnaround >>> Am 19.09.2018 um 13:47 schrieb Jamil Nimeh : >>> >>> Hello all, >>> >>> This fix handles an issue in TLS client certificate authentication where our client was failing to send a certificate after consuming the CertificateRequest message. Thanks to Norman Maurer for bringing this to our attention. >>> >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/ >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210846 >>> >>> --Jamil >>> From jamil.j.nimeh at oracle.com Thu Sep 20 00:37:27 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 19 Sep 2018 17:37:27 -0700 Subject: =?US-ASCII?Q?Re:_RFR:_JDK-8210846,_TLSv.?= =?US-ASCII?Q?1.3_interop_problems_with_Ope?= =?US-ASCII?Q?nSSL_1.1.1=0D__when_used_on_the_client_side_with_mutual_auth?= Message-ID: Great news! ?Thanks for running the tests on your end, Norman. --Jamil -------- Original message -------- From: Norman Maurer Date: 9/19/18 4:32 PM (GMT-08:00) To: Bradford Wetmore Cc: Jamil Nimeh , OpenJDK Dev list Subject: Re: RFR: JDK-8210846, TLSv.1.3 interop problems with OpenSSL 1.1.1   when used on the client side with mutual auth I can confirm that this patch fixes the issue I was seeing. After applying it it also passes all of the tests that we have in the SSL testsuite of netty. So +1 from me. Bye Norman > On 19. Sep 2018, at 15:13, Bradford Wetmore wrote: > > Looks good from a CR standpoint.? Silly typos... > > Looking forward to hearing back from Norman.? I believe we are running the same testbed, so I expect it will work. > > Jamil, be sure to include the specific interop test information in the bug, so that when SQE goes to verify, they can be sure to run it manually. > > Brad > > > On 9/19/2018 1:59 PM, Norman Maurer wrote: >> I will test and report back later today . Thanks for the quick turnaround >>> Am 19.09.2018 um 13:47 schrieb Jamil Nimeh : >>> >>> Hello all, >>> >>> This fix handles an issue in TLS client certificate authentication where our client was failing to send a certificate after consuming the CertificateRequest message.? Thanks to Norman Maurer for bringing this to our attention. >>> >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210846/webrev.01/ >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210846 >>> >>> --Jamil >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasadarao.koppula at oracle.com Thu Sep 20 03:08:53 2018 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Wed, 19 Sep 2018 20:08:53 -0700 (PDT) Subject: [8u-dev] RFR JDK-8187218 & JDK-8131051, two krb5 fixes on renewable In-Reply-To: References: <5574b292-1143-456d-b53d-88d650bcfb56@default> Message-ID: Thanks Max for review, corrected all the coding style changes. Thanks, Prasad.K -----Original Message----- From: Weijun Wang Sent: Wednesday, September 19, 2018 9:09 PM To: Prasadrao Koppula Cc: security-dev at openjdk.java.net Subject: Re: [8u-dev] RFR JDK-8187218 & JDK-8131051, two krb5 fixes on renewable Change looks fine, but the code style of lines 947-954 is quite different from normal, including, no space after keywords, wrong indentation of inner block and wrapped line, brace and else not on the same line, etc. --Max > On Sep 19, 2018, at 10:40 PM, Prasadrao Koppula wrote: > > Could you please review the following fixes for 8u-dev? > > jbs: https://bugs.openjdk.java.net/browse/JDK-8187218, > https://bugs.openjdk.java.net/browse/JDK-8131051 > webrev: http://cr.openjdk.java.net/~pkoppula/8187218/webrev.00/ > > Thanks, > Prasad.K From jai.forums2013 at gmail.com Thu Sep 20 13:16:30 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 20 Sep 2018 18:46:30 +0530 Subject: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid ECDH ServerKeyExchange with non-default security provider In-Reply-To: <31ab966b-1f35-7cdd-3541-4b81e2d0bf01@gmail.com> References: <31ab966b-1f35-7cdd-3541-4b81e2d0bf01@gmail.com> Message-ID: <78b2ea15-82e1-57cd-49dc-d042323852b6@gmail.com> Just checking - does this look like a genuine issue? Anything else I can provide to help reproduce this? -Jaikiran On 18/09/18 7:06 PM, Jaikiran Pai wrote: > I have been testing some projects that I know of, with Java 11 RC. > There's one specific test that has been failing for me, for a while now, > during SSL handshake. Took me a while to narrow it down given the size > of the application and the nature of the exception. The exception occurs > during SSL handshake between a client and a server (both Java and both > using Java 11 RC) and it kept throwing: > > Exception in thread "main" javax.net.ssl.SSLHandshakeException: Invalid > ECDH ServerKeyExchange signature > ??? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) > ??? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > ??? at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > ??? at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) > ??? at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) > ??? at > java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.(ECDHServerKeyExchange.java:329) > ??? at > java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeConsumer.consume(ECDHServerKeyExchange.java:535) > ??? at > java.base/sun.security.ssl.ServerKeyExchange$ServerKeyExchangeConsumer.consume(ServerKeyExchange.java:103) > ??? at > java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) > ??? at > java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) > ??? at > java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421) > ??? at > java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178) > ??? at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) > ??? at > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) > ??? at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) > ??? at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > ??? at > java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567) > ??? at > java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) > ??? at > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581) > ??? at > java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509) > ??? at > java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245) > ... > > This is consistently reproducible if, in the scheme of things: > > ?1. the cipher suite selected is a ECDHE one. For example > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. The TLS version itself is TLSv1.2 > (both server and client). > > ?2. One side of the client/server, is backed by BouncyCastle as the > security provider (very specifically for SignatureSpi). > > Assuming the server side is using BouncyCastle provider, what's > happening is that during the handshake, the server side uses the > RSASSA-PSS algorithm, backed by this provider and writes out the > signature. The client side uses SunRsaSign (default provider) and tries > to verify this RSASSA-PSS signature and fails with that above exception. > FWIW, I don't believe the signature algorithm matters as long as the > cipher is ECDHE backed and the client and server side use a different > security provider. > > All this works perfectly fine when both the sides use the default > provider and bouncycastle isn't involved. > > I was able to get this reproducible in a very simple server/client > standalone program. I think this can even be demonstrated in a jtreg > test but I don't have enough experience with it to see how to trigger a > server in a separate JVM and then use a client for testing. The > reproducer code (Server.java and Client.java) is at the end of this mail > along with instructions on how to reproduce it. > > I was also able to narrow down this issue down to a specific part of the > JDK code. sun.security.ssl.SignatureScheme#getSignature[1] inits the > Signature instance for either signing or verifying. However it sets up > the signature parameters _after_ the init is done and in fact, there's > an explicit note[2] stating what/why it's doing it there. I admit, I > don't have much knowledge of the Java SSL parts and none in these > internal details and don't understand the details of that implementation > notes. However, just to try it out, I switched the order of it by using > this local patch: > > diff -r fbb71a7edc1a > src/java.base/share/classes/sun/security/ssl/SignatureScheme.java > --- > a/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java??? > Sat Aug 25 20:16:43 2018 +0530 > +++ > b/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java??? > Tue Sep 18 18:47:52 2018 +0530 > @@ -467,18 +467,16 @@ > ???????? } > ? > ???????? Signature signer = JsseJce.getSignature(algorithm); > +??????? if (signAlgParameter != null) { > +??????????? signer.setParameter(signAlgParameter); > +??????? } > + > ???????? if (key instanceof PublicKey) { > ???????????? signer.initVerify((PublicKey)(key)); > ???????? } else { > ???????????? signer.initSign((PrivateKey)key); > ???????? } > ? > -??????? // Important note:? Please don't set the parameters before > signature > -??????? // or verification initialization, so that the crypto provider can > -??????? // be selected properly. > -??????? if (signAlgParameter != null) { > -??????????? signer.setParameter(signAlgParameter); > -??????? } > ? > ???????? return signer; > ???? } > > Built this version and gave it a try with the sample code below (and > also against the actual application). Both worked fine. I tried cases: > > ?- where one side had default provider and other side had bouncycastle. > > ?- where both sides were default provider > > > Any thoughts on this issue? Here's the code to reproduce it: > > Server.java > > ----------- > > import java.io.*; > import java.net.*; > import javax.net.ssl.*; > import java.util.*; > import java.util.concurrent.*; > import java.security.*; > import com.sun.net.httpserver.*; > import java.security.cert.*; > > > public class Server { > ??? private static final String keyFilename = "keystore"; > ??? private static final String keystorePass = "passphrase"; > ??? private static final String WEB_APP_CONTEXT = "/test"; > > ??? public static void main(final String[] args) throws Exception { > ??? ??? if (args.length == 1 && args[0].equals("--use-bouncy-castle")) { > ??? ??? ??? // enable bouncycastle > ??? ??? ??? Security.insertProviderAt(new > org.bouncycastle.jce.provider.BouncyCastleProvider(), 2); > ??? ??? ??? System.out.println("Using bouncycastle provider"); > ??? ??? } else { > ??? ??? ??? System.out.println("Using JRE security provider"); > ??? ??? } > > ??? ??? final int port = 12345; > ??? ??? // start the server > ??????? final HttpsServer server = startServer("localhost", port); > ??????? // stop server on shutdown > ??????? Runtime.getRuntime().addShutdownHook(new Thread(() -> { > ??????? ??? if (server != null) { > ??????? ??? ??? server.stop(0); > ??? ??? ??? ??? System.out.println("Stopped server"); > ??????? ??? } > ??????? })); > ??? } > > ??? private static HttpsServer startServer(final String host, final int > port) throws Exception { > ??????? final HttpsServer server = HttpsServer.create(new > InetSocketAddress(host, port), 0); > ??? ??? final Thread t = new Thread(() -> { > ??? ??? ??? try { > ??? ??? ??? ??? final SSLContext sslctx = SSLContext.getInstance("TLSv1.2"); > ??? ??? ??????? final KeyManagerFactory kmf = > KeyManagerFactory.getInstance("SunX509"); > ??? ??? ??????? final KeyStore ks = KeyStore.getInstance("JKS"); > ??? ??? ??????? try (final FileInputStream fis = new > FileInputStream(keyFilename)) { > ??? ??? ??????????? ks.load(fis, keystorePass.toCharArray()); > ??? ??? ??????? } > ??? ??? ??????? kmf.init(ks, keystorePass.toCharArray()); > ??? ??? ??????? sslctx.init(kmf.getKeyManagers(), null, null); > ??? ??? ??????? final SSLParameters sslParameters = > sslctx.getDefaultSSLParameters(); > ??? ??? ??????? sslParameters.setProtocols(new String[] { "TLSv1.2" }); > ??? ??? ??????? // use ECDHE specific ciphersuite > ??? ??? ??????? sslParameters.setCipherSuites(new String[] { > "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"}); > ??? ??? ??????? server.setHttpsConfigurator(new HttpsConfigurator(sslctx) { > ??? ??? ??????? ??? @Override > ??? ??? ??????? ??? public void configure(final HttpsParameters params) { > ??? ??? ??????? ??? ??? params.setSSLParameters(sslParameters); > ??? ??? ??????? ??? } > ??? ??? ??????? }); > ??? ??? ??????? server.createContext(WEB_APP_CONTEXT, (exchange)-> > exchange.sendResponseHeaders(200, -1)); > ??? ??? ??? ??? server.start(); > ??? ??? ??? ??? System.out.println("Started server at " + > server.getAddress()); > ??? ??? ??? } catch(Exception e) { > ??? ??? ??? ??? throw new RuntimeException(e); > ??? ??? ??? } > ??? ??? }); > ??? ??? t.start(); > ??? ??? return server; > ??? } > } > > To run this: > > (you'll need bouncycastle jar in your classpath. you can get it from[3]) > > java -cp bcprov-jdk15on-1.58.jar Server.java --use-bouncy-castle > > You should see output like: > > Using bouncycastle provider > Started server at /127.0.0.1:12345 > > (not passing --use-bouncy-castle will start the server with the regular > default JRE provided security provider). > > The server is now up and running and ready to accept the request. See > how to run the client below. This server code uses a keystore file which > is part of the OpenJDK repo and can be obtained from [4] and stored in > the current working directory. > > Client.java > > ------------ > > import java.io.*; > import java.net.*; > import javax.net.ssl.*; > import java.util.*; > import java.util.concurrent.*; > import java.security.*; > import com.sun.net.httpserver.*; > import java.security.cert.*; > > > public class Client { > ??? private static final String WEB_APP_CONTEXT = "/test"; > > ??? public static void main(final String[] args) throws Exception {??? ??? > ??? ??? HttpsURLConnection.setDefaultHostnameVerifier((h, s) -> {return > true;}); > ??? ??? > ??? ??? final int port = 12345; > ??? ??? final URL targetURL = new URL("https://localhost:" + port + > WEB_APP_CONTEXT); > ??? ??? final HttpsURLConnection conn = (HttpsURLConnection) > targetURL.openConnection(); > ??? ??? > ??? ??? // use a SSLSocketFactory which "trusts all" > ??? ??? final SSLContext sslctx = SSLContext.getInstance("TLSv1.2"); > ??????? sslctx.init(null, new TrustManager[] {new TrustAll()}, null); > ??? ??? conn.setSSLSocketFactory(sslctx.getSocketFactory()); > > ??? ??? // read > ??? ??? try (final InputStream is = conn.getInputStream()) { > ??? ??????? is.read(); > ??? ??? } > ??? ??? System.out.println("Received status code " + > conn.getResponseCode()); > ??? } > > ??? private static class TrustAll implements X509TrustManager { > > ??? ??? @Override > ??? ??? public void checkClientTrusted(X509Certificate[] chain, String > authType) throws CertificateException { > ??? ??? ??? return; > ??????? } > > ??? ??? @Override > ??? ??? public void checkServerTrusted(X509Certificate[] chain, String > authType) throws CertificateException { > ??? ??? ??? return; > ??? ??? } > > ??? ??? @Override > ??? ??? public X509Certificate[] getAcceptedIssuers() { > ??? ??? ??? return new X509Certificate[0]; > ??? ??? } > ??? } > } > > To run the client: > > java Client.java > > A successful execution will show: > > Received status code 200 > > whereas a failed execution should throw the exception shown previously > in the mail. > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l463 > > [2] > http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l476 > > [3] > http://repo1.maven.org/maven2/org/bouncycastle/bcprov-jdk15on/1.58/bcprov-jdk15on-1.58.jar > > [4] > http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/test/jdk/javax/net/ssl/etc/keystore > > -Jaikiran > > > > > From xuelei.fan at oracle.com Thu Sep 20 15:07:02 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 20 Sep 2018 08:07:02 -0700 Subject: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid ECDH ServerKeyExchange with non-default security provider In-Reply-To: <78b2ea15-82e1-57cd-49dc-d042323852b6@gmail.com> References: <31ab966b-1f35-7cdd-3541-4b81e2d0bf01@gmail.com> <78b2ea15-82e1-57cd-49dc-d042323852b6@gmail.com> Message-ID: <75aa940a-33c9-1d13-ec84-1843631adb74@oracle.com> Hi Jaikiran, Does it happen if using JDK crypto provider? Thanks, Xuelei On 9/20/2018 6:16 AM, Jaikiran Pai wrote: > Just checking - does this look like a genuine issue? Anything else I can > provide to help reproduce this? > > -Jaikiran > > > On 18/09/18 7:06 PM, Jaikiran Pai wrote: >> I have been testing some projects that I know of, with Java 11 RC. >> There's one specific test that has been failing for me, for a while now, >> during SSL handshake. Took me a while to narrow it down given the size >> of the application and the nature of the exception. The exception occurs >> during SSL handshake between a client and a server (both Java and both >> using Java 11 RC) and it kept throwing: >> >> Exception in thread "main" javax.net.ssl.SSLHandshakeException: Invalid >> ECDH ServerKeyExchange signature >> ??? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >> ??? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> ??? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >> ??? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) >> ??? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) >> ??? at >> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.(ECDHServerKeyExchange.java:329) >> ??? at >> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeConsumer.consume(ECDHServerKeyExchange.java:535) >> ??? at >> java.base/sun.security.ssl.ServerKeyExchange$ServerKeyExchangeConsumer.consume(ServerKeyExchange.java:103) >> ??? at >> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >> ??? at >> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) >> ??? at >> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421) >> ??? at >> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178) >> ??? at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >> ??? at >> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >> ??? at >> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >> ??? at >> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >> ??? at >> java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567) >> ??? at >> java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) >> ??? at >> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581) >> ??? at >> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509) >> ??? at >> java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245) >> ... >> >> This is consistently reproducible if, in the scheme of things: >> >> ?1. the cipher suite selected is a ECDHE one. For example >> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. The TLS version itself is TLSv1.2 >> (both server and client). >> >> ?2. One side of the client/server, is backed by BouncyCastle as the >> security provider (very specifically for SignatureSpi). >> >> Assuming the server side is using BouncyCastle provider, what's >> happening is that during the handshake, the server side uses the >> RSASSA-PSS algorithm, backed by this provider and writes out the >> signature. The client side uses SunRsaSign (default provider) and tries >> to verify this RSASSA-PSS signature and fails with that above exception. >> FWIW, I don't believe the signature algorithm matters as long as the >> cipher is ECDHE backed and the client and server side use a different >> security provider. >> >> All this works perfectly fine when both the sides use the default >> provider and bouncycastle isn't involved. >> >> I was able to get this reproducible in a very simple server/client >> standalone program. I think this can even be demonstrated in a jtreg >> test but I don't have enough experience with it to see how to trigger a >> server in a separate JVM and then use a client for testing. The >> reproducer code (Server.java and Client.java) is at the end of this mail >> along with instructions on how to reproduce it. >> >> I was also able to narrow down this issue down to a specific part of the >> JDK code. sun.security.ssl.SignatureScheme#getSignature[1] inits the >> Signature instance for either signing or verifying. However it sets up >> the signature parameters _after_ the init is done and in fact, there's >> an explicit note[2] stating what/why it's doing it there. I admit, I >> don't have much knowledge of the Java SSL parts and none in these >> internal details and don't understand the details of that implementation >> notes. However, just to try it out, I switched the order of it by using >> this local patch: >> >> diff -r fbb71a7edc1a >> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java >> --- >> a/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java >> Sat Aug 25 20:16:43 2018 +0530 >> +++ >> b/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java >> Tue Sep 18 18:47:52 2018 +0530 >> @@ -467,18 +467,16 @@ >> ???????? } >> >> ???????? Signature signer = JsseJce.getSignature(algorithm); >> +??????? if (signAlgParameter != null) { >> +??????????? signer.setParameter(signAlgParameter); >> +??????? } >> + >> ???????? if (key instanceof PublicKey) { >> ???????????? signer.initVerify((PublicKey)(key)); >> ???????? } else { >> ???????????? signer.initSign((PrivateKey)key); >> ???????? } >> >> -??????? // Important note:? Please don't set the parameters before >> signature >> -??????? // or verification initialization, so that the crypto provider can >> -??????? // be selected properly. >> -??????? if (signAlgParameter != null) { >> -??????????? signer.setParameter(signAlgParameter); >> -??????? } >> >> ???????? return signer; >> ???? } >> >> Built this version and gave it a try with the sample code below (and >> also against the actual application). Both worked fine. I tried cases: >> >> ?- where one side had default provider and other side had bouncycastle. >> >> ?- where both sides were default provider >> >> >> Any thoughts on this issue? Here's the code to reproduce it: >> >> Server.java >> >> ----------- >> >> import java.io.*; >> import java.net.*; >> import javax.net.ssl.*; >> import java.util.*; >> import java.util.concurrent.*; >> import java.security.*; >> import com.sun.net.httpserver.*; >> import java.security.cert.*; >> >> >> public class Server { >> ??? private static final String keyFilename = "keystore"; >> ??? private static final String keystorePass = "passphrase"; >> ??? private static final String WEB_APP_CONTEXT = "/test"; >> >> ??? public static void main(final String[] args) throws Exception { >> ??? ??? if (args.length == 1 && args[0].equals("--use-bouncy-castle")) { >> ??? ??? ??? // enable bouncycastle >> ??? ??? ??? Security.insertProviderAt(new >> org.bouncycastle.jce.provider.BouncyCastleProvider(), 2); >> ??? ??? ??? System.out.println("Using bouncycastle provider"); >> ??? ??? } else { >> ??? ??? ??? System.out.println("Using JRE security provider"); >> ??? ??? } >> >> ??? ??? final int port = 12345; >> ??? ??? // start the server >> ??????? final HttpsServer server = startServer("localhost", port); >> ??????? // stop server on shutdown >> ??????? Runtime.getRuntime().addShutdownHook(new Thread(() -> { >> ??????? ??? if (server != null) { >> ??????? ??? ??? server.stop(0); >> ??? ??? ??? ??? System.out.println("Stopped server"); >> ??????? ??? } >> ??????? })); >> ??? } >> >> ??? private static HttpsServer startServer(final String host, final int >> port) throws Exception { >> ??????? final HttpsServer server = HttpsServer.create(new >> InetSocketAddress(host, port), 0); >> ??? ??? final Thread t = new Thread(() -> { >> ??? ??? ??? try { >> ??? ??? ??? ??? final SSLContext sslctx = SSLContext.getInstance("TLSv1.2"); >> ??? ??? ??????? final KeyManagerFactory kmf = >> KeyManagerFactory.getInstance("SunX509"); >> ??? ??? ??????? final KeyStore ks = KeyStore.getInstance("JKS"); >> ??? ??? ??????? try (final FileInputStream fis = new >> FileInputStream(keyFilename)) { >> ??? ??? ??????????? ks.load(fis, keystorePass.toCharArray()); >> ??? ??? ??????? } >> ??? ??? ??????? kmf.init(ks, keystorePass.toCharArray()); >> ??? ??? ??????? sslctx.init(kmf.getKeyManagers(), null, null); >> ??? ??? ??????? final SSLParameters sslParameters = >> sslctx.getDefaultSSLParameters(); >> ??? ??? ??????? sslParameters.setProtocols(new String[] { "TLSv1.2" }); >> ??? ??? ??????? // use ECDHE specific ciphersuite >> ??? ??? ??????? sslParameters.setCipherSuites(new String[] { >> "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"}); >> ??? ??? ??????? server.setHttpsConfigurator(new HttpsConfigurator(sslctx) { >> ??? ??? ??????? ??? @Override >> ??? ??? ??????? ??? public void configure(final HttpsParameters params) { >> ??? ??? ??????? ??? ??? params.setSSLParameters(sslParameters); >> ??? ??? ??????? ??? } >> ??? ??? ??????? }); >> ??? ??? ??????? server.createContext(WEB_APP_CONTEXT, (exchange)-> >> exchange.sendResponseHeaders(200, -1)); >> ??? ??? ??? ??? server.start(); >> ??? ??? ??? ??? System.out.println("Started server at " + >> server.getAddress()); >> ??? ??? ??? } catch(Exception e) { >> ??? ??? ??? ??? throw new RuntimeException(e); >> ??? ??? ??? } >> ??? ??? }); >> ??? ??? t.start(); >> ??? ??? return server; >> ??? } >> } >> >> To run this: >> >> (you'll need bouncycastle jar in your classpath. you can get it from[3]) >> >> java -cp bcprov-jdk15on-1.58.jar Server.java --use-bouncy-castle >> >> You should see output like: >> >> Using bouncycastle provider >> Started server at /127.0.0.1:12345 >> >> (not passing --use-bouncy-castle will start the server with the regular >> default JRE provided security provider). >> >> The server is now up and running and ready to accept the request. See >> how to run the client below. This server code uses a keystore file which >> is part of the OpenJDK repo and can be obtained from [4] and stored in >> the current working directory. >> >> Client.java >> >> ------------ >> >> import java.io.*; >> import java.net.*; >> import javax.net.ssl.*; >> import java.util.*; >> import java.util.concurrent.*; >> import java.security.*; >> import com.sun.net.httpserver.*; >> import java.security.cert.*; >> >> >> public class Client { >> ??? private static final String WEB_APP_CONTEXT = "/test"; >> >> ??? public static void main(final String[] args) throws Exception { >> ??? ??? HttpsURLConnection.setDefaultHostnameVerifier((h, s) -> {return >> true;}); >> >> ??? ??? final int port = 12345; >> ??? ??? final URL targetURL = new URL("https://localhost:" + port + >> WEB_APP_CONTEXT); >> ??? ??? final HttpsURLConnection conn = (HttpsURLConnection) >> targetURL.openConnection(); >> >> ??? ??? // use a SSLSocketFactory which "trusts all" >> ??? ??? final SSLContext sslctx = SSLContext.getInstance("TLSv1.2"); >> ??????? sslctx.init(null, new TrustManager[] {new TrustAll()}, null); >> ??? ??? conn.setSSLSocketFactory(sslctx.getSocketFactory()); >> >> ??? ??? // read >> ??? ??? try (final InputStream is = conn.getInputStream()) { >> ??? ??????? is.read(); >> ??? ??? } >> ??? ??? System.out.println("Received status code " + >> conn.getResponseCode()); >> ??? } >> >> ??? private static class TrustAll implements X509TrustManager { >> >> ??? ??? @Override >> ??? ??? public void checkClientTrusted(X509Certificate[] chain, String >> authType) throws CertificateException { >> ??? ??? ??? return; >> ??????? } >> >> ??? ??? @Override >> ??? ??? public void checkServerTrusted(X509Certificate[] chain, String >> authType) throws CertificateException { >> ??? ??? ??? return; >> ??? ??? } >> >> ??? ??? @Override >> ??? ??? public X509Certificate[] getAcceptedIssuers() { >> ??? ??? ??? return new X509Certificate[0]; >> ??? ??? } >> ??? } >> } >> >> To run the client: >> >> java Client.java >> >> A successful execution will show: >> >> Received status code 200 >> >> whereas a failed execution should throw the exception shown previously >> in the mail. >> >> [1] >> http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l463 >> >> [2] >> http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l476 >> >> [3] >> http://repo1.maven.org/maven2/org/bouncycastle/bcprov-jdk15on/1.58/bcprov-jdk15on-1.58.jar >> >> [4] >> http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/test/jdk/javax/net/ssl/etc/keystore >> >> -Jaikiran >> >> >> >> >> > From jai.forums2013 at gmail.com Thu Sep 20 15:22:02 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 20 Sep 2018 20:52:02 +0530 Subject: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid ECDH ServerKeyExchange with non-default security provider In-Reply-To: <75aa940a-33c9-1d13-ec84-1843631adb74@oracle.com> References: <31ab966b-1f35-7cdd-3541-4b81e2d0bf01@gmail.com> <78b2ea15-82e1-57cd-49dc-d042323852b6@gmail.com> <75aa940a-33c9-1d13-ec84-1843631adb74@oracle.com> Message-ID: Hello Xuelei, It doesn't happen if both the server side and client side use the JDK crypto provider. However if any one side uses a different crypto provider (bouncycastle in this case) then it throws this exception. -Jaikiran On 20/09/18 8:37 PM, Xuelei Fan wrote: > Hi Jaikiran, > > Does it happen if using JDK crypto provider? > > Thanks, > Xuelei > > On 9/20/2018 6:16 AM, Jaikiran Pai wrote: >> Just checking - does this look like a genuine issue? Anything else I can >> provide to help reproduce this? >> >> -Jaikiran >> >> >> On 18/09/18 7:06 PM, Jaikiran Pai wrote: >>> I have been testing some projects that I know of, with Java 11 RC. >>> There's one specific test that has been failing for me, for a while >>> now, >>> during SSL handshake. Took me a while to narrow it down given the size >>> of the application and the nature of the exception. The exception >>> occurs >>> during SSL handshake between a client and a server (both Java and both >>> using Java 11 RC) and it kept throwing: >>> >>> Exception in thread "main" javax.net.ssl.SSLHandshakeException: Invalid >>> ECDH ServerKeyExchange signature >>> ???? at >>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>> ???? at >>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>> ???? at >>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>> >>> ???? at >>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) >>> >>> ???? at >>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) >>> >>> ???? at >>> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.(ECDHServerKeyExchange.java:329) >>> >>> ???? at >>> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeConsumer.consume(ECDHServerKeyExchange.java:535) >>> >>> ???? at >>> java.base/sun.security.ssl.ServerKeyExchange$ServerKeyExchangeConsumer.consume(ServerKeyExchange.java:103) >>> >>> ???? at >>> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >>> ???? at >>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) >>> >>> ???? at >>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421) >>> >>> ???? at >>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178) >>> >>> ???? at >>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>> ???? at >>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >>> >>> ???? at >>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >>> >>> ???? at >>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >>> >>> ???? at >>> java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567) >>> >>> ???? at >>> java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) >>> >>> ???? at >>> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581) >>> >>> ???? at >>> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509) >>> >>> ???? at >>> java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245) >>> >>> ... >>> >>> This is consistently reproducible if, in the scheme of things: >>> >>> ??1. the cipher suite selected is a ECDHE one. For example >>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. The TLS version itself is >>> TLSv1.2 >>> (both server and client). >>> >>> ??2. One side of the client/server, is backed by BouncyCastle as the >>> security provider (very specifically for SignatureSpi). >>> >>> Assuming the server side is using BouncyCastle provider, what's >>> happening is that during the handshake, the server side uses the >>> RSASSA-PSS algorithm, backed by this provider and writes out the >>> signature. The client side uses SunRsaSign (default provider) and tries >>> to verify this RSASSA-PSS signature and fails with that above >>> exception. >>> FWIW, I don't believe the signature algorithm matters as long as the >>> cipher is ECDHE backed and the client and server side use a different >>> security provider. >>> >>> All this works perfectly fine when both the sides use the default >>> provider and bouncycastle isn't involved. >>> >>> I was able to get this reproducible in a very simple server/client >>> standalone program. I think this can even be demonstrated in a jtreg >>> test but I don't have enough experience with it to see how to trigger a >>> server in a separate JVM and then use a client for testing. The >>> reproducer code (Server.java and Client.java) is at the end of this >>> mail >>> along with instructions on how to reproduce it. >>> >>> I was also able to narrow down this issue down to a specific part of >>> the >>> JDK code. sun.security.ssl.SignatureScheme#getSignature[1] inits the >>> Signature instance for either signing or verifying. However it sets up >>> the signature parameters _after_ the init is done and in fact, there's >>> an explicit note[2] stating what/why it's doing it there. I admit, I >>> don't have much knowledge of the Java SSL parts and none in these >>> internal details and don't understand the details of that >>> implementation >>> notes. However, just to try it out, I switched the order of it by using >>> this local patch: >>> >>> diff -r fbb71a7edc1a >>> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java >>> --- >>> a/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java >>> Sat Aug 25 20:16:43 2018 +0530 >>> +++ >>> b/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java >>> Tue Sep 18 18:47:52 2018 +0530 >>> @@ -467,18 +467,16 @@ >>> ????????? } >>> ? ????????? Signature signer = JsseJce.getSignature(algorithm); >>> +??????? if (signAlgParameter != null) { >>> +??????????? signer.setParameter(signAlgParameter); >>> +??????? } >>> + >>> ????????? if (key instanceof PublicKey) { >>> ????????????? signer.initVerify((PublicKey)(key)); >>> ????????? } else { >>> ????????????? signer.initSign((PrivateKey)key); >>> ????????? } >>> ? -??????? // Important note:? Please don't set the parameters before >>> signature >>> -??????? // or verification initialization, so that the crypto >>> provider can >>> -??????? // be selected properly. >>> -??????? if (signAlgParameter != null) { >>> -??????????? signer.setParameter(signAlgParameter); >>> -??????? } >>> ? ????????? return signer; >>> ????? } >>> >>> Built this version and gave it a try with the sample code below (and >>> also against the actual application). Both worked fine. I tried cases: >>> >>> ??- where one side had default provider and other side had >>> bouncycastle. >>> >>> ??- where both sides were default provider >>> >>> >>> Any thoughts on this issue? Here's the code to reproduce it: >>> >>> Server.java >>> >>> ----------- >>> >>> import java.io.*; >>> import java.net.*; >>> import javax.net.ssl.*; >>> import java.util.*; >>> import java.util.concurrent.*; >>> import java.security.*; >>> import com.sun.net.httpserver.*; >>> import java.security.cert.*; >>> >>> >>> public class Server { >>> ???? private static final String keyFilename = "keystore"; >>> ???? private static final String keystorePass = "passphrase"; >>> ???? private static final String WEB_APP_CONTEXT = "/test"; >>> >>> ???? public static void main(final String[] args) throws Exception { >>> ???? ??? if (args.length == 1 && >>> args[0].equals("--use-bouncy-castle")) { >>> ???? ??? ??? // enable bouncycastle >>> ???? ??? ??? Security.insertProviderAt(new >>> org.bouncycastle.jce.provider.BouncyCastleProvider(), 2); >>> ???? ??? ??? System.out.println("Using bouncycastle provider"); >>> ???? ??? } else { >>> ???? ??? ??? System.out.println("Using JRE security provider"); >>> ???? ??? } >>> >>> ???? ??? final int port = 12345; >>> ???? ??? // start the server >>> ???????? final HttpsServer server = startServer("localhost", port); >>> ???????? // stop server on shutdown >>> ???????? Runtime.getRuntime().addShutdownHook(new Thread(() -> { >>> ???????? ??? if (server != null) { >>> ???????? ??? ??? server.stop(0); >>> ???? ??? ??? ??? System.out.println("Stopped server"); >>> ???????? ??? } >>> ???????? })); >>> ???? } >>> >>> ???? private static HttpsServer startServer(final String host, final >>> int >>> port) throws Exception { >>> ???????? final HttpsServer server = HttpsServer.create(new >>> InetSocketAddress(host, port), 0); >>> ???? ??? final Thread t = new Thread(() -> { >>> ???? ??? ??? try { >>> ???? ??? ??? ??? final SSLContext sslctx = >>> SSLContext.getInstance("TLSv1.2"); >>> ???? ??? ??????? final KeyManagerFactory kmf = >>> KeyManagerFactory.getInstance("SunX509"); >>> ???? ??? ??????? final KeyStore ks = KeyStore.getInstance("JKS"); >>> ???? ??? ??????? try (final FileInputStream fis = new >>> FileInputStream(keyFilename)) { >>> ???? ??? ??????????? ks.load(fis, keystorePass.toCharArray()); >>> ???? ??? ??????? } >>> ???? ??? ??????? kmf.init(ks, keystorePass.toCharArray()); >>> ???? ??? ??????? sslctx.init(kmf.getKeyManagers(), null, null); >>> ???? ??? ??????? final SSLParameters sslParameters = >>> sslctx.getDefaultSSLParameters(); >>> ???? ??? ??????? sslParameters.setProtocols(new String[] { "TLSv1.2" >>> }); >>> ???? ??? ??????? // use ECDHE specific ciphersuite >>> ???? ??? ??????? sslParameters.setCipherSuites(new String[] { >>> "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"}); >>> ???? ??? ??????? server.setHttpsConfigurator(new >>> HttpsConfigurator(sslctx) { >>> ???? ??? ??????? ??? @Override >>> ???? ??? ??????? ??? public void configure(final HttpsParameters >>> params) { >>> ???? ??? ??????? ??? ??? params.setSSLParameters(sslParameters); >>> ???? ??? ??????? ??? } >>> ???? ??? ??????? }); >>> ???? ??? ??????? server.createContext(WEB_APP_CONTEXT, (exchange)-> >>> exchange.sendResponseHeaders(200, -1)); >>> ???? ??? ??? ??? server.start(); >>> ???? ??? ??? ??? System.out.println("Started server at " + >>> server.getAddress()); >>> ???? ??? ??? } catch(Exception e) { >>> ???? ??? ??? ??? throw new RuntimeException(e); >>> ???? ??? ??? } >>> ???? ??? }); >>> ???? ??? t.start(); >>> ???? ??? return server; >>> ???? } >>> } >>> >>> To run this: >>> >>> (you'll need bouncycastle jar in your classpath. you can get it >>> from[3]) >>> >>> java -cp bcprov-jdk15on-1.58.jar Server.java --use-bouncy-castle >>> >>> You should see output like: >>> >>> Using bouncycastle provider >>> Started server at /127.0.0.1:12345 >>> >>> (not passing --use-bouncy-castle will start the server with the regular >>> default JRE provided security provider). >>> >>> The server is now up and running and ready to accept the request. See >>> how to run the client below. This server code uses a keystore file >>> which >>> is part of the OpenJDK repo and can be obtained from [4] and stored in >>> the current working directory. >>> >>> Client.java >>> >>> ------------ >>> >>> import java.io.*; >>> import java.net.*; >>> import javax.net.ssl.*; >>> import java.util.*; >>> import java.util.concurrent.*; >>> import java.security.*; >>> import com.sun.net.httpserver.*; >>> import java.security.cert.*; >>> >>> >>> public class Client { >>> ???? private static final String WEB_APP_CONTEXT = "/test"; >>> >>> ???? public static void main(final String[] args) throws Exception { >>> ???? ??? HttpsURLConnection.setDefaultHostnameVerifier((h, s) -> >>> {return >>> true;}); >>> ??????? ???? ??? final int port = 12345; >>> ???? ??? final URL targetURL = new URL("https://localhost:" + port + >>> WEB_APP_CONTEXT); >>> ???? ??? final HttpsURLConnection conn = (HttpsURLConnection) >>> targetURL.openConnection(); >>> ??????? ???? ??? // use a SSLSocketFactory which "trusts all" >>> ???? ??? final SSLContext sslctx = SSLContext.getInstance("TLSv1.2"); >>> ???????? sslctx.init(null, new TrustManager[] {new TrustAll()}, null); >>> ???? ??? conn.setSSLSocketFactory(sslctx.getSocketFactory()); >>> >>> ???? ??? // read >>> ???? ??? try (final InputStream is = conn.getInputStream()) { >>> ???? ??????? is.read(); >>> ???? ??? } >>> ???? ??? System.out.println("Received status code " + >>> conn.getResponseCode()); >>> ???? } >>> >>> ???? private static class TrustAll implements X509TrustManager { >>> >>> ???? ??? @Override >>> ???? ??? public void checkClientTrusted(X509Certificate[] chain, String >>> authType) throws CertificateException { >>> ???? ??? ??? return; >>> ???????? } >>> >>> ???? ??? @Override >>> ???? ??? public void checkServerTrusted(X509Certificate[] chain, String >>> authType) throws CertificateException { >>> ???? ??? ??? return; >>> ???? ??? } >>> >>> ???? ??? @Override >>> ???? ??? public X509Certificate[] getAcceptedIssuers() { >>> ???? ??? ??? return new X509Certificate[0]; >>> ???? ??? } >>> ???? } >>> } >>> >>> To run the client: >>> >>> java Client.java >>> >>> A successful execution will show: >>> >>> Received status code 200 >>> >>> whereas a failed execution should throw the exception shown previously >>> in the mail. >>> >>> [1] >>> http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l463 >>> >>> >>> [2] >>> http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l476 >>> >>> >>> [3] >>> http://repo1.maven.org/maven2/org/bouncycastle/bcprov-jdk15on/1.58/bcprov-jdk15on-1.58.jar >>> >>> >>> [4] >>> http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/test/jdk/javax/net/ssl/etc/keystore >>> >>> >>> -Jaikiran >>> >>> >>> >>> >>> >> From xuelei.fan at oracle.com Thu Sep 20 15:35:56 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 20 Sep 2018 08:35:56 -0700 Subject: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid ECDH ServerKeyExchange with non-default security provider In-Reply-To: References: <31ab966b-1f35-7cdd-3541-4b81e2d0bf01@gmail.com> <78b2ea15-82e1-57cd-49dc-d042323852b6@gmail.com> <75aa940a-33c9-1d13-ec84-1843631adb74@oracle.com> Message-ID: Thanks for the quick reply, Jaikiran! Per your diff code, it sounds like a crypto provider implementation bugs. JDK is using a lazy initialization so that the right provider get used. Third party's provider may not do this way. Would you please help to verify if the parameters get used in BouncyCastle if it is set after the init method? Thanks, Xuelei On 9/20/2018 8:22 AM, Jaikiran Pai wrote: > Hello Xuelei, > > It doesn't happen if both the server side and client side use the JDK > crypto provider. However if any one side uses a different crypto > provider (bouncycastle in this case) then it throws this exception. > > -Jaikiran > > > On 20/09/18 8:37 PM, Xuelei Fan wrote: >> Hi Jaikiran, >> >> Does it happen if using JDK crypto provider? >> >> Thanks, >> Xuelei >> >> On 9/20/2018 6:16 AM, Jaikiran Pai wrote: >>> Just checking - does this look like a genuine issue? Anything else I can >>> provide to help reproduce this? >>> >>> -Jaikiran >>> >>> >>> On 18/09/18 7:06 PM, Jaikiran Pai wrote: >>>> I have been testing some projects that I know of, with Java 11 RC. >>>> There's one specific test that has been failing for me, for a while >>>> now, >>>> during SSL handshake. Took me a while to narrow it down given the size >>>> of the application and the nature of the exception. The exception >>>> occurs >>>> during SSL handshake between a client and a server (both Java and both >>>> using Java 11 RC) and it kept throwing: >>>> >>>> Exception in thread "main" javax.net.ssl.SSLHandshakeException: Invalid >>>> ECDH ServerKeyExchange signature >>>> ???? at >>>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>>> ???? at >>>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>> ???? at >>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>>> >>>> ???? at >>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) >>>> >>>> ???? at >>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) >>>> >>>> ???? at >>>> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.(ECDHServerKeyExchange.java:329) >>>> >>>> ???? at >>>> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeConsumer.consume(ECDHServerKeyExchange.java:535) >>>> >>>> ???? at >>>> java.base/sun.security.ssl.ServerKeyExchange$ServerKeyExchangeConsumer.consume(ServerKeyExchange.java:103) >>>> >>>> ???? at >>>> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >>>> ???? at >>>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) >>>> >>>> ???? at >>>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421) >>>> >>>> ???? at >>>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178) >>>> >>>> ???? at >>>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>>> ???? at >>>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >>>> >>>> ???? at >>>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >>>> >>>> ???? at >>>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >>>> >>>> ???? at >>>> java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567) >>>> >>>> ???? at >>>> java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) >>>> >>>> ???? at >>>> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581) >>>> >>>> ???? at >>>> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509) >>>> >>>> ???? at >>>> java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245) >>>> >>>> ... >>>> >>>> This is consistently reproducible if, in the scheme of things: >>>> >>>> ??1. the cipher suite selected is a ECDHE one. For example >>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. The TLS version itself is >>>> TLSv1.2 >>>> (both server and client). >>>> >>>> ??2. One side of the client/server, is backed by BouncyCastle as the >>>> security provider (very specifically for SignatureSpi). >>>> >>>> Assuming the server side is using BouncyCastle provider, what's >>>> happening is that during the handshake, the server side uses the >>>> RSASSA-PSS algorithm, backed by this provider and writes out the >>>> signature. The client side uses SunRsaSign (default provider) and tries >>>> to verify this RSASSA-PSS signature and fails with that above >>>> exception. >>>> FWIW, I don't believe the signature algorithm matters as long as the >>>> cipher is ECDHE backed and the client and server side use a different >>>> security provider. >>>> >>>> All this works perfectly fine when both the sides use the default >>>> provider and bouncycastle isn't involved. >>>> >>>> I was able to get this reproducible in a very simple server/client >>>> standalone program. I think this can even be demonstrated in a jtreg >>>> test but I don't have enough experience with it to see how to trigger a >>>> server in a separate JVM and then use a client for testing. The >>>> reproducer code (Server.java and Client.java) is at the end of this >>>> mail >>>> along with instructions on how to reproduce it. >>>> >>>> I was also able to narrow down this issue down to a specific part of >>>> the >>>> JDK code. sun.security.ssl.SignatureScheme#getSignature[1] inits the >>>> Signature instance for either signing or verifying. However it sets up >>>> the signature parameters _after_ the init is done and in fact, there's >>>> an explicit note[2] stating what/why it's doing it there. I admit, I >>>> don't have much knowledge of the Java SSL parts and none in these >>>> internal details and don't understand the details of that >>>> implementation >>>> notes. However, just to try it out, I switched the order of it by using >>>> this local patch: >>>> >>>> diff -r fbb71a7edc1a >>>> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java >>>> --- >>>> a/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java >>>> Sat Aug 25 20:16:43 2018 +0530 >>>> +++ >>>> b/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java >>>> Tue Sep 18 18:47:52 2018 +0530 >>>> @@ -467,18 +467,16 @@ >>>> ????????? } >>>> ? ????????? Signature signer = JsseJce.getSignature(algorithm); >>>> +??????? if (signAlgParameter != null) { >>>> +??????????? signer.setParameter(signAlgParameter); >>>> +??????? } >>>> + >>>> ????????? if (key instanceof PublicKey) { >>>> ????????????? signer.initVerify((PublicKey)(key)); >>>> ????????? } else { >>>> ????????????? signer.initSign((PrivateKey)key); >>>> ????????? } >>>> ? -??????? // Important note:? Please don't set the parameters before >>>> signature >>>> -??????? // or verification initialization, so that the crypto >>>> provider can >>>> -??????? // be selected properly. >>>> -??????? if (signAlgParameter != null) { >>>> -??????????? signer.setParameter(signAlgParameter); >>>> -??????? } >>>> ? ????????? return signer; >>>> ????? } >>>> >>>> Built this version and gave it a try with the sample code below (and >>>> also against the actual application). Both worked fine. I tried cases: >>>> >>>> ??- where one side had default provider and other side had >>>> bouncycastle. >>>> >>>> ??- where both sides were default provider >>>> >>>> >>>> Any thoughts on this issue? Here's the code to reproduce it: >>>> >>>> Server.java >>>> >>>> ----------- >>>> >>>> import java.io.*; >>>> import java.net.*; >>>> import javax.net.ssl.*; >>>> import java.util.*; >>>> import java.util.concurrent.*; >>>> import java.security.*; >>>> import com.sun.net.httpserver.*; >>>> import java.security.cert.*; >>>> >>>> >>>> public class Server { >>>> ???? private static final String keyFilename = "keystore"; >>>> ???? private static final String keystorePass = "passphrase"; >>>> ???? private static final String WEB_APP_CONTEXT = "/test"; >>>> >>>> ???? public static void main(final String[] args) throws Exception { >>>> ???? ??? if (args.length == 1 && >>>> args[0].equals("--use-bouncy-castle")) { >>>> ???? ??? ??? // enable bouncycastle >>>> ???? ??? ??? Security.insertProviderAt(new >>>> org.bouncycastle.jce.provider.BouncyCastleProvider(), 2); >>>> ???? ??? ??? System.out.println("Using bouncycastle provider"); >>>> ???? ??? } else { >>>> ???? ??? ??? System.out.println("Using JRE security provider"); >>>> ???? ??? } >>>> >>>> ???? ??? final int port = 12345; >>>> ???? ??? // start the server >>>> ???????? final HttpsServer server = startServer("localhost", port); >>>> ???????? // stop server on shutdown >>>> ???????? Runtime.getRuntime().addShutdownHook(new Thread(() -> { >>>> ???????? ??? if (server != null) { >>>> ???????? ??? ??? server.stop(0); >>>> ???? ??? ??? ??? System.out.println("Stopped server"); >>>> ???????? ??? } >>>> ???????? })); >>>> ???? } >>>> >>>> ???? private static HttpsServer startServer(final String host, final >>>> int >>>> port) throws Exception { >>>> ???????? final HttpsServer server = HttpsServer.create(new >>>> InetSocketAddress(host, port), 0); >>>> ???? ??? final Thread t = new Thread(() -> { >>>> ???? ??? ??? try { >>>> ???? ??? ??? ??? final SSLContext sslctx = >>>> SSLContext.getInstance("TLSv1.2"); >>>> ???? ??? ??????? final KeyManagerFactory kmf = >>>> KeyManagerFactory.getInstance("SunX509"); >>>> ???? ??? ??????? final KeyStore ks = KeyStore.getInstance("JKS"); >>>> ???? ??? ??????? try (final FileInputStream fis = new >>>> FileInputStream(keyFilename)) { >>>> ???? ??? ??????????? ks.load(fis, keystorePass.toCharArray()); >>>> ???? ??? ??????? } >>>> ???? ??? ??????? kmf.init(ks, keystorePass.toCharArray()); >>>> ???? ??? ??????? sslctx.init(kmf.getKeyManagers(), null, null); >>>> ???? ??? ??????? final SSLParameters sslParameters = >>>> sslctx.getDefaultSSLParameters(); >>>> ???? ??? ??????? sslParameters.setProtocols(new String[] { "TLSv1.2" >>>> }); >>>> ???? ??? ??????? // use ECDHE specific ciphersuite >>>> ???? ??? ??????? sslParameters.setCipherSuites(new String[] { >>>> "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"}); >>>> ???? ??? ??????? server.setHttpsConfigurator(new >>>> HttpsConfigurator(sslctx) { >>>> ???? ??? ??????? ??? @Override >>>> ???? ??? ??????? ??? public void configure(final HttpsParameters >>>> params) { >>>> ???? ??? ??????? ??? ??? params.setSSLParameters(sslParameters); >>>> ???? ??? ??????? ??? } >>>> ???? ??? ??????? }); >>>> ???? ??? ??????? server.createContext(WEB_APP_CONTEXT, (exchange)-> >>>> exchange.sendResponseHeaders(200, -1)); >>>> ???? ??? ??? ??? server.start(); >>>> ???? ??? ??? ??? System.out.println("Started server at " + >>>> server.getAddress()); >>>> ???? ??? ??? } catch(Exception e) { >>>> ???? ??? ??? ??? throw new RuntimeException(e); >>>> ???? ??? ??? } >>>> ???? ??? }); >>>> ???? ??? t.start(); >>>> ???? ??? return server; >>>> ???? } >>>> } >>>> >>>> To run this: >>>> >>>> (you'll need bouncycastle jar in your classpath. you can get it >>>> from[3]) >>>> >>>> java -cp bcprov-jdk15on-1.58.jar Server.java --use-bouncy-castle >>>> >>>> You should see output like: >>>> >>>> Using bouncycastle provider >>>> Started server at /127.0.0.1:12345 >>>> >>>> (not passing --use-bouncy-castle will start the server with the regular >>>> default JRE provided security provider). >>>> >>>> The server is now up and running and ready to accept the request. See >>>> how to run the client below. This server code uses a keystore file >>>> which >>>> is part of the OpenJDK repo and can be obtained from [4] and stored in >>>> the current working directory. >>>> >>>> Client.java >>>> >>>> ------------ >>>> >>>> import java.io.*; >>>> import java.net.*; >>>> import javax.net.ssl.*; >>>> import java.util.*; >>>> import java.util.concurrent.*; >>>> import java.security.*; >>>> import com.sun.net.httpserver.*; >>>> import java.security.cert.*; >>>> >>>> >>>> public class Client { >>>> ???? private static final String WEB_APP_CONTEXT = "/test"; >>>> >>>> ???? public static void main(final String[] args) throws Exception { >>>> ???? ??? HttpsURLConnection.setDefaultHostnameVerifier((h, s) -> >>>> {return >>>> true;}); >>>> ??????? ???? ??? final int port = 12345; >>>> ???? ??? final URL targetURL = new URL("https://localhost:" + port + >>>> WEB_APP_CONTEXT); >>>> ???? ??? final HttpsURLConnection conn = (HttpsURLConnection) >>>> targetURL.openConnection(); >>>> ??????? ???? ??? // use a SSLSocketFactory which "trusts all" >>>> ???? ??? final SSLContext sslctx = SSLContext.getInstance("TLSv1.2"); >>>> ???????? sslctx.init(null, new TrustManager[] {new TrustAll()}, null); >>>> ???? ??? conn.setSSLSocketFactory(sslctx.getSocketFactory()); >>>> >>>> ???? ??? // read >>>> ???? ??? try (final InputStream is = conn.getInputStream()) { >>>> ???? ??????? is.read(); >>>> ???? ??? } >>>> ???? ??? System.out.println("Received status code " + >>>> conn.getResponseCode()); >>>> ???? } >>>> >>>> ???? private static class TrustAll implements X509TrustManager { >>>> >>>> ???? ??? @Override >>>> ???? ??? public void checkClientTrusted(X509Certificate[] chain, String >>>> authType) throws CertificateException { >>>> ???? ??? ??? return; >>>> ???????? } >>>> >>>> ???? ??? @Override >>>> ???? ??? public void checkServerTrusted(X509Certificate[] chain, String >>>> authType) throws CertificateException { >>>> ???? ??? ??? return; >>>> ???? ??? } >>>> >>>> ???? ??? @Override >>>> ???? ??? public X509Certificate[] getAcceptedIssuers() { >>>> ???? ??? ??? return new X509Certificate[0]; >>>> ???? ??? } >>>> ???? } >>>> } >>>> >>>> To run the client: >>>> >>>> java Client.java >>>> >>>> A successful execution will show: >>>> >>>> Received status code 200 >>>> >>>> whereas a failed execution should throw the exception shown previously >>>> in the mail. >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l463 >>>> >>>> >>>> [2] >>>> http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l476 >>>> >>>> >>>> [3] >>>> http://repo1.maven.org/maven2/org/bouncycastle/bcprov-jdk15on/1.58/bcprov-jdk15on-1.58.jar >>>> >>>> >>>> [4] >>>> http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/test/jdk/javax/net/ssl/etc/keystore >>>> >>>> >>>> -Jaikiran >>>> >>>> >>>> >>>> >>>> >>> > From jai.forums2013 at gmail.com Thu Sep 20 15:46:05 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 20 Sep 2018 21:16:05 +0530 Subject: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid ECDH ServerKeyExchange with non-default security provider In-Reply-To: References: <31ab966b-1f35-7cdd-3541-4b81e2d0bf01@gmail.com> <78b2ea15-82e1-57cd-49dc-d042323852b6@gmail.com> <75aa940a-33c9-1d13-ec84-1843631adb74@oracle.com> Message-ID: <1c78066a-2415-ebb1-a9bc-f573a861988b@gmail.com> Sure, I'll run some tests tomorrow and get more details on whether/how bouncycastle uses these parameters if they are set after the init verify/sign calls. -Jaikiran On 20/09/18 9:05 PM, Xuelei Fan wrote: > Thanks for the quick reply, Jaikiran! > > Per your diff code, it sounds like a crypto provider implementation > bugs.? JDK is using a lazy initialization so that the right provider > get used.? Third party's provider may not do this way.?? Would you > please help to verify if the parameters get used in BouncyCastle if it > is set after the init method? > > Thanks, > Xuelei > > On 9/20/2018 8:22 AM, Jaikiran Pai wrote: >> Hello Xuelei, >> >> It doesn't happen if both the server side and client side use the JDK >> crypto provider. However if any one side uses a different crypto >> provider (bouncycastle in this case) then it throws this exception. >> >> -Jaikiran >> >> >> On 20/09/18 8:37 PM, Xuelei Fan wrote: >>> Hi Jaikiran, >>> >>> Does it happen if using JDK crypto provider? >>> >>> Thanks, >>> Xuelei >>> >>> On 9/20/2018 6:16 AM, Jaikiran Pai wrote: >>>> Just checking - does this look like a genuine issue? Anything else >>>> I can >>>> provide to help reproduce this? >>>> >>>> -Jaikiran >>>> >>>> >>>> On 18/09/18 7:06 PM, Jaikiran Pai wrote: >>>>> I have been testing some projects that I know of, with Java 11 RC. >>>>> There's one specific test that has been failing for me, for a while >>>>> now, >>>>> during SSL handshake. Took me a while to narrow it down given the >>>>> size >>>>> of the application and the nature of the exception. The exception >>>>> occurs >>>>> during SSL handshake between a client and a server (both Java and >>>>> both >>>>> using Java 11 RC) and it kept throwing: >>>>> >>>>> Exception in thread "main" javax.net.ssl.SSLHandshakeException: >>>>> Invalid >>>>> ECDH ServerKeyExchange signature >>>>> ????? at >>>>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>>>> ????? at >>>>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>>> ????? at >>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeMessage.(ECDHServerKeyExchange.java:329) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.security.ssl.ECDHServerKeyExchange$ECDHServerKeyExchangeConsumer.consume(ECDHServerKeyExchange.java:535) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.security.ssl.ServerKeyExchange$ServerKeyExchangeConsumer.consume(ServerKeyExchange.java:103) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) >>>>> >>>>> ????? at >>>>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>>>> ????? at >>>>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509) >>>>> >>>>> >>>>> ????? at >>>>> java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245) >>>>> >>>>> >>>>> ... >>>>> >>>>> This is consistently reproducible if, in the scheme of things: >>>>> >>>>> ???1. the cipher suite selected is a ECDHE one. For example >>>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. The TLS version itself is >>>>> TLSv1.2 >>>>> (both server and client). >>>>> >>>>> ???2. One side of the client/server, is backed by BouncyCastle as the >>>>> security provider (very specifically for SignatureSpi). >>>>> >>>>> Assuming the server side is using BouncyCastle provider, what's >>>>> happening is that during the handshake, the server side uses the >>>>> RSASSA-PSS algorithm, backed by this provider and writes out the >>>>> signature. The client side uses SunRsaSign (default provider) and >>>>> tries >>>>> to verify this RSASSA-PSS signature and fails with that above >>>>> exception. >>>>> FWIW, I don't believe the signature algorithm matters as long as the >>>>> cipher is ECDHE backed and the client and server side use a different >>>>> security provider. >>>>> >>>>> All this works perfectly fine when both the sides use the default >>>>> provider and bouncycastle isn't involved. >>>>> >>>>> I was able to get this reproducible in a very simple server/client >>>>> standalone program. I think this can even be demonstrated in a jtreg >>>>> test but I don't have enough experience with it to see how to >>>>> trigger a >>>>> server in a separate JVM and then use a client for testing. The >>>>> reproducer code (Server.java and Client.java) is at the end of this >>>>> mail >>>>> along with instructions on how to reproduce it. >>>>> >>>>> I was also able to narrow down this issue down to a specific part of >>>>> the >>>>> JDK code. sun.security.ssl.SignatureScheme#getSignature[1] inits the >>>>> Signature instance for either signing or verifying. However it >>>>> sets up >>>>> the signature parameters _after_ the init is done and in fact, >>>>> there's >>>>> an explicit note[2] stating what/why it's doing it there. I admit, I >>>>> don't have much knowledge of the Java SSL parts and none in these >>>>> internal details and don't understand the details of that >>>>> implementation >>>>> notes. However, just to try it out, I switched the order of it by >>>>> using >>>>> this local patch: >>>>> >>>>> diff -r fbb71a7edc1a >>>>> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java >>>>> --- >>>>> a/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java >>>>> Sat Aug 25 20:16:43 2018 +0530 >>>>> +++ >>>>> b/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java >>>>> Tue Sep 18 18:47:52 2018 +0530 >>>>> @@ -467,18 +467,16 @@ >>>>> ?????????? } >>>>> ?? ????????? Signature signer = JsseJce.getSignature(algorithm); >>>>> +??????? if (signAlgParameter != null) { >>>>> +??????????? signer.setParameter(signAlgParameter); >>>>> +??????? } >>>>> + >>>>> ?????????? if (key instanceof PublicKey) { >>>>> ?????????????? signer.initVerify((PublicKey)(key)); >>>>> ?????????? } else { >>>>> ?????????????? signer.initSign((PrivateKey)key); >>>>> ?????????? } >>>>> ?? -??????? // Important note:? Please don't set the parameters >>>>> before >>>>> signature >>>>> -??????? // or verification initialization, so that the crypto >>>>> provider can >>>>> -??????? // be selected properly. >>>>> -??????? if (signAlgParameter != null) { >>>>> -??????????? signer.setParameter(signAlgParameter); >>>>> -??????? } >>>>> ?? ????????? return signer; >>>>> ?????? } >>>>> >>>>> Built this version and gave it a try with the sample code below (and >>>>> also against the actual application). Both worked fine. I tried >>>>> cases: >>>>> >>>>> ???- where one side had default provider and other side had >>>>> bouncycastle. >>>>> >>>>> ???- where both sides were default provider >>>>> >>>>> >>>>> Any thoughts on this issue? Here's the code to reproduce it: >>>>> >>>>> Server.java >>>>> >>>>> ----------- >>>>> >>>>> import java.io.*; >>>>> import java.net.*; >>>>> import javax.net.ssl.*; >>>>> import java.util.*; >>>>> import java.util.concurrent.*; >>>>> import java.security.*; >>>>> import com.sun.net.httpserver.*; >>>>> import java.security.cert.*; >>>>> >>>>> >>>>> public class Server { >>>>> ????? private static final String keyFilename = "keystore"; >>>>> ????? private static final String keystorePass = "passphrase"; >>>>> ????? private static final String WEB_APP_CONTEXT = "/test"; >>>>> >>>>> ????? public static void main(final String[] args) throws Exception { >>>>> ????? ??? if (args.length == 1 && >>>>> args[0].equals("--use-bouncy-castle")) { >>>>> ????? ??? ??? // enable bouncycastle >>>>> ????? ??? ??? Security.insertProviderAt(new >>>>> org.bouncycastle.jce.provider.BouncyCastleProvider(), 2); >>>>> ????? ??? ??? System.out.println("Using bouncycastle provider"); >>>>> ????? ??? } else { >>>>> ????? ??? ??? System.out.println("Using JRE security provider"); >>>>> ????? ??? } >>>>> >>>>> ????? ??? final int port = 12345; >>>>> ????? ??? // start the server >>>>> ????????? final HttpsServer server = startServer("localhost", port); >>>>> ????????? // stop server on shutdown >>>>> ????????? Runtime.getRuntime().addShutdownHook(new Thread(() -> { >>>>> ????????? ??? if (server != null) { >>>>> ????????? ??? ??? server.stop(0); >>>>> ????? ??? ??? ??? System.out.println("Stopped server"); >>>>> ????????? ??? } >>>>> ????????? })); >>>>> ????? } >>>>> >>>>> ????? private static HttpsServer startServer(final String host, final >>>>> int >>>>> port) throws Exception { >>>>> ????????? final HttpsServer server = HttpsServer.create(new >>>>> InetSocketAddress(host, port), 0); >>>>> ????? ??? final Thread t = new Thread(() -> { >>>>> ????? ??? ??? try { >>>>> ????? ??? ??? ??? final SSLContext sslctx = >>>>> SSLContext.getInstance("TLSv1.2"); >>>>> ????? ??? ??????? final KeyManagerFactory kmf = >>>>> KeyManagerFactory.getInstance("SunX509"); >>>>> ????? ??? ??????? final KeyStore ks = KeyStore.getInstance("JKS"); >>>>> ????? ??? ??????? try (final FileInputStream fis = new >>>>> FileInputStream(keyFilename)) { >>>>> ????? ??? ??????????? ks.load(fis, keystorePass.toCharArray()); >>>>> ????? ??? ??????? } >>>>> ????? ??? ??????? kmf.init(ks, keystorePass.toCharArray()); >>>>> ????? ??? ??????? sslctx.init(kmf.getKeyManagers(), null, null); >>>>> ????? ??? ??????? final SSLParameters sslParameters = >>>>> sslctx.getDefaultSSLParameters(); >>>>> ????? ??? ??????? sslParameters.setProtocols(new String[] { "TLSv1.2" >>>>> }); >>>>> ????? ??? ??????? // use ECDHE specific ciphersuite >>>>> ????? ??? ??????? sslParameters.setCipherSuites(new String[] { >>>>> "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"}); >>>>> ????? ??? ??????? server.setHttpsConfigurator(new >>>>> HttpsConfigurator(sslctx) { >>>>> ????? ??? ??????? ??? @Override >>>>> ????? ??? ??????? ??? public void configure(final HttpsParameters >>>>> params) { >>>>> ????? ??? ??????? ??? ??? params.setSSLParameters(sslParameters); >>>>> ????? ??? ??????? ??? } >>>>> ????? ??? ??????? }); >>>>> ????? ??? ??????? server.createContext(WEB_APP_CONTEXT, (exchange)-> >>>>> exchange.sendResponseHeaders(200, -1)); >>>>> ????? ??? ??? ??? server.start(); >>>>> ????? ??? ??? ??? System.out.println("Started server at " + >>>>> server.getAddress()); >>>>> ????? ??? ??? } catch(Exception e) { >>>>> ????? ??? ??? ??? throw new RuntimeException(e); >>>>> ????? ??? ??? } >>>>> ????? ??? }); >>>>> ????? ??? t.start(); >>>>> ????? ??? return server; >>>>> ????? } >>>>> } >>>>> >>>>> To run this: >>>>> >>>>> (you'll need bouncycastle jar in your classpath. you can get it >>>>> from[3]) >>>>> >>>>> java -cp bcprov-jdk15on-1.58.jar Server.java --use-bouncy-castle >>>>> >>>>> You should see output like: >>>>> >>>>> Using bouncycastle provider >>>>> Started server at /127.0.0.1:12345 >>>>> >>>>> (not passing --use-bouncy-castle will start the server with the >>>>> regular >>>>> default JRE provided security provider). >>>>> >>>>> The server is now up and running and ready to accept the request. See >>>>> how to run the client below. This server code uses a keystore file >>>>> which >>>>> is part of the OpenJDK repo and can be obtained from [4] and >>>>> stored in >>>>> the current working directory. >>>>> >>>>> Client.java >>>>> >>>>> ------------ >>>>> >>>>> import java.io.*; >>>>> import java.net.*; >>>>> import javax.net.ssl.*; >>>>> import java.util.*; >>>>> import java.util.concurrent.*; >>>>> import java.security.*; >>>>> import com.sun.net.httpserver.*; >>>>> import java.security.cert.*; >>>>> >>>>> >>>>> public class Client { >>>>> ????? private static final String WEB_APP_CONTEXT = "/test"; >>>>> >>>>> ????? public static void main(final String[] args) throws Exception { >>>>> ????? ??? HttpsURLConnection.setDefaultHostnameVerifier((h, s) -> >>>>> {return >>>>> true;}); >>>>> ???????? ???? ??? final int port = 12345; >>>>> ????? ??? final URL targetURL = new URL("https://localhost:" + port + >>>>> WEB_APP_CONTEXT); >>>>> ????? ??? final HttpsURLConnection conn = (HttpsURLConnection) >>>>> targetURL.openConnection(); >>>>> ???????? ???? ??? // use a SSLSocketFactory which "trusts all" >>>>> ????? ??? final SSLContext sslctx = >>>>> SSLContext.getInstance("TLSv1.2"); >>>>> ????????? sslctx.init(null, new TrustManager[] {new TrustAll()}, >>>>> null); >>>>> ????? ??? conn.setSSLSocketFactory(sslctx.getSocketFactory()); >>>>> >>>>> ????? ??? // read >>>>> ????? ??? try (final InputStream is = conn.getInputStream()) { >>>>> ????? ??????? is.read(); >>>>> ????? ??? } >>>>> ????? ??? System.out.println("Received status code " + >>>>> conn.getResponseCode()); >>>>> ????? } >>>>> >>>>> ????? private static class TrustAll implements X509TrustManager { >>>>> >>>>> ????? ??? @Override >>>>> ????? ??? public void checkClientTrusted(X509Certificate[] chain, >>>>> String >>>>> authType) throws CertificateException { >>>>> ????? ??? ??? return; >>>>> ????????? } >>>>> >>>>> ????? ??? @Override >>>>> ????? ??? public void checkServerTrusted(X509Certificate[] chain, >>>>> String >>>>> authType) throws CertificateException { >>>>> ????? ??? ??? return; >>>>> ????? ??? } >>>>> >>>>> ????? ??? @Override >>>>> ????? ??? public X509Certificate[] getAcceptedIssuers() { >>>>> ????? ??? ??? return new X509Certificate[0]; >>>>> ????? ??? } >>>>> ????? } >>>>> } >>>>> >>>>> To run the client: >>>>> >>>>> java Client.java >>>>> >>>>> A successful execution will show: >>>>> >>>>> Received status code 200 >>>>> >>>>> whereas a failed execution should throw the exception shown >>>>> previously >>>>> in the mail. >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l463 >>>>> >>>>> >>>>> >>>>> [2] >>>>> http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l476 >>>>> >>>>> >>>>> >>>>> [3] >>>>> http://repo1.maven.org/maven2/org/bouncycastle/bcprov-jdk15on/1.58/bcprov-jdk15on-1.58.jar >>>>> >>>>> >>>>> >>>>> [4] >>>>> http://hg.openjdk.java.net/jdk/jdk/file/fbec908e2783/test/jdk/javax/net/ssl/etc/keystore >>>>> >>>>> >>>>> >>>>> -Jaikiran >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >> From bradford.wetmore at oracle.com Thu Sep 20 18:30:09 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 20 Sep 2018 11:30:09 -0700 Subject: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: <9f43f386-ede9-3615-df30-19e0a851b991@oracle.com> References: <32bad254-1a8c-7933-d5a0-0b8ce3ed2f68@oracle.com> <05EF82F5-6506-4928-8030-B9BEEE64E1F1@googlemail.com> <0EB21A4C-7DFF-4878-9446-182DA35F0A8C@googlemail.com> <2dea4403-e019-613d-373e-75c789029cef@oracle.com> <422BC150-FBAE-4829-B375-637F27C671C4@googlemail.com> <499D9F15-3CF1-4FDC-80AB-5A73FCB744FD@googlemail.com> <9f43f386-ede9-3615-df30-19e0a851b991@oracle.com> Message-ID: <57cf1167-e988-0f37-a721-fe7a3918e4ec@oracle.com> Just to followup on your (Norman's) earlier question: On 9/19/2018, Norman wrote: >> Is this just the >> initial version set or do you not plan to fix it in Java11 ? and On 9/19/2018 9:34 AM, Xuelei Fan wrote: > It is just a initial version set. Getting this fix into JDK 12 was easy as 12 is in the early development stages. However, the GA release of JDK 11 is very close now and the bar is high for any changes. That said, we are currently looking into which JDK 11 update release would be appropriate for this and a couple of other needed fixes. Hope this helps. Brad On 9/19/2018 9:34 AM, Xuelei Fan wrote: > Hi Norman, > > It is just a initial version set. > > Thanks, > Xuelei > > On 9/19/2018 8:49 AM, Norman Maurer wrote: >> I see this is now tracked as >> https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8210846?filter=allopenissues?:) >> >> >> Just one question, I saw it list 12 as fix version. Is this just the >> initial version set or do you not plan to fix it in Java11 ? IMHO this >> is a quite an important thing to fix as otherwise you may run into >> issues when using SSL on the client-side as most real-world apps use >> OpenSSL on the server-side. >> >> Bye >> Norman >> >> >>> On 17. Sep 2018, at 10:44, Norman Maurer >>> > >>> wrote: >>> >>> Of course not? >>> >>> ID: 9057280 >>> >>> Thanks >>> Norman >>> >>> >>>> On 17. Sep 2018, at 19:35, Xuelei Fan >>> > wrote: >>>> >>>> Hi Norman, >>>> >>>> Thank you so much for the reproducing code. ?Would you mind file a >>>> bug for this issue? >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 9/17/2018 3:39 AM, Norman Maurer wrote: >>>>> Hi all, >>>>> As requested I pushed a pure JDK reproducer to GitHub which you can >>>>> easily use to reproduce the problem. All the details how to run it >>>>> etc are in the README.md file. I also included a server to show >>>>> that all works if we use the JDK on the client side and server side. >>>>> Also as stated before you will see that the cert will be send even >>>>> if you use OpenSSL on the serverside if you replace ?-Verify 1? >>>>> with ?-verify 1? (which is kind of the same as >>>>> setWantClientAuth(true)). >>>>> Please don't hesitate to ping me if you need any more details or >>>>> have any more questions. >>>>> https://github.com/normanmaurer/jdktls13bugreproducer >>>>> Here is the output with debugging enabled on the client side. >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.515 >>>>> CEST|SSLContextImpl.java:427|System property >>>>> jdk.tls.client.cipherSuites is set to 'null' >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.529 >>>>> CEST|SSLContextImpl.java:427|System property >>>>> jdk.tls.server.cipherSuites is set to 'null' >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.563 >>>>> CEST|SSLCipher.java:437|jdk.tls.keyLimits: ?entry = >>>>> AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = >>>>> 137438953472 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.577 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.577 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.580 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.580 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_RC4_128_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_RC4_128_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDHE_RSA_WITH_RC4_128_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_RSA_WITH_RC4_128_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_RSA_WITH_RC4_128_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_RSA_WITH_RC4_128_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_RC4_128_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_RC4_128_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDH_RSA_WITH_RC4_128_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDH_RSA_WITH_RC4_128_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_RSA_WITH_RC4_128_MD5 >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_RSA_WITH_RC4_128_MD5 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDH_anon_WITH_RC4_128_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDH_anon_WITH_RC4_128_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DH_anon_WITH_RC4_128_MD5 >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DH_anon_WITH_RC4_128_MD5 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_RSA_EXPORT_WITH_RC4_40_MD5 >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_RSA_EXPORT_WITH_RC4_40_MD5 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.591 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.593 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.593 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.599 >>>>> CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: >>>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.599 >>>>> CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: >>>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.642 >>>>> CEST|SunX509KeyManagerImpl.java:164|found key for : 1 ( >>>>> "certificate" : { >>>>> "version" ? ? ? ? ? ?: "v3", >>>>> "serial number" ? ? ?: "20 C3 8D C4 49 66 D0 02", >>>>> "signature algorithm": "SHA256withRSA", >>>>> "issuer" ? ? ? ? ? ? : >>>>> "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>>>> "not before" ? ? ? ? : "2013-08-02 09:51:36.000 CEST", >>>>> "not ?after" ? ? ? ? : "10000-01-01 24:59:59.000 CET", >>>>> "subject" ? ? ? ? ? ?: >>>>> "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>>>> "subject public key" : "RSA"} >>>>> ) >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 >>>>> CEST|SSLContextImpl.java:115|trigger seeding of SecureRandom >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 >>>>> CEST|SSLContextImpl.java:119|done seeding of SecureRandom >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.665 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_AES_128_GCM_SHA256 for TLS12 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.666 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_AES_256_GCM_SHA384 for TLS12 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_AES_128_GCM_SHA256 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_AES_256_GCM_SHA384 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS11 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_AES_128_GCM_SHA256 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_AES_256_GCM_SHA384 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS10 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 >>>>> CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: >>>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS10 >>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.690 >>>>> CEST|ServerNameExtension.java:255|Unable to indicate server name >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.690 >>>>> CEST|SSLExtensions.java:235|Ignore, context unavailable extension: >>>>> server_name >>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.701 >>>>> CEST|SignatureScheme.java:282|Signature algorithm, ed25519, is not >>>>> supported by the underlying providers >>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.702 >>>>> CEST|SignatureScheme.java:282|Signature algorithm, ed448, is not >>>>> supported by the underlying providers >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.706 >>>>> CEST|SignatureScheme.java:358|Ignore disabled signature sheme: rsa_md5 >>>>> javax.net.ssl|INFO|01|main|2018-09-17 11:51:54.706 >>>>> CEST|AlpnExtension.java:161|No available application protocols >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.706 >>>>> CEST|SSLExtensions.java:235|Ignore, context unavailable extension: >>>>> application_layer_protocol_negotiation >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.707 >>>>> CEST|SSLExtensions.java:235|Ignore, context unavailable extension: >>>>> cookie >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 >>>>> CEST|SSLExtensions.java:235|Ignore, context unavailable extension: >>>>> renegotiation_info >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 >>>>> CEST|PreSharedKeyExtension.java:606|No session to resume. >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 >>>>> CEST|SSLExtensions.java:235|Ignore, context unavailable extension: >>>>> pre_shared_key >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 >>>>> CEST|ClientHello.java:633|Produced ClientHello handshake message ( >>>>> "ClientHello": { >>>>> "client version" ? ? ?: "TLSv1.2", >>>>> "random" ? ? ? ? ? ? ?: "66 2E BE D3 8A 77 39 06 3B 5A 34 03 7D EE >>>>> 74 BB 08 D2 19 FD 50 17 2D 84 29 AA FB E0 EE ED 50 69", >>>>> "session id" ? ? ? ? ?: "0B 03 C8 E2 D2 A5 CD 3A 22 C5 85 17 06 64 >>>>> A9 30 14 62 C0 AF AB 67 CE 63 50 41 50 7F 6B FD 4C 9F", >>>>> "cipher suites" ? ? ? : "[TLS_AES_128_GCM_SHA256(0x1301), >>>>> TLS_AES_256_GCM_SHA384(0x1302), >>>>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), >>>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), >>>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), >>>>> TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), >>>>> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), >>>>> TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), >>>>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), >>>>> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), >>>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), >>>>> TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), >>>>> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), >>>>> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), >>>>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), >>>>> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), >>>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), >>>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), >>>>> TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), >>>>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), >>>>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), >>>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), >>>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), >>>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), >>>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), >>>>> TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), >>>>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), >>>>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), >>>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), >>>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), >>>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), >>>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), >>>>> TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), >>>>> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), >>>>> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), >>>>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), >>>>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), >>>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), >>>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), >>>>> TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), >>>>> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), >>>>> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), >>>>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), >>>>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), >>>>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]", >>>>> "compression methods" : "00", >>>>> "extensions" ? ? ? ? ?: [ >>>>> "status_request (5)": { >>>>> "certificate status type": ocsp >>>>> "OCSP status request": { >>>>> "responder_id": >>>>> "request extensions": { >>>>> >>>>> } >>>>> } >>>>> }, >>>>> "supported_groups (10)": { >>>>> "versions": [secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, >>>>> sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, >>>>> ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] >>>>> }, >>>>> "ec_point_formats (11)": { >>>>> "formats": [uncompressed] >>>>> }, >>>>> "signature_algorithms (13)": { >>>>> "signature schemes": [ecdsa_secp256r1_sha256, >>>>> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, >>>>> rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, >>>>> rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, >>>>> rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, >>>>> ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, >>>>> dsa_sha1] >>>>> }, >>>>> "signature_algorithms_cert (50)": { >>>>> "signature schemes": [ecdsa_secp256r1_sha256, >>>>> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, >>>>> rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, >>>>> rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, >>>>> rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, >>>>> ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, >>>>> dsa_sha1] >>>>> }, >>>>> "status_request_v2 (17)": { >>>>> "cert status request": { >>>>> "certificate status type": ocsp_multi >>>>> "OCSP status request": { >>>>> "responder_id": >>>>> "request extensions": { >>>>> >>>>> } >>>>> } >>>>> } >>>>> }, >>>>> "extended_master_secret (23)": { >>>>> >>>>> }, >>>>> "supported_versions (43)": { >>>>> "versions": [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1] >>>>> }, >>>>> "psk_key_exchange_modes (45)": { >>>>> "ke_modes": [psk_dhe_ke] >>>>> }, >>>>> "key_share (51)": { >>>>> "client_shares": [ >>>>> { >>>>> "named group": secp256r1 >>>>> "key_exchange": { >>>>> 0000: 04 A3 9F B9 05 27 00 38 ? C4 D7 61 6C 66 1F 4A 8D >>>>> ??.....'.8..alf.J. >>>>> 0010: B1 02 6F 0B F6 E1 BD 50 ? 93 52 86 2C D2 3C 8D 1A >>>>> ??..o....P.R.,.<.. >>>>> 0020: 10 A9 CD F0 40 F4 CD 04 ? 25 A1 11 E2 58 23 A3 24 >>>>> ??.... at ...%...X#.$ >>>>> 0030: CA E8 8F 28 F7 2B 65 96 ? B2 E3 A1 AE 99 24 94 28 >>>>> ??...(.+e......$.( >>>>> 0040: 83 >>>>> } >>>>> }, >>>>> ] >>>>> } >>>>> ] >>>>> } >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 >>>>> CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length >>>>> = 417 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.719 >>>>> CEST|SSLSocketOutputRecord.java:255|Raw write ( >>>>> 0000: 16 03 03 01 A1 01 00 01 ? 9D 03 03 66 2E BE D3 8A >>>>> ?...........f.... >>>>> 0010: 77 39 06 3B 5A 34 03 7D ? EE 74 BB 08 D2 19 FD 50 >>>>> ?w9.;Z4...t.....P >>>>> 0020: 17 2D 84 29 AA FB E0 EE ? ED 50 69 20 0B 03 C8 E2 >>>>> ?.-.).....Pi .... >>>>> 0030: D2 A5 CD 3A 22 C5 85 17 ? 06 64 A9 30 14 62 C0 AF >>>>> ?...:"....d.0.b.. >>>>> 0040: AB 67 CE 63 50 41 50 7F ? 6B FD 4C 9F 00 5A 13 01 >>>>> ?.g.cPAP.k.L..Z.. >>>>> 0050: 13 02 C0 2C C0 2B C0 30 ? 00 9D C0 2E C0 32 00 9F >>>>> ?...,.+.0.....2.. >>>>> 0060: 00 A3 C0 2F 00 9C C0 2D ? C0 31 00 9E 00 A2 C0 24 >>>>> ?.../...-.1.....$ >>>>> 0070: C0 28 00 3D C0 26 C0 2A ? 00 6B 00 6A C0 0A C0 14 >>>>> ?.(.=.&.*.k.j.... >>>>> 0080: 00 35 C0 05 C0 0F 00 39 ? 00 38 C0 23 C0 27 00 3C >>>>> ?.5.....9.8.#.'.< >>>>> 0090: C0 25 C0 29 00 67 00 40 ? C0 09 C0 13 00 2F C0 04 >>>>> ?.%.).g. at ...../.. >>>>> 00A0: C0 0E 00 33 00 32 00 FF ? 01 00 00 FA 00 05 00 05 >>>>> ?...3.2.......... >>>>> 00B0: 01 00 00 00 00 00 0A 00 ? 20 00 1E 00 17 00 18 00 ?........ >>>>> ....... >>>>> 00C0: 19 00 09 00 0A 00 0B 00 ? 0C 00 0D 00 0E 00 16 01 >>>>> ?................ >>>>> 00D0: 00 01 01 01 02 01 03 01 ? 04 00 0B 00 02 01 00 00 >>>>> ?................ >>>>> 00E0: 0D 00 28 00 26 04 03 05 ? 03 06 03 08 04 08 05 08 >>>>> ?..(.&........... >>>>> 00F0: 06 08 09 08 0A 08 0B 04 ? 01 05 01 06 01 04 02 03 >>>>> ?................ >>>>> 0100: 03 03 01 03 02 02 03 02 ? 01 02 02 00 32 00 28 00 >>>>> ?............2.(. >>>>> 0110: 26 04 03 05 03 06 03 08 ? 04 08 05 08 06 08 09 08 >>>>> ?&............... >>>>> 0120: 0A 08 0B 04 01 05 01 06 ? 01 04 02 03 03 03 01 03 >>>>> ?................ >>>>> 0130: 02 02 03 02 01 02 02 00 ? 11 00 09 00 07 02 00 04 >>>>> ?................ >>>>> 0140: 00 00 00 00 00 17 00 00 ? 00 2B 00 09 08 03 04 03 >>>>> ?.........+...... >>>>> 0150: 03 03 02 03 01 00 2D 00 ? 02 01 01 00 33 00 47 00 >>>>> ?......-.....3.G. >>>>> 0160: 45 00 17 00 41 04 A3 9F ? B9 05 27 00 38 C4 D7 61 >>>>> ?E...A.....'.8..a >>>>> 0170: 6C 66 1F 4A 8D B1 02 6F ? 0B F6 E1 BD 50 93 52 86 >>>>> ?lf.J...o....P.R. >>>>> 0180: 2C D2 3C 8D 1A 10 A9 CD ? F0 40 F4 CD 04 25 A1 11 >>>>> ?,.<...... at ...%.. >>>>> 0190: E2 58 23 A3 24 CA E8 8F ? 28 F7 2B 65 96 B2 E3 A1 >>>>> ?.X#.$...(.+e.... >>>>> 01A0: AE 99 24 94 28 83 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?..$.(. >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: 16 03 03 00 9B ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 >>>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length >>>>> = 155 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.721 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: 02 00 00 97 03 03 AB 76 ? F1 BA F3 B1 F0 DD 53 AC >>>>> ?.......v......S. >>>>> 0010: 5B 54 E9 E4 2E F8 44 D2 ? 5E B2 59 85 0D 16 79 EE >>>>> ?[T....D.^.Y...y. >>>>> 0020: A7 66 8A 84 69 2A 20 0B ? 03 C8 E2 D2 A5 CD 3A 22 ?.f..i* >>>>> .......:" >>>>> 0030: C5 85 17 06 64 A9 30 14 ? 62 C0 AF AB 67 CE 63 50 >>>>> ?....d.0.b...g.cP >>>>> 0040: 41 50 7F 6B FD 4C 9F 13 ? 01 00 00 4F 00 2B 00 02 >>>>> ?AP.k.L.....O.+.. >>>>> 0050: 03 04 00 33 00 45 00 17 ? 00 41 04 18 4A 46 BB 73 >>>>> ?...3.E...A..JF.s >>>>> 0060: F4 6F 5D F0 3C 98 AD 70 ? 7E 13 D6 C0 E5 C0 28 5A >>>>> ?.o].<..p......(Z >>>>> 0070: D7 42 78 95 68 E0 85 B7 ? 06 CD DB 3C 35 DA AF E8 >>>>> ?.Bx.h......<5... >>>>> 0080: 95 D6 A2 3C 77 CF 7E 8E ? C8 94 50 BA CD 18 3F DA >>>>> ?...>>>> 0090: E3 A3 25 E9 F3 C9 A9 7F ? 4E B6 A9 ? ? ? ? ? ? ? ? ..%.....N.. >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.721 >>>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 handshake, length >>>>> = 155 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.722 >>>>> CEST|ServerHello.java:866|Consuming ServerHello handshake message ( >>>>> "ServerHello": { >>>>> "server version" ? ? ?: "TLSv1.2", >>>>> "random" ? ? ? ? ? ? ?: "AB 76 F1 BA F3 B1 F0 DD 53 AC 5B 54 E9 E4 >>>>> 2E F8 44 D2 5E B2 59 85 0D 16 79 EE A7 66 8A 84 69 2A", >>>>> "session id" ? ? ? ? ?: "0B 03 C8 E2 D2 A5 CD 3A 22 C5 85 17 06 64 >>>>> A9 30 14 62 C0 AF AB 67 CE 63 50 41 50 7F 6B FD 4C 9F", >>>>> "cipher suite" ? ? ? ?: "TLS_AES_128_GCM_SHA256(0x1301)", >>>>> "compression methods" : "00", >>>>> "extensions" ? ? ? ? ?: [ >>>>> "supported_versions (43)": { >>>>> "selected version": [TLSv1.3] >>>>> }, >>>>> "key_share (51)": { >>>>> "server_share": { >>>>> "named group": secp256r1 >>>>> "key_exchange": { >>>>> 0000: 04 18 4A 46 BB 73 F4 6F ? 5D F0 3C 98 AD 70 7E 13 >>>>> ??..JF.s.o].<..p.. >>>>> 0010: D6 C0 E5 C0 28 5A D7 42 ? 78 95 68 E0 85 B7 06 CD >>>>> ??....(Z.Bx.h..... >>>>> 0020: DB 3C 35 DA AF E8 95 D6 ? A2 3C 77 CF 7E 8E C8 94 >>>>> ??.<5......>>>> 0030: 50 BA CD 18 3F DA E3 A3 ? 25 E9 F3 C9 A9 7F 4E B6 >>>>> ??P...?...%.....N. >>>>> 0040: A9 >>>>> } >>>>> }, >>>>> } >>>>> ] >>>>> } >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 >>>>> CEST|SSLExtensions.java:167|Consumed extension: supported_versions >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 >>>>> CEST|ServerHello.java:962|Negotiated protocol version: TLSv1.3 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 >>>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: server_name >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 >>>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: >>>>> max_fragment_length >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 >>>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: >>>>> status_request >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 >>>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: >>>>> ec_point_formats >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 >>>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: >>>>> application_layer_protocol_negotiation >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 >>>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: >>>>> status_request_v2 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 >>>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: >>>>> extended_master_secret >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 >>>>> CEST|SSLExtensions.java:167|Consumed extension: supported_versions >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 >>>>> CEST|SSLExtensions.java:167|Consumed extension: key_share >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 >>>>> CEST|SSLExtensions.java:138|Ignore unsupported extension: >>>>> renegotiation_info >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 >>>>> CEST|PreSharedKeyExtension.java:832|Handling pre_shared_key absence. >>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.725 >>>>> CEST|SSLSessionImpl.java:203|Session initialized: >>>>> ??Session(1537177914725|TLS_AES_128_GCM_SHA256) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 >>>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: server_name >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>>> max_fragment_length >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>>> status_request >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>>> ec_point_formats >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>>> application_layer_protocol_negotiation >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>>> status_request_v2 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>>> extended_master_secret >>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.726 >>>>> CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: >>>>> supported_versions >>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.726 >>>>> CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: >>>>> key_share >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>>> renegotiation_info >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 >>>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>>> pre_shared_key >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.732 >>>>> CEST|SSLCipher.java:1824|KeyLimit read side: algorithm = >>>>> AES/GCM/NOPADDING:KEYUPDATE >>>>> countdown value = 137438953472 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.735 >>>>> CEST|SSLCipher.java:1978|KeyLimit write side: algorithm = >>>>> AES/GCM/NOPADDING:KEYUPDATE >>>>> countdown value = 137438953472 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.736 >>>>> CEST|SSLSocketOutputRecord.java:225|Raw write ( >>>>> 0000: 14 03 03 00 01 01 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...... >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.736 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: 14 03 03 00 01 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 >>>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 >>>>> change_cipher_spec, length = 1 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: 01 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? . >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 >>>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 >>>>> change_cipher_spec, length = 1 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 >>>>> CEST|ChangeCipherSpec.java:232|Consuming ChangeCipherSpec message >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: 17 03 03 00 27 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ....' >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 >>>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, >>>>> length = 39 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: D5 B7 25 6F AF E9 D6 6F ? 7C 61 98 90 3F FE BA 9A >>>>> ?..%o...o.a..?... >>>>> 0010: A8 5B 94 5E 3A 47 38 62 ? 36 90 9A 1D BE BF 87 18 >>>>> ?.[.^:G8b6....... >>>>> 0020: 56 8C E3 AA CE AD AA ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? V...... >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 >>>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, >>>>> length = 39 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.746 >>>>> CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>>> 0000: 08 00 00 12 00 10 00 0A ? 00 0C 00 0A 00 1D 00 17 >>>>> ?................ >>>>> 0010: 00 1E 00 19 00 18 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...... >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 >>>>> CEST|EncryptedExtensions.java:171|Consuming EncryptedExtensions >>>>> handshake message ( >>>>> "EncryptedExtensions": [ >>>>> "supported_groups (10)": { >>>>> "versions": [x25519, secp256r1, x448, secp521r1, secp384r1] >>>>> } >>>>> ] >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 >>>>> CEST|SSLExtensions.java:148|Ignore unavailable extension: server_name >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 >>>>> CEST|SSLExtensions.java:148|Ignore unavailable extension: >>>>> max_fragment_length >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 >>>>> CEST|SSLExtensions.java:167|Consumed extension: supported_groups >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 >>>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: server_name >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 >>>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>>> max_fragment_length >>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.748 >>>>> CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: >>>>> supported_groups >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 >>>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>>> application_layer_protocol_negotiation >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: 17 03 03 00 42 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ....B >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 >>>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, >>>>> length = 66 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: 63 F7 54 24 11 6A 91 1F ? 1F C5 70 9A 26 AD CE 98 >>>>> ?c.T$.j....p.&... >>>>> 0010: D0 A9 7A 84 AF 39 7C A0 ? AD F6 6B B2 10 88 27 8B >>>>> ?..z..9....k...'. >>>>> 0020: 79 E0 F4 5A 9F 68 AA F0 ? 56 D3 45 72 7C 7F 22 03 >>>>> ?y..Z.h..V.Er..". >>>>> 0030: 0A 53 F6 24 68 CB 0B E1 ? 3B DD D4 78 B5 AC 1E D7 >>>>> ?.S.$h...;..x.... >>>>> 0040: 03 FB ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.. >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 >>>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, >>>>> length = 66 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 >>>>> CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>>> 0000: 0D 00 00 2D 00 00 2A 00 ? 0D 00 26 00 24 04 03 05 >>>>> ?...-..*...&.$... >>>>> 0010: 03 06 03 08 07 08 08 08 ? 09 08 0A 08 0B 08 04 08 >>>>> ?................ >>>>> 0020: 05 08 06 04 01 05 01 06 ? 01 03 03 02 03 03 01 02 >>>>> ?................ >>>>> 0030: 01 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? . >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 >>>>> CEST|CertificateRequest.java:864|Consuming CertificateRequest >>>>> handshake message ( >>>>> "CertificateRequest": { >>>>> "certificate_request_context": "", >>>>> "extensions": [ >>>>> "signature_algorithms (13)": { >>>>> "signature schemes": [ecdsa_secp256r1_sha256, >>>>> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, ed25519, ed448, >>>>> rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, >>>>> rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, >>>>> rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha224, >>>>> ecdsa_sha1, rsa_sha224, rsa_pkcs1_sha1] >>>>> } >>>>> ] >>>>> } >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 >>>>> CEST|SSLExtensions.java:167|Consumed extension: signature_algorithms >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 >>>>> CEST|SSLExtensions.java:148|Ignore unavailable extension: >>>>> signature_algorithms_cert >>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 >>>>> CEST|SignatureScheme.java:390|Unsupported signature scheme: ed25519 >>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 >>>>> CEST|SignatureScheme.java:390|Unsupported signature scheme: ed448 >>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 >>>>> CEST|SignatureScheme.java:390|Unsupported signature scheme: >>>>> ecdsa_sha224 >>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 >>>>> CEST|SignatureScheme.java:390|Unsupported signature scheme: rsa_sha224 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 >>>>> CEST|SSLExtensions.java:199|Populated with extension: >>>>> signature_algorithms >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 >>>>> CEST|SSLExtensions.java:182|Ignore unavailable extension: >>>>> signature_algorithms_cert >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: 17 03 03 03 20 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .... >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 >>>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, >>>>> length = 800 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.753 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: FE BB B2 07 BA CE A6 32 ? AA 58 66 2F 6D 87 16 75 >>>>> ?.......2.Xf/m..u >>>>> 0010: CF 71 13 53 FB 45 AE DC ? 84 F4 AA 33 08 08 DF B5 >>>>> ?.q.S.E.....3.... >>>>> 0020: 97 C5 79 40 4A 28 F4 9D ? 0F 5A 86 4E C4 5F C7 2E >>>>> ?..y at J(...Z.N._.. >>>>> 0030: AA AA 42 F7 8A FF 6B C1 ? 28 75 9B A3 25 F0 23 81 >>>>> ?..B...k.(u..%.#. >>>>> 0040: 74 BB 9A EA A8 8D 89 BE ? E9 80 AE 31 C3 3A FC 35 >>>>> ?t..........1.:.5 >>>>> 0050: E6 CA C5 77 BF C7 0E ED ? 64 26 DB 4E C3 3D F5 AD >>>>> ?...w....d&.N.=.. >>>>> 0060: 5E EB A8 37 AA 81 EF 39 ? 24 84 C9 C4 C7 A2 D7 DB >>>>> ?^..7...9$....... >>>>> 0070: 7F 82 01 7A 02 E7 23 A3 ? 6E C9 68 B8 E5 C3 9F 53 >>>>> ?...z..#.n.h....S >>>>> 0080: 16 6E EF B0 54 D2 67 4C ? FF 22 E6 78 B1 A0 DB BE >>>>> ?.n..T.gL.".x.... >>>>> 0090: 97 23 FC C8 D8 92 86 3D ? C6 6B E4 C1 AC EF B8 46 >>>>> ?.#.....=.k.....F >>>>> 00A0: 75 3C 00 08 8B 34 5F 59 ? 05 49 25 97 BE A8 61 8E >>>>> ?u<...4_Y.I%...a. >>>>> 00B0: B0 5F 25 91 7A FE 79 53 ? 7A C1 A7 E7 70 7B A5 53 >>>>> ?._%.z.ySz...p..S >>>>> 00C0: 5A 63 8B 8E B9 92 2D B3 ? 80 DC AA 75 BE 0F 47 F3 >>>>> ?Zc....-....u..G. >>>>> 00D0: E8 D9 0D 7D D9 C3 B6 00 ? AD 2A 43 CC 66 87 88 AF >>>>> ?.........*C.f... >>>>> 00E0: 35 87 74 2F 87 2F 3C A6 ? FB 12 1A 9C 46 62 1C DC >>>>> ?5.t/./<.....Fb.. >>>>> 00F0: 4E 4E DC 16 70 7E 08 74 ? FB F7 E6 5F 4D D9 20 F9 >>>>> ?NN..p..t..._M. . >>>>> 0100: CA F3 91 45 D6 1A B3 BA ? FA 4E BD A4 74 9E 4C 78 >>>>> ?...E.....N..t.Lx >>>>> 0110: 03 18 2C 70 35 42 68 F3 ? 9A 1D 24 3F A7 27 DF 29 >>>>> ?..,p5Bh...$?.'.) >>>>> 0120: D5 58 7C CB 19 2F D1 DF ? 8A 6D B2 85 52 B5 78 19 >>>>> ?.X.../...m..R.x. >>>>> 0130: EA 5C E2 7A 23 42 9E D7 ? A3 DC D0 DE D8 33 47 2B >>>>> ?.\.z#B.......3G+ >>>>> 0140: 0C D8 6E 77 25 DB E6 12 ? B0 7A AD A5 C9 96 AC A9 >>>>> ?..nw%....z...... >>>>> 0150: 1D CD 73 39 AC 6A 9F E2 ? 0A F7 17 F1 F0 FF 75 9C >>>>> ?..s9.j........u. >>>>> 0160: B2 05 9E 7A F4 18 4F FC ? 9D 42 69 4C E0 3E A1 21 >>>>> ?...z..O..BiL.>.! >>>>> 0170: DA 1F 71 07 59 C6 A2 F9 ? 0B 4F C0 CD A4 85 A8 DB >>>>> ?..q.Y....O...... >>>>> 0180: 77 F6 87 5E 09 16 49 5C ? 2C B8 C0 7B 39 81 65 FD >>>>> ?w..^..I\,...9.e. >>>>> 0190: 29 52 E2 C7 F5 C7 AD BC ? F6 A9 F9 6D D2 E9 A4 14 >>>>> ?)R.........m.... >>>>> 01A0: C9 D3 79 2E D2 BA 10 4C ? BD 44 65 2B A8 7E F1 3A >>>>> ?..y....L.De+...: >>>>> 01B0: F3 F6 11 53 38 17 10 12 ? B4 CD C5 AD 72 3B 84 A2 >>>>> ?...S8.......r;.. >>>>> 01C0: 1B F9 D7 BF 34 00 5A FE ? F4 CE 09 0C EA F2 27 9A >>>>> ?....4.Z.......'. >>>>> 01D0: BD DD 93 37 E2 DF 60 CC ? 8A F7 C6 4B 08 30 0D 78 >>>>> ?...7..`....K.0.x >>>>> 01E0: 5C EB 49 34 DB 8B EB 55 ? 33 0C 82 03 07 FD 3D FC >>>>> ?\.I4...U3.....=. >>>>> 01F0: 49 11 88 1C F6 67 7F 0B ? 48 AA EC 1B AF 04 46 CF >>>>> ?I....g..H.....F. >>>>> 0200: 09 C5 8E B3 F8 92 C4 56 ? 3D 8F 0E 1D 9F D3 0C FE >>>>> ?.......V=....... >>>>> 0210: 94 23 15 53 8E 1F 5E C4 ? FA 44 03 3B 1B B0 0A 2D >>>>> ?.#.S..^..D.;...- >>>>> 0220: 71 D4 B5 AC 1F 52 D7 25 ? 9F A0 C8 4B 9B 32 B8 22 >>>>> ?q....R.%...K.2." >>>>> 0230: 3F AF B3 19 16 8C 2A 5C ? B4 89 BF 82 DC 4D AF 22 >>>>> ??.....*\.....M." >>>>> 0240: 2A 33 73 90 F3 C8 FF 2E ? C1 B3 83 D2 7A 29 4E 15 >>>>> ?*3s.........z)N. >>>>> 0250: 5D 87 86 F6 94 EA B0 B4 ? A4 41 B9 C5 BA 89 B8 E9 >>>>> ?]........A...... >>>>> 0260: 26 E7 96 BC 4D 8A FD 86 ? C7 C9 2A 96 75 C3 07 EF >>>>> ?&...M.....*.u... >>>>> 0270: 5C 5A 4E 91 71 7D 1B A2 ? 12 88 C5 D0 D2 5E 79 E1 >>>>> ?\ZN.q........^y. >>>>> 0280: 6C 65 35 5E 6C CC 56 47 ? FD F3 96 78 7A A0 08 7E >>>>> ?le5^l.VG...xz... >>>>> 0290: DB 3C CC 10 76 15 37 46 ? 48 6B 2D 23 7B A3 44 5A >>>>> ?.<..v.7FHk-#..DZ >>>>> 02A0: A4 46 B3 CE E2 15 BA 4C ? D2 93 16 57 1F BA 75 72 >>>>> ?.F.....L...W..ur >>>>> 02B0: BF 8C 66 50 F2 A4 F6 05 ? 84 E5 47 12 30 BE 34 70 >>>>> ?..fP......G.0.4p >>>>> 02C0: 4D 0F BD FE 54 E8 B1 CE ? B5 7F 6E 97 38 09 29 1F >>>>> ?M...T.....n.8.). >>>>> 02D0: 41 2D 2E 9E 75 D8 77 0C ? 08 DB 5C B4 EE 3F FE E2 >>>>> ?A-..u.w...\..?.. >>>>> 02E0: DC CF D0 ED C8 02 50 C4 ? EE B3 1D 8A 9E 9B EE 5E >>>>> ?......P........^ >>>>> 02F0: 14 BA C2 5A B0 83 8E 5C ? E5 7B 69 2B 69 8C F1 AA >>>>> ?...Z...\..i+i... >>>>> 0300: 2D D5 D1 3D 9D 42 1B B2 ? 50 5D BE 7E E4 11 D2 90 >>>>> ?-..=.B..P]...... >>>>> 0310: 0B 54 71 7F D6 13 88 E2 ? FE 37 9F 70 B5 0B 57 79 >>>>> ?.Tq......7.p..Wy >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.753 >>>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, >>>>> length = 800 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.755 >>>>> CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>>> 0000: 0B 00 03 0B 00 00 03 07 ? 00 03 02 30 82 02 FE 30 >>>>> ?...........0...0 >>>>> 0010: 82 01 E6 A0 03 02 01 02 ? 02 08 20 C3 8D C4 49 66 ?.......... >>>>> ...If >>>>> 0020: D0 02 30 0D 06 09 2A 86 ? 48 86 F7 0D 01 01 0B 05 >>>>> ?..0...*.H....... >>>>> 0030: 00 30 3E 31 3C 30 3A 06 ? 03 55 04 03 0C 33 65 38 >>>>> ?.0>1<0:..U...3e8 >>>>> 0040: 61 63 30 32 66 61 30 64 ? 36 35 61 38 34 32 31 39 >>>>> ?ac02fa0d65a84219 >>>>> 0050: 30 31 36 30 34 35 64 62 ? 38 62 30 35 63 34 38 35 >>>>> ?016045db8b05c485 >>>>> 0060: 62 34 65 63 64 66 2E 6E ? 65 74 74 79 2E 74 65 73 >>>>> ?b4ecdf.netty.tes >>>>> 0070: 74 30 20 17 0D 31 33 30 ? 38 30 32 30 37 35 31 33 ?t0 >>>>> ..13080207513 >>>>> 0080: 36 5A 18 0F 39 39 39 39 ? 31 32 33 31 32 33 35 39 >>>>> ?6Z..999912312359 >>>>> 0090: 35 39 5A 30 3E 31 3C 30 ? 3A 06 03 55 04 03 0C 33 >>>>> ?59Z0>1<0:..U...3 >>>>> 00A0: 65 38 61 63 30 32 66 61 ? 30 64 36 35 61 38 34 32 >>>>> ?e8ac02fa0d65a842 >>>>> 00B0: 31 39 30 31 36 30 34 35 ? 64 62 38 62 30 35 63 34 >>>>> ?19016045db8b05c4 >>>>> 00C0: 38 35 62 34 65 63 64 66 ? 2E 6E 65 74 74 79 2E 74 >>>>> ?85b4ecdf.netty.t >>>>> 00D0: 65 73 74 30 82 01 22 30 ? 0D 06 09 2A 86 48 86 F7 >>>>> ?est0.."0...*.H.. >>>>> 00E0: 0D 01 01 01 05 00 03 82 ? 01 0F 00 30 82 01 0A 02 >>>>> ?...........0.... >>>>> 00F0: 82 01 01 00 DB F8 70 4E ? DC 2D 14 44 12 AF 0D 48 >>>>> ?......pN.-.D...H >>>>> 0100: 09 1D B8 48 94 1C 9E F1 ? 7F DC 6C D1 F7 94 3A B7 >>>>> ?...H......l...:. >>>>> 0110: 5C E3 85 07 3E CB E1 76 ? 4A 2C 32 17 4B E1 5E 42 >>>>> ?\...>..vJ,2.K.^B >>>>> 0120: A4 80 50 CA 36 A2 D9 94 ? F9 59 23 D0 AA 2B B2 13 >>>>> ?..P.6....Y#..+.. >>>>> 0130: 23 6D 45 DF 13 52 A4 4E ? 28 D3 30 99 5A 81 AD 8C >>>>> ?#mE..R.N(.0.Z... >>>>> 0140: DB 15 55 B7 6D 5F 44 89 ? 09 35 66 C8 2F 47 56 14 >>>>> ?..U.m_D..5f./GV. >>>>> 0150: B5 B2 46 AE CE 5D DC A0 ? C8 59 08 89 6F 5B DB F2 >>>>> ?..F..]...Y..o[.. >>>>> 0160: D8 69 E3 C1 80 44 F6 DA ? 46 ED 1D 20 80 12 3F 81 >>>>> ?.i...D..F.. ..?. >>>>> 0170: 95 27 F6 EB 9F B5 AC DC ? 72 01 70 46 18 67 1C 08 >>>>> ?.'......r.pF.g.. >>>>> 0180: AC C4 6D CA 80 48 12 87 ? 3A 05 69 EA 92 EA 95 00 >>>>> ?..m..H..:.i..... >>>>> 0190: 1F B9 2C BA 83 F3 B3 1B ? 37 1E B3 7C D7 46 B1 AE >>>>> ?..,.....7....F.. >>>>> 01A0: D4 DD E9 04 8C C0 23 00 ? 96 E3 6F 67 E7 66 65 61 >>>>> ?......#...og.fea >>>>> 01B0: F6 11 D2 7A FE 44 42 83 ? 9D 1A CF 20 80 EC 58 04 >>>>> ?...z.DB.... ..X. >>>>> 01C0: A6 10 78 41 7B 34 C3 FA ? FD 2A 08 94 72 2F 3D AE >>>>> ?..xA.4...*..r/=. >>>>> 01D0: B0 58 16 63 EE DA 81 42 ? 44 DB 21 C7 23 69 93 BB >>>>> ?.X.c...BD.!.#i.. >>>>> 01E0: 64 40 16 78 01 8A 52 57 ? 94 C0 AD 57 04 F4 C4 6B >>>>> ?d at .x..RW...W...k >>>>> 01F0: 90 C6 46 C7 02 03 01 00 ? 01 30 0D 06 09 2A 86 48 >>>>> ?..F......0...*.H >>>>> 0200: 86 F7 0D 01 01 0B 05 00 ? 03 82 01 01 00 4B FC 37 >>>>> ?.............K.7 >>>>> 0210: B5 E6 F2 A6 98 D8 58 2B ? 39 CE 8F 6B 51 93 80 0F >>>>> ?......X+9..kQ... >>>>> 0220: 80 39 BD DA 53 7D D3 1B ? 00 11 F3 A7 FE 9C B7 FA >>>>> ?.9..S........... >>>>> 0230: 05 23 DA A2 17 10 7C E7 ? 89 89 DE C5 90 5B 98 22 >>>>> ?.#...........[." >>>>> 0240: 7B 97 97 EA 2A B3 E4 6A ? 33 F8 FC 47 41 39 06 E1 >>>>> ?....*..j3..GA9.. >>>>> 0250: 98 63 6C 0E 2A 92 FF 3D ? B1 62 D7 27 FF 2B 2B DF >>>>> ?.cl.*..=.b.'.++. >>>>> 0260: B7 B2 95 87 C7 B5 21 45 ? 1E 73 F8 B5 0D D6 13 0C >>>>> ?......!E.s...... >>>>> 0270: 1D 25 35 6B D7 5F 18 DF ? 30 A1 8B 72 DD C6 31 B1 >>>>> ?.%5k._..0..r..1. >>>>> 0280: 07 2A F2 DF 1F 1E 36 23 ? 0C FF F9 FB DA E8 B5 2B >>>>> ?.*....6#.......+ >>>>> 0290: 3B 8B B6 4C 37 EF D3 27 ? 07 B9 1E D4 64 4B 82 D4 >>>>> ?;..L7..'....dK.. >>>>> 02A0: 32 78 C6 D1 61 6E 9A BF ? 41 10 23 0B 27 CD C7 77 >>>>> ?2x..an..A.#.'..w >>>>> 02B0: 03 73 B2 F6 12 D2 56 9C ? 29 A2 BD 31 40 F6 5F 0C >>>>> ?.s....V.)..1 at ._. >>>>> 02C0: 17 56 4F 30 34 95 77 87 ? 9C 43 B0 74 C5 92 05 43 >>>>> ?.VO04.w..C.t...C >>>>> 02D0: 97 12 48 5B 7B 58 66 89 ? 0A C1 8C CD 89 14 E0 5A >>>>> ?..H[.Xf........Z >>>>> 02E0: 78 23 29 10 71 6C 5D 94 ? D5 FB C0 96 51 C1 0D 93 >>>>> ?x#).ql].....Q... >>>>> 02F0: 64 91 45 82 5A 53 88 56 ? 5D 7A AE 88 E8 07 7D 02 >>>>> ?d.E.ZS.V]z...... >>>>> 0300: 7D 44 9D CA 73 E5 6F 14 ? 27 8B 6F 86 6C 00 00 >>>>> .D..s.o.'.o.l.. >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 >>>>> CEST|CertificateMessage.java:1148|Consuming server Certificate >>>>> handshake message ( >>>>> "Certificate": { >>>>> "certificate_request_context": "", >>>>> "certificate_list": [ >>>>> { >>>>> "certificate" : { >>>>> "version" ? ? ? ? ? ?: "v3", >>>>> "serial number" ? ? ?: "20 C3 8D C4 49 66 D0 02", >>>>> "signature algorithm": "SHA256withRSA", >>>>> "issuer" ? ? ? ? ? ? : >>>>> "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>>>> "not before" ? ? ? ? : "2013-08-02 09:51:36.000 CEST", >>>>> "not ?after" ? ? ? ? : "10000-01-01 24:59:59.000 CET", >>>>> "subject" ? ? ? ? ? ?: >>>>> "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>>>> "subject public key" : "RSA"} >>>>> "extensions": { >>>>> >>>>> } >>>>> }, >>>>> ] >>>>> } >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 >>>>> CEST|SSLExtensions.java:148|Ignore unavailable extension: >>>>> status_request >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: 17 03 03 01 19 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 >>>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, >>>>> length = 281 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: DE 53 C0 74 78 C3 82 0D ? E8 46 C0 0A F4 56 6E 6B >>>>> ?.S.tx....F...Vnk >>>>> 0010: B5 39 77 41 20 21 BA 07 ? 99 2B BF 8D 0A 41 C9 B8 ?.9wA >>>>> !...+...A.. >>>>> 0020: BC 0F C1 8E C5 76 36 F0 ? 7A B6 9A F8 38 4D 4D 4D >>>>> ?.....v6.z...8MMM >>>>> 0030: 70 33 BE 8F 8C ED BE BC ? 60 49 B8 41 65 E9 04 D9 >>>>> ?p3......`I.Ae... >>>>> 0040: 45 43 AA 41 6D F7 67 7B ? 03 6D FF E0 4D 76 53 CE >>>>> ?EC.Am.g..m..MvS. >>>>> 0050: C1 73 3E 1C CD 87 40 B7 ? 25 56 54 0C 3E CA D7 1D >>>>> ?.s>... at .%VT.>... >>>>> 0060: 45 80 41 E8 36 B7 FC 57 ? 38 BB 21 EB E7 EA 19 A1 >>>>> ?E.A.6..W8.!..... >>>>> 0070: 39 25 B0 44 8B FD 30 87 ? 86 7A 47 03 C1 02 AC FD >>>>> ?9%.D..0..zG..... >>>>> 0080: 67 89 4B 27 34 04 20 AE ? 91 65 7C 8C 4A 58 C5 77 ?g.K'4. >>>>> ..e..JX.w >>>>> 0090: 46 2E DD A8 23 CA 5C 28 ? 49 25 23 3D 8A 93 B9 10 >>>>> ?F...#.\(I%#=.... >>>>> 00A0: 24 0D DE DC 98 AC AA B0 ? CB 51 80 D7 F8 E7 20 23 >>>>> ?$........Q.... # >>>>> 00B0: 41 64 A6 44 93 A7 E1 A7 ? 91 62 4F 3A 73 F6 24 04 >>>>> ?Ad.D.....bO:s.$. >>>>> 00C0: C3 E8 25 65 37 D9 1B 7A ? 65 AE DE C6 29 67 2E C1 >>>>> ?..%e7..ze...)g.. >>>>> 00D0: F7 4C 5C 18 D7 14 98 90 ? ED 9D AD F5 98 A7 FD 93 >>>>> ?.L\............. >>>>> 00E0: 53 F4 B5 90 C9 CB FD 54 ? 8E 5F 53 23 E3 73 94 BD >>>>> ?S......T._S#.s.. >>>>> 00F0: A4 07 B7 E3 C7 83 7B 17 ? CF 51 4A 9E 9C 05 3C 51 >>>>> ?.........QJ...>>>> 0100: 4D C7 A1 7A D6 4D A6 58 ? E5 3A D4 12 B9 B9 46 9C >>>>> ?M..z.M.X.:....F. >>>>> 0110: AB 1D C5 6B F9 6A 85 CB ? E2 ? ? ? ? ? ? ? ? ? ? ? ...k.j... >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.758 >>>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, >>>>> length = 281 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.758 >>>>> CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>>> 0000: 0F 00 01 04 08 04 01 00 ? 30 11 28 CE 64 4E 08 BA >>>>> ?........0.(.dN.. >>>>> 0010: A1 BE 46 D9 3D 14 29 1A ? EB 5A B0 1A 09 B7 11 A5 >>>>> ?..F.=.)..Z...... >>>>> 0020: 9A F4 22 17 87 5F 87 D5 ? 63 04 8E 27 EC 3A F8 52 >>>>> ?..".._..c..'.:.R >>>>> 0030: 36 F4 2F CF 47 D2 5C CE ? 0A F0 29 EF 63 03 B1 64 >>>>> ?6./.G.\...).c..d >>>>> 0040: B8 45 6E 39 71 E3 BD 25 ? 95 31 25 85 4C FB C6 AD >>>>> ?.En9q..%.1%.L... >>>>> 0050: C8 43 96 4E FA AD B9 98 ? 17 43 61 FB 9B 87 CE 94 >>>>> ?.C.N.....Ca..... >>>>> 0060: CF 74 6F 3B AA 6A C8 80 ? 8F C7 C8 05 E4 EF 42 6C >>>>> ?.to;.j........Bl >>>>> 0070: D4 01 9E 25 5E 34 E8 2D ? 93 BD BB 05 49 2F 9D B6 >>>>> ?...%^4.-....I/.. >>>>> 0080: F6 91 2F D1 E5 CB 1B 9E ? F6 DB 18 32 1D F5 66 A0 >>>>> ?../........2..f. >>>>> 0090: 63 5D 25 01 B6 F6 1B 41 ? 07 3E 90 61 37 49 38 17 >>>>> ?c]%....A.>.a7I8. >>>>> 00A0: B0 15 C9 AD 0C 7A 05 8D ? B4 48 BB 03 2D DE 5E 49 >>>>> ?.....z...H..-.^I >>>>> 00B0: 99 8B 74 53 5F 73 9B 18 ? FD 95 2A C3 F9 A3 8B 59 >>>>> ?..tS_s....*....Y >>>>> 00C0: 1A ED 2C 55 C2 22 10 1E ? 7A FC 38 0A 99 FC 30 89 >>>>> ?..,U."..z.8...0. >>>>> 00D0: 03 89 1C CD A7 DE E5 35 ? FD E9 E0 05 96 09 AF DD >>>>> ?.......5........ >>>>> 00E0: 51 A3 7F C7 16 C5 96 8D ? CA CC 53 50 DC C5 C6 BA >>>>> ?Q.........SP.... >>>>> 00F0: D6 05 28 18 BA 99 F8 0F ? 7F 24 9F D5 6B 93 DE BC >>>>> ?..(......$..k... >>>>> 0100: EB 23 85 D9 D3 41 56 44 ? ? ? ? ? ? ? ? ? ? ? ? ? ?.#...AVD >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 >>>>> CEST|CertificateVerify.java:1128|Consuming CertificateVerify >>>>> handshake message ( >>>>> "CertificateVerify": { >>>>> "signature algorithm": rsa_pss_rsae_sha256 >>>>> "signature": { >>>>> 0000: 30 11 28 CE 64 4E 08 BA ? A1 BE 46 D9 3D 14 29 1A >>>>> ??0.(.dN....F.=.). >>>>> 0010: EB 5A B0 1A 09 B7 11 A5 ? 9A F4 22 17 87 5F 87 D5 >>>>> ??.Z........".._.. >>>>> 0020: 63 04 8E 27 EC 3A F8 52 ? 36 F4 2F CF 47 D2 5C CE >>>>> ??c..'.:.R6./.G.\. >>>>> 0030: 0A F0 29 EF 63 03 B1 64 ? B8 45 6E 39 71 E3 BD 25 >>>>> ??..).c..d.En9q..% >>>>> 0040: 95 31 25 85 4C FB C6 AD ? C8 43 96 4E FA AD B9 98 >>>>> ??.1%.L....C.N.... >>>>> 0050: 17 43 61 FB 9B 87 CE 94 ? CF 74 6F 3B AA 6A C8 80 >>>>> ??.Ca......to;.j.. >>>>> 0060: 8F C7 C8 05 E4 EF 42 6C ? D4 01 9E 25 5E 34 E8 2D >>>>> ??......Bl...%^4.- >>>>> 0070: 93 BD BB 05 49 2F 9D B6 ? F6 91 2F D1 E5 CB 1B 9E >>>>> ??....I/..../..... >>>>> 0080: F6 DB 18 32 1D F5 66 A0 ? 63 5D 25 01 B6 F6 1B 41 >>>>> ??...2..f.c]%....A >>>>> 0090: 07 3E 90 61 37 49 38 17 ? B0 15 C9 AD 0C 7A 05 8D >>>>> ??.>.a7I8......z.. >>>>> 00A0: B4 48 BB 03 2D DE 5E 49 ? 99 8B 74 53 5F 73 9B 18 >>>>> ??.H..-.^I..tS_s.. >>>>> 00B0: FD 95 2A C3 F9 A3 8B 59 ? 1A ED 2C 55 C2 22 10 1E >>>>> ??..*....Y..,U.".. >>>>> 00C0: 7A FC 38 0A 99 FC 30 89 ? 03 89 1C CD A7 DE E5 35 >>>>> ??z.8...0........5 >>>>> 00D0: FD E9 E0 05 96 09 AF DD ? 51 A3 7F C7 16 C5 96 8D >>>>> ??........Q....... >>>>> 00E0: CA CC 53 50 DC C5 C6 BA ? D6 05 28 18 BA 99 F8 0F >>>>> ??..SP......(..... >>>>> 00F0: 7F 24 9F D5 6B 93 DE BC ? EB 23 85 D9 D3 41 56 44 >>>>> ??.$..k....#...AVD >>>>> } >>>>> } >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: 17 03 03 00 35 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ....5 >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 >>>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, >>>>> length = 53 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: F6 A7 CD EA 89 34 B2 DB ? C4 28 91 18 C9 03 98 B6 >>>>> ?.....4...(...... >>>>> 0010: DF 49 4E F5 2E 23 32 90 ? F8 13 C7 AE 18 E3 E5 64 >>>>> ?.IN..#2........d >>>>> 0020: D9 E4 A5 B0 5C F0 4A 3E ? AF EC 28 8D 09 78 AB EE >>>>> ?....\.J>..(..x.. >>>>> 0030: 38 1B 9E 45 04 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 8..E. >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 >>>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, >>>>> length = 53 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 >>>>> CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>>> 0000: 14 00 00 20 F2 93 6B 71 ? 2B FA F3 1B BF 68 98 D1 ?... >>>>> ..kq+....h.. >>>>> 0010: AA 5E B0 AF 5D 3B A6 B5 ? 8F 79 BA 64 E8 A1 34 5F >>>>> ?.^..];...y.d..4_ >>>>> 0020: D4 2B ED 8C ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.+.. >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.764 >>>>> CEST|Finished.java:860|Consuming server Finished handshake message ( >>>>> "Finished": { >>>>> "verify data": { >>>>> 0000: F2 93 6B 71 2B FA F3 1B ? BF 68 98 D1 AA 5E B0 AF >>>>> ??..kq+....h...^.. >>>>> 0010: 5D 3B A6 B5 8F 79 BA 64 ? E8 A1 34 5F D4 2B ED 8C >>>>> ??];...y.d..4_.+.. >>>>> }'} >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.765 >>>>> CEST|SSLCipher.java:1824|KeyLimit read side: algorithm = >>>>> AES/GCM/NOPADDING:KEYUPDATE >>>>> countdown value = 137438953472 >>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.765 >>>>> CEST|CertificateMessage.java:1015|No signature_algorithms(_cert) in >>>>> ClientHello >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 >>>>> CEST|CertificateMessage.java:1081|No available client >>>>> authentication scheme >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 >>>>> CEST|CertificateMessage.java:1116|Produced client Certificate >>>>> message ( >>>>> "Certificate": { >>>>> "certificate_request_context": "", >>>>> "certificate_list": [ >>>>> ] >>>>> } >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 >>>>> CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 8 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 >>>>> CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( >>>>> 0000: 0B 00 00 04 00 00 00 00 ? 16 00 00 00 00 00 00 00 >>>>> ?................ >>>>> 0010: 00 00 00 00 00 00 00 00 ? 00 ? ? ? ? ? ? ? ? ? ? ? ......... >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 >>>>> CEST|SSLSocketOutputRecord.java:255|Raw write ( >>>>> 0000: 17 03 03 00 29 E5 32 E4 ? 5B 13 E7 D4 A1 78 FE 38 >>>>> ?....).2.[....x.8 >>>>> 0010: 26 22 CB C1 04 88 3A 3A ? 2D D4 A1 31 5A 78 65 50 >>>>> ?&"....::-..1ZxeP >>>>> 0020: 51 45 67 FA 9F 55 35 E1 ? 49 C5 3B 3B 91 B1 >>>>> ?QEg..U5.I.;;.. >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 >>>>> CEST|CertificateVerify.java:1059|No X.509 credentials negotiated >>>>> for CertificateVerify >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 >>>>> CEST|Finished.java:658|Produced client Finished handshake message ( >>>>> "Finished": { >>>>> "verify data": { >>>>> 0000: D8 47 0B A0 DF BB BF 49 ? E4 55 B9 D3 FB 3D B0 DD >>>>> ??.G.....I.U...=.. >>>>> 0010: 57 1E 08 28 20 7E E1 0B ? E3 EB 12 10 09 76 D1 8F ?W..( >>>>> ........v.. >>>>> }'} >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 >>>>> CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length >>>>> = 36 >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 >>>>> CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( >>>>> 0000: 14 00 00 20 D8 47 0B A0 ? DF BB BF 49 E4 55 B9 D3 ?... >>>>> .G.....I.U.. >>>>> 0010: FB 3D B0 DD 57 1E 08 28 ? 20 7E E1 0B E3 EB 12 10 ?.=..W..( >>>>> ....... >>>>> 0020: 09 76 D1 8F 16 00 00 00 ? 00 00 00 00 00 00 00 00 >>>>> ?.v.............. >>>>> 0030: 00 00 00 00 00 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 >>>>> CEST|SSLSocketOutputRecord.java:255|Raw write ( >>>>> 0000: 17 03 03 00 45 0F 4D 84 ? 52 28 59 96 92 52 D1 AB >>>>> ?....E.M.R(Y..R.. >>>>> 0010: DB 86 64 25 31 FF 9D 8E ? D7 84 63 B5 03 E2 9E 06 >>>>> ?..d%1.....c..... >>>>> 0020: 3C 8C C2 22 F3 7A EE 55 ? AD 8C F5 5C F6 04 9A E2 >>>>> ?<..".z.U...\.... >>>>> 0030: 6D BA E4 C4 9F 97 C3 DA ? BC D3 CB 8C 2C 9E BF FD >>>>> ?m...........,... >>>>> 0040: A3 9F C1 A2 79 51 75 B7 ? AE B6 ? ? ? ? ? ? ? ? ? ?....yQu... >>>>> ) >>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.770 >>>>> CEST|SSLCipher.java:1978|KeyLimit write side: algorithm = >>>>> AES/GCM/NOPADDING:KEYUPDATE >>>>> countdown value = 137438953472 >>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: 17 03 03 00 13 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ..... >>>>> ) >>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 >>>>> CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, >>>>> length = 19 >>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 >>>>> CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>> 0000: 4F 0D C7 65 8B 24 B4 92 ? A2 26 31 8C 81 AF 8F F7 >>>>> ?O..e.$...&1..... >>>>> 0010: AC C3 B3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ... >>>>> ) >>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 >>>>> CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, >>>>> length = 19 >>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.773 >>>>> CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>>> 0000: 02 74 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.t >>>>> ) >>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.774 >>>>> CEST|Alert.java:232|Received alert message ( >>>>> "Alert": { >>>>> "level" ? ? ?: "fatal", >>>>> "description": "certificate_required" >>>>> } >>>>> ) >>>>> javax.net.ssl|ERROR|0C|Thread-0|2018-09-17 11:51:54.774 >>>>> CEST|TransportContext.java:313|Fatal (CERTIFICATE_REQUIRED): >>>>> Received fatal alert: certificate_required ( >>>>> "throwable" : { >>>>> javax.net.ssl.SSLHandshakeException: Received fatal alert: >>>>> certificate_required >>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>>> at >>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>>>> >>>>> at >>>>> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >>>>> at >>>>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >>>>> >>>>> at >>>>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>>>> at >>>>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) >>>>> >>>>> at >>>>> java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) >>>>> >>>>> at >>>>> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) >>>>> >>>>> at >>>>> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) >>>>> >>>>> at ReproducerClient$1.run(ReproducerClient.java:33) >>>>> at java.base/java.lang.Thread.run(Thread.java:834)} >>>>> ) >>>>> javax.net.ssl|ALL|0C|Thread-0|2018-09-17 11:51:54.775 >>>>> CEST|SSLSessionImpl.java:753|Invalidated session: >>>>> ??Session(1537177914725|TLS_AES_128_GCM_SHA256) >>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 >>>>> CEST|SSLSocketImpl.java:1361|close the underlying socket >>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 >>>>> CEST|SSLSocketImpl.java:1380|close the SSL connection (initiative) >>>>> javax.net.ssl|WARNING|0C|Thread-0|2018-09-17 11:51:54.777 >>>>> CEST|SSLSocketImpl.java:1289|handling exception ( >>>>> "throwable" : { >>>>> javax.net.ssl.SSLHandshakeException: Received fatal alert: >>>>> certificate_required >>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>>> at >>>>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>>>> >>>>> at >>>>> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >>>>> at >>>>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >>>>> >>>>> at >>>>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>>>> at >>>>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) >>>>> >>>>> at >>>>> java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) >>>>> >>>>> at >>>>> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) >>>>> >>>>> at >>>>> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) >>>>> >>>>> at ReproducerClient$1.run(ReproducerClient.java:33) >>>>> at java.base/java.lang.Thread.run(Thread.java:834)} >>>>> ) >>>>> Bye >>>>> Norman >>>>>> On 16. Sep 2018, at 15:54, Norman Maurer >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> Will do, ?but not before tomorrow (I will also share the client >>>>>> side code). That said there is nothing special about the keymanager. >>>>>> Like I said before it sends the cert when using ?want client >>>>>> with?, it just seems it may be too late. >>>>>> >>>>>> >>>>>> Bye >>>>>> Norman >>>>>> >>>>>>> Am 15.09.2018 um 08:26 schrieb Bradford Wetmore >>>>>>> >>>>>> >: >>>>>>> >>>>>>> >>>>>>> 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)) >>>>>>>>>>> 0000 - 16 03 03 01 60 ???????????????????????????????????....` >>>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 >>>>>>>>>>> (0x160)) >>>>>>>>>>> 0000 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 >>>>>>>>>>> ??...\..".... at 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..o....K...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)) >>>>>>>>>>> 0000 - 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|J....n....] >>>>>>>>>>> 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..o....K.. >>>>>>>>>>> 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 >>>>>>>>>>> ??MT....B5S[...... >>>>>>>>>>> 00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65 >>>>>>>>>>> ??.(.m...8.wrs%&.e >>>>>>>>>>> 00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96 >>>>>>>>>>> ??X........P...... >>>>>>>>>>> 0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9 >>>>>>>>>>> ??.;<..AX...:(..a. >>>>>>>>>>> 0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5 >>>>>>>>>>> ??.h...f.[..... .. >>>>>>>>>>> 0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb >>>>>>>>>>> ??.RD...c=........ >>>>>>>>>>> 0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6 >>>>>>>>>>> ??.*O[J.wx.u. .... >>>>>>>>>>> 0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee >>>>>>>>>>> ??...VV._.e.~n=.f. >>>>>>>>>>> 0150 - 10 4c f7 6d 9b 73 86 14-7a 81 f8 b1 27 af 08 ee >>>>>>>>>>> ??.L.m.s..z...'... >>>>>>>>>>> 0160 - ce 26 90 34 73 3d b7 45-8d 85 29 a8 65 19 e7 02 >>>>>>>>>>> ??.&.4s=.E..).e... >>>>>>>>>>> 0170 - e5 55 4a 27 f1 b1 6a a4-11 cc 6c af 78 6d 22 5c >>>>>>>>>>> ??.UJ'..j...l.xm"\ >>>>>>>>>>> 0180 - 33 73 e3 ad 7f 8d 1b d3-75 95 66 64 2d 0e f1 3e >>>>>>>>>>> ??3s......u.fd-..> >>>>>>>>>>> 0190 - c2 30 df a1 7e ce a3 50-c3 4e 68 f6 36 b3 4e 45 >>>>>>>>>>> ??.0..~..P.Nh.6.NE >>>>>>>>>>> 01a0 - 9c ac e9 f2 0d 7c e3 73-6a 40 ab 6e 6e f9 d8 20 >>>>>>>>>>> ??.....|.sj at .nn.. >>>>>>>>>>> 01b0 - 9c f3 04 32 cd 1d df 18-e5 4d e3 e8 b1 38 59 f8 >>>>>>>>>>> ??...2.....M...8Y. >>>>>>>>>>> 01c0 - 28 67 2e ca af a2 8b 88-ce ca 48 a6 07 2b a6 9a >>>>>>>>>>> ??(g........H..+.. >>>>>>>>>>> 01d0 - 0e 88 5b d7 0b d9 31 77-97 8d 6c 2b f5 60 24 61 >>>>>>>>>>> ??..[...1w..l+.`$a >>>>>>>>>>> 01e0 - a8 5c 47 5d 7c 66 f0 9b-1f e4 76 93 38 f6 78 3e >>>>>>>>>>> ??.\G]|f....v.8.x> >>>>>>>>>>> 01f0 - 69 29 72 f9 d9 4b cb 05-03 e4 f2 d6 24 e1 91 ee >>>>>>>>>>> ??i)r..K......$... >>>>>>>>>>> 0200 - 85 37 d7 7b c3 5c 35 90-08 cd b1 cc 76 11 fc 00 >>>>>>>>>>> ??.7.{.\5.....v... >>>>>>>>>>> 0210 - 12 7e 89 7b 70 e6 ca fe-0b 26 b6 bb ac fe 4b 9f >>>>>>>>>>> ??.~.{p....&....K. >>>>>>>>>>> 0220 - ec cf 41 69 42 3a 3e 41-f9 b0 c0 93 5b 70 1f c7 >>>>>>>>>>> ??..AiB:>A....[p.. >>>>>>>>>>> 0230 - 11 00 3d ec 66 5a 1a ca-31 89 22 27 02 dd a0 cb >>>>>>>>>>> ??..=.fZ..1."'.... >>>>>>>>>>> 0240 - 39 14 25 ee 30 44 e8 62-97 bf 8e 16 63 40 c4 11 >>>>>>>>>>> ??9.%.0D.b....c at .. >>>>>>>>>>> 0250 - a6 d9 32 b1 3c 86 35 bb-9f f1 4d 71 9f a5 4f 78 >>>>>>>>>>> ??..2.<.5...Mq..Ox >>>>>>>>>>> 0260 - 0a e8 96 dd 4d 10 c3 48-f2 db 67 57 2d cd dc 23 >>>>>>>>>>> ??....M..H..gW-..# >>>>>>>>>>> 0270 - 3a 8d 6a 61 47 20 ff c8-33 cd e9 f7 47 4c 68 4f >>>>>>>>>>> ??:.jaG ..3...GLhO >>>>>>>>>>> 0280 - 19 2f 8b e3 b1 90 ac 66-a7 cf 5c e6 d2 05 21 25 >>>>>>>>>>> ??./.....f..\...!% >>>>>>>>>>> 0290 - d2 d8 f0 43 8c 55 01 ef-d6 8f c0 27 87 0d 21 d5 >>>>>>>>>>> ??...C.U.....'..!. >>>>>>>>>>> 02a0 - 2b 2b 6f db e8 85 ea cd-6e 9c 5d 56 d5 31 c1 f2 >>>>>>>>>>> ??++o.....n.]V.1.. >>>>>>>>>>> 02b0 - 97 2f 5a 83 7a 2b 71 03-65 e0 b6 4a 56 37 de e1 >>>>>>>>>>> ??./Z.z+q.e..JV7.. >>>>>>>>>>> 02c0 - 80 3a c4 cc 5a ac 3b 9a-7a bf f7 6b fe a8 69 e9 >>>>>>>>>>> ??.:..Z.;.z..k..i. >>>>>>>>>>> 02d0 - 58 09 59 bd 46 bd d2 a3-bc ad 1c 10 53 c8 29 7b >>>>>>>>>>> ??X.Y.F.......S.){ >>>>>>>>>>> 02e0 - be 63 00 d6 e5 a8 d6 ab-b2 bc 8b e1 2c 0e 24 2a >>>>>>>>>>> ??.c..........,.$* >>>>>>>>>>> 02f0 - c2 31 2d d8 6e 1f 19 93-d7 54 e1 1e 28 ce 72 83 >>>>>>>>>>> ??.1-.n....T..(.r. >>>>>>>>>>> 0300 - ff 05 18 f2 fc e9 0c b3-0c 1b d5 96 c2 d8 fc 76 >>>>>>>>>>> ??...............v >>>>>>>>>>> 0310 - 37 a9 5a ef 8e e9 b6 71-21 f3 bd c1 85 23 85 22 >>>>>>>>>>> ??7.Z....q!....#." >>>>>>>>>>> 0320 - 3d c4 1c c9 31 8b 7e 00-8f 8e b4 9f 05 d4 80 6b >>>>>>>>>>> ??=...1.~........k >>>>>>>>>>> 0330 - 98 4c a8 82 68 ff 1a a5-28 e2 9b 03 a1 a7 b1 00 >>>>>>>>>>> ??.L..h...(....... >>>>>>>>>>> 0340 - 02 2b 2d e2 e1 87 8c e8-0a fb 0b 79 54 ca 3d d5 >>>>>>>>>>> ??.+-........yT.=. >>>>>>>>>>> 0350 - 6a dd b7 b7 87 42 2b 47-49 da e9 0a 82 0a c9 8f >>>>>>>>>>> ??j....B+GI....... >>>>>>>>>>> 0360 - 57 f7 1e 03 ca 8d 16 bc-21 3a 6a ee b9 b8 fa f0 >>>>>>>>>>> ??W.......!:j..... >>>>>>>>>>> 0370 - d9 18 35 9f 35 ac d8 6e-9a 8a 0d 56 10 1e 1f 5a >>>>>>>>>>> ??..5.5..n...V...Z >>>>>>>>>>> 0380 - ba ec e4 fe 1a 92 b4 31-35 43 1d 99 b9 12 fa ff >>>>>>>>>>> ??.......15C...... >>>>>>>>>>> 0390 - 99 2b 88 e0 58 ec 9c dc-8f 67 ef 2a c2 e2 64 5d >>>>>>>>>>> ??.+..X....g.*..d] >>>>>>>>>>> 03a0 - 66 76 1c d0 aa 00 30 59-b1 f5 b1 55 9f ad 60 e9 >>>>>>>>>>> ??fv....0Y...U..`. >>>>>>>>>>> 03b0 - 3d 03 1e d0 8b 4d bf 74-ac bc bb 1c 83 14 c5 e0 >>>>>>>>>>> ??=....M.t........ >>>>>>>>>>> 03c0 - f4 fc 70 9e f4 22 a0 78-04 fe c8 b1 17 65 f6 94 >>>>>>>>>>> ??..p..".x.....e.. >>>>>>>>>>> 03d0 - 47 82 50 4a b6 32 74 ae-5b 38 5a 2e d9 b0 6a 45 >>>>>>>>>>> ??G.PJ.2t.[8Z...jE >>>>>>>>>>> 03e0 - 74 e8 f0 22 fe d3 b0 11-c3 fd 72 4f da 77 7a ba >>>>>>>>>>> ??t.."......rO.wz. >>>>>>>>>>> 03f0 - 26 3e 61 0c 63 21 17 a6-b2 13 6e 71 5c f2 0d ad >>>>>>>>>>> ??&>a.c!....nq\... >>>>>>>>>>> 0400 - f2 d1 19 71 51 9e a4 1b-b0 30 24 e0 71 7d 87 80 >>>>>>>>>>> ??...qQ....0$.q}.. >>>>>>>>>>> 0410 - a9 5a e9 bc db e4 4f 50-4d a1 bc bc 2c 4b 66 98 >>>>>>>>>>> ??.Z....OPM...,Kf. >>>>>>>>>>> 0420 - d4 e4 b0 76 0f d2 db a5-a5 39 9e f2 5b ea 34 c1 >>>>>>>>>>> ??...v.....9..[.4. >>>>>>>>>>> 0430 - 62 ab 47 51 3b 37 17 45-54 31 18 f3 f1 ca 17 03 >>>>>>>>>>> ??b.GQ;7.ET1...... >>>>>>>>>>> 0440 - 03 01 19 dd 50 50 f5 0c-f2 c9 3c b4 8f 63 cc 4a >>>>>>>>>>> ??....PP....<..c.J >>>>>>>>>>> 0450 - a7 50 c9 91 9b 79 9a 2a-5c 47 d3 77 f6 56 69 90 >>>>>>>>>>> ??.P...y.*\G.w.Vi. >>>>>>>>>>> 0460 - 98 cd ff bd c1 2a 49 fc-0d d4 7e cc 7e 44 af c4 >>>>>>>>>>> ??.....*I...~.~D.. >>>>>>>>>>> 0470 - 61 47 e0 c1 76 b1 8c 2e-df 7e d0 82 e1 89 1f 04 >>>>>>>>>>> ??aG..v....~...... >>>>>>>>>>> 0480 - ae 64 bd 71 4d ae 1c 3c-e3 d3 39 5d 61 2a ea 70 >>>>>>>>>>> ??.d.qM..<..9]a*.p >>>>>>>>>>> 0490 - 8c 31 6d a0 b1 72 a8 7a-5c 9c 11 08 b8 4d a5 c4 >>>>>>>>>>> ??.1m..r.z\....M.. >>>>>>>>>>> 04a0 - ad 1b 38 4a 6a 02 28 d4-d1 0f c8 9f 0b b3 02 18 >>>>>>>>>>> ??..8Jj.(......... >>>>>>>>>>> 04b0 - 82 2b bd 46 82 04 64 f0-41 b2 da f5 cd 9c f7 f3 >>>>>>>>>>> ??.+.F..d.A....... >>>>>>>>>>> 04c0 - 73 30 58 ca 12 ec ea 90-85 1c 75 09 0a 70 b8 80 >>>>>>>>>>> ??s0X.......u..p.. >>>>>>>>>>> 04d0 - 3d 02 17 3e 9b 83 04 b5-dd 9e e6 18 17 65 83 a5 >>>>>>>>>>> ??=..>.........e.. >>>>>>>>>>> 04e0 - 59 7d 4b 98 da bd 8b aa-d6 aa c5 1c 7d 87 56 e3 >>>>>>>>>>> ??Y}K.........}.V. >>>>>>>>>>> 04f0 - 74 d8 e9 7b eb b3 3d f7-7c 3c 0a e9 a8 2e 04 0d >>>>>>>>>>> ??t..{..=.|<...... >>>>>>>>>>> 0500 - 6a e7 83 e0 ec 99 43 6a-8b 1c 73 59 7a c8 cd 6e >>>>>>>>>>> ??j.....Cj..sYz..n >>>>>>>>>>> 0510 - 4a 14 73 ff 9a fb 71 94-d5 50 a9 d9 e0 dd 02 4c >>>>>>>>>>> ??J.s...q..P.....L >>>>>>>>>>> 0520 - 2b 67 9e da 9e fa 2d 67-49 df 13 10 ed 35 3e 73 >>>>>>>>>>> ??+g....-gI....5>s >>>>>>>>>>> 0530 - 07 20 17 fb 0b ef f6 d0-b7 68 1c 65 21 a6 e3 3b ??. >>>>>>>>>>> .......h.e!..; >>>>>>>>>>> 0540 - bf 7b 84 cd 9e f5 76 2a-0d 4f b8 c3 c8 15 08 e9 >>>>>>>>>>> ??.{....v*.O...... >>>>>>>>>>> 0550 - 0f 3c 50 49 12 97 a8 d7-f1 a3 16 da 17 03 03 00 >>>>>>>>>>> ??.>>>>>>>>>> 0560 - 35 22 dd a2 9d 25 98 2c-35 b8 00 29 fa a1 dd ba >>>>>>>>>>> ??5"...%.,5..).... >>>>>>>>>>> 0570 - 72 b9 fe e5 85 85 f0 f1-3b 4e f5 7c 58 c8 2a da >>>>>>>>>>> ??r.......;N.|X.*. >>>>>>>>>>> 0580 - d2 75 94 3b c1 7a 7c 7e-db 5b fe 8a 2d 3f 8c 9a >>>>>>>>>>> ??.u.;.z|~.[..-?.. >>>>>>>>>>> 0590 - 6e 79 ab 2b ff 1a ????????????????????????????????ny.+.. >>>>>>>>>>> SSL_accept:SSLv3/TLS write finished >>>>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>>>>>>> 0000 - 14 03 03 00 01 ???????????????????????????????????..... >>>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (1 bytes => 1 (0x1)) >>>>>>>>>>> 0000 - 01 ???????????????????????????????????????????????. >>>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>>>>>>> 0000 - 17 03 03 00 3d ???????????????????????????????????....= >>>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (61 bytes => 61 >>>>>>>>>>> (0x3D)) >>>>>>>>>>> 0000 - 38 e7 bb 2c 5b af b6 5f-37 d8 3e 7e bb f4 04 f5 >>>>>>>>>>> ??8..,[.._7.>~.... >>>>>>>>>>> 0010 - e1 28 b5 e5 07 5a ec ce-da 2f f3 b6 45 61 cf ef >>>>>>>>>>> ??.(...Z.../..Ea.. >>>>>>>>>>> 0020 - 90 fb 57 b8 f3 20 45 27-60 d4 26 51 38 77 e4 bc >>>>>>>>>>> ??..W.. E'`.&Q8w.. >>>>>>>>>>> 0030 - b7 64 d4 8b 73 25 41 9e-fe d3 9d 5f 53 >>>>>>>>>>> ???????????.d..s%A...._S >>>>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>>>> write to 0x7fe400f050c0 [0x7fe403018a00] (24 bytes => 24 (0x18)) >>>>>>>>>>> 0000 - 17 03 03 00 13 25 85 60-eb 7d c1 a8 15 49 d5 63 >>>>>>>>>>> ??.....%.`.}...I.c >>>>>>>>>>> 0010 - 18 7f c6 ac ed 7f df 77- >>>>>>>>>>> ?????????????????????????.......w >>>>>>>>>>> SSL3 alert write:fatal:unknown >>>>>>>>>>> SSL_accept:error in error >>>>>>>>>>> ERROR >>>>>>>>>>> 140736092021632:error:1417C0C7:SSL >>>>>>>>>>> routines:tls_process_client_certificate:peer did not return a >>>>>>>>>>> certificate:ssl/statem/statem_srvr.c:3654: >>>>>>>>>>> shutting down SSL >>>>>>>>>>> CONNECTION CLOSED >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> When using openssl s_client all works as expected tho (thats >>>>>>>>>>> also true if I use my native implementation on the client and >>>>>>>>>>> server side that uses openssl): >>>>>>>>>>> >>>>>>>>>>> ./bin/openssl s_client -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 >>>>>>>>>>> ?-state -tls1_3 -connect localhost:8443 >>>>>>>>>>> >>>>>>>>>>> The interesting thing is if I use ?-verify 1? and not >>>>>>>>>>> ?-Verify 1? with openssl which tells it I want to request a >>>>>>>>>>> certificate but will also process if none is provided I >>>>>>>>>>> receive the certificate at some point as seen here: >>>>>>>>>>> >>>>>>>>>>> SSL_accept:before SSL initialization >>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>>> 0000 - 16 03 03 01 60 ???????????????????????????????????....` >>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (352 bytes => 352 >>>>>>>>>>> (0x160)) >>>>>>>>>>> 0000 - 01 00 01 5c 03 03 61 c0-b3 ed 88 65 e6 cf 11 3f >>>>>>>>>>> ??...\..a....e...? >>>>>>>>>>> 0010 - c0 e0 f8 df a6 63 32 c2-ab 3d 61 6f 41 ed b1 4b >>>>>>>>>>> ??.....c2..=aoA..K >>>>>>>>>>> 0020 - 53 0e 83 e5 a1 b8 20 c7-1b 8c b8 e6 b5 da 4e 4e >>>>>>>>>>> ??S..... .......NN >>>>>>>>>>> 0030 - 3f 3c 61 7a ad 58 23 94-a7 32 79 2f db 9f 21 c0 >>>>>>>>>>> ???>>>>>>>>>> 0040 - 8e 0c c5 ce b1 c2 a4 00-14 c0 2c c0 2b c0 2f c0 >>>>>>>>>>> ??..........,.+./. >>>>>>>>>>> 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 52 dc d6 47 6e >>>>>>>>>>> ??.3.G.E...A.R..Gn >>>>>>>>>>> 0120 - a1 de 9c 71 c2 54 0e 5c-9b 57 fb c8 aa 3f 19 f7 >>>>>>>>>>> ??...q.T.\.W...?.. >>>>>>>>>>> 0130 - d3 a4 25 12 fa 3f 6c 6d-95 30 66 ca 63 b7 a1 dd >>>>>>>>>>> ??..%..?lm.0f.c... >>>>>>>>>>> 0140 - ae 9f 99 d6 a8 6b 20 4f-29 7a 74 58 ad 58 de 12 >>>>>>>>>>> ??.....k O)ztX.X.. >>>>>>>>>>> 0150 - d7 a5 9b 69 dc 27 ac ec-9e d4 04 ff 01 00 01 00 >>>>>>>>>>> ??...i.'.......... >>>>>>>>>>> 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 0x7fdc58809fb0 [0x7fdc59025e00] (1430 bytes => 1430 >>>>>>>>>>> (0x596)) >>>>>>>>>>> 0000 - 16 03 03 00 9b 02 00 00-97 03 03 8b c8 62 48 6c >>>>>>>>>>> ??.............bHl >>>>>>>>>>> 0010 - f5 7c 73 d9 17 f8 63 a2-11 27 40 93 09 26 53 06 >>>>>>>>>>> ??.|s...c..'@..&S. >>>>>>>>>>> 0020 - b3 62 df 46 26 b6 dc 59-29 b5 58 20 c7 1b 8c b8 >>>>>>>>>>> ??.b.F&..Y).X .... >>>>>>>>>>> 0030 - e6 b5 da 4e 4e 3f 3c 61-7a ad 58 23 94 a7 32 79 >>>>>>>>>>> ??...NN?>>>>>>>>>> 0040 - 2f db 9f 21 c0 8e 0c c5-ce b1 c2 a4 13 01 00 00 >>>>>>>>>>> ??/..!............ >>>>>>>>>>> 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 >>>>>>>>>>> ??O.+.....3.E...A. >>>>>>>>>>> 0060 - 07 63 1c 19 53 89 68 a8-0f ea 9e 4c 18 6f 2a ad >>>>>>>>>>> ??.c..S.h....L.o*. >>>>>>>>>>> 0070 - 2a df eb 17 a2 08 94 c6-e3 c5 97 ae 0f c1 1a d7 >>>>>>>>>>> ??*............... >>>>>>>>>>> 0080 - 0d d7 2e 6d 77 3d 30 a0-07 db 70 35 bb 37 dd 1e >>>>>>>>>>> ??...mw=0...p5.7.. >>>>>>>>>>> 0090 - b6 f3 4d cb 13 97 7c 11-63 98 e8 64 2d a7 e6 cc >>>>>>>>>>> ??..M...|.c..d-... >>>>>>>>>>> 00a0 - 14 03 03 00 01 01 17 03-03 00 27 a3 73 d2 ee 2c >>>>>>>>>>> ??..........'.s.., >>>>>>>>>>> 00b0 - 2f 9c 8f 95 7f ca a3 89-bc b4 b3 b2 3c 8b 23 ef >>>>>>>>>>> ??/...........<.#. >>>>>>>>>>> 00c0 - 36 66 23 c9 09 02 33 0d-dc 5d 36 61 44 89 8b ef >>>>>>>>>>> ??6f#...3..]6aD... >>>>>>>>>>> 00d0 - fd 13 17 03 03 00 42 f2-5b 3c 0c 27 5e 7f 97 4f >>>>>>>>>>> ??......B.[<.'^..O >>>>>>>>>>> 00e0 - 0f de 8c b9 0a a1 41 c7-c2 1e 92 99 6a d5 bd 12 >>>>>>>>>>> ??......A.....j... >>>>>>>>>>> 00f0 - 38 b6 b7 93 33 e9 8e 0f-44 93 f0 69 58 b6 41 22 >>>>>>>>>>> ??8...3...D..iX.A" >>>>>>>>>>> 0100 - 46 e2 4a d5 d6 32 2b b8-a7 ae 3a c2 c5 2f e6 35 >>>>>>>>>>> ??F.J..2+...:../.5 >>>>>>>>>>> 0110 - 11 0c f1 9a 35 2a 87 ed-9e 17 03 03 03 20 a7 e2 >>>>>>>>>>> ??....5*....... .. >>>>>>>>>>> 0120 - fe ba c7 10 5b 9c cd 94-67 19 37 2d 46 59 ab 56 >>>>>>>>>>> ??....[...g.7-FY.V >>>>>>>>>>> 0130 - 6b dd a4 10 61 cc ed f1-71 a7 2d 6a 41 2e 2b da >>>>>>>>>>> ??k...a...q.-jA.+. >>>>>>>>>>> 0140 - d1 35 fc 01 df 49 e5 90-1d 9b b2 03 0a 81 58 18 >>>>>>>>>>> ??.5...I........X. >>>>>>>>>>> 0150 - 96 a1 db 31 19 98 35 5c-87 8f 6e 32 0a e6 c0 aa >>>>>>>>>>> ??...1..5\..n2.... >>>>>>>>>>> 0160 - 9e 8e 72 e2 34 b3 b7 a3-d6 d1 66 c7 ce 93 fe 78 >>>>>>>>>>> ??..r.4.....f....x >>>>>>>>>>> 0170 - 17 c4 71 7c 42 15 c8 af-dc 4f 50 42 51 80 fc bf >>>>>>>>>>> ??..q|B....OPBQ... >>>>>>>>>>> 0180 - fc 54 d5 d8 59 20 9a 90-c4 78 97 9c 2d 4a d5 58 >>>>>>>>>>> ??.T..Y ...x..-J.X >>>>>>>>>>> 0190 - be 81 79 23 59 22 9d 27-f8 bd a0 b2 98 b3 47 82 >>>>>>>>>>> ??..y#Y".'......G. >>>>>>>>>>> 01a0 - d3 52 b5 b5 91 ab 5c 76-52 c5 a5 95 2d 03 1c b7 >>>>>>>>>>> ??.R....\vR...-... >>>>>>>>>>> 01b0 - 64 4d 0b 88 7f 15 0b c8-a8 90 50 9a b6 b1 9f b7 >>>>>>>>>>> ??dM........P..... >>>>>>>>>>> 01c0 - 40 09 f2 5f 39 f8 9a 06-21 4d 67 10 0a 67 08 b6 >>>>>>>>>>> ??@.._9...!Mg..g.. >>>>>>>>>>> 01d0 - b5 9a 25 8c d5 ca 31 6a-8a 6b 01 93 7d 6f 1e 52 >>>>>>>>>>> ??..%...1j.k..}o.R >>>>>>>>>>> 01e0 - 98 96 9d fb e8 c1 07 ab-57 98 2d 1e 75 77 ef c2 >>>>>>>>>>> ??........W.-.uw.. >>>>>>>>>>> 01f0 - 49 78 e0 b9 2b 32 23 7e-95 4d 3e 27 00 61 86 0c >>>>>>>>>>> ??Ix..+2#~.M>'.a.. >>>>>>>>>>> 0200 - 47 c7 79 e4 ee 9d ba c0-ea 62 f1 0d 8e 4a 91 30 >>>>>>>>>>> ??G.y......b...J.0 >>>>>>>>>>> 0210 - bc 4f 5a 98 26 30 66 ec-c4 63 8f 28 d5 1c 61 23 >>>>>>>>>>> ??.OZ.&0f..c.(..a# >>>>>>>>>>> 0220 - ea e9 90 4e 36 d9 fa 31-7b 14 27 22 0a ae 9f 64 >>>>>>>>>>> ??...N6..1{.'"...d >>>>>>>>>>> 0230 - 40 3d e5 a0 5c 9d 3c 04-71 09 b0 7a 6b 51 a0 9c >>>>>>>>>>> ??@=..\.<.q..zkQ.. >>>>>>>>>>> 0240 - c0 61 32 ce 15 62 8e 29-b1 59 91 c0 17 2c b3 c5 >>>>>>>>>>> ??.a2..b.).Y...,.. >>>>>>>>>>> 0250 - f9 ed 07 65 3d 11 de 98-de 62 36 50 74 37 af 2d >>>>>>>>>>> ??...e=....b6Pt7.- >>>>>>>>>>> 0260 - 7d 86 55 c4 3e a2 83 ab-47 8d f2 b2 8d 1d 75 83 >>>>>>>>>>> ??}.U.>...G.....u. >>>>>>>>>>> 0270 - b5 e4 41 87 a7 a3 85 b0-5e 4e 2e 9c 8c b0 1b 83 >>>>>>>>>>> ??..A.....^N...... >>>>>>>>>>> 0280 - 7b 54 79 c9 60 ea 7d ed-06 fa dd 24 40 f1 53 9e >>>>>>>>>>> ??{Ty.`.}....$@.S. >>>>>>>>>>> 0290 - 43 79 25 53 9c c7 6e 95-ab 9f 96 59 cd b9 7b a8 >>>>>>>>>>> ??Cy%S..n....Y..{. >>>>>>>>>>> 02a0 - a0 23 13 69 db a9 c9 e7-1a 8e e1 9b 54 94 1c 44 >>>>>>>>>>> ??.#.i........T..D >>>>>>>>>>> 02b0 - 50 08 8b dd eb 4e 2b bb-d7 c9 c2 33 8c a1 b3 65 >>>>>>>>>>> ??P....N+....3...e >>>>>>>>>>> 02c0 - 06 e6 9d ac 11 16 21 58-40 8d 59 e6 67 e5 31 02 >>>>>>>>>>> ??......!X at .Y.g.1. >>>>>>>>>>> 02d0 - 15 8d 29 80 20 66 ba c3-56 93 95 5c 65 4b 41 00 ??..). >>>>>>>>>>> f..V..\eKA. >>>>>>>>>>> 02e0 - c5 71 12 12 f5 20 4f 59-be 77 06 10 6e 48 85 5c >>>>>>>>>>> ??.q... OY.w..nH.\ >>>>>>>>>>> 02f0 - ff a2 c4 ae fb 4d 95 f5-cc f6 61 20 33 b7 92 1d >>>>>>>>>>> ??.....M....a 3... >>>>>>>>>>> 0300 - ac a8 f1 b2 b0 88 c6 7b-8b 00 53 30 6d 4a d1 42 >>>>>>>>>>> ??.......{..S0mJ.B >>>>>>>>>>> 0310 - b3 3e 85 f5 84 e1 c6 ab-10 9d 61 03 46 ff 2d 81 >>>>>>>>>>> ??.>........a.F.-. >>>>>>>>>>> 0320 - 15 4f 84 d1 4c ee f4 a6-a0 ec 50 60 a0 d1 ff df >>>>>>>>>>> ??.O..L.....P`.... >>>>>>>>>>> 0330 - 8a 97 f6 7d fb 8f fb 60-18 d4 f1 1f 92 4d d8 69 >>>>>>>>>>> ??...}...`.....M.i >>>>>>>>>>> 0340 - b1 92 97 44 0f 3c 8a aa-47 07 48 d4 07 2d 3e f2 >>>>>>>>>>> ??...D.<..G.H..->. >>>>>>>>>>> 0350 - c4 a7 16 35 a7 17 71 ef-98 84 24 67 12 58 30 3b >>>>>>>>>>> ??...5..q...$g.X0; >>>>>>>>>>> 0360 - 1d 41 8d e5 12 52 95 64-e5 88 35 99 d7 c3 58 40 >>>>>>>>>>> ??.A...R.d..5...X@ >>>>>>>>>>> 0370 - f9 55 9b 9f e5 33 15 70-41 d7 45 ba a4 fc 75 ea >>>>>>>>>>> ??.U...3.pA.E...u. >>>>>>>>>>> 0380 - a4 ae f0 68 ea 64 d8 f5-06 68 a9 75 22 4d 43 cc >>>>>>>>>>> ??...h.d...h.u"MC. >>>>>>>>>>> 0390 - ff 50 cc ac 6e fd 43 dd-eb e4 c8 dd 4b 6c 12 bb >>>>>>>>>>> ??.P..n.C.....Kl.. >>>>>>>>>>> 03a0 - f1 d4 5e 11 4a 86 90 0b-f8 3a 2e 23 db 61 5a 1f >>>>>>>>>>> ??..^.J....:.#.aZ. >>>>>>>>>>> 03b0 - 7e 11 00 92 21 68 1f b5-ab f2 f8 38 5e 62 ea f8 >>>>>>>>>>> ??~...!h.....8^b.. >>>>>>>>>>> 03c0 - da ef c2 6e a0 b8 20 e4-69 49 b3 1f 15 84 0b 9b >>>>>>>>>>> ??...n.. .iI...... >>>>>>>>>>> 03d0 - ce b0 6f 36 32 7f 7e bf-e8 d7 18 7a 58 60 f4 04 >>>>>>>>>>> ??..o62.~....zX`.. >>>>>>>>>>> 03e0 - cc 36 bf 06 cd ec e5 9b-19 03 96 09 fb af 8f c3 >>>>>>>>>>> ??.6.............. >>>>>>>>>>> 03f0 - 98 b4 02 aa e8 55 81 aa-c4 fe 06 81 30 a0 c7 b2 >>>>>>>>>>> ??.....U......0... >>>>>>>>>>> 0400 - f8 e2 30 00 d7 a0 54 7f-5f d7 ef a6 f8 41 58 34 >>>>>>>>>>> ??..0...T._....AX4 >>>>>>>>>>> 0410 - f5 f0 18 69 8d e6 7a 23-78 90 8f b1 05 c5 b5 7f >>>>>>>>>>> ??...i..z#x....... >>>>>>>>>>> 0420 - e0 f2 c7 fa c8 36 5b 53-7e cf e6 75 d3 54 b4 69 >>>>>>>>>>> ??.....6[S~..u.T.i >>>>>>>>>>> 0430 - 68 43 0d 6a d2 83 cc 13-6d ca bf 83 3c 90 17 03 >>>>>>>>>>> ??hC.j....m...<... >>>>>>>>>>> 0440 - 03 01 19 96 dc 49 26 ce-1d 8e 86 3d bd cb 00 5e >>>>>>>>>>> ??.....I&....=...^ >>>>>>>>>>> 0450 - ee f6 e7 1d 16 7a ca ef-fa 6d 16 40 b6 99 d0 c1 >>>>>>>>>>> ??.....z...m. at .... >>>>>>>>>>> 0460 - df 0b 5f 51 60 a8 24 e0-61 82 13 40 da 88 38 3a >>>>>>>>>>> ??.._Q`.$.a.. at ..8: >>>>>>>>>>> 0470 - 26 1d 80 51 c4 b1 95 35-95 3c 91 35 28 17 49 d8 >>>>>>>>>>> ??&..Q...5.<.5(.I. >>>>>>>>>>> 0480 - c3 45 be 32 98 3e 02 07-3b 01 20 2b 51 e1 1a 94 >>>>>>>>>>> ??.E.2.>..;. +Q... >>>>>>>>>>> 0490 - b9 be 96 aa 7a 13 09 ff-d5 a9 63 d4 6f 49 cb b5 >>>>>>>>>>> ??....z.....c.oI.. >>>>>>>>>>> 04a0 - 23 ab 7f 8c e2 63 f0 5c-5c 27 1e 04 a8 71 0c c0 >>>>>>>>>>> ??#....c.\\'...q.. >>>>>>>>>>> 04b0 - 89 cd ed 18 8d 5b 75 ac-af f3 68 6d cc ba 20 38 >>>>>>>>>>> ??.....[u...hm.. 8 >>>>>>>>>>> 04c0 - b5 7c 09 47 29 28 e2 26-57 57 1f f0 f3 18 fd 6f >>>>>>>>>>> ??.|.G)(.&WW.....o >>>>>>>>>>> 04d0 - 27 42 a4 e3 de bb e5 d6-09 7d 25 b1 98 97 ad 33 >>>>>>>>>>> ??'B.......}%....3 >>>>>>>>>>> 04e0 - 68 35 92 07 80 23 f1 66-20 5d 74 f3 02 c5 51 ff >>>>>>>>>>> ??h5...#.f ]t...Q. >>>>>>>>>>> 04f0 - 07 a9 e9 0e 3e 74 da 2e-8f 3b 16 be e6 94 1b 66 >>>>>>>>>>> ??....>t...;.....f >>>>>>>>>>> 0500 - bb b2 a2 1e 7c 7b ff 5e-a4 36 2a ba 0b cd 7f e9 >>>>>>>>>>> ??....|{.^.6*..... >>>>>>>>>>> 0510 - 86 bb 5e 30 f5 57 92 52-82 b6 2e da 71 b7 22 c2 >>>>>>>>>>> ??..^0.W.R....q.". >>>>>>>>>>> 0520 - 90 c4 69 46 07 df 6c 3f-05 8b 19 3e ce b9 75 0d >>>>>>>>>>> ??..iF..l?...>..u. >>>>>>>>>>> 0530 - 4b 97 37 ae 94 e2 d6 3c-91 e6 82 c7 a1 78 79 2c >>>>>>>>>>> ??K.7....<.....xy, >>>>>>>>>>> 0540 - 9a a3 d5 45 94 ad e2 c8-ab fd 81 ec 62 87 f7 75 >>>>>>>>>>> ??...E........b..u >>>>>>>>>>> 0550 - e3 70 79 8e 82 3b c5 45-0d d0 33 5f 17 03 03 00 >>>>>>>>>>> ??.py..;.E..3_.... >>>>>>>>>>> 0560 - 35 da e0 74 2a 06 41 5a-64 1e 54 94 29 73 43 3f >>>>>>>>>>> ??5..t*.AZd.T.)sC? >>>>>>>>>>> 0570 - e5 24 a8 ba b2 7e 6b 26-82 fc d9 f6 dd 19 05 4a >>>>>>>>>>> ??.$...~k&.......J >>>>>>>>>>> 0580 - 2c 1a f3 bb 16 1d 38 95-a6 d3 a8 58 f6 a3 41 c7 >>>>>>>>>>> ??,.....8....X..A. >>>>>>>>>>> 0590 - 92 44 35 24 25 0e ????????????????????????????????.D5$%. >>>>>>>>>>> SSL_accept:SSLv3/TLS write finished >>>>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>>> 0000 - 14 03 03 00 01 ???????????????????????????????????..... >>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (1 bytes => 1 (0x1)) >>>>>>>>>>> 0000 - 01 ???????????????????????????????????????????????. >>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>>> 0000 - 17 03 03 00 3d ???????????????????????????????????....= >>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (61 bytes => 61 >>>>>>>>>>> (0x3D)) >>>>>>>>>>> 0000 - ad dd 3e d9 ee ab 56 65-50 1c 72 2a d8 62 7f 90 >>>>>>>>>>> ??..>...VeP.r*.b.. >>>>>>>>>>> 0010 - 13 71 7d 37 39 40 fb 89-8f 05 4b 39 44 9d 4d 67 >>>>>>>>>>> ??.q}79 at ....K9D.Mg >>>>>>>>>>> 0020 - e3 41 29 b6 3e e8 fe 04-1b 8e eb 7a 4c e2 14 a0 >>>>>>>>>>> ??.A).>......zL... >>>>>>>>>>> 0030 - b1 c2 47 3f 94 35 ed ab-8a d1 75 3b ba >>>>>>>>>>> ???????????..G?.5....u;. >>>>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>>>> SSL_accept:SSLv3/TLS read client certificate >>>>>>>>>>> SSL_accept:SSLv3/TLS read finished >>>>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 >>>>>>>>>>> (0xDF)) >>>>>>>>>>> 0000 - 17 03 03 00 da 52 1f 48-00 f4 31 13 90 7f 9c c2 >>>>>>>>>>> ??.....R.H..1..... >>>>>>>>>>> 0010 - fc 70 1a fc f7 4a 48 e7-31 ad 37 ab b5 2b 4e 5c >>>>>>>>>>> ??.p...JH.1.7..+N\ >>>>>>>>>>> 0020 - e8 d8 6d e9 af 6c 4f c1-9e 7b ea ff ef b3 eb 74 >>>>>>>>>>> ??..m..lO..{.....t >>>>>>>>>>> 0030 - 27 67 10 21 66 5b 32 13-31 bc 99 d5 1c 6c 79 55 >>>>>>>>>>> ??'g.!f[2.1....lyU >>>>>>>>>>> 0040 - f3 3e f6 4b 07 4d a9 78-3d 12 8a f5 38 ef d9 f4 >>>>>>>>>>> ??.>.K.M.x=...8... >>>>>>>>>>> 0050 - 48 e0 2c 35 94 06 4f eb-09 e6 70 fb 59 95 7a c8 >>>>>>>>>>> ??H.,5..O...p.Y.z. >>>>>>>>>>> 0060 - 24 dd 24 e2 f9 63 b9 3c-f2 66 86 c4 73 44 53 fd >>>>>>>>>>> ??$.$..c.<.f..sDS. >>>>>>>>>>> 0070 - ca 67 8f 01 d6 db 70 f9-60 bc 50 11 51 72 dc 63 >>>>>>>>>>> ??.g....p.`.P.Qr.c >>>>>>>>>>> 0080 - 12 ca 4f 23 e2 c5 d1 1d-e5 b0 d4 ec 89 ca 28 be >>>>>>>>>>> ??..O#..........(. >>>>>>>>>>> 0090 - 9c 30 83 40 02 a4 62 a8-5c b3 20 1a ab 39 b7 7b >>>>>>>>>>> ??.0. at ..b.\. ..9.{ >>>>>>>>>>> 00a0 - 89 13 39 87 73 be a8 f8-60 13 31 0a 48 5c 79 b9 >>>>>>>>>>> ??..9.s...`.1.H\y. >>>>>>>>>>> 00b0 - cc 4a 51 e3 0d d2 b4 93-c0 1f 3a 22 b3 fa 24 a0 >>>>>>>>>>> ??.JQ.......:"..$. >>>>>>>>>>> 00c0 - 7c f6 76 79 d0 2d 5b 1a-ff a6 e9 e1 40 d3 b1 8c >>>>>>>>>>> ??|.vy.-[..... at ... >>>>>>>>>>> 00d0 - 0a fa fa de f3 8e d6 ad-9a 22 6b 67 0b 88 18 >>>>>>>>>>> ?????........."kg... >>>>>>>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 >>>>>>>>>>> (0xDF)) >>>>>>>>>>> 0000 - 17 03 03 00 da 46 aa ea-6a 37 b1 35 e8 41 c8 b3 >>>>>>>>>>> ??.....F..j7.5.A.. >>>>>>>>>>> 0010 - 84 25 af 1c 36 a3 6d 78-a4 44 4a 83 52 ef 13 7c >>>>>>>>>>> ??.%..6.mx.DJ.R..| >>>>>>>>>>> 0020 - 8f 18 d3 4c f8 22 c8 b3-ad d0 d0 5b 47 a0 43 da >>>>>>>>>>> ??...L.".....[G.C. >>>>>>>>>>> 0030 - d2 6e 04 8f dc c9 56 90-58 87 62 63 4c cc 31 ec >>>>>>>>>>> ??.n....V.X.bcL.1. >>>>>>>>>>> 0040 - b8 c9 18 be 41 32 e1 3c-00 41 2a f1 4d 5c 2d 44 >>>>>>>>>>> ??....A2.<.A*.M\-D >>>>>>>>>>> 0050 - 8c aa e1 f0 ed 38 ee 44-64 e5 fd ea 58 3b 84 5d >>>>>>>>>>> ??.....8.Dd...X;.] >>>>>>>>>>> 0060 - 83 39 21 2e fe 79 4d 76-10 65 87 0f 3c ac df 28 >>>>>>>>>>> ??.9!..yMv.e..<..( >>>>>>>>>>> 0070 - 49 f8 60 eb be 49 e4 0a-0b 6a 03 2b 9d cf 9b a5 >>>>>>>>>>> ??I.`..I...j.+.... >>>>>>>>>>> 0080 - 03 56 58 32 c2 b2 59 f9-0a 0d f0 ae af ff 20 19 >>>>>>>>>>> ??.VX2..Y....... . >>>>>>>>>>> 0090 - e5 6e e4 86 2f 5e 3f 7d-47 d5 73 ae 89 48 a7 66 >>>>>>>>>>> ??.n../^?}G.s..H.f >>>>>>>>>>> 00a0 - fb 2d 83 60 e8 8b ab 27-12 db 24 78 54 eb 14 2d >>>>>>>>>>> ??.-.`...'..$xT..- >>>>>>>>>>> 00b0 - b7 c6 17 2d 3c 91 57 ac-6e 35 b8 c3 fa c2 42 48 >>>>>>>>>>> ??...-<.W.n5....BH >>>>>>>>>>> 00c0 - 2a cb aa 98 32 89 8a ce-0c f7 cd 5e fb bf 6d 33 >>>>>>>>>>> ??*...2......^..m3 >>>>>>>>>>> 00d0 - 08 50 cf 1e 06 bb a1 98-be a4 a9 51 9a b0 34 >>>>>>>>>>> ?????.P.........Q..4 >>>>>>>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>>>>>> 0000 - 17 03 03 00 12 c5 9b 73-cc 91 7e 48 cb 25 31 a0 >>>>>>>>>>> ??.......s..~H.%1. >>>>>>>>>>> 0010 - 67 41 db bb 0f 62 d8 ?????????????????????????????gA...b. >>>>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>>>>>> 0000 - 17 03 03 00 12 0f dd 3f-c1 7c e6 b0 cc ea f0 13 >>>>>>>>>>> ??.......?.|...... >>>>>>>>>>> 0010 - 00 d8 01 de ef 7c bb ?????????????????????????????.....|. >>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>>> 0000 - 17 03 03 00 1e ???????????????????????????????????..... >>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (30 bytes => 30 >>>>>>>>>>> (0x1E)) >>>>>>>>>>> 0000 - d6 88 44 82 cb 23 16 ba-c9 a4 fb 55 51 08 90 c1 >>>>>>>>>>> ??..D..#.....UQ... >>>>>>>>>>> 0010 - bf bd a1 7f 0e 37 b0 b4-b5 df f1 07 6c 07 >>>>>>>>>>> ????????.....7......l. >>>>>>>>>>> I am a clientwrite to 0x7fdc58809fb0 [0x7fdc59021c03] (23 >>>>>>>>>>> bytes => 23 (0x17)) >>>>>>>>>>> 0000 - 17 03 03 00 12 c0 70 5d-14 e7 69 57 0a d8 64 16 >>>>>>>>>>> ??......p]..iW..d. >>>>>>>>>>> 0010 - 0c 90 06 0f c3 4d 1d ?????????????????????????????.....M. >>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>>> 0000 - 17 03 03 00 13 ???????????????????????????????????..... >>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (19 bytes => 19 >>>>>>>>>>> (0x13)) >>>>>>>>>>> 0000 - 60 28 5b ff bb 0d 9f 96-9a 2d cb fd 60 eb 96 62 >>>>>>>>>>> ??`([......-..`..b >>>>>>>>>>> 0010 - 53 e6 25 ?????????????????????????????????????????S.% >>>>>>>>>>> SSL3 alert read:warning:close notify >>>>>>>>>>> DONE >>>>>>>>>>> shutting down SSL >>>>>>>>>>> CONNECTION CLOSED >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I am using the following JDK version on MacOS: >>>>>>>>>>> >>>>>>>>>>> ssl git:(cert_cb_openssl_1_1_1) ? >>>>>>>>>>> /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java >>>>>>>>>>> -version >>>>>>>>>>> java version "11" 2018-09-25 >>>>>>>>>>> Java(TM) SE Runtime Environment 18.9 (build 11+28) >>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) >>>>>>>>>>> >>>>>>>>>>> For this to work you will need to have openssl 1.1.1 installed. >>>>>>>>>>> >>>>>>>>>>> Any help would be welcome, >>>>>>>>>>> Norman >>>>>>>>>>> >>>>>>>>>>> [1] https://github.com/netty/netty-tcnative >>> >> From norman.maurer at googlemail.com Thu Sep 20 18:34:26 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Thu, 20 Sep 2018 11:34:26 -0700 Subject: TLSv.1.3 interropt problems with OpenSSL 1.1.1 when used on the client side with mutual auth In-Reply-To: <57cf1167-e988-0f37-a721-fe7a3918e4ec@oracle.com> References: <32bad254-1a8c-7933-d5a0-0b8ce3ed2f68@oracle.com> <05EF82F5-6506-4928-8030-B9BEEE64E1F1@googlemail.com> <0EB21A4C-7DFF-4878-9446-182DA35F0A8C@googlemail.com> <2dea4403-e019-613d-373e-75c789029cef@oracle.com> <422BC150-FBAE-4829-B375-637F27C671C4@googlemail.com> <499D9F15-3CF1-4FDC-80AB-5A73FCB744FD@googlemail.com> <9f43f386-ede9-3615-df30-19e0a851b991@oracle.com> <57cf1167-e988-0f37-a721-fe7a3918e4ec@oracle.com> Message-ID: Got it... just keep in mind that this bug make it kind of unusable on the client-side so I think it should be a high priority to fix it rather sooner then later. Especially as the fix is really a one line change Norman > Am 20.09.2018 um 11:30 schrieb Bradford Wetmore : > > Just to followup on your (Norman's) earlier question: > > On 9/19/2018, Norman wrote: > >> Is this just the > >> initial version set or do you not plan to fix it in Java11 ? > > and > > On 9/19/2018 9:34 AM, Xuelei Fan wrote: > > It is just a initial version set. > > Getting this fix into JDK 12 was easy as 12 is in the early development stages. However, the GA release of JDK 11 is very close now and the bar is high for any changes. > > That said, we are currently looking into which JDK 11 update release would be appropriate for this and a couple of other needed fixes. > > Hope this helps. > > Brad > > > > >> On 9/19/2018 9:34 AM, Xuelei Fan wrote: >> Hi Norman, >> It is just a initial version set. >> Thanks, >> Xuelei >>> On 9/19/2018 8:49 AM, Norman Maurer wrote: >>> I see this is now tracked as https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8210846?filter=allopenissues :) >>> >>> Just one question, I saw it list 12 as fix version. Is this just the initial version set or do you not plan to fix it in Java11 ? IMHO this is a quite an important thing to fix as otherwise you may run into issues when using SSL on the client-side as most real-world apps use OpenSSL on the server-side. >>> >>> Bye >>> Norman >>> >>> >>>> On 17. Sep 2018, at 10:44, Norman Maurer > wrote: >>>> >>>> Of course not? >>>> >>>> ID: 9057280 >>>> >>>> Thanks >>>> Norman >>>> >>>> >>>>> On 17. Sep 2018, at 19:35, Xuelei Fan > wrote: >>>>> >>>>> Hi Norman, >>>>> >>>>> Thank you so much for the reproducing code. Would you mind file a bug for this issue? >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>>> On 9/17/2018 3:39 AM, Norman Maurer wrote: >>>>>> Hi all, >>>>>> As requested I pushed a pure JDK reproducer to GitHub which you can easily use to reproduce the problem. All the details how to run it etc are in the README.md file. I also included a server to show that all works if we use the JDK on the client side and server side. >>>>>> Also as stated before you will see that the cert will be send even if you use OpenSSL on the serverside if you replace ?-Verify 1? with ?-verify 1? (which is kind of the same as setWantClientAuth(true)). >>>>>> Please don't hesitate to ping me if you need any more details or have any more questions. >>>>>> https://github.com/normanmaurer/jdktls13bugreproducer >>>>>> Here is the output with debugging enabled on the client side. >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.515 CEST|SSLContextImpl.java:427|System property jdk.tls.client.cipherSuites is set to 'null' >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.529 CEST|SSLContextImpl.java:427|System property jdk.tls.server.cipherSuites is set to 'null' >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.563 CEST|SSLCipher.java:437|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.577 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.577 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.578 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.579 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.580 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.580 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.581 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_RC4_128_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_RC4_128_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.582 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_RC4_128_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_RC4_128_MD5 >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_RC4_128_MD5 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.583 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_anon_WITH_RC4_128_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_WITH_RC4_128_MD5 >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_WITH_RC4_128_MD5 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.584 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_EXPORT_WITH_DES40_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.585 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5 >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_EXPORT_WITH_RC4_40_MD5 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.586 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.589 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.590 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.591 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.591 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.593 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.593 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.594 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.595 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.597 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.598 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.599 CEST|SSLContextImpl.java:401|Ignore disabled cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.599 CEST|SSLContextImpl.java:410|Ignore unsupported cipher suite: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.642 CEST|SunX509KeyManagerImpl.java:164|found key for : 1 ( >>>>>> "certificate" : { >>>>>> "version" : "v3", >>>>>> "serial number" : "20 C3 8D C4 49 66 D0 02", >>>>>> "signature algorithm": "SHA256withRSA", >>>>>> "issuer" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>>>>> "not before" : "2013-08-02 09:51:36.000 CEST", >>>>>> "not after" : "10000-01-01 24:59:59.000 CET", >>>>>> "subject" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>>>>> "subject public key" : "RSA"} >>>>>> ) >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 CEST|SSLContextImpl.java:115|trigger seeding of SecureRandom >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.643 CEST|SSLContextImpl.java:119|done seeding of SecureRandom >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.665 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_128_GCM_SHA256 for TLS12 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.666 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_256_GCM_SHA384 for TLS12 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_128_GCM_SHA256 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_256_GCM_SHA384 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.671 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.672 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.673 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS11 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_128_GCM_SHA256 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.674 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_AES_256_GCM_SHA384 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.675 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.676 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLS10 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.677 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLS10 >>>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.690 CEST|ServerNameExtension.java:255|Unable to indicate server name >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.690 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: server_name >>>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.701 CEST|SignatureScheme.java:282|Signature algorithm, ed25519, is not supported by the underlying providers >>>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.702 CEST|SignatureScheme.java:282|Signature algorithm, ed448, is not supported by the underlying providers >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.706 CEST|SignatureScheme.java:358|Ignore disabled signature sheme: rsa_md5 >>>>>> javax.net.ssl|INFO|01|main|2018-09-17 11:51:54.706 CEST|AlpnExtension.java:161|No available application protocols >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.706 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: application_layer_protocol_negotiation >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.707 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: cookie >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: renegotiation_info >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 CEST|PreSharedKeyExtension.java:606|No session to resume. >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.711 CEST|SSLExtensions.java:235|Ignore, context unavailable extension: pre_shared_key >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 CEST|ClientHello.java:633|Produced ClientHello handshake message ( >>>>>> "ClientHello": { >>>>>> "client version" : "TLSv1.2", >>>>>> "random" : "66 2E BE D3 8A 77 39 06 3B 5A 34 03 7D EE 74 BB 08 D2 19 FD 50 17 2D 84 29 AA FB E0 EE ED 50 69", >>>>>> "session id" : "0B 03 C8 E2 D2 A5 CD 3A 22 C5 85 17 06 64 A9 30 14 62 C0 AF AB 67 CE 63 50 41 50 7F 6B FD 4C 9F", >>>>>> "cipher suites" : "[TLS_AES_128_GCM_SHA256(0x1301), TLS_AES_256_GCM_SHA384(0x1302), TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]", >>>>>> "compression methods" : "00", >>>>>> "extensions" : [ >>>>>> "status_request (5)": { >>>>>> "certificate status type": ocsp >>>>>> "OCSP status request": { >>>>>> "responder_id": >>>>>> "request extensions": { >>>>>> >>>>>> } >>>>>> } >>>>>> }, >>>>>> "supported_groups (10)": { >>>>>> "versions": [secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192] >>>>>> }, >>>>>> "ec_point_formats (11)": { >>>>>> "formats": [uncompressed] >>>>>> }, >>>>>> "signature_algorithms (13)": { >>>>>> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] >>>>>> }, >>>>>> "signature_algorithms_cert (50)": { >>>>>> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1] >>>>>> }, >>>>>> "status_request_v2 (17)": { >>>>>> "cert status request": { >>>>>> "certificate status type": ocsp_multi >>>>>> "OCSP status request": { >>>>>> "responder_id": >>>>>> "request extensions": { >>>>>> >>>>>> } >>>>>> } >>>>>> } >>>>>> }, >>>>>> "extended_master_secret (23)": { >>>>>> >>>>>> }, >>>>>> "supported_versions (43)": { >>>>>> "versions": [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1] >>>>>> }, >>>>>> "psk_key_exchange_modes (45)": { >>>>>> "ke_modes": [psk_dhe_ke] >>>>>> }, >>>>>> "key_share (51)": { >>>>>> "client_shares": [ >>>>>> { >>>>>> "named group": secp256r1 >>>>>> "key_exchange": { >>>>>> 0000: 04 A3 9F B9 05 27 00 38 C4 D7 61 6C 66 1F 4A 8D .....'.8..alf.J. >>>>>> 0010: B1 02 6F 0B F6 E1 BD 50 93 52 86 2C D2 3C 8D 1A ..o....P.R.,.<.. >>>>>> 0020: 10 A9 CD F0 40 F4 CD 04 25 A1 11 E2 58 23 A3 24 .... at ...%...X#.$ >>>>>> 0030: CA E8 8F 28 F7 2B 65 96 B2 E3 A1 AE 99 24 94 28 ...(.+e......$.( >>>>>> 0040: 83 >>>>>> } >>>>>> }, >>>>>> ] >>>>>> } >>>>>> ] >>>>>> } >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.714 CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 417 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.719 CEST|SSLSocketOutputRecord.java:255|Raw write ( >>>>>> 0000: 16 03 03 01 A1 01 00 01 9D 03 03 66 2E BE D3 8A ...........f.... >>>>>> 0010: 77 39 06 3B 5A 34 03 7D EE 74 BB 08 D2 19 FD 50 w9.;Z4...t.....P >>>>>> 0020: 17 2D 84 29 AA FB E0 EE ED 50 69 20 0B 03 C8 E2 .-.).....Pi .... >>>>>> 0030: D2 A5 CD 3A 22 C5 85 17 06 64 A9 30 14 62 C0 AF ...:"....d.0.b.. >>>>>> 0040: AB 67 CE 63 50 41 50 7F 6B FD 4C 9F 00 5A 13 01 .g.cPAP.k.L..Z.. >>>>>> 0050: 13 02 C0 2C C0 2B C0 30 00 9D C0 2E C0 32 00 9F ...,.+.0.....2.. >>>>>> 0060: 00 A3 C0 2F 00 9C C0 2D C0 31 00 9E 00 A2 C0 24 .../...-.1.....$ >>>>>> 0070: C0 28 00 3D C0 26 C0 2A 00 6B 00 6A C0 0A C0 14 .(.=.&.*.k.j.... >>>>>> 0080: 00 35 C0 05 C0 0F 00 39 00 38 C0 23 C0 27 00 3C .5.....9.8.#.'.< >>>>>> 0090: C0 25 C0 29 00 67 00 40 C0 09 C0 13 00 2F C0 04 .%.).g. at ...../.. >>>>>> 00A0: C0 0E 00 33 00 32 00 FF 01 00 00 FA 00 05 00 05 ...3.2.......... >>>>>> 00B0: 01 00 00 00 00 00 0A 00 20 00 1E 00 17 00 18 00 ........ ....... >>>>>> 00C0: 19 00 09 00 0A 00 0B 00 0C 00 0D 00 0E 00 16 01 ................ >>>>>> 00D0: 00 01 01 01 02 01 03 01 04 00 0B 00 02 01 00 00 ................ >>>>>> 00E0: 0D 00 28 00 26 04 03 05 03 06 03 08 04 08 05 08 ..(.&........... >>>>>> 00F0: 06 08 09 08 0A 08 0B 04 01 05 01 06 01 04 02 03 ................ >>>>>> 0100: 03 03 01 03 02 02 03 02 01 02 02 00 32 00 28 00 ............2.(. >>>>>> 0110: 26 04 03 05 03 06 03 08 04 08 05 08 06 08 09 08 &............... >>>>>> 0120: 0A 08 0B 04 01 05 01 06 01 04 02 03 03 03 01 03 ................ >>>>>> 0130: 02 02 03 02 01 02 02 00 11 00 09 00 07 02 00 04 ................ >>>>>> 0140: 00 00 00 00 00 17 00 00 00 2B 00 09 08 03 04 03 .........+...... >>>>>> 0150: 03 03 02 03 01 00 2D 00 02 01 01 00 33 00 47 00 ......-.....3.G. >>>>>> 0160: 45 00 17 00 41 04 A3 9F B9 05 27 00 38 C4 D7 61 E...A.....'.8..a >>>>>> 0170: 6C 66 1F 4A 8D B1 02 6F 0B F6 E1 BD 50 93 52 86 lf.J...o....P.R. >>>>>> 0180: 2C D2 3C 8D 1A 10 A9 CD F0 40 F4 CD 04 25 A1 11 ,.<...... at ...%.. >>>>>> 0190: E2 58 23 A3 24 CA E8 8F 28 F7 2B 65 96 B2 E3 A1 .X#.$...(.+e.... >>>>>> 01A0: AE 99 24 94 28 83 ..$.(. >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: 16 03 03 00 9B ..... >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.720 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 handshake, length = 155 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.721 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: 02 00 00 97 03 03 AB 76 F1 BA F3 B1 F0 DD 53 AC .......v......S. >>>>>> 0010: 5B 54 E9 E4 2E F8 44 D2 5E B2 59 85 0D 16 79 EE [T....D.^.Y...y. >>>>>> 0020: A7 66 8A 84 69 2A 20 0B 03 C8 E2 D2 A5 CD 3A 22 .f..i* .......:" >>>>>> 0030: C5 85 17 06 64 A9 30 14 62 C0 AF AB 67 CE 63 50 ....d.0.b...g.cP >>>>>> 0040: 41 50 7F 6B FD 4C 9F 13 01 00 00 4F 00 2B 00 02 AP.k.L.....O.+.. >>>>>> 0050: 03 04 00 33 00 45 00 17 00 41 04 18 4A 46 BB 73 ...3.E...A..JF.s >>>>>> 0060: F4 6F 5D F0 3C 98 AD 70 7E 13 D6 C0 E5 C0 28 5A .o].<..p......(Z >>>>>> 0070: D7 42 78 95 68 E0 85 B7 06 CD DB 3C 35 DA AF E8 .Bx.h......<5... >>>>>> 0080: 95 D6 A2 3C 77 CF 7E 8E C8 94 50 BA CD 18 3F DA ...>>>>> 0090: E3 A3 25 E9 F3 C9 A9 7F 4E B6 A9 ..%.....N.. >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.721 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 handshake, length = 155 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.722 CEST|ServerHello.java:866|Consuming ServerHello handshake message ( >>>>>> "ServerHello": { >>>>>> "server version" : "TLSv1.2", >>>>>> "random" : "AB 76 F1 BA F3 B1 F0 DD 53 AC 5B 54 E9 E4 2E F8 44 D2 5E B2 59 85 0D 16 79 EE A7 66 8A 84 69 2A", >>>>>> "session id" : "0B 03 C8 E2 D2 A5 CD 3A 22 C5 85 17 06 64 A9 30 14 62 C0 AF AB 67 CE 63 50 41 50 7F 6B FD 4C 9F", >>>>>> "cipher suite" : "TLS_AES_128_GCM_SHA256(0x1301)", >>>>>> "compression methods" : "00", >>>>>> "extensions" : [ >>>>>> "supported_versions (43)": { >>>>>> "selected version": [TLSv1.3] >>>>>> }, >>>>>> "key_share (51)": { >>>>>> "server_share": { >>>>>> "named group": secp256r1 >>>>>> "key_exchange": { >>>>>> 0000: 04 18 4A 46 BB 73 F4 6F 5D F0 3C 98 AD 70 7E 13 ..JF.s.o].<..p.. >>>>>> 0010: D6 C0 E5 C0 28 5A D7 42 78 95 68 E0 85 B7 06 CD ....(Z.Bx.h..... >>>>>> 0020: DB 3C 35 DA AF E8 95 D6 A2 3C 77 CF 7E 8E C8 94 .<5......>>>>> 0030: 50 BA CD 18 3F DA E3 A3 25 E9 F3 C9 A9 7F 4E B6 P...?...%.....N. >>>>>> 0040: A9 >>>>>> } >>>>>> }, >>>>>> } >>>>>> ] >>>>>> } >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|SSLExtensions.java:167|Consumed extension: supported_versions >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|ServerHello.java:962|Negotiated protocol version: TLSv1.3 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|SSLExtensions.java:138|Ignore unsupported extension: server_name >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|SSLExtensions.java:138|Ignore unsupported extension: max_fragment_length >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.723 CEST|SSLExtensions.java:138|Ignore unsupported extension: status_request >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:138|Ignore unsupported extension: ec_point_formats >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:138|Ignore unsupported extension: application_layer_protocol_negotiation >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:138|Ignore unsupported extension: status_request_v2 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:138|Ignore unsupported extension: extended_master_secret >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.724 CEST|SSLExtensions.java:167|Consumed extension: supported_versions >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 CEST|SSLExtensions.java:167|Consumed extension: key_share >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 CEST|SSLExtensions.java:138|Ignore unsupported extension: renegotiation_info >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 CEST|PreSharedKeyExtension.java:832|Handling pre_shared_key absence. >>>>>> javax.net.ssl|ALL|01|main|2018-09-17 11:51:54.725 CEST|SSLSessionImpl.java:203|Session initialized: Session(1537177914725|TLS_AES_128_GCM_SHA256) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.725 CEST|SSLExtensions.java:182|Ignore unavailable extension: server_name >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: max_fragment_length >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: status_request >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: ec_point_formats >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: application_layer_protocol_negotiation >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: status_request_v2 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: extended_master_secret >>>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: supported_versions >>>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: key_share >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: renegotiation_info >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.726 CEST|SSLExtensions.java:182|Ignore unavailable extension: pre_shared_key >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.732 CEST|SSLCipher.java:1824|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE >>>>>> countdown value = 137438953472 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.735 CEST|SSLCipher.java:1978|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE >>>>>> countdown value = 137438953472 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.736 CEST|SSLSocketOutputRecord.java:225|Raw write ( >>>>>> 0000: 14 03 03 00 01 01 ...... >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.736 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: 14 03 03 00 01 ..... >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 change_cipher_spec, length = 1 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: 01 . >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 change_cipher_spec, length = 1 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|ChangeCipherSpec.java:232|Consuming ChangeCipherSpec message >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.737 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: 17 03 03 00 27 ....' >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 39 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: D5 B7 25 6F AF E9 D6 6F 7C 61 98 90 3F FE BA 9A ..%o...o.a..?... >>>>>> 0010: A8 5B 94 5E 3A 47 38 62 36 90 9A 1D BE BF 87 18 .[.^:G8b6....... >>>>>> 0020: 56 8C E3 AA CE AD AA V...... >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.738 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 39 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.746 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>>>> 0000: 08 00 00 12 00 10 00 0A 00 0C 00 0A 00 1D 00 17 ................ >>>>>> 0010: 00 1E 00 19 00 18 ...... >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 CEST|EncryptedExtensions.java:171|Consuming EncryptedExtensions handshake message ( >>>>>> "EncryptedExtensions": [ >>>>>> "supported_groups (10)": { >>>>>> "versions": [x25519, secp256r1, x448, secp521r1, secp384r1] >>>>>> } >>>>>> ] >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 CEST|SSLExtensions.java:148|Ignore unavailable extension: server_name >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.747 CEST|SSLExtensions.java:148|Ignore unavailable extension: max_fragment_length >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:167|Consumed extension: supported_groups >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:182|Ignore unavailable extension: server_name >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:182|Ignore unavailable extension: max_fragment_length >>>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:190|Ignore impact of unsupported extension: supported_groups >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.748 CEST|SSLExtensions.java:182|Ignore unavailable extension: application_layer_protocol_negotiation >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: 17 03 03 00 42 ....B >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 66 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: 63 F7 54 24 11 6A 91 1F 1F C5 70 9A 26 AD CE 98 c.T$.j....p.&... >>>>>> 0010: D0 A9 7A 84 AF 39 7C A0 AD F6 6B B2 10 88 27 8B ..z..9....k...'. >>>>>> 0020: 79 E0 F4 5A 9F 68 AA F0 56 D3 45 72 7C 7F 22 03 y..Z.h..V.Er..". >>>>>> 0030: 0A 53 F6 24 68 CB 0B E1 3B DD D4 78 B5 AC 1E D7 .S.$h...;..x.... >>>>>> 0040: 03 FB .. >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.749 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 66 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>>>> 0000: 0D 00 00 2D 00 00 2A 00 0D 00 26 00 24 04 03 05 ...-..*...&.$... >>>>>> 0010: 03 06 03 08 07 08 08 08 09 08 0A 08 0B 08 04 08 ................ >>>>>> 0020: 05 08 06 04 01 05 01 06 01 03 03 02 03 03 01 02 ................ >>>>>> 0030: 01 . >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 CEST|CertificateRequest.java:864|Consuming CertificateRequest handshake message ( >>>>>> "CertificateRequest": { >>>>>> "certificate_request_context": "", >>>>>> "extensions": [ >>>>>> "signature_algorithms (13)": { >>>>>> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, ed25519, ed448, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha224, ecdsa_sha1, rsa_sha224, rsa_pkcs1_sha1] >>>>>> } >>>>>> ] >>>>>> } >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 CEST|SSLExtensions.java:167|Consumed extension: signature_algorithms >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.750 CEST|SSLExtensions.java:148|Ignore unavailable extension: signature_algorithms_cert >>>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 CEST|SignatureScheme.java:390|Unsupported signature scheme: ed25519 >>>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 CEST|SignatureScheme.java:390|Unsupported signature scheme: ed448 >>>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 CEST|SignatureScheme.java:390|Unsupported signature scheme: ecdsa_sha224 >>>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.751 CEST|SignatureScheme.java:390|Unsupported signature scheme: rsa_sha224 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 CEST|SSLExtensions.java:199|Populated with extension: signature_algorithms >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 CEST|SSLExtensions.java:182|Ignore unavailable extension: signature_algorithms_cert >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: 17 03 03 03 20 .... >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.752 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 800 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.753 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: FE BB B2 07 BA CE A6 32 AA 58 66 2F 6D 87 16 75 .......2.Xf/m..u >>>>>> 0010: CF 71 13 53 FB 45 AE DC 84 F4 AA 33 08 08 DF B5 .q.S.E.....3.... >>>>>> 0020: 97 C5 79 40 4A 28 F4 9D 0F 5A 86 4E C4 5F C7 2E ..y at J(...Z.N._.. >>>>>> 0030: AA AA 42 F7 8A FF 6B C1 28 75 9B A3 25 F0 23 81 ..B...k.(u..%.#. >>>>>> 0040: 74 BB 9A EA A8 8D 89 BE E9 80 AE 31 C3 3A FC 35 t..........1.:.5 >>>>>> 0050: E6 CA C5 77 BF C7 0E ED 64 26 DB 4E C3 3D F5 AD ...w....d&.N.=.. >>>>>> 0060: 5E EB A8 37 AA 81 EF 39 24 84 C9 C4 C7 A2 D7 DB ^..7...9$....... >>>>>> 0070: 7F 82 01 7A 02 E7 23 A3 6E C9 68 B8 E5 C3 9F 53 ...z..#.n.h....S >>>>>> 0080: 16 6E EF B0 54 D2 67 4C FF 22 E6 78 B1 A0 DB BE .n..T.gL.".x.... >>>>>> 0090: 97 23 FC C8 D8 92 86 3D C6 6B E4 C1 AC EF B8 46 .#.....=.k.....F >>>>>> 00A0: 75 3C 00 08 8B 34 5F 59 05 49 25 97 BE A8 61 8E u<...4_Y.I%...a. >>>>>> 00B0: B0 5F 25 91 7A FE 79 53 7A C1 A7 E7 70 7B A5 53 ._%.z.ySz...p..S >>>>>> 00C0: 5A 63 8B 8E B9 92 2D B3 80 DC AA 75 BE 0F 47 F3 Zc....-....u..G. >>>>>> 00D0: E8 D9 0D 7D D9 C3 B6 00 AD 2A 43 CC 66 87 88 AF .........*C.f... >>>>>> 00E0: 35 87 74 2F 87 2F 3C A6 FB 12 1A 9C 46 62 1C DC 5.t/./<.....Fb.. >>>>>> 00F0: 4E 4E DC 16 70 7E 08 74 FB F7 E6 5F 4D D9 20 F9 NN..p..t..._M. . >>>>>> 0100: CA F3 91 45 D6 1A B3 BA FA 4E BD A4 74 9E 4C 78 ...E.....N..t.Lx >>>>>> 0110: 03 18 2C 70 35 42 68 F3 9A 1D 24 3F A7 27 DF 29 ..,p5Bh...$?.'.) >>>>>> 0120: D5 58 7C CB 19 2F D1 DF 8A 6D B2 85 52 B5 78 19 .X.../...m..R.x. >>>>>> 0130: EA 5C E2 7A 23 42 9E D7 A3 DC D0 DE D8 33 47 2B .\.z#B.......3G+ >>>>>> 0140: 0C D8 6E 77 25 DB E6 12 B0 7A AD A5 C9 96 AC A9 ..nw%....z...... >>>>>> 0150: 1D CD 73 39 AC 6A 9F E2 0A F7 17 F1 F0 FF 75 9C ..s9.j........u. >>>>>> 0160: B2 05 9E 7A F4 18 4F FC 9D 42 69 4C E0 3E A1 21 ...z..O..BiL.>.! >>>>>> 0170: DA 1F 71 07 59 C6 A2 F9 0B 4F C0 CD A4 85 A8 DB ..q.Y....O...... >>>>>> 0180: 77 F6 87 5E 09 16 49 5C 2C B8 C0 7B 39 81 65 FD w..^..I\,...9.e. >>>>>> 0190: 29 52 E2 C7 F5 C7 AD BC F6 A9 F9 6D D2 E9 A4 14 )R.........m.... >>>>>> 01A0: C9 D3 79 2E D2 BA 10 4C BD 44 65 2B A8 7E F1 3A ..y....L.De+...: >>>>>> 01B0: F3 F6 11 53 38 17 10 12 B4 CD C5 AD 72 3B 84 A2 ...S8.......r;.. >>>>>> 01C0: 1B F9 D7 BF 34 00 5A FE F4 CE 09 0C EA F2 27 9A ....4.Z.......'. >>>>>> 01D0: BD DD 93 37 E2 DF 60 CC 8A F7 C6 4B 08 30 0D 78 ...7..`....K.0.x >>>>>> 01E0: 5C EB 49 34 DB 8B EB 55 33 0C 82 03 07 FD 3D FC \.I4...U3.....=. >>>>>> 01F0: 49 11 88 1C F6 67 7F 0B 48 AA EC 1B AF 04 46 CF I....g..H.....F. >>>>>> 0200: 09 C5 8E B3 F8 92 C4 56 3D 8F 0E 1D 9F D3 0C FE .......V=....... >>>>>> 0210: 94 23 15 53 8E 1F 5E C4 FA 44 03 3B 1B B0 0A 2D .#.S..^..D.;...- >>>>>> 0220: 71 D4 B5 AC 1F 52 D7 25 9F A0 C8 4B 9B 32 B8 22 q....R.%...K.2." >>>>>> 0230: 3F AF B3 19 16 8C 2A 5C B4 89 BF 82 DC 4D AF 22 ?.....*\.....M." >>>>>> 0240: 2A 33 73 90 F3 C8 FF 2E C1 B3 83 D2 7A 29 4E 15 *3s.........z)N. >>>>>> 0250: 5D 87 86 F6 94 EA B0 B4 A4 41 B9 C5 BA 89 B8 E9 ]........A...... >>>>>> 0260: 26 E7 96 BC 4D 8A FD 86 C7 C9 2A 96 75 C3 07 EF &...M.....*.u... >>>>>> 0270: 5C 5A 4E 91 71 7D 1B A2 12 88 C5 D0 D2 5E 79 E1 \ZN.q........^y. >>>>>> 0280: 6C 65 35 5E 6C CC 56 47 FD F3 96 78 7A A0 08 7E le5^l.VG...xz... >>>>>> 0290: DB 3C CC 10 76 15 37 46 48 6B 2D 23 7B A3 44 5A .<..v.7FHk-#..DZ >>>>>> 02A0: A4 46 B3 CE E2 15 BA 4C D2 93 16 57 1F BA 75 72 .F.....L...W..ur >>>>>> 02B0: BF 8C 66 50 F2 A4 F6 05 84 E5 47 12 30 BE 34 70 ..fP......G.0.4p >>>>>> 02C0: 4D 0F BD FE 54 E8 B1 CE B5 7F 6E 97 38 09 29 1F M...T.....n.8.). >>>>>> 02D0: 41 2D 2E 9E 75 D8 77 0C 08 DB 5C B4 EE 3F FE E2 A-..u.w...\..?.. >>>>>> 02E0: DC CF D0 ED C8 02 50 C4 EE B3 1D 8A 9E 9B EE 5E ......P........^ >>>>>> 02F0: 14 BA C2 5A B0 83 8E 5C E5 7B 69 2B 69 8C F1 AA ...Z...\..i+i... >>>>>> 0300: 2D D5 D1 3D 9D 42 1B B2 50 5D BE 7E E4 11 D2 90 -..=.B..P]...... >>>>>> 0310: 0B 54 71 7F D6 13 88 E2 FE 37 9F 70 B5 0B 57 79 .Tq......7.p..Wy >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.753 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 800 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.755 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>>>> 0000: 0B 00 03 0B 00 00 03 07 00 03 02 30 82 02 FE 30 ...........0...0 >>>>>> 0010: 82 01 E6 A0 03 02 01 02 02 08 20 C3 8D C4 49 66 .......... ...If >>>>>> 0020: D0 02 30 0D 06 09 2A 86 48 86 F7 0D 01 01 0B 05 ..0...*.H....... >>>>>> 0030: 00 30 3E 31 3C 30 3A 06 03 55 04 03 0C 33 65 38 .0>1<0:..U...3e8 >>>>>> 0040: 61 63 30 32 66 61 30 64 36 35 61 38 34 32 31 39 ac02fa0d65a84219 >>>>>> 0050: 30 31 36 30 34 35 64 62 38 62 30 35 63 34 38 35 016045db8b05c485 >>>>>> 0060: 62 34 65 63 64 66 2E 6E 65 74 74 79 2E 74 65 73 b4ecdf.netty.tes >>>>>> 0070: 74 30 20 17 0D 31 33 30 38 30 32 30 37 35 31 33 t0 ..13080207513 >>>>>> 0080: 36 5A 18 0F 39 39 39 39 31 32 33 31 32 33 35 39 6Z..999912312359 >>>>>> 0090: 35 39 5A 30 3E 31 3C 30 3A 06 03 55 04 03 0C 33 59Z0>1<0:..U...3 >>>>>> 00A0: 65 38 61 63 30 32 66 61 30 64 36 35 61 38 34 32 e8ac02fa0d65a842 >>>>>> 00B0: 31 39 30 31 36 30 34 35 64 62 38 62 30 35 63 34 19016045db8b05c4 >>>>>> 00C0: 38 35 62 34 65 63 64 66 2E 6E 65 74 74 79 2E 74 85b4ecdf.netty.t >>>>>> 00D0: 65 73 74 30 82 01 22 30 0D 06 09 2A 86 48 86 F7 est0.."0...*.H.. >>>>>> 00E0: 0D 01 01 01 05 00 03 82 01 0F 00 30 82 01 0A 02 ...........0.... >>>>>> 00F0: 82 01 01 00 DB F8 70 4E DC 2D 14 44 12 AF 0D 48 ......pN.-.D...H >>>>>> 0100: 09 1D B8 48 94 1C 9E F1 7F DC 6C D1 F7 94 3A B7 ...H......l...:. >>>>>> 0110: 5C E3 85 07 3E CB E1 76 4A 2C 32 17 4B E1 5E 42 \...>..vJ,2.K.^B >>>>>> 0120: A4 80 50 CA 36 A2 D9 94 F9 59 23 D0 AA 2B B2 13 ..P.6....Y#..+.. >>>>>> 0130: 23 6D 45 DF 13 52 A4 4E 28 D3 30 99 5A 81 AD 8C #mE..R.N(.0.Z... >>>>>> 0140: DB 15 55 B7 6D 5F 44 89 09 35 66 C8 2F 47 56 14 ..U.m_D..5f./GV. >>>>>> 0150: B5 B2 46 AE CE 5D DC A0 C8 59 08 89 6F 5B DB F2 ..F..]...Y..o[.. >>>>>> 0160: D8 69 E3 C1 80 44 F6 DA 46 ED 1D 20 80 12 3F 81 .i...D..F.. ..?. >>>>>> 0170: 95 27 F6 EB 9F B5 AC DC 72 01 70 46 18 67 1C 08 .'......r.pF.g.. >>>>>> 0180: AC C4 6D CA 80 48 12 87 3A 05 69 EA 92 EA 95 00 ..m..H..:.i..... >>>>>> 0190: 1F B9 2C BA 83 F3 B3 1B 37 1E B3 7C D7 46 B1 AE ..,.....7....F.. >>>>>> 01A0: D4 DD E9 04 8C C0 23 00 96 E3 6F 67 E7 66 65 61 ......#...og.fea >>>>>> 01B0: F6 11 D2 7A FE 44 42 83 9D 1A CF 20 80 EC 58 04 ...z.DB.... ..X. >>>>>> 01C0: A6 10 78 41 7B 34 C3 FA FD 2A 08 94 72 2F 3D AE ..xA.4...*..r/=. >>>>>> 01D0: B0 58 16 63 EE DA 81 42 44 DB 21 C7 23 69 93 BB .X.c...BD.!.#i.. >>>>>> 01E0: 64 40 16 78 01 8A 52 57 94 C0 AD 57 04 F4 C4 6B d at .x..RW...W...k >>>>>> 01F0: 90 C6 46 C7 02 03 01 00 01 30 0D 06 09 2A 86 48 ..F......0...*.H >>>>>> 0200: 86 F7 0D 01 01 0B 05 00 03 82 01 01 00 4B FC 37 .............K.7 >>>>>> 0210: B5 E6 F2 A6 98 D8 58 2B 39 CE 8F 6B 51 93 80 0F ......X+9..kQ... >>>>>> 0220: 80 39 BD DA 53 7D D3 1B 00 11 F3 A7 FE 9C B7 FA .9..S........... >>>>>> 0230: 05 23 DA A2 17 10 7C E7 89 89 DE C5 90 5B 98 22 .#...........[." >>>>>> 0240: 7B 97 97 EA 2A B3 E4 6A 33 F8 FC 47 41 39 06 E1 ....*..j3..GA9.. >>>>>> 0250: 98 63 6C 0E 2A 92 FF 3D B1 62 D7 27 FF 2B 2B DF .cl.*..=.b.'.++. >>>>>> 0260: B7 B2 95 87 C7 B5 21 45 1E 73 F8 B5 0D D6 13 0C ......!E.s...... >>>>>> 0270: 1D 25 35 6B D7 5F 18 DF 30 A1 8B 72 DD C6 31 B1 .%5k._..0..r..1. >>>>>> 0280: 07 2A F2 DF 1F 1E 36 23 0C FF F9 FB DA E8 B5 2B .*....6#.......+ >>>>>> 0290: 3B 8B B6 4C 37 EF D3 27 07 B9 1E D4 64 4B 82 D4 ;..L7..'....dK.. >>>>>> 02A0: 32 78 C6 D1 61 6E 9A BF 41 10 23 0B 27 CD C7 77 2x..an..A.#.'..w >>>>>> 02B0: 03 73 B2 F6 12 D2 56 9C 29 A2 BD 31 40 F6 5F 0C .s....V.)..1 at ._. >>>>>> 02C0: 17 56 4F 30 34 95 77 87 9C 43 B0 74 C5 92 05 43 .VO04.w..C.t...C >>>>>> 02D0: 97 12 48 5B 7B 58 66 89 0A C1 8C CD 89 14 E0 5A ..H[.Xf........Z >>>>>> 02E0: 78 23 29 10 71 6C 5D 94 D5 FB C0 96 51 C1 0D 93 x#).ql].....Q... >>>>>> 02F0: 64 91 45 82 5A 53 88 56 5D 7A AE 88 E8 07 7D 02 d.E.ZS.V]z...... >>>>>> 0300: 7D 44 9D CA 73 E5 6F 14 27 8B 6F 86 6C 00 00 .D..s.o.'.o.l.. >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 CEST|CertificateMessage.java:1148|Consuming server Certificate handshake message ( >>>>>> "Certificate": { >>>>>> "certificate_request_context": "", >>>>>> "certificate_list": [ >>>>>> { >>>>>> "certificate" : { >>>>>> "version" : "v3", >>>>>> "serial number" : "20 C3 8D C4 49 66 D0 02", >>>>>> "signature algorithm": "SHA256withRSA", >>>>>> "issuer" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>>>>> "not before" : "2013-08-02 09:51:36.000 CEST", >>>>>> "not after" : "10000-01-01 24:59:59.000 CET", >>>>>> "subject" : "CN=e8ac02fa0d65a84219016045db8b05c485b4ecdf.netty.test", >>>>>> "subject public key" : "RSA"} >>>>>> "extensions": { >>>>>> >>>>>> } >>>>>> }, >>>>>> ] >>>>>> } >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.756 CEST|SSLExtensions.java:148|Ignore unavailable extension: status_request >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: 17 03 03 01 19 ..... >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 281 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.757 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: DE 53 C0 74 78 C3 82 0D E8 46 C0 0A F4 56 6E 6B .S.tx....F...Vnk >>>>>> 0010: B5 39 77 41 20 21 BA 07 99 2B BF 8D 0A 41 C9 B8 .9wA !...+...A.. >>>>>> 0020: BC 0F C1 8E C5 76 36 F0 7A B6 9A F8 38 4D 4D 4D .....v6.z...8MMM >>>>>> 0030: 70 33 BE 8F 8C ED BE BC 60 49 B8 41 65 E9 04 D9 p3......`I.Ae... >>>>>> 0040: 45 43 AA 41 6D F7 67 7B 03 6D FF E0 4D 76 53 CE EC.Am.g..m..MvS. >>>>>> 0050: C1 73 3E 1C CD 87 40 B7 25 56 54 0C 3E CA D7 1D .s>... at .%VT.>... >>>>>> 0060: 45 80 41 E8 36 B7 FC 57 38 BB 21 EB E7 EA 19 A1 E.A.6..W8.!..... >>>>>> 0070: 39 25 B0 44 8B FD 30 87 86 7A 47 03 C1 02 AC FD 9%.D..0..zG..... >>>>>> 0080: 67 89 4B 27 34 04 20 AE 91 65 7C 8C 4A 58 C5 77 g.K'4. ..e..JX.w >>>>>> 0090: 46 2E DD A8 23 CA 5C 28 49 25 23 3D 8A 93 B9 10 F...#.\(I%#=.... >>>>>> 00A0: 24 0D DE DC 98 AC AA B0 CB 51 80 D7 F8 E7 20 23 $........Q.... # >>>>>> 00B0: 41 64 A6 44 93 A7 E1 A7 91 62 4F 3A 73 F6 24 04 Ad.D.....bO:s.$. >>>>>> 00C0: C3 E8 25 65 37 D9 1B 7A 65 AE DE C6 29 67 2E C1 ..%e7..ze...)g.. >>>>>> 00D0: F7 4C 5C 18 D7 14 98 90 ED 9D AD F5 98 A7 FD 93 .L\............. >>>>>> 00E0: 53 F4 B5 90 C9 CB FD 54 8E 5F 53 23 E3 73 94 BD S......T._S#.s.. >>>>>> 00F0: A4 07 B7 E3 C7 83 7B 17 CF 51 4A 9E 9C 05 3C 51 .........QJ...>>>>> 0100: 4D C7 A1 7A D6 4D A6 58 E5 3A D4 12 B9 B9 46 9C M..z.M.X.:....F. >>>>>> 0110: AB 1D C5 6B F9 6A 85 CB E2 ...k.j... >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.758 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 281 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.758 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>>>> 0000: 0F 00 01 04 08 04 01 00 30 11 28 CE 64 4E 08 BA ........0.(.dN.. >>>>>> 0010: A1 BE 46 D9 3D 14 29 1A EB 5A B0 1A 09 B7 11 A5 ..F.=.)..Z...... >>>>>> 0020: 9A F4 22 17 87 5F 87 D5 63 04 8E 27 EC 3A F8 52 ..".._..c..'.:.R >>>>>> 0030: 36 F4 2F CF 47 D2 5C CE 0A F0 29 EF 63 03 B1 64 6./.G.\...).c..d >>>>>> 0040: B8 45 6E 39 71 E3 BD 25 95 31 25 85 4C FB C6 AD .En9q..%.1%.L... >>>>>> 0050: C8 43 96 4E FA AD B9 98 17 43 61 FB 9B 87 CE 94 .C.N.....Ca..... >>>>>> 0060: CF 74 6F 3B AA 6A C8 80 8F C7 C8 05 E4 EF 42 6C .to;.j........Bl >>>>>> 0070: D4 01 9E 25 5E 34 E8 2D 93 BD BB 05 49 2F 9D B6 ...%^4.-....I/.. >>>>>> 0080: F6 91 2F D1 E5 CB 1B 9E F6 DB 18 32 1D F5 66 A0 ../........2..f. >>>>>> 0090: 63 5D 25 01 B6 F6 1B 41 07 3E 90 61 37 49 38 17 c]%....A.>.a7I8. >>>>>> 00A0: B0 15 C9 AD 0C 7A 05 8D B4 48 BB 03 2D DE 5E 49 .....z...H..-.^I >>>>>> 00B0: 99 8B 74 53 5F 73 9B 18 FD 95 2A C3 F9 A3 8B 59 ..tS_s....*....Y >>>>>> 00C0: 1A ED 2C 55 C2 22 10 1E 7A FC 38 0A 99 FC 30 89 ..,U."..z.8...0. >>>>>> 00D0: 03 89 1C CD A7 DE E5 35 FD E9 E0 05 96 09 AF DD .......5........ >>>>>> 00E0: 51 A3 7F C7 16 C5 96 8D CA CC 53 50 DC C5 C6 BA Q.........SP.... >>>>>> 00F0: D6 05 28 18 BA 99 F8 0F 7F 24 9F D5 6B 93 DE BC ..(......$..k... >>>>>> 0100: EB 23 85 D9 D3 41 56 44 .#...AVD >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 CEST|CertificateVerify.java:1128|Consuming CertificateVerify handshake message ( >>>>>> "CertificateVerify": { >>>>>> "signature algorithm": rsa_pss_rsae_sha256 >>>>>> "signature": { >>>>>> 0000: 30 11 28 CE 64 4E 08 BA A1 BE 46 D9 3D 14 29 1A 0.(.dN....F.=.). >>>>>> 0010: EB 5A B0 1A 09 B7 11 A5 9A F4 22 17 87 5F 87 D5 .Z........".._.. >>>>>> 0020: 63 04 8E 27 EC 3A F8 52 36 F4 2F CF 47 D2 5C CE c..'.:.R6./.G.\. >>>>>> 0030: 0A F0 29 EF 63 03 B1 64 B8 45 6E 39 71 E3 BD 25 ..).c..d.En9q..% >>>>>> 0040: 95 31 25 85 4C FB C6 AD C8 43 96 4E FA AD B9 98 .1%.L....C.N.... >>>>>> 0050: 17 43 61 FB 9B 87 CE 94 CF 74 6F 3B AA 6A C8 80 .Ca......to;.j.. >>>>>> 0060: 8F C7 C8 05 E4 EF 42 6C D4 01 9E 25 5E 34 E8 2D ......Bl...%^4.- >>>>>> 0070: 93 BD BB 05 49 2F 9D B6 F6 91 2F D1 E5 CB 1B 9E ....I/..../..... >>>>>> 0080: F6 DB 18 32 1D F5 66 A0 63 5D 25 01 B6 F6 1B 41 ...2..f.c]%....A >>>>>> 0090: 07 3E 90 61 37 49 38 17 B0 15 C9 AD 0C 7A 05 8D .>.a7I8......z.. >>>>>> 00A0: B4 48 BB 03 2D DE 5E 49 99 8B 74 53 5F 73 9B 18 .H..-.^I..tS_s.. >>>>>> 00B0: FD 95 2A C3 F9 A3 8B 59 1A ED 2C 55 C2 22 10 1E ..*....Y..,U.".. >>>>>> 00C0: 7A FC 38 0A 99 FC 30 89 03 89 1C CD A7 DE E5 35 z.8...0........5 >>>>>> 00D0: FD E9 E0 05 96 09 AF DD 51 A3 7F C7 16 C5 96 8D ........Q....... >>>>>> 00E0: CA CC 53 50 DC C5 C6 BA D6 05 28 18 BA 99 F8 0F ..SP......(..... >>>>>> 00F0: 7F 24 9F D5 6B 93 DE BC EB 23 85 D9 D3 41 56 44 .$..k....#...AVD >>>>>> } >>>>>> } >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: 17 03 03 00 35 ....5 >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.762 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 53 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: F6 A7 CD EA 89 34 B2 DB C4 28 91 18 C9 03 98 B6 .....4...(...... >>>>>> 0010: DF 49 4E F5 2E 23 32 90 F8 13 C7 AE 18 E3 E5 64 .IN..#2........d >>>>>> 0020: D9 E4 A5 B0 5C F0 4A 3E AF EC 28 8D 09 78 AB EE ....\.J>..(..x.. >>>>>> 0030: 38 1B 9E 45 04 8..E. >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 53 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.763 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>>>> 0000: 14 00 00 20 F2 93 6B 71 2B FA F3 1B BF 68 98 D1 ... ..kq+....h.. >>>>>> 0010: AA 5E B0 AF 5D 3B A6 B5 8F 79 BA 64 E8 A1 34 5F .^..];...y.d..4_ >>>>>> 0020: D4 2B ED 8C .+.. >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.764 CEST|Finished.java:860|Consuming server Finished handshake message ( >>>>>> "Finished": { >>>>>> "verify data": { >>>>>> 0000: F2 93 6B 71 2B FA F3 1B BF 68 98 D1 AA 5E B0 AF ..kq+....h...^.. >>>>>> 0010: 5D 3B A6 B5 8F 79 BA 64 E8 A1 34 5F D4 2B ED 8C ];...y.d..4_.+.. >>>>>> }'} >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.765 CEST|SSLCipher.java:1824|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE >>>>>> countdown value = 137438953472 >>>>>> javax.net.ssl|WARNING|01|main|2018-09-17 11:51:54.765 CEST|CertificateMessage.java:1015|No signature_algorithms(_cert) in ClientHello >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|CertificateMessage.java:1081|No available client authentication scheme >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|CertificateMessage.java:1116|Produced client Certificate message ( >>>>>> "Certificate": { >>>>>> "certificate_request_context": "", >>>>>> "certificate_list": [ >>>>>> ] >>>>>> } >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 8 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.766 CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( >>>>>> 0000: 0B 00 00 04 00 00 00 00 16 00 00 00 00 00 00 00 ................ >>>>>> 0010: 00 00 00 00 00 00 00 00 00 ......... >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 CEST|SSLSocketOutputRecord.java:255|Raw write ( >>>>>> 0000: 17 03 03 00 29 E5 32 E4 5B 13 E7 D4 A1 78 FE 38 ....).2.[....x.8 >>>>>> 0010: 26 22 CB C1 04 88 3A 3A 2D D4 A1 31 5A 78 65 50 &"....::-..1ZxeP >>>>>> 0020: 51 45 67 FA 9F 55 35 E1 49 C5 3B 3B 91 B1 QEg..U5.I.;;.. >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.767 CEST|CertificateVerify.java:1059|No X.509 credentials negotiated for CertificateVerify >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 CEST|Finished.java:658|Produced client Finished handshake message ( >>>>>> "Finished": { >>>>>> "verify data": { >>>>>> 0000: D8 47 0B A0 DF BB BF 49 E4 55 B9 D3 FB 3D B0 DD .G.....I.U...=.. >>>>>> 0010: 57 1E 08 28 20 7E E1 0B E3 EB 12 10 09 76 D1 8F W..( ........v.. >>>>>> }'} >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.768 CEST|SSLSocketOutputRecord.java:241|WRITE: TLS13 handshake, length = 36 >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 CEST|SSLCipher.java:2020|Plaintext before ENCRYPTION ( >>>>>> 0000: 14 00 00 20 D8 47 0B A0 DF BB BF 49 E4 55 B9 D3 ... .G.....I.U.. >>>>>> 0010: FB 3D B0 DD 57 1E 08 28 20 7E E1 0B E3 EB 12 10 .=..W..( ....... >>>>>> 0020: 09 76 D1 8F 16 00 00 00 00 00 00 00 00 00 00 00 .v.............. >>>>>> 0030: 00 00 00 00 00 ..... >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.769 CEST|SSLSocketOutputRecord.java:255|Raw write ( >>>>>> 0000: 17 03 03 00 45 0F 4D 84 52 28 59 96 92 52 D1 AB ....E.M.R(Y..R.. >>>>>> 0010: DB 86 64 25 31 FF 9D 8E D7 84 63 B5 03 E2 9E 06 ..d%1.....c..... >>>>>> 0020: 3C 8C C2 22 F3 7A EE 55 AD 8C F5 5C F6 04 9A E2 <..".z.U...\.... >>>>>> 0030: 6D BA E4 C4 9F 97 C3 DA BC D3 CB 8C 2C 9E BF FD m...........,... >>>>>> 0040: A3 9F C1 A2 79 51 75 B7 AE B6 ....yQu... >>>>>> ) >>>>>> javax.net.ssl|DEBUG|01|main|2018-09-17 11:51:54.770 CEST|SSLCipher.java:1978|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE >>>>>> countdown value = 137438953472 >>>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: 17 03 03 00 13 ..... >>>>>> ) >>>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:213|READ: TLSv1.2 application_data, length = 19 >>>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:458|Raw read ( >>>>>> 0000: 4F 0D C7 65 8B 24 B4 92 A2 26 31 8C 81 AF 8F F7 O..e.$...&1..... >>>>>> 0010: AC C3 B3 ... >>>>>> ) >>>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.772 CEST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 19 >>>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.773 CEST|SSLCipher.java:1915|Plaintext after DECRYPTION ( >>>>>> 0000: 02 74 .t >>>>>> ) >>>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.774 CEST|Alert.java:232|Received alert message ( >>>>>> "Alert": { >>>>>> "level" : "fatal", >>>>>> "description": "certificate_required" >>>>>> } >>>>>> ) >>>>>> javax.net.ssl|ERROR|0C|Thread-0|2018-09-17 11:51:54.774 CEST|TransportContext.java:313|Fatal (CERTIFICATE_REQUIRED): Received fatal alert: certificate_required ( >>>>>> "throwable" : { >>>>>> javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_required >>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>>>>> at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >>>>>> at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >>>>>> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>>>>> at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) >>>>>> at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) >>>>>> at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) >>>>>> at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) >>>>>> at ReproducerClient$1.run(ReproducerClient.java:33) >>>>>> at java.base/java.lang.Thread.run(Thread.java:834)} >>>>>> ) >>>>>> javax.net.ssl|ALL|0C|Thread-0|2018-09-17 11:51:54.775 CEST|SSLSessionImpl.java:753|Invalidated session: Session(1537177914725|TLS_AES_128_GCM_SHA256) >>>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 CEST|SSLSocketImpl.java:1361|close the underlying socket >>>>>> javax.net.ssl|DEBUG|0C|Thread-0|2018-09-17 11:51:54.776 CEST|SSLSocketImpl.java:1380|close the SSL connection (initiative) >>>>>> javax.net.ssl|WARNING|0C|Thread-0|2018-09-17 11:51:54.777 CEST|SSLSocketImpl.java:1289|handling exception ( >>>>>> "throwable" : { >>>>>> javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_required >>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) >>>>>> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >>>>>> at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >>>>>> at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) >>>>>> at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) >>>>>> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) >>>>>> at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) >>>>>> at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) >>>>>> at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) >>>>>> at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) >>>>>> at ReproducerClient$1.run(ReproducerClient.java:33) >>>>>> at java.base/java.lang.Thread.run(Thread.java:834)} >>>>>> ) >>>>>> Bye >>>>>> Norman >>>>>>> On 16. Sep 2018, at 15:54, Norman Maurer > wrote: >>>>>>> >>>>>>> Will do, but not before tomorrow (I will also share the client side code). That said there is nothing special about the keymanager. >>>>>>> Like I said before it sends the cert when using ?want client with?, it just seems it may be too late. >>>>>>> >>>>>>> >>>>>>> Bye >>>>>>> Norman >>>>>>> >>>>>>>> Am 15.09.2018 um 08:26 schrieb Bradford Wetmore >: >>>>>>>> >>>>>>>> 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)) >>>>>>>>>>>> 0000 - 16 03 03 01 60 ....` >>>>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (352 bytes => 352 (0x160)) >>>>>>>>>>>> 0000 - 01 00 01 5c 03 03 22 da-02 d7 86 40 6e 7d c5 a7 ...\..".... at 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..o....K...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)) >>>>>>>>>>>> 0000 - 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|J....n....] >>>>>>>>>>>> 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..o....K.. >>>>>>>>>>>> 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 MT....B5S[...... >>>>>>>>>>>> 00e0 - 00 28 05 6d a8 c9 bb 38-e2 77 72 73 25 26 e3 65 .(.m...8.wrs%&.e >>>>>>>>>>>> 00f0 - 58 d8 fd 15 8a ce ea 97-8a 50 1e e3 f9 c5 dc 96 X........P...... >>>>>>>>>>>> 0100 - f0 3b 3c 0a 12 41 58 9d-ab f8 3a 28 0a 1f 61 e9 .;<..AX...:(..a. >>>>>>>>>>>> 0110 - df 68 a9 1f 84 66 f7 5b-d7 17 03 03 03 20 8f b5 .h...f.[..... .. >>>>>>>>>>>> 0120 - b4 52 44 80 d0 b9 63 3d-80 9c 8b 02 fc f3 d5 bb .RD...c=........ >>>>>>>>>>>> 0130 - a9 2a 4f 5b 4a cc 77 78-96 75 95 20 b8 12 c4 a6 .*O[J.wx.u. .... >>>>>>>>>>>> 0140 - e6 82 ea 56 56 e2 5f 97-65 99 7e 6e 3d b1 66 ee ...VV._.e.~n=.f. >>>>>>>>>>>> 0150 - 10 4c f7 6d 9b 73 86 14-7a 81 f8 b1 27 af 08 ee .L.m.s..z...'... >>>>>>>>>>>> 0160 - ce 26 90 34 73 3d b7 45-8d 85 29 a8 65 19 e7 02 .&.4s=.E..).e... >>>>>>>>>>>> 0170 - e5 55 4a 27 f1 b1 6a a4-11 cc 6c af 78 6d 22 5c .UJ'..j...l.xm"\ >>>>>>>>>>>> 0180 - 33 73 e3 ad 7f 8d 1b d3-75 95 66 64 2d 0e f1 3e 3s......u.fd-..> >>>>>>>>>>>> 0190 - c2 30 df a1 7e ce a3 50-c3 4e 68 f6 36 b3 4e 45 .0..~..P.Nh.6.NE >>>>>>>>>>>> 01a0 - 9c ac e9 f2 0d 7c e3 73-6a 40 ab 6e 6e f9 d8 20 .....|.sj at .nn.. >>>>>>>>>>>> 01b0 - 9c f3 04 32 cd 1d df 18-e5 4d e3 e8 b1 38 59 f8 ...2.....M...8Y. >>>>>>>>>>>> 01c0 - 28 67 2e ca af a2 8b 88-ce ca 48 a6 07 2b a6 9a (g........H..+.. >>>>>>>>>>>> 01d0 - 0e 88 5b d7 0b d9 31 77-97 8d 6c 2b f5 60 24 61 ..[...1w..l+.`$a >>>>>>>>>>>> 01e0 - a8 5c 47 5d 7c 66 f0 9b-1f e4 76 93 38 f6 78 3e .\G]|f....v.8.x> >>>>>>>>>>>> 01f0 - 69 29 72 f9 d9 4b cb 05-03 e4 f2 d6 24 e1 91 ee i)r..K......$... >>>>>>>>>>>> 0200 - 85 37 d7 7b c3 5c 35 90-08 cd b1 cc 76 11 fc 00 .7.{.\5.....v... >>>>>>>>>>>> 0210 - 12 7e 89 7b 70 e6 ca fe-0b 26 b6 bb ac fe 4b 9f .~.{p....&....K. >>>>>>>>>>>> 0220 - ec cf 41 69 42 3a 3e 41-f9 b0 c0 93 5b 70 1f c7 ..AiB:>A....[p.. >>>>>>>>>>>> 0230 - 11 00 3d ec 66 5a 1a ca-31 89 22 27 02 dd a0 cb ..=.fZ..1."'.... >>>>>>>>>>>> 0240 - 39 14 25 ee 30 44 e8 62-97 bf 8e 16 63 40 c4 11 9.%.0D.b....c at .. >>>>>>>>>>>> 0250 - a6 d9 32 b1 3c 86 35 bb-9f f1 4d 71 9f a5 4f 78 ..2.<.5...Mq..Ox >>>>>>>>>>>> 0260 - 0a e8 96 dd 4d 10 c3 48-f2 db 67 57 2d cd dc 23 ....M..H..gW-..# >>>>>>>>>>>> 0270 - 3a 8d 6a 61 47 20 ff c8-33 cd e9 f7 47 4c 68 4f :.jaG ..3...GLhO >>>>>>>>>>>> 0280 - 19 2f 8b e3 b1 90 ac 66-a7 cf 5c e6 d2 05 21 25 ./.....f..\...!% >>>>>>>>>>>> 0290 - d2 d8 f0 43 8c 55 01 ef-d6 8f c0 27 87 0d 21 d5 ...C.U.....'..!. >>>>>>>>>>>> 02a0 - 2b 2b 6f db e8 85 ea cd-6e 9c 5d 56 d5 31 c1 f2 ++o.....n.]V.1.. >>>>>>>>>>>> 02b0 - 97 2f 5a 83 7a 2b 71 03-65 e0 b6 4a 56 37 de e1 ./Z.z+q.e..JV7.. >>>>>>>>>>>> 02c0 - 80 3a c4 cc 5a ac 3b 9a-7a bf f7 6b fe a8 69 e9 .:..Z.;.z..k..i. >>>>>>>>>>>> 02d0 - 58 09 59 bd 46 bd d2 a3-bc ad 1c 10 53 c8 29 7b X.Y.F.......S.){ >>>>>>>>>>>> 02e0 - be 63 00 d6 e5 a8 d6 ab-b2 bc 8b e1 2c 0e 24 2a .c..........,.$* >>>>>>>>>>>> 02f0 - c2 31 2d d8 6e 1f 19 93-d7 54 e1 1e 28 ce 72 83 .1-.n....T..(.r. >>>>>>>>>>>> 0300 - ff 05 18 f2 fc e9 0c b3-0c 1b d5 96 c2 d8 fc 76 ...............v >>>>>>>>>>>> 0310 - 37 a9 5a ef 8e e9 b6 71-21 f3 bd c1 85 23 85 22 7.Z....q!....#." >>>>>>>>>>>> 0320 - 3d c4 1c c9 31 8b 7e 00-8f 8e b4 9f 05 d4 80 6b =...1.~........k >>>>>>>>>>>> 0330 - 98 4c a8 82 68 ff 1a a5-28 e2 9b 03 a1 a7 b1 00 .L..h...(....... >>>>>>>>>>>> 0340 - 02 2b 2d e2 e1 87 8c e8-0a fb 0b 79 54 ca 3d d5 .+-........yT.=. >>>>>>>>>>>> 0350 - 6a dd b7 b7 87 42 2b 47-49 da e9 0a 82 0a c9 8f j....B+GI....... >>>>>>>>>>>> 0360 - 57 f7 1e 03 ca 8d 16 bc-21 3a 6a ee b9 b8 fa f0 W.......!:j..... >>>>>>>>>>>> 0370 - d9 18 35 9f 35 ac d8 6e-9a 8a 0d 56 10 1e 1f 5a ..5.5..n...V...Z >>>>>>>>>>>> 0380 - ba ec e4 fe 1a 92 b4 31-35 43 1d 99 b9 12 fa ff .......15C...... >>>>>>>>>>>> 0390 - 99 2b 88 e0 58 ec 9c dc-8f 67 ef 2a c2 e2 64 5d .+..X....g.*..d] >>>>>>>>>>>> 03a0 - 66 76 1c d0 aa 00 30 59-b1 f5 b1 55 9f ad 60 e9 fv....0Y...U..`. >>>>>>>>>>>> 03b0 - 3d 03 1e d0 8b 4d bf 74-ac bc bb 1c 83 14 c5 e0 =....M.t........ >>>>>>>>>>>> 03c0 - f4 fc 70 9e f4 22 a0 78-04 fe c8 b1 17 65 f6 94 ..p..".x.....e.. >>>>>>>>>>>> 03d0 - 47 82 50 4a b6 32 74 ae-5b 38 5a 2e d9 b0 6a 45 G.PJ.2t.[8Z...jE >>>>>>>>>>>> 03e0 - 74 e8 f0 22 fe d3 b0 11-c3 fd 72 4f da 77 7a ba t.."......rO.wz. >>>>>>>>>>>> 03f0 - 26 3e 61 0c 63 21 17 a6-b2 13 6e 71 5c f2 0d ad &>a.c!....nq\... >>>>>>>>>>>> 0400 - f2 d1 19 71 51 9e a4 1b-b0 30 24 e0 71 7d 87 80 ...qQ....0$.q}.. >>>>>>>>>>>> 0410 - a9 5a e9 bc db e4 4f 50-4d a1 bc bc 2c 4b 66 98 .Z....OPM...,Kf. >>>>>>>>>>>> 0420 - d4 e4 b0 76 0f d2 db a5-a5 39 9e f2 5b ea 34 c1 ...v.....9..[.4. >>>>>>>>>>>> 0430 - 62 ab 47 51 3b 37 17 45-54 31 18 f3 f1 ca 17 03 b.GQ;7.ET1...... >>>>>>>>>>>> 0440 - 03 01 19 dd 50 50 f5 0c-f2 c9 3c b4 8f 63 cc 4a ....PP....<..c.J >>>>>>>>>>>> 0450 - a7 50 c9 91 9b 79 9a 2a-5c 47 d3 77 f6 56 69 90 .P...y.*\G.w.Vi. >>>>>>>>>>>> 0460 - 98 cd ff bd c1 2a 49 fc-0d d4 7e cc 7e 44 af c4 .....*I...~.~D.. >>>>>>>>>>>> 0470 - 61 47 e0 c1 76 b1 8c 2e-df 7e d0 82 e1 89 1f 04 aG..v....~...... >>>>>>>>>>>> 0480 - ae 64 bd 71 4d ae 1c 3c-e3 d3 39 5d 61 2a ea 70 .d.qM..<..9]a*.p >>>>>>>>>>>> 0490 - 8c 31 6d a0 b1 72 a8 7a-5c 9c 11 08 b8 4d a5 c4 .1m..r.z\....M.. >>>>>>>>>>>> 04a0 - ad 1b 38 4a 6a 02 28 d4-d1 0f c8 9f 0b b3 02 18 ..8Jj.(......... >>>>>>>>>>>> 04b0 - 82 2b bd 46 82 04 64 f0-41 b2 da f5 cd 9c f7 f3 .+.F..d.A....... >>>>>>>>>>>> 04c0 - 73 30 58 ca 12 ec ea 90-85 1c 75 09 0a 70 b8 80 s0X.......u..p.. >>>>>>>>>>>> 04d0 - 3d 02 17 3e 9b 83 04 b5-dd 9e e6 18 17 65 83 a5 =..>.........e.. >>>>>>>>>>>> 04e0 - 59 7d 4b 98 da bd 8b aa-d6 aa c5 1c 7d 87 56 e3 Y}K.........}.V. >>>>>>>>>>>> 04f0 - 74 d8 e9 7b eb b3 3d f7-7c 3c 0a e9 a8 2e 04 0d t..{..=.|<...... >>>>>>>>>>>> 0500 - 6a e7 83 e0 ec 99 43 6a-8b 1c 73 59 7a c8 cd 6e j.....Cj..sYz..n >>>>>>>>>>>> 0510 - 4a 14 73 ff 9a fb 71 94-d5 50 a9 d9 e0 dd 02 4c J.s...q..P.....L >>>>>>>>>>>> 0520 - 2b 67 9e da 9e fa 2d 67-49 df 13 10 ed 35 3e 73 +g....-gI....5>s >>>>>>>>>>>> 0530 - 07 20 17 fb 0b ef f6 d0-b7 68 1c 65 21 a6 e3 3b . .......h.e!..; >>>>>>>>>>>> 0540 - bf 7b 84 cd 9e f5 76 2a-0d 4f b8 c3 c8 15 08 e9 .{....v*.O...... >>>>>>>>>>>> 0550 - 0f 3c 50 49 12 97 a8 d7-f1 a3 16 da 17 03 03 00 .>>>>>>>>>>> 0560 - 35 22 dd a2 9d 25 98 2c-35 b8 00 29 fa a1 dd ba 5"...%.,5..).... >>>>>>>>>>>> 0570 - 72 b9 fe e5 85 85 f0 f1-3b 4e f5 7c 58 c8 2a da r.......;N.|X.*. >>>>>>>>>>>> 0580 - d2 75 94 3b c1 7a 7c 7e-db 5b fe 8a 2d 3f 8c 9a .u.;.z|~.[..-?.. >>>>>>>>>>>> 0590 - 6e 79 ab 2b ff 1a ny.+.. >>>>>>>>>>>> SSL_accept:SSLv3/TLS write finished >>>>>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>>>>>>>> 0000 - 14 03 03 00 01 ..... >>>>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (1 bytes => 1 (0x1)) >>>>>>>>>>>> 0000 - 01 . >>>>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f603] (5 bytes => 5 (0x5)) >>>>>>>>>>>> 0000 - 17 03 03 00 3d ....= >>>>>>>>>>>> read from 0x7fe400f050c0 [0x7fe40300f608] (61 bytes => 61 (0x3D)) >>>>>>>>>>>> 0000 - 38 e7 bb 2c 5b af b6 5f-37 d8 3e 7e bb f4 04 f5 8..,[.._7.>~.... >>>>>>>>>>>> 0010 - e1 28 b5 e5 07 5a ec ce-da 2f f3 b6 45 61 cf ef .(...Z.../..Ea.. >>>>>>>>>>>> 0020 - 90 fb 57 b8 f3 20 45 27-60 d4 26 51 38 77 e4 bc ..W.. E'`.&Q8w.. >>>>>>>>>>>> 0030 - b7 64 d4 8b 73 25 41 9e-fe d3 9d 5f 53 .d..s%A...._S >>>>>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>>>>> write to 0x7fe400f050c0 [0x7fe403018a00] (24 bytes => 24 (0x18)) >>>>>>>>>>>> 0000 - 17 03 03 00 13 25 85 60-eb 7d c1 a8 15 49 d5 63 .....%.`.}...I.c >>>>>>>>>>>> 0010 - 18 7f c6 ac ed 7f df 77- .......w >>>>>>>>>>>> SSL3 alert write:fatal:unknown >>>>>>>>>>>> SSL_accept:error in error >>>>>>>>>>>> ERROR >>>>>>>>>>>> 140736092021632:error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate:ssl/statem/statem_srvr.c:3654: >>>>>>>>>>>> shutting down SSL >>>>>>>>>>>> CONNECTION CLOSED >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> When using openssl s_client all works as expected tho (thats also true if I use my native implementation on the client and server side that uses openssl): >>>>>>>>>>>> >>>>>>>>>>>> ./bin/openssl s_client -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 -state -tls1_3 -connect localhost:8443 >>>>>>>>>>>> >>>>>>>>>>>> The interesting thing is if I use ?-verify 1? and not ?-Verify 1? with openssl which tells it I want to request a certificate but will also process if none is provided I receive the certificate at some point as seen here: >>>>>>>>>>>> >>>>>>>>>>>> SSL_accept:before SSL initialization >>>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>>>> 0000 - 16 03 03 01 60 ....` >>>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (352 bytes => 352 (0x160)) >>>>>>>>>>>> 0000 - 01 00 01 5c 03 03 61 c0-b3 ed 88 65 e6 cf 11 3f ...\..a....e...? >>>>>>>>>>>> 0010 - c0 e0 f8 df a6 63 32 c2-ab 3d 61 6f 41 ed b1 4b .....c2..=aoA..K >>>>>>>>>>>> 0020 - 53 0e 83 e5 a1 b8 20 c7-1b 8c b8 e6 b5 da 4e 4e S..... .......NN >>>>>>>>>>>> 0030 - 3f 3c 61 7a ad 58 23 94-a7 32 79 2f db 9f 21 c0 ?>>>>>>>>>>> 0040 - 8e 0c c5 ce b1 c2 a4 00-14 c0 2c c0 2b c0 2f c0 ..........,.+./. >>>>>>>>>>>> 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 52 dc d6 47 6e .3.G.E...A.R..Gn >>>>>>>>>>>> 0120 - a1 de 9c 71 c2 54 0e 5c-9b 57 fb c8 aa 3f 19 f7 ...q.T.\.W...?.. >>>>>>>>>>>> 0130 - d3 a4 25 12 fa 3f 6c 6d-95 30 66 ca 63 b7 a1 dd ..%..?lm.0f.c... >>>>>>>>>>>> 0140 - ae 9f 99 d6 a8 6b 20 4f-29 7a 74 58 ad 58 de 12 .....k O)ztX.X.. >>>>>>>>>>>> 0150 - d7 a5 9b 69 dc 27 ac ec-9e d4 04 ff 01 00 01 00 ...i.'.......... >>>>>>>>>>>> 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 0x7fdc58809fb0 [0x7fdc59025e00] (1430 bytes => 1430 (0x596)) >>>>>>>>>>>> 0000 - 16 03 03 00 9b 02 00 00-97 03 03 8b c8 62 48 6c .............bHl >>>>>>>>>>>> 0010 - f5 7c 73 d9 17 f8 63 a2-11 27 40 93 09 26 53 06 .|s...c..'@..&S. >>>>>>>>>>>> 0020 - b3 62 df 46 26 b6 dc 59-29 b5 58 20 c7 1b 8c b8 .b.F&..Y).X .... >>>>>>>>>>>> 0030 - e6 b5 da 4e 4e 3f 3c 61-7a ad 58 23 94 a7 32 79 ...NN?>>>>>>>>>>> 0040 - 2f db 9f 21 c0 8e 0c c5-ce b1 c2 a4 13 01 00 00 /..!............ >>>>>>>>>>>> 0050 - 4f 00 2b 00 02 03 04 00-33 00 45 00 17 00 41 04 O.+.....3.E...A. >>>>>>>>>>>> 0060 - 07 63 1c 19 53 89 68 a8-0f ea 9e 4c 18 6f 2a ad .c..S.h....L.o*. >>>>>>>>>>>> 0070 - 2a df eb 17 a2 08 94 c6-e3 c5 97 ae 0f c1 1a d7 *............... >>>>>>>>>>>> 0080 - 0d d7 2e 6d 77 3d 30 a0-07 db 70 35 bb 37 dd 1e ...mw=0...p5.7.. >>>>>>>>>>>> 0090 - b6 f3 4d cb 13 97 7c 11-63 98 e8 64 2d a7 e6 cc ..M...|.c..d-... >>>>>>>>>>>> 00a0 - 14 03 03 00 01 01 17 03-03 00 27 a3 73 d2 ee 2c ..........'.s.., >>>>>>>>>>>> 00b0 - 2f 9c 8f 95 7f ca a3 89-bc b4 b3 b2 3c 8b 23 ef /...........<.#. >>>>>>>>>>>> 00c0 - 36 66 23 c9 09 02 33 0d-dc 5d 36 61 44 89 8b ef 6f#...3..]6aD... >>>>>>>>>>>> 00d0 - fd 13 17 03 03 00 42 f2-5b 3c 0c 27 5e 7f 97 4f ......B.[<.'^..O >>>>>>>>>>>> 00e0 - 0f de 8c b9 0a a1 41 c7-c2 1e 92 99 6a d5 bd 12 ......A.....j... >>>>>>>>>>>> 00f0 - 38 b6 b7 93 33 e9 8e 0f-44 93 f0 69 58 b6 41 22 8...3...D..iX.A" >>>>>>>>>>>> 0100 - 46 e2 4a d5 d6 32 2b b8-a7 ae 3a c2 c5 2f e6 35 F.J..2+...:../.5 >>>>>>>>>>>> 0110 - 11 0c f1 9a 35 2a 87 ed-9e 17 03 03 03 20 a7 e2 ....5*....... .. >>>>>>>>>>>> 0120 - fe ba c7 10 5b 9c cd 94-67 19 37 2d 46 59 ab 56 ....[...g.7-FY.V >>>>>>>>>>>> 0130 - 6b dd a4 10 61 cc ed f1-71 a7 2d 6a 41 2e 2b da k...a...q.-jA.+. >>>>>>>>>>>> 0140 - d1 35 fc 01 df 49 e5 90-1d 9b b2 03 0a 81 58 18 .5...I........X. >>>>>>>>>>>> 0150 - 96 a1 db 31 19 98 35 5c-87 8f 6e 32 0a e6 c0 aa ...1..5\..n2.... >>>>>>>>>>>> 0160 - 9e 8e 72 e2 34 b3 b7 a3-d6 d1 66 c7 ce 93 fe 78 ..r.4.....f....x >>>>>>>>>>>> 0170 - 17 c4 71 7c 42 15 c8 af-dc 4f 50 42 51 80 fc bf ..q|B....OPBQ... >>>>>>>>>>>> 0180 - fc 54 d5 d8 59 20 9a 90-c4 78 97 9c 2d 4a d5 58 .T..Y ...x..-J.X >>>>>>>>>>>> 0190 - be 81 79 23 59 22 9d 27-f8 bd a0 b2 98 b3 47 82 ..y#Y".'......G. >>>>>>>>>>>> 01a0 - d3 52 b5 b5 91 ab 5c 76-52 c5 a5 95 2d 03 1c b7 .R....\vR...-... >>>>>>>>>>>> 01b0 - 64 4d 0b 88 7f 15 0b c8-a8 90 50 9a b6 b1 9f b7 dM........P..... >>>>>>>>>>>> 01c0 - 40 09 f2 5f 39 f8 9a 06-21 4d 67 10 0a 67 08 b6 @.._9...!Mg..g.. >>>>>>>>>>>> 01d0 - b5 9a 25 8c d5 ca 31 6a-8a 6b 01 93 7d 6f 1e 52 ..%...1j.k..}o.R >>>>>>>>>>>> 01e0 - 98 96 9d fb e8 c1 07 ab-57 98 2d 1e 75 77 ef c2 ........W.-.uw.. >>>>>>>>>>>> 01f0 - 49 78 e0 b9 2b 32 23 7e-95 4d 3e 27 00 61 86 0c Ix..+2#~.M>'.a.. >>>>>>>>>>>> 0200 - 47 c7 79 e4 ee 9d ba c0-ea 62 f1 0d 8e 4a 91 30 G.y......b...J.0 >>>>>>>>>>>> 0210 - bc 4f 5a 98 26 30 66 ec-c4 63 8f 28 d5 1c 61 23 .OZ.&0f..c.(..a# >>>>>>>>>>>> 0220 - ea e9 90 4e 36 d9 fa 31-7b 14 27 22 0a ae 9f 64 ...N6..1{.'"...d >>>>>>>>>>>> 0230 - 40 3d e5 a0 5c 9d 3c 04-71 09 b0 7a 6b 51 a0 9c @=..\.<.q..zkQ.. >>>>>>>>>>>> 0240 - c0 61 32 ce 15 62 8e 29-b1 59 91 c0 17 2c b3 c5 .a2..b.).Y...,.. >>>>>>>>>>>> 0250 - f9 ed 07 65 3d 11 de 98-de 62 36 50 74 37 af 2d ...e=....b6Pt7.- >>>>>>>>>>>> 0260 - 7d 86 55 c4 3e a2 83 ab-47 8d f2 b2 8d 1d 75 83 }.U.>...G.....u. >>>>>>>>>>>> 0270 - b5 e4 41 87 a7 a3 85 b0-5e 4e 2e 9c 8c b0 1b 83 ..A.....^N...... >>>>>>>>>>>> 0280 - 7b 54 79 c9 60 ea 7d ed-06 fa dd 24 40 f1 53 9e {Ty.`.}....$@.S. >>>>>>>>>>>> 0290 - 43 79 25 53 9c c7 6e 95-ab 9f 96 59 cd b9 7b a8 Cy%S..n....Y..{. >>>>>>>>>>>> 02a0 - a0 23 13 69 db a9 c9 e7-1a 8e e1 9b 54 94 1c 44 .#.i........T..D >>>>>>>>>>>> 02b0 - 50 08 8b dd eb 4e 2b bb-d7 c9 c2 33 8c a1 b3 65 P....N+....3...e >>>>>>>>>>>> 02c0 - 06 e6 9d ac 11 16 21 58-40 8d 59 e6 67 e5 31 02 ......!X at .Y.g.1. >>>>>>>>>>>> 02d0 - 15 8d 29 80 20 66 ba c3-56 93 95 5c 65 4b 41 00 ..). f..V..\eKA. >>>>>>>>>>>> 02e0 - c5 71 12 12 f5 20 4f 59-be 77 06 10 6e 48 85 5c .q... OY.w..nH.\ >>>>>>>>>>>> 02f0 - ff a2 c4 ae fb 4d 95 f5-cc f6 61 20 33 b7 92 1d .....M....a 3... >>>>>>>>>>>> 0300 - ac a8 f1 b2 b0 88 c6 7b-8b 00 53 30 6d 4a d1 42 .......{..S0mJ.B >>>>>>>>>>>> 0310 - b3 3e 85 f5 84 e1 c6 ab-10 9d 61 03 46 ff 2d 81 .>........a.F.-. >>>>>>>>>>>> 0320 - 15 4f 84 d1 4c ee f4 a6-a0 ec 50 60 a0 d1 ff df .O..L.....P`.... >>>>>>>>>>>> 0330 - 8a 97 f6 7d fb 8f fb 60-18 d4 f1 1f 92 4d d8 69 ...}...`.....M.i >>>>>>>>>>>> 0340 - b1 92 97 44 0f 3c 8a aa-47 07 48 d4 07 2d 3e f2 ...D.<..G.H..->. >>>>>>>>>>>> 0350 - c4 a7 16 35 a7 17 71 ef-98 84 24 67 12 58 30 3b ...5..q...$g.X0; >>>>>>>>>>>> 0360 - 1d 41 8d e5 12 52 95 64-e5 88 35 99 d7 c3 58 40 .A...R.d..5...X@ >>>>>>>>>>>> 0370 - f9 55 9b 9f e5 33 15 70-41 d7 45 ba a4 fc 75 ea .U...3.pA.E...u. >>>>>>>>>>>> 0380 - a4 ae f0 68 ea 64 d8 f5-06 68 a9 75 22 4d 43 cc ...h.d...h.u"MC. >>>>>>>>>>>> 0390 - ff 50 cc ac 6e fd 43 dd-eb e4 c8 dd 4b 6c 12 bb .P..n.C.....Kl.. >>>>>>>>>>>> 03a0 - f1 d4 5e 11 4a 86 90 0b-f8 3a 2e 23 db 61 5a 1f ..^.J....:.#.aZ. >>>>>>>>>>>> 03b0 - 7e 11 00 92 21 68 1f b5-ab f2 f8 38 5e 62 ea f8 ~...!h.....8^b.. >>>>>>>>>>>> 03c0 - da ef c2 6e a0 b8 20 e4-69 49 b3 1f 15 84 0b 9b ...n.. .iI...... >>>>>>>>>>>> 03d0 - ce b0 6f 36 32 7f 7e bf-e8 d7 18 7a 58 60 f4 04 ..o62.~....zX`.. >>>>>>>>>>>> 03e0 - cc 36 bf 06 cd ec e5 9b-19 03 96 09 fb af 8f c3 .6.............. >>>>>>>>>>>> 03f0 - 98 b4 02 aa e8 55 81 aa-c4 fe 06 81 30 a0 c7 b2 .....U......0... >>>>>>>>>>>> 0400 - f8 e2 30 00 d7 a0 54 7f-5f d7 ef a6 f8 41 58 34 ..0...T._....AX4 >>>>>>>>>>>> 0410 - f5 f0 18 69 8d e6 7a 23-78 90 8f b1 05 c5 b5 7f ...i..z#x....... >>>>>>>>>>>> 0420 - e0 f2 c7 fa c8 36 5b 53-7e cf e6 75 d3 54 b4 69 .....6[S~..u.T.i >>>>>>>>>>>> 0430 - 68 43 0d 6a d2 83 cc 13-6d ca bf 83 3c 90 17 03 hC.j....m...<... >>>>>>>>>>>> 0440 - 03 01 19 96 dc 49 26 ce-1d 8e 86 3d bd cb 00 5e .....I&....=...^ >>>>>>>>>>>> 0450 - ee f6 e7 1d 16 7a ca ef-fa 6d 16 40 b6 99 d0 c1 .....z...m. at .... >>>>>>>>>>>> 0460 - df 0b 5f 51 60 a8 24 e0-61 82 13 40 da 88 38 3a .._Q`.$.a.. at ..8: >>>>>>>>>>>> 0470 - 26 1d 80 51 c4 b1 95 35-95 3c 91 35 28 17 49 d8 &..Q...5.<.5(.I. >>>>>>>>>>>> 0480 - c3 45 be 32 98 3e 02 07-3b 01 20 2b 51 e1 1a 94 .E.2.>..;. +Q... >>>>>>>>>>>> 0490 - b9 be 96 aa 7a 13 09 ff-d5 a9 63 d4 6f 49 cb b5 ....z.....c.oI.. >>>>>>>>>>>> 04a0 - 23 ab 7f 8c e2 63 f0 5c-5c 27 1e 04 a8 71 0c c0 #....c.\\'...q.. >>>>>>>>>>>> 04b0 - 89 cd ed 18 8d 5b 75 ac-af f3 68 6d cc ba 20 38 .....[u...hm.. 8 >>>>>>>>>>>> 04c0 - b5 7c 09 47 29 28 e2 26-57 57 1f f0 f3 18 fd 6f .|.G)(.&WW.....o >>>>>>>>>>>> 04d0 - 27 42 a4 e3 de bb e5 d6-09 7d 25 b1 98 97 ad 33 'B.......}%....3 >>>>>>>>>>>> 04e0 - 68 35 92 07 80 23 f1 66-20 5d 74 f3 02 c5 51 ff h5...#.f ]t...Q. >>>>>>>>>>>> 04f0 - 07 a9 e9 0e 3e 74 da 2e-8f 3b 16 be e6 94 1b 66 ....>t...;.....f >>>>>>>>>>>> 0500 - bb b2 a2 1e 7c 7b ff 5e-a4 36 2a ba 0b cd 7f e9 ....|{.^.6*..... >>>>>>>>>>>> 0510 - 86 bb 5e 30 f5 57 92 52-82 b6 2e da 71 b7 22 c2 ..^0.W.R....q.". >>>>>>>>>>>> 0520 - 90 c4 69 46 07 df 6c 3f-05 8b 19 3e ce b9 75 0d ..iF..l?...>..u. >>>>>>>>>>>> 0530 - 4b 97 37 ae 94 e2 d6 3c-91 e6 82 c7 a1 78 79 2c K.7....<.....xy, >>>>>>>>>>>> 0540 - 9a a3 d5 45 94 ad e2 c8-ab fd 81 ec 62 87 f7 75 ...E........b..u >>>>>>>>>>>> 0550 - e3 70 79 8e 82 3b c5 45-0d d0 33 5f 17 03 03 00 .py..;.E..3_.... >>>>>>>>>>>> 0560 - 35 da e0 74 2a 06 41 5a-64 1e 54 94 29 73 43 3f 5..t*.AZd.T.)sC? >>>>>>>>>>>> 0570 - e5 24 a8 ba b2 7e 6b 26-82 fc d9 f6 dd 19 05 4a .$...~k&.......J >>>>>>>>>>>> 0580 - 2c 1a f3 bb 16 1d 38 95-a6 d3 a8 58 f6 a3 41 c7 ,.....8....X..A. >>>>>>>>>>>> 0590 - 92 44 35 24 25 0e .D5$%. >>>>>>>>>>>> SSL_accept:SSLv3/TLS write finished >>>>>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>>>> 0000 - 14 03 03 00 01 ..... >>>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (1 bytes => 1 (0x1)) >>>>>>>>>>>> 0000 - 01 . >>>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>>>> 0000 - 17 03 03 00 3d ....= >>>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (61 bytes => 61 (0x3D)) >>>>>>>>>>>> 0000 - ad dd 3e d9 ee ab 56 65-50 1c 72 2a d8 62 7f 90 ..>...VeP.r*.b.. >>>>>>>>>>>> 0010 - 13 71 7d 37 39 40 fb 89-8f 05 4b 39 44 9d 4d 67 .q}79 at ....K9D.Mg >>>>>>>>>>>> 0020 - e3 41 29 b6 3e e8 fe 04-1b 8e eb 7a 4c e2 14 a0 .A).>......zL... >>>>>>>>>>>> 0030 - b1 c2 47 3f 94 35 ed ab-8a d1 75 3b ba ..G?.5....u;. >>>>>>>>>>>> SSL_accept:TLSv1.3 early data >>>>>>>>>>>> SSL_accept:SSLv3/TLS read client certificate >>>>>>>>>>>> SSL_accept:SSLv3/TLS read finished >>>>>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>>>>>>>>> 0000 - 17 03 03 00 da 52 1f 48-00 f4 31 13 90 7f 9c c2 .....R.H..1..... >>>>>>>>>>>> 0010 - fc 70 1a fc f7 4a 48 e7-31 ad 37 ab b5 2b 4e 5c .p...JH.1.7..+N\ >>>>>>>>>>>> 0020 - e8 d8 6d e9 af 6c 4f c1-9e 7b ea ff ef b3 eb 74 ..m..lO..{.....t >>>>>>>>>>>> 0030 - 27 67 10 21 66 5b 32 13-31 bc 99 d5 1c 6c 79 55 'g.!f[2.1....lyU >>>>>>>>>>>> 0040 - f3 3e f6 4b 07 4d a9 78-3d 12 8a f5 38 ef d9 f4 .>.K.M.x=...8... >>>>>>>>>>>> 0050 - 48 e0 2c 35 94 06 4f eb-09 e6 70 fb 59 95 7a c8 H.,5..O...p.Y.z. >>>>>>>>>>>> 0060 - 24 dd 24 e2 f9 63 b9 3c-f2 66 86 c4 73 44 53 fd $.$..c.<.f..sDS. >>>>>>>>>>>> 0070 - ca 67 8f 01 d6 db 70 f9-60 bc 50 11 51 72 dc 63 .g....p.`.P.Qr.c >>>>>>>>>>>> 0080 - 12 ca 4f 23 e2 c5 d1 1d-e5 b0 d4 ec 89 ca 28 be ..O#..........(. >>>>>>>>>>>> 0090 - 9c 30 83 40 02 a4 62 a8-5c b3 20 1a ab 39 b7 7b .0. at ..b.\. ..9.{ >>>>>>>>>>>> 00a0 - 89 13 39 87 73 be a8 f8-60 13 31 0a 48 5c 79 b9 ..9.s...`.1.H\y. >>>>>>>>>>>> 00b0 - cc 4a 51 e3 0d d2 b4 93-c0 1f 3a 22 b3 fa 24 a0 .JQ.......:"..$. >>>>>>>>>>>> 00c0 - 7c f6 76 79 d0 2d 5b 1a-ff a6 e9 e1 40 d3 b1 8c |.vy.-[..... at ... >>>>>>>>>>>> 00d0 - 0a fa fa de f3 8e d6 ad-9a 22 6b 67 0b 88 18 ........."kg... >>>>>>>>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59025e00] (223 bytes => 223 (0xDF)) >>>>>>>>>>>> 0000 - 17 03 03 00 da 46 aa ea-6a 37 b1 35 e8 41 c8 b3 .....F..j7.5.A.. >>>>>>>>>>>> 0010 - 84 25 af 1c 36 a3 6d 78-a4 44 4a 83 52 ef 13 7c .%..6.mx.DJ.R..| >>>>>>>>>>>> 0020 - 8f 18 d3 4c f8 22 c8 b3-ad d0 d0 5b 47 a0 43 da ...L.".....[G.C. >>>>>>>>>>>> 0030 - d2 6e 04 8f dc c9 56 90-58 87 62 63 4c cc 31 ec .n....V.X.bcL.1. >>>>>>>>>>>> 0040 - b8 c9 18 be 41 32 e1 3c-00 41 2a f1 4d 5c 2d 44 ....A2.<.A*.M\-D >>>>>>>>>>>> 0050 - 8c aa e1 f0 ed 38 ee 44-64 e5 fd ea 58 3b 84 5d .....8.Dd...X;.] >>>>>>>>>>>> 0060 - 83 39 21 2e fe 79 4d 76-10 65 87 0f 3c ac df 28 .9!..yMv.e..<..( >>>>>>>>>>>> 0070 - 49 f8 60 eb be 49 e4 0a-0b 6a 03 2b 9d cf 9b a5 I.`..I...j.+.... >>>>>>>>>>>> 0080 - 03 56 58 32 c2 b2 59 f9-0a 0d f0 ae af ff 20 19 .VX2..Y....... . >>>>>>>>>>>> 0090 - e5 6e e4 86 2f 5e 3f 7d-47 d5 73 ae 89 48 a7 66 .n../^?}G.s..H.f >>>>>>>>>>>> 00a0 - fb 2d 83 60 e8 8b ab 27-12 db 24 78 54 eb 14 2d .-.`...'..$xT..- >>>>>>>>>>>> 00b0 - b7 c6 17 2d 3c 91 57 ac-6e 35 b8 c3 fa c2 42 48 ...-<.W.n5....BH >>>>>>>>>>>> 00c0 - 2a cb aa 98 32 89 8a ce-0c f7 cd 5e fb bf 6d 33 *...2......^..m3 >>>>>>>>>>>> 00d0 - 08 50 cf 1e 06 bb a1 98-be a4 a9 51 9a b0 34 .P.........Q..4 >>>>>>>>>>>> SSL_accept:SSLv3/TLS write session ticket >>>>>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>>>>>>> 0000 - 17 03 03 00 12 c5 9b 73-cc 91 7e 48 cb 25 31 a0 .......s..~H.%1. >>>>>>>>>>>> 0010 - 67 41 db bb 0f 62 d8 gA...b. >>>>>>>>>>>> write to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>>>>>>> 0000 - 17 03 03 00 12 0f dd 3f-c1 7c e6 b0 cc ea f0 13 .......?.|...... >>>>>>>>>>>> 0010 - 00 d8 01 de ef 7c bb .....|. >>>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>>>> 0000 - 17 03 03 00 1e ..... >>>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (30 bytes => 30 (0x1E)) >>>>>>>>>>>> 0000 - d6 88 44 82 cb 23 16 ba-c9 a4 fb 55 51 08 90 c1 ..D..#.....UQ... >>>>>>>>>>>> 0010 - bf bd a1 7f 0e 37 b0 b4-b5 df f1 07 6c 07 .....7......l. >>>>>>>>>>>> I am a clientwrite to 0x7fdc58809fb0 [0x7fdc59021c03] (23 bytes => 23 (0x17)) >>>>>>>>>>>> 0000 - 17 03 03 00 12 c0 70 5d-14 e7 69 57 0a d8 64 16 ......p]..iW..d. >>>>>>>>>>>> 0010 - 0c 90 06 0f c3 4d 1d .....M. >>>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da03] (5 bytes => 5 (0x5)) >>>>>>>>>>>> 0000 - 17 03 03 00 13 ..... >>>>>>>>>>>> read from 0x7fdc58809fb0 [0x7fdc5901da08] (19 bytes => 19 (0x13)) >>>>>>>>>>>> 0000 - 60 28 5b ff bb 0d 9f 96-9a 2d cb fd 60 eb 96 62 `([......-..`..b >>>>>>>>>>>> 0010 - 53 e6 25 S.% >>>>>>>>>>>> SSL3 alert read:warning:close notify >>>>>>>>>>>> DONE >>>>>>>>>>>> shutting down SSL >>>>>>>>>>>> CONNECTION CLOSED >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I am using the following JDK version on MacOS: >>>>>>>>>>>> >>>>>>>>>>>> ssl git:(cert_cb_openssl_1_1_1) ? /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java -version >>>>>>>>>>>> java version "11" 2018-09-25 >>>>>>>>>>>> Java(TM) SE Runtime Environment 18.9 (build 11+28) >>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode) >>>>>>>>>>>> >>>>>>>>>>>> For this to work you will need to have openssl 1.1.1 installed. >>>>>>>>>>>> >>>>>>>>>>>> Any help would be welcome, >>>>>>>>>>>> Norman >>>>>>>>>>>> >>>>>>>>>>>> [1] https://github.com/netty/netty-tcnative >>>> >>> From xuelei.fan at oracle.com Thu Sep 20 20:02:00 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 20 Sep 2018 13:02:00 -0700 Subject: Code Review Request, JDK-8210974 : No extensions debug log for ClientHello Message-ID: <784e904a-a3a4-78ea-ff59-079c291b261f@oracle.com> Hi, Please review this simple fix for SunJSSE debug log: http://cr.openjdk.java.net/~xuelei/8210974/webrev.00/ The debug log for ClientHello message does not appear in JDK 12. Trivial update, no new regression test. Thanks, Xuelei From jamil.j.nimeh at oracle.com Thu Sep 20 20:03:07 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 20 Sep 2018 13:03:07 -0700 Subject: Code Review Request, JDK-8210974 : No extensions debug log for ClientHello In-Reply-To: <784e904a-a3a4-78ea-ff59-079c291b261f@oracle.com> References: <784e904a-a3a4-78ea-ff59-079c291b261f@oracle.com> Message-ID: <9e2136aa-40e4-63fd-e698-70404213ecd2@oracle.com> Looks good. On 9/20/2018 1:02 PM, Xuelei Fan wrote: > Hi, > > Please review this simple fix for SunJSSE debug log: > ? http://cr.openjdk.java.net/~xuelei/8210974/webrev.00/ > > The debug log for ClientHello message does not appear in JDK 12. > Trivial update, no new regression test. > > Thanks, > Xuelei From bradford.wetmore at oracle.com Thu Sep 20 20:57:54 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 20 Sep 2018 13:57:54 -0700 Subject: Code Review Request, JDK-8210974 : No extensions debug log for ClientHello In-Reply-To: <9e2136aa-40e4-63fd-e698-70404213ecd2@oracle.com> References: <784e904a-a3a4-78ea-ff59-079c291b261f@oracle.com> <9e2136aa-40e4-63fd-e698-70404213ecd2@oracle.com> Message-ID: Ditto. Brad On 9/20/2018 1:03 PM, Jamil Nimeh wrote: > Looks good. > > On 9/20/2018 1:02 PM, Xuelei Fan wrote: >> Hi, >> >> Please review this simple fix for SunJSSE debug log: >> ? http://cr.openjdk.java.net/~xuelei/8210974/webrev.00/ >> >> The debug log for ClientHello message does not appear in JDK 12. >> Trivial update, no new regression test. >> >> Thanks, >> Xuelei > From jamil.j.nimeh at oracle.com Fri Sep 21 06:51:34 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 20 Sep 2018 23:51:34 -0700 Subject: RFR: backport of JDK-8209916, JDK-8210334, JDK-8210846 to jdk11u Message-ID: Hello all, This review is for a backport of 3 TLS interoperability issues that have come up over the past week or so.? These are already in jdk/jdk.? They cover the following issues: * An NPE thrown during processing of the supported groups extension with curves not enabled by default * A problem processing client hellos where pre_shared_key and psk_key_exchange_modes extensions are both omitted * A problem where JSSE TLS clients send empty Certificate messages during client certificate authentication Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/jdk11u-tls-compat/webrev.01/ JBS Issues: https://bugs.openjdk.java.net/browse/JDK-8209916 https://bugs.openjdk.java.net/browse/JDK-8210334 https://bugs.openjdk.java.net/browse/JDK-8210846 Thanks, --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Sep 21 14:20:53 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 21 Sep 2018 07:20:53 -0700 Subject: RFR: backport of JDK-8209916, JDK-8210334, JDK-8210846 to jdk11u In-Reply-To: References: Message-ID: <43a6c0a1-62b0-2821-82b0-54f2b86e5f40@oracle.com> Looks fine to me. Thanks, Xuelei On 9/20/2018 11:51 PM, Jamil Nimeh wrote: > Hello all, > > This review is for a backport of 3 TLS interoperability issues that have > come up over the past week or so.? These are already in jdk/jdk.? They > cover the following issues: > > * An NPE thrown during processing of the supported groups extension > with curves not enabled by default > * A problem processing client hellos where pre_shared_key and > psk_key_exchange_modes extensions are both omitted > * A problem where JSSE TLS clients send empty Certificate messages > during client certificate authentication > > Webrev: > http://cr.openjdk.java.net/~jnimeh/reviews/jdk11u-tls-compat/webrev.01/ > > JBS Issues: > https://bugs.openjdk.java.net/browse/JDK-8209916 > https://bugs.openjdk.java.net/browse/JDK-8210334 > https://bugs.openjdk.java.net/browse/JDK-8210846 > > Thanks, > --Jamil From sean.mullan at oracle.com Fri Sep 21 18:49:12 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 21 Sep 2018 14:49:12 -0400 Subject: RFR 8076190: Support passwordless access to PKCS12 keystores In-Reply-To: <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> Message-ID: Still reviewing but here are some initial comments. It seems this is more than a fix for JDK-8076190. It also adds configuration properties for the PKCS12 algorithms. I think you should expand the scope/description of the issue to include that. * HmacPKCS12PBECore.java The class description should be updated to PKCS #12 v1.1 and list the new algorithms that you added. * java.security Change "PKCS 12" to "PKCS12" to match the standard name. These properties are also for existing keystores so I would change the first sentence to mention that, ex: "... during the creation of a new keystore or modification of an existing keystore." The default alg values seem somewhat weak. Can we upgrade them or is there a compatibility issue/risk? --Sean On 8/9/18 5:55 AM, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8076190/webrev.02 > > The only change is in keytool/Main and the test. keytool will not prompt for store password if it detects a password-less keystore. > > This is 3) below. > > Thanks > Max > >> On Jul 24, 2018, at 6:49 PM, Weijun Wang wrote: >> >> Please review the code change and CSR at >> >> webrev: http://cr.openjdk.java.net/~weijun/8076190/webrev.01/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8202590 >> >> The bug is at >> >> https://bugs.openjdk.java.net/browse/JDK-8076190 >> >> This is the 1st part of the process to make cacerts using pkcs12: >> >> 1. Support passwordless access to PKCS12 keystores >> 2. Update default algorithms and params when creating a PKCS12 keystore >> 3. Update keytool to support passwordless pkcs12 keystores >> 4. Migrate cacerts to pkcs12 >> >> Thanks >> Max >> > From dblack at atlassian.com Fri Sep 21 18:55:38 2018 From: dblack at atlassian.com (David Black) Date: Fri, 21 Sep 2018 20:55:38 +0200 Subject: How does securely obtain and verify openjdk repositories as a non-contributor? In-Reply-To: <5380ea09-809e-0834-68f6-ad342c2e1c2f@oracle.com> References: <5380ea09-809e-0834-68f6-ad342c2e1c2f@oracle.com> Message-ID: On 31 August 2018 at 20:16, Bradford Wetmore wrote: > I would suggest contacting ops at openjdk.java.net, they should be able to > answer these kinds of infrastructure questions. Hi, I have emailed that address but I am yet to hear back. Additionally, I have raised a bug with AdoptOpenJDK about how they obtain OpenJdk sources (https://github.com/AdoptOpenJDK/openjdk-build/issues/514). -- David Black / Security Engineer. From bradford.wetmore at oracle.com Fri Sep 21 21:22:19 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 21 Sep 2018 14:22:19 -0700 Subject: RFR: backport of JDK-8209916, JDK-8210334, JDK-8210846 to jdk11u In-Reply-To: References: Message-ID: Looks fine. Where are your new regression tests for 916/334? Will that be under a separate bug? Thanks. Brad On 9/20/2018 11:51 PM, Jamil Nimeh wrote: > Hello all, > > This review is for a backport of 3 TLS interoperability issues that have > come up over the past week or so.? These are already in jdk/jdk.? They > cover the following issues: > > * An NPE thrown during processing of the supported groups extension > with curves not enabled by default > * A problem processing client hellos where pre_shared_key and > psk_key_exchange_modes extensions are both omitted > * A problem where JSSE TLS clients send empty Certificate messages > during client certificate authentication > > Webrev: > http://cr.openjdk.java.net/~jnimeh/reviews/jdk11u-tls-compat/webrev.01/ > > JBS Issues: > https://bugs.openjdk.java.net/browse/JDK-8209916 > https://bugs.openjdk.java.net/browse/JDK-8210334 > https://bugs.openjdk.java.net/browse/JDK-8210846 > > Thanks, > --Jamil From jamil.j.nimeh at oracle.com Fri Sep 21 21:24:51 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 21 Sep 2018 14:24:51 -0700 Subject: RFR: backport of JDK-8209916, JDK-8210334, JDK-8210846 to jdk11u In-Reply-To: References: Message-ID: <95ee751e-958a-353f-b5b0-2474c03c1e3c@oracle.com> Yep, code review coming in a few minutes. --Jamil On 9/21/2018 2:22 PM, Bradford Wetmore wrote: > Looks fine. > > Where are your new regression tests for 916/334?? Will that be under a > separate bug? > > Thanks. > > Brad > > > > On 9/20/2018 11:51 PM, Jamil Nimeh wrote: >> Hello all, >> >> This review is for a backport of 3 TLS interoperability issues that >> have come up over the past week or so.? These are already in >> jdk/jdk.? They cover the following issues: >> >> ? * An NPE thrown during processing of the supported groups extension >> ??? with curves not enabled by default >> ? * A problem processing client hellos where pre_shared_key and >> ??? psk_key_exchange_modes extensions are both omitted >> ? * A problem where JSSE TLS clients send empty Certificate messages >> ??? during client certificate authentication >> >> Webrev: >> http://cr.openjdk.java.net/~jnimeh/reviews/jdk11u-tls-compat/webrev.01/ >> >> JBS Issues: >> https://bugs.openjdk.java.net/browse/JDK-8209916 >> https://bugs.openjdk.java.net/browse/JDK-8210334 >> https://bugs.openjdk.java.net/browse/JDK-8210846 >> >> Thanks, >> --Jamil From jamil.j.nimeh at oracle.com Fri Sep 21 21:35:40 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 21 Sep 2018 14:35:40 -0700 Subject: RFR: JDK-8210918, Add test to exercise server-side client hello processing Message-ID: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> Hello all, This adds a test that lets us send different kinds of client hellos to a JSSE server. It can be extended to handle different kinds of corner cases for client hello extension sets as well as fuzzing test cases in the future.? It also provides some extra test coverage for JDK-8210334 and JDK-8209916. Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8210918 Thanks and have a good weekend, --Jamil From xuelei.fan at oracle.com Fri Sep 21 22:55:36 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 21 Sep 2018 15:55:36 -0700 Subject: RFR: JDK-8210918, Add test to exercise server-side client hello processing In-Reply-To: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> References: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> Message-ID: <38fbcd4c-617b-01e5-1d96-defe43dc2153@oracle.com> Once there is a test case failed, it may be not straightforward to identify which one is failed. Especially, currently, the testing blog may be swallowed if it is too long. Would you please consider one case per test? Or break immediately if a test case failed, instead of waiting for all to complete? Thanks, Xuelei On 9/21/2018 2:35 PM, Jamil Nimeh wrote: > Hello all, > > This adds a test that lets us send different kinds of client hellos to a > JSSE server. It can be extended to handle different kinds of corner > cases for client hello extension sets as well as fuzzing test cases in > the future.? It also provides some extra test coverage for JDK-8210334 > and JDK-8209916. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.01/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8210918 > > Thanks and have a good weekend, > --Jamil From jamil.j.nimeh at oracle.com Fri Sep 21 23:00:53 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 21 Sep 2018 16:00:53 -0700 Subject: RFR: JDK-8210918, Add test to exercise server-side client hello processing In-Reply-To: <38fbcd4c-617b-01e5-1d96-defe43dc2153@oracle.com> References: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> <38fbcd4c-617b-01e5-1d96-defe43dc2153@oracle.com> Message-ID: <6ad5efaa-152c-6499-6f57-dbef613ac906@oracle.com> Are you suggesting having multiple run lines or something like that?? I think we could do that.? I would like to have it run all cases rather than short-circuit on the first failure, as each case doesn't depend on the others.? Let me play around with the run directives and see if we can make it work more along the lines you want. --Jamil On 09/21/2018 03:55 PM, Xuelei Fan wrote: > Once there is a test case failed, it may be not straightforward to > identify which one is failed.? Especially, currently, the testing blog > may be swallowed if it is too long.?? Would you please consider one > case per test?? Or break immediately if a test case failed, instead of > waiting for all to complete? > > Thanks, > Xuelei > > On 9/21/2018 2:35 PM, Jamil Nimeh wrote: >> Hello all, >> >> This adds a test that lets us send different kinds of client hellos >> to a JSSE server. It can be extended to handle different kinds of >> corner cases for client hello extension sets as well as fuzzing test >> cases in the future.? It also provides some extra test coverage for >> JDK-8210334 and JDK-8209916. >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.01/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210918 >> >> Thanks and have a good weekend, >> --Jamil From xuelei.fan at oracle.com Fri Sep 21 23:15:40 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 21 Sep 2018 16:15:40 -0700 Subject: RFR: JDK-8210918, Add test to exercise server-side client hello processing In-Reply-To: <6ad5efaa-152c-6499-6f57-dbef613ac906@oracle.com> References: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> <38fbcd4c-617b-01e5-1d96-defe43dc2153@oracle.com> <6ad5efaa-152c-6499-6f57-dbef613ac906@oracle.com> Message-ID: On 9/21/2018 4:00 PM, Jamil Nimeh wrote: > Are you suggesting having multiple run lines or something like that?? I > think we could do that. I would prefer to to the run lines. > I would like to have it run all cases rather > than short-circuit on the first failure, as each case doesn't depend on > the others. It should be fine to break earlier as normally the test should be passed. > Let me play around with the run directives and see if we > can make it work more along the lines you want. > Thanks! Xuelei > --Jamil > > > On 09/21/2018 03:55 PM, Xuelei Fan wrote: >> Once there is a test case failed, it may be not straightforward to >> identify which one is failed.? Especially, currently, the testing blog >> may be swallowed if it is too long.?? Would you please consider one >> case per test?? Or break immediately if a test case failed, instead of >> waiting for all to complete? >> >> Thanks, >> Xuelei >> >> On 9/21/2018 2:35 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This adds a test that lets us send different kinds of client hellos >>> to a JSSE server. It can be extended to handle different kinds of >>> corner cases for client hello extension sets as well as fuzzing test >>> cases in the future.? It also provides some extra test coverage for >>> JDK-8210334 and JDK-8209916. >>> >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.01/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210918 >>> >>> Thanks and have a good weekend, >>> --Jamil > From bradford.wetmore at oracle.com Fri Sep 21 23:20:23 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 21 Sep 2018 16:20:23 -0700 Subject: RFR: JDK-8210918, Add test to exercise server-side client hello processing In-Reply-To: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> References: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> Message-ID: <16436985-02cc-8894-6a4d-ea472e7704f9@oracle.com> Take my "personal preference" comments with a grain of salt. This test may be part of a test template, so if some of my comments (e.g. 340/412) are because of your test modification, you can ignore them. CliHelloProcessing.java ----------------------- My personal preference is to have the names written out for testing, unless there is a real reason to not. ClientHelloExtensionProcessing.java? You can immediately tell what the test is doing by the name. 74: Would you please include a printout of what's actually being sent here? That would help people parse it instead of having to run it and then print out the debug information. This might also come in handy to help folks understand what you tested against when other problems with other extensions come up. 74: You might mention that this might happen when clients that don't support PSK are used. 248: You might mention that we know about names, but didn't support it (IIRC), and would fail if we tried to use it. 283: Would it be better just to create a single static SSLContext, and then create SSLEngines from that, rather that creating a bunch of SSLContexts? Same with the packet bufs. 336: Personal preference again: it could be just an Exception, rather than RTE, since this is not a programming error. 340: Why are passing proto, then not using it? 347: If you're going to be running with debug on, maybe include the packet dump as well, rather than a separate println here? 412: You're passing back hsStatus, but not using it. Suggest void. Hope this helps. Brad On 9/21/2018 2:35 PM, Jamil Nimeh wrote: > Hello all, > > This adds a test that lets us send different kinds of client hellos to a > JSSE server. It can be extended to handle different kinds of corner > cases for client hello extension sets as well as fuzzing test cases in > the future.? It also provides some extra test coverage for JDK-8210334 > and JDK-8209916. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.01/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8210918 > > Thanks and have a good weekend, > --Jamil From bradford.wetmore at oracle.com Fri Sep 21 23:22:46 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 21 Sep 2018 16:22:46 -0700 Subject: RFR: JDK-8210918, Add test to exercise server-side client hello processing In-Reply-To: <38fbcd4c-617b-01e5-1d96-defe43dc2153@oracle.com> References: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> <38fbcd4c-617b-01e5-1d96-defe43dc2153@oracle.com> Message-ID: <2f03171a-9d4d-3717-08fa-640a38dce9bd@oracle.com> I had the same initial thought, but he is actually outputting the exception where it occurs, and only failing at the end. So 4 failures will have 4 exceptions output. Brad On 9/21/2018 3:55 PM, Xuelei Fan wrote: > Once there is a test case failed, it may be not straightforward to > identify which one is failed.? Especially, currently, the testing blog > may be swallowed if it is too long.?? Would you please consider one case > per test?? Or break immediately if a test case failed, instead of > waiting for all to complete? > > Thanks, > Xuelei > > On 9/21/2018 2:35 PM, Jamil Nimeh wrote: >> Hello all, >> >> This adds a test that lets us send different kinds of client hellos to >> a JSSE server. It can be extended to handle different kinds of corner >> cases for client hello extension sets as well as fuzzing test cases in >> the future.? It also provides some extra test coverage for JDK-8210334 >> and JDK-8209916. >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.01/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210918 >> >> Thanks and have a good weekend, >> --Jamil From jamil.j.nimeh at oracle.com Fri Sep 21 23:30:07 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 21 Sep 2018 16:30:07 -0700 Subject: RFR: JDK-8210918, Add test to exercise server-side client hello processing In-Reply-To: <16436985-02cc-8894-6a4d-ea472e7704f9@oracle.com> References: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> <16436985-02cc-8894-6a4d-ea472e7704f9@oracle.com> Message-ID: Hi Brad, thanks for the review.? Comments in-line. On 9/21/2018 4:20 PM, Bradford Wetmore wrote: > Take my "personal preference" comments with a grain of salt. > > This test may be part of a test template, so if some of my comments > (e.g. 340/412) are because of your test modification, you can ignore > them. > > > CliHelloProcessing.java > ----------------------- > My personal preference is to have the names written out for testing, > unless there is a real reason to not. > ClientHelloExtensionProcessing.java?? You can immediately tell what > the test is doing by the name. > > 74:? Would you please include a printout of what's actually being sent > here?? That would help people parse it instead of having to run it and > then print out the debug information.? This might also come in handy? > to help folks understand what you tested against when other problems > with other extensions come up. Yes, I think I could do that for each one. > > 74:? You might mention that this might happen when clients that don't > support PSK are used. Good idea.? I will add that. > > 248:? You might mention that we know about names, but didn't support > it (IIRC), and would fail if we tried to use it. OK > > 283:? Would it be better just to create a single static SSLContext, > and then create SSLEngines from that, rather that creating a bunch of > SSLContexts?? Same with the packet bufs. I actually wanted to be able to control the kind of SSLContext so we could have engines created in future cases where a client might send a 1.3 hello and we want to process it with engines that would only do 1.0, 1.1 or 1.2.? Since I'm going to run one test per execution, it matters less now where it gets made since only one context and one buffer is being made. > > 336:? Personal preference again:? it could be just an Exception, > rather than RTE, since this is not a programming error. I think this will end up being OBE since we're running one test per.? But in cases where a failure should occur but does not I'll throw Exception if you prefer that. > > > 340:?? Why are passing proto, then not using it? I was trying to think ahead for those cases where we want to force the server to be 1.2 only. > > 347:? If you're going to be running with debug on, maybe include the > packet dump as well, rather than a separate println here? Oh, you mean inline with the debug stuff?? That was just because I find it easier to read our parsing without the hexdumps interlaced with the debug logging, but I still want to see the bytes I sent...so I let our debug parsing happen on stderr and have the packet dump go to stdout. > > > 412:? You're passing back hsStatus, but not using it.? Suggest void. OK, I can do that. > > Hope this helps. > > Brad > > > > > On 9/21/2018 2:35 PM, Jamil Nimeh wrote: >> Hello all, >> >> This adds a test that lets us send different kinds of client hellos >> to a JSSE server. It can be extended to handle different kinds of >> corner cases for client hello extension sets as well as fuzzing test >> cases in the future.? It also provides some extra test coverage for >> JDK-8210334 and JDK-8209916. >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.01/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210918 >> >> Thanks and have a good weekend, >> --Jamil From jamil.j.nimeh at oracle.com Fri Sep 21 23:45:28 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 21 Sep 2018 16:45:28 -0700 Subject: RFR: JDK-8210918, Add test to exercise server-side client hello processing In-Reply-To: References: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> <38fbcd4c-617b-01e5-1d96-defe43dc2153@oracle.com> <6ad5efaa-152c-6499-6f57-dbef613ac906@oracle.com> Message-ID: Hi Xuelei, I started getting into making the one test per run approach - having these controlled from command line args in the run line gets a little weird after a while.? We have different hello messages that are byte arrays, so you have to map them to strings (easy), but then some test cases (in the future, not now) might need SSLContexts created with different alg names, might throw different exceptions, we may want to take slightly different actions based on how the processClientHello reacts to a given message, etc.? Those things are easier to write into the body of the test. Would you be OK with an approach where the output on stdout clearly indicates a PASS/FAIL for each test it performs?? Then if it fails one only needs to look at stdout to see which test went haywire and go from there. --Jamil On 9/21/2018 4:15 PM, Xuelei Fan wrote: > On 9/21/2018 4:00 PM, Jamil Nimeh wrote: >> Are you suggesting having multiple run lines or something like that?? >> I think we could do that. > I would prefer to to the run lines. > >> I would like to have it run all cases rather than short-circuit on >> the first failure, as each case doesn't depend on the others. > It should be fine to break earlier as normally the test should be passed. > >> Let me play around with the run directives and see if we can make it >> work more along the lines you want. >> > Thanks! > > Xuelei > >> --Jamil >> >> >> On 09/21/2018 03:55 PM, Xuelei Fan wrote: >>> Once there is a test case failed, it may be not straightforward to >>> identify which one is failed. Especially, currently, the testing >>> blog may be swallowed if it is too long.?? Would you please consider >>> one case per test? Or break immediately if a test case failed, >>> instead of waiting for all to complete? >>> >>> Thanks, >>> Xuelei >>> >>> On 9/21/2018 2:35 PM, Jamil Nimeh wrote: >>>> Hello all, >>>> >>>> This adds a test that lets us send different kinds of client hellos >>>> to a JSSE server. It can be extended to handle different kinds of >>>> corner cases for client hello extension sets as well as fuzzing >>>> test cases in the future.? It also provides some extra test >>>> coverage for JDK-8210334 and JDK-8209916. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.01/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210918 >>>> >>>> Thanks and have a good weekend, >>>> --Jamil >> From Xuelei.Fan at Oracle.Com Sat Sep 22 00:18:02 2018 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Fri, 21 Sep 2018 17:18:02 -0700 Subject: RFR: JDK-8210918, Add test to exercise server-side client hello processing In-Reply-To: References: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> <38fbcd4c-617b-01e5-1d96-defe43dc2153@oracle.com> <6ad5efaa-152c-6499-6f57-dbef613ac906@oracle.com> Message-ID: > On Sep 21, 2018, at 4:45 PM, Jamil Nimeh wrote: > > Hi Xuelei, > > I started getting into making the one test per run approach - having these controlled from command line args in the run line gets a little weird after a while. We have different hello messages that are byte arrays, so you have to map them to strings (easy), but then some test cases (in the future, not now) might need SSLContexts created with different alg names, might throw different exceptions, we may want to take slightly different actions based on how the processClientHello reacts to a given message, etc. Those things are easier to write into the body of the test. > > Would you be OK with an approach where the output on stdout clearly indicates a PASS/FAIL for each test it performs? Then if it fails one only needs to look at stdout to see which test went haywire and go from there. > It would help simplify the failure evaluation. But there is still a problem that when we run a lot test, the debug log may be swallowed, for example over 5000 lines. The result is that the failure output may not appear in the debug log. However, it is a very minor issue. We can consider make the improvement later when we have more cycles. I?m fine with the current code. Thanks, Xuelei > --Jamil > >> On 9/21/2018 4:15 PM, Xuelei Fan wrote: >>> On 9/21/2018 4:00 PM, Jamil Nimeh wrote: >>> Are you suggesting having multiple run lines or something like that? I think we could do that. >> I would prefer to to the run lines. >> >>> I would like to have it run all cases rather than short-circuit on the first failure, as each case doesn't depend on the others. >> It should be fine to break earlier as normally the test should be passed. >> >>> Let me play around with the run directives and see if we can make it work more along the lines you want. >>> >> Thanks! >> >> Xuelei >> >>> --Jamil >>> >>> >>>> On 09/21/2018 03:55 PM, Xuelei Fan wrote: >>>> Once there is a test case failed, it may be not straightforward to identify which one is failed. Especially, currently, the testing blog may be swallowed if it is too long. Would you please consider one case per test? Or break immediately if a test case failed, instead of waiting for all to complete? >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> On 9/21/2018 2:35 PM, Jamil Nimeh wrote: >>>>> Hello all, >>>>> >>>>> This adds a test that lets us send different kinds of client hellos to a JSSE server. It can be extended to handle different kinds of corner cases for client hello extension sets as well as fuzzing test cases in the future. It also provides some extra test coverage for JDK-8210334 and JDK-8209916. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.01/ >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210918 >>>>> >>>>> Thanks and have a good weekend, >>>>> --Jamil >>> > From jamil.j.nimeh at oracle.com Sat Sep 22 00:23:21 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 21 Sep 2018 17:23:21 -0700 Subject: RFR: JDK-8210918, Add test to exercise server-side client hello processing In-Reply-To: References: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> <38fbcd4c-617b-01e5-1d96-defe43dc2153@oracle.com> <6ad5efaa-152c-6499-6f57-dbef613ac906@oracle.com> Message-ID: <54b3d371-25ab-8502-530e-f15b88872de9@oracle.com> Thanks Xuelei. You make a good point about the debug logs losing information when they get large.? We have a lot of tests, more than a couple I wrote, where we do multiple tests in a single execution.? In most cases it works pretty nicely, but admittedly when the logs get really long then I have to isolate specific tests that are the ones that fail.? Maybe we should revisit those test cases in the future and see if we can do something better. --Jamil On 09/21/2018 05:18 PM, Xuelei Fan wrote: > >> On Sep 21, 2018, at 4:45 PM, Jamil Nimeh wrote: >> >> Hi Xuelei, >> >> I started getting into making the one test per run approach - having these controlled from command line args in the run line gets a little weird after a while. We have different hello messages that are byte arrays, so you have to map them to strings (easy), but then some test cases (in the future, not now) might need SSLContexts created with different alg names, might throw different exceptions, we may want to take slightly different actions based on how the processClientHello reacts to a given message, etc. Those things are easier to write into the body of the test. >> >> Would you be OK with an approach where the output on stdout clearly indicates a PASS/FAIL for each test it performs? Then if it fails one only needs to look at stdout to see which test went haywire and go from there. >> > It would help simplify the failure evaluation. > > But there is still a problem that when we run a lot test, the debug log may be swallowed, for example over 5000 lines. The result is that the failure output may not appear in the debug log. > > However, it is a very minor issue. We can consider make the improvement later when we have more cycles. > > I?m fine with the current code. > > Thanks, > Xuelei > > >> --Jamil >> >>> On 9/21/2018 4:15 PM, Xuelei Fan wrote: >>>> On 9/21/2018 4:00 PM, Jamil Nimeh wrote: >>>> Are you suggesting having multiple run lines or something like that? I think we could do that. >>> I would prefer to to the run lines. >>> >>>> I would like to have it run all cases rather than short-circuit on the first failure, as each case doesn't depend on the others. >>> It should be fine to break earlier as normally the test should be passed. >>> >>>> Let me play around with the run directives and see if we can make it work more along the lines you want. >>>> >>> Thanks! >>> >>> Xuelei >>> >>>> --Jamil >>>> >>>> >>>>> On 09/21/2018 03:55 PM, Xuelei Fan wrote: >>>>> Once there is a test case failed, it may be not straightforward to identify which one is failed. Especially, currently, the testing blog may be swallowed if it is too long. Would you please consider one case per test? Or break immediately if a test case failed, instead of waiting for all to complete? >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>>> On 9/21/2018 2:35 PM, Jamil Nimeh wrote: >>>>>> Hello all, >>>>>> >>>>>> This adds a test that lets us send different kinds of client hellos to a JSSE server. It can be extended to handle different kinds of corner cases for client hello extension sets as well as fuzzing test cases in the future. It also provides some extra test coverage for JDK-8210334 and JDK-8209916. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.01/ >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210918 >>>>>> >>>>>> Thanks and have a good weekend, >>>>>> --Jamil From bradford.wetmore at oracle.com Sat Sep 22 00:37:44 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 21 Sep 2018 17:37:44 -0700 Subject: RFR: JDK-8210918, Add test to exercise server-side client hello processing In-Reply-To: <54b3d371-25ab-8502-530e-f15b88872de9@oracle.com> References: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> <38fbcd4c-617b-01e5-1d96-defe43dc2153@oracle.com> <6ad5efaa-152c-6499-6f57-dbef613ac906@oracle.com> <54b3d371-25ab-8502-530e-f15b88872de9@oracle.com> Message-ID: IIRC/AIUI, jtreg only outputs standard output test run information when tests fail. This brings down the amount of test info a lot. To find the failing case, you just have to grep for: ^TEST RESULT:.*FAIL Brad On 9/21/2018 5:23 PM, Jamil Nimeh wrote: > Thanks Xuelei. > > You make a good point about the debug logs losing information when they > get large.? We have a lot of tests, more than a couple I wrote, where we > do multiple tests in a single execution.? In most cases it works pretty > nicely, but admittedly when the logs get really long then I have to > isolate specific tests that are the ones that fail.? Maybe we should > revisit those test cases in the future and see if we can do something > better. > > --Jamil > > > On 09/21/2018 05:18 PM, Xuelei Fan wrote: >> >>> On Sep 21, 2018, at 4:45 PM, Jamil Nimeh >>> wrote: >>> >>> Hi Xuelei, >>> >>> I started getting into making the one test per run approach - having >>> these controlled from command line args in the run line gets a little >>> weird after a while.? We have different hello messages that are byte >>> arrays, so you have to map them to strings (easy), but then some test >>> cases (in the future, not now) might need SSLContexts created with >>> different alg names, might throw different exceptions, we may want to >>> take slightly different actions based on how the processClientHello >>> reacts to a given message, etc.? Those things are easier to write >>> into the body of the test. >>> >>> Would you be OK with an approach where the output on stdout clearly >>> indicates a PASS/FAIL for each test it performs?? Then if it fails >>> one only needs to look at stdout to see which test went haywire and >>> go from there. >>> >> It would help simplify the failure evaluation. >> >> But there is still a problem that when we run a lot test, the debug >> log may be swallowed, for example over 5000 lines.? The result is that >> the failure output may not appear in the debug log. >> >> However, it is a very minor issue.? We can consider make the >> improvement later when we have more cycles. >> >> I?m fine with the current code. >> >> Thanks, >> Xuelei >> >> >>> --Jamil >>> >>>> On 9/21/2018 4:15 PM, Xuelei Fan wrote: >>>>> On 9/21/2018 4:00 PM, Jamil Nimeh wrote: >>>>> Are you suggesting having multiple run lines or something like >>>>> that?? I think we could do that. >>>> I would prefer to to the run lines. >>>> >>>>> I would like to have it run all cases rather than short-circuit on >>>>> the first failure, as each case doesn't depend on the others. >>>> It should be fine to break earlier as normally the test should be >>>> passed. >>>> >>>>> Let me play around with the run directives and see if we can make >>>>> it work more along the lines you want. >>>>> >>>> Thanks! >>>> >>>> Xuelei >>>> >>>>> --Jamil >>>>> >>>>> >>>>>> On 09/21/2018 03:55 PM, Xuelei Fan wrote: >>>>>> Once there is a test case failed, it may be not straightforward to >>>>>> identify which one is failed. Especially, currently, the testing >>>>>> blog may be swallowed if it is too long.?? Would you please >>>>>> consider one case per test? Or break immediately if a test case >>>>>> failed, instead of waiting for all to complete? >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>>> On 9/21/2018 2:35 PM, Jamil Nimeh wrote: >>>>>>> Hello all, >>>>>>> >>>>>>> This adds a test that lets us send different kinds of client >>>>>>> hellos to a JSSE server. It can be extended to handle different >>>>>>> kinds of corner cases for client hello extension sets as well as >>>>>>> fuzzing test cases in the future.? It also provides some extra >>>>>>> test coverage for JDK-8210334 and JDK-8209916. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.01/ >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210918 >>>>>>> >>>>>>> Thanks and have a good weekend, >>>>>>> --Jamil > From jamil.j.nimeh at oracle.com Sat Sep 22 18:33:36 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sat, 22 Sep 2018 11:33:36 -0700 Subject: RFR: JDK-8210918, Add test to exercise server-side client hello processing In-Reply-To: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> References: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> Message-ID: Hi Brad, Xuelei, et al., Thanks for all your comments.? I've udpated the test with Brad's findings and made it use separate @run lines for each test as Xuelei requested. Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.02 --Jamil On 09/21/2018 02:35 PM, Jamil Nimeh wrote: > Hello all, > > This adds a test that lets us send different kinds of client hellos to > a JSSE server. It can be extended to handle different kinds of corner > cases for client hello extension sets as well as fuzzing test cases in > the future.? It also provides some extra test coverage for JDK-8210334 > and JDK-8209916. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.01/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8210918 > > Thanks and have a good weekend, > --Jamil From xuelei.fan at oracle.com Sat Sep 22 20:55:11 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 22 Sep 2018 13:55:11 -0700 Subject: RFR: JDK-8210918, Add test to exercise server-side client hello processing In-Reply-To: References: <1afa582a-d309-3167-92d5-a9e25dd607d0@oracle.com> Message-ID: I like the updated test code. Thanks! Xuelei On 9/22/2018 11:33 AM, Jamil Nimeh wrote: > Hi Brad, Xuelei, et al., > > Thanks for all your comments.? I've udpated the test with Brad's > findings and made it use separate @run lines for each test as Xuelei > requested. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.02 > > --Jamil > > On 09/21/2018 02:35 PM, Jamil Nimeh wrote: >> Hello all, >> >> This adds a test that lets us send different kinds of client hellos to >> a JSSE server. It can be extended to handle different kinds of corner >> cases for client hello extension sets as well as fuzzing test cases in >> the future.? It also provides some extra test coverage for JDK-8210334 >> and JDK-8209916. >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.01/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210918 >> >> Thanks and have a good weekend, >> --Jamil > From norman.maurer at googlemail.com Sat Sep 22 22:40:38 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Sat, 22 Sep 2018 15:40:38 -0700 Subject: NPE during SSL handshake caused by HostnameChecker Message-ID: <78A6846B-5B4C-4EA6-881F-4242F71A53C2@googlemail.com> Hi all, I think I found another bug in the the SSL implementation (well really in the TrustManager related part) which leads to a NPE. I was able to reproduce this on Java8 and Java11 (ea28) but I am sure it also exists on 9 and 10. While trying to write some test code for netty I did something stupid while creating the SSLEngine by passing a hostname as parameter for the server which then ended up in an NPE during handshake. I would argue we should not fail with a NPE. Basically something like: SSLEngine serverEngine = serverCtx.createSSLEngine("localhost", -1); I think this is caused by sun.security.ssl.X509TrustManagerImpl.checkIdentity(?) missing a null check for the hostname before calling sun.security.util.HostnameChecker.match(?) A full reproduce (which I extracted from my netty testcase) can be found here (there is a README.md which explains how to run it): https://github.com/normanmaurer/jdk_ssl_npe_reproducer The stack I see is: Exception in thread "main" java.lang.RuntimeException: Delegated task threw Exception/Error at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1527) at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214) at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186) at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469) at JDKSslReproducer.handshake(JDKSslReproducer.java:76) at JDKSslReproducer.main(JDKSslReproducer.java:51) Caused by: java.lang.NullPointerException at sun.net.util.IPAddressUtil.textToNumericFormatV4(IPAddressUtil.java:49) at sun.net.util.IPAddressUtil.isIPv4LiteralAddress(IPAddressUtil.java:241) at sun.security.util.HostnameChecker.isIpAddress(HostnameChecker.java:125) at sun.security.util.HostnameChecker.match(HostnameChecker.java:93) at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455) at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1068) at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1007) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) at sun.security.ssl.Handshaker$1.run(Handshaker.java:992) at sun.security.ssl.Handshaker$1.run(Handshaker.java:989) at java.security.AccessController.doPrivileged(Native Method) at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) at JDKSslReproducer.runDelegatedTasks(JDKSslReproducer.java:131) at JDKSslReproducer.handshake(JDKSslReproducer.java:99) ... 1 more This only happens if a X509Trustmanager is used (not the Extended version) and when setEndpointIdentificationAlgorithm(?) is used on the client-side. Please let me know if you agree this is a bug and I am happy to open a bug for it. Thanks Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sun Sep 23 13:42:37 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 23 Sep 2018 21:42:37 +0800 Subject: RFR 8076190: Support passwordless access to PKCS12 keystores In-Reply-To: References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> Message-ID: <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> > On Sep 22, 2018, at 2:49 AM, Sean Mullan wrote: > > Still reviewing but here are some initial comments. > > It seems this is more than a fix for JDK-8076190. It also adds configuration properties for the PKCS12 algorithms. I think you should expand the scope/description of the issue to include that. The title of the bug is already "Customizing the generation of a PKCS12 keystore", I'll update the description. > > * HmacPKCS12PBECore.java > > The class description should be updated to PKCS #12 v1.1 and list the new algorithms that you added. OK. > > * java.security > > Change "PKCS 12" to "PKCS12" to match the standard name. OK. > > These properties are also for existing keystores so I would change the first sentence to mention that, ex: > > "... during the creation of a new keystore or modification of an existing keystore." Those (esp certProtectionAlgorithm and macAlgorithm) are only used when generating a keystore. When an existing keystore is modified the properties are not used. I made this choice so that after we create the initial cacerts as password-less (with system properties on the command line), the user can add new cert into the file without any special system property setting and keep it password-less. I've tried my best to describe this in the java.security. > > The default alg values seem somewhat weak. Can we upgrade them or is there a compatibility issue/risk? It will be addressed in a different RFE and is not related to migrating cacerts to password-less. I haven't studied it yet. Need to investigate how current releases of various tools (openssl, browsers...) support it. Thanks Max > > --Sean > > On 8/9/18 5:55 AM, Weijun Wang wrote: >> Webrev updated at >> http://cr.openjdk.java.net/~weijun/8076190/webrev.02 >> The only change is in keytool/Main and the test. keytool will not prompt for store password if it detects a password-less keystore. >> This is 3) below. >> Thanks >> Max >>> On Jul 24, 2018, at 6:49 PM, Weijun Wang wrote: >>> >>> Please review the code change and CSR at >>> >>> webrev: http://cr.openjdk.java.net/~weijun/8076190/webrev.01/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8202590 >>> >>> The bug is at >>> >>> https://bugs.openjdk.java.net/browse/JDK-8076190 >>> >>> This is the 1st part of the process to make cacerts using pkcs12: >>> >>> 1. Support passwordless access to PKCS12 keystores >>> 2. Update default algorithms and params when creating a PKCS12 keystore >>> 3. Update keytool to support passwordless pkcs12 keystores >>> 4. Migrate cacerts to pkcs12 >>> >>> Thanks >>> Max >>> From sean.mullan at oracle.com Mon Sep 24 15:15:38 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 24 Sep 2018 11:15:38 -0400 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> Message-ID: On 9/23/18 9:42 AM, Weijun Wang wrote: >> On Sep 22, 2018, at 2:49 AM, Sean Mullan wrote: >> >> Still reviewing but here are some initial comments. >> >> It seems this is more than a fix for JDK-8076190. It also adds configuration properties for the PKCS12 algorithms. I think you should expand the scope/description of the issue to include that. > The title of the bug is already "Customizing the generation of a PKCS12 keystore", I'll update the description. I also changed the Subject of the email to the new name. >> These properties are also for existing keystores so I would change the first sentence to mention that, ex: >> >> "... during the creation of a new keystore or modification of an existing keystore." > Those (esp certProtectionAlgorithm and macAlgorithm) are only used when generating a keystore. When an existing keystore is modified the properties are not used. I made this choice so that after we create the initial cacerts as password-less (with system properties on the command line), the user can add new cert into the file without any special system property setting and keep it password-less. > > I've tried my best to describe this in the java.security. Right, I understand their usage and the properties are well documented. My comment is that if you just read the first sentence which is typically a summary sentence, it gives no indication that some of these properties may also be used when modifying a keystore. You have to read further to figure that out, and that might be missed. Perhaps if you added a second sentence to the first paragraph: "Several of the properties may also be used when modifying an existing keystore." Then the next paragraph starts ... >> The default alg values seem somewhat weak. Can we upgrade them or is there a compatibility issue/risk? > It will be addressed in a different RFE and is not related to migrating cacerts to password-less. > > I haven't studied it yet. Need to investigate how current releases of various tools (openssl, browsers...) support it. Ok. Still need to review PKCS12KeyStore, but here are some more comments: * java.security You should probably say that these properties are specific to the JDK PKCS12 KeyStore implementation and may not be supported by other PKCS12 implementations. What happens if the properties are not set or are set to the empty String? Are the algorithm names case-insensitive? What if illegal values, or unknown algorithms are set for the properties? Are they ignored? Do they throw an Exception? Or do they fallback to hard-coded defaults? This behavior should be specified. * Passwordless Can you add some comments as to why openssl is needed? Aren't there some tests you can still do if it is not there? And maybe add some comments in the class description as to what the test is generally testing as it hard to discern that from just scanning the code. --Sean From xuelei.fan at oracle.com Mon Sep 24 17:19:47 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 24 Sep 2018 10:19:47 -0700 Subject: NPE during SSL handshake caused by HostnameChecker In-Reply-To: <78A6846B-5B4C-4EA6-881F-4242F71A53C2@googlemail.com> References: <78A6846B-5B4C-4EA6-881F-4242F71A53C2@googlemail.com> Message-ID: Hi Norman, It looks like a bug to me. Would you please file a new bug? Thanks, Xuelei On 9/22/2018 3:40 PM, Norman Maurer wrote: > Hi all, > > I think I found another bug in the the SSL implementation (well really > in the TrustManager related part) which leads to a NPE. I was able to > reproduce this on Java8 and Java11 (ea28) but I am sure it also exists > on 9 and 10. > > While trying to write some test code for netty I did something stupid > while creating the SSLEngine by passing a hostname as parameter for the > server which then ended up in an NPE during handshake. I would argue we > should not fail with a NPE. > > Basically something like: > > SSLEngine serverEngine = serverCtx.createSSLEngine("localhost", -1); > > > I think this is caused by > sun.security.ssl.X509TrustManagerImpl.checkIdentity(?)?missing a null > check for the hostname before calling > sun.security.util.HostnameChecker.match(?) > > A full reproduce (which I extracted from my netty testcase) ?can be > found here (there is a README.md which explains how to run it): > > https://github.com/normanmaurer/jdk_ssl_npe_reproducer > > The stack I see is: > > |Exception in thread "main" java.lang.RuntimeException: Delegated task > threw Exception/Error at > sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1527) at > sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) > at > sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214) > at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186) at > javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469) at > JDKSslReproducer.handshake(JDKSslReproducer.java:76) at > JDKSslReproducer.main(JDKSslReproducer.java:51) Caused by: > java.lang.NullPointerException at > sun.net.util.IPAddressUtil.textToNumericFormatV4(IPAddressUtil.java:49) > at > sun.net.util.IPAddressUtil.isIPv4LiteralAddress(IPAddressUtil.java:241) > at > sun.security.util.HostnameChecker.isIpAddress(HostnameChecker.java:125) > at sun.security.util.HostnameChecker.match(HostnameChecker.java:93) at > sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455) > at > sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1068) > at > sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1007) > at > sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601) > at > sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) > at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) at > sun.security.ssl.Handshaker$1.run(Handshaker.java:992) at > sun.security.ssl.Handshaker$1.run(Handshaker.java:989) at > java.security.AccessController.doPrivileged(Native Method) at > sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) at > JDKSslReproducer.runDelegatedTasks(JDKSslReproducer.java:131) at > JDKSslReproducer.handshake(JDKSslReproducer.java:99) ... 1 more| > > > This only happens if a X509Trustmanager is used (not the Extended > version) and when ?setEndpointIdentificationAlgorithm(?) is used on the > client-side. > > Please let me know if you agree this is a bug and I am happy to open a > bug for it. > > > Thanks > Norman > From norman.maurer at googlemail.com Mon Sep 24 18:02:36 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 24 Sep 2018 20:02:36 +0200 Subject: NPE during SSL handshake caused by HostnameChecker In-Reply-To: References: <78A6846B-5B4C-4EA6-881F-4242F71A53C2@googlemail.com> Message-ID: <211ACBDE-CD9A-410C-BCFF-15A7CEEFF0E4@googlemail.com> Done? Received: We will review your report and have assigned it an internal review ID : 9057381 I used Java8 as Java version but mentioned that it also happens on 11. Hope it helps, Norman > On 24. Sep 2018, at 19:19, Xuelei Fan wrote: > > Hi Norman, > > It looks like a bug to me. Would you please file a new bug? > > Thanks, > Xuelei > > On 9/22/2018 3:40 PM, Norman Maurer wrote: >> Hi all, >> I think I found another bug in the the SSL implementation (well really in the TrustManager related part) which leads to a NPE. I was able to reproduce this on Java8 and Java11 (ea28) but I am sure it also exists on 9 and 10. >> While trying to write some test code for netty I did something stupid while creating the SSLEngine by passing a hostname as parameter for the server which then ended up in an NPE during handshake. I would argue we should not fail with a NPE. >> Basically something like: >> SSLEngine serverEngine = serverCtx.createSSLEngine("localhost", -1); >> I think this is caused by sun.security.ssl.X509TrustManagerImpl.checkIdentity(?) missing a null check for the hostname before calling sun.security.util.HostnameChecker.match(?) >> A full reproduce (which I extracted from my netty testcase) can be found here (there is a README.md which explains how to run it): >> https://github.com/normanmaurer/jdk_ssl_npe_reproducer >> The stack I see is: >> |Exception in thread "main" java.lang.RuntimeException: Delegated task threw Exception/Error at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1527) at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1214) at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1186) at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469) at JDKSslReproducer.handshake(JDKSslReproducer.java:76) at JDKSslReproducer.main(JDKSslReproducer.java:51) Caused by: java.lang.NullPointerException at sun.net.util.IPAddressUtil.textToNumericFormatV4(IPAddressUtil.java:49) at sun.net.util.IPAddressUtil.isIPv4LiteralAddress(IPAddressUtil.java:241) at sun.security.util.HostnameChecker.isIpAddress(HostnameChecker.java:125) at sun.security.util.HostnameChecker.match(HostnameChecker.java:93) at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:455) at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1068) at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1007) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1601) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052) at sun.security.ssl.Handshaker$1.run(Handshaker.java:992) at sun.security.ssl.Handshaker$1.run(Handshaker.java:989) at java.security.AccessController.doPrivileged(Native Method) at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1467) at JDKSslReproducer.runDelegatedTasks(JDKSslReproducer.java:131) at JDKSslReproducer.handshake(JDKSslReproducer.java:99) ... 1 more| >> This only happens if a X509Trustmanager is used (not the Extended version) and when setEndpointIdentificationAlgorithm(?) is used on the client-side. >> Please let me know if you agree this is a bug and I am happy to open a bug for it. >> Thanks >> Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini at zeus.net.au Tue Sep 25 02:19:12 2018 From: jini at zeus.net.au (Peter) Date: Tue, 25 Sep 2018 12:19:12 +1000 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <69982972-2fc5-595e-695a-b47527c0d406@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> <5B9FA0E2.7050607@zeus.net.au> <08f168e5-4c96-4946-77bf-5744a57f3921@oracle.com> <5BA1068F.5000606@zeus.net.au> <69982972-2fc5-595e-695a-b47527c0d406@oracle.com> Message-ID: <5BA99B20.4030103@zeus.net.au> Hi Alan, Ok will do. I'm guessing the test case needs to be a jtreg test? I haven't used lambda's in a SecurityManager implementation at this time, but will experiment and see what happens. Perhaps an comment in the documentation around implementation and recursion difficulties would be sufficient? When implementing a SecurityManager, or Policy, the best way to avoid recursion issues, is to ensure that all necessary classes are loaded before the SecurityManager or policy provider are in force, during construction, or static initialization and that the SecurityManager or Policy has AllPermission. Non-blocking concurrency also eliminates recursive blocking issues. In my implementation, the policy provider is effectively immutable (apart from one volatile reference used during refresh calls), mutable state in PermissionCollection instances is thread confined and unshared, Permission instances also have to be called after construction but before publication to ensure effective immutability, permission implies checks are performed concurrently on all ProtectionDomain's in the AccessControlContext and implies checks on AccessControlContext are also free to occur in concurrently. I can donate only the parts of the code that I alone have authored, should the JDK wish to go down this path. I am the sole author of parts that may the be most useful however, as they store the existing policy file structures in memory, allowing PermissionCollection instances to be created on demand without blocking, but they do depend on RFC3986 URI (of which I'm not the sole author, I might be able to track down other authors). Regards, Peter. On 19/09/2018 5:51 AM, Alan Bateman wrote: > On 18/09/2018 15:07, Peter wrote: >> Hi Alan, >> >> I'm a little time poor presently, but will put it on my todo list. >> Admittedly this is one part of the JVM that could have better test >> coverage. Implementing a custom SecurityManager was fraught with >> recursion difficulties, > If you can get time to try to reproduce with a JDK 11 or 12 build then > it would be useful. As things stand there are still issues with using > lambda expressions in the checkPermission method [1] but I believe the > other recursive initialization issues that arise with malformed policy > files or lcating resources for exception messages have been resolved. > > -Alan. > > [1] https://bugs.openjdk.java.net/browse/JDK-8155659 From weijun.wang at oracle.com Tue Sep 25 03:59:45 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 25 Sep 2018 11:59:45 +0800 Subject: RFR 8210395: Add doc to SecurityTools.java In-Reply-To: <22AF6964-E1CD-491A-BC9C-0318965FE171@oracle.com> References: <22AF6964-E1CD-491A-BC9C-0318965FE171@oracle.com> Message-ID: Ping again. > On Sep 5, 2018, at 12:17 PM, Weijun Wang wrote: > > I ran javadoc on test/lib so I can learn the useful helper classes, and find out SecurityTools.java has no javadoc at all. > > Please review this change > > http://cr.openjdk.java.net/~weijun/8210395/webrev.00/ > > Thanks > Max > From Alan.Bateman at oracle.com Tue Sep 25 09:51:23 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Sep 2018 10:51:23 +0100 Subject: recursive initialization issue with custom security manager In-Reply-To: <5BA99B20.4030103@zeus.net.au> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <79a763fa-a2ed-4f7c-cd69-f8619e665505@oracle.com> <5B9FA0E2.7050607@zeus.net.au> <08f168e5-4c96-4946-77bf-5744a57f3921@oracle.com> <5BA1068F.5000606@zeus.net.au> <69982972-2fc5-595e-695a-b47527c0d406@oracle.com> <5BA99B20.4030103@zeus.net.au> Message-ID: <4f9aedf9-e7d2-7a24-2b90-e1de3fdbb625@oracle.com> (I've changed the subject line to distinguish it from the ongoing discussion about introducing an execution mode that does not support the security manager) On 25/09/2018 03:19, Peter wrote: > Hi Alan, > > Ok will do.? I'm guessing the test case needs to be a jtreg test? It doesn't need to be a jtreg test, I think all we need here is a minimal SecurityManager that shows the bug you are running into. As I said, there have been several changes in this area since JDK 8 so a custom SM that shows the issue with JDK 11 or JDK 12 EA builds would be good. I hope it doesn't require bringing along a complete URI parser. -Alan From sha.jiang at oracle.com Tue Sep 25 10:30:24 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 25 Sep 2018 18:30:24 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx Message-ID: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> Hi, JDK-8164639 removed NSS libs from repo, so sun/security/tools/keytool/autotest.sh has to download NSS libs from artifactory on macosx. This patch also refactors this shell test to a Java test. Webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8209546 Best regards, John Jiang From weijun.wang at oracle.com Tue Sep 25 10:49:50 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 25 Sep 2018 18:49:50 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> Message-ID: <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> Webrev updated at http://cr.openjdk.java.net/~weijun/8076190/webrev.03/. Mostly spec changes. The test is enhanced a little to check for macAlg interop. > On Sep 24, 2018, at 11:15 PM, Sean Mullan wrote: > > Right, I understand their usage and the properties are well documented. My comment is that if you just read the first sentence which is typically a summary sentence, it gives no indication that some of these properties may also be used when modifying a keystore. You have to read further to figure that out, and that might be missed. Perhaps if you added a second sentence to the first paragraph: "Several of the properties may also be used when modifying an existing keystore." Then the next paragraph starts ... Good. > >>> The default alg values seem somewhat weak. Can we upgrade them or is there a compatibility issue/risk? >> It will be addressed in a different RFE and is not related to migrating cacerts to password-less. >> I haven't studied it yet. Need to investigate how current releases of various tools (openssl, browsers...) support it. > > Ok. > > Still need to review PKCS12KeyStore, but here are some more comments: > > * java.security > > You should probably say that these properties are specific to the JDK PKCS12 KeyStore implementation and may not be supported by other PKCS12 implementations. > > What happens if the properties are not set or are set to the empty String? When not set, there is a default value. It happens to be the same as what the out-of-box java.security shows. When empty, there will be an error. Say, NumberFormatException, NoSuchAlgorithmException. > Are the algorithm names case-insensitive? Should be case-insensitive. For each one, I've specified it as "algorithm defined in the XYZ section of standard names". Is that enough to show it's case-insensitive? > > What if illegal values, or unknown algorithms are set for the properties? Are they ignored? Do they throw an Exception? Or do they fallback to hard-coded defaults? This behavior should be specified. Throw an exception. I cannot guarantee when it will be thrown so I just say "when it's used". > > * Passwordless > > Can you add some comments as to why openssl is needed? Aren't there some tests you can still do if it is not there? And maybe add some comments in the class description as to what the test is generally testing as it hard to discern that from just scanning the code. Interoperability. I generate pkcs12 keystores from openssl using various settings and make sure keytool can read them, vice versa. Maybe I should move it to the infra test group. Thanks Max > > --Sean From weijun.wang at oracle.com Tue Sep 25 14:30:47 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 25 Sep 2018 22:30:47 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx In-Reply-To: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> References: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> Message-ID: Some questions: 1. Do we still need the OS check on lines 47-49? As long as getLibPath() can return something, does it mean the test should just run? Especially, does the test run on Windows? 2. Is launching a separate process necessary? Can we just call KeyToolTest::main after setting system properties and copying the files. 3. Is it possible to include standard.sh? Thanks Max > On Sep 25, 2018, at 6:30 PM, sha.jiang at oracle.com wrote: > > Hi, > JDK-8164639 removed NSS libs from repo, so sun/security/tools/keytool/autotest.sh has to download NSS libs from artifactory on macosx. > This patch also refactors this shell test to a Java test. > > Webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8209546 > > Best regards, > John Jiang > From adam.petcher at oracle.com Tue Sep 25 14:40:21 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 25 Sep 2018 10:40:21 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> Message-ID: <12a5b48d-9d6e-51a1-1f5b-9cbf32de910d@oracle.com> Thanks, everyone for your feedback on this JEP. I have incorporated this feedback (received on this mailing list and elsewhere) into the draft JEP[1]. Here is a summary of the current JEP and plan: *) A new provider (name TBD) will be developed to hold the new ECC implementation for the three curves. This provider will feature the interoperability-limiting restrictions on its API that were discussed at length on this mailing list. The new provider will be at the end of the list, so it won't be used by default. *) The operations of the new implementation will also be added to SunEC for the three curves. This means that the new implementation will be used by default, in a completely compatible way (without any restrictions on its API). Using the new implementation through SunEC will not provide the same level of security against side-channel attacks as using it through the new provider. *) We will add some tests that make sure that TLS still work when the new provider is used instead of SunEC. We may need to make some small changes to the TLS implementation in order to get these tests to pass. *) A couple of people asked me about whether we could modernize the implementation of more curves in the future. I added a section at the end of the JEP to discuss this. Of course, none of this is set in stone, and we still have some API details to work out in the CSR. I'll be doing the CSR next, and I'm happy to accept feedback at any time. [1] https://bugs.openjdk.java.net/browse/JDK-8204574 On 8/23/2018 1:50 PM, Adam Petcher wrote: > I'm starting work on yet another ECC JEP[1], this time with the goal > of developing improved implementations of existing algorithms, rather > than implementing new ones. The JEP will re-implement ECDH and ECDSA > for the 256-, 384-, and 521-bit NIST prime curves. The new > implementation will be all Java, and will resist side-channel attacks > by not branching on secrets. It will go in a new provider which is not > in the provider list in the java.security file by default. So it will > need to be manually enabled by changing the configuration or putting > the new provider name in the code. It will only support a subset of > the API that is supported by the implementation in SunEC. In > particular, it will reject any private keys with scalar values > specified using BigInteger (as in ECPrivateKeySpec), and its private > keys will not return scalar values as BigInteger (as in > ECPrivateKey.getS()). > > Please take a look and send me any feedback you have. I'm especially > looking for suggestions on how this new implementation should fit into > the API. I would prefer to have it enabled by default, but I can't > think of a way to do that without either branching on secrets in some > cases (converting a BigInteger private key to an array) or breaking > compatibility (throwing an exception when it gets a BigInteger private > key). > > [1] https://bugs.openjdk.java.net/browse/JDK-8204574 > From xuelei.fan at oracle.com Tue Sep 25 15:15:32 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 25 Sep 2018 08:15:32 -0700 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <12a5b48d-9d6e-51a1-1f5b-9cbf32de910d@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <12a5b48d-9d6e-51a1-1f5b-9cbf32de910d@oracle.com> Message-ID: I did not follow the discussion. But it does not sound right to me to have an application to be provider dependent (#3). I was not confident that a new provider instead of updating the existing provider is a good idea. It might be a significant effort to update existing provider. However, if we don't do that, the cost to use the new provider is not minimal. As we discussed previous, lacking interop could face significant issues and result in complicated coding in practice. Thinking about SunPKCS11 and SunMSCAPI provider, and how many trouble we have had for them, and how many workaround we have patched for them. Unless it is not possible to have an interop-able implementation, I would suggest take more time to have an interop-able design and impl. Is it possible to have an interop-able impl? If it is possible, how much effort will it take? Thanks, Xuelei On 9/25/2018 7:40 AM, Adam Petcher wrote: > Thanks, everyone for your feedback on this JEP. I have incorporated this > feedback (received on this mailing list and elsewhere) into the draft > JEP[1]. Here is a summary of the current JEP and plan: > > *) A new provider (name TBD) will be developed to hold the new ECC > implementation for the three curves. This provider will feature the > interoperability-limiting restrictions on its API that were discussed at > length on this mailing list. The new provider will be at the end of the > list, so it won't be used by default. > *) The operations of the new implementation will also be added to SunEC > for the three curves. This means that the new implementation will be > used by default, in a completely compatible way (without any > restrictions on its API). Using the new implementation through SunEC > will not provide the same level of security against side-channel attacks > as using it through the new provider. > *) We will add some tests that make sure that TLS still work when the > new provider is used instead of SunEC. We may need to make some small > changes to the TLS implementation in order to get these tests to pass. > *) A couple of people asked me about whether we could modernize the > implementation of more curves in the future. I added a section at the > end of the JEP to discuss this. > > Of course, none of this is set in stone, and we still have some API > details to work out in the CSR. I'll be doing the CSR next, and I'm > happy to accept feedback at any time. > > [1] https://bugs.openjdk.java.net/browse/JDK-8204574 > > > On 8/23/2018 1:50 PM, Adam Petcher wrote: >> I'm starting work on yet another ECC JEP[1], this time with the goal >> of developing improved implementations of existing algorithms, rather >> than implementing new ones. The JEP will re-implement ECDH and ECDSA >> for the 256-, 384-, and 521-bit NIST prime curves. The new >> implementation will be all Java, and will resist side-channel attacks >> by not branching on secrets. It will go in a new provider which is not >> in the provider list in the java.security file by default. So it will >> need to be manually enabled by changing the configuration or putting >> the new provider name in the code. It will only support a subset of >> the API that is supported by the implementation in SunEC. In >> particular, it will reject any private keys with scalar values >> specified using BigInteger (as in ECPrivateKeySpec), and its private >> keys will not return scalar values as BigInteger (as in >> ECPrivateKey.getS()). >> >> Please take a look and send me any feedback you have. I'm especially >> looking for suggestions on how this new implementation should fit into >> the API. I would prefer to have it enabled by default, but I can't >> think of a way to do that without either branching on secrets in some >> cases (converting a BigInteger private key to an array) or breaking >> compatibility (throwing an exception when it gets a BigInteger private >> key). >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8204574 >> > From sha.jiang at oracle.com Tue Sep 25 15:30:29 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 25 Sep 2018 23:30:29 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx In-Reply-To: References: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> Message-ID: <32499310-1bcb-35dc-9792-aa20d4a6b0f0@oracle.com> Hi Max, On 2018/9/25 22:30, Weijun Wang wrote: > Some questions: > > 1. Do we still need the OS check on lines 47-49? As long as getLibPath() can return something, does it mean the test should just run? Especially, does the test run on Windows? The original test ignores Windows, and says "This test is only executed on several platforms". So, I didn't change this test logic. But I'll have a try without that OS checking. > > 2. Is launching a separate process necessary? Can we just call KeyToolTest::main after setting system properties and copying the files. I did think about this point. It looks this test could be run by manual if someone want to set those system properties. I supposed that's why KeyToolTest.java is not a jtreg test. > > 3. Is it possible to include standard.sh? No problem. This test looks quite similar to autotest.sh. Best regards, John Jiang > > Thanks > Max > >> On Sep 25, 2018, at 6:30 PM, sha.jiang at oracle.com wrote: >> >> Hi, >> JDK-8164639 removed NSS libs from repo, so sun/security/tools/keytool/autotest.sh has to download NSS libs from artifactory on macosx. >> This patch also refactors this shell test to a Java test. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8209546 >> >> Best regards, >> John Jiang >> > From adam.petcher at oracle.com Tue Sep 25 15:34:47 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 25 Sep 2018 11:34:47 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <12a5b48d-9d6e-51a1-1f5b-9cbf32de910d@oracle.com> Message-ID: On 9/25/2018 11:15 AM, Xuelei Fan wrote: > I did not follow the discussion.? But it does not sound right to me to > have an application to be provider dependent (#3). There will be nothing provider-dependent in the TLS implementation. The point of #3 is to say that we should test the TLS implementation to ensure that it will work with either "EC" provider. The only required changes to TLS code will be using PKCS8 private keys instead of BigInteger private keys. > > I was not confident that a new provider instead of updating the > existing provider is a good idea.? It might be a significant effort to > update existing provider.? However, if we don't do that, the cost to > use the new provider is not minimal. > > As we discussed previous, lacking interop could face significant > issues and result in complicated coding in practice.? Thinking about > SunPKCS11 and SunMSCAPI provider, and how many trouble we have had for > them, and how many workaround we have patched for them. > > Unless it is not possible to have an interop-able implementation, I > would suggest take more time to have an interop-able design and impl. > > Is it possible to have an interop-able impl?? If it is possible, how > much effort will it take? Yes, it is possible, at the expense of some assurance related to security against side-channel attacks. This interoperable implementation will be available by default in SunEC. A higher-assurance form of the same implementation will be available in the new provider. The additional effort required to put this implementation in both providers is expected to be relatively small. From xuelei.fan at oracle.com Tue Sep 25 15:57:23 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 25 Sep 2018 08:57:23 -0700 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <12a5b48d-9d6e-51a1-1f5b-9cbf32de910d@oracle.com> Message-ID: On 9/25/2018 8:34 AM, Adam Petcher wrote: > On 9/25/2018 11:15 AM, Xuelei Fan wrote: > >> I did not follow the discussion.? But it does not sound right to me to >> have an application to be provider dependent (#3). > > There will be nothing provider-dependent in the TLS implementation. The > point of #3 is to say that we should test the TLS implementation to > ensure that it will work with either "EC" provider. The only required > changes to TLS code will be using PKCS8 private keys instead of > BigInteger private keys. > I read it as there is no need to change TLS implementation, right? The change from BigInteger private keys to PKCS8 private keys is for test only, right? What if we don't change test code as well? Can an existing application survive if it uses BigInteger private keys (okay, I this is a interop question)? >> >> I was not confident that a new provider instead of updating the >> existing provider is a good idea.? It might be a significant effort to >> update existing provider.? However, if we don't do that, the cost to >> use the new provider is not minimal. >> >> As we discussed previous, lacking interop could face significant >> issues and result in complicated coding in practice.? Thinking about >> SunPKCS11 and SunMSCAPI provider, and how many trouble we have had for >> them, and how many workaround we have patched for them. >> >> Unless it is not possible to have an interop-able implementation, I >> would suggest take more time to have an interop-able design and impl. >> >> Is it possible to have an interop-able impl?? If it is possible, how >> much effort will it take? > > Yes, it is possible, at the expense of some assurance related to > security against side-channel attacks. We may not want to have an impl to expose to side-channel attacks. Okay, let me ask the question in another way. Is it possible to have an interop-able impl without losing the quality of the new formula (side-channel attacks, etc)? How much effort will it take to make it possible (please consider even we have to update the BigInteger APIs as well)? Sorry for so much question, I did not take enough time for the new formula. So I depend on the questions to you so that I can have a better feel of the design. Thanks, Xuelei > This interoperable implementation > will be available by default in SunEC. A higher-assurance form of the > same implementation will be available in the new provider. The > additional effort required to put this implementation in both providers > is expected to be relatively small. From xuelei.fan at oracle.com Tue Sep 25 16:06:44 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 25 Sep 2018 09:06:44 -0700 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <12a5b48d-9d6e-51a1-1f5b-9cbf32de910d@oracle.com> Message-ID: <4a6bf1e1-8e50-4015-414f-9550d0d8b29f@oracle.com> On 9/25/2018 8:34 AM, Adam Petcher wrote: > Yes, it is possible, at the expense of some assurance related to > security against side-channel attacks. This interoperable implementation > will be available by default in SunEC. A higher-assurance form of the > same implementation will be available in the new provider. The > additional effort required to put this implementation in both providers > is expected to be relatively small. Can we have the same security level impl in SunEC in some circumstances? For example, when the key is not imported for the 4 named curves. Using a new provider means we force applications to choose between weak and interop, just because we cannot provide both at the same time. Thanks, Xuelei From mstjohns at comcast.net Tue Sep 25 16:30:40 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 25 Sep 2018 12:30:40 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <4a6bf1e1-8e50-4015-414f-9550d0d8b29f@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <12a5b48d-9d6e-51a1-1f5b-9cbf32de910d@oracle.com> <4a6bf1e1-8e50-4015-414f-9550d0d8b29f@oracle.com> Message-ID: On 9/25/2018 12:06 PM, Xuelei Fan wrote: > > > On 9/25/2018 8:34 AM, Adam Petcher wrote: >> Yes, it is possible, at the expense of some assurance related to >> security against side-channel attacks. This interoperable >> implementation will be available by default in SunEC. A >> higher-assurance form of the same implementation will be available in >> the new provider. The additional effort required to put this >> implementation in both providers is expected to be relatively small. > Can we have the same security level impl in SunEC in some > circumstances? ?For example, when the key is not imported for the 4 > named curves. Using a new provider means we force applications to > choose between weak and interop, just because we cannot provide both > at the same time. > > Thanks, > Xuelei There's a hole in my desk from where I've been pounding my head on this subject. Basically, for the opaque operations - signing, verifying, deriving shared secrets - Adam can meet his branchless goal.? For the non-opaque operations - importing and exporting the private key according to the interface specifications, he can't or thinks he can't.?? And even with the latter - with the use of PKCS12 as the standard key store format - the import of a private key from a key store (e.g. internally stored as PKCS8) should be able to be implemented branchless without too much effort. It's only when moving key material to/from his implementation where there are interoperability requirements that might involve branching (and not even then if he makes his own version of BigInteger to avoid those branches in the new() methods).? Given that once the key leaves his implementation he has no control over whether it's used branchless, it's utterly disingenuous to claim that the process of exporting also must be branchless. So to clarify: all of his opaque code will be "high assurance" - and that's will be what's used about 99.999% of the time. The rest of this is just religious dogma that doesn't consider the actual use cases and costs related to moving keys to/from his implementation. Later, Mike From sha.jiang at oracle.com Tue Sep 25 16:36:00 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 26 Sep 2018 00:36:00 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx In-Reply-To: <32499310-1bcb-35dc-9792-aa20d4a6b0f0@oracle.com> References: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> <32499310-1bcb-35dc-9792-aa20d4a6b0f0@oracle.com> Message-ID: <87fcf6ff-e3e1-f78a-f50e-37da583f8a38@oracle.com> >> >> 2. Is launching a separate process necessary? Can we just call >> KeyToolTest::main after setting system properties and copying the files. > I did think about this point. > It looks this test could be run by manual if someone want to set those > system properties. > I supposed that's why KeyToolTest.java is not a jtreg test. I misunderstood this point. Will apply that. Best regards, John Jiang From sean.mullan at oracle.com Tue Sep 25 18:22:26 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 25 Sep 2018 14:22:26 -0400 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> Message-ID: Update is looking good, just a few more comments ... * java.security 1066 # The following parameters, if configured, are used by the PKCS12 KeyStore 1067 # implementation during the creation of a new keystore. Several of the 1068 # properties may also be used when modifying an existing keystore. If you use the KeyStore API and specify your own algorithms, the API algorithms supersede these properties. Maybe you should say something about that, that these properties can be overridden by the API. Otherwise it may sound like they are always used. 1094 # iteration count not an integer, or an unknown algorithm name, an exception Slight wording suggestion: "an iteration count that is not an integer, ..." 1098 # It is not guaranteed to be examined and used by other implementations. s/It is/They are/ 1100 # The iteration count used by the PBE algorithm encrypting a certificate. Slight wording suggestion: s/encrypting/when encrypting/. Same comment on line 1104. 1104 # The iteration count used by the PBE algorithm encrypting a private key. should this be "private key or secret key"? 1122 keystore.pkcs12.certProtectionAlgorithm = PBEWithSHA1AndRC2_40 Shouldn't this be named certPbeAlgorithm so that it matches certPbeIterationCount? Same comment about keyProtectionAlgorithm. 1124 # The Mac algorithm. This can be any HmacPBE algorithm defined in the Mac I would add a little bit more description as to what this Mac algorithm is used for. Also, I would probably order these differently. I think it makes more sense to have the algorithms listed first, followed by parameters that affect them: keystore.pkcs12.certProtectionAlgorithm keystore.pkcs12.certPbeIterationCount keystore.pkcs12.keyProtectionAlgorithm keystore.pkcs12.keyPbeIterationCount keystore.pkcs12.macAlgorithm keystore.pkcs12.macIterationCount * PKCS12KeyStore.java 145 private static final int PBE_ITERATION_COUNT 146 = getPkcs12Setting("pbeIterationCount", 50000); Shouldn't there be 2 constants above, one for certPbeIterationCount and one for keyPbeIterationCount? 208 String name2 = "keystore.PKCS12." + type; I'm not sure checking the property name with uppercase PKCS12 is necessary. I think we should assume that the property name is case-sensitive, as most properties are. 2108 // What shall we do if there is ENCRYPTED_DATA_OID but 2109 // we do not have a password? This section of comments (thru line 2123) should really be reworded to say what the current implementation does and perhaps allude to why it is not perfect but is probably the best option. Right now it reads too much like a brainstorming session :) --Sean On 9/25/18 6:49 AM, Weijun Wang wrote: > Webrev updated at http://cr.openjdk.java.net/~weijun/8076190/webrev.03/. > > Mostly spec changes. The test is enhanced a little to check for macAlg interop. > >> On Sep 24, 2018, at 11:15 PM, Sean Mullan wrote: >> >> Right, I understand their usage and the properties are well documented. My comment is that if you just read the first sentence which is typically a summary sentence, it gives no indication that some of these properties may also be used when modifying a keystore. You have to read further to figure that out, and that might be missed. Perhaps if you added a second sentence to the first paragraph: "Several of the properties may also be used when modifying an existing keystore." Then the next paragraph starts ... > > Good. > >> >>>> The default alg values seem somewhat weak. Can we upgrade them or is there a compatibility issue/risk? >>> It will be addressed in a different RFE and is not related to migrating cacerts to password-less. >>> I haven't studied it yet. Need to investigate how current releases of various tools (openssl, browsers...) support it. >> >> Ok. >> >> Still need to review PKCS12KeyStore, but here are some more comments: >> >> * java.security >> >> You should probably say that these properties are specific to the JDK PKCS12 KeyStore implementation and may not be supported by other PKCS12 implementations. >> >> What happens if the properties are not set or are set to the empty String? > > When not set, there is a default value. It happens to be the same as what the out-of-box java.security shows. > > When empty, there will be an error. Say, NumberFormatException, NoSuchAlgorithmException. > >> Are the algorithm names case-insensitive? > > Should be case-insensitive. For each one, I've specified it as "algorithm defined in the XYZ section of standard names". Is that enough to show it's case-insensitive? > >> >> What if illegal values, or unknown algorithms are set for the properties? Are they ignored? Do they throw an Exception? Or do they fallback to hard-coded defaults? This behavior should be specified. > > Throw an exception. I cannot guarantee when it will be thrown so I just say "when it's used". > >> >> * Passwordless >> >> Can you add some comments as to why openssl is needed? Aren't there some tests you can still do if it is not there? And maybe add some comments in the class description as to what the test is generally testing as it hard to discern that from just scanning the code. > > Interoperability. I generate pkcs12 keystores from openssl using various settings and make sure keytool can read them, vice versa. Maybe I should move it to the infra test group. > > Thanks > Max > >> >> --Sean > From John.Gray at entrustdatacard.com Tue Sep 25 21:14:43 2018 From: John.Gray at entrustdatacard.com (John Gray) Date: Tue, 25 Sep 2018 21:14:43 +0000 Subject: Security provider self-integrity checking changes in JDK 9.0? Message-ID: Hello, We have a couple questions regarding Jar verification in Java 9 (and later) We produce a Java based toolkit that contains a Security Provider. Because of this, we follow the guidance on the following page: https://docs.oracle.com/javase/9/security/howtoimplaprovider.htm#JSSEC-GUID-C6054169-FE6E-4837-B2BD-382DFEB955C0 However, we have recently noticed a change between JDK 9 and JDK 8 In JDK 8: (https://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/HowToImplAProvider.html) Step 1.1: Additional JCA Provider Requirements and Recommendations for Encryption Implementations When instantiating a provider's implementation (class) of a Cipher, KeyAgreement, KeyGenerator, MAC or SecretKey factory, the framework will determine the provider's codebase (JAR file) and verify its signature. In this way, JCA authenticates the provider and ensures that only providers signed by a trusted entity can be plugged into JCA. Thus, one requirement for encryption providers is that they must be signed, as described in later steps. In addition, each provider should perform self-integrity checking to ensure that the JAR file containing its code has not been manipulated in an attempt to invoke provider methods directly rather than through JCA. For further information, see How a Provider Can Do Self-Integrity Checking. In JDK 9: (https://docs.oracle.com/javase/9/security/howtoimplaprovider.htm ) Step 1.1: Consider Additional JCA Provider Requirements and Recommendations for Encryption Implementations When instantiating a provider's implementation (class) of a Cipher, KeyAgreement, KeyGenerator, MAC, or SecretKey factory, the framework will determine the provider's codebase (JAR file) and verify its signature. In this way, JCA authenticates the provider and ensures that only providers signed by a trusted entity can be plugged into the JCA. Thus, one requirement for encryption providers is that they must be signed, as described in later steps. There is no mention of the self-integrity checking in this section? There doesn't seem to be an explanation as to why it was removed? In Section 8.2, it briefly mentions self-integrity checking: Step 8.2: Set Provider Permissions Permissions must be granted for when applications are run while a security manager is installed. A security manager may be installed for an application either through code in the application itself or through a command-line argument. 1. Your provider may need the following permissions granted to it in the client environment: * java.lang.RuntimePermission to get class protection domains. The provider may need to get its own protection domain in the process of doing self-integrity checking. * java.security.SecurityPermission to set provider properties. So we are just wondering if something has changed in JDK 9 (and later) that makes the self-integrity check by a security provider unnecessary. If it has been changed, could we get information as to what has changed and why it changed? Thanks so much John Gray Entrust Datacard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Tue Sep 25 21:47:50 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 25 Sep 2018 14:47:50 -0700 Subject: Security provider self-integrity checking changes in JDK 9.0? In-Reply-To: References: Message-ID: On 9/25/2018 2:14 PM, John Gray wrote: > Hello, > > We have a couple questions regarding Jar verification in Java 9 (and later) ...deleted... > There is no mention of the self-integrity checking in this section? > There doesn?t seem to be an explanation as to why it was removed? The self-interity requirement check was necessary for very early versions of JCE when crypto regulations were different, but is no longer necessary. IIRC, we left the guidance in because some folks were still targeting those ancient versions along with JDK 6/7. But with the docs cleanup in 9, we removed some of the old obsolete information like that. ---begin--- IMPORTANT NOTE: In the unbundled version of JCE 1.2.x, (used with JDKs 1.2.x and 1.3.x), providers needed to include code to authenticate the JCA framework to assure themselves of the integrity and authenticity of the JCA that they plugged into. In JDK 6 and later, this is no longer necessary. ---end--- Thanks, Brad > In Section 8.2, it briefly mentions self-integrity checking: > > Step 8.2: Set Provider Permissions > > Permissions > > must be granted for when applications are run while a security manager > is installed. A security manager may be installed for an application > either through code in the application itself or through a command-line > argument. > > 1. Your provider may need the following permissions granted to it in > the client environment: > * java.lang.RuntimePermission to get class protection domains. The > provider may need to get its own protection domain in the > process of doing self-integrity checking. > * java.security.SecurityPermission to set provider properties. > > So we are just wondering if something has changed in JDK 9 (and later) > that makes the self-integrity check by a security provider > unnecessary.?? If it has been changed, could we get information as to > what has changed and why it changed? > > Thanks so much > > John Gray > > Entrust Datacard > From adam.petcher at oracle.com Wed Sep 26 13:35:31 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 26 Sep 2018 09:35:31 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <12a5b48d-9d6e-51a1-1f5b-9cbf32de910d@oracle.com> Message-ID: On 9/25/2018 11:57 AM, Xuelei Fan wrote: > On 9/25/2018 8:34 AM, Adam Petcher wrote: >> >> There will be nothing provider-dependent in the TLS implementation. >> The point of #3 is to say that we should test the TLS implementation >> to ensure that it will work with either "EC" provider. The only >> required changes to TLS code will be using PKCS8 private keys instead >> of BigInteger private keys. >> > I read it as there is no need to change TLS implementation, right?? > The change from BigInteger private keys to PKCS8 private keys is for > test only, right?? What if we don't change test code as well?? Can an > existing application survive if it uses BigInteger private keys (okay, > I this is a interop question)? I looked into the TLS code a bit, and the key stores (both PKCS12 and JKS) load the private keys in PKCS8 format and give them to the KeyFactory as a PKCS8EncodedKeySpec. From that point on, the TLS implementation uses the opaque keys. Based on this behavior, I don't expect there will be any need to change the TLS code in order for it to work with the new provider. An existing application cannot use BigInteger private keys if it wants to be branchless. If such an application attempts to use the new branchless provider, then the provider will throw an exception. If branchless behavior in the entire application is desired, then the solution is to change the application code so that private keys go directly from storage into the provider in PKCS8 format, in the same way that our TLS code behaves. If the import/export is allowed to branch, then the developer/configuration can use SunEC, which will allow branching in import/export, but will be branchless for the core EC operations (for three curves only). > We may not want to have an impl to expose to side-channel attacks. > > Okay, let me ask the question in another way.? Is it possible to have > an interop-able impl without losing the quality of the new formula > (side-channel attacks, etc)??? How much effort will it take to make it > possible (please consider even we have to update the BigInteger APIs > as well)? Also, you asked a related question in another email: "Can we have the same security level impl in SunEC in some circumstances?" Yes, the implementation in SunEC will be interoperable and will have the same level of security against side-channel attacks when used in a particular way. Using this implementation in the new provider only ensures that it is used in the particular way that enables this level of security. I've thought more about modifying/subclassing BigInteger, and I don't believe it helps us. It only seems to move the problem around. For example, say getS() returns an internal BigInteger subclass that only supports a subset of the BigInteger operations. When an API client tries to use an operation that is not supported, it will get an exception or incorrect results. So we are back to having compatibility/interoperability issues, just in a different place in the code. Making a BigInteger subclass that implements the entire BigInteger API in constant time is impossible because the size of a BigInteger is unbounded. From weijun.wang at oracle.com Wed Sep 26 15:57:26 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 26 Sep 2018 23:57:26 +0800 Subject: RFR 8210821: Support dns_canonicalize_hostname in krb5.conf In-Reply-To: References: <49DF7170-4E18-431D-A733-10507625BCB9@oracle.com> Message-ID: <8AB1F42A-A2B5-4F87-9EC3-AB2F158DA7D2@oracle.com> Hi Valerie I've updated the CSR to remove the "always canonicalize" choice and now the default is "true", i.e. the current "smart-canonicalization" behavior. It's 12am here and I'll update the webrev tomorrow. Thanks Max > On Sep 18, 2018, at 8:52 AM, Valerie Peng wrote: > > Look fine to me. Added myself to CSR as reviewer. > > Thanks, > > Valerie > > > On 9/17/2018 1:17 AM, Weijun Wang wrote: >> Please review the code change and CSR at >> >> http://cr.openjdk.java.net/~weijun/8210821/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8210822 >> >> Thanks >> Max >> > From sha.jiang at oracle.com Thu Sep 27 01:25:16 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 27 Sep 2018 09:25:16 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx In-Reply-To: References: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> Message-ID: <8fcc29ae-4c17-b1f9-1a50-e45a96af1318@oracle.com> Hi Max, Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.01/ All your comments are addressed, though this test is moved to problem list for windows due to JDK-8204203. Best regards, John Jiang On 2018/9/25 22:30, Weijun Wang wrote: > Some questions: > > 1. Do we still need the OS check on lines 47-49? As long as getLibPath() can return something, does it mean the test should just run? Especially, does the test run on Windows? > > 2. Is launching a separate process necessary? Can we just call KeyToolTest::main after setting system properties and copying the files. > > 3. Is it possible to include standard.sh? > > Thanks > Max > >> On Sep 25, 2018, at 6:30 PM,sha.jiang at oracle.com wrote: >> >> Hi, >> JDK-8164639 removed NSS libs from repo, so sun/security/tools/keytool/autotest.sh has to download NSS libs from artifactory on macosx. >> This patch also refactors this shell test to a Java test. >> >> Webrev:http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/ >> Issue:https://bugs.openjdk.java.net/browse/JDK-8209546 >> >> Best regards, >> John Jiang >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Sep 27 02:09:36 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 27 Sep 2018 10:09:36 +0800 Subject: RFR 8210821: Support dns_canonicalize_hostname in krb5.conf In-Reply-To: <8AB1F42A-A2B5-4F87-9EC3-AB2F158DA7D2@oracle.com> References: <49DF7170-4E18-431D-A733-10507625BCB9@oracle.com> <8AB1F42A-A2B5-4F87-9EC3-AB2F158DA7D2@oracle.com> Message-ID: Webrev updated at https://cr.openjdk.java.net/~weijun/8210821/webrev.01. > On Sep 26, 2018, at 11:57 PM, Weijun Wang wrote: > > Hi Valerie > > I've updated the CSR to remove the "always canonicalize" choice and now the default is "true", i.e. the current "smart-canonicalization" behavior. It's 12am here and I'll update the webrev tomorrow. > > Thanks > Max > >> On Sep 18, 2018, at 8:52 AM, Valerie Peng wrote: >> >> Look fine to me. Added myself to CSR as reviewer. >> >> Thanks, >> >> Valerie >> >> >> On 9/17/2018 1:17 AM, Weijun Wang wrote: >>> Please review the code change and CSR at >>> >>> http://cr.openjdk.java.net/~weijun/8210821/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8210822 >>> >>> Thanks >>> Max >>> >> > From weijun.wang at oracle.com Thu Sep 27 02:34:47 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 27 Sep 2018 10:34:47 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx In-Reply-To: <8fcc29ae-4c17-b1f9-1a50-e45a96af1318@oracle.com> References: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> <8fcc29ae-4c17-b1f9-1a50-e45a96af1318@oracle.com> Message-ID: <0ED6BF6E-FFF7-40C3-8F2D-5DE9ECAF3F88@oracle.com> Hi John 1. Please add @bug to all tests. 2. Are getLibPath() and findLib() in AutoTest.java really necessary? It looks like PKCS11Test::getNSSLibDir is doing something similar. 3. Looks like Standard.java is not necessary now. You can just make KeyToolTest.java a @test and add a @run line there, something like @run main/othervm/timeout=600 -Dfile KeyToolTest 4. Maybe we can rename AutoTest.java to NssTest.java. The old name says nothing. Thanks Max > On Sep 27, 2018, at 9:25 AM, sha.jiang at oracle.com wrote: > > Hi Max, > Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.01/ > All your comments are addressed, though this test is moved to problem list for windows due to JDK-8204203. > > Best regards, > John Jiang > On 2018/9/25 22:30, Weijun Wang wrote: >> Some questions: >> >> 1. Do we still need the OS check on lines 47-49? As long as getLibPath() can return something, does it mean the test should just run? Especially, does the test run on Windows? >> >> 2. Is launching a separate process necessary? Can we just call KeyToolTest::main after setting system properties and copying the files. >> >> 3. Is it possible to include standard.sh? >> >> Thanks >> Max >> >> >>> On Sep 25, 2018, at 6:30 PM, sha.jiang at oracle.com >>> wrote: >>> >>> Hi, >>> JDK-8164639 removed NSS libs from repo, so sun/security/tools/keytool/autotest.sh has to download NSS libs from artifactory on macosx. >>> This patch also refactors this shell test to a Java test. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8209546 >>> >>> >>> Best regards, >>> John Jiang >>> >>> > From sha.jiang at oracle.com Thu Sep 27 03:18:46 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 27 Sep 2018 11:18:46 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx In-Reply-To: <0ED6BF6E-FFF7-40C3-8F2D-5DE9ECAF3F88@oracle.com> References: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> <8fcc29ae-4c17-b1f9-1a50-e45a96af1318@oracle.com> <0ED6BF6E-FFF7-40C3-8F2D-5DE9ECAF3F88@oracle.com> Message-ID: <498226a1-bf16-d353-a0d6-a1bfc09c41ae@oracle.com> On 2018/9/27 10:34, Weijun Wang wrote: > Hi John > > 1. Please add @bug to all tests. Which issue should be linked? JDK-8209546? I suppose @bug should indicate a product issue here. At least, JDK-8209546 looks have no much association with this test. > > 2. Are getLibPath() and findLib() in AutoTest.java really necessary? It looks like PKCS11Test::getNSSLibDir is doing something similar. I'll modify PKCS11Test.java a bit to help this point. > > 3. Looks like Standard.java is not necessary now. You can just make KeyToolTest.java a @test and add a @run line there, something like > > @run main/othervm/timeout=600 -Dfile KeyToolTest Will address. > > 4. Maybe we can rename AutoTest.java to NssTest.java. The old name says nothing. Will address. Best regards, John Jiang > > Thanks > Max > >> On Sep 27, 2018, at 9:25 AM, sha.jiang at oracle.com wrote: >> >> Hi Max, >> Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.01/ >> All your comments are addressed, though this test is moved to problem list for windows due to JDK-8204203. >> >> Best regards, >> John Jiang >> On 2018/9/25 22:30, Weijun Wang wrote: >>> Some questions: >>> >>> 1. Do we still need the OS check on lines 47-49? As long as getLibPath() can return something, does it mean the test should just run? Especially, does the test run on Windows? >>> >>> 2. Is launching a separate process necessary? Can we just call KeyToolTest::main after setting system properties and copying the files. >>> >>> 3. Is it possible to include standard.sh? >>> >>> Thanks >>> Max >>> >>> >>>> On Sep 25, 2018, at 6:30 PM, sha.jiang at oracle.com >>>> wrote: >>>> >>>> Hi, >>>> JDK-8164639 removed NSS libs from repo, so sun/security/tools/keytool/autotest.sh has to download NSS libs from artifactory on macosx. >>>> This patch also refactors this shell test to a Java test. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8209546 >>>> >>>> >>>> Best regards, >>>> John Jiang >>>> >>>> > From weijun.wang at oracle.com Thu Sep 27 03:20:39 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 27 Sep 2018 11:20:39 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx In-Reply-To: <498226a1-bf16-d353-a0d6-a1bfc09c41ae@oracle.com> References: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> <8fcc29ae-4c17-b1f9-1a50-e45a96af1318@oracle.com> <0ED6BF6E-FFF7-40C3-8F2D-5DE9ECAF3F88@oracle.com> <498226a1-bf16-d353-a0d6-a1bfc09c41ae@oracle.com> Message-ID: > On Sep 27, 2018, at 11:18 AM, sha.jiang at oracle.com wrote: > > On 2018/9/27 10:34, Weijun Wang wrote: >> Hi John >> >> 1. Please add @bug to all tests. > Which issue should be linked? JDK-8209546? > I suppose @bug should indicate a product issue here. > At least, JDK-8209546 looks have no much association with this test. I meant JDK-8209546. My understanding is that even if it's a noreg-self change, the bug id should also be included. Thanks Max > >> >> 2. Are getLibPath() and findLib() in AutoTest.java really necessary? It looks like PKCS11Test::getNSSLibDir is doing something similar. > I'll modify PKCS11Test.java a bit to help this point. > >> >> 3. Looks like Standard.java is not necessary now. You can just make KeyToolTest.java a @test and add a @run line there, something like >> >> @run main/othervm/timeout=600 -Dfile KeyToolTest > Will address. > >> >> 4. Maybe we can rename AutoTest.java to NssTest.java. The old name says nothing. > Will address. > > Best regards, > John Jiang >> >> Thanks >> Max >> >>> On Sep 27, 2018, at 9:25 AM, sha.jiang at oracle.com wrote: >>> >>> Hi Max, >>> Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.01/ >>> All your comments are addressed, though this test is moved to problem list for windows due to JDK-8204203. >>> >>> Best regards, >>> John Jiang >>> On 2018/9/25 22:30, Weijun Wang wrote: >>>> Some questions: >>>> >>>> 1. Do we still need the OS check on lines 47-49? As long as getLibPath() can return something, does it mean the test should just run? Especially, does the test run on Windows? >>>> >>>> 2. Is launching a separate process necessary? Can we just call KeyToolTest::main after setting system properties and copying the files. >>>> >>>> 3. Is it possible to include standard.sh? >>>> >>>> Thanks >>>> Max >>>> >>>> >>>>> On Sep 25, 2018, at 6:30 PM, sha.jiang at oracle.com >>>>> wrote: >>>>> >>>>> Hi, >>>>> JDK-8164639 removed NSS libs from repo, so sun/security/tools/keytool/autotest.sh has to download NSS libs from artifactory on macosx. >>>>> This patch also refactors this shell test to a Java test. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8209546 >>>>> >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> >>>>> >> > From sha.jiang at oracle.com Thu Sep 27 03:43:03 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 27 Sep 2018 11:43:03 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx In-Reply-To: References: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> <8fcc29ae-4c17-b1f9-1a50-e45a96af1318@oracle.com> <0ED6BF6E-FFF7-40C3-8F2D-5DE9ECAF3F88@oracle.com> <498226a1-bf16-d353-a0d6-a1bfc09c41ae@oracle.com> Message-ID: On 2018/9/27 11:20, Weijun Wang wrote: >> On Sep 27, 2018, at 11:18 AM, sha.jiang at oracle.com wrote: >> >> On 2018/9/27 10:34, Weijun Wang wrote: >>> Hi John >>> >>> 1. Please add @bug to all tests. >> Which issue should be linked? JDK-8209546? >> I suppose @bug should indicate a product issue here. >> At least, JDK-8209546 looks have no much association with this test. > I meant JDK-8209546. My understanding is that even if it's a noreg-self change, the bug id should also be included. In practice, we may not add a direct associated test bug id to the test itself; otherwise, many tests would contain a lot of bug ids. In fact, we can find the test bug id in the changeset message. In addition, the below statement is copied from jtreg FAQ item 4.28 [1] "If you're updating a test because it was affected by a bug fix, but the test is not otherwise a regression test for the bug fix, then you should probably not update the @bug entry." With my understanding, in my case, this @bug should not be updated. [1] http://openjdk.java.net/jtreg/faq.html#when-should-i-update-the-bug-entry-in-a-test-description Best regards, Best regards, From weijun.wang at oracle.com Thu Sep 27 04:00:25 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 27 Sep 2018 12:00:25 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx In-Reply-To: References: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> <8fcc29ae-4c17-b1f9-1a50-e45a96af1318@oracle.com> <0ED6BF6E-FFF7-40C3-8F2D-5DE9ECAF3F88@oracle.com> <498226a1-bf16-d353-a0d6-a1bfc09c41ae@oracle.com> Message-ID: <8AB537F1-5C47-4943-9C4E-50A705D096F6@oracle.com> But this is not "affected by a bug fix". This is just refactoring. Maybe any is OK, I just feel uncomfortable that there is no @bug at all. --Max > On Sep 27, 2018, at 11:43 AM, sha.jiang at oracle.com wrote: > > On 2018/9/27 11:20, Weijun Wang wrote: >>> On Sep 27, 2018, at 11:18 AM, sha.jiang at oracle.com wrote: >>> >>> On 2018/9/27 10:34, Weijun Wang wrote: >>>> Hi John >>>> >>>> 1. Please add @bug to all tests. >>> Which issue should be linked? JDK-8209546? >>> I suppose @bug should indicate a product issue here. >>> At least, JDK-8209546 looks have no much association with this test. >> I meant JDK-8209546. My understanding is that even if it's a noreg-self change, the bug id should also be included. > In practice, we may not add a direct associated test bug id to the test itself; > otherwise, many tests would contain a lot of bug ids. > In fact, we can find the test bug id in the changeset message. > > In addition, the below statement is copied from jtreg FAQ item 4.28 [1] > "If you're updating a test because it was affected by a bug fix, > but the test is not otherwise a regression test for the bug fix, > then you should probably not update the @bug entry." > > With my understanding, in my case, this @bug should not be updated. > > [1] http://openjdk.java.net/jtreg/faq.html#when-should-i-update-the-bug-entry-in-a-test-description > > Best regards, > Best regards, From weijun.wang at oracle.com Thu Sep 27 05:58:26 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 27 Sep 2018 13:58:26 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> Message-ID: All others accepted. > 1122 keystore.pkcs12.certProtectionAlgorithm = PBEWithSHA1AndRC2_40 > > Shouldn't this be named certPbeAlgorithm so that it matches certPbeIterationCount? Same comment about keyProtectionAlgorithm. Unfortunately we already had "keystore.pkcs12.keyProtectionAlgorithm" and it also accepts "PKCS12". See http://cr.openjdk.java.net/~weijun/8076190/webrev.03/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java-.html: 147 private static final String[] KEY_PROTECTION_ALGORITHM = { 148 "keystore.pkcs12.keyProtectionAlgorithm", 149 "keystore.PKCS12.keyProtectionAlgorithm" 150 }; But you are right the names are not consistent and supporting both "pkcs12" and "PKCS12" is awkward (and cannot make use of the new SecurityProperties::privilegedGetOverridable method). Now I decide to name the new properties as (key|cert)PbeAlgorithm names with only "pkcs12", and only support the old names as a fallback. > * PKCS12KeyStore.java > > 145 private static final int PBE_ITERATION_COUNT > 146 = getPkcs12Setting("pbeIterationCount", 50000); > > Shouldn't there be 2 constants above, one for certPbeIterationCount and one for keyPbeIterationCount? Oops. Will fix. > > 208 String name2 = "keystore.PKCS12." + type; > > I'm not sure checking the property name with uppercase PKCS12 is necessary. I think we should assume that the property name is case-sensitive, as most properties are. See above. > > 2108 // What shall we do if there is ENCRYPTED_DATA_OID but > 2109 // we do not have a password? > > This section of comments (thru line 2123) should really be reworded to say what the current implementation does and perhaps allude to why it is not perfect but is probably the best option. Right now it reads too much like a brainstorming session :) I *am* brainstorming inside my brain. I had long thought about throwing an exception here. With the password-less cacerts, hopefully this will not be a problem for many people and we can just keep the current behavior. Thanks Max > > --Sean > > On 9/25/18 6:49 AM, Weijun Wang wrote: >> Webrev updated at http://cr.openjdk.java.net/~weijun/8076190/webrev.03/. >> Mostly spec changes. The test is enhanced a little to check for macAlg interop. >>> On Sep 24, 2018, at 11:15 PM, Sean Mullan wrote: >>> >>> Right, I understand their usage and the properties are well documented. My comment is that if you just read the first sentence which is typically a summary sentence, it gives no indication that some of these properties may also be used when modifying a keystore. You have to read further to figure that out, and that might be missed. Perhaps if you added a second sentence to the first paragraph: "Several of the properties may also be used when modifying an existing keystore." Then the next paragraph starts ... >> Good. >>> >>>>> The default alg values seem somewhat weak. Can we upgrade them or is there a compatibility issue/risk? >>>> It will be addressed in a different RFE and is not related to migrating cacerts to password-less. >>>> I haven't studied it yet. Need to investigate how current releases of various tools (openssl, browsers...) support it. >>> >>> Ok. >>> >>> Still need to review PKCS12KeyStore, but here are some more comments: >>> >>> * java.security >>> >>> You should probably say that these properties are specific to the JDK PKCS12 KeyStore implementation and may not be supported by other PKCS12 implementations. >>> >>> What happens if the properties are not set or are set to the empty String? >> When not set, there is a default value. It happens to be the same as what the out-of-box java.security shows. >> When empty, there will be an error. Say, NumberFormatException, NoSuchAlgorithmException. >>> Are the algorithm names case-insensitive? >> Should be case-insensitive. For each one, I've specified it as "algorithm defined in the XYZ section of standard names". Is that enough to show it's case-insensitive? >>> >>> What if illegal values, or unknown algorithms are set for the properties? Are they ignored? Do they throw an Exception? Or do they fallback to hard-coded defaults? This behavior should be specified. >> Throw an exception. I cannot guarantee when it will be thrown so I just say "when it's used". >>> >>> * Passwordless >>> >>> Can you add some comments as to why openssl is needed? Aren't there some tests you can still do if it is not there? And maybe add some comments in the class description as to what the test is generally testing as it hard to discern that from just scanning the code. >> Interoperability. I generate pkcs12 keystores from openssl using various settings and make sure keytool can read them, vice versa. Maybe I should move it to the infra test group. >> Thanks >> Max >>> >>> --Sean From sha.jiang at oracle.com Thu Sep 27 09:34:38 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 27 Sep 2018 17:34:38 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx In-Reply-To: <498226a1-bf16-d353-a0d6-a1bfc09c41ae@oracle.com> References: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> <8fcc29ae-4c17-b1f9-1a50-e45a96af1318@oracle.com> <0ED6BF6E-FFF7-40C3-8F2D-5DE9ECAF3F88@oracle.com> <498226a1-bf16-d353-a0d6-a1bfc09c41ae@oracle.com> Message-ID: <9e963d63-cbc8-967f-6d1f-6bcd182e2eed@oracle.com> Hi Max, Please review this new webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.02/ You previous points, except #1, are addressed. Best regards, John Jiang On 2018/9/27 11:18, sha.jiang at oracle.com wrote: > On 2018/9/27 10:34, Weijun Wang wrote: >> Hi John >> >> 1. Please add @bug to all tests. > Which issue should be linked? JDK-8209546? > I suppose @bug should indicate a product issue here. > At least, JDK-8209546 looks have no much association with this test. > >> >> 2. Are getLibPath() and findLib() in AutoTest.java really necessary? >> It looks like PKCS11Test::getNSSLibDir is doing something similar. > I'll modify PKCS11Test.java a bit to help this point. > >> >> 3. Looks like Standard.java is not necessary now. You can just make >> KeyToolTest.java a @test and add a @run line there, something like >> >> ???? @run main/othervm/timeout=600 -Dfile KeyToolTest > Will address. > >> >> 4. Maybe we can rename AutoTest.java to NssTest.java. The old name >> says nothing. > Will address. > > Best regards, > John Jiang >> >> Thanks >> Max >> >>> On Sep 27, 2018, at 9:25 AM, sha.jiang at oracle.com wrote: >>> >>> Hi Max, >>> Please review the updated webrev: >>> http://cr.openjdk.java.net/~jjiang/8209546/webrev.01/ >>> All your comments are addressed, though this test is moved to >>> problem list for windows due to JDK-8204203. >>> >>> Best regards, >>> John Jiang >>> On 2018/9/25 22:30, Weijun Wang wrote: >>>> Some questions: >>>> >>>> 1. Do we still need the OS check on lines 47-49? As long as >>>> getLibPath() can return something, does it mean the test should >>>> just run? Especially, does the test run on Windows? >>>> >>>> 2. Is launching a separate process necessary? Can we just call >>>> KeyToolTest::main after setting system properties and copying the >>>> files. >>>> >>>> 3. Is it possible to include standard.sh? >>>> >>>> Thanks >>>> Max >>>> >>>> >>>>> On Sep 25, 2018, at 6:30 PM, sha.jiang at oracle.com >>>>> ? wrote: >>>>> >>>>> Hi, >>>>> JDK-8164639 removed NSS libs from repo, so >>>>> sun/security/tools/keytool/autotest.sh has to download NSS libs >>>>> from artifactory on macosx. >>>>> This patch also refactors this shell test to a Java test. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8209546 >>>>> >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> >>>>> >> > > From weijun.wang at oracle.com Thu Sep 27 10:26:55 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 27 Sep 2018 18:26:55 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> Message-ID: <25C4BF71-9BF8-424A-9A48-AD5516D480CE@oracle.com> Webrev updated at http://cr.openjdk.java.net/~weijun/8076190/webrev.04/. Thanks Max > On Sep 27, 2018, at 1:58 PM, Weijun Wang wrote: > > All others accepted. > >> 1122 keystore.pkcs12.certProtectionAlgorithm = PBEWithSHA1AndRC2_40 >> >> Shouldn't this be named certPbeAlgorithm so that it matches certPbeIterationCount? Same comment about keyProtectionAlgorithm. > > Unfortunately we already had "keystore.pkcs12.keyProtectionAlgorithm" and it also accepts "PKCS12". See http://cr.openjdk.java.net/~weijun/8076190/webrev.03/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java-.html: > > 147 private static final String[] KEY_PROTECTION_ALGORITHM = { > 148 "keystore.pkcs12.keyProtectionAlgorithm", > 149 "keystore.PKCS12.keyProtectionAlgorithm" > 150 }; > > But you are right the names are not consistent and supporting both "pkcs12" and "PKCS12" is awkward (and cannot make use of the new SecurityProperties::privilegedGetOverridable method). Now I decide to name the new properties as (key|cert)PbeAlgorithm names with only "pkcs12", and only support the old names as a fallback. > >> * PKCS12KeyStore.java >> >> 145 private static final int PBE_ITERATION_COUNT >> 146 = getPkcs12Setting("pbeIterationCount", 50000); >> >> Shouldn't there be 2 constants above, one for certPbeIterationCount and one for keyPbeIterationCount? > > Oops. Will fix. > >> >> 208 String name2 = "keystore.PKCS12." + type; >> >> I'm not sure checking the property name with uppercase PKCS12 is necessary. I think we should assume that the property name is case-sensitive, as most properties are. > > See above. > >> >> 2108 // What shall we do if there is ENCRYPTED_DATA_OID but >> 2109 // we do not have a password? >> >> This section of comments (thru line 2123) should really be reworded to say what the current implementation does and perhaps allude to why it is not perfect but is probably the best option. Right now it reads too much like a brainstorming session :) > > I *am* brainstorming inside my brain. I had long thought about throwing an exception here. > > With the password-less cacerts, hopefully this will not be a problem for many people and we can just keep the current behavior. > > Thanks > Max > >> >> --Sean >> >> On 9/25/18 6:49 AM, Weijun Wang wrote: >>> Webrev updated at http://cr.openjdk.java.net/~weijun/8076190/webrev.03/. >>> Mostly spec changes. The test is enhanced a little to check for macAlg interop. >>>> On Sep 24, 2018, at 11:15 PM, Sean Mullan wrote: >>>> >>>> Right, I understand their usage and the properties are well documented. My comment is that if you just read the first sentence which is typically a summary sentence, it gives no indication that some of these properties may also be used when modifying a keystore. You have to read further to figure that out, and that might be missed. Perhaps if you added a second sentence to the first paragraph: "Several of the properties may also be used when modifying an existing keystore." Then the next paragraph starts ... >>> Good. >>>> >>>>>> The default alg values seem somewhat weak. Can we upgrade them or is there a compatibility issue/risk? >>>>> It will be addressed in a different RFE and is not related to migrating cacerts to password-less. >>>>> I haven't studied it yet. Need to investigate how current releases of various tools (openssl, browsers...) support it. >>>> >>>> Ok. >>>> >>>> Still need to review PKCS12KeyStore, but here are some more comments: >>>> >>>> * java.security >>>> >>>> You should probably say that these properties are specific to the JDK PKCS12 KeyStore implementation and may not be supported by other PKCS12 implementations. >>>> >>>> What happens if the properties are not set or are set to the empty String? >>> When not set, there is a default value. It happens to be the same as what the out-of-box java.security shows. >>> When empty, there will be an error. Say, NumberFormatException, NoSuchAlgorithmException. >>>> Are the algorithm names case-insensitive? >>> Should be case-insensitive. For each one, I've specified it as "algorithm defined in the XYZ section of standard names". Is that enough to show it's case-insensitive? >>>> >>>> What if illegal values, or unknown algorithms are set for the properties? Are they ignored? Do they throw an Exception? Or do they fallback to hard-coded defaults? This behavior should be specified. >>> Throw an exception. I cannot guarantee when it will be thrown so I just say "when it's used". >>>> >>>> * Passwordless >>>> >>>> Can you add some comments as to why openssl is needed? Aren't there some tests you can still do if it is not there? And maybe add some comments in the class description as to what the test is generally testing as it hard to discern that from just scanning the code. >>> Interoperability. I generate pkcs12 keystores from openssl using various settings and make sure keytool can read them, vice versa. Maybe I should move it to the infra test group. >>> Thanks >>> Max >>>> >>>> --Sean > From weijun.wang at oracle.com Thu Sep 27 13:20:10 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 27 Sep 2018 21:20:10 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx In-Reply-To: <9e963d63-cbc8-967f-6d1f-6bcd182e2eed@oracle.com> References: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> <8fcc29ae-4c17-b1f9-1a50-e45a96af1318@oracle.com> <0ED6BF6E-FFF7-40C3-8F2D-5DE9ECAF3F88@oracle.com> <498226a1-bf16-d353-a0d6-a1bfc09c41ae@oracle.com> <9e963d63-cbc8-967f-6d1f-6bcd182e2eed@oracle.com> Message-ID: Change looks fine. On PKCS11Test.java:453, you can use Files::newInputStream. Thanks Max > On Sep 27, 2018, at 5:34 PM, sha.jiang at oracle.com wrote: > > Hi Max, > Please review this new webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.02/ > You previous points, except #1, are addressed. > > Best regards, > John Jiang > > On 2018/9/27 11:18, sha.jiang at oracle.com wrote: >> On 2018/9/27 10:34, Weijun Wang wrote: >>> Hi John >>> >>> 1. Please add @bug to all tests. >> Which issue should be linked? JDK-8209546? >> I suppose @bug should indicate a product issue here. >> At least, JDK-8209546 looks have no much association with this test. >> >>> >>> 2. Are getLibPath() and findLib() in AutoTest.java really necessary? It looks like PKCS11Test::getNSSLibDir is doing something similar. >> I'll modify PKCS11Test.java a bit to help this point. >> >>> >>> 3. Looks like Standard.java is not necessary now. You can just make KeyToolTest.java a @test and add a @run line there, something like >>> >>> @run main/othervm/timeout=600 -Dfile KeyToolTest >> Will address. >> >>> >>> 4. Maybe we can rename AutoTest.java to NssTest.java. The old name says nothing. >> Will address. >> >> Best regards, >> John Jiang >>> >>> Thanks >>> Max >>> >>>> On Sep 27, 2018, at 9:25 AM, sha.jiang at oracle.com wrote: >>>> >>>> Hi Max, >>>> Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.01/ >>>> All your comments are addressed, though this test is moved to problem list for windows due to JDK-8204203. >>>> >>>> Best regards, >>>> John Jiang >>>> On 2018/9/25 22:30, Weijun Wang wrote: >>>>> Some questions: >>>>> >>>>> 1. Do we still need the OS check on lines 47-49? As long as getLibPath() can return something, does it mean the test should just run? Especially, does the test run on Windows? >>>>> >>>>> 2. Is launching a separate process necessary? Can we just call KeyToolTest::main after setting system properties and copying the files. >>>>> >>>>> 3. Is it possible to include standard.sh? >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>>> On Sep 25, 2018, at 6:30 PM, sha.jiang at oracle.com >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> JDK-8164639 removed NSS libs from repo, so sun/security/tools/keytool/autotest.sh has to download NSS libs from artifactory on macosx. >>>>>> This patch also refactors this shell test to a Java test. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/ >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8209546 >>>>>> >>>>>> >>>>>> Best regards, >>>>>> John Jiang >>>>>> >>>>>> >>> >> >> > From sean.mullan at oracle.com Thu Sep 27 13:43:40 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 27 Sep 2018 09:43:40 -0400 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> Message-ID: <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> On 9/27/18 1:58 AM, Weijun Wang wrote: > All others accepted. > >> 1122 keystore.pkcs12.certProtectionAlgorithm = PBEWithSHA1AndRC2_40 >> >> Shouldn't this be named certPbeAlgorithm so that it matches certPbeIterationCount? Same comment about keyProtectionAlgorithm. > > Unfortunately we already had "keystore.pkcs12.keyProtectionAlgorithm" and it also accepts "PKCS12". Ah, I see - I forgot about that property. See http://cr.openjdk.java.net/~weijun/8076190/webrev.03/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java-.html: > > 147 private static final String[] KEY_PROTECTION_ALGORITHM = { > 148 "keystore.pkcs12.keyProtectionAlgorithm", > 149 "keystore.PKCS12.keyProtectionAlgorithm" > 150 }; > > But you are right the names are not consistent and supporting both "pkcs12" and "PKCS12" is awkward (and cannot make use of the new SecurityProperties::privilegedGetOverridable method). Now I decide to name the new properties as (key|cert)PbeAlgorithm names with only "pkcs12", and only support the old names as a fallback. Hmm, but this means we have to support 2 properties meaning the same thing, and the KeyStore.PasswordProtection.getProtectionAlgorithm() is already specified to use the keystore..keyProtectionAlgorithm property. Based on that, I take back my comment, and I think it would be better to retain the existing property instead of defining another one with the same meaning. I don't like having to try to get the properties with "pkcs12" and "PKCS12", but it seems we could live with that since we have been doing it and we only need to do this for the existing properties - we could assume "pkcs12" for all of the new ones. --Sean From weijun.wang at oracle.com Thu Sep 27 14:23:46 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 27 Sep 2018 22:23:46 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> Message-ID: Oh, I didn't know it was specified in KeyStore.PasswordProtection.getProtectionAlgorithm(). I'll need to rework on webrev.04. As for pkcs12 or PKCS12, do we really need to treat old and new properties differently? I would document them in java.security with pkcs12 but support reading both. --Max > On Sep 27, 2018, at 9:43 PM, Sean Mullan wrote: > > On 9/27/18 1:58 AM, Weijun Wang wrote: >> All others accepted. >>> 1122 keystore.pkcs12.certProtectionAlgorithm = PBEWithSHA1AndRC2_40 >>> >>> Shouldn't this be named certPbeAlgorithm so that it matches certPbeIterationCount? Same comment about keyProtectionAlgorithm. >> Unfortunately we already had "keystore.pkcs12.keyProtectionAlgorithm" and it also accepts "PKCS12". > > Ah, I see - I forgot about that property. > > See http://cr.openjdk.java.net/~weijun/8076190/webrev.03/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java-.html: >> 147 private static final String[] KEY_PROTECTION_ALGORITHM = { >> 148 "keystore.pkcs12.keyProtectionAlgorithm", >> 149 "keystore.PKCS12.keyProtectionAlgorithm" >> 150 }; >> But you are right the names are not consistent and supporting both "pkcs12" and "PKCS12" is awkward (and cannot make use of the new SecurityProperties::privilegedGetOverridable method). Now I decide to name the new properties as (key|cert)PbeAlgorithm names with only "pkcs12", and only support the old names as a fallback. > > Hmm, but this means we have to support 2 properties meaning the same thing, and the KeyStore.PasswordProtection.getProtectionAlgorithm() is already specified to use the keystore..keyProtectionAlgorithm property. Based on that, I take back my comment, and I think it would be better to retain the existing property instead of defining another one with the same meaning. I don't like having to try to get the properties with "pkcs12" and "PKCS12", but it seems we could live with that since we have been doing it and we only need to do this for the existing properties - we could assume "pkcs12" for all of the new ones. > > --Sean From sean.mullan at oracle.com Thu Sep 27 14:29:13 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 27 Sep 2018 10:29:13 -0400 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> Message-ID: <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> It seems odd to support both. Once we put that into the code it?s very hard to take out in case someone is depending on it. So for the new properties I would just support one variant. > On Sep 27, 2018, at 10:23 AM, Weijun Wang wrote: > > Oh, I didn't know it was specified in KeyStore.PasswordProtection.getProtectionAlgorithm(). I'll need to rework on webrev.04. > > As for pkcs12 or PKCS12, do we really need to treat old and new properties differently? I would document them in java.security with pkcs12 but support reading both. > > --Max > >> On Sep 27, 2018, at 9:43 PM, Sean Mullan wrote: >> >> On 9/27/18 1:58 AM, Weijun Wang wrote: >>> All others accepted. >>>> 1122 keystore.pkcs12.certProtectionAlgorithm = PBEWithSHA1AndRC2_40 >>>> >>>> Shouldn't this be named certPbeAlgorithm so that it matches certPbeIterationCount? Same comment about keyProtectionAlgorithm. >>> Unfortunately we already had "keystore.pkcs12.keyProtectionAlgorithm" and it also accepts "PKCS12". >> >> Ah, I see - I forgot about that property. >> >> See http://cr.openjdk.java.net/~weijun/8076190/webrev.03/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java-.html: >>> 147 private static final String[] KEY_PROTECTION_ALGORITHM = { >>> 148 "keystore.pkcs12.keyProtectionAlgorithm", >>> 149 "keystore.PKCS12.keyProtectionAlgorithm" >>> 150 }; >>> But you are right the names are not consistent and supporting both "pkcs12" and "PKCS12" is awkward (and cannot make use of the new SecurityProperties::privilegedGetOverridable method). Now I decide to name the new properties as (key|cert)PbeAlgorithm names with only "pkcs12", and only support the old names as a fallback. >> >> Hmm, but this means we have to support 2 properties meaning the same thing, and the KeyStore.PasswordProtection.getProtectionAlgorithm() is already specified to use the keystore..keyProtectionAlgorithm property. Based on that, I take back my comment, and I think it would be better to retain the existing property instead of defining another one with the same meaning. I don't like having to try to get the properties with "pkcs12" and "PKCS12", but it seems we could live with that since we have been doing it and we only need to do this for the existing properties - we could assume "pkcs12" for all of the new ones. >> >> --Sean > From weijun.wang at oracle.com Thu Sep 27 15:27:34 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 27 Sep 2018 23:27:34 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> Message-ID: <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> Thinking about this more and there is a small problem. Suppose a user is already using PKCS12. Since it was a security property, there are 2 ways to use it: 1. Set it in java.security. Now the user is using JDK 12 and in java.security there is an existing keystore.pkcs12.keyProtectionAlgorithm. If the user noticed it, he would realize this is the formal name and modify it. If he hasn't noticed it he would add a new line using PKCS12. But then since both exist, the "pkcs12" one will be read first. 2. Set it with Security::setProperty. This is similar to the "hasn't noticed it" case above, and his value will be ignored. So, the user-provided PKCS12 one will only be used if the user is using an old java.security file. Do we really want to support that? Since PKCS12 is already written into KeyStore.java, it seems the correct way is to use "PKCS12" as the formal name and use "pkcs12" as an alias. But in JDK 11, the search order is first "pkcs12" and then "PKCS12". Or, shall we comment out the lines in java.security? They are indeed useless because default values are already hardcoded in source files. --Max > On Sep 27, 2018, at 10:29 PM, Sean Mullan wrote: > > It seems odd to support both. Once we put that into the code it?s very hard to take out in case someone is depending on it. So for the new properties I would just support one variant. From sean.mullan at oracle.com Thu Sep 27 16:22:51 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 27 Sep 2018 12:22:51 -0400 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> Message-ID: <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> The keystore.pkcs12.keyProtectionAlgorithm property was introduced in JDK 8. I don't think there are many apps using it. Thus, I would make a decision on what you think the best solution is long-term and then make sure you document any compatibility issues in the CSR and release note. My main advice is not to carry over the existing PKCS12 or pkcs12 flexibility into the new properties. --Sean On 9/27/18 11:27 AM, Weijun Wang wrote: > Thinking about this more and there is a small problem. > > Suppose a user is already using PKCS12. Since it was a security property, there are 2 ways to use it: > > 1. Set it in java.security. Now the user is using JDK 12 and in java.security there is an existing keystore.pkcs12.keyProtectionAlgorithm. If the user noticed it, he would realize this is the formal name and modify it. If he hasn't noticed it he would add a new line using PKCS12. But then since both exist, the "pkcs12" one will be read first. > > 2. Set it with Security::setProperty. This is similar to the "hasn't noticed it" case above, and his value will be ignored. > > So, the user-provided PKCS12 one will only be used if the user is using an old java.security file. Do we really want to support that? > > > Since PKCS12 is already written into KeyStore.java, it seems the correct way is to use "PKCS12" as the formal name and use "pkcs12" as an alias. But in JDK 11, the search order is first "pkcs12" and then "PKCS12". > > Or, shall we comment out the lines in java.security? They are indeed useless because default values are already hardcoded in source files. > > --Max > >> On Sep 27, 2018, at 10:29 PM, Sean Mullan wrote: >> >> It seems odd to support both. Once we put that into the code it?s very hard to take out in case someone is depending on it. So for the new properties I would just support one variant. > From norman.maurer at googlemail.com Thu Sep 27 18:19:20 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Thu, 27 Sep 2018 20:19:20 +0200 Subject: sun.security.ssl.ProtocolVersion.valueOf(...) in Java8 and TLSv1.3 In-Reply-To: <3AB902DD-412B-4ECB-9772-529D5274EC52@googlemail.com> References: <2005a485-1cac-2049-223d-beaa45084dbe@oracle.com> <3AB902DD-412B-4ECB-9772-529D5274EC52@googlemail.com> Message-ID: <8D3BB701-4985-4B64-8372-3DE2C4EB6C44@googlemail.com> So I did some more testing and all in all it seems to work. I will do some more investigating still and then log the request if I can not see any negative side-effects. Bye Norman > On 18. Sep 2018, at 18:08, Norman Maurer wrote: > > I did some testing and it seems to ?just work?. I will do a bit more and then come back you + filling the enhancement request. > > Bye > Norman > > >> On 17. Sep 2018, at 18:04, Xuelei Fan wrote: >> >> Hi Norman, >> >> In general, it is risk to support unknown protocol version in the key/trust manager implementation. The trust manager implemented for TLS 1.2 and prior versions might not work with TLS 1.3 probably. Did you make the evaluation? Would you mind contribute a patch? >> >> Please feel free to file an enhancement request, for further evaluation when there is a chance. >> >> Thanks, >> Xuelei >> >> On 9/17/2018 5:28 AM, Norman Maurer wrote: >>> Hi all, >>> In netty we support using OpenSSL for native SSL which recently added TLSv1.3 support as part of OpenSSL 1.1.1. In an ideal world we would be able to use this even with Java8 which is almost true except the fact that sun.security.ssl.ProtocolVersion.valueOf(?) will throw an IllegalArgumentException when the string ?TLSv1.3? is provided. This is problematic as this happens during validation in the default TrustManager used by the OpenJDK. >>> The stack looks something like this: >>> java.lang.IllegalArgumentException: TLSv1.3 >>> at sun.security.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:187) >>> at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:258) >>> at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:136) >>> I could work around this by just wrap the SSLSession and return TLSv1.2 during validation as the same validation should be done as in the TLSv1.2 implementation but this is really just a hack.So I wonder if you would consider to either add support for parsing TLSv1.3 to the internal enum or just handle it more gracefully. Another thing that would work of course is to always provide a custom X509ExtendedTrustManager but I hoped to be able to re-use the default implementation as it already implements a lot of verification logic. >>> WDYT ? >>> Norman > From weijun.wang at oracle.com Thu Sep 27 23:26:57 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 28 Sep 2018 07:26:57 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> Message-ID: <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> I think commenting out the key=value lines in java.security will ensure compatibility. Also, I think it's a tiny bug between 1. KeyStore.java uses "keystore.PKCS12.keyProtectionAlgorithm" 2. PKCS12KeyStore searches for "keystore.pkcs12.keyProtectionAlgorithm" first and "keystore.PKCS12.keyProtectionAlgorithm" next. I would like to update KeyStore.java to use "keystore.pkcs12.keyProtectionAlgorithm". We will keep supporting the PKCS12 name for this old property but everything else is clean. How do you think? Thanks Max > On Sep 28, 2018, at 12:22 AM, Sean Mullan wrote: > > The keystore.pkcs12.keyProtectionAlgorithm property was introduced in JDK 8. I don't think there are many apps using it. > > Thus, I would make a decision on what you think the best solution is long-term and then make sure you document any compatibility issues in the CSR and release note. > > My main advice is not to carry over the existing PKCS12 or pkcs12 flexibility into the new properties. > > --Sean > > On 9/27/18 11:27 AM, Weijun Wang wrote: >> Thinking about this more and there is a small problem. >> Suppose a user is already using PKCS12. Since it was a security property, there are 2 ways to use it: >> 1. Set it in java.security. Now the user is using JDK 12 and in java.security there is an existing keystore.pkcs12.keyProtectionAlgorithm. If the user noticed it, he would realize this is the formal name and modify it. If he hasn't noticed it he would add a new line using PKCS12. But then since both exist, the "pkcs12" one will be read first. >> 2. Set it with Security::setProperty. This is similar to the "hasn't noticed it" case above, and his value will be ignored. >> So, the user-provided PKCS12 one will only be used if the user is using an old java.security file. Do we really want to support that? >> Since PKCS12 is already written into KeyStore.java, it seems the correct way is to use "PKCS12" as the formal name and use "pkcs12" as an alias. But in JDK 11, the search order is first "pkcs12" and then "PKCS12". >> Or, shall we comment out the lines in java.security? They are indeed useless because default values are already hardcoded in source files. >> --Max >>> On Sep 27, 2018, at 10:29 PM, Sean Mullan wrote: >>> >>> It seems odd to support both. Once we put that into the code it?s very hard to take out in case someone is depending on it. So for the new properties I would just support one variant. From sha.jiang at oracle.com Fri Sep 28 00:55:23 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 28 Sep 2018 08:55:23 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx In-Reply-To: References: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> <8fcc29ae-4c17-b1f9-1a50-e45a96af1318@oracle.com> <0ED6BF6E-FFF7-40C3-8F2D-5DE9ECAF3F88@oracle.com> <498226a1-bf16-d353-a0d6-a1bfc09c41ae@oracle.com> <9e963d63-cbc8-967f-6d1f-6bcd182e2eed@oracle.com> Message-ID: <7994fae4-a8bd-70d7-738b-2cc478d9675e@oracle.com> On 2018/9/27 21:20, Weijun Wang wrote: > Change looks fine. > > On PKCS11Test.java:453, you can use Files::newInputStream. Just addressed it, please take a look at this updated webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.03/ It also renames the test in ProblemList.txt accordingly. Best regards, John Jiang > Thanks > Max > >> On Sep 27, 2018, at 5:34 PM,sha.jiang at oracle.com wrote: >> >> Hi Max, >> Please review this new webrev:http://cr.openjdk.java.net/~jjiang/8209546/webrev.02/ >> You previous points, except #1, are addressed. >> >> Best regards, >> John Jiang >> >> On 2018/9/27 11:18,sha.jiang at oracle.com wrote: >>> On 2018/9/27 10:34, Weijun Wang wrote: >>>> Hi John >>>> >>>> 1. Please add @bug to all tests. >>> Which issue should be linked? JDK-8209546? >>> I suppose @bug should indicate a product issue here. >>> At least, JDK-8209546 looks have no much association with this test. >>> >>>> 2. Are getLibPath() and findLib() in AutoTest.java really necessary? It looks like PKCS11Test::getNSSLibDir is doing something similar. >>> I'll modify PKCS11Test.java a bit to help this point. >>> >>>> 3. Looks like Standard.java is not necessary now. You can just make KeyToolTest.java a @test and add a @run line there, something like >>>> >>>> @run main/othervm/timeout=600 -Dfile KeyToolTest >>> Will address. >>> >>>> 4. Maybe we can rename AutoTest.java to NssTest.java. The old name says nothing. >>> Will address. >>> >>> Best regards, >>> John Jiang >>>> Thanks >>>> Max >>>> >>>>> On Sep 27, 2018, at 9:25 AM,sha.jiang at oracle.com wrote: >>>>> >>>>> Hi Max, >>>>> Please review the updated webrev:http://cr.openjdk.java.net/~jjiang/8209546/webrev.01/ >>>>> All your comments are addressed, though this test is moved to problem list for windows due to JDK-8204203. >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> On 2018/9/25 22:30, Weijun Wang wrote: >>>>>> Some questions: >>>>>> >>>>>> 1. Do we still need the OS check on lines 47-49? As long as getLibPath() can return something, does it mean the test should just run? Especially, does the test run on Windows? >>>>>> >>>>>> 2. Is launching a separate process necessary? Can we just call KeyToolTest::main after setting system properties and copying the files. >>>>>> >>>>>> 3. Is it possible to include standard.sh? >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>>> On Sep 25, 2018, at 6:30 PM,sha.jiang at oracle.com >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> JDK-8164639 removed NSS libs from repo, so sun/security/tools/keytool/autotest.sh has to download NSS libs from artifactory on macosx. >>>>>>> This patch also refactors this shell test to a Java test. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/ >>>>>>> >>>>>>> Issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8209546 >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> John Jiang >>>>>>> >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Sep 28 07:19:57 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 28 Sep 2018 15:19:57 +0800 Subject: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx In-Reply-To: <7994fae4-a8bd-70d7-738b-2cc478d9675e@oracle.com> References: <7c1cf9a6-363a-a73f-e255-f7dda8b27db9@oracle.com> <8fcc29ae-4c17-b1f9-1a50-e45a96af1318@oracle.com> <0ED6BF6E-FFF7-40C3-8F2D-5DE9ECAF3F88@oracle.com> <498226a1-bf16-d353-a0d6-a1bfc09c41ae@oracle.com> <9e963d63-cbc8-967f-6d1f-6bcd182e2eed@oracle.com> <7994fae4-a8bd-70d7-738b-2cc478d9675e@oracle.com> Message-ID: The change looks fine. Thanks Max > On Sep 28, 2018, at 8:55 AM, sha.jiang at oracle.com wrote: > > On 2018/9/27 21:20, Weijun Wang wrote: >> Change looks fine. >> >> On PKCS11Test.java:453, you can use Files::newInputStream. >> > Just addressed it, please take a look at this updated webrev: > http://cr.openjdk.java.net/~jjiang/8209546/webrev.03/ > It also renames the test in ProblemList.txt accordingly. > > Best regards, > John Jiang >> Thanks >> Max >> >> >>> On Sep 27, 2018, at 5:34 PM, sha.jiang at oracle.com >>> wrote: >>> >>> Hi Max, >>> Please review this new webrev: >>> http://cr.openjdk.java.net/~jjiang/8209546/webrev.02/ >>> >>> You previous points, except #1, are addressed. >>> >>> Best regards, >>> John Jiang >>> >>> On 2018/9/27 11:18, >>> sha.jiang at oracle.com >>> wrote: >>> >>>> On 2018/9/27 10:34, Weijun Wang wrote: >>>> >>>>> Hi John >>>>> >>>>> 1. Please add @bug to all tests. >>>>> >>>> Which issue should be linked? JDK-8209546? >>>> I suppose @bug should indicate a product issue here. >>>> At least, JDK-8209546 looks have no much association with this test. >>>> >>>> >>>>> 2. Are getLibPath() and findLib() in AutoTest.java really necessary? It looks like PKCS11Test::getNSSLibDir is doing something similar. >>>>> >>>> I'll modify PKCS11Test.java a bit to help this point. >>>> >>>> >>>>> 3. Looks like Standard.java is not necessary now. You can just make KeyToolTest.java a @test and add a @run line there, something like >>>>> >>>>> @run main/othervm/timeout=600 -Dfile KeyToolTest >>>>> >>>> Will address. >>>> >>>> >>>>> 4. Maybe we can rename AutoTest.java to NssTest.java. The old name says nothing. >>>>> >>>> Will address. >>>> >>>> Best regards, >>>> John Jiang >>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>>> On Sep 27, 2018, at 9:25 AM, sha.jiang at oracle.com >>>>>> wrote: >>>>>> >>>>>> Hi Max, >>>>>> Please review the updated webrev: >>>>>> http://cr.openjdk.java.net/~jjiang/8209546/webrev.01/ >>>>>> >>>>>> All your comments are addressed, though this test is moved to problem list for windows due to JDK-8204203. >>>>>> >>>>>> Best regards, >>>>>> John Jiang >>>>>> On 2018/9/25 22:30, Weijun Wang wrote: >>>>>> >>>>>>> Some questions: >>>>>>> >>>>>>> 1. Do we still need the OS check on lines 47-49? As long as getLibPath() can return something, does it mean the test should just run? Especially, does the test run on Windows? >>>>>>> >>>>>>> 2. Is launching a separate process necessary? Can we just call KeyToolTest::main after setting system properties and copying the files. >>>>>>> >>>>>>> 3. Is it possible to include standard.sh? >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Sep 25, 2018, at 6:30 PM, sha.jiang at oracle.com >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> JDK-8164639 removed NSS libs from repo, so sun/security/tools/keytool/autotest.sh has to download NSS libs from artifactory on macosx. >>>>>>>> This patch also refactors this shell test to a Java test. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Issue: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8209546 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> John Jiang >>>>>>>> >>>>>>>> >>>>>>>> > From weijun.wang at oracle.com Fri Sep 28 13:36:57 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 28 Sep 2018 21:36:57 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> Message-ID: Webrev updated at http://cr.openjdk.java.net/~weijun/8076190/webrev.04/ Major changes: 1. Comment out key=value lines in java.security 2. Fix a bug in PBES2Parameters.java 3. Test no longer depends on openssl. Instead, use openssl to generate some pkcs12 files and included in the test. 4. A new test KeyProtAlgCompat.java to ensure compatibility on pkcs12/PKCS12 names I haven't made any change to KeyStore.java yet. CSR is also not updated. Thanks Max > On Sep 28, 2018, at 7:26 AM, Weijun Wang wrote: > > I think commenting out the key=value lines in java.security will ensure compatibility. > > Also, I think it's a tiny bug between > > 1. KeyStore.java uses "keystore.PKCS12.keyProtectionAlgorithm" > 2. PKCS12KeyStore searches for "keystore.pkcs12.keyProtectionAlgorithm" first and "keystore.PKCS12.keyProtectionAlgorithm" next. > > I would like to update KeyStore.java to use "keystore.pkcs12.keyProtectionAlgorithm". We will keep supporting the PKCS12 name for this old property but everything else is clean. > > How do you think? > > Thanks > Max > >> On Sep 28, 2018, at 12:22 AM, Sean Mullan wrote: >> >> The keystore.pkcs12.keyProtectionAlgorithm property was introduced in JDK 8. I don't think there are many apps using it. >> >> Thus, I would make a decision on what you think the best solution is long-term and then make sure you document any compatibility issues in the CSR and release note. >> >> My main advice is not to carry over the existing PKCS12 or pkcs12 flexibility into the new properties. >> >> --Sean >> >> On 9/27/18 11:27 AM, Weijun Wang wrote: >>> Thinking about this more and there is a small problem. >>> Suppose a user is already using PKCS12. Since it was a security property, there are 2 ways to use it: >>> 1. Set it in java.security. Now the user is using JDK 12 and in java.security there is an existing keystore.pkcs12.keyProtectionAlgorithm. If the user noticed it, he would realize this is the formal name and modify it. If he hasn't noticed it he would add a new line using PKCS12. But then since both exist, the "pkcs12" one will be read first. >>> 2. Set it with Security::setProperty. This is similar to the "hasn't noticed it" case above, and his value will be ignored. >>> So, the user-provided PKCS12 one will only be used if the user is using an old java.security file. Do we really want to support that? >>> Since PKCS12 is already written into KeyStore.java, it seems the correct way is to use "PKCS12" as the formal name and use "pkcs12" as an alias. But in JDK 11, the search order is first "pkcs12" and then "PKCS12". >>> Or, shall we comment out the lines in java.security? They are indeed useless because default values are already hardcoded in source files. >>> --Max >>>> On Sep 27, 2018, at 10:29 PM, Sean Mullan wrote: >>>> >>>> It seems odd to support both. Once we put that into the code it?s very hard to take out in case someone is depending on it. So for the new properties I would just support one variant. > From valerie.peng at oracle.com Sat Sep 29 00:15:57 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 28 Sep 2018 17:15:57 -0700 Subject: RFR 8210821: Support dns_canonicalize_hostname in krb5.conf In-Reply-To: References: <49DF7170-4E18-431D-A733-10507625BCB9@oracle.com> <8AB1F42A-A2B5-4F87-9EC3-AB2F158DA7D2@oracle.com> Message-ID: <3ca1245f-4c6f-91c2-3e1a-a396d6f675b1@oracle.com> Sure, I like the new simplified result. Changes look fine, Valerie On 9/26/2018 7:09 PM, Weijun Wang wrote: > Webrev updated at https://cr.openjdk.java.net/~weijun/8210821/webrev.01. > >> On Sep 26, 2018, at 11:57 PM, Weijun Wang wrote: >> >> Hi Valerie >> >> I've updated the CSR to remove the "always canonicalize" choice and now the default is "true", i.e. the current "smart-canonicalization" behavior. It's 12am here and I'll update the webrev tomorrow. >> >> Thanks >> Max >> >>> On Sep 18, 2018, at 8:52 AM, Valerie Peng wrote: >>> >>> Look fine to me. Added myself to CSR as reviewer. >>> >>> Thanks, >>> >>> Valerie >>> >>> >>> On 9/17/2018 1:17 AM, Weijun Wang wrote: >>>> Please review the code change and CSR at >>>> >>>> http://cr.openjdk.java.net/~weijun/8210821/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8210822 >>>> >>>> Thanks >>>> Max >>>> From hohensee at amazon.com Thu Sep 20 20:52:55 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 20 Sep 2018 20:52:55 +0000 Subject: SSL session cache default maximum number of entries In-Reply-To: <6208f73e-2a3a-896c-15dd-4ee608cfc235@oracle.com> References: <7BB7D5C5-2B63-4451-AC8B-3C65D231BBDC@amazon.com> <65e68e95-dac4-7443-02ad-0e2375b740cb@oracle.com> <4CCB1576-6BFA-430B-974D-86DFD0D864E6@amazon.com> <6208f73e-2a3a-896c-15dd-4ee608cfc235@oracle.com> Message-ID: I've filed https://bugs.openjdk.java.net/browse/JDK-8210985. Thanks for looking into this. Paul ?On 9/17/18, 8:37 AM, "Sean Mullan" wrote: On 9/12/18 2:25 PM, Hohensee, Paul wrote: > Thanks very much for investigating. We're aware that the cache size can be set by the user, but many of our users haven't done so because it hasn't been necessary, and boom. Would you mind filing a bug and we will look into it? Thanks, Sean > > Paul > > On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan" wrote: > > Hi Paul, > > Thank you for bringing this issue to our attention. While we agree that > this does indeed seem like an issue that should be addressed, it is > quite late in the JDK 11 schedule, and it does not appear to be a new > issue introduced in JDK 11. We will be investigating this offline and > will get back to you as soon as we can with more details. Offhand, I > think that we would be able to change the default in an update release. > > Also, you are probably already be aware of this, but you can use the > SSLSessionContext.setSessionCacheSize() API as well as the > "javax.net.ssl.sessionCacheSize" system property to customize the cache > size. > > --Sean > > On 9/11/18 12:02 PM, Sean Mullan wrote: > > cross-posting to security-dev since this is related to SSL/TLS. > > > > On 9/11/18 11:41 AM, Hohensee, Paul wrote: > >> The default value for the maximum number of entries in the SSL session > >> cache (which is a SoftReference cache) is infinite, and the entry > >> timeout is 24 hours. With larger heaps, we?re running into situations > >> where the cache ends up with several million entries when the 24 hours > >> are up. They?re then all invalidated at the same time, resulting in > >> multi-minute pauses (effectively service failures). We?ve experimented > >> with using 10k as the default maximum number of entries with good > >> results (i.e., no latency increases due to sessions falling out of the > >> cache). It?s late and a long shot for JDK11: we?d love to see it > >> changed there because 11 is an LTS release and this is, at least > >> nominally, a behavior change which might not be acceptable in 11u. > >> What do people think? > >> > >> Thanks, > >> > >> Paul > >> > > From mchoma at redhat.com Tue Sep 25 08:23:33 2018 From: mchoma at redhat.com (Martin Choma) Date: Tue, 25 Sep 2018 10:23:33 +0200 Subject: RFR11(s): 8207317: SSLEngine negotiation fail exception behavior changed from fail-fast to fail-lazy Message-ID: Hi, With jdk11 (openjdk/oracle) I see on client side "SSLProtocolException: Connection reset" in negative scenarios (wrong certificate), instead of expected javax.net.SSLException . What is strange, although, it happens randomly (different negative scenarios fails this way and only sometimes) and only on windows machines. So sometimes connection is rather reseted than proper exception is thrown. I came across https://bugs.openjdk.java.net/browse/JDK-8207317, which seems to me relevant to this scenario. Is it possible some indeterministic behaviour was introduced by the fix. Regards, Martin Choma -------------- next part -------------- A non-text attachment was scrubbed... Name: ssl.debug Type: application/octet-stream Size: 77582 bytes Desc: not available URL: