Linux and FTP

Deadjasper

2[H]4U
Joined
Oct 28, 2001
Messages
2,568
I have an FTP URL link. I need to download the file the link points to but apparently Linux doesn't know squat shit about FTP. It asks me to choose a program to open it with and when I click the button it opens to the last location I had open and not to a folder containing programs. I've installed Filezilla but it apparently doesn't do URL's, just ip addresses. Since this is Supermicro's FTP server I'm not going to live long enough to slog through it looking for the file I need. I need to use the link.

Any help much appreciated.
 
It's not just Linux, browser makers have stripped the understanding out (stipped out FTP for "reasons"), and that's what is used for those "UTL links" in the past. Sometimes your file manager (e.g. Dolphin) can handle these.
 
Sometimes they have a web interface at the same domain; try swapping ftp for http and see what you get.

You can also browse using a terminal ftp client, or download the file directly with "curl" or "wget" if you know the exact location on the ftp server.
 
Sometimes they have a web interface at the same domain; try swapping ftp for http and see what you get.

You can also browse using a terminal ftp client, or download the file directly with "curl" or "wget" if you know the exact location on the ftp server.

Firefox changes it back to ftp
 
So where to begin ... Firstly it should be SFTP and not ftp.

You might have a url in that looks like

sftp://username: password@server: port

Sftp general is generally over port 22 but can be any port. If different from 22, it's appended at the end. (Ignore spaces in my example)

This is the structure of any url irrespective of protocol, server, operating system etc. I suggested reading up on URLs and what they mean and what they're made up of

In Linux you can use SCP to upload and download to remote hosts in a shell

FileZilla has 3-4 fields at the top in the quick connect section that you can use to connect to the remote to browse
 
Does this look like a proper URL?

ftp://ftp.supermicro.com/driver/VGA/Matrox/Nuvoton/G200e/Windows/Win2012/
 
Does this look like a proper URL?

ftp://ftp.supermicro.com/driver/VGA/Matrox/Nuvoton/G200e/Windows/Win2012/
Yup so protocol is ftp, means port is 21
Host or server is ftp.supermicro.com
Credentials are either supplied somewhere else or you can try logging in anonymously

FileZilla has a connection dialog that allows you to specify these params and save them under a connection for repeated use

You choose the connection type first, ftp, and it should fill the port field automatically. then fill in the rest and/or check off anonymous login. Could be slightly different cause I don't remember the dialog exactly

Oh and once logged in, you'll be able to browse to the path you need, drivers/ etc and so on
 
fz3_win_sitemanager.png


Do you have a drop down called logon type? If so it should be in there
 
So where to begin ... Firstly it should be SFTP and not ftp.
...............
Not true at all, claiming it "should" be SFTP is incorrect, plenty of sites still use FTP (sadly) but also if it is not required to be encrypted, who cares...
 
Define required
If you download a public file from a website, there is pretty much no need for the transmission to be encrypted. Anyone can access and open that file like you do. You might argue that encryption might make it more difficult to perform a man in the middle attack, but even that is not true since in order to do that the attacker basically has to take over a router within the route and then he can decrypt the TLS.
 
If you download a public file from a website, there is pretty much no need for the transmission to be encrypted. Anyone can access and open that file like you do. You might argue that encryption might make it more difficult to perform a man in the middle attack, but even that is not true since in order to do that the attacker basically has to take over a router within the route and then he can decrypt the TLS.

Anyone can state the obvious and say data that isn't sensitive doesn't need encryption. I don't need anyone eavesdropping on what I'm doing whether I'm accessing public information or not.
What are the downsides of using a modern protocol ?

Threads done anyway
 
Anyone can state the obvious and say data that isn't sensitive doesn't need encryption. I don't need anyone eavesdropping on what I'm doing whether I'm accessing public information or not.
What are the downsides of using a modern protocol ?

Threads done anyway
If you're worried about eavesdropping, TLS won't give you any privacy. Your only option is to use a trustworthy VPN provider in that case. Your ISP can still see every file you download TLS or not.
 
