1. Transport Layer Security (TLS) v1.3 Support in Java
2018 CodeOne
DEV5945
Brad Wetmore
Xue-Lei Fan
Principal Members of Technical Staff
Oracle, Java Security Libraries/Java Core Platform
October 22, 2018

2. Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, timing, and pricing of any features or functionality described for Oracle’s products may change and remains at the sole discretion of Oracle Corporation.

3. QUICK SSL/TLS Overview

4. What is TLS and SSL (Secure Sockets Layer)?
A Secure Communications Channel Between Two Peers
Features:
Authentication (Peer Identification)
Confidentiality (Data Encryption)
Integrity Protection (Checksum/Hash)
Two Main Components
Handshake Protocol
Authenticates Parties, Negotiates Crypto Modes and Keys
Record Protocol
Uses Handshake Results to Protect Data

5. Network Stack Client Server HTTP Other Applications HTTP Other
SSL/TLS
SSL/TLS
TCP
TCP IP IP
Network
Network

6. TLS Cryptographic Fundamentals
Key Exchange/Key Agreement
Asymmetric Encryption (Public/Private Key)
Slow: used to exchange Symmetric keys over untrusted channels
Examples: RSA, Diffie-Hellman, Elliptic Curve Diffie-Hellman, etc.
Ciphers
Symmetric Encryption
Fast: keys derived from above
Examples: AES, DESede (aka 3DES), RC4, DES, etc.
Message Authentication Code (MAC)
Hash/Checksums with a private initial state (also derived from above)
Examples: MD5, SHA1, SHA256/384/512, etc.

7. Key Exchange/Agreement
How TLS Operates
Network
Client
Server
Key Exchange/Agreement
Keys
Keys
Cipher
Cipher
Encryption
Network Packet
Network Packet
MAC
Integrity Protection
MAC

8. SSL 3.0/TLS 1.0-1.2 Handshaking Messages
Client SSLv3.0/TLSv Server
ClientHello >
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
< ServerHelloDone
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished >
< Finished
Application Data < > Application Data

9. SSL/TLS Historical Highlights
SSL version 1.0 (mid-1994): Netscape
Several Flaws, Never Released
SSL version 2.0 (1995): Netscape
Single certs, key lengths for auth/ciphers (export), MD5
SSL version 3.0 (1996): Netscape (RFC historical)
Microsoft introduced competing protocols (PCT/STLP)
Netscape/Web Security Community vs. Microsoft’s Huge Base

10. Historical Highlights (cont.)
TLS version 1.0 (RFC 2246, 1999): IETF
Very similar to SSLv3, but not interoperable
Took a long time to gain consensus
Different aspirations and protocol interdependencies
TLS version 1.1 (RFC 4346, 2006): IETF
Protection against Cipher Block Chaining (CBC) IV attacks and Padding Error Handling
TLS version 1.2 (RFC 5246, 2008): IETF
Replacement of PseudoRandom Functions (PRF), MD5/SHA1 combo no longer used, indication of acceptable hash/signature algs, new ciphersuites, updated SHA-2 MAC protection, etc.
Is current TLS “Best Practice”

11. Why is TLS 1.3 Needed? RFC 7627 SSLv3/TLSv1.0/ TLSv1.1/TLSv1.2
POODLE
RFC 7919

12. 25 Years of Vulnerability Research
BEASTs and POODLES and FREAKs, OH MY!!!
TLS 1.2 and earlier versions have had many challenges over 20+ years
Lots of known (and cleverly named) attacks – wikipedia.org, RFC 7457
CBC attacks: BEAST – addressed by “1/n-1 fix”
Compression attacks: CRIME, BREACH (JSSE doesn’t use compression)
Renegotiation attacks - addressed by RFC 5746
Padding Oracle attacks: POODLE, Lucky 13
RC4 attacks: Bar Mitzvah
RSA-related attacks
Weak Diffie-Hellman parameters - addressed by RFC 7919
Triple handshake attacks – addressed by RFC 7627
Downgrade attacks – FREAK, Logjam
Weak ciphers – Sweet 32

13. Why is TLS 1.3 Needed? SSLv2.0 was prohibited by RFC 6176 (March 2011)
Older Protocols are Being Phased Out
SSLv2.0 was prohibited by RFC 6176 (March 2011)
SSLv3.0 was deprecated by RFC 7568 (June 2015)
No Acceptable Record Protection
CBC and non-deterministic padding issue (POODLE)
No acceptable stream ciphers (RC4 biases)
Broken Key Exchange (Man-In-The-Middle)
Previous TLS Hacks Used Extensions
Extensions NOT available in SSLv3.0

