Re: TLS ALPN Proposal v5

[ecki]

Hello,

Just want to mention that with explicite http/https URLs users and applications 
are somewhat used to select the application protocol first. In fact if I have a 
H2 client I would expect it to try H2 first (especially given the fact that no 
weak ciphers could be negotiated anyway). So basically cipher order would 
select if you want strong but fast or very strong but slower crypto for H2. You 
could only mess that up by prefering blacklisted ciphers. But even then the 
serrver can still pick H2 and skip all blacklisted preferences, right?

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Xuelei Fan 
To: Simone Bordet 
Cc: OpenJDK Dev list , "net-dev@openjdk.java.net 
>> OpenJDK Network Dev list" 
Sent: Fr., 25 Sep. 2015 11:48
Subject: Re: TLS ALPN Proposal v5

On 9/25/2015 4:11 PM, Simone Bordet wrote:
> Hi,
> 
> On Fri, Sep 25, 2015 at 3:44 AM, Xuelei Fan  wrote:
>> For example, a client wants to negotiate  {HTTP2,  HTTP1.1} or {HTTP1.1,
>> HTTP2} and {TLS_RSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}.
>> HTTP1.1/TLS_RSA_WITH_AES_128_CBC_SHA should be negotiated per the TLS
>> and HTTP2 specification.  If the cipher suites are sorted,
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 would be negotiated, this is not
>> what the customer really expected.  The customer preference should be
>> respected.
>>
>> I don't think we really need to re-order the cipher suites.
> 
> "We" as in the OpenJDK implementation *must not* reorder the cipher suites.
Yes. I agree with this point, OpenJDK MUST NOT reorder the cipher suites.

> "We" as in an application that wants to use HTTP/2 *must* reorder the
> cipher suites.
In an application, the cipher suites preference MUST be used properly,
but the "reorder" behavior may be not the application expected order.
For some reasons, applications (or customers) may want the preference of
{TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384},
rather than reordered to {TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_RSA_WITH_AES_128_CBC_SHA}.  Customers preference should be
respected,  application and OpenJDK MUST NOT reorder the cipher suites.

If there are three roles, OpenJDK, application, customers, there are
three result:
1. OpenJDK MUST NOT reorder the cipher suites if no application request.
2. Applications MUST NOT reorder the cipher suites if no customer request.
3. Customers can set the cipher suites order according to they requirements.

> The comparator provided is only a help to the application to perform
> this reordering.
> 
>> Let's consider the following client requests (prefer cipher suite more
>> than application protocol; blacklisted_CS are HTTP2 blacklisted cipher
>> suite):
>>
>> 1. {HTTP2, HTTP1.1} {strong_cipher_site, blacklisted_CS}
>> HTTP2 and strong_cipher_site should be negotiated.  Need not to re-order
>> cipher suites.
>>
>> 2. {HTTP1.1, HTTP2} {strong_cipher_site, blacklisted_CS}
>> HTTP1.1 and strong_cipher_site should be negotiated. Need not to
>> re-order cipher suites.
>>
>> 3. {HTTP2, HTTP1.1} {blacklisted_CS, strong_cipher_site}
>> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order
>> cipher suites.
> 
> Of course you need to re-order in this case.
> The application has just provided a preference for HTTP/2 in the
> application protocol list, it actually happens that HTTP/2 could be
> negotiated because strong ciphers are present, but instead HTTP/1.1 is
> chosen.
> 
Here is the question to answer, which preference should be respected
firstly between cipher suite and application protocol?  If application
protocol are preferred at first, of course, application preference
should be respected at first; otherwise, cipher suite preference should
be respected at first.

Let's re-write the example, among {application_protocol_1,
application_protocol_2} and {cipher_suite_for_AP2,
cipher_suite_for_AP1}.  If application protocol preference get
respected, application_protocol_1/cipher_suite_for_AP1 would be
negotiated;  If cipher suite preference get respected,
application_protocol_2/cipher_suite_for_AP2 should be negotiated.

