A fully fledged TLS Extensions API ?
Simone Bordet
simone.bordet at gmail.com
Fri Nov 7 13:06:39 UTC 2014
Hi,
I was writing the email about the ALPN API proposal when I realized
that it would have been better to split the arguments in different
emails.
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, to provide application code that will be run in the
context of the TLS implementation, rather than just values such as
booleans or strings.
IMHO this chance can be lifted to provide a full TLS Extensions API.
Alternative providers such as IAIK offer a private API such as [1]:
SSLSocket.getActiveExtensions()
SSLSocket.getPeerExtensions()
Similarly, BouncyCastle offers [2]:
DefaultTlsClient.getClientExtensions()
In the JDK there is a class named SSLParameters that contains some of
the configuration values for TLS.
Some of those are duplicated in SSLSocket and SSLEngine (e.g.
wantClientAuth, needClientAuth, etc), with some temporal dependency
(call this before the other, if I have to trust the comments of
SSLSocketImpl.setHost()).
Eventually all values get forwarded to the handshaker, but from the
API point of view it's not very clear what API one should call (the
one on SSLEngine or the one on SSLParameters), nor where the ALPN
setup should be done.
The idea would then be to introduce a fully fledged TLS extensions API
to handle all the TLS extensions related things, such as
renegotiation, SNI, elliptic curves, NPN, ALPN, session tickets etc.
Both applications and the JDK implementation would be able to leverage
this new API.
Note that the bulk of this API already exists in sun.security.ssl.
My question is really whether JDK 9 could take in consideration such
TLS Extension API be exposed publicly for applications to use it.
See the other emails about ALPN and the interaction between ALPN and
HTTP 2 for further examples of where this TLS Extension API would come
handy.
Thanks !
[0] http://tools.ietf.org/html/rfc7301
[1] http://javadoc.iaik.tugraz.at/isasilk/current/iaik/security/ssl/SSLSocket.html
[2] https://www.bouncycastle.org/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. Victoria Livschitz
More information about the security-dev
mailing list