14. Why is TLS 1.3 Needed? (cont.)
Older Protocols are Being Phased Out
TLS version 1.0/1.1 are also rapidly being phased out
IETF TLS WG Draft to Deprecate TLS 1.0 and 1.1: “draft-moriarty-tls-oldversions-diediedie-00”
Requires 3DES suites, no AEAD ciphers, too many “active” versions
Microsoft Edge/IE (First 1/2 of 2019), Chrome (January 2020), Firefox/Safari (March 2020)
Payment Card Industry Security Standards Council (PCI SSC) obsoleted TLS 1.0 (June 2018)
Use of TLS 1.2 over 1.1 is strongly preferred
HTTP/2 (RFC 7540) requires TLS 1.2 w/ “Blacklisted ciphersuites” or TLS 1.3+
3GPP 5G (Telecom Standard): TLS 1.3 is mandatory and TLS 1.1 is removed
NIST.org turned off TLS 1.0 (Feb 2017), GitHub drops TLS 1.0 and 1.1 (Feb 2018)
TLS 1.2 is 10 years old!
Needed updating with latest crypto practices/advancements

15. TLS 1.3 Details

16. How does TLS 1.3 differ from TLS 1.2?
IETF TLS Working Group produced 28 drafts over 4.5 years
TLS 1.3 (RFC 8446, August 2018) is a major overhaul with 2 primary advantages
Enhanced Security
Improved Speed

17. Enhanced Security Remove support for old broken forms of cryptography
Less is Safer
Remove support for old broken forms of cryptography
RSA key transport (no forward secrecy, timing attacks)
CBC mode cipher suites
RC4 stream cipher
SHA-1 hash function (deprecated in favor of SHA-2)
Arbitrary Diffie-Hellman groups
Clean up unsafe features
Compression
Renegotiation

18. Enhanced Security More modern crypto algorithms
RSASSA-PSS signature algorithms
ChaCha20/Poly1305 cipher
x25519/x448 key agreement
Ed25591/Ed448 signature algorithms
New TLS version negotiation and downgrade protection
More of handshake is encrypted

19. TLS 1.0-1.2 vs. 1.3 Handshaking Messages
Client SSLv3.0/TLSv Server
ClientHello >
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
< ServerHelloDone
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished >
< Finished
Application Data < > Application Data
Client TLSv Server
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* >
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
< [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} >
[Application Data]< > [Application Data]
+ Important Extensions {} Encrypted Handshake Msgs
* optional/situational [] Encrypted App Msgs

20. Improved Speed New handshake model Simple is Faster
TLS 1.3 can use 1-Round Trip Time (RTT) (without pre-shared key) or 0-RTT (with pre-shared key)
TLS 1.2 requires 2-RTT (Round Trip Times) for a complete handshake
Shared secrets are derived earlier
More effective key update

21. TLS 1.3 in JDK/JSSE

22. JDK’s TLS 1.3 Implementation
Goal: an interoperable TLS 1.3 implementation with all required features
New algorithm names
SSLContext algorithm: TLSv1.3
TLS protocol name: TLSv1.3
Cipher suites: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384
Integrated into JDK 11 on June 25, 2018
54,000 lines TLS implementation code
69,289 lines overall (test/make/etc.)

23. Developed Under Java Enhancement Proposal (JEP) Process
BugID
Title
JDK
JEP 332: Transport Layer Security (TLS) 1.3
JDK
JEP 324: Key Agreement with Curve25519 and Curve448 (JCE Only)
JDK
JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms (JCE Only)

24. JEPs in the Java SE Security Conceptual Diagram JSSE/JCE
Tools
APIs and Libraries
keytool
Java Language and Runtime Security
JAAS
policytool
GSSAPI/Kerberos
XML Signature
JSSE (SSL/TLS)
SASL
JCE (crypto)
PKI
332
324
329
= JDK Enhancement-Proposal
JEP

