Re: Alias internal format leaked to application code?

Hi, On Mon, Jun 1, 2020 at 5:24 PM Xuelei Fan wrote: > > Good catch, Simone. It is not expected to parser the alias in application > code. Would you like file a bug? https://bugs.openjdk.java.net/browse/JDK-8246262. Thanks! -- Simone Bordet --- Finally, no matter how good the arc

Alias internal format leaked to application code?

should "unwrap" this internal alias format (is it defined somewhere?), or if this internal format is wrongly leaked to user-written code? Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and r

Re: Reading from a closed socket: different behavior between Linux and other operating systems

throws (on Windows). -- Simone Bordet --- 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: Aftermath of TLS 1.3 in Java 11 with wrapped IOExceptions

he exact reason for the SSLHandshakeException, and from it decide whether it's retryable or not. Thanks! -- Simone Bordet --- 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 flawl

Re: Change in closeOutbound() behavior for unused SSLEngine

Hi, On Wed, Oct 16, 2019 at 7:42 PM Xuelei Fan wrote: > > Hi Simone, > > The compatibility impact makes sense to me. Would you mind file a new bug? https://bugs.openjdk.java.net/browse/JDK-8232432 Thanks! -- Simone Bordet --- Finally, no matter how good the architectur

Re: Change in closeOutbound() behavior for unused SSLEngine

een produced, so no close_notify is sent to the other peer, but we know from the CLOSED result that we can now send the FIN to the other peer. Thanks! -- Simone Bordet --- 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

Change in closeOutbound() behavior for unused SSLEngine

are established but never used (not even a TLS byte was exchanged). Is this change in behavior expected? I find strange that calling closeOutbound() results in a NEED_UNWRAP (as there is nothing to read). Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are

Re: JDK 13 SSLSession.getValue() throws NPE

"13" but doesn't have a build number associated with it. Which > build of JDK 13 are you on? I was using 13+29. The issue is fixed in 13+33. Sorry for the noise. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with o

JDK 13 SSLSession.getValue() throws NPE

so trying to call SSLSession.getValue() throws a NPE. Is this a regression? Thanks! -- Simone Bordet http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts.

Re: Use of OpenSSL as JCE security provider if available on system

improvements. https://nbsoftsolutions.com/blog/dropwizard-1-3-upcoming-tls-improvements I guess the memory allocation/footprint has similar improvements, with the JDK insisting at requiring ~17 KiB buffers to read HTTP requests in the order of <1 KiB. -- Simone Bordet --- Finally, no matter how

Re: Align SSLSocket and SSLEngine Javadocs

) and startHandshake() have a very similar Javadoc. Thanks! -- Simone Bordet --- 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

Align SSLSocket and SSLEngine Javadocs

be used to update encryption keys etc. Especially in light of TLS 1.3 where renegotiation is forbidden, I would like the Javadoc of these method to align and describe exactly when they do with respect to the TLS protocol version. Thanks! -- Simone Bordet --- Finally, no matter how good

Re: SSLSocket session resumption not working with TLS 1.3 and 11+27

Hi, On Fri, Aug 24, 2018 at 8:54 PM Adam Petcher wrote: > On 8/23/2018 3:28 PM, Simone Bordet wrote: > > Hi, > > > > The code below reproduces a bug where session resumption is tested. > > Turns out that session resumption does happen on the client and on the &g

SSLSocket session resumption not working with TLS 1.3 and 11+27

