JEP 244: TLS Application-Layer Protocol Negotiation Extension
Bradford Wetmore
bradford.wetmore at oracle.com
Wed May 20 00:30:02 UTC 2015
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 <david.lloyd at redhat.com> 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.
>>>
>>
>
More information about the security-dev
mailing list