FTPS Transfer Fault Query | Thales IoT Developer Community
February 1, 2016 - 10:45pm, 7314 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
Hi Bob,
it could be like you said certificate problem. Have you set certificate for your module? If you haven't it would maybe help to check AT^SJMSEC Java Midlet Security chapter in AT command document. But if you will try to set certificate for your module, you should be cerfull because you can lock your module and then you won't be able to install any midlet on it.
Regards,
Jure
Hello,
If you just want to connect to some FTPS server to have the secure data transfer and you don't need to verify the server certificate then you don't need to install any certificates on the module.
At the moment it is hard to say what is causing this problem.
Have you tried with another server for comparison? Maybe there's some problem or strange setting on the server you are using. If you had a possibility to trace on the server that could also be helpful. Have you checked what kind of cipher suite is used by the server?
Please send the ATI1 reply to verify your firmware version. You could also paste the log to show how you configure and use the connection.
If you are using URC's and CMEE=2 setting then you probably can see all that is possible to see. You could also try AT^SISE and AT+CEER commands after the connection failure.
What else is your Java application doing? Any other network connections? You could also try to reproduce this problem without Java.
Best regards,
Bartłomiej
At the moment I am sending the commands via HyperTerminal, before adding the commands to a Java Midlet.
So far only trying to do the bare minimum to check the connection. Even with the final code I do not intend to verify the server certificate - unlesss I have to. There are no certificates installed on the EHS6T module.
CMEE=2 is already being used.
At the moment I do not have another FTPS Server to try.
I do not have any information on what cipher suites are used on the FTPS Server I am using - trying to gather as much information from my end first.
AT Commands and their responses
ati1
Cinterion
EHS6
REVISION 02.000
A-REVISION 00.000.03
OK
at+cmee=2
OK
at^sics=0,"conType","gprs0"
OK
at^sics=0,"passwd","passwd"
OK
at^sics=0,"apn","everywhere"
OK
at^siss=1,srvtype","ftp"
OK
at^siss=1,"conid",0
OK
at^siss=1,"address","ftps://ftp.website.com/sftp;type=a"
OK
at^siss=1,"user","*****"
OK
at^siss=1,"passwd","****"
at^siss=1,"files","Test.txt"
OK
at^siss=1,"cmd","put"
at"siss?
^SISS:0,"srvType",""
^SISS:1,"srvType","FTP"
^SISS:1,"conID","0"
^SISS:1,"address","fpps:ftp.website.com/sftp:type=a"
^SISS:1,"tcpMR","10"
^SISS:1,"tcpOT","6000"
^SISS:1,"user","****"
^SISS:1,"passwd","****"
^SISS:1,"Files","Test.txt"
^SISS:"cmd","put"
^SISS:2,"srvType",""
^SISS:3,"srvType",""
^SISS:4,"srvType",""
^SISS:5,"srvType",""
^SISS:6,"srvType",""
^SISS:7,"srvType",""
^SISS:8,"srvType",""
^SISS:9,"srvType",""
OK
at^siso=1
OK
^SIS:1,0,2100,"Ftp open(ftp.website.com:990)"
^SIS:1,0,50,"Fatel: Service has detected an internal error"
at+ceer
+CEER:"No report available"
OK
at^sise=1
^SISE:1,100,"Socket-Error:0"
OK
Hello,
The log seems correct. Something bad probably happens during the connection establishment or just after that.
The firmware that you have on the module is not latest. There are updates for release 2 and there's release 3 available.
But I'd also try to test with some other server.
Regards,
Bartłomiej
Using Filezilla I can connect to the FTPS Server.
The encryption used on the FTPS Server is 'Require explicit FTP over TLS'.
Presumably this encryption method can be handled ??
Tried another FTPS Server, but still no success, and with slightly different response:
^SIS: 1,0,2100, "FTP open(website2.com:990)"
After a delay of a minute or so:
^SIS: 1,0,14, "An established connection was aborted, possibly due to a data transmission"
at^sise=1
^SISE: 1,100,"Socket-Error:14"
OK
at+ceer
+CEER: "No report available"
Bob
Hello Bob,
By cipher suite I meant something like: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA. For Java you can find the list in the Java user's guide. Unfortunately there's no such list in the AT commands specification but I'm pretty sure that it's the same.
If you are using FileZilla please click the padlock on the right bottom of the window. You should be able to find the session details like for example: protocol TLS1.2, key exchange ECDHE-RSA, cipher AES-256-CBC, MAC SHA384.
The only public ftps server I have found has the parameters like I put in the example above and in the document there's only TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA without SHA384. I wasn't able to connect to it because the connection was reset by the server.
Please check your server.
Regards,
Bartłomiej
Hi, thank you for your feedback.
On the FTPS Server it gives the following:
Signature Algorithm: RSA-SHA256
Cipher: AES-256-CBC
Protocol: TLS1.0
Key Exchange: RSA
Public Key Algorithm: RSA with 2048 bits.
Comparing this with section 11.1 of the EHSx Java User Guide, though the format is conveniently different from the format given in FileZilla:
HTTP / SecureConnection over SSL version 3.0 and TLS versions 1.0, 1.1 and 1.2.
SHA-256 cipher suites:
TLS_RSA_WITH_AES_256_CBC_SHA256
My interpretation is that the above format corresponds to the format supported by FTPS Server?
There appears to be possible optional exchanges of Certificate / Certificate Request, Server Key Exchange, but these are sent after an initial Server ' ****** message, which is not been received by the Client EHS6T.
When the initial Open URC is received, is that just indicating that a connection has been made with the Server, but prior to and TLS/SSL negotiations - so appears to indicate operating in **** 0 ?
Although it would seem that there is a common protocol supported by both sides the Server '****** message is not been received, which would indicate what protocol would be used after the initial negotiation between both sides on what protocols are supported.
Is there anything else to try to find out what is going on ??
The FTPS Server is using TLS 1.0, is there a way of limiting the EHS6T to this version to see if this helps ??
Bob
After some reserch my impression is the problem may be due to the method of creating a TLS connection. It would appear the FTPS Server I am using requires a 'explicit TLS' connection, ie it initially connects on the standard FTP Port 21 before it switches to a TLS negotiation.
I think the 'Java way' is using an 'Implict TLS' connection, ie connecting direct to Port 990 and then try to do a TLS negotiation.
If the above is correct, is there a way I can connect to a FTPS Server that requires an 'Explicit' connection ??
Bob
Hello,
As far as I know the implicit method is used in FTPS connection over AT commands.
I'm not sure if we can be sure it this is the only problem at the moment. But in such case you would probably need to implement the connection by your own in pure Java without using AT commands. On the other hand this could also be a good test to use pure SocketConnection or SecureSocketConnection to connect to your server and check what will happen, if the connection will be established and some data will be sent by server.
Regards,
Bartłomiej
Hello
Thank you for your reply. Sounds as though this could involve a major re-write of my current program to do cater for an Explicit TLS connection. Are their any good examples / pointers to show how to implement an Explicit TLS connecton via SecureSocketConnections so I can see what is involved - don't want to redesign the wheel if I don't have to.
Bob
Pages