On Sat, Oct 3, 2015 at 2:19 AM, Bradford Wetmore
wrote:
Thanks for the comments everyone. I'm submitting the following to the CCC
(internal review board):
http://cr.openjdk.java.net/~wetmore/8051498/webrev.17/
Changes:
1. No H2 Blacklist/Comparator
2. set/getApplicationProtocols()
Bradford,
On Sat, Oct 3, 2015 at 2:19 AM, Bradford Wetmore
wrote:
> Thanks for the comments everyone. I'm submitting the following to the CCC
> (internal review board):
>
> http://cr.openjdk.java.net/~wetmore/8051498/webrev.17/
>
> Changes:
>
> 1. No H2 Blacklist/Comparator
>
> 2. set/getA
I didn't reply on this last week, but this looks workable to me. Thanks!
On 10/02/2015 07:19 PM, Bradford Wetmore wrote:
On 10/1/2015 7:35 PM, Xuelei Fan wrote:
On 10/2/2015 9:03 AM, Bradford Wetmore wrote:
Major changes:
1. ApplicationProtocols is gone. The H2 black list and comparator
Thanks!
Xuelei
On 10/3/2015 8:19 AM, Bradford Wetmore wrote:
>
>
> On 10/1/2015 7:35 PM, Xuelei Fan wrote:
>> On 10/2/2015 9:03 AM, Bradford Wetmore wrote:
>>> Major changes:
>>>
>>> 1. ApplicationProtocols is gone. The H2 black list and comparator were
>>> moved to StandardConstants.
>>>
>>>
On 10/1/2015 7:35 PM, Xuelei Fan wrote:
On 10/2/2015 9:03 AM, Bradford Wetmore wrote:
Major changes:
1. ApplicationProtocols is gone. The H2 black list and comparator were
moved to StandardConstants.
2. StandardConstants. Strings for "h2" and "http/1.1" are back. And
now that you are pa
On 10/2/2015 9:03 AM, Bradford Wetmore wrote:
> Major changes:
>
> 1. ApplicationProtocols is gone. The H2 black list and comparator were
> moved to StandardConstants.
>
> 2. StandardConstants. Strings for "h2" and "http/1.1" are back. And
> now that you are parsing the raw network bytes, I
You guys (David/Simone/Bernd/Jason) are more on the front lines in
server development and how functional this API will be, so I'll trust
your judgement here. If you are ok with:
1. potentially being blind during renegotiations in the existing
TLSv1/v1.1/v1.2, and,
2. not having an SSLExpl
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 Sep 25, 2015, at 3:22 PM, David M. Lloyd wrote:
>
> 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
etwork Dev list"
Sent: Sa., 26 Sep. 2015 3:19
Subject: Re: TLS ALPN Proposal v5
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
prot
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
>
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 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
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: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 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
-Original Message-
From: Xuelei Fan
To: Simone Bordet
Cc: OpenJDK Dev list , "net-...@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
Hi,
On Mon, Sep 7, 2015 at 5:54 AM, Bradford Wetmore
wrote:
> IMHO, the following works well. I've added a new method that contains the
> ordered list of ciphersuites still to be tried which is a hint for ALPNinboked
> selection, but we delay the actual ciphersuite selection until after the
> AL
Hi all,
Simone/Xuelei/I wrote:
Per my understanding, application protocol should be negotiated before
>>>cipher suite and protocol version negotiated.
>>
>>This is not possible for HTTP/2.
>>Application protocol negotiation MUST happen*after* the TLS protocol
>>and the TLS cipher are negotiat
Hi,
On Fri, Jul 24, 2015 at 9:38 PM, Jason Greene wrote:
> The truth is that there is a gap between the current capabilities of TLS
> stacks and what the specs are trying to achieve. Ultimately the desired
> semantic the specs are trying to achieve is that every ALPN protocol can have
> its ow
Am Fri, 24 Jul 2015 14:38:36 -0500
schrieb Jason Greene :
> The truth is that there is a gap between the current capabilities of
> TLS stacks and what the specs are trying to achieve. Ultimately the
> desired semantic the specs are trying to achieve is that every ALPN
> protocol can have its own TL
> On Jul 9, 2015, at 12:02 PM, Bradford Wetmore oracle.com> wrote:
>
> Ok, I'll check with the HTTP/2 group tomorrow. It appears the proper
> list is:
Hi Brad,
Your post to the H2 group got my attention, so I thought as a user of JSSE for
an H2 implementation I should reply additionally he
Ok, I'll check with the HTTP/2 group tomorrow. It appears the proper
list is:
ietf-http...@w3.org
Is that correct?
Brad
On 7/9/2015 8:29 AM, Simone Bordet wrote:
Hi,
On Thu, Jul 9, 2015 at 1:42 AM, Bradford Wetmore
wrote:
SSLParameters is a configuration class which is used to conf
Hi,
On Thu, Jul 9, 2015 at 1:42 AM, Bradford Wetmore
wrote:
> SSLParameters is a configuration class which is used to configure
> SSLSockets/SSLEngines. SSLSession/ExtendedSSLSession is a class which holds
> negotiated Session values. getReceivedApplicationProtocols() represents the
> Applicati
On 7/9/2015 7:42 AM, Bradford Wetmore wrote:
> Xuelei/Simone wrote:
>>> Per my understanding, application protocol should be negotiated before
>>> cipher suite and protocol version negotiated.
>>
>> This is not possible for HTTP/2.
>> Application protocol negotiation MUST happen *after* the TLS pro
Greetings,
Xuelei wrote:
> I think Brad would consider our information for his design.
I did, and thanks for the all of the detailed discussion,
Simone/Michael/Xuelei. I've taken into account the feedback from the
previous discussion back in June. Here is v3 of the public ALPN API.
ht
On 6/5/2015 11:16 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Jun 5, 2015 at 4:46 PM, Xuelei Fan wrote:
>> If H2 is not supported, SPDY/3.1 would be attempted, of SPDY/3.1 is not
>> supported HTTP/1.1 would be attempted.
>
> Correct.
>
>> If H2 is supported in both side,
>> but H2 does not work,
Hi,
On Fri, Jun 5, 2015 at 4:46 PM, Xuelei Fan wrote:
> If H2 is not supported, SPDY/3.1 would be attempted, of SPDY/3.1 is not
> supported HTTP/1.1 would be attempted.
Correct.
> If H2 is supported in both side,
> but H2 does not work, it is a H2 problem that need to be addressed in H2
> layer
On 6/5/2015 10:11 PM, Simone Bordet wrote:
> On Fri, Jun 5, 2015 at 2:36 PM, Xuelei Fan wrote:
>> > See more inlines, please.
>> >
>> > Please help on one question I'm not sure of. Per HTTP/2 specification,
>> > Does H2 server allow fallback to HTTP/1.1 if client requests a HTTP/2
>> > connection
Hi,
On Fri, Jun 5, 2015 at 2:36 PM, Xuelei Fan wrote:
> See more inlines, please.
>
> Please help on one question I'm not sure of. Per HTTP/2 specification,
> Does H2 server allow fallback to HTTP/1.1 if client requests a HTTP/2
> connection? I did not find the answer from RFC 7540.
Yes.
The i
See more inlines, please.
Please help on one question I'm not sure of. Per HTTP/2 specification,
Does H2 server allow fallback to HTTP/1.1 if client requests a HTTP/2
connection? I did not find the answer from RFC 7540.
In TLS, if client requests to negotiate TLS v1.2, and server supports
TLS 1
I've just noticed the SSLParameters.setUseCipherSuitesOrder() method.
I guess this can be used to enforce a higher priority for the h2
compatible ciphers
on the server side.
On the new API, I'm not sure about the SSLBase, SSLFunction construct
either.
I don't think it is very clear, and if its
Hi,
On Fri, Jun 5, 2015 at 6:11 AM, Xuelei Fan wrote:
> I think it should be true that if a server can negotiate h2, the server
> MUST support H2 and the enabled cipher suites MUST contains at least one
> H2 required cipher suite. Otherwise, it's bug in server side.
>
> It's instinctive that if
On 6/5/2015 8:37 AM, Bradford Wetmore wrote:
>> I'd like to use:
>>
>> - * Gets the application protocol value(s) received from the peer
>> - * for this connection.
>> + * Gets a {@link List} of requested application protocol value(s)
>> + * for this connection.
>
> I've never seen a link insi
Hi,
See inlines, please.
On 6/5/2015 5:30 AM, Simone Bordet wrote:
> Hi,
>
> On Thu, Jun 4, 2015 at 6:50 PM, Xuelei Fan wrote:
>> Hm, I see your point now. But I may not agree with your ALPN "MUST
>> happen after" protocol/cipher suite negotiation conclusion.
>>
>> I parse this section as, a H
On 6/2/2015 11:23 PM, Xuelei Fan wrote:
src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java
=
List getReceivedApplicationProtocols()
--
C1. It might be useful to know the cl
Hi,
On Thu, Jun 4, 2015 at 6:50 PM, Xuelei Fan wrote:
> Hm, I see your point now. But I may not agree with your ALPN "MUST
> happen after" protocol/cipher suite negotiation conclusion.
>
> I parse this section as, a H2 server must be strong enough(comply to
> RFC7540), and a H2 client must also
On 6/5/2015 12:12 AM, Simone Bordet wrote:
> Hi,
>
> On Thu, Jun 4, 2015 at 5:53 PM, Xuelei Fan wrote:
>> On 6/4/2015 8:19 PM, Simone Bordet wrote:
>>> This is not possible for HTTP/2.
>>> Application protocol negotiation MUST happen *after* the TLS protocol
>>> and the TLS cipher are negotiated.
Hi,
On Thu, Jun 4, 2015 at 5:53 PM, Xuelei Fan wrote:
> On 6/4/2015 8:19 PM, Simone Bordet wrote:
>> This is not possible for HTTP/2.
>> Application protocol negotiation MUST happen *after* the TLS protocol
>> and the TLS cipher are negotiated.
>>
> Why? Is it a spec of HTTP/2? It is a point I d
On 04/06/15 15:18, Simone Bordet wrote:
Hi,
On Thu, Jun 4, 2015 at 3:08 PM, Michael McMahon
wrote:
On 04/06/15 13:19, Simone Bordet wrote:
Hi,
On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote:
Per section 4, RFC 7301:
"... The
"application_layer_protocol_negotiation" ServerHello e
On 6/4/2015 8:19 PM, Simone Bordet wrote:
> Hi,
>
> On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote:
>> Per section 4, RFC 7301:
>> "... The
>>"application_layer_protocol_negotiation" ServerHello extension is
>>intended to be definitive for the connection (until the connection is
>>
Hi,
On Thu, Jun 4, 2015 at 3:08 PM, Michael McMahon
wrote:
> On 04/06/15 13:19, Simone Bordet wrote:
>>
>> Hi,
>>
>> On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote:
>>>
>>> Per section 4, RFC 7301:
>>>"... The
>>> "application_layer_protocol_negotiation" ServerHello extension is
>>>
On 04/06/15 13:19, Simone Bordet wrote:
Hi,
On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote:
Per section 4, RFC 7301:
"... The
"application_layer_protocol_negotiation" ServerHello extension is
intended to be definitive for the connection (until the connection is
renegotiated) a
Hi,
On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan wrote:
> Per section 4, RFC 7301:
> "... The
>"application_layer_protocol_negotiation" ServerHello extension is
>intended to be definitive for the connection (until the connection is
>renegotiated) and is sent in plaintext to permit net
Hi,
On Wed, Jun 3, 2015 at 2:56 AM, Bradford Wetmore
wrote:
> Hi,
>
> I have just posted the second iteration of the ALPN proposal which hopefully
> addresses all of the comments raised here. It is in javadoc format, but
> things can certainly be adjusted:
>
> http://cr.openjdk.java.net/~wet
src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java
=
List getReceivedApplicationProtocols()
--
C1. It might be useful to know the client requested application
protocols in som
Hi,
I have just posted the second iteration of the ALPN proposal which
hopefully addresses all of the comments raised here. It is in javadoc
format, but things can certainly be adjusted:
http://cr.openjdk.java.net/~wetmore/8051498/webrev.00/
Please see the archive [1] for previous desig
Simone,
I'm sorry for the delay in responding, I've been getting familiar with
lambdas the last couple days, and how we might be able to apply it to
the ALPNSelector code. Interesting stuff.
To the question in this email. I'll leave the previous discussion for
context. See my responses i
Hi,
On Tue, May 26, 2015 at 8:46 PM, Bradford Wetmore
wrote:
>> I am not sure I follow this. Can you please sketch the steps/algorithm
>> that will be done in your proposed solution ?
>
> I'm assuming you are talking about 1a and not 1b.
>
> Sure, most of the heavy lifting takes place in ServerHa
> I am not sure I follow this. Can you please sketch the steps/algorithm
> that will be done in your proposed solution ?
I'm assuming you are talking about 1a and not 1b.
Sure, most of the heavy lifting takes place in ServerHandshaker.
ServerHandshaker.java
=
In the SunJSSE
Hi,
On Tue, May 26, 2015 at 2:30 AM, Bradford Wetmore
wrote:
> Darn those Chicken/Eggs [1]!
>
> Yes, you are correct. The steps for the current server code:
>
> 1. The ClientHello is parsed, and the SNI matcher callback is called. It
> does not return which value was matched in the ServerHello,
Darn those Chicken/Eggs [1]!
Yes, you are correct. The steps for the current server code:
1. The ClientHello is parsed, and the SNI matcher callback is called.
It does not return which value was matched in the ServerHello, just
whether a SNI name was matched or not:
The "extension_data
On 5/22/2015 8:28 PM, Weijun Wang wrote:
On 5/23/2015 9:13 AM, Bradford Wetmore wrote:
Weijun wrote:
> But in the RFC the name is in uppercase and chars in string are all
> lowercases.
> ...deleted...
> - Compare with equalsIgnoreCase()
Not following here, the spec is specific about th
Hi,
On Mon, May 25, 2015 at 3:57 PM, Michael McMahon
wrote:
> Perhaps, though it seems there are specific ALPNs for HTTP/1.1 ("http/1.1")
> and for HTTP/2 ("h2"). So, I think you would use ALPN itself to do that
> negotiation.
> An incoming TLS connection without the ALPN extension is just assume
On 25/05/15 12:34, Simone Bordet wrote:
Hi,
On Mon, May 25, 2015 at 12:08 PM, Michael McMahon
wrote:
Hi Brad,
A couple of initial comments/questions.
1) Certificate selection is one feature envisaged by ALPN. ie a client or a
server
ought to be able to choose a different certificate dep
Hi,
On Mon, May 25, 2015 at 12:08 PM, Michael McMahon
wrote:
> Hi Brad,
>
> A couple of initial comments/questions.
>
> 1) Certificate selection is one feature envisaged by ALPN. ie a client or a
> server
> ought to be able to choose a different certificate depending on the
> application name
Hi Brad,
A couple of initial comments/questions.
1) Certificate selection is one feature envisaged by ALPN. ie a client
or a server
ought to be able to choose a different certificate depending on the
application name
that gets negotiated. Is that possible with this API?
2) The notion
Hi,
On Sat, May 23, 2015 at 3:13 AM, Bradford Wetmore
wrote:
> Thanks for the thorough reviews and comments, I really appreciate it and
> always learn something. FunctionalInterface (@since 1.8) is something I
> haven't really explored yet, so off to the books.
Just to be clear, this is what I
On 5/23/2015 9:13 AM, Bradford Wetmore wrote:
Weijun wrote:
> But in the RFC the name is in uppercase and chars in string are all
> lowercases.
> ...deleted...
> - Compare with equalsIgnoreCase()
Not following here, the spec is specific about the over-the-wire byte
values, and http/1.1 !=
Thanks for the thorough reviews and comments, I really appreciate it and
always learn something. FunctionalInterface (@since 1.8) is something I
haven't really explored yet, so off to the books.
I'm glad this ALPN approach seems worth pursing. I have several
different comments I'll combine i
On 5/23/2015 3:20 AM, Simone Bordet wrote:
Hi,
On Fri, May 22, 2015 at 9:14 PM, Bernd Eckenfels wrote:
I would suggest to make this encoded in latin1 instead. This is
supposed to be a 8bit clean encoding (and will be compatible to all
ASCII only strings). It is still ugly and needs to be doc
Hi,
On Fri, May 22, 2015 at 9:14 PM, Bernd Eckenfels wrote:
> I would suggest to make this encoded in latin1 instead. This is
> supposed to be a 8bit clean encoding (and will be compatible to all
> ASCII only strings). It is still ugly and needs to be documanted
> cleanly that the string you get
Hi,
On Fri, May 22, 2015 at 8:54 PM, Sean Mullan wrote:
> There's actually a bunch of methods in common, so one possibility is to
> create a new interface containing the common methods (say SSLBase for now
> for lack of a better name). Then you could change SSLEngine and SSLSocket to
> implement
> > There was also some internal discussion about whether the values
> > should be Strings or byte arrays. The ALPN RFC only discusses
> > bytes, and a String.toBytes("US-ASCII") would limit the API to
> > ASCII strings.
> >
> > Lastly, we could also add some convenience values for well-known
> >
On 05/22/2015 12:12 PM, Simone Bordet wrote:
Would be great if we could make this class a FunctionalInterface
Yes, that would be nice.
, but
I guess it's not easy due to lack of commonality between SSLSocket and
SSLEngine.
Unless there is a way to abstract something out of those 2:)
There's
Hi,
On Fri, May 22, 2015 at 2:55 AM, Bradford Wetmore
wrote:
> This is a fork of the previous thread:
>
> Subject: TLS Handshake Message Proposal
> (Was: Re: JEP 244: TLS Application-Layer Protocol
> Negotiation Extension)
>
> I broke this thread off to keep this
This is a fork of the previous thread:
Subject: TLS Handshake Message Proposal
(Was: Re: JEP 244: TLS Application-Layer Protocol
Negotiation Extension)
I broke this thread off to keep this proposal discussion together, but
if you're interested in the history, pl
97 matches
Mail list logo
