://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
property rather than a
session property.
> Finally, 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 th
Hi,
On Wed, Aug 20, 2014 at 1:03 PM, Simone Bordet wrote:
> On Tue, Aug 19, 2014 at 4:11 PM, Vincent Ryan
> 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 when this is
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 sof
For reference 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 imple
See also: https://github.com/http2/http2-spec/issues/612
On Wed, Sep 17, 2014 at 3:17 PM, Simone Bordet wrote:
> Hi,
>
> On Wed, Sep 17, 2014 at 12:57 PM, Michael McMahon
> wrote:
>> Hi Simone,
>>
>> I'm interested to understand why you think this Ht
n49
There you can call getSSLEngine(), 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 so
x27;s going 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. Victoria Livschitz
nsion.class)
rather than
http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sni/SSLExplorer.java
(yuck :)
--
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
Hi,
On Fri, Sep 26, 2014 at 8:03 PM, Sean Mullan 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
>>
ike to know 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.
!
--
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
/docs/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. Vic
ut why I think a TLS Extension API
would be beneficial, see also the other emails.
Thanks !
[0] http://tools.ietf.org/html/rfc7301
[1]
https://github.com/eclipse/jetty.alpn/blob/master/src/main/java/org/eclipse/jetty/alpn/ALPN.java
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no m
isite to implement h2, but may not be sufficient,
since additional methods 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
Hi,
On Mon, Nov 10, 2014 at 2:07 PM, Florian Weimer 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 fr
ons for SSLSocket (similar to
HandshakeCompletedListener) would 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
e out of
scope for this ALPN work.
I mentioned it as a reminder that the API cannot be too "closed", 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 B
d update the
current 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
the API to ASCII strings.
>
> Lastly, we could also add some convenience values for well-known values.
> e.g.:
>
> public static final AP_HTTP_1.1 = "http/1.1";
>
> or in byte form:
>
> public static final AP_H2 = "h2".getBytes(""US-ASC
r
SSLSocket, and can 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
ring 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
s 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
efinitely needs 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 impl
ore the cipher is selected, but you need ALPN to select
the certificate.
If those two 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 s
-or-
>
> 1b. Keep API as is, and make two callbacks. This first is an advisory
> value, the TLS protocol version and proposed ciphersuite will be available
> in getHandshakeSession(). The second callback sets the final value that
> will be sent.
>
>
> I think 1.a is my pref
neServerAlias() will be called repeatedly for other
ciphers, until a cipher good for h2 is found, otherwise it's an alert
120.
Are you proposing to call select(...) from chooseEngineServerAlias(),
and give the ALPN callback a semantic that it may be called multiple
times, each time with a
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
h
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 back
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
>>>
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 sp
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
terminate
> the connection.
Nope.
Imagine a server that overnight added h2 support.
Yesterday a browser could open a page and browse the site over http/1.1.
Today, the browser cannot even connect to the website (because you
don't allow fallback).
But if you use Netscape 4, you can act
nnot be a requirement that whenever TLS changes, an update to HTTP/2
must be published.
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
arifications to the RFC
7540 and RFC 7301 mailing 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.c
8/webrev.04/test/javax/net/ssl/ALPN/Http2ApplicationSelector.java.html
>
> Note the HTTP/2 blacklist and reordering code.
>
> The code is not actually "working" yet (haven't merged API/impl repos yet),
> but shows how to configure/use this API.
Just a reminder th
ore HTTP/2 to support 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
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.
"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 convinced that - so far - the Jetty API proposal (o
and
it's available in SSLSession.
When remains is the transient value of cipher that is being chosen.
Because we already have modified the API to support the application
protocol transient value (by adding
SSLEngine.getHandshakeApplicationProtocol()) to be used by
KeyManagers
vely 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 ?
Thanks !
--
S
protocol, you 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.thenComparing
are open to comply with any legal papers that needs to be in place
for this contribution.
I 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
7;s on the radar for JDK 9.
Ok, if impossible I 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 perfor
and we
optionally use it in Jetty too.
--
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
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 goo
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.
in "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 w
stablished 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,
to
bytes have been 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
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 architecture and de
know the 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 tec
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
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
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
he strength for general purpose, but not for
> application protocol.
Because HTTP/2 would probably be popular given the success of its
predecessor, it would be handy to have a HTTP/2 comparator to
influence the selection of the HTTP/2 protocol.
Nothing forbids to offer a comparator by ciphe
l.
It cannot choose the cipher based on the application protocol.
--
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
to prefer 128 bits or lower to favor performance,
but also do HTTP/2.
The H2 comparator will sort the blacklisted at the end.
Among the good ones, they all compare == 0 for the H2 comparator.
That is where the second comparator will kick in, grep the cipher name
for the bits number and sort them accor
avor ap1 *and* c2, you have to decide what is more
important between the two, because you cannot have both.
I don't see any problem, really.
That the results are different, sure, but they are predictable.
When the configuration uses one comparator, it will always be that
result, and same for t
m 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 design are,
to deliver bug
tions, exactly
because the application decides whether to accept or not the
combination of application protocol, cipher, etc.
--
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
H1 and 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
and also much more flexible.
Well, I kinda like it, but I have strong reservations that it cannot
really "negotiate" the application protocol, meaning that if one
application protocol fails, try the next, and then the next and so
forth until one succeeds (or they all fail).
Thanks !
--
an implementation already ? That would help.
--
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
cklist/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, no matter how good the arch
handshake
Is that right ?
In that scenario, what is the use of
SSLEngine.getHandshakeApplicationProtocol() ?
Also, I don't understand how the above could work for SSLSocket ?
Can someone write down the steps a client and a server should do to
actually use ALPN with SSLSocket ?
Thanks !
--
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, no matter how good the architectur
ly, but I cannot
believe that all others that are interested in ALPN in Java 9 went for
a workaround instead of asking here whether the cipher names could
have been exposed in a standard way.
Considering the historical issue you mention it is important that
there are no ambiguities in the cipher names
LParameters 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 mat
at 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 !
--
Simone Bordet
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
o a forward compatible ALPN
implementation that can be run with any JDK 9+.
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 tech
r.
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 performance and reliability,
the imp
Hi,
On Tue, Jun 14, 2016 at 5:58 PM, Simone Bordet 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 chooses the cipher, it
> may think
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 reliabilit
Hi,
On Wed, Jun 15, 2016 at 10:03 AM, Andrew Haley 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, it
>> would just
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 with
detail.
The information 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 ou
pose 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 optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
sufficient after 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,
ction" ?
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 ?
Thanks !
--
Simone Bordet
http://bor
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
rt) ?
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 performance and reliability,
, 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
Hi,
On Wed, Jan 11, 2017 at 5:57 PM, Simone Bordet 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 much much simpler way.
>
> The amount of
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
;
// 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 r
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
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,
know that other 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.
n("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.
end the close_notify if it doesn't want to close. 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
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
the server; 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
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 mat
produces
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
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
lt is OK, 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_
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-free
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
---
Fin
tify 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
1 - 100 of 106 matches
Mail list logo