ion(); session2.set(session.toString() + " - " + Arrays.toString(session.getId())); handshakeLatch2.countDown(); }); sslClient2.startHandshake(); handshakeLatch2.await(1, TimeUnit.SECONDS); System.err.println("session1 = " + session1); System.err.println("se

SSLSocket weird behavior in JDK 11+27

write(0); //output.flush(); // Raw close. rawClient.close(); latch.await(10, TimeUnit.SECONDS); } } -- Simone Bordet http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts.

Re: SSLEngine weird behavior in 11+21?

Hi, > > On 7/12/2018 1:17 PM, Simone Bordet wrote: > > Currently: > > - Server wraps 160, 6 and 907 in 3 wraps. > > - Server *sends* the 1073 bytes in 1 TCP write > > - Client unwraps 160, then goes into NEED_WRAP > > - Client wraps 6, then goes again into

Re: SSLEngine weird behavior in 11+21?

alert, and therefore the connection will be > duplex closed. > > Does it make sense to you? Yes. Although I think application will need to make adjustments for TLS 1.3 anyway. That system property will smooth things, but won't guarantee that an application written for SSLEngine TLS 1

Re: SSLEngine weird behavior in 11+21?

ING Result is CLOSED > Server wrapped 16406 bytes. > Server handshake status is NOT_HANDSHAKING Result is OK > Server called closeOutbound() status is NEED_WRAP > Server wraps 24 bytes > Server handshake status is NOT_HANDSHAKING Result is CLOSED Thanks! -- Simone Bordet --

Re: SSLEngine weird behavior in 11+21?

G. Yes, we agreed that at step 2 and especially step 3 result must be CLOSED. Please consider the case where data is sent before the close_notify reply, and what would be good for you. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug

Re: SSLEngine weird behavior in 11+21?

, stays in NOT_HANDSHAKING. 5. Client unwraps data bytes result is OK, stays in NOT_HANDSHAKING. 6. server.closeOutbound() then goes into NEED_WRAP. 7. Server wraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING. 8. Client unwraps 24 bytes, result is CLOSED, then goes into NOT_HANDSHAKING

Re: SSLEngine weird behavior in 11+21?

Hi, On Tue, Jul 31, 2018 at 11:39 AM Simone Bordet wrote: > > Hi, > On Mon, Jul 30, 2018 at 8:08 PM Xuelei Fan wrote: > > Would you mind look at the code I posted in the following thread: > > http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.ht

Re: SSLEngine weird behavior in 11+21?

uces 0 bytes, so it's going to be a tight spin loop - not good. Thanks! -- Simone Bordet --- 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: SSLEngine weird behavior in 11+21?

Hi, On Fri, Jul 13, 2018 at 3:45 PM Xuelei Fan wrote: > Thank you very much, Simone. I find at least two improvements we can > take. It's really good! Great! Let know when they land in a 11+X release and we'll try them out. Thanks! -- Simone Bordet --- Finally, no matter ho

Re: SSLEngine weird behavior in 11+21?

; if it does not see it, it closes the raw socket after a timeout. The timeout could account for receiving data (i.e. it is reset if application data arrives), or not. Thanks! -- Simone Bordet --- 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: SSLEngine weird behavior in 11+21?

Hi, On Thu, Jul 12, 2018 at 11:15 PM Xuelei Fan wrote: > > On 7/12/2018 1:09 PM, Simone Bordet wrote: > > Hi, > > On Thu, Jul 12, 2018 at 10:05 PM David Lloyd wrote: > >> But more importantly, I think this > >> represents a chance to fix this l

Re: SSLEngine weird behavior in 11+21?

If we > have the client goes into NEED_UNWRAP, there is a potential dead waiting. Good point. Thanks! -- Simone Bordet --- 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: SSLEngine weird behavior in 11+21?

eption("The method shutdownOutput() is not supported in SSLSocket"); Thanks! -- Simone Bordet http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts.

Re: SSLEngine weird behavior in 11+21?

r SSLEngine users for widely used Java network servers are around in this list :) Would be great if they can feedback about whether JDK's SSLEngine with TLS 1.3 is working well for them. Thanks! -- Simone Bordet http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts.

Re: SSLEngine weird behavior in 11+21?

Hi, On Thu, Jul 12, 2018 at 12:06 AM Simone Bordet wrote: > > Hi, > > I can see this (weird) behavior in SSLEngine for TLS 1.3 in JDK 11+21. > It's a simple new connection (no resumption) that performs a TLS 1.3 > handshake. > The bytes numbers are those that I get,

SSLEngine weird behavior in 11+21?

into NEED_UNWRAP instead, and only at 10 go into FINISHED. Thanks! -- Simone Bordet --- 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: JDK 11+21 SSLSocket.close() deadlock?

// Wait for sslServer to start reading from the client. Thread.sleep(1000); // Hangs here. sslServer.close(); client.close(); } -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliab

JDK 11+21 SSLSocket.close() deadlock?

a sun.security.ssl.SSLSocketImpl) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:383) -- Simone Bordet --- 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: Feedback on SSLEngine.setHandshakeApplicationProtocolSelector()