>From my understand, cipher suite preference should be preferred over
application protocols.

>> 4. {HTTP1.1, HTTP2} {blacklisted_CS, strong_cipher_site}
>> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order
>> cipher suites.
>>
>> 5. {HTTP2} {strong_cipher_site, blacklisted_CS}
>> HTTP2 and strong_cipher_site should be negotiated. Need not to re-order
>> cipher suites.
>>
>> 6. {HTTP1.1} {strong_cipher_site, blacklisted_CS}
>> HTTP1.1 and strong_cipher_site should be negotiated. Need not to
>> re-order cipher suites.
>>
>> 7. {HTTP2} {blacklisted_CS, strong_cipher_site}
>> blacklisted_CS would be filtered out as it does not appy to HTTP2.  Only
>> strong_cipher_site presents in ClientHello message.
>>
>> HTTP2 and strong_cipher_site should be negotiated. Need not to re-order
>> cipher suites.
>>
>> 8. {HTTP1.1} {blacklisted_CS, st

Re: RFR 8016521: InetAddress should not always re-order addresses returned from name service

[ecki]

Hello,

Love it. Not sure about two things, first of all if there are more test cases 
(especially assertions) needed and

secondly how to handle the prefer=System case for anyAddr and local. Currently 
it seems to prefer v4 (since this is the current default) howver i would expect 
in the system case to either detect the prefered AF or use ipv6 (as of rfc). 
Returning 127.0.1/0.0.0.0 might actually make the system based address 
detection unuseable in v6 scenarios.

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

-Original Message-
From: vyom 
To: net-dev 
Sent: Di., 10 Mai 2016 12:36
Subject: RFR 8016521: InetAddress should not always re-order addresses returned 
from name service

Hi All,

Please review the code changes for the below issue.

Bug   : JDK-8016521 : InetAddress should not always re-order 
addresses returned from name service
Webrev : 
http://cr.openjdk.java.net/~vtewari/8016521/webrev0.0/index.html 


Thanks,
Vyom

Re: Ping - RFR 8158023: SocketExceptions contain too little information sometimes

[ecki]

Hello,

Since nobody commented, here is my non binding comment:

I am not sure which Exception call-site actually improved (i.e. added the error 
code)? I would split out the improvement of this/those throws and the 
refacturing of the code. Personally I would prefer to keep the NET_ variant and 
adjust the native utilities to remove code duplication.

Does your new version still contain the nummric error code (os error messages 
are unfortunatelly translated).

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

-Original Message-
From: "Langer, Christoph" 
To: "net-dev@openjdk.java.net" 
Sent: Mi., 01 Juni 2016 9:20
Subject: Ping - RFR 8158023: SocketExceptions contain too little information 
sometimes

Hi,

ping - any comments on this?

Thanks
Christoph

From: Langer, Christoph
Sent: Freitag, 27. Mai 2016 10:30
To: net-dev@openjdk.java.net
Cc: core-libs-...@openjdk.java.net; nio-...@openjdk.java.net
Subject: RFR 8158023: SocketExceptions contain too little information sometimes

Hi all,

please review the following change:
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/
Bug: https://bugs.openjdk.java.net/browse/JDK-8158023

During error analysis I stumbled over a place where I encountered a 
SocketException which was thrown along with some strerror information as 
message. I found it hard to find the originating code spot with that 
information.

So I looked at the places where we throw exceptions, namely JNU_Throw... and 
NET_Throw... functions and came up with the following enhancement:
- NET_ThrowByNameWithLastError can go completely as it does not provide any 
benefit over JNU_ThrowByNameWithLastError.
- JNU_ThrowByNameWithLastError can be cleaned up.

- I added JNU_ThrowByNameWithMessageAndLastError to print out a string like 
message + ": " + last error.

- I went over all places where NET_ThrowByNameWithLastError is used and 
replaced it appropriately.

Do you think this change is desirable/possible?

Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as 
well as JNU_Throw... code affects all.

Best regards
Christoph