Refactoring TLS code

[Xuelei Fan]

Hi Ben,

The tutorial is impressive to me.

Thanks for the reporting, I filed a RFE for the tracking:
    https://bugs.openjdk.java.net/browse/JDK-8245983

Xuelei

On 5/27/2020 7:23 AM, Ben Smyth wrote:
> 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