Question:
I recently released a new version of my application which uses an FTP connection. The old version used FTP2 v9.2.1 and the new one uses v9.3.0, though I have also tried v9.4.1.42. I am using Chilkat C/C++ Libraries for VC++ 10.0 (win32 and x64).
I have a problem in the new version of my program when connecting to a FTP server using TLS. The first time the program connects, everything works OK. However, if the program tries to make a second connection, it fails during the TLS handshaking. The old version of the program does not have this problem and can connect any number of times.
The log file for a successful connection using v9.4.1.42 looks like this (excerpt):
sentCommand: AUTH TLS
receivedResponse: 234 AUTH TLS OK.
ssl_protocol_3: 0
ConvertToTls_4:
clientHandshake:
clientHelloMajorMinorVersion: 3.1
buildClientHello:
majorVersion: 3
minorVersion: 1
numRandomBytes: 32
sessionIdSize: 0
numCipherSuites: 10
numCompressionMethods: 1
--buildClientHello
readIncomingTls_serverHello:
processTlsRecord:
processHandshake:
handshakeMessageType: ServerHello
handshakeMessageLen: 0x46
processHandshakeMessage:
MessageType: ServerHello
Processing ServerHello...
ServerHello:
For a failed connection, it looks like this:
sentCommand: AUTH TLS
receivedResponse: 234 AUTH TLS OK.
ssl_protocol_3: 0
ConvertToTls_4:
clientHandshake:
clientHelloMajorMinorVersion: 3.1
buildClientHello:
majorVersion: 3
minorVersion: 1
numRandomBytes: 4
sessionIdSize: 0
numCipherSuites: 10
numCompressionMethods: 1
--buildClientHello
readIncomingTls_serverHello:
processTlsRecord:
processAlert:
TlsAlert:
level: fatal
descrip: decode error
--TlsAlert
Closing connection in response to fatal error.
--processAlert
Notice that the numRandomBytes value is 4 instead of 32. According to the TLS spec, the client should provide 32 bytes of random data. I wonder whether the client is trying to send a session ID to resume its connection to the server and is generating the handshake block incorrectly. Or maybe Chilkat is just sending the wrong amount of random data.
Does anyone have any experience of this or any advice? Is there some way that I can prevent Chilkat from trying to resume a session?
Many thanks for your help.
My guess is that you are somehow calling CkSettings::cleanupMemory. The CkSettings::cleanupMemory should only be called at the very end of your C++ program, and only after all Chilkat objects have been destructed, and only when no other Chilkat objects will be created or used. The only real purpose for calling CkSetting::cleanupMemory is to help with memory leak detection. The Chilkat lib internally will utilize build-once / keep-in-memory tables for various tasks relating to different parts of functionality, ranging from Zip huffman tables, to character encoding/decoding lookups, and in this case IL_R250 random number generation.
Thanks for the response. I was calling cleanupMemory in the destructor of the connection class. I’ve moved it to be called only on program shutdown and the program can now connect multiple times. Thank you very much for your help and your quick response.