how about enabling TLS on your Assignment Servers?

[bren]

from the logs, I read the client is connecting to remote servers on port 80 and 8080.
I guess it would be nice to have protocol HTTPS enabled rather than HTTP.
Could you please set it up?
Thanks

[Jesse_V]

It's a good idea, but I don't see a necessity for it. There's not many secrets in the F@h data and I don't see much impact from talking to a impersonating server or a man-in-the-middle system.

F@h is also an international project and I believe that there are issues exporting cryptography to certain countries depending on export laws from the 1990s. Other countries may have issues with encrypted connections to a research lab without the ability to inspect the traffic. There's a lot of little tangles there.

[JimboPalmer]

The assignment servers are overloaded as is, deciding to implement Crypto on them can't possibly speed them up.

[lazyacevw]

It should still be added to the todo list. TLS is worldwide and widely adopted. At this point, it is unclear if the AS are overloaded due to bandwidth restrictions or actual resource limitations. If someone wanted to be malicious and operate a killer bitcoin mining botnet or get hecka points, they could MITM and send their own work.

[Jesse_V]

It should still be added to the todo list. TLS is worldwide and widely adopted. At this point, it is unclear if the AS are overloaded due to bandwidth restrictions or actual resource limitations. If someone wanted to be malicious and operate a killer bitcoin mining botnet or get hecka points, they could MITM and send their own work.

It's a good idea, I agree.

The servers are overloaded in multiple ways. Today for example they were serving about 104,000 workunits/hour, which is about 30 units/second. Workunits are maybe 10-50 MB. That's a lot of bandwidth and a lot of I/O. A few months ago they were serving about 10,000 workunits/hour.

I don't see any motivation for a man-in-the-middle attack because you can't buy anything with points. All that the attacker would be able to do is secretly submit a bunch of bad workunits, which would quite likely be caught by the server's integrity checks and resubmitted to someone else.

[Joe_H]

In addition, all of the WU's and other files passed over the connections are digitally signed, so someone attempting to insert their own files would have trouble doing so. Raw IP numbers are used for many of the connections, they are harder to spoof for MITM attacks.

[Asgaroth]

Not to mention the cipher settings required to configure ssl/tls on the edge to support all the different versions of operating systems/browsers out there, may indeed defeat the purpose of enabling secure protocols in the first place seeing that there are vulnerabilities available for most security protocols excluding, for now, tls v1.3

[cveiche]

+1 to this.
setting up https is fairly non-invasive and has very low overhead. since the jobs and binaries (i.e., cores{dot}foldingathome{dot}org) are distributed in the clear, it seems that a mitm or dns takeover could possibly be used to take over FAHClient instances.

[Abu Jazar]

+1f

Common crypto algorithms used by TLS is basically «free» on modern CPUs.

Also: TLS and work unit distribution/reception should probably be implemented on a load balancer rather than talking to each individual server. Also, port 8080 is blocked by a lot of default firewall configs. I just noticed it might be possible to report these as issues on Folding@home's GitHub, I'll look into it : ) (Can't post link because I've been quarantined, that is, by the forum, not by Covid-19).

[lazyacevw]

Glad there is a discussion on this. All I can say is that a few months ago before volunteer clients came on board, this whole operation was run and designed by a bunch of good hearted individuals, designed to operate lean and mean. Now that the distributed computing system has more processing power than the top 7 supercomputers in the world, combined, it may find itself of interest to nation states that it is currently spanking.

[jcoffland]

The Assignment Server already supports TLS/https. It's the client software that uses http.

[ipkh]

Port 80 just specifies that its a webserver and has nothing to do with encryption.
You connect to port 80 or 8080 if a proxy is setup on your home/office network. And then the server sets up the encryption and assigns the actual port mapping to use for further communications.
You might be confusing how other protocols, such as email, deal with encryption versus websites.

[bren]

The Assignment Server already supports TLS/https.

yes I noticed it later, thanks.
But not all of them are correctly configured imho.
Take https://assign6.foldingathome.org/ for example; in the cert you can read Common Name == 128.252.203.2 rather than Common Name == FQDN which is probably a mistake.

It's the client software that uses http.

Right, and I think it would be nice to have the option to force HTTPS over HTTP.

[HaloJones]

nothing in this world is "free". using server CPU to encrypt data costs power and achieves what exactly? this data has no value to any other party. in twenty years there has never been an attack or attempt to steal data.

you are asking for a feature that has no benefit whatsoever and would require the encryption of vast amounts of data, costing cpu cycles that cost money.

[Joe_H]

Take https://assign6.foldingathome.org/ for example; in the cert you can read Common Name == 128.252.203.2 rather than Common Name == FQDN which is probably a mistake.

Where do you see assign6 used? The AS's in current use are 1 & 2, there is a redirect from assign-cpu for compatibility with older versions of the client. Last I checked same held for assign3 & assign4 addresses.