25. How to Use TLS 1.3: By Default
Get TLSv1.3 without modification if using default settings on JDK 11:
// Can override with jdk.tls.client.protocols or jdk.tls.server.protocols
SSLSocketFactory sslSocketFactory = SSLSocketFactory.getDefault();
SSLSocket sslSocket = sslSocketFactory.createSocket(“ 80);
SSLContext sslContext = SSLContext.getDefault(); // or SSLContext.getDefault(“TLS”);
SSLEngine sslEngine = sslContext.createSSLEngine(“ 80);
HttpClient client = HttpClient.newBuilder().version(Version.HTTP_2).build();

26. How to Use TLS 1.3: “Correcting” Hard-Coded Values
If app asks for a specific SSLContext, it may need updating:
SSLContext sslContext = SSLContext.getInstance(“TLSv1.3”);
If specific context/protocols/ciphersuites were requested, may need to update the enabled lists
// TLS_AES_128_GCM_SHA256 (new) vs TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (old)
-Dhttps.protocols=“TLSv1.3,…” // HttpsURLConnection
-Dhttps.cipherSuites=“TLS_AES_128_GCM_SHA256,…”
SSLParameters params = new SSLParameters(
new String[] { “TLS_AES_128_GCM_SHA256“, …}, // Enabled Ciphersuites
new String[] { “TLSv1.3”, … }); // Enabled Protocols
[sslSocket,sslEngine].setSSLParameters(params);
HttpClient client = HttpClient.newBuilder().version(Version.HTTP_2).sslParameters(params).build();

27. TLS 1.3 Features: Where Are We?
Required Features
Optional Features
New handshake model
JDK 11
HKDF (RFC 5869)
FFDHE (RFC 7919)
JDK 10/9.0.4/8u161
Key Usage limit
RSASSA-PSS
AES-CCM (RFC 6655)
EdDSA (RFC 8032)
JDK 12
X25519/x448 (RFC 7748) 11
ChaCha20/Poly1305 (RFC 7539)
SCT (RFC 6962)
0-RTT
Vulnerable?
Post-handshake authentication

28. Extensions: Where Are We?
Optional
Mandatory/Required
max_fragment_length (RFC 6066)
JDK 7
status_request (RFC 6066)
JDK 9
ALPN (RFC 7301)
use_srtp (RFC 5764)
heartbeat (RFC 6520)
signed_certificate_timestamp (RFC 6962)
client_certificate_type (RFC 7250)
server_certificate_type (RFC 7250)
padding (RFC 7685)
early_data (TLS 1.3)
certificate_authorities (TLS 1.3)
oid_filters (TLS 1.3)
post_handshake_auth (TLS 1.3)
supported_versions (TLS 1.3)
JDK 11
cookie (TLS 1.3)
signature_algorithms (TLS 1.3)
signature_algorithms_cert (TLS 1.3)
supported_groups (RFC 4492/7919)
JDK 7
key_share (TLS 1.3)
server_name (RFC 6066)
pre_shared_key (TLS 1.3)
psk_key_exchange_modes (TLS 1.3)

29. Configuration Properties
Existing & New System Properties to Override Enabled Protocol Defaults
Existing client-side
jdk.tls.client.protocols=“TLSv1.3,TLSv1.2”
New JDK 11 server-side
jdk.tls.server.protocols=“TLSv1.3,TLSv1.2”
New Security Property “jdk.tls.keyLimits”
Limit the transportation key usage amount (default 128 Gb)
jdk.tls.keyLimits=AES/GCM/NoPadding KeyUpdate 2^37

