Re: HttpURLConnection throws SunCertPathBuilderException in jdk11

[Andrey Turbanov]

Thank you for response.
I submitted bug to bugtracker. Iinternal review ID : 9055666
Didn't find a way to attach files there, but program example is short and
can be easily run by anyone.


Andrey Turbanov.

2018-06-15 16:58 GMT+03:00 Sean Mullan :

> The 2nd (good) logfile looks like it is from a completely different
> program - are you sure you are using the same code?
>
> If it is, please rerun again and also add -Djavax.net.debug=all to the
> command-line which should give a bit more debug info as to where the issue
> is occurring in the TLS handshake.
>
> I would also recommend filing a bug and attaching the logfiles so that
> this is tracked and evaluated more formally:
> https://bugreport.java.com/bugreport/
>
> If this is indeed a regression, it's important that we get to the bottom
> of it.
>
> Thanks,
> Sean
>
>
> On 6/12/18 11:10 AM, Андрей Турбанов wrote:
>
>> 2 log files attached.
>>
>> Андрей Турбанов
>>
>> 2018-06-12 15:40 GMT+03:00 Sean Mullan > sean.mul...@oracle.com>>:
>>
>>
>> Please add -Djava.security.debug=certpath to the java command line
>> and attach the log file. Preferably, attach 2 log files, one for a
>> good run and one for a bad run. This should help show what the
>> problem is.
>>
>> --Sean
>>
>> On 6/11/18 7:59 PM, Андрей Турбанов wrote:
>>
>> Hello.
>> I tried to use early jdk11 build (http://jdk.java.net/11/) -
>> Oracle JDK build for Windows.
>> I got exception when my program tries to connect (via
>> HttpURLConnection) to https://api.vk.com/
>>
>> sun.security.provider.certpath.SunCertPathBuilderException:
>> unable to find valid certification path to requested target
>>   at
>> sun.security.provider.certpath.SunCertPathBuilder.build(
>> SunCertPathBuilder.java:141)
>> ~[?:?]
>>   at
>> sun.security.provider.certpath.SunCertPathBuilder.engineBuil
>> d(SunCertPathBuilder.java:126)
>> ~[?:?]
>>   at
>> java.security.cert.CertPathBuilder.build(CertPathBuilder.
>> java:297)
>> ~[?:?]
>>   at
>> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.
>> java:380)
>> ~[?:?]
>>   at
>> sun.security.validator.PKIXValidator.engineValidate(PKIXVali
>> dator.java:290)
>> ~[?:?]
>>   at
>> sun.security.validator.Validator.validate(Validator.java:264)
>> ~[?:?]
>>   at
>> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustMana
>> gerImpl.java:343)
>> ~[?:?]
>>
>> Same code works well with JDK 10.
>> Does JDK11 have different set of SSL certificates? Is there any
>> way to allow connection to vk.com  > >?
>>
>> Andrey Turbanov
>>
>>
>>

Re: java.net.Socket should report the attempted address and port

[Sean Mullan]

Hi Michael,

I agree with Alan and Peter that the name should more clearly identify 
the security implications of setting it.


Alternatively, if you think you may build on this you might want to add 
support for a multi-valued property, like 
jdk.net.includeInExceptions=hostInfo,...


--Sean

On 6/14/18 1:41 PM, Michael McMahon wrote:

Hi Alan,

Thanks for looking at it.

On 14/06/2018, 18:10, Alan Bateman wrote:

On 06/06/2018 08:45, Michael McMahon wrote:

Hi all,

Finally to return to this topic. We have looked at a few different 
approaches
and it seems the best way is to define a security property that can 
be set
in the java.security configuration file, but which can be overridden 
as a
system property. The current behavior will remain the default, but 
setting

the property will add addressing information to exception texts.
The change applies to all TCP socket types in java.net and java.nio.
Webrev at: 
http://cr.openjdk.java.net/~michaelm/8204233/webrev.1/index.html
This looks quite good and the ability to use a system property to 
override the java.security file is useful for ad hoc enabling. The 
property name can probably be improved The jdk.net prefix looks right 
but jdk.net.enhanceExceptionText isn't very clear, esp. when used on 
the command line. It feels it should something like 
jdk.net.includeHostInfoInExceptions or something that makes it clear 
that it adds host information to socket exceptions.


That seems too specific to me. My feeling was that other exceptions 
might be enhanced in the same way and would
hang off the same property name. If we use a name that is specific to 
hostinfo, then we would need a new property

for other information types.

I see Jaikiran Pai spotted the close was accidentally removed from 
AbstractPlainSocketImpl so I assume you'll fix that.



Yes, that was fixed and the webrev updated in place.

Aside from AsynchronousCloseException, are there are other IOException 
classes that don't have the 1-arg String constructor. Just wondering 
if it would be better to special case that to not use SocketExceptions 
or alternative not rely on catching NoSuchMethodException.


The problem was I wrote it first checking types statically, and there 
were a lot of different exception types,
which is ugly enough to begin with but I also overlooked those NIO types 
completely.
It was just difficult to write a test that generated all the possible 
exceptions. So, my concern was overlooking
any future change in that area. Or are you suggesting we just not 
implement this for the async socket channels?


Thanks,

Michael

-Alan

Re: HttpURLConnection throws SunCertPathBuilderException in jdk11