If you download a public file from a website, there is pretty much no need for the transmission to be encrypted. Anyone can access and open that file like you do. You might argue that encryption might make it more difficult to perform a man in the middle attack, but even that is not true since in order to do that the attacker basically has to take over a router within the route and then he can decrypt the TLS.

If you're worried about eavesdropping, TLS won't give you any privacy. Your only option is to use a trustworthy VPN provider in that case. Your ISP can still see every file you download TLS or not.

Yeah, that's all nonsense.

Aside from a few basic headers, the entirety of a transfer over SSL/TLS is encrypted. Neither the ISP nor anyone else between the host and server can see what is being transferred. It's very difficult to decrypt such a transfer, as doing so would basically require replacing certificates with compromised ones controlled by the attackers (and if they're that far in to either end, there are far easier ways to steal data).

VPNs do not provide any real privacy. All you're doing is moving any possible data collection from the ISP to the VPN provider (those services aren't so cheap because what they do is cheap, they're collecting your info just the same). Depending on where you live, the ISP may actually be subject to more stringent regulations regarding what data they can collect and what they can do with it.
 
Yeah, that's all nonsense.

Aside from a few basic headers, the entirety of a transfer over SSL/TLS is encrypted. Neither the ISP nor anyone else between the host and server can see what is being transferred. It's very difficult to decrypt such a transfer, as doing so would basically require replacing certificates with compromised ones controlled by the attackers (and if they're that far in to either end, there are far easier ways to steal data).

VPNs do not provide any real privacy. All you're doing is moving any possible data collection from the ISP to the VPN provider (those services aren't so cheap because what they do is cheap, they're collecting your info just the same). Depending on where you live, the ISP may actually be subject to more stringent regulations regarding what data they can collect and what they can do with it.
You have some learning to do apparently. Breaking TLS transparently is trivial if you can take over any router on the path. And TLS will not hide the information of any files you download (by means of request URL), only their content. So the only way to hide what you load from the ISP is to use a trustworthy VPN provider.
 
You have some learning to do apparently. Breaking TLS transparently is trivial if you can take over any router on the path. And TLS will not hide the information of any files you download (by means of request URL), only their content. So the only way to hide what you load from the ISP is to use a trustworthy VPN provider.

Breaking TLS is only trivial when applications don't validate certificates (which some clients don't do or don't do well, but IE/Firefox/Chrome/Safari all validate certificates properly baring the ocassional security bug). Or if you've taken over the server's default route and can get a new certificate issued (and don't mind the certificate showing up in certificate transparency logs).

Mostly, TLS exposes the destination hostname (there's encrypted SNI, but there's so many caveats ... It can probably help in some circumstances), and anyway, for non-shared hosting you can usually figure out the hostname other ways. For shared hosting, if the client doesn't do fancy DNS hiding stuff like DNS over HTTPS, you can figure out the hostname from that.

But the path beyond the hostname is and has been protected for always. The client doesn't send the path until after it receives and validates the server handshake.

That said, download size is mostly visible (TLS1.3 has optional padding to make sizes not totally obvious, but I don't know if anything actually uses it, you could probably pad a bit with http headers or trailers too, but again, not sure if anything uses it), so if I know you're connecting to the supermicro site and you download a file within a few kb of the Matrox drivers, there's only a few possibilities of what you downloaded. Some paranoid applications will do https downloads through fixed size https range requests to limit observable information (the last range would overlap the previous range so it's the same size range at the end of the file).

Far from trivially interceptable, but not entirely impenetrable either. If you've got some way to transparently intercept on a modern browser without installing your own certificate authority, that would be news to a lot of people.
 
Breaking TLS is only trivial when applications don't validate certificates (which some clients don't do or don't do well, but IE/Firefox/Chrome/Safari all validate certificates properly baring the ocassional security bug). Or if you've taken over the server's default route and can get a new certificate issued (and don't mind the certificate showing up in certificate transparency logs).