Hi, On Wed, Jan 11, 2017 at 5:57 PM, Simone Bordet <simone.bor...@gmail.com> wrote: > Hi, > > I just wanted to report that I have implemented the new mechanism > provided by SSLEngine.setHandshakeApplicationProtocolSelector() in > Jetty, and it works well in a

Feedback on SSLEngine.setHandshakeApplicationProtocolSelector()

, and we basically tap into the existing mechanism that Jetty had. No big surprises here since the new JDK mechanism is very similar to what Jetty has for JDK 8. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug

Re: TLS-PSK status ?

for JDK 9 or even 8 (via backport) ? It is just to know and to respond to people that asked about supporting TLS-PSK support. Thanks again ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal pe

TLS-PSK status ?

Hi, https://bugs.openjdk.java.net/browse/JDK-6476446 is closed as a duplicate of JDK-8049402, but unfortunately this latter issue is not public. Is there any status about the implementation of TLS-PSK (RFC 4279, 4785, 5489) ? Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally

Re: [9] RFR 8171443: (spec) An ALPN callback function may also ignore ALPN

sed to signal "no action" ? The SSLEngine implementation should also check that the String returned is among those sent by the other peer, so an empty string is as invalid as the string "no_proto" - hence the choice of null to signal "no action". Makes sense ?

Re: [9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake

ter all, > leaving a bit of dead code around. >From how I understand this change, the whole mechanism of parsing the ClientHello, running your logic, running again the ClientHello parsing and the JDK logic, resulting in calling the application callbacks (for SNI for example) twice,

Re: Issues with ALPN implementation in JDK 9

then the solution I propose works equally well to what you guys propose. There is no "flaw", it is just undecidable. What am I missing ? Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with

Re: Issues with ALPN implementation in JDK 9

ion that needs to be reported in the ServerHello is only needed when the ServerHello is being constructed. Had the JDK implementation been written with a delayed handshaker.started=true we would have the best of both worlds. You could write your own solution, we could write our own. Yours will have some re

Re: Issues with ALPN implementation in JDK 9

e *are* still in time, according to Mark Reinhold. The changes are simple. We have not heard from Oracle yet, but I can prepare a webrev if that helps. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software wit

Re: Issues with ALPN implementation in JDK 9

Hi, On Wed, Jun 15, 2016 at 10:03 AM, Andrew Haley <a...@redhat.com> wrote: > On 14/06/16 14:57, Simone Bordet wrote: >> * Lack of facilities to convert TLS protocol bytes to protocol strings. >> This class already exist in JDK, sun.security.ssl.ProtocolVersion,

Re: Issues with ALPN implementation in JDK 9

oof. I don't control which JDK people use to run Jetty. I would rather not duplicate all the JDK logic into an application. 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

Re: Issues with ALPN implementation in JDK 9

Hi, On Tue, Jun 14, 2016 at 5:58 PM, Simone Bordet <simone.bor...@gmail.com> wrote: > The server could choose an ECDSA cipher for h3, the mandatory cipher > for h2, so the list of cipher is (ECDSA, RSA). If, at this point, the > server chooses the protocol *before* the JDK cho

Re: Issues with ALPN implementation in JDK 9

e TLS stack chooses the RSA cipher. At this point, you have the h3 protocol with the RSA cipher, which may be an invalid combination. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal

Re: Issues with ALPN implementation in JDK 9

for ECDSA). That is a breaking change to me. I imagine in the future ECDSA be replaced by something else, or a different DSA being used, I have to change the server code. I would like to avoid that, and keep the server logic independent of how the JDK chooses the cipher. Makes sense ? Thanks ! -

Issues with ALPN implementation in JDK 9

s can be changed just after the NEED_TASK step, so that server applications will be able to interact with the JDK for what pertains TLS protocols, ciphers, SNI, etc. without duplicating the logic. Comments welcome. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good th

Re: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension

hat there are no ambiguities in the cipher names, and having the JDK as the only source is really important. Can I ask you to reconsider this small change for JDK 9 ? -- 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: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension

edCipherSuites(), etc. which handle String[]. Having the JDK to provide this facility would guarantee that the naming is always consistent, and that it is always up-to-date with the JDK in use. Looking forward to your comments. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally,

Re: TLS ALPN Proposal v7

