FTPS Transfer Fault Query | Thales IoT Developer Community
February 1, 2016 - 10:45pm, 8098 views
Using a EHS6T, using URC's, and calling AT commands within a Java program I have been able to successfully for a FTP transfer. Now I need to transmit to a FTPS Server.
I changed the ftp://address.co to ftps://address.com.
On issuing the command at^sis0 = 1, I get the URC's:
^SIS:1,0,2100,"FTP open(address.com:990)"
^SIS: 1,0,50."Fatal: Service has detected an internal error"
Thus I need to establish what is causing this error - would a SSL error cause this ??.
For a SSL transfer, is there anything else I need to set up - if yes, a link to any information would be appreciated - creation / installation etc.
Would differences in SSL certificates cause this type of error ??
I would appreciate any information on how to trace what is causing this issue.
Bob
Hello,
Generally Gemalto does not provide additional libraries so in such case some open source can be adopted if there's any.
I'm not the FTPS expert but after some more research I'm not sure if it is possible to implement it. It seems that after connecting to the regular port the client can (but don't have to) issue AUTH TLS command and then the TLS negotiation should start. If another connection would then be established on the secure socket that would be easy. But it seems that the TLS negotiation starts on the same connection - and in such case I don't see a way of transforming/upgrading the regular socket connection to secure connection with the existing API.
To check this scenario with FileZilla I have used the "ftpes" prefix. But you were initially connecting to port 990 which is FTPS port where TLS connection should be started without any previous requests. So maybe this is not the case here.
Regards,
Bartłomiej
Further research appears to indicates the main issue is trying to find a FTPS Hosting Server that supports the ciphers listed in the EHS6X Java user guide.
Is it possible to add additional Certificated Authority, CA, ciphers onto the EHS6T to support additional ciphers to those listed in section 11 of the EHS6T User Guide ??
Note: Only need to cover the security of any data transfers - ie not required for security of any Java modules - if that is possible. A certificate on the EHS6T is not required since all I am trying to do is support an existing cipher on an existing FTPS Server.
If this is possible are there any user guides / information on the process for doing this - the EHS6X Java User Guide does not provide sufficient guidance on what is required for support of additional ciphers.
I would appreciate any guidance on the above.
Bob
Hello,
Adding the additional cipher suites is not possible. There is no such functionality. The new algorithms would need to be added to the firmware probably and the new release would need to be prepared.
Regards,
Bartłomiej
Thank you for your reply. It appears the information in the Java User Guide is not clear, at least to me, since it indicates that you can:
i) "Add a Client Certificate on the module for Client-Verification of the HTTPS connection".
ii) "Add Certificate for Verification of the HTTPS Connections"
The FTP Server being the Host and the EHS6T module being the Client.
My interpretation was that :
(i) would have allowed installing a Client Certificate on the EHS6T for the SSL handshaking with a FTPS Server.
ii) would allow installing a Host certificate on the EHS6T - ie when configured as a FTPS Server.
The User Guide could do with examples in this area to illustrate the various configurations to make it clearer.
Bob
Hello,
You previously asked about the cipher suites that can be used by the module while communicating with the other hosts and this list is limited to the suites placed in the document. So you can communicate with the server that allows using these types of cipher suites. In that simple case no validation of server certificate is made, just the data connection is encrypted.
Besides that you can import the server certificate to the module in order to be able validate the server certificate during the connection to be sure that you really connected to the server you wanted to. You can also create your own certificate and load it to the module. With that the server could validate your certificate (it ***** to have your public key). You can also use your certificate for signing the MIDlets and allow only signed MIDlets to be installed.
So the cipher suite and certificate is not the same thing.
Regards,
Bartłomiej
Thank you for your reply.
However at the end of the day there may be multiple failure ***** possible.
The cipher is only one part, along with the Key Exchange, and MAC. It is only the MAC element that is different, which determines the number of security bits used. My assumption at the moment is that all elements are needed - the User Guide for the Protol / Key Exchange / cipher / Mac that is the closest only shows SHA, but not the number of bits security so not sure on how many bits of security there is for comparing with the SHA384 specified by the HTP hosting site. With the lack or URC information it is impossible to know which element(s) of the Protocol / Key Exchange / Cipher / MAC is actually causing an issue with the FTP Hosting sites I have found.
My understanding, admittedly limited, is that initially TLS handshaking is performed and if that 'passes' then a ******* message should be received by the Client (EHS6T) from the FTPS Server. However due to the limitation in the error messages generated at the EHS6T end I don't know whether this stage is successful or not - rightly or wrongly I would have thought I should have got a ******* urc message back, rather than just a 'FTP Server connection terminated' message .
Also it appears you can have issues if any of the optional TLS parameters are used by the FTPS Server.
Thus need to know how to ensure that minimum checking of any Server Certificate is enabled - at the moment I am not sure whether this is the default setting?.
Only when the initial TLS handshaking has completed succesfully then we are into any cipher issues.
This is why I am looking at both the Certificate and the Cipher since at the present I am unable to say if there is just a Cipher/ Key Exchange / MAC issue or whether there is also a Certificate issue.
Initially I am trying to set up the bare minimum just to initially get a system working before trying to add on any extras.
Bob
Hello,
I think that to get the ***** message from the FTP server (the one that is displayed in URC) the TLS negotiation connection must be finished and secure connection established. So if there is no message from server the problem probably is in TLS connection.
If there is no number after SHA then the lowest version should be considered.
If you sent me the server address I could try to connect to it with my device.
Regards,
Bartłomiej
Hi
I use a 1and1 FTPS Server:
Server address: ftp://rg-jlf-diags.co.uk
Cipher suite details:
Protocol: TLS1.2
Key Exchange: ECDHE-RSA
Cipher: AES-256-CBC
MAC: SHA384
As indicated previously apart from the MAC value this matches one of the Cipher suite valus shown in section 11 of the EHS6T User Guide.
Bob
Hello,
It seems that this server is using the same cipher suite that the one I was trying (test.rebex.net).
It is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 which is not supported.
The similar supported cipher suites are:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
However I was able to connect to your server on standard FTP port without TLS and make the logging attempt.
While trying the 990 port the connection was not successful. With FileZilla it was working.
I have also traced the traffic and the result was that the module did not manage to send 'Client ****** message. It sent 'PSH, ACK' packet on which the reply was 'FIN, ACK'.
So for now it seems that at least you should be able to connect without TLS to that particular server.
Regards,
Bartłomiej
Hi
Thank you for your reply, this is is what I had also found - which seems strange since you need to change the configuration of the FTP Server to add the certificate for the TLS secure setting - but then you find you can still get access via standard FTP - which seems to go against the reason for adding a TLS connection in the first place - security of data transfer and also security of data on the FTP Server!!.
Bob