30. New Debugging Mechanism (We always suggest using: -Djavax. net
New Debugging Mechanism (We always suggest using: -Djavax.net.debug=all)
See Example in JDK 11 JSSE Reference Guide: Debugging TLS Connections
Old
Use System.out or System.err
*** ServerHello, TLSv1.2
RandomCookie: random_bytes = {5A 4E F9 E3 0C C5 … C0 FB CA C5 DD 6E 79 DB FF AE C }
Session ID: {90, 78, 249, 227, 53, 127, …, 168, 150, 161, 217, 57, 214, 248, 78, 138, 158}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
New
Use System.err
javax.net.ssl|DEBUG|01|main| :51: PDT|ServerHello.java:362|Produced ServerHello handshake message (
"ServerHello": {
"server version" : "TLSv1.2",
"random" : " A B … 5A ED 01 BA E3 DB 9E 4C 81 C ",
"session id" : "57 D7 69 7B 34 C8 5F 67 … E 7F A6 54 C8 A1 9C A0 3D 24",
"cipher suite" : "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C)",
"compression methods" : "00",
"extensions" : [
"renegotiation_info (65,281)": {
"renegotiated connection": [<no renegotiated connection>]
}]})

31. More Enhancements Remove unsafe KRB5 cipher suites
Support stateless HelloRetryRequest
Used by server if the client does not provide sufficient crypto parameters
Performance and security improvement
TLS 1.3 is implemented in compatibility mode (RFC 8446: Appendix D)
Use non-empty session ID
Use/allow dummy change_cipher_spec record
Supports version downgrade protection mechanism
A limited protection against version downgrade attacks.

32. Compatibility Risks

33. TCP/IP: Half-Closed Feature
Client
Server
Fin
Ack
Server can send
Fin
Ack

34. SSL 3.0/TLS 1.0-1.2: No Half-Closed Feature
Peer must also close when it receives a close_notify Alert
Client
close_notify
Server
close_notify

35. TLS 1.3: Half-Closed Now Supported
Client
close_notify
Server
Server can send
close_notify

36. Compatibility Risks
Half-close policy in TLS 1.3 vs duplex-close policy in TLS 1.2
When a connection is no longer needed, the client and server applications should each close both sides of their respective connection
A new System Property, “jdk.tls.acknowledgeCloseNotify” if TLS 1.2 close_notify behavior is needed

37. Compatibility Risks
TLS 1.3 uses pre-defined X.509 certificate key and signature algorithms
The mandatory signature_algorithms_cert extension requires that only pre-defined signature algorithms are used for certificate authentication
In practice, however, an application may use non-supported signature algorithms
SHA-1 for legacy use only
No MD5 signature algorithms supported
DSA is deprecated
The DSA signature algorithm is not supported in TLS 1.3
If a client or server is configured with only DSA certificates, it cannot use TLS 1.3
SHA224-based Signature algorithms are also deprecated

38. Countermeasures
Customize default enabled protocols with System Property:
jdk.tls.client.protocols (“TLSv1.2”)
jdk.tls.server.protocols (“TLSv1.2”)

39. Impact of RSA Key Exchange Deprecation: Monitoring/Middleware Boxes/Stored Traffic/etc.
TLS v
ClientHello >
ServerHello
Certificate*
< ServerHelloDone
ClientKeyExchange
[ChangeCipherSpec]
Finished >
< Finished
Application Data < > Application Data
SNOOP
Cert with Server’s Public Key
Client chooses Session Key
Encrypts with Server Pub Key
Session Key Used to
Initialize All Crypto
Server Decrypts Session Key/
Session Key Used to
Initialize All Crypto
Server’s Private Key
Network Traffic
Network Traffic

40. Status of TLS 1.3 (RFC 8446, August 2018) Available Implementations To Date (Oct. 19, 2018)
NSS (8446: version )
OpenSSL (8446: version 1.1.1)
BoringSSL/Google (8446: fork of OpenSSL)
GnuTLS (draft 28: version 3.6.3)
Tris/Cloudflare (8446)
Fizz/Facebook (draft -28)
> 50% of Facebook traffic now uses TLS 1.3 (mobile app)
Firefox (draft -28)
Chrome (draft -23/-28)
Final Chromium-side changes went in mid- Aug 2018
Uses BoringSSL
Opera (depends on Chromium)
SChannel/IE/EDGE/Mobile (in development)
Safari (draft -18)

41. “Can I Use” TLS 1. 3. (Source: https://caniuse

42. Interoperability and Compatibility Testing
Ensuring compatibility for TLS 1.2/1.1/1.0
Interoperability testing with other implementations
OpenSSL/NSS/BouncyCastle, Firefox/Chrome
Existing TLS regression/infra testing, JCK testing
Third party compatibility testing
MySQL
Jetty/Netty/ElasticSearch
No major issues so far. Improvements ongoing:
JDK : mismatching input stream close behavior (JDK 12)
JDK : More effective TLS records delivery (JDK 12)
JDK : SO_LINGER and socket close (JDK 12)

43. TLS 1.3 Regression and Interoperability Testing
Regression testing
Existing test cases using default TLS version (TLS 1.3 is default in JDK 11)
New TLS 1.3 test cases
HttpClient (upgraded to support TLS 1.3) testing
TLS 1.3 Interop testing
OpenSSL (RFC 8446/v1.1.1)
Firefox (draft 28)
Third party TLS 1.3 interop test servers
Challenge: RFC finally finished, so impls are shaking out interop bugs

44. Wrapup/Futures
(Implementation Internals If Time Allows)

45. What’s next? Improvement of TLS 1.3 implementation
JDK
Public APIs for better control of TLS 1.3 behaviors
JDK
Additional features
AES-CCM (RFC 6655)
JDK (JCE)/JDK (JSSE)
EdDSA (RFC 8032)
JDK (JCE)/JDK (JSSE)
X25519/x448 (RFC 7748)
JDK (JSSE)
ChaCha20/Poly1305 (RFC 7539)
JDK (JSSE)

46. What’s next? (cont.) SCT (RFC 6962)
JDK
Post-handshake authentication (TLS 1.3)
JDK
Using raw public keys (RFC 7250)
JDK
Certificate Authorities (TLS 1.3)
JDK
OID Filters (TLS 1.3)
JDK

47. Beyond TLS 1.3 Sun-setting TLS 1.0 and 1.1
DTLS1.3 (currently at draft 28)

48. More Information Open JDK (https://jdk.java.net/11)
The same features and performance as Oracle JDK, but with GPLv2+CP License
Oracle JDK  (
Oracle Customers, uses OTN License
JDK 11 Docs Security Guides
Mailing List: OpenJDK Developer Q’s only - NOT FOR GENERAL SUPPORT!

49. Filing TLS Bugs Cat/Subcat: security-libs/javax.net.sslor
(OpenJDK Developer ID required)

50. Other Recommended Sessions
DEV5996: High-Speed Cryptography in Java: x25519, Poly 1305, and EdDSA
Monday 12:30 PM – Moscone West, Room 2004 (This Room)

51. Q & A

52. JSSE Implementation Details/Internals
Non-OpenJDK Developers: We’ll wake you in <TBD> minutes…

53. Implementation Details – Code Locations Stay the Same
API: javax/net, javax/net/ssl
Impl: sun/security/ssl
HttpsURLConnection: sun/net/www/protocol/https
HttpClient (2.0): java/net/http
jdk/internal/net/http, sun/net/www/http

54. Implementation Details – Major Classes in sun/security/ssl
SSLContextImpl
TLSContext (default), TLS1[0-3]Context
Protocol specific settings (active protocols/ciphersuites/etc)
SSLSocketImpl/SSLEngineImpl
main I/O classes
SSLHandshake/SSLExtension
Enum: mapping of messages + functions to call for each protocol
Various Handshaking Messages
ClientHello, ServerHello, EncryptedExtensions, ServerHelloDone, Certificate, ServerKeyExchange, CertificateRequest, CertificateVerify, Finished, KeyUpdate, etc.
Producers, Consumers, Message Handling
Different handlers/message formats for different protocol versions
How to handle missing messages

55. Implementation Details – Major Classes
TransportContext
I/O Transport structures used by SSLSocket/SSLEngine
Configuration settings (protocols/ciphersuites/etc), active session, ALPN values, Input/OutputRecords, HandshakeContexts
Map of required/optional handshake messages
HandshakeContext
Active handshaking data
configurations, available protocols/ciphersuites, hashing, sessions/credentials under construction, nonces, etc.
HandshakeHash
Keeps track of all handshake hash data
SSLCipher
Encryption/decryption routines called from Input/OutputRecord
SSLLogger
New Logging mechanism
System.getLogger("javax.net.ssl");

56. High-level I/O & Handshake Object Layout
SSLEngine
Message Consumer
List
Message
Producer List
SSLEngineImpl
TransportContext
HandshakeContext
HandshakeInputStream
HandshakeOutputStream
SSLEngineInputRecord /
OutputRecord
SSLEngineOutputRecord/
OutputRecord
Handshake
Fragment(s)

57. Handshake Message Consumer/Producer Architecture
enum SSLHandshake { }
enum Name
byte id
String name
handshakeConsumers []
handshakeProducers []
handshakeAbsence []
ServerHello
0x02
“server_hello”
ServerHello.hsConsumer -> SSLv3-TLSv1.2
ServerHello.t13hsProducer -> TLSv1.3
ServerHello.t12hsProducer-> SSLv3-TLSv1.2
<null>

58. Wakey Wakey!!!
Please nudge your non-OpenJDK developer neighbor…

59. Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, timing, and pricing of any features or functionality described for Oracle’s products may change and remains at the sole discretion of Oracle Corporation.