server side tls (for http/2)...2015/09/24 · © 2015 pivotal software, inc. all rights reserved. 2...

2 © 2015 Pivotal Software, Inc. All rights reserved. 2 © 2015 Pivotal Software, Inc. All rights reserved.

Server Side TLS (for HTTP/2) and Java

Mark Thomas, September 2015

3 © 2015 Pivotal Software, Inc. All rights reserved.

Introduction

Apache Tomcat committer since December 2003 – [email protected]

Tomcat 8 release manager

Member of the Servlet, WebSocket and EL expert groups

Consultant Software Engineer @ Pivotal

Currently focused on Apache Tomcat 9

Tomcat 9 will support HTTP/2


Agenda

Server side TLS requirements – Mainly from an HTTP/2 perspective

Server Name Indication (SNI)

Multiple certificate support

Application Layer Protocol Negotiation (ALPN)


Server Side TLS Requirements


Server Name Indication (SNI)

Server side TLS requirements

HTTP/1.1 supports virtual hosts

Host name passed as an HTTP header

TLS certificate needs to match host name

Certificate must be presented in the TLS handshake

The TLS handshake must complete before any HTTP traffic

SNI: adds host name to the handshake


Multiple certificates

Server side TLS

Three types of certificate – RSA (most popular)

– DSA (rarely used)

– EC (increasing in popularity)

Available ciphers depend on the certificate


Application Layer Protocol Negotiation (ALPN)

Server side TLS

ALPN adds protocol negotiation to the TLS handshake

HTTP/2 requires ALPN – HTTP/2 traffic starts as soon as the TLS handshake completes


Server side TLS

SNI, ALPN and certificate selection are inter-related

SNI determines which certificate(s) to use

Certificate(s) determine which ciphers are available

ALPN may have requirements for ciphers

Client capabilities also have an impact

Negotiation involves combination of protocol, host & ciphers


Server Name Indication



Java 8 added ‘support’ for server side SNI

But Java only allows a single certificate to be configured – Fine for *.apache.org

– Not so good for www.openoffice.org and openoffice.apache.org

So what SNI support does Java 8 provide?



Java provides a callback with the client provided host name

Java API provides the following options – Abort the connection

– Allow the connection to proceed

So how does the API support virtual hosting with different

certs for different hosts? – It doesn’t

Never fear, Oracle has a plan…



To use server side Java TLS virtual hosting applications

must: – Buffer the incoming network packets

– Parse the opening TLS handshake

– Extract the requested server name

– Select the correct certificate

– Configure the socket with the right TLS configuration

– Pass the buffered data to the socket

– Continue to pass all subsequent data



Java provides support for one certificate per connection

Same problem as with SNI

Use the same solution – Extract client ciphers form initial TLS handshake

– Filter ciphers based on available certificate(s)

– Select preferred cipher

– Use matching certificate


Application Layer Protocol Negotiation



Servlet 4.0 will require ALPN support

Servlet 4.0 is part of Java EE 8

Java EE 8 must pass the TCK on Java 8

ALPN support is planned for Java 9

Servlet EG requested a backport of ALPN support to Java 8 – request denied

– twice


The Java solution


Require Java 9

ALPN support is coming in Java 9

API isn’t finalized yet – complicated by negotiation requirements

Risk that ALPN support turns into another SNI – ALPN messages go both ways

– Parsing the handshake trick can’t work


The Jetty Solution


Jetty has produced a binary patch to add ALPN to Java 8

JRE vendor and exact version specific

It is known to be working

Potential for support issues – Users have to install the right version

– Behavior may be ’odd’ if the wrong version is used


The OpenSSL solution


OpenSSL supports ALPN

Tomcat’s APR/native connector uses OpenSSL

Also supports – SNI

– Multiple certificates

Requires a native library


The OpenSSL based JSSE provider solution


TLS in Java is provided by JSSE

JSSE supports pluggable providers

Implement a JSSE provider using OpenSSL

Several attempts – Not aware of any that have been successful


The JSSE plus OpenSSL solution


SSLContext is normally provided by JSSE

JSSE allows injection of custom SSLContext – Ability to do this spotted by the Netty project

Implementing an OpenSSL based SSLContext is much

simpler than implementing a JSSE provider

Requires a native library

Works with the JSSE API


Tomcat 9 plan for TLS


Tomcat 9 plan for TLS

Requiring Java 9 is not an option

The Jetty solution complicates the install

APR/native will be used – Tomcat already has the necessary code

OpenSSL based SSLContext will be used – Plugs in to existing Java I/O


Questions

server side tls (for http/2)...2015/09/24 · © 2015 pivotal software, inc. all rights reserved. 2...

Documents