Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

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 protocol. What happens if corner cases happen that the security is not sufficient (client

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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 >

Re: TLS ALPN Proposal v5

-Original Message- From: Xuelei Fan <xuelei@oracle.com> To: Simone Bordet <sbor...@webtide.com> Cc: OpenJDK Dev list <security-...@openjdk.java.net>, "net-dev@openjdk.java.net >> OpenJDK Network Dev list" <net-dev@openjdk.java.net> Sent: Fr.,

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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}. >>

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

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

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

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

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.

Re: TLS ALPN Proposal v5

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

Re: TLS ALPN Proposal v5

> 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

Re: TLS ALPN Proposal v5

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

TLS ALPN Proposal v5

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