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 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
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,
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
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 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 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 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 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
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
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,
JDK-806769 doesn't exist, can you double-check what issue you think
caused this? Looks like you are missing a digit.
Thanks,
Sean
On 9/24/15 10:46 PM, David Black wrote:
As I do not have an account on https://bugs.openjdk.java.net, yes I have
submitted a standard oracle java bug report, I thou
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
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
Looks fine.
--Sean
On 9/25/15 1:27 AM, Amanda Jiang wrote:
Hi Sean,
Thanks for reviewing this, new comments has been addressed, please
check the webrev below:
http://cr.openjdk.java.net/~amjiang/8050402/webrev.03/
Thanks,
Amanda
On 9/24/15, 12:21 PM, Sean Mullan wrote:
Hi Amanda,
Just a c
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
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
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
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/
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
>
SecurityPermission:
Change "login, logout" to "login and logout"
All files:
Use "@since 9" instead of "1.9"
Looks good otherwise.
--Sean
On 9/24/15 10:28 PM, Valerie Peng wrote:
Sure, the webrev is updated below with your comments and Joe's
suggestion of adding a query API for provider con
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
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 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
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 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
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
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
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 Sean,
Thanks!
Webrev updated: http://cr.openjdk.java.net/~valeriep/8130648/webrev.02
CCC updated: http://ccc.us.oracle.com/8130648
I will finalize CCC after your review.
Thanks & have a great weekend~
Valerie
On 9/25/2015 8:44 AM, Sean Mullan wrote:
SecurityPermission:
Change "login, logou
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
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
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
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
35 matches
Mail list logo
