Re: TLS ALPN Proposal v2
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 inside an opening sentence. I have seen @code,
> but there's only 6 in the entire java namespace.
Better to use @code.
Xuelei
Re: TLS ALPN Proposal v2
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 H2 server must be strong enough(comply to >> RFC7540), and a H2 client must also be strong enough (comply to >> RFC7540). Otherwise, both side may terminated the connection, and >> cannot declare as complying to H2. It is not necessary for an >> application protocol selector to detect whether a H2 server/client >> comply to H2 or not. >> >> If "H2" is requested, it means that the client supports H2. Otherwise, >> it's a client application bug. > > Not that simple, see below. > >> If "H2" is selected by a selected, it >> means that the selected server supports H2. Otherwise, it is a selector >> implementation bug. If something wrong in either client or server, it >> is expected to terminate the connection immediately, rather than >> downgrade to a not-strong enough level. >> >> From the points above, I think an application protocol selector may not >> need to know the negotiated protocol version and cipher suite. > > No. > > The client may send ciphers that are valid for http/1.1 (but invalid > for h2), along with ciphers that are good for h2 (as well as http/1.1 > of course), plus the list of protocols it supports. > The client has no idea what the server supports. > I think it should be true that if a client requests h2, the client MUST support H2 and the requested cipher suites MUST contains at least one H2 required cipher suite. Otherwise, it's bug in client side. > When the server sees that the client supports h2, it MUST pick a > cipher that is valid for h2. > Alternatively, the ciphers on the server are sorted so that those > valid for h2 have higher priority (they are attempted before all the > others), so that there is a high chance that a h2 valid cipher is > chosen (but no guarantee) before choosing the application protocol. > When the application protocol selector callback is invoked, it can > only pick h2 IFF the cipher is h2 valid, otherwise it has to fallback > to http/1.1. > 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 a server support h2, and then the application protocol selector would select h2. If the server declare to support h2, but no suitable cipher suites, it may be a server bug. The connection should be terminated rather than downgrade to HTTP/1.1, I think. Is it possible that client only request h2_valid_cipher_a, but server only support h2_valid_cipher_b, and as would result in that there is no common cipher suites between client and server for H2? It is possible, surely. Should the connection be terminated, or fall-back to HTTP/1.1? I think connection should be terminated immediately, rather than fall-back to HTTP/1.1. Per page 68, section 9.2.2, RFC 7540, there is an mandatory cipher suite (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) MUST be supported in both client and server. If there is no common cipher suites between client and server for H2, it is actually a bad deployments, and the connection should be terminated rather than fall-back to HTTP/1.1. Version downgrading is not a safe behavior, I think. > With your reasoning, the client can send [h2_invalid_cipher, > h2_valid_cipher], the server may pick h2_invalid_cipher, then the > application protocol selector is invoked, which will only look at the > protocols, pick h2 since it's supported by client and server, and now > you have an invalid connection: the h2 protocol with > h2_invalid_cipher. > That's an interesting case. The question actually is: between requested application protocols and cipher suites, which preference should be respected at first. Because it is a application requirement that a certain cipher suite is not suitable to H2, I think requested application protocols should be respected at first. My scenarios look like: 1. client sends [h2_invalid_cipher, h2_valid_cipher] and h2/http/1.1 application protocol. 2. server selects h2 (we need an API for the selection). 3. server selects h2_valid_cipher because of h2 is selected previously (may need an API for the selection). In #1, if there is no h2_valid_cipher requested, it is a bug in client side. In #3, if there is no h2_valid_cipher that can be negotiated, it is a bug in server side, or the client does not enabled the mandatory cipher suite (a bug in client). > We have been through these issues for months in the RFC 7540 expert > group, and the outcome is that protocol selection, for h2, depends on > the cipher. > We have also been through a number of scenarios where both the client > and the server send h2 valid ciphers, but their intersection is empty > (
Re: TLS ALPN Proposal v2
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 client requested application
protocols in some circumstance. Better to set the application protocols
in client side either.
For ALPN, the client supplies the list, the server chooses. For NPN,
the server supplies the list, the client chooses. So it's a list of
received (requested) protocols. I've changed it for now, not a big deal
to me.
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 inside an opening sentence. I have seen @code,
but there's only 6 in the entire java namespace. The
-public List getReceivedApplicationProtocols() {
+public List getRequesedApplicationProtocols() {
I'll assume that was supposed to be requested. :)
C2. The return value would better to be immutable, and better to
describe the preference per RFC 7301. Maybe looks like:
-* @return the non-null list of application protocol names
+* @return the non-null immutable list of application protocol
+* names, in descending order of preference. The returned
+* list may be empty if no application protocols were
+* requested.
Done.
src/java.base/share/classes/javax/net/ssl/SSLParameters.java
List getApplicationProtocols()
--
C3. Better to indicate explicitly that this method only apply to client
mode.
See above.
C4. The method description is not instinctive enough for an application
developer. Can we use words to indicate the purpose of the setting?
For example:
- * Gets the list of application-level protocol names that could
- * be sent to the SSL/TLS peer.
+ * Gets the {@link List} of application layer protocol names that
+ * can be negotiated over SSL/TLS/DTLS protocols.
Changed, except for the @link.
C5. Prefer to use immutable return value:
- * @return a non-null list of application protocol names.
+ * @return a non-null immutable list of application protocol names.
Changed.
C6. Nice to have a link for the standard protocol names.
I wasn't planning on having a list of standard protocol names.
See below.
void setApplicationProtocols(List protocols)
C7. see C3.
C8. see C4.
Changed.
s/getApplicationProtocolSelector()
--
C9. The use of SSLFunction make the implementation of
protocol selector and JSSE provider implementation complicated.
From the spec, looks like the selector may want to know address/ports,
SSL protocol versions or the negotiated cipher suit. As would require
that before use this selector, the handshaking must negotiate the
protocol version and the cipher suite. That's a specific JSSE
implementation requirement. It does not sound like a reasonable behavior.
The implement of the selector is not straightforward, I think.
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 network elements to
provide differentiated service for the connection when the TCP or UDP
port number is not definitive for the application-layer protocol to
be used in the connection. By placing ownership of protocol
selection on the server, ALPN facilitates scenarios in which
certificate selection or connection rerouting may be based on the
negotiated protocol."
Per my understanding, application protocol should be negotiated before
cipher suite and protocol version negotiated. And the connection may be
rerouted (even to different machines) for further operation. The
requested application protocols list should be the only information for
the selection of a suitable application protocol.
Based on that, I think it is more simple to use Simone's proposal:
@FunctionalInterface
interface ApplicationProtocolSelector
{
String select(List protocols) throws SSLException;
}
Hence, no need for a SSLBase any more.
There's been a lot of discussion this morning, I'll return to this later
when I've had a chance to parse it.
public static final String AP_HTTP_1_1 = "http/1.1";
public static final String AP_H2 = "h2";
C10. I understand why the constants are defined here. However, usually,
we don't define standard names in JSSE APIs. Instead, we normally use
Oracle standard names documentation.
This is not really a Standard Name in our normal sense/usage. Usuall
Re: RFR 7191662: JCE providers should be located via ServiceLoader
Build experts, Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. Thanks, Valerie On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: Correct, if the makefile related changes are removed then no need for build team to review 7191662 webrev anymore. There are other discussions ongoing and we should be able to reach a decision in a day or two. Will update the list again. Thanks, Valerie On 06/01/15 16:39, Magnus Ihse Bursie wrote: On 2015-05-29 00:10, Valerie Peng wrote: Please find comments in line... On 5/27/2015 3:42 PM, Mandy Chung wrote: Valerie, Did you see my comment yesterday? http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html Yes, we exchanged emails after this above one. I will follow up your latest one later today. Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let’s remove the META-INF files in the first push and the build change. The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. Sure, I can remove the META-INF files so the providers are loaded through the legacyLoad(). Hmm, the ProviderLoader.load() method is used by java.security file provider loading. Since the current list still uses class name, it should take class name when checking for matches while iterating through the list returned by ServiceLoader. This way, when changes are sync'ed into Jake, no extra change required and the providers will be loaded through ProviderLoader.load() automatically with the current list. I’ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev Ok. Thanks, Valerie I'm not sure I followed completely here were this landed. Does this mean that there's currently no need for a build system code review on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a new webrev will be posted instead? /Magnus . Mandy On May 27, 2015, at 3:29 PM, Valerie Peng wrote: Hi, build experts, Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. The rest of source code changes are reviewed by my team already. Thanks, Valerie (Java Security Team)
Re: TLS ALPN Proposal v2
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 be strong enough (comply to > RFC7540). Otherwise, both side may terminated the connection, and > cannot declare as complying to H2. It is not necessary for an > application protocol selector to detect whether a H2 server/client > comply to H2 or not. > > If "H2" is requested, it means that the client supports H2. Otherwise, > it's a client application bug. Not that simple, see below. > If "H2" is selected by a selected, it > means that the selected server supports H2. Otherwise, it is a selector > implementation bug. If something wrong in either client or server, it > is expected to terminate the connection immediately, rather than > downgrade to a not-strong enough level. > > From the points above, I think an application protocol selector may not > need to know the negotiated protocol version and cipher suite. No. The client may send ciphers that are valid for http/1.1 (but invalid for h2), along with ciphers that are good for h2 (as well as http/1.1 of course), plus the list of protocols it supports. The client has no idea what the server supports. When the server sees that the client supports h2, it MUST pick a cipher that is valid for h2. Alternatively, the ciphers on the server are sorted so that those valid for h2 have higher priority (they are attempted before all the others), so that there is a high chance that a h2 valid cipher is chosen (but no guarantee) before choosing the application protocol. When the application protocol selector callback is invoked, it can only pick h2 IFF the cipher is h2 valid, otherwise it has to fallback to http/1.1. With your reasoning, the client can send [h2_invalid_cipher, h2_valid_cipher], the server may pick h2_invalid_cipher, then the application protocol selector is invoked, which will only look at the protocols, pick h2 since it's supported by client and server, and now you have an invalid connection: the h2 protocol with h2_invalid_cipher. We have been through these issues for months in the RFC 7540 expert group, and the outcome is that protocol selection, for h2, depends on the cipher. We have also been through a number of scenarios where both the client and the server send h2 valid ciphers, but their intersection is empty (this may happen when a very old client talks to a very new server, think TLS 1.2 vs TLS 1.4, or viceversa). Same outcome: to pick h2 you MUST have a h2 valid cipher in common between client and server, so application protocol selection, for h2, depends on the cipher. A bit of warning here: we are designing an API for ALPN, not for HTTP/2. The ALPN API should be flexible enough to implement *at least* HTTP/2, possibly even more complex scenarios (for example alias selection), but IMHO it should not be tied to HTTP/2. Again, I see 2 cases: either the JDK implementation picks the TLS protocol, the cipher and the alias like it does now, and then invokes the "callback" to pick the application protocol (current Jetty ALPN behavior), or the implementation must be reviewed to perform TLS protocol, cipher, alias and application protocol selection at once, with a "callback" that will be invoked possibly multiple times until it can find the right tuple to return. The latter would be the optimal solution, the former has certainly working implementations. Hope this clarified. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
RSA intrinsics [Was: RFR(L): 8069539: RSA acceleration]
I'm sorry this is a rather long email, and I pray for your patience. I'm getting close to something I can put forward for review. The performance is encouraging. [ Some background: The kernel of RSA and Diffie-Hellman key exchange is Montgomery multiplication. Optimizing RSA basically comes down to optimizing Montgomery multiplication. The core of OpenJDK's RSA is BigInteger.oddModPow(). ] My Montgomery multiply routine (mostly portable C, with a small assembly-language insert) executes a 1024-bit multiply/reduce in about 2000ns; the hand-coded assembly language equivalent in OpenSSL is faster (as you'd expect) but not very much faster: about 1700ns. In other words, compiled C is only about 20% slower. Firstly, this is pretty remarkable performance by GCC (Yay! Go GCC!) and it shows I'm on the right track. It also shows that there isn't a huge amount to be gained by hand-coding Montgomery multiplication, but anybody who fancies their hand can try to improve on GCC. This is also very nice because porting it to non-x86 hardware is fairly straightforward -- certainly far easier than writing a large assembly- language routine. Here are some numbers for comparison. Today's hs-comp: signverifysign/s verify/s rsa 512 bits 0.000133s 0.09s 7508.5 112819.1 rsa 1024 bits 0.000667s 0.28s 1498.6 35497.2 rsa 2048 bits 0.003867s 0.97s258.6 10342.7 rsa 4096 bits 0.026383s 0.000357s 37.9 2799.8 After my patch: signverifysign/s verify/s rsa 512 bits 0.71s 0.05s 14127.3 204112.4 rsa 1024 bits 0.000292s 0.13s 3424.5 74204.1 rsa 2048 bits 0.001628s 0.45s614.4 22399.7 rsa 4096 bits 0.010966s 0.000163s 91.2 6117.8 So, it's about twice as fast we have at present. [ Note that this comparison includes the latest "8081778: Use Intel x64 CPU instructions for RSA acceleration" patch. ] However, even after my patch OpenJDK is still somewhat slower than OpenSSL, which is: signverifysign/s verify/s rsa 512 bits 0.48s 0.04s 20687.1 257399.4 rsa 1024 bits 0.000189s 0.11s 5288.3 91711.5 rsa 2048 bits 0.001174s 0.37s851.7 27367.2 rsa 4096 bits 0.008475s 0.000137s118.0 7305.4 [ I am assuming that OpenSSL represents something like the "speed of light" for RSA on x86: this is carefully hand-coded assembly language and C, hand tuned. Getting anywhere near OpenSSL is a major win. ] Here's my problem: Some of this slowdown is due to the overhead of using the JCE, but not very much. Quite a lot of it, however, is due to the fact that the scratch memory used in oddModPow() is a big-endian array of jints. I have to convert the big-endian jints into native jlongs to do the multiply on little-endian x86-64. If I do the word reversal during the multiply (i.e. keep all data in memory in little-endian form, swap words when reading and writing to memory) the performance is horrible: a 1024-bit multiply takes 3000ns, 50% longer. This perhaps isn't very surprising: if you do the word-reversal before the multiplication you have O(N) swaps, if you do it during the multiplication you have O(N^2). I have found that the best thing to do is to word reverse all the data in memory into temporary little-endian arrays and do the work on them. It's much faster, but still really is very annoying: for 1024-bit RSA the word reversal is 14% of the total runtime. It would be nice to keep all of the data in an array of jlongs for the duration of oddModPow(). Here's one idea: I could write a version of oddModPow() which is guaranteed never to use the Java version of the Montgomery multiply. This would use a JNI method which calls the native Montgomery multiply routine, guaranteeing that that we always use that native routine, even from the interpreter and C1. Then I could keep all the internal state in native word order, and all this word-swapping would just go away. This would have the additional benefit that it would be faster when using the interpreter and C1. So, we'd have two versions of oddModPow() in BigInteger, and switch between them depending on whether the platform had support for a native Montgomery multiplication. The downside of having two versions of oddModPow() would, of course, be some code duplication. Or am I just making too much fuss about this? Maybe I should be happy with what I've got. Thank you for reading this far, Andrew.
Re: TLS ALPN Proposal v2
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. >>> >> Why? Is it a spec of HTTP/2? It is a point I don't understand now. >> Please help with more details. > > http://tools.ietf.org/html/rfc7540#section-9.2 > > You can only speak h2 if the cipher is strong enough as defined by RFC 7540. > 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 be strong enough (comply to RFC7540). Otherwise, both side may terminated the connection, and cannot declare as complying to H2. It is not necessary for an application protocol selector to detect whether a H2 server/client comply to H2 or not. If "H2" is requested, it means that the client supports H2. Otherwise, it's a client application bug. If "H2" is selected by a selected, it means that the selected server supports H2. Otherwise, it is a selector implementation bug. If something wrong in either client or server, it is expected to terminate the connection immediately, rather than downgrade to a not-strong enough level. >From the points above, I think an application protocol selector may not need to know the negotiated protocol version and cipher suite. Thanks, Xuelei
Re: TLS ALPN Proposal v2
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 don't understand now. > Please help with more details. http://tools.ietf.org/html/rfc7540#section-9.2 You can only speak h2 if the cipher is strong enough as defined by RFC 7540. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Re: TLS ALPN Proposal v2
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 extension is intended to be definitive for the connection (until the connection is renegotiated) and is sent in plaintext to permit network elements to provide differentiated service for the connection when the TCP or UDP port number is not definitive for the application-layer protocol to be used in the connection. By placing ownership of protocol selection on the server, ALPN facilitates scenarios in which certificate selection or connection rerouting may be based on the negotiated protocol." 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 negotiated. What do you mean by "after"? As far as TLS is concerned, all of this negotiation happens in one negotiation. The client proposes a list of ciphers and application protocols. The server chooses a cipher and application protocol and sends back its choices. Currently, IIUC, the cipher selection is an iterative process where a cipher is attempted until one is negotiated. In this process, there is no looking at the application protocol. Here we're trying to find a solution for ALPN, and either we 1) look the application protocol in this iterative process (and therefore the SSLFunction is invoked multiple times), so that TLS protocol, cipher (possibly the alias too) and application protocol are chosen together, at once (for each iteration); or 2) we separate the TLS protocol and cipher negotiation (and alias) in one step, and we perform application protocol selection afterwards. The latter is how Jetty's ALPN works, and that's what I mean with *after*. For HTTP/2 it won't work to pick the application protocol before the cipher. Either at the same time, or after. That is why I asked to specify how the mechanism worked. Okay. I've been looking at it from the client point of view, and as far as I understand it, all of the information is available to the client at the right time. The HTTP/2 RFC specifically warns against splitting this negotiation with the example that a client could propose a mandatory TLS 1.2 cipher, but which is black-listed by HTTP/2. If (internally) the server chooses that cipher first, without knowing the application protocol is going to be HTTP/2 then you end up with a non-compliant connection that will probably have to be closed for reason of insufficient security. If the server chooses a blacklisted cipher, and then "h2" as protocol, it's a non compliant server. Communication of clients with compliant (and properly configured) servers is guaranteed if the application protocol is chosen after (or at the same time of) the cipher. If I understand you correctly, you are proposing to rework the internal JDK code to perform TLS protocol, cipher, alias and application protocol in one point, which is then possibly iterated multiple times until a satisfactory tuple is selected ? I am fine with this approach too, but I guess the API will be very different from Jetty's ALPN and this current proposal (which is fine as well - does not have to be similar to Jetty's). I don't know enough about the TLS implementation to say how much work it is. Thanks ! Actually, I'm not proposing anything at this stage. But, I wonder if it might be simpler to just make all relevant information available to the existing negotiation API, rather than splitting it into separate calls - Michael.
Re: TLS ALPN Proposal v2
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 >>renegotiated) and is sent in plaintext to permit network elements to >>provide differentiated service for the connection when the TCP or UDP >>port number is not definitive for the application-layer protocol to >>be used in the connection. By placing ownership of protocol >>selection on the server, ALPN facilitates scenarios in which >>certificate selection or connection rerouting may be based on the >>negotiated protocol." >> >> 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 negotiated. > Why? Is it a spec of HTTP/2? It is a point I don't understand now. Please help with more details. >> And the connection may be >> rerouted (even to different machines) for further operation. The >> requested application protocols list should be the only information for >> the selection of a suitable application protocol. > > Not sure what you exactly mean here, Here is an example to explain the "rerouting". For example, there a four entities, an TLS client, a router, an http/2 over TLS server, and an http/1.1 over TLS server. 1. the client request a connection to the http/2 server, the TCP connection is established between the client the router at first. 2. the router analysis the ClientHello message, and reroute the connection to the http/2 server. 3. the client and http/2 server negotiate the TLS connection, including the SSL protocol and cipher suite. The router should not be able to play man-in-the-middle negotiation if it does not know the server credentials. > but you can't pick the HTTP/2 > protocol unless you have the TLS protocol and TLS cipher available. > So *only* the list of protocol sent by the client is not enough for > HTTP/2, we would need additional contextual information. > See my question above. > What a HTTP/2 aware load balancer written in Java that offloads TLS > would need to do is to negotiate the TLS protocol, negotiate the TLS > cipher, *then* negotiate the application protocol (whether "h2" or > "http/1.1"), and with the last information pick a backend server, > typically forwarding clear text bytes to the backend. > See my question above. Thanks, Xuelei
Re: TLS ALPN Proposal v2
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 >>> intended to be definitive for the connection (until the connection is >>> renegotiated) and is sent in plaintext to permit network elements to >>> provide differentiated service for the connection when the TCP or UDP >>> port number is not definitive for the application-layer protocol to >>> be used in the connection. By placing ownership of protocol >>> selection on the server, ALPN facilitates scenarios in which >>> certificate selection or connection rerouting may be based on the >>> negotiated protocol." >>> >>> 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 negotiated. > > > What do you mean by "after"? As far as TLS is concerned, all of this > negotiation happens in one negotiation. The client proposes a list of > ciphers and application protocols. The server chooses a cipher > and application protocol and sends back its choices. Currently, IIUC, the cipher selection is an iterative process where a cipher is attempted until one is negotiated. In this process, there is no looking at the application protocol. Here we're trying to find a solution for ALPN, and either we 1) look the application protocol in this iterative process (and therefore the SSLFunction is invoked multiple times), so that TLS protocol, cipher (possibly the alias too) and application protocol are chosen together, at once (for each iteration); or 2) we separate the TLS protocol and cipher negotiation (and alias) in one step, and we perform application protocol selection afterwards. The latter is how Jetty's ALPN works, and that's what I mean with *after*. For HTTP/2 it won't work to pick the application protocol before the cipher. Either at the same time, or after. That is why I asked to specify how the mechanism worked. > The HTTP/2 RFC specifically warns against splitting this negotiation > with the example that a client could propose a mandatory TLS 1.2 cipher, > but which is black-listed by HTTP/2. If (internally) the server chooses that > cipher first, > without knowing the application protocol is going to be HTTP/2 > then you end up with a non-compliant connection that will probably have > to be closed for reason of insufficient security. If the server chooses a blacklisted cipher, and then "h2" as protocol, it's a non compliant server. Communication of clients with compliant (and properly configured) servers is guaranteed if the application protocol is chosen after (or at the same time of) the cipher. If I understand you correctly, you are proposing to rework the internal JDK code to perform TLS protocol, cipher, alias and application protocol in one point, which is then possibly iterated multiple times until a satisfactory tuple is selected ? I am fine with this approach too, but I guess the API will be very different from Jetty's ALPN and this current proposal (which is fine as well - does not have to be similar to Jetty's). I don't know enough about the TLS implementation to say how much work it is. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Re: TLS ALPN Proposal v2
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) and is sent in plaintext to permit network elements to provide differentiated service for the connection when the TCP or UDP port number is not definitive for the application-layer protocol to be used in the connection. By placing ownership of protocol selection on the server, ALPN facilitates scenarios in which certificate selection or connection rerouting may be based on the negotiated protocol." 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 negotiated. What do you mean by "after"? As far as TLS is concerned, all of this negotiation happens in one negotiation. The client proposes a list of ciphers and application protocols. The server chooses a cipher and application protocol and sends back its choices. The HTTP/2 RFC specifically warns against splitting this negotiation with the example that a client could propose a mandatory TLS 1.2 cipher, but which is black-listed by HTTP/2. If (internally) the server chooses that cipher first, without knowing the application protocol is going to be HTTP/2 then you end up with a non-compliant connection that will probably have to be closed for reason of insufficient security. - Michael And the connection may be rerouted (even to different machines) for further operation. The requested application protocols list should be the only information for the selection of a suitable application protocol. Not sure what you exactly mean here, but you can't pick the HTTP/2 protocol unless you have the TLS protocol and TLS cipher available. So *only* the list of protocol sent by the client is not enough for HTTP/2, we would need additional contextual information. What a HTTP/2 aware load balancer written in Java that offloads TLS would need to do is to negotiate the TLS protocol, negotiate the TLS cipher, *then* negotiate the application protocol (whether "h2" or "http/1.1"), and with the last information pick a backend server, typically forwarding clear text bytes to the backend. Thanks !
Re: TLS ALPN Proposal v2
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 network elements to >provide differentiated service for the connection when the TCP or UDP >port number is not definitive for the application-layer protocol to >be used in the connection. By placing ownership of protocol >selection on the server, ALPN facilitates scenarios in which >certificate selection or connection rerouting may be based on the >negotiated protocol." > > 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 negotiated. > And the connection may be > rerouted (even to different machines) for further operation. The > requested application protocols list should be the only information for > the selection of a suitable application protocol. Not sure what you exactly mean here, but you can't pick the HTTP/2 protocol unless you have the TLS protocol and TLS cipher available. So *only* the list of protocol sent by the client is not enough for HTTP/2, we would need additional contextual information. What a HTTP/2 aware load balancer written in Java that offloads TLS would need to do is to negotiate the TLS protocol, negotiate the TLS cipher, *then* negotiate the application protocol (whether "h2" or "http/1.1"), and with the last information pick a backend server, typically forwarding clear text bytes to the backend. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Re: TLS ALPN Proposal v2
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/~wetmore/8051498/webrev.00/
>
> Please see the archive [1] for previous design discussion. I will be
> writing up usage examples in the next few days.
>
> The significant changes:
>
> ExtendedSSLSession
> public List getReceivedApplicationProtocols() {
>
> This will allow applications to examine which protocol names were
> sent.
This is a constant once the application protocols are received, so it
can be surely retrieved from SSLParameters.
I don't understand why it is replicated here ?
> SSLParameters
> mentions both ALPN/NPN as possible protocols. I removed the
> discussion about "server" and "client" since ALPN/NPN essentially
> reverse the roles.
>
> mentions "appropriate character sets" for String-byte[] conversions
> such as UTF-8 for ALPN.
>
> The application protocol selector is now a @FunctionalInterface
> (i.e. lambda-ready) called SSLFunction. It is to throw an
> SSLException if no values are supported, or null if you want to
> treat as an unknown extension.
>
> Defined constants for HTTP/1.1 and HTTP/2.
>
> SSLSession
>
> Called out that getHandshakeSession's ciphersuite may vary until
> selected.
>
> SSLBase
>
> A new marker interface that SSLEngine/SSLSocket will implement.
> This will allow for a single SSLFunction instead of having
> SSLFunctionSSLEngine and SSLFunctionSSLSocket. It does require
> that the lambda do a instanceof, unless we were to move the common
> Socket/Engine APIs into this class.
I'm not sure about this one being a marker interface.
I could understand if it extracted the common functionality of
SSLEngine and SSLSocket, but a marker interface does not really add
much, and perhaps I would prefer it entirely gone.
On the same note, why is SSLFunction generic at all ?
Also, it is critical to detail how the mechanism work.
Will SSLFunction be invoked multiple times, or only once ? When,
exactly, with respect to cipher selection and alias selection ?
Example implementations for SSLFunction would be great to have: the
typical HTTP/2 case is to select the application protocol based on the
TLS protocol and the already negotiated cipher.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
Re: [9] Review request for 8072515: Test Task: Develop new tests for JEP 219: Datagram Transport Layer Security (DTLS)
Hi Xue-Lei Thanks for reviewing! I will reduce the line size, make JPRT testing and push then. -Konstantin On 06/04/2015 04:57 AM, Xuelei Fan wrote: Looks fine to me. It's nice to keep each line not exceed 80 characters. For example - * @run main/othervm -Dtest.security.protocol=DTLS -Dtest.mode=norm DTLSBufferOverflowUnderflowTest + * @run main/othervm -Dtest.security.protocol=DTLS + * -Dtest.mode=norm DTLSBufferOverflowUnderflowTest Thanks, Xuelei On 6/2/2015 8:15 PM, Konstantin Shefov wrote: Hello, Please review new tests fro DTLS feature for JDK 9: bug: https://bugs.openjdk.java.net/browse/JDK-8072515 webrev: http://cr.openjdk.java.net/~kshefov/8072515/webrev.00/ Thanks -Konstantin
