Re: [twsocket] Using the SslFTPClient
> In response to the FEAT request, some servers just return "PROT" > and the current test for PROT P will always fail. > This is the minor change I have made to the FTP Client. It would > be nice if this could be added so I don't have to modify the > source after each update: I'll put it on my list, but may not be quick, very busy. The FTP stuff has not changed for two years except for a new Delphi release. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
In response to the FEAT request, some servers just return "PROT" and the
current test for PROT P will always fail.
This is the minor change I have made to the FTP Client. It would be nice
if this could be added so I don't have to modify the source after each
update:
Change this:
if Pos('PROT', Feat) = 1 then begin
if Feat = 'PROT' then
FSupportedExtensions := FSupportedExtensions +
[ftpFeatProt];
if Pos('C', Feat) > 5 then
FSupportedExtensions := FSupportedExtensions +
[ftpFeatProtC];
if (Pos('P', Feat) > 5) then
FSupportedExtensions := FSupportedExtensions +
[ftpFeatProtP];
end;
to this:
Define tempFeat at start of ControlSocketDataAvailable
Add ftpFeatProt to TFtpExtension
if Pos('PROT', Feat) = 1 then
begin
tempFeat := Feat;
Delete (tempFeat, 1, 4); //Just leave any parameters
if Length (tempFeat) = 0 then //It was just "PROT"
begin
FSupportedExtensions := FSupportedExtensions +
[ftpFeatProt];
end
else
begin
if Pos('C', tempFeat) > 0 then
FSupportedExtensions := FSupportedExtensions +
[ftpFeatProtC];
if Pos('P', tempFeat) > 0 then
FSupportedExtensions := FSupportedExtensions +
[ftpFeatProtP];
end;
end;
Regards
Graham
On 11/02/2018 21:16, Graham Powell wrote:
Thank you once again for your help. You are indeed correct. A search
on the Internet suggests the timeout could be between 30 and 120 seconds.
When I have finished all my testing, I show you what I have modified
in the SslFtpClient. Just a simple change to the processing of the
FEAT response regarding PROT. Some servers just return PROT and the
current detection of PROT P will always fail.
Regards
Graham
On 11/02/2018 14:40, Angus Robertson - Magenta Systems Ltd wrote:
I have set Active Mode and the Data Port Range to 1..10010
I connect to the Demo Server and click on the "Get" button.
I have a breakpoint where the Data Port number is allocated so I
can see it increment through the above range.
When it gets to 10010 it loops back to 1.
The next click on the "Get" button fails with the error that this
port (1) is in use.
This is standard windows behaviour, established ports do not close
instantly you close a connection, they go into time_wait state for
about 60 seconds in case packets are still floating around.
So you probably clicked past your range of 10 in one minute or so.
Just make the range 100 or 1,000.
Finding some users ports (1,024 up) in use is inevitable because so
many applications use them for internal purposes, so you need to always
retry failed connection, repeatedly. Also better to choose an obscure
range that others are less likely to be using than around 10,000.
Which is exactly why many people use my TMagFtp component, all this
stuff is long known and handled.
Angus
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
Yes please, an account might be useful to have, thank you. Graham On 12/02/2018 12:01, Angus Robertson - Magenta Systems Ltd wrote: The only reason I mentioned it was, as you may remember, my mission is to connect to a Linux FTP server using AUTH TLS. Everything is fine except if I select "Passive" mode and PROT=Private, I cannot login. I get SSL handshake errors. They suggested that I should use BLOCK mode in this instance. My reading suggests virtually no FTP clients or servers support MODE B. The header is only three bytes and no file name, so no idea how multiple files would be sent. It certainly will have no effect on SSL connections. You can test SSL against ftp.icstest.org, which is my ICS FTP server running the latest stuff. I can give you can account for uploads if you need it. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
> The only reason I mentioned it was, as you may remember, my > mission is to connect to a Linux FTP server using AUTH TLS. > Everything is fine except if I select "Passive" mode and > PROT=Private, I cannot login. I get SSL handshake errors. They > suggested that I should use BLOCK mode in this instance. My reading suggests virtually no FTP clients or servers support MODE B. The header is only three bytes and no file name, so no idea how multiple files would be sent. It certainly will have no effect on SSL connections. You can test SSL against ftp.icstest.org, which is my ICS FTP server running the latest stuff. I can give you can account for uploads if you need it. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
The only reason I mentioned it was, as you may remember, my mission is to connect to a Linux FTP server using AUTH TLS. Everything is fine except if I select "Passive" mode and PROT=Private, I cannot login. I get SSL handshake errors. They suggested that I should use BLOCK mode in this instance. I'm not so sure that this is the solution and may just tell them there are plenty of other combinations that work. Incidentally using the ICS SSL FTP Client demo with the Server demo does not have any issues with any combination of Active/Passive and Private/Clear. Regards Graham On 12/02/2018 11:18, Angus Robertson - Magenta Systems Ltd wrote: I see that the component supports MODE S and MODE Z. Is there any way it can, or will in the future, support MODE B (Block)? Block mode goes back to the RFC959 written over 40 years ago, before the internet really existed and FTP was used by mainframe computers. I've never really come across it until you mentioned it, but a little Googling suggests IIS FTP7 does actually support it, and it may be beneficial for lots of small files avoiding lots of separate data connections (particularly with SSL connection overhead). So perhaps it is a good idea to add to ICS, not easy and I certainly won't have time for several months, too busy adding Jose stuff like JWK, JWS, JWT, ACME and OAuth2, mostly for Let's Encrypt SSL certificates, then OpenSSL 1.1.1 and TLS/1.3, never mind my own projects. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
> I see that the component supports MODE S and MODE Z. Is there any > way it can, or will in the future, support MODE B (Block)? Block mode goes back to the RFC959 written over 40 years ago, before the internet really existed and FTP was used by mainframe computers. I've never really come across it until you mentioned it, but a little Googling suggests IIS FTP7 does actually support it, and it may be beneficial for lots of small files avoiding lots of separate data connections (particularly with SSL connection overhead). So perhaps it is a good idea to add to ICS, not easy and I certainly won't have time for several months, too busy adding Jose stuff like JWK, JWS, JWT, ACME and OAuth2, mostly for Let's Encrypt SSL certificates, then OpenSSL 1.1.1 and TLS/1.3, never mind my own projects. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
Hopefully the last question on this FTP client. I see that the component supports MODE S and MODE Z. Is there any way it can, or will in the future, support MODE B (Block)? Regards Graham On 11/02/2018 21:16, Graham Powell wrote: Thank you once again for your help. You are indeed correct. A search on the Internet suggests the timeout could be between 30 and 120 seconds. When I have finished all my testing, I show you what I have modified in the SslFtpClient. Just a simple change to the processing of the FEAT response regarding PROT. Some servers just return PROT and the current detection of PROT P will always fail. Regards Graham On 11/02/2018 14:40, Angus Robertson - Magenta Systems Ltd wrote: I have set Active Mode and the Data Port Range to 1..10010 I connect to the Demo Server and click on the "Get" button. I have a breakpoint where the Data Port number is allocated so I can see it increment through the above range. When it gets to 10010 it loops back to 1. The next click on the "Get" button fails with the error that this port (1) is in use. This is standard windows behaviour, established ports do not close instantly you close a connection, they go into time_wait state for about 60 seconds in case packets are still floating around. So you probably clicked past your range of 10 in one minute or so. Just make the range 100 or 1,000. Finding some users ports (1,024 up) in use is inevitable because so many applications use them for internal purposes, so you need to always retry failed connection, repeatedly. Also better to choose an obscure range that others are less likely to be using than around 10,000. Which is exactly why many people use my TMagFtp component, all this stuff is long known and handled. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
Thank you once again for your help. You are indeed correct. A search on the Internet suggests the timeout could be between 30 and 120 seconds. When I have finished all my testing, I show you what I have modified in the SslFtpClient. Just a simple change to the processing of the FEAT response regarding PROT. Some servers just return PROT and the current detection of PROT P will always fail. Regards Graham On 11/02/2018 14:40, Angus Robertson - Magenta Systems Ltd wrote: I have set Active Mode and the Data Port Range to 1..10010 I connect to the Demo Server and click on the "Get" button. I have a breakpoint where the Data Port number is allocated so I can see it increment through the above range. When it gets to 10010 it loops back to 1. The next click on the "Get" button fails with the error that this port (1) is in use. This is standard windows behaviour, established ports do not close instantly you close a connection, they go into time_wait state for about 60 seconds in case packets are still floating around. So you probably clicked past your range of 10 in one minute or so. Just make the range 100 or 1,000. Finding some users ports (1,024 up) in use is inevitable because so many applications use them for internal purposes, so you need to always retry failed connection, repeatedly. Also better to choose an obscure range that others are less likely to be using than around 10,000. Which is exactly why many people use my TMagFtp component, all this stuff is long known and handled. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
> I have set Active Mode and the Data Port Range to 1..10010 > I connect to the Demo Server and click on the "Get" button. > I have a breakpoint where the Data Port number is allocated so I > can see it increment through the above range. > When it gets to 10010 it loops back to 1. > The next click on the "Get" button fails with the error that this > port (1) is in use. This is standard windows behaviour, established ports do not close instantly you close a connection, they go into time_wait state for about 60 seconds in case packets are still floating around. So you probably clicked past your range of 10 in one minute or so. Just make the range 100 or 1,000. Finding some users ports (1,024 up) in use is inevitable because so many applications use them for internal purposes, so you need to always retry failed connection, repeatedly. Also better to choose an obscure range that others are less likely to be using than around 10,000. Which is exactly why many people use my TMagFtp component, all this stuff is long known and handled. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
Sorry, more questions on this topic. I am testing with the SslFtpClient demo and the SslFtpServer demo programs and am currently interested in setting the Data Port range. I have set Active Mode and the Data Port Range to 1..10010 I connect to the Demo Server and click on the "Get" button. I have a breakpoint where the Data Port number is allocated so I can see it increment through the above range. When it gets to 10010 it loops back to 1. The next click on the "Get" button fails with the error that this port (1) is in use. So which end is not behaving itself? I looks like the Data Port is not being freed up. Any clues? Graham On 23/01/2018 20:53, Graham Powell wrote: First a reply to Nicholas Machand as a reply to your e-mail bounces: The "KeepAliveSecs" makes no difference. I have turned off the Windows Firewall - No difference. I have disconnected the Internet router, just left with a simple switch connecting the computers - No difference. Graham On 23/01/2018 16:00, Jörg Fischer wrote: Hi, Am 23.01.2018 um 15:54 schrieb Graham Powell: I don't think that's the problem as the ICS FTP demo setup I am currently using for test only has one connection. Somehow my network or Windows has a data limit for each session. Send details please.. ;-) Note that this rings a bell here: Some peer-to-peer blockers work like that. You may want to check the filters of your internet router, or antivirus software on your PC. -- Jörg Graham On 23/01/2018 14:23, Angus Robertson - Magenta Systems Ltd wrote: Any clues as to whether or not there is something wrong with the ICS components or is it my setup? Sorry no, I download hundreds of files a day from my servers using secure FTP, totalling hundreds of megs, and problems are very rare. I suggest you try and use FTP with a single component, instead of two. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
> It would appear that this is a Windows Firewall issue after all. > I am using Windows 10 and if I turn off the Private AND Public > Firewalls, the problem of "peer reset" after a certain number of > transfers does not occur. Is Windows Firewall aware of your application? You can add it to the exception list so the firewall ignores it. Or open the ports you needs, which is harder for FTP due to the data channel. https://msdn.microsoft.com/en-us/library/aa366421.aspx I wrote a MagFirewall component a couple of years ago but have not yet used it in it's intended application, so not sure how much I ever tested it. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
First a reply to Nicholas Machand as a reply to your e-mail bounces: The "KeepAliveSecs" makes no difference. I have turned off the Windows Firewall - No difference. I have disconnected the Internet router, just left with a simple switch connecting the computers - No difference. Graham On 23/01/2018 16:00, Jörg Fischer wrote: Hi, Am 23.01.2018 um 15:54 schrieb Graham Powell: I don't think that's the problem as the ICS FTP demo setup I am currently using for test only has one connection. Somehow my network or Windows has a data limit for each session. Send details please.. ;-) Note that this rings a bell here: Some peer-to-peer blockers work like that. You may want to check the filters of your internet router, or antivirus software on your PC. -- Jörg Graham On 23/01/2018 14:23, Angus Robertson - Magenta Systems Ltd wrote: Any clues as to whether or not there is something wrong with the ICS components or is it my setup? Sorry no, I download hundreds of files a day from my servers using secure FTP, totalling hundreds of megs, and problems are very rare. I suggest you try and use FTP with a single component, instead of two. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
Hi, Am 23.01.2018 um 15:54 schrieb Graham Powell: > I don't think that's the problem as the ICS FTP demo setup I am > currently using for test only has one connection. > Somehow my network or Windows has a data limit for each session. > Send details please.. ;-) Note that this rings a bell here: Some peer-to-peer blockers work like that. You may want to check the filters of your internet router, or antivirus software on your PC. -- Jörg > Graham > > On 23/01/2018 14:23, Angus Robertson - Magenta Systems Ltd wrote: >>> Any clues as to whether or not there is something wrong with the >>> ICS components or is it my setup? >> Sorry no, I download hundreds of files a day from my servers using >> secure FTP, totalling hundreds of megs, and problems are very rare. >> >> I suggest you try and use FTP with a single component, instead of two. >> >> >> Angus >> > -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
I don't think that's the problem as the ICS FTP demo setup I am currently using for test only has one connection. Somehow my network or Windows has a data limit for each session. Graham On 23/01/2018 14:23, Angus Robertson - Magenta Systems Ltd wrote: Any clues as to whether or not there is something wrong with the ICS components or is it my setup? Sorry no, I download hundreds of files a day from my servers using secure FTP, totalling hundreds of megs, and problems are very rare. I suggest you try and use FTP with a single component, instead of two. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
> Any clues as to whether or not there is something wrong with the > ICS components or is it my setup? Sorry no, I download hundreds of files a day from my servers using secure FTP, totalling hundreds of megs, and problems are very rare. I suggest you try and use FTP with a single component, instead of two. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
Hello again, I have been doing more tests to try and find out which end is causing the problem. My latest setup is to use the IcsSslFtpTst1 demo program and connect it to the IcsSslFtpServ1 demo program. The client demo has been modified to display the number of times I press the "Get" button and display a running total of the bytes received. This shows the same problem. After a number of "Gets" which usually corressponds to about a total of 2 Megabytes of received data, the errors are generated and it all stops. It is not clear which end bombs out first. ClientError at the client end and an exception at the server. Both ends of this setup are running Windows 10. Just a simple network between the two ends. Any clues as to whether or not there is something wrong with the ICS components or is it my setup? Regards Graham On 10/01/2018 10:03, Angus Robertson - Magenta Systems Ltd wrote: I have 2 ftp components and both are logged into the server. The first just does a LIST command every 3 seconds. The second does the GET commands. After 198 GETs I receive and error 10054. I re-connect both ftp clients and after a further 198 GETs the same thing happens again. So you have continuous open control channels, and do 198 SSL gets, each will open and close a new data channel, with a new SSL negotiation and session each time. There are no known restrictions in ICS over number of SSL sessions that can be opened, I've done thousands in a single thread. However ICS does have various SSL session caching options, and depending on which you are using that might be the issue. Never really looked closely at session caching, it just seems to work. So most likely the FTP server SSL implementation is bad. Have you tried downloading 250 files using FileZilla and SSL? Should replicate what your application is doing. I would say long idle FTP sessions are not a good idea, servers like to timeout long sessions and are not usually tested for long idle periods. So having your application periodically log-off and on again may help long term, you'll need that anyway to cope with bad internet connections. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
> I have 2 ftp components and both are logged into the server. The > first just does a LIST command every 3 seconds. The second does > the GET commands. > After 198 GETs I receive and error 10054. I re-connect both ftp > clients and after a further 198 GETs the same thing happens again. So you have continuous open control channels, and do 198 SSL gets, each will open and close a new data channel, with a new SSL negotiation and session each time. There are no known restrictions in ICS over number of SSL sessions that can be opened, I've done thousands in a single thread. However ICS does have various SSL session caching options, and depending on which you are using that might be the issue. Never really looked closely at session caching, it just seems to work. So most likely the FTP server SSL implementation is bad. Have you tried downloading 250 files using FileZilla and SSL? Should replicate what your application is doing. I would say long idle FTP sessions are not a good idea, servers like to timeout long sessions and are not usually tested for long idle periods. So having your application periodically log-off and on again may help long term, you'll need that anyway to cope with bad internet connections. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
1: The PROT issue is indeed irrelevent, but a simple fix at least lets
you know if PROT is supported.
Something like this maybe, so long as ftpFeatProt is added to the set:
if Pos('PROT', Feat) = 1 then begin
if Feat = 'PROT' then
FSupportedExtensions := FSupportedExtensions +
[ftpFeatProt];
if Pos('C', Feat) > 5 then
FSupportedExtensions := FSupportedExtensions +
[ftpFeatProtC];
if (Pos('P', Feat) > 5) then
FSupportedExtensions := FSupportedExtensions +
[ftpFeatProtP];
2: This server requires Passive mode when using AuthTls, so another
step forward.
3: Now I have an interesting one and it's difficult to know from which
end the problem is being initiated.
I have 2 ftp components and both are logged into the server. The first
just does a LIST command every 3 seconds. The second does the GET commands.
After 198 GETs I receive and error 10054. I re-connect both ftp clients
and after a further 198 GETs the same thing happens again.
Error 10054 is a "connection reset by peer" message, which would imply
that it's the server that has initiated this. But is there anything at
the ftp client end that could cause the server to behave as it does?
If I log into the server with the SSL Mode set to sslTypeNone, this
problem does not occur.
Any clues much appreciated.
Graham
On 26/12/2017 17:34, Angus Robertson - Magenta Systems Ltd wrote:
Hold fire on what I said before. I am still in learning mode as
this is all new to me.
I would suggest you at least try the compiled version of my high level
TMagFtp component from:
https://www.magsys.co.uk/delphi/magxfer.asp
which handles all this stuff automatically. If TMagFtp works, then you
can look at the source to see why.
The one thing I have found is that when I execute the featAsync,
I do not see the PROT in the list of supported extensions. When I
look at the source code, you are looking for "PROT C" or "PROT
P". This server only returns "PROT".
This may be irrelevant, the feature list is designed to tell you which
commands you can use, they don't stop you using them anyway (probably,
not looked at the code in a while).
Angus
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
> Hold fire on what I said before. I am still in learning mode as > this is all new to me. I would suggest you at least try the compiled version of my high level TMagFtp component from: https://www.magsys.co.uk/delphi/magxfer.asp which handles all this stuff automatically. If TMagFtp works, then you can look at the source to see why. > The one thing I have found is that when I execute the featAsync, > I do not see the PROT in the list of supported extensions. When I > look at the source code, you are looking for "PROT C" or "PROT > P". This server only returns "PROT". This may be irrelevant, the feature list is designed to tell you which commands you can use, they don't stop you using them anyway (probably, not looked at the code in a while). Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
Hold fire on what I said before. I am still in learning mode as this is all new to me. I had made a basic assumption that if I set "C" or "P" in the ftpClient.ProtLevel then that would be enough to be incorporated into the FTP connect mechanism. However not so is it. I have to manually execute ProtAsync after the client has connected. So now we move one step further on. The "Clear" mode works and I can connect. If I select "Private" then I get errors and cannot connect. Now I have to sort out certificates and things. I'll get back to you if I find out anything that might be relevant to ICS. The one thing I have found is that when I execute the featAsync, I do not see the PROT in the list of supported extensions. When I look at the source code, you are looking for "PROT C" or "PROT P". This server only returns "PROT". There is a simple fix at the ICS client end, but not sure yet if ICS truncates the response early on, or the server isn't sending it correctly. Regards Graham On 20/12/2017 12:09, Angus Robertson - Magenta Systems Ltd wrote: Also if I set the PROT to C, both the listAsync and getAsync responses are encrypted. If PROT is set to P, only the getAsync response is encrypted. That does not seem correct, C should not use SSL atall. I'll put this on the list to look at, but it may be several weeks, or longer, none of this has changed in many years and it's low priority. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
I'll contact the server folks as well to see what they are expecting. Thanks again. Graham On 20/12/2017 12:09, Angus Robertson - Magenta Systems Ltd wrote: Also if I set the PROT to C, both the listAsync and getAsync responses are encrypted. If PROT is set to P, only the getAsync response is encrypted. That does not seem correct, C should not use SSL atall. I'll put this on the list to look at, but it may be several weeks, or longer, none of this has changed in many years and it's low priority. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
Thank you for that. It does appear that the cert and key files are not required to log in. Also if I set the PROT to C, both the listAsync and getAsync responses are encrypted. If PROT is set to P, only the getAsync response is encrypted. P and C are the only two PROT commands supported by this server. Regards Graham On 20/12/2017 10:50, Angus Robertson - Magenta Systems Ltd wrote: I use the 01cert.pem etc. as example files SSL client applications don't need certificate or private key files, unless the server is high security and requires secure identification of remote users, like access to corporate LANs, money transfer services. You only need a root CA file bundle, and ICS now bundles one in wsocket as constants. when I look at the data being transferred with Wireshark, I see that everything is encrypted except for the response to the DirAsync command. Should be easy to answer, but actually not. Each data connection uses a separate TCP connection that requires a new SSL handshake, which is quite expensive in packets. So data encryption is optional, defined by the PROT command, C means clear, P means private which in modern terms means SSL. Clear might be acceptable if the files are already encrypted and the overhead of extra encryption is not required. Remember this stuff was devised back in 1997 when computing power and memory where expensive, and no-one envisaged how it might be implemented in the future. Assuming you have set protection to P, the ICS client should be opening an SSL connection for directory related commands, there are several. I have a log that shows 04:05:00 > XDMLSD -R 004:05:00 ! SSL Connected OK with TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384, key auth RSA, key exchange ECDH, encryption AESGCM(256), message auth AEAD So it's working with that particular directory command (only supported by the ICS FTP server). But I can no say it works will all versions, some of which use the control channel instead (which should be encrypted anyway). Assuming you are logging the SSL handshake event and FTP commands, your application should tell you want is encrypted and how. This is all down the client, not the server. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using the SslFTPClient
> I use the 01cert.pem etc. as example files SSL client applications don't need certificate or private key files, unless the server is high security and requires secure identification of remote users, like access to corporate LANs, money transfer services. You only need a root CA file bundle, and ICS now bundles one in wsocket as constants. > when I look at the data being transferred with Wireshark, I see > that everything is encrypted except for the response to the > DirAsync command. Should be easy to answer, but actually not. Each data connection uses a separate TCP connection that requires a new SSL handshake, which is quite expensive in packets. So data encryption is optional, defined by the PROT command, C means clear, P means private which in modern terms means SSL. Clear might be acceptable if the files are already encrypted and the overhead of extra encryption is not required. Remember this stuff was devised back in 1997 when computing power and memory where expensive, and no-one envisaged how it might be implemented in the future. Assuming you have set protection to P, the ICS client should be opening an SSL connection for directory related commands, there are several. I have a log that shows 04:05:00 > XDMLSD -R 004:05:00 ! SSL Connected OK with TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384, key auth RSA, key exchange ECDH, encryption AESGCM(256), message auth AEAD So it's working with that particular directory command (only supported by the ICS FTP server). But I can no say it works will all versions, some of which use the control channel instead (which should be encrypted anyway). Assuming you are logging the SSL handshake event and FTP commands, your application should tell you want is encrypted and how. This is all down the client, not the server. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