[Sean Mullan]

The 2nd (good) logfile looks like it is from a completely different 
program - are you sure you are using the same code?


If it is, please rerun again and also add -Djavax.net.debug=all to the 
command-line which should give a bit more debug info as to where the 
issue is occurring in the TLS handshake.


I would also recommend filing a bug and attaching the logfiles so that 
this is tracked and evaluated more formally: 
https://bugreport.java.com/bugreport/


If this is indeed a regression, it's important that we get to the bottom 
of it.


Thanks,
Sean


On 6/12/18 11:10 AM, Андрей Турбанов wrote:

2 log files attached.

Андрей Турбанов

2018-06-12 15:40 GMT+03:00 Sean Mullan >:


Please add -Djava.security.debug=certpath to the java command line
and attach the log file. Preferably, attach 2 log files, one for a
good run and one for a bad run. This should help show what the
problem is.

--Sean

On 6/11/18 7:59 PM, Андрей Турбанов wrote:

Hello.
I tried to use early jdk11 build (http://jdk.java.net/11/) -
Oracle JDK build for Windows.
I got exception when my program tries to connect (via
HttpURLConnection) to https://api.vk.com/

sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
      at

sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
~[?:?]
      at

sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
~[?:?]
      at
java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
~[?:?]
      at
sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
~[?:?]
      at

sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:290)
~[?:?]
      at
sun.security.validator.Validator.validate(Validator.java:264) ~[?:?]
      at

sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:343)
~[?:?]

Same code works well with JDK 10.
Does JDK11 have different set of SSL certificates? Is there any
way to allow connection to vk.com  ?

Andrey Turbanov

Re: java.net.Socket should report the attempted address and port

[Alan Bateman]

On 15/06/2018 11:53, Péter Gergely Horváth wrote:

Hi Michael,

I am wondering if the property name could be maybe improved:

1.) The prefix "jdk" does not seem to match the naming convention that 
of the existing networking properties [1], where for example prefix 
"java.net " is used for "java.net.preferIPv4Stack"


The convention in recent years is to use jdk.* for JDK-specific 
properties. JDK-specific meaning specific to the JDK implementation and 
not specified in the Java SE specification. So I think jdk.net is right 
here.


-Alan.

Re: java.net.Socket should report the attempted address and port

[Péter Gergely Horváth]

Hi Michael,

I am wondering if the property name could be maybe improved:

1.) The prefix "jdk" does not seem to match the naming convention that of
the existing networking properties [1], where for example prefix "java.net"
is used for "java.net.preferIPv4Stack"
2.) I agree with Alan that the current name ("enhanceExceptionText") is not
fully specific about what is going to happen when enabled. Since this
feature is made optional due to security considerations, I would rather be
completely clear regarding the meaning of this switch.

Once again, thank you for all your efforts here.


Thanks,
Peter

[1] https://docs.oracle.com/javase/7/docs/api/java/net/
doc-files/net-properties.html




On Thu, Jun 14, 2018 at 7:41 PM, Michael McMahon <
michael.x.mcma...@oracle.com> wrote:

> Hi Alan,
>
> Thanks for looking at it.
>
> On 14/06/2018, 18:10, Alan Bateman wrote:
>
>> On 06/06/2018 08:45, Michael McMahon wrote:
>>
>>> Hi all,
>>>
>>> Finally to return to this topic. We have looked at a few different
>>> approaches
>>> and it seems the best way is to define a security property that can be
>>> set
>>> in the java.security configuration file, but which can be overridden as a
>>> system property. The current behavior will remain the default, but
>>> setting
>>> the property will add addressing information to exception texts.
>>> The change applies to all TCP socket types in java.net and java.nio.
>>> Webrev at: http://cr.openjdk.java.net/~michaelm/8204233/webrev.1/index.
>>> html
>>>
>> This looks quite good and the ability to use a system property to
>> override the java.security file is useful for ad hoc enabling. The property
>> name can probably be improved The jdk.net prefix looks right but
>> jdk.net.enhanceExceptionText isn't very clear, esp. when used on the
>> command line. It feels it should something like jdk.net
>> .includeHostInfoInExceptions or something that makes it clear that it
>> adds host information to socket exceptions.
>>
>> That seems too specific to me. My feeling was that other exceptions might
> be enhanced in the same way and would
> hang off the same property name. If we use a name that is specific to
> hostinfo, then we would need a new property
> for other information types.
>
> I see Jaikiran Pai spotted the close was accidentally removed from
>> AbstractPlainSocketImpl so I assume you'll fix that.
>>
>> Yes, that was fixed and the webrev updated in place.
>
> Aside from AsynchronousCloseException, are there are other IOException
>> classes that don't have the 1-arg String constructor. Just wondering if it
>> would be better to special case that to not use SocketExceptions or
>> alternative not rely on catching NoSuchMethodException.
>>
>> The problem was I wrote it first checking types statically, and there
> were a lot of different exception types,
> which is ugly enough to begin with but I also overlooked those NIO types
> completely.
> It was just difficult to write a test that generated all the possible
> exceptions. So, my concern was overlooking
> any future change in that area. Or are you suggesting we just not
> implement this for the async socket channels?
>
> Thanks,
>
> Michael
>
>> -Alan
>>
>>
>>
>>
>>
>>
>>
>>