JSSE: SSLEngine reporting HandshakeStatus.FINISHED, disabling NewSessionTicket
TL;DR: Why does a client report HandshakeStatus.FINISHED twice? Can production of NewSessionTicket be disabled? A client (respectively server) becomes ready to encrypt application data upon completing their side of handshaking: "Once a side has sent its Finished message and has received and validated the Finished message from its peer, it may begin to send and receive Application Data over the connection" (RFC8446); a client completes handshaking upon wrapping a FINISHED message and a server completes upon unwrapping such a message. (There's an exception for 0-RTT data, and another for a server operating with reduced security.) Javadoc advises HandshakeStatus.FINISHED is reported when "a call to SSLEngine.wrap() / unwrap() ... finishes a handshake." As expected, * OpenJDK SSLEngine.wrap() reports HandshakeStatus.FINISHED on wrapping a client's (TLS) FINISHED message. By comparison, rather than report (server) handshake completion upon unwrapping a client's (TLS) FINISHED message, HandshakeStatus.NEED_WRAP is reported, a NewSessionTicket is produced on wrapping and * OpenJDK SSLEngine.wrap() reports HandshakeStatus.FINISHED on wrapping a server's (TLS) NewSessionTicket message. Upon receipt of which, * OpenJDK SSLEngine.unwrap() reports HandshakeStatus.FINISHED on unwrapping a server's (TLS) NewSessionTicket message. What does finishing a handshake mean in SSLEngine parlance? (I don't understand why a client should report finishing twice.) Can production of NewSessionTicket be disabled?
OpenJDK-TLS Manual: (Second) call for contributions
I've written an OpenJDK-TLS manual, intended to ease readers into the most recent TLS specification and OpenJDK's implementation. (At the very least, it helped me get to grips with the spec and the code!) I've made the manual available on GitHub (https://github.com/BenSmyth/tls-tutorial/) and a pdf is also available: https://bensmyth.com/files/Smyth19-TLS-tutorial.pdf I hope the manual will help you too. I'm far from perfect and I'm sure the manuscript has numerous deficiencies. Interesting aspects are omitted, because I didn't have the time, knowledge, or expertise to add them. In particular, my coverage of OpenJDK could be substantially improved and extended. I encourage you to improve the manuscript. Fix a typo. Patch grammar. Revise awkward, overcomplicated, or otherwise poorly-written passages, and correct my outright mistakes. Contribute an entire section, there's certainly a lot of scope regarding OpenJDK. Help evolve the manual. (Perhaps get in touch prior to writing an entire section! We should probably reach consensus on what to add.) Contributions will be recognised through acknowledgements or co-authorship. Best regards, Ben -- https://bensmyth.com/
TLS Manual: Call for contributions
I've written a TLS manual, intended to ease readers into the most recent specification. (At the very least, it helped me get to grips with the spec!) I've now made the manual available on GitHub: https://github.com/BenSmyth/tls-tutorial/ A pdf is also available (https://bensmyth.com/files/Smyth19-TLS-tutorial.pdf). I'm far from perfect and I'm sure the manuscript houses numerous deficiencies. Interesting aspects are omitted, because I didn't have the time, knowledge, or expertise to add them. For instance, the specification hasn't been entirely covered, as is documented; discussion of security guarantees are notably lacking; and an introduction to the underlying cryptography is absent. (E.g., some details on DHKE, AEAD, etc. would be grand.) Directions for further exploration are missing, hands-on teaching opportunities foregone. For instance, a Davies-style exploration of TLS on-the-wire, with notes on Wireshark and SSLKEYLOGFILE---perhaps as dirty as readers can get, without bursting-out soldering irons. Mistakes and issues are no doubt numerous. I encourage you to improve this manuscript. Fix a typo. Patch grammar. Revise awkward, overcomplicated, or otherwise poorly-written passages. Contribute an entire section. Help evolve the manual. (Perhaps get in touch prior to writing an entire section! We should probably reach consensus on what to add.) Contributions will be recognised through acknowledgements or co-authorship. Best regards, Ben -- https://bensmyth.com/
Refactoring TLS code
I have written a TLS 1.3 tutorial ( https://bensmyth.com/publications/2019-TLS-tutorial/) which includes source code from JDK 11. Whilst explaining the code, I noticed some possible refactoring that would simplify the (JDK 11 & current) code base: - createHkdfInfo is defined three times: SSLBasicKeyDerivation.createHkdfInfo could perhaps be dropped in favour of SSLSecretDerivation.createHkdfInfo (noting a slight difference regarding runtime exceptions), as can SSLTrafficKeyDerivation.T13TrafficKeyDerivation.createHkdfInfo (noting the need to supply 0x00 as the context). - ServerHello.T13ServerHelloProducer.produce and ServerHello.T13ServerHelloConsumer.consume each define code to changeclient/server handshake traffic secrets. The code is identical up to contexts, labels s_hs_traffic and c_hs_traffic, treatment of null in tricks to make the compiler happy (cf. return null; and return; in catch-branches), alpha-renaming of one variable, and whitespace (and some obsolete, commented-out code). - Similarly to the previous point, Finished.T13FinishedProducer.onProduceFinished and Finished.T13FinishedConsumer.onConsumeFinished define code to derive traffic secrets and corresponding traffic keys, (unsurprisingly) computations are similar. (The same is true for other secrets and traffic keys.) - CertificateVerify.onProduceCertificateVerify is defined for ServerHandshakeContext and ClientHandshakeContext, both instances are identical up to variables shc and chc (with the former using string "server" and the latter using "client" for logging). - Not really refactoring, but comment on ClientHello:1172 says extension key_share is ignored, when it isn't (extension psk_key_exchange_modes, pre_shared_key, and protocol_version are). My apologises if this mail is considered noise (or is simply wrong)---I figured suggestions for simplifying JDK's code base might be useful. Best regards, Ben
