Hi Brad, thanks for replying; comments are inline:
On 09/28/2015 08:40 PM, Bradford Wetmore wrote:
Several comments about David's proposal:
1. Only the initial ClientHellos are parsable.
===
The biggest problem I have with an Explorer-based design i
Several comments about David's proposal:
1. Only the initial ClientHellos are parsable.
===
The biggest problem I have with an Explorer-based design is that only
the initial ClientHello on a connection is passed in the clear.
Subsequent negotiations
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,
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
>
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 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
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
-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
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
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
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.
Wo
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 kee
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
comparat
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 b
> 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
Hi,
On Sat, Sep 19, 2015 at 7:15 AM, Bradford Wetmore
wrote:
> Here is the new webrev:
>
> http://cr.openjdk.java.net/~wetmore/8051498/webrev.12/
>
> Unless there are major objections, we need to get ALPN into JDK very soon to
> make JDK 9. We can still tweak the APIs if something is found l
Hi all,
On 9/7/2015 7:18 AM, Simone Bordet wrote:
On Mon, Sep 7, 2015 at 5:54 AM, Bradford Wetmore
wrote:
In general, if the ciphersuites aren't ordered properly, that should be
considered a configuration error on the part of the application(s). However,
this dynamic ALPN selection approach
40 matches
Mail list logo