; Changes: > > 1. No H2 Blacklist/Comparator > > 2. set/getApplicationProtocols() back to SSLParameters. Have you implemented this solution already ? Also for clients ? Do you have feedback on actually implementing ALPN in this way ? -- Simone Bordet http://bordet.blogspot.com --- Finally,

Re: TLS ALPN Proposal v5

d H2 for ap.matches(), but in general these will be implemented by application code. For an application that wants to support H2, this boils down to the first 2 lines, the rest is in the JDK. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and de

Re: TLS ALPN Proposal v5

only sort to favour the best protocol. 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, then with AP_NEW.CIPHER_COMPARATOR. cipherSuites = Arrays.sort(cipherSuites, ApplicationProtocol.H2.CIPHER_COMPARATOR.then

Re: TLS ALPN Proposal v5

parator by cipher strength too. -- Simone Bordet http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts.

Re: TLS ALPN Proposal v5

, and same for the other comparator. But you configure the comparators in base of what you want to do. -- 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

[no subject]

? I did not get the > answer from the HTTP/2 spec. Yes, there was an answer to Bradford's email: https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0160.html. The answer is "yes". -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and des

Re: TLS ALPN Proposal v5

ant to use ALPN extensively because they use many different communication protocols internally, so it won't be a rare occasion to implement ApplicationProtocol. > http://cr.openjdk.java.net/~wetmore/8051498/webrev.15/ I gather that the Map parameter can't be solved in other ways, right

Re: TLS ALPN Proposal v5

o be used by KeyManagers, I was wondering if we cannot either: A) add: String SSLEngine.getHandshakeCipherSuite(), to be used by ApplicationProtocol or B) add: Map<String, String> SSLEngine.getHandshakeParameters() or perhaps: Map<String, String> SSLParameters.getHandshakeParameters(). 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 v5

seems totally geared towards server "matching" more than client notification. For me this is a blocker. Can you please provide an example of how a client application would use this new API to be notified that the server has chosen protocol "foo" ? I still remain convin

Re: TLS ALPN Proposal v4

ommunity). This proposal seems less clear to me, a bit of compromise between a full fledged multi-selector API (it is in fact a 2-selector API for cipher and application protocol) and the previous proposal (that was a select-after-the-cipher selector API). If the times are tight, I would go for the simpler approach and leave the full fledged multi-selector API for JDK 10. Thanks ! -- Simone Bordet http://cometd.org http://webtide.com Developer advice, training, services and support from the Jetty & CometD experts.

Re: TLS ALPN Proposal v3

the current situation ? -- 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 v3

protocol is 1.3, there is no need to look at the ciphers (nor to sort them). 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

Re: TLS ALPN Proposal v2

. Hope this clarifies. 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

lists, or even directly to the editors of those RFCs; they are typically open to answer questions, I guess especially so if they come from the OpenJDK team that is implementing those specification. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good

Re: TLS ALPN Proposal v2

. 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 Thu, Jun 4, 2015 at 5:53 PM, Xuelei Fan xuelei@oracle.com 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

Re: TLS ALPN Proposal v2

Hi, On Thu, Jun 4, 2015 at 3:08 PM, Michael McMahon michael.x.mcma...@oracle.com wrote: On 04/06/15 13:19, Simone Bordet wrote: Hi, On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan xuelei@oracle.com wrote: Per section 4, RFC 7301: ... The application_layer_protocol_negotiation

Re: TLS ALPN Proposal v2

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

Re: TLS ALPN Proposal v2

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

Re: TLS ALPN Proposal

access to the ALPN callback implementation to SNI to choose the right protocol based on that ? 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

Re: TLS ALPN Proposal

that will be sent. I think 1.a is my preference. I am not sure I follow this. Can you please sketch the steps/algorithm that will be done in your proposed solution ? -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software

Re: TLS ALPN Proposal

the cipher to be negotiated to support HTTP/2, so I hope it's not a chicken-egg problem. -- 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

Re: TLS ALPN Proposal

steps can be split, then ALPN code could be put in between and all is solved. -- 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

Re: TLS ALPN Proposal

on SSLParameters, and everything is much simpler. -- 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

call for it so far. I agree that only http/1.1 and h2 deserve a constant. -- 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

Re: TLS ALPN Proposal

be reduced to a FunctionalInterface. -- 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

