Hi Simone/Thomas/David/others,
Thomas wrote:
would it not be an great idea to combine all these new extensions to
an generic way how to handle the SSL Protocol Handshake ?
I've finally been able to deep dive back into ALPN, specifically looking
at the ideas of a general Hello extension framework, but also a more
general handshaking framework that could support additional/future
handshake message types (e.g.
NPN/CertificateStatus/SupplementalData/SessionTicket).
After reading lots of current/proposed/private TLS extension RFCs[1][4],
I concur with much of what Xuelei wrote previously (see below). I also
agree that having a Hello+extension explorer/modifier would have some
utility for ALPN and a few others (including TLS_FALLBACK_SCSV), but
many of the current extensions require modifications to the
protocol/calculations and/or the KeyManager/TrustManagers and thus can't
simply be bolted into SunJSSE using the current APIs/implementations. In
most cases, it requires modification of the underlying SunJSSE
implementation to support them, or else a strong working knowledge of
the TLS protocol to make the right insertions in the right place.
I have varying degrees of familiarity with these extensions, so I may
have missed an obvious way to implement something and am certainly open
to suggestions, but here's the current extension list and my notes:
# Extension Name Reference
= ============== =========
0 server_name [RFC6066]
Currently supported
1 max_fragment_length [RFC6066]
No: Protocol I/O modifications needed to generate proper sized packets.
2 client_certificate_url [RFC6066]
No: Requires new KM/TM API style that knows how to fetch URLs
3 trusted_ca_keys [RFC6066]
Yes: pretty straightforward
4 truncated_hmac [RFC6066]
No: Protocol modifications needed
5 status_request [RFC6066]
Currently under development for JDK 9[2]
6 user_mapping [RFC4681]
Possible: need to insert Supplemental Data handshake message type into
right place in handshake, but probably not too difficult.
7 client_authz [RFC5878]
8 server_authz [RFC5878]
Possible: also must insert Supplemental Data into the right places in
handshake, but probably not too difficult.
9 cert_type [RFC6091]
No: Currently only support X509KM/X509TM, not OpenPGP credentials.
10 elliptic_curves [RFC4492]
11 ec_point_formats [RFC4492]
Currently supported
12 srp [RFC5054]
No: Requires new ciphersuites and ClientKeyExchange format support.
13 signature_algorithms [RFC5246]
Currently supported
14 use_srtp [RFC5764]
No: APIs do not expose the PRF and TLS master secret mechanisms. Might
be able to talk RTP using socket overlays, but the other issues make
this impossible.
15 heartbeat [RFC6520]
No: Don't support heartbeat message type.
16 application_layer_protocol_negotiation [RFC7301]
Currently under development for JDK 9[3]
17 status_request_v2 [RFC6961]
Currently under development for JDK 9[2]
18 signed_certificate_timestamp [RFC6962]
No: We might be able to support this extension, but it would be
incomplete as OCSP doesn't support 1.3.6.1.4.1.11129.2.4.5. Clients
must support X509v3 cert extension, TLS exension, and OCSP: servers
only need to support one.
19 client_certificate_type [RFC7250]
20 server_certificate_type [RFC7250]
No: We do support X509 certs, but we don't support Raw Public Keys with
our current impl so this would not be a complete implementation.
21 padding [draft-ietf-tls-padding]
Yes: but would require educated guesses on how much padding to add.
22 encrypt_then_mac [RFC7366]
No: protocol modifications needed
23 extended_master_secret [draft-ietf-tls-session-hash]
No: would require changes to the PRF computation parameters.
35 SessionTicket TLS [RFC4507]
Possible: requires new SessionTicket message be sent in the right place,
probably not too difficult.
13172 NPN [4]
Possible: requires insertion of a NextProtocol message between CCS and
Finished.
65281 renegotiation_info [RFC5746]
Currently supported
I also looked at extending the handshake examiner for channel bindings
using either raw TLS X509Certs or Finished messages. It seems easier to
me if developers had 2-4 methods with descriptive names rather than
having to use a generic handshake message examiner/modifier and an
intimate working knowledge of the TLS protocol.
At this point, my feeling is to provide a default ALPN selector (using
the server-ordered list), but also have a Hello Callback+Examiner with
the ability to add/modify/delete extensions upon receipt/before
transmission, including handling unknown/future extensions
(getEncoded()). It will be up to the application to parse/handle said
extensions. That would help guide HTTP-2 protocol/ciphersuite/ALPN
selection (i.e. fallback to HTTP/1.1 if not TLSv1.2), plus the
TLS_FALLBACK_SCSV (however, Florian's work might be in place soon), but
I'm not sure how much additional use it will be. Initially I would
probably expose via API only the supported extensions, along with an API
for determining if an "unknown" extension is supported by the underlying
implementation (SSLSocket/SSLEngine.isExtensionSupported()?).
One last comment, the IETF released RFC 7540 (HTTP/2) last Friday.
There are a few tweaks that we will need to make regarding keysizes,
ciphersuites, and TLS renegotiation. We'll be filing bugs on those shortly.
Thanks,
Brad
[1]
http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
[2] https://bugs.openjdk.java.net/browse/JDK-8046321
JEP 249: OCSP Stapling for TLS
[3] https://bugs.openjdk.java.net/browse/JDK-8051498
JEP 244: TLS Application-Layer Protocol Negotiation Extension
[4] https://technotes.googlecode.com/git/nextprotoneg.html
On 4/13/2015 8:02 PM, Xuelei Fan wrote:
Thanks for the proposal.
A general TLS/DTLS extension API and pluginable extension implementation
is a good idea. But as there is no rules about how an extension may
impact the handshake flow, it is not easy to define a general APIs for
all existing known or unknown extensions and future extensions. For
example, an extension may impact the cipher suite selection, may need to
define new handshake messages, may need new algorithm implementation,
may impact the algorithm used to sign handshake messages, may impact the
algorithm used to protected application data, etc. An extension may
impact every details of handshaking, not only the client hello and
server hello messages. It would be great if there are general APIs that
are simple and cover the possible impact in every details of
handshaking. I'm open for more advices.
Maybe we can have APIs to define the extension parameters, rather than
the handshake implementation. But as we already have SSLParameters, I
don't think we need extra APIs for extension parameters any more.
JSSE is open source and an provider based framework. Alternatively,
we'd like to accept extension implementation contributions, or developer
can define their own private provider if necessary.
Regards,
Xuelei
On 4/14/2015 1:14 AM, Thomas Lußnig wrote:
Hi,
this could be an interface for such an Callback.
It allow hello extensions as well as handshake extensions.
If it would be really clean we would have an handler for:
- NPN
- ALPN
- Channel ID
- ZertificateSignature
- OCSP-Stapling
- ServerName
- Session Ticket
The handler could be also used for handling:
- TLS_FALLBACK_SCSV
The current way is that all these extensions are in the sun Private
package space
and to make it even worse each extension is written in another way.
Also i am missing an API defined way to extend the list in
sun.security.ssl.CipherSuite.
Gruß Thomas
public interface HelloHandler {
/**
* Allow to add extesions to Server/Client Hello
* based on the Client/Server hello */
public void handleHelloMessage(ClientHello clientHello, ServerHello
serverHello);
/** Allow to add new Handshake Messages based on
* the Client/Server Hello
*/
public void sendHandshakeMessage(HandshakeOutStream handshakeOutStream,
ClientHello clientHello, ServerHello serverHello);
/**
* define an order of the extensions
*/
Class<? extends HelloHandler > runBefore();
/**
* define an order of the extensions
*/
Class<? extends HelloHandler > runAfter();
}
Hi,
On Mon, Apr 13, 2015 at 6:22 PM, David M. Lloyd <[email protected]> wrote:
Do you know of a Java TLS implementation that has APIs like this already? I
am also interested in this for the ability to implement authentication
mechanisms (GSSAPI and SASL) that rely on channel binding, so I would like
to see such an API materialize as well.
I posted a while back such APIs from 3rd party JSSE implementations:
http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011014.html
(at the end).
The problem that has been raised is that if you offer a generic TLS
extensions API, then the extension may have a semantic that it's not
implemented.
Imagine this TLS extensions API already existed, to add extensions to SSLEngine.
Now, ALPN comes along as a new TLS extension. An application could
create their own ALPNExtension subclass (extending a standard one
provided by the TLS extensions API), and add it to the ClientHello.
But there is no code in the JDK that calls the application, asking (on
the server) to select one of the protocols, for then send back the
chosen protocol to the client.
This could be solved by a callback API at the moment the ClientHello
is received by the server (and the ServerHello by the client), so the
application can examine the ALPN protocols.
The NPN extension was doing something even more complicated, creating
an additional TLS message that needed to be sent at the right time.
It may be that a TLS extensions API (to add/remove/query TLS
extensions) *and* a callback API to analyze "hello" messages when they
are received is enough to cover a lot of cases, perhaps even all
currently existing ones.
I asked for feedback some time ago about the status of the ALPN
implementation; would be great if the security team could update the
current status.
