Another area of applicability is inner authentication mechanisms which
make use of channel binding; these mechanisms need to actually acquire
chunks of data from the handshake exchange.
http://tools.ietf.org/html/rfc5929 for more info
On 11/10/2014 03:36 PM, Bernd Eckenfels wrote:
Hello,
the question is, what is a extension API actually helping with: the JSSE
implementation is slow to adopt to typical advances in TLS browser
"wars". While this is not so bad as nobody implements a Web Browser in
Java anyway, it does make it harder for server vendors to offer a full
stack (without native libraries or reverse proxies).
Having an API to handle extensions could help with this a bit, however
a lot of the extensions cannot be bolted on, they alter the handshake
sequence, introduce new messages or alter interpretatrion of existing
enums. So while ALPN can be handled pretty easily, it would be harder
for things like eliptic_curves or supported_signatures or SRP (or Poly
authenticator) - or TLS_FALLBACK_SCSV (or simple things like rate
limiting the renegotiations).
The other question is, if advances in SSL/TLS protocol really need to
be bound with major java versions. It would do the world a favor to
have a backport of a system property allowing TLS1.2 to be used by
default. Having the JSSE implementation beeing its own sub project
under the openjdk could help with that. Especially if providers become
more plugable. And optimizations like intrinsic are not bound to the
providers, but to the actual primitive needed (like AES GCM).
Gruss
Bernd
Am Mon, 10 Nov 2014 14:28:44 +0100
schrieb Simone Bordet <simone.bor...@gmail.com>:
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, to provide application code that will be run in the
context of the TLS implementation, rather than just values such as
booleans or strings.
That's going to be interesting if you need to support non-blocking
operation for use with SSLEngine.
In the case where you have to load the configuration from a place
where it may take a lot of time, you can easily change the ALPN API to
something like:
For the client:
void selected(String protocol, CompletableFuture<Void> callback)
For the server:
void select(List<String> protocols, CompletableFuture<String>
callback)
and when you're done call callback.complete() or
callback.completeExceptionally().
This would mean that the TLS implementation has to wait for those
callbacks to be completed before proceeding.
On one side, having application code to complete the callbacks is, in
our experience, error prone (i.e. applications forget it)
On the other side, applications that make use of this API are
typically on the implementer side rather than on the developer side
(here I mean people that implement a server, rather than a developer
of a webapp), so I guess a callback, albeit more complex, may give
implementers more room for different implementations.
IMHO this chance can be lifted to provide a full TLS Extensions
API.
I don't think this is possible because TLS extensions can alter the
TLS handshake, result in additional messages being exchanged, and
generally alter the protocol in unforeseeable ways. On top of
that, the concrete TLS implementation is not fixed, it can be
swapped out, so tying the extension API to the existing OpenJDK
internals will not work for everyone.
Can you expand what you mean here ?
If a TLS extensions API is provided by JDK 9, would it not be
implemented by providers like they do with the other APIs they have to
implement to be a compliant provider ?
It's a little more effort for providers, but with a public API should
be implementable by any provider and an application would be portable
across providers.
Thanks !
--
- DML