Mostly, TLS exposes the destination hostname (there's encrypted SNI, but there's so many caveats ... It can probably help in some circumstances), and anyway, for non-shared hosting you can usually figure out the hostname other ways. For shared hosting, if the client doesn't do fancy DNS hiding stuff like DNS over HTTPS, you can figure out the hostname from that.

But the path beyond the hostname is and has been protected for always. The client doesn't send the path until after it receives and validates the server handshake.

That said, download size is mostly visible (TLS1.3 has optional padding to make sizes not totally obvious, but I don't know if anything actually uses it, you could probably pad a bit with http headers or trailers too, but again, not sure if anything uses it), so if I know you're connecting to the supermicro site and you download a file within a few kb of the Matrox drivers, there's only a few possibilities of what you downloaded. Some paranoid applications will do https downloads through fixed size https range requests to limit observable information (the last range would overlap the previous range so it's the same size range at the end of the file).

Far from trivially interceptable, but not entirely impenetrable either. If you've got some way to transparently intercept on a modern browser without installing your own certificate authority, that would be news to a lot of people.
https://www.zdnet.com/article/new-tls-encryption-busting-attack-also-impacts-the-newer-tls-1-3/

It's very much doable if your router gets compromised. Also, HTTPS does not hide your URL requests so if you go on a website and click a download link https://fileshare.com/mysecretfile.exe the ISP will see that you clicked that link on that site, just not what the link contains. Having said this, many ISP provided routers contain backdoors that let the ISP to your lan. So the technician can in the worst case access your router in admin mode remotely and basically do what he likes on it. So if you're even remotely privacy oriented, get a router modem with OpenWRT capability and set up your own system. Then if you dislike ads, set up a pihole box and route your dns through it, it will filter out ads from all devices on your wifi/lan.
 
Last edited:

