This would ensure no information is transmitted in plain text and reduce the attack possibilities against client computers. I know a lot of info is already transmitted encrypted, but the initial connection is a weak point.

For older clients, it requires a detach and reattach. For newer clients it will handle adding HTTPS itself. (See https://github.com/BOINC/boinc/commit/b695ca2c05c42814bd832d17134dfefd4c9969ac)

I've pledged to contribute my resources to any projects that switch as a way to help mitigate any potential losses (I'm hoping others join me on that). See BOINC thread here: https://github.com/BOINC/boinc/issues/1345

Our server is using SSL and http requests are automatically redirected to https. So I am a little confused here. Are you referring to the scheduler requests that occur from within the client?

I tried to change the urls in the config file a year or 2 ago. It ended up causing all kinds of connection problems with users and brought the project to a stand still. So I am a little hesitant to do that again.

Please keep an eye on future developments - specifically, https://github.com/BOINC/boinc/pull/4539, "all master URL update to https".

David Anderson wrote that yesterday, when he should have been fixing a problem caused by the expiry of an SSL certificate the day before.

Judging by his comment, "Note: code you wrote a long time ago sometimes doesn't seem to make any sense at all", I don't expect this feature to be fully tested in time for the emergency release we expect in the next few days, but there's hope that the problems you encountered will be reduced when the next recommended release reaches widespread coverage,

Yes, the master_url (https://numberfields.asu.edu/NumberFields/get_project_config.php) or project url that BOINC does the initial connection with.

2 years ago the patch for handling http->https changes automatically wasn't there. Depending on how many users have upgraded to a version that includes it, it should go much better. (Also importantly, your cert doesn't seem affected by the recent BOINC CA issues..)

Another reason for not acting too precipitately: the SSL expiry problem only affected clients running on the Windows platform. They use a static ca-bundle.crt file, which can't be automatically updated. Other platforms use the operating system's security bundle, so they get updates with system updates.

The emergency release we are expecting 'real soon now' will be for Windows only. The http->https patch will only be fully effective when a planned release is made across all platforms. That's been overdue for a while, but there's no sign of a plan for when it might take place.

It sounds like I should wait until the patch is available to all platforms.

The Windows version 7.6.20 should make the http->https seamless (has been out for some time) - it did include the previously mentioned patch.

Mac/Linux users likely still have to do the detach/re-attach dance (it's unlikely to reach all Linux users for a while - and there isn't a new Mac build available yet).

Project admins should pester David Anderson to ask why there is still no sign of a v7.18 release for all platforms.