Thanks Martin.
Hi net-dev, and/or security-dev Reviewers,
Please help review and sponsor this patch if acceptable.
It does not tend to bring any functionality changes, instead to propose an
early fix, for the build (linking) errors with further toolchain (GCC 10).
JBS: https://bugs.openjdk.java
On 12/16/19 12:02 PM, ra...@web.de wrote:
Dear all,
in Java 13 the new System properties
jdk.tls.client.enableSessionTicketExtension and
jdk.tls.server.enableSessionTicketExtension were introduced. In TLS 1.2 and
prior these properties support stateful session resumption according to RFC
So maybe I'll make a short-term fix to at least make the client not barf
on the status_request in the CR message from the server. That much
should be done for correctness. Making the client actually support OCSP
stapling in its Cert message is a much bigger change and can come later.
I'll cre
Dear all,
in Java 13 the new System properties
jdk.tls.client.enableSessionTicketExtension and
jdk.tls.server.enableSessionTicketExtension were introduced. In TLS 1.2 and
prior these properties support stateful session resumption according to RFC
5077.
In TLS 1.3, however, there is no Se
Hi Jamil,
Thanks for your answer.
On 12/16/19 2:29 PM, Jamil Nimeh wrote
> If you want to take a swing at it, go for it. I'd be happy to be a
> reviewer for it.
I'm still unsure of how are we going to prioritize this but I'd let you
know if we go for it.
Regards,
Martin.-
Hi,
I'm having a lot of trouble with Java and the implementation of
an FTPS-client that can work with most of the FTPS servers out
there that require the data connection to be established with
TLS session resumption of the control channel's session. Because
the control channel is a different port
It wasn't implemented primarily for time considerations during the
initial TLS 1.3 implementation. I had planned to go back at some point
and add support for it. It's the wrong thing to have an alert thrown by
the client if the extension is present, since it's legal to have in TLS
1.3. Our c
Hi all,
Looks to me that OpenJDK's TLS 1.3 implementation is not supporting
status_request extension in CertificateRequest messages [1]. This is
specified in RFC 8446 at section "4.4.2.1. OCSP Status and
SCT Extensions" [2]:
"A server MAY request that a client present an OCSP response with its
ce
The recent crypto event logging mechanism (JDK-8148188) has introduced a
regression whereby the System Logger may be invoked too early in the
bootstrap phase. This causes issue when JarFile objects are locked by
JarFile verifier initialization code. The logging work records an X509
Certificate