Yeah, security bugs are bad. They happen to everything, not just TLS. There's nothing about a VPN that makes it immune to such bugs. I've no doubt that a search of the CVEs for IPSec, L2TP, OpenVPN (which relies on SSL/TLS) and maybe even WireGuard (though it's very new and not very established yet) will pull up a lot of examples of comparable severity or worse.

AFAICT the vulnerability cited was fixed long ago. Usually they're disclosed to the responsible parties and fixed prior to publishing to reduce the chances that they'll be exploited.


Also, HTTPS does not hide your URL requests so if you go on a website and click a download link https://fileshare.com/mysecretfile.exe the ISP will see that you clicked that link on that site, just not what the link contains.

toast0 explained how the SNI works. The entire URL path is encrypted, only the site's FQDN is potentially exposed.


Having said this, many ISP provided routers contain backdoors that let the ISP to your lan. So the technician can in the worst case access your router in admin mode remotely and basically do what he likes on it.

This has absolutely nothing to do with the TLS vulnerability you're claiming. Also, the management interface for a router available to an ISP's support isn't going to be able to do anything more than the user themselves could (outside on some modem setup/diagnostics for integrated units), certainly nothing of any consequence on the LAN (e.g., ping).

(AFAIK, such devices are not even directly accessible by support staff, but instead they're provided limited access via a support interface that communicates with the router/modem via an API. Kinda like how, for instance, the Ubiquiti Unifi app works with APs/routers/etc., but on a much larger scale.)
 
Yeah, security bugs are bad. They happen to everything, not just TLS. There's nothing about a VPN that makes it immune to such bugs. I've no doubt that a search of the CVEs for IPSec, L2TP, OpenVPN (which relies on SSL/TLS) and maybe even WireGuard (though it's very new and not very established yet) will pull up a lot of examples of comparable severity or worse.

AFAICT the vulnerability cited was fixed long ago. Usually they're disclosed to the responsible parties and fixed prior to publishing to reduce the chances that they'll be exploited.




toast0 explained how the SNI works. The entire URL path is encrypted, only the site's FQDN is potentially exposed.




This has absolutely nothing to do with the TLS vulnerability you're claiming. Also, the management interface for a router available to an ISP's support isn't going to be able to do anything more than the user themselves could (outside on some modem setup/diagnostics for integrated units), certainly nothing of any consequence on the LAN (e.g., ping).

(AFAIK, such devices are not even directly accessible by support staff, but instead they're provided limited access via a support interface that communicates with the router/modem via an API. Kinda like how, for instance, the Ubiquiti Unifi app works with APs/routers/etc., but on a much larger scale.)
Uh I know for a fact that the tech could see even my wifi name remotely when I still had an ISP provided modem. That means that he got into the administration interface remotely. If he can do it, so can potentially an attacker. And masking your requests requires using ESNI/dns over https, a feature the majority of users are not using at the moment. HTTPS alone masks nothing. VPN then again, masks all traffic between the client and the vpn host so it provides 100% better privacy as far as the ISP and different DRM trolls etc. are concerned who try potentially to bring you to court over downloading stuff.
 
HTTPS encrypts the whole HTTP request and response and always has. The path is not cleartext and never has been. There have been vulnerabilities over the years that were pretty bad, and I'm sure there will be more and Bleichenbacher is a disappointingly recurring theme, so it's not perfect, but if you've got a current browser and the server you're talking to is reasonably up to date, your ISP can only see the hostname and the file size and can't fuck around with it other than closing the connection. Maybe one day the hostname will be harder for ISPs when you connect to a Cloudflare site, maybe.

If TLS is broken, your VPN provider can see your spicy Matrox drivers. If TLS is broken, so is your TLS based VPN. Your IPSec based VPN is probably also broken, since they use a lot of the same constructions as TLS and they can be harder to patch. WireGuard uses different crypto and may avoid a lot of those issues, but will likely end up with oopses too. Cryptography is hard to get right.

Yeah, your ISP can see your network name when you use their modem. If you don't like it, put their modem into as close to a bridge mode as you can get. But they still control the other end of the modem and can do whatever MITM stuff from there. Which is probably not going to include sniffing your driver downloads during the brief periods between TLS vulnerability discoveries and their patches being widely deployed. They've got better things to do, like ignoring when peering and transit connections are heavily utilized and figuring out how to make modern hardware run DNS recursive servers as slow as they did in 1996.
 
HTTPS encrypts the whole HTTP request and response and always has. The path is not cleartext and never has been. There have been vulnerabilities over the years that were pretty bad, and I'm sure there will be more and Bleichenbacher is a disappointingly recurring theme, so it's not perfect, but if you've got a current browser and the server you're talking to is reasonably up to date, your ISP can only see the hostname and the file size and can't fuck around with it other than closing the connection. Maybe one day the hostname will be harder for ISPs when you connect to a Cloudflare site, maybe.

If TLS is broken, your VPN provider can see your spicy Matrox drivers. If TLS is broken, so is your TLS based VPN. Your IPSec based VPN is probably also broken, since they use a lot of the same constructions as TLS and they can be harder to patch. WireGuard uses different crypto and may avoid a lot of those issues, but will likely end up with oopses too. Cryptography is hard to get right.

Yeah, your ISP can see your network name when you use their modem. If you don't like it, put their modem into as close to a bridge mode as you can get. But they still control the other end of the modem and can do whatever MITM stuff from there. Which is probably not going to include sniffing your driver downloads during the brief periods between TLS vulnerability discoveries and their patches being widely deployed. They've got better things to do, like ignoring when peering and transit connections are heavily utilized and figuring out how to make modern hardware run DNS recursive servers as slow as they did in 1996.
In my case the tech didn't see my network name, he saw my SSID which was not the networks name.
 
Guy wanted to download a file.
Was told to read up on how URLs work.
We got to read a heated debate on network cryptography.
This is why we can't have nice things on alternative OS'.
 
Separate. I'm thinking to set up my Rock64 as pihole also, to filter ads on mobile devices that lack proper adblocks.
Pi-hole goes a long way to blocking a lot of garbage. I'm using 2 VMs on my Pi4 8gb with ESXi to make that happen.
 
Back
Top