Re: RFR: 8135305: InetAddress.isReachable reports true when loopback interface is specified
Please ignore the formatting errors. Thats either a problem with hg diff or webrev, but its fixed in the repo. -Rob On 24/09/15 15:43, Rob McKenna wrote: Hi folks, The recent change to isReachable (8133015: InetAddress.isReachable(tmout) returning wrong value on Windows for IPv6 - http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/59ff6cd9535d) neglected to take the specified interface into account for ipv4. This change ensures that isReachable returns false for external hosts when the loopback interface is specified. http://cr.openjdk.java.net/~robm/8135305/webrev.01/ -Rob
RFR: 8135305: InetAddress.isReachable reports true when loopback interface is specified
Hi folks, The recent change to isReachable (8133015: InetAddress.isReachable(tmout) returning wrong value on Windows for IPv6 - http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/59ff6cd9535d) neglected to take the specified interface into account for ipv4. This change ensures that isReachable returns false for external hosts when the loopback interface is specified. http://cr.openjdk.java.net/~robm/8135305/webrev.01/ -Rob
Re: TLS ALPN Proposal v5
On 9/23/2015 2:33 AM, Simone Bordet wrote:
Hi,
On Wed, Sep 23, 2015 at 7:04 AM, Bradford Wetmore
wrote:
This new proposal still requires that ciphers are sorted in a way that
matches the ApplicationProtocol order.
Would be nice if, along with the HTTP/2 blacklist, there is a HTTP/2
comparator that sorts ciphers putting the blacklisted ones at the end.
Hm...is the sample code at the end of the initial class description
insufficient? Adding a comparator seems a little heavyweight in that it
could require access to the ciphersuite internals and would add a lot of
complexity for this one known use case. When TLSv1.3 is done, the blacklist
stuff in HTTP/2 goes away.
Sure, but until TLS 1.3 widely deployed, applications will have to
sort the ciphers to put HTTP/2 ones before the blacklisted ones.
Providing this comparator is as trivial as providing
ApplicationProtocol.HTTP2BLACKLIST, so I thought to mention it.
I learned something today: Collections/Arrays.sort()/others are stable.
(i.e. equal elements will not be reordered as a result of the sort)
My expectation of "equals" was .equals(), not return value == 0.
I was concerned that such a Comparator might reorder valid H2 suites
from what was passed in. Thankfully, that's not the case, so I've added
this Comparator. There is a warning now about "consistency with
equals()", as the Strings obvioulsy won't be equals() and thus sorted
sets/maps just won't work. (See the Comparator pages for further
discussion.)
I also don't understand why there are 2 methods for the protocol name
? What value does it bring to have 2 methods for the same thing ?
Please see the IANA registry:
http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
for RFC 7301:
http://www.rfc-editor.org/info/rfc7301
getProtocolName() is the IANA/IETF textual representation of the protocol
name (i.e. "Protocol" column), for example "HTTP/1.1", "SPDY/3", and "HTTP/2
over TLS". I suppose toString() could be used instead, but thought it might
eventually output additional ALPN value state. I don't have any concrete
plans at this point.
getNetworkSequence() is the identification sequence for the protocol (i.e.
"Identification Sequence" column), and represents the actual byte
identifiers that will travel the network in an ALPN extension.
0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")
0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3")
0x68 0x32 ("h2")
When client wants to send the extension over the network, it grabs the
ApplicationProtocols values from the SSLParameters, then calls
getNetworkSequence() on each ApplicationProtocol to obtain the actual opaque
ProtocolName(1..2^8-1) to send. Likewise on the server side, we match the
incoming active ALPN opaque values with the list of mutually agreeable ALPN
values. And of course, send back the final selected value.
Sure, but application will have to implement two methods instead of
one, and AFAIU the JDK implementation is never calling
getProtocolName() since it's just a description for humans.
I think that a textual name will be better than:
// Output: javax.net.ssl.ApplicationProtocol$1@1b9e1916
System.out.println(ApplicationProtocol.H2);
and there's no UTF-8 ambiguity.
I've updated the webrev to include an SSLSocket test variant, and added a
few more comments.
http://cr.openjdk.java.net/~wetmore/8051498/webrev.14/
Hopefully things are more clear now. Thanks for your review/comments.
I see now, thanks for the pointers !
Indulge me a bit more below on the Map passed as parameter to
ApplicationProtocol :)
IIUC, by the time we are executing the code that calls
ApplicationProtocol.match(), the TLS protocol is already chosen and
it's available in SSLSession.
Not necessarily. This could also be called before the connection has
even been attempted, say if the client wants to determine if the
proposed protocols or protocol/ciphersuites it wants to use are even
allowed by an ApplicationProtocol.
When remains is the transient value of cipher that is being chosen.
Because we already have modified the API to support the application
protocol transient value (by adding
SSLEngine.getHandshakeApplicationProtocol()) to be used by
KeyManagers, I was wondering if we cannot either:
CipherSuite is more of a Session value, so it should probably be part of
the handshakeSSLSession. We could set
handshakeSSLSession.getCipherSuite() before calling the ALPN selector,
or pass it in as part of the Map.
> A) add: String SSLEngine.getHandshakeCipherSuite(), to be used by
> ApplicationProtocol
That's kind of what we are doing already, but just in the
ApplicationProtocol matcher instead so that it doesn't add extra methods
to SSLSocket/SSLEngine.
And this doesn't really help the pre-connection situation where you want
to query/filter out unacceptable values.
http://cr.openjdk.java.net/~wetmore/8051498/webrev.15/
1. New H2
Re: TLS ALPN Proposal v5
Hi, On Fri, Sep 25, 2015 at 1:45 AM, Bradford Wetmore wrote: > I think that a textual name will be better than: > > // Output: javax.net.ssl.ApplicationProtocol$1@1b9e1916 > > System.out.println(ApplicationProtocol.H2); > > and there's no UTF-8 ambiguity. Sure, but then I would just keep getNetworkSequence(), and remove getProtocolName(), since toString() is sufficient. To have to implement getProtocolName(), I see it as a non-strictly-needed burden to developers that implement ApplicationProtocol. I know of companies that want to use ALPN extensively because they use many different communication protocols internally, so it won't be a rare occasion to implement ApplicationProtocol. > http://cr.openjdk.java.net/~wetmore/8051498/webrev.15/ I gather that the Map parameter can't be solved in other ways, right ? Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Re: TLS ALPN Proposal v5
On 9/25/2015 7:45 AM, Bradford Wetmore wrote:
>
> On 9/23/2015 2:33 AM, Simone Bordet wrote:
>> Hi,
>>
>> On Wed, Sep 23, 2015 at 7:04 AM, Bradford Wetmore
>> wrote:
>>>
This new proposal still requires that ciphers are sorted in a way that
matches the ApplicationProtocol order.
Would be nice if, along with the HTTP/2 blacklist, there is a HTTP/2
comparator that sorts ciphers putting the blacklisted ones at the end.
>>>
>>> Hm...is the sample code at the end of the initial class description
>>> insufficient? Adding a comparator seems a little heavyweight in that it
>>> could require access to the ciphersuite internals and would add a lot of
>>> complexity for this one known use case. When TLSv1.3 is done, the
>>> blacklist
>>> stuff in HTTP/2 goes away.
>>
>> Sure, but until TLS 1.3 widely deployed, applications will have to
>> sort the ciphers to put HTTP/2 ones before the blacklisted ones.
>> Providing this comparator is as trivial as providing
>> ApplicationProtocol.HTTP2BLACKLIST, so I thought to mention it.
>
> I learned something today: Collections/Arrays.sort()/others are stable.
> (i.e. equal elements will not be reordered as a result of the sort) My
> expectation of "equals" was .equals(), not return value == 0.
>
> I was concerned that such a Comparator might reorder valid H2 suites
> from what was passed in. Thankfully, that's not the case, so I've added
> this Comparator. There is a warning now about "consistency with
> equals()", as the Strings obvioulsy won't be equals() and thus sorted
> sets/maps just won't work. (See the Comparator pages for further
> discussion.)
It might be not customers expected behavior to re-order/sort their
preference of cipher suites or preference.
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.
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.
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, strong_cipher_site}
HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order
cipher suites.
One concern may be that, the customer is not intent to negotiate HTTP2
blacklisted cipher suite. The customer just don't know which are the
strong cipher suites among many cipher suites. I think we may need a
handy tool to order the cipher suites before configuration.
// there are a few cipher suites are available
String[] cipherSuites = ... // a array of cipher suites.
// Q: Don't know the strength of them
// A: OK, there is a handy tool
cipherSuites = cipherSuiteReorder.sort(cipherSuites);
// configure the cipher suites
SSLParameters.setCipherSuites(cipherSuites);
The order also apply to the normally cipher suites configuration, not
only to application protocols. The re-order should be called by
customers explicitly. JSSE would better not sort them automatically.
I think, the handy sort tool cannot be simply bind to application
protocol. For example, HTTP2 has a blacklisted cipher suites. OK,
ApplicationProtocol.H2BLACKLISTCOMPARATOR is expected to make the sort.
If, in the future, a new application protocol (AP_NEW) has a different
blacklist cipher suites, a new
ApplicationProtocol.APNEWBLACKLISTCOMPARATOR would be defined. If both
{HTTP2, AP_NEW} would be requested, which comparator for the sorting
would be used? None of them can sort the cipher suite properly. The
comparator des
