On 9/26/2015 8:47 AM, Bradford Wetmore wrote:
>> It might be not customers expected behavior to re-order/sort their
>> preference of cipher suites or preference.
>
> Are we are clear that the intention was never for the JDK to internally
> resort the ciphersuites, but rather to provide an external
On 9/26/2015 8:47 AM, Bradford Wetmore wrote:
>> {TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}
>
> BTW, in case anyone was wondering, both of these suites are on the RFC
> 7540 blacklist.
Ooops, I meant to use "TLS_ECDHE_" as HTTP2 non-blacklisted cipher suite.
Xuelei
I would second David's proposal based on the #1/#A ideas.
Here are some background and options.
1. a HTTP2 server should support HTTP2
If a HTTP2 server declare to support HTTP2, it should support HTTP2
protocol. What happens if corner cases happen that the security is not
sufficient (client requ
You guys certainly were prolific in your discussions last night. ;)
Many comments to touch on, and I definitely won't have time today to
respond to everything.
Xuelei wrote:
> I don't think we really need to re-order the cipher suites.
Simone wrote:
> Of course you need to re-order in this
On 09/25/2015 02:11 PM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd wrote:
The application protocol implementation chooses only valid cipher suites for
the protocol. Why would it choose one that is not valid, considering that
the protocol implementation itself is
Hi Michael
Maybe these have been fixed in the meantime, but I think I've found a bug:
in
http://cr.openjdk.java.net/~michaelm/8087112/01/src/java.base/share/classes/sun/net/httpclient/Utils.java.html
single quotes must be accepted, while parentheses must be rejected [1]
and a few typos:
in
ht
Hi,
On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd wrote:
> The application protocol implementation chooses only valid cipher suites for
> the protocol. Why would it choose one that is not valid, considering that
> the protocol implementation itself is the only thing that "knows" what is
> vali
Here are some solid reasons that this is the best possible approach:
* It will work for 100% of foreseeable use cases - i.e. there is 0% risk
of permanently baking in flawed logic into the API
* It is dead simple - only one new method on SSLSocket/SSLEngine to set
the protocol list (client) or
On 09/25/2015 12:13 PM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 6:49 PM, David M. Lloyd wrote:
A: receive raw SSL packet on Socket or SocketChannel
A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info
This requires the application to write a TLS parser. This is currently
Hi,
On Fri, Sep 25, 2015 at 6:49 PM, David M. Lloyd wrote:
> A: receive raw SSL packet on Socket or SocketChannel
> A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info
This requires the application to write a TLS parser. This is currently
not necessary, nor provided.
You think this
On 09/25/2015 11:37 AM, Simone Bordet wrote:
David,
sorry, but I don't understand your proposal.
Can you please write it down in pseudo code what a server application
should do and what the JDK should do to negotiate HTTP/2 with a client
?
Sure.
A: receive raw SSL packet on Socket or SocketC
David,
sorry, but I don't understand your proposal.
Can you please write it down in pseudo code what a server application
should do and what the JDK should do to negotiate HTTP/2 with a client
?
I don't see how it is even possible for a user to decide anything
*before* the handshaking is even in
On 09/25/2015 10:13 AM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 4:48 PM, David M. Lloyd wrote:
Yes, you would have to add a method - *one* method - to SSLSocket/SSLEngine
to specify the selected protocol; this would be done during setup before you
initiate handshake (which is why you
Hi,
On Fri, Sep 25, 2015 at 4:48 PM, David M. Lloyd wrote:
> Yes, you would have to add a method - *one* method - to SSLSocket/SSLEngine
> to specify the selected protocol; this would be done during setup before you
> initiate handshake (which is why you need to explore the Hello packet in the
>
On 9/25/2015 10:28 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 4:19 PM, Xuelei Fan wrote:
>> Actually, it was a puzzle to me: whether a concrete server can support
>> both HTTP/2 and HTTP/1.1, or not. If HTTP/2 mode of the server does not
>> work, is it OK to fall-over to use HTTP/
CC security-dev.
On 9/25/2015 9:14 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 2:46 PM, David M. Lloyd
> wrote:
>> Well, SNI already basically works this way, so it's not so great a stretch.
>
> I don't follow ?
> SNI has APIs in JDK 8, you don't use SSLExplorer at all.
>
> Als
On 9/25/2015 10:20 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 3:20 PM, Xuelei Fan wrote:
>> For the complication, I posted the comments in previous mail here:
>>
>> -
>>> In case you have [HTTP/2, AP_NEW, HTTP/1.1], then you can simply
>>> compose the c
Sorry I didn't get the reply from Simone Bordet - it must have gone to
only one of the two lists (which I'm not on).
On 9/25/2015 9:14 PM, Simone Bordet wrote:
I don't follow ?
SNI has APIs in JDK 8, you don't use SSLExplorer at all.
They're highly limited; you can only tell the socket/engine
Hi,
On Fri, Sep 25, 2015 at 4:19 PM, Xuelei Fan wrote:
> Actually, it was a puzzle to me: whether a concrete server can support
> both HTTP/2 and HTTP/1.1, or not. If HTTP/2 mode of the server does not
> work, is it OK to fall-over to use HTTP/1.1 mode? I did not get the
> answer from the HTTP/2
Hi,
On Fri, Sep 25, 2015 at 3:20 PM, Xuelei Fan wrote:
> For the complication, I posted the comments in previous mail here:
>
> -
>> In case you have [HTTP/2, AP_NEW, HTTP/1.1], then you can simply
>> compose the comparators to sort first with the H2.CIPHER_COMPARATOR,
On 9/25/2015 9:14 PM, Simone Bordet wrote:
> On Fri, Sep 25, 2015 at 2:46 PM, David M. Lloyd
> wrote:
>> > Well, SNI already basically works this way, so it's not so great a stretch.
> I don't follow ?
> SNI has APIs in JDK 8, you don't use SSLExplorer at all.
There are two typical cases for SNI
On 9/25/2015 8:48 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 2:26 PM, Xuelei Fan wrote:
>> Maybe, we are not on the same page, I think.
>
> We are.
>
>> I think a general cipher strength comparator is sufficient for HTTP/2
>> preference too. What do you think?
>
> I don't know
Hi,
On Fri, Sep 25, 2015 at 2:46 PM, David M. Lloyd wrote:
> Well, SNI already basically works this way, so it's not so great a stretch.
I don't follow ?
SNI has APIs in JDK 8, you don't use SSLExplorer at all.
Also, SNI is a client-to-server information only, while with ALPN you
have to reply
Good point. I'll remove that pre-push.
-Rob
On 25/09/15 11:57, Mark Sheppard wrote:
Hi Rob,
looks fine ... the "him" variable in the
Java_java_net_Inet4AddressImpl_isReachable0
would appear not to be used now, so could probably be removed with its
call on memset ?
regards
Mark
Hi,
On Fri, Sep 25, 2015 at 2:26 PM, Xuelei Fan wrote:
> Maybe, we are not on the same page, I think.
We are.
> I think a general cipher strength comparator is sufficient for HTTP/2
> preference too. What do you think?
I don't know if all the blacklisted ciphers are actually lower
strength of
On 09/25/2015 07:29 AM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 2:15 PM, David M. Lloyd wrote:
...why does sorting even matter? Why should selection not be implemented
100% in user code, based on both the cipher suites list and application
protocol, rendering this whole discussion po
Hi,
On Fri, Sep 25, 2015 at 2:15 PM, David M. Lloyd wrote:
> ...why does sorting even matter? Why should selection not be implemented
> 100% in user code, based on both the cipher suites list and application
> protocol, rendering this whole discussion pointless? It's clearly a complex
> enough
On 9/25/2015 7:42 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 11:47 AM, Xuelei Fan wrote:
>> 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,
Hi,
On Fri, Sep 25, 2015 at 1:54 PM, wrote:
> Hello,
>
> Just want to mention that with explicite http/https URLs users and
> applications are somewhat used to select the application protocol first.
Well, kind of :)
Some time ago, and still now, if you put "https" in a URL, you are
actually ta
On 09/25/2015 06:42 AM, Simone Bordet wrote:
Hi,
On Fri, Sep 25, 2015 at 11:47 AM, Xuelei Fan wrote:
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, applicati
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 basi
Hi,
On Fri, Sep 25, 2015 at 11:47 AM, Xuelei Fan wrote:
> 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 fir
New to ALPN and this thread, just my $0.02.
On 09/25/2015 05:47 PM, Xuelei Fan wrote:
Here is the question to answer, which preference should be respected
firstly between cipher suite and application protocol?
No concrete answer, but I think it's always better to "first respect
what the user
Hi Rob,
looks fine ... the "him" variable in the
Java_java_net_Inet4AddressImpl_isReachable0
would appear not to be used now, so could probably be removed with its
call on memset ?
regards
Mark
On 24/09/2015 15:45, Rob McKenna wrote:
Please ignore the formatting errors. Thats either a
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_1
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 HTT
36 matches
Mail list logo