that the string you get back might not be a string at all. RFC 7301 hints that protocol string could be UTF-8 encoded: http://tools.ietf.org/html/rfc7301#section-6 -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software

Re: JEP 244: TLS Application-Layer Protocol Negotiation Extension

status. -- 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: JEP Review Request: TLS Application-Layer Protocol Negotiation Extension

, as the protocol selection may need to access contextual information such as the TSL protocol version, the negotiated cipher, possibly the server name indication, etc. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug

Re: A fully fledged TLS Extensions API ?

Hi, On Mon, Nov 10, 2014 at 2:07 PM, Florian Weimer fwei...@redhat.com wrote: On 11/07/2014 02:06 PM, Simone Bordet wrote: This email is about the idea to introduce in JDK 9 a fully fledged TLS Extensions API. Adding ALPN [0] support to JDK 9 requires, differently from other TLS extensions

Re: A fully fledged TLS Extensions API ?

be needed too. 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

A fully fledged TLS Extensions API ?

/docs1.5on/org/bouncycastle/crypto/tls/DefaultTlsClient.html -- 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

ALPN HTTP2

on Cipher and other TLS classes may be needed. Thanks ! [0] http://tools.ietf.org/html/draft-ietf-httpbis-http2-14 -- 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

Re: TLS extensions API, ALPN and HTTP 2.0

! -- 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 extensions API, ALPN and HTTP 2.0

in advance if this is not possible at all. Thanks ! -- Simone Bordet http://cometd.org http://webtide.com http://intalio.com Developer advice, training, services and support from the Jetty CometD experts. Intalio, the modern way to build business applications.

Re: TLS extensions API, ALPN and HTTP 2.0

Hi, On Fri, Sep 26, 2014 at 8:03 PM, Sean Mullan sean.mul...@oracle.com wrote: On 09/17/2014 01:18 PM, Simone Bordet wrote: For the server to differentiate between those 2 connections he would need the SNI information, which I don't think it's currently available in JDK 8, right

Re: TLS extensions API, ALPN and HTTP 2.0

this feature. The idea being to wait a bit to define the ALPN APIs until this issue is resolved, to see if the resolution requires changes in the ALPN APIs. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free

Re: TLS extensions API, ALPN and HTTP 2.0

the discussion happens at http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2112.html. -- 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

Re: TLS extensions API, ALPN and HTTP 2.0

See also: https://github.com/http2/http2-spec/issues/612 On Wed, Sep 17, 2014 at 3:17 PM, Simone Bordet simone.bor...@gmail.com wrote: Hi, On Wed, Sep 17, 2014 at 12:57 PM, Michael McMahon michael.x.mcma...@oracle.com wrote: Hi Simone, I'm interested to understand why you think this Http 2

Re: TLS extensions API, ALPN and HTTP 2.0

(), which will be able to return a number of information about the handshake (such as the cipher chosen). Makes sense ? -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance

Re: [undertow-dev] NoSuchMethod in 9ea-b30 getRawHostnameSE

on :) But yes, having ALPN support in JDK 9 will definitely be great. -- 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

Re: TLS extensions API, ALPN and HTTP 2.0

Hi, On Wed, Aug 20, 2014 at 1:03 PM, Simone Bordet simone.bor...@gmail.com wrote: On Tue, Aug 19, 2014 at 4:11 PM, Vincent Ryan vincent.x.r...@oracle.com wrote: Finally, please confirm that you have already signed the OCA [1] I have not yet, it's running through legals ATM. I'll notify

Re: TLS extensions API, ALPN and HTTP 2.0

, please confirm that you have already signed the OCA [1] I have not yet, it's running through legals ATM. I'll notify when this is done. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal

TLS extensions API, ALPN and HTTP 2.0

://javadoc.iaik.tugraz.at/isasilk/current/iaik/security/ssl/ExtensionList.html and its usage in http://javadoc.iaik.tugraz.at/isasilk/current/iaik/security/ssl/SSLSocket.html. We are happy to contribute to this effort, but we seek guidance from the experts in this list. Thanks ! -- Simone Bordet http

Re: Next Protocol Negotiation TLS Extension

will eventually pop up again when JDK 8 is released and JDK 9 work started. 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

Next Protocol Negotiation TLS Extension

will be more than happy to provide detailed information about the implementation of Jetty NPN and have it discussed (or even reviewed) by security experts. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free