Dear volunteers

We have switched our test project, Albert@Home, to use HTTPS instead of plain HTTP. This applies not just to the Web pages, but also to the communication between the BOINC client and the project site.

We'd like to use this as a test to see if this would cause any problems for volunteers (proxies, (personal) firewalls, etc). If you have any problems (unable to connect, unable to get tasks, warning messages while browsing the site.....anything that is unusual), you might not be able to post in this forum on Albert, so please feel free to report at Einstein@Home, e.g. here:

http://einstein.phys.uwm.edu/forum_thread.php?id=10095

Cheers
HB

---

Hello Bikeman,

Win7-64 and Boinc 7.0.64:

<snip>
03-May-2013 11:51:12 [Albert@Home] Sending scheduler request: To fetch work.
03-May-2013 11:51:12 [Albert@Home] Requesting new tasks for ATI
03-May-2013 11:51:14 [Albert@Home] Scheduler request failed: Peer certificate cannot be authenticated with given CA certificates
</snip>

Jürgen

03-May-2013 11:51:14 [Albert@Home] Scheduler request failed: Peer certificate cannot be authenticated with given CA certificates

Experiencing the same issue. Mac OS X.8.4, BOINC 7.0.65. Einstein works still.

same problem for me...

---

Same problem Windows 7,vista,linux

4760 Albert@Home 2013-05-03 12:25:54 Scheduler request failed: Peer certificate cannot be authenticated with given CA certificates

---

I see...I notified our admin at the UWM .

Cheers
HB

---

Same issue being reported in this thread, I believe. The website certificate was issued by "InCommon Server CA" on 1st May; older versions of Firefox (and presumably other browsers) don't seem to recognise this CA. My Albert hosts appear unaffected so far - relatively recent set-ups though so maybe they know the CA.

Edit: My hosts are affected too - though they're still ploughing through old jobs.

Same issue being reported in this thread, I believe. The website certificate was issued by "InCommon Server CA" on 1st May; older versions of Firefox (and presumably other browsers) don't seem to recognise this CA. My hosts appear unaffected so far - relatively recent set-ups though so maybe they know the CA.

If it's a new CA, then the certificate will need to be added to BOINC's "ca-bundle.crt" file as well - and that will be difficult to do retrospectively.

I tried to add Albert on my notebook.

03.05.2013 14:47:22 | | Fetching configuration file from https://albert.phys.uwm.edu/get_project_config.php
03.05.2013 14:47:27 | | Project communication failed: attempting access to reference site
03.05.2013 14:47:31 | | Internet access OK - project servers may be temporarily down.
03.05.2013 14:47:50 | | Fetching configuration file from https://albert.phys.uwm.edu/get_project_config.php
03.05.2013 14:47:54 | | Project communication failed: attempting access to reference site
03.05.2013 14:47:56 | | Internet access OK - project servers may be temporarily down.

---

Got through successfully about 10 minutes ago:

03/05/2013 14:18:36 | Albert@Home | Sending scheduler request: To fetch work.
03/05/2013 14:18:36 | Albert@Home | Reporting 15 completed tasks
03/05/2013 14:18:42 | Albert@Home | Scheduler request completed: got 17 new tasks

We switched back to HTTP for now, there could be intermittent glitches because of further tests to fix the certificate problem, tho.

Cheers
HB

---

I've posted some comments in the same thread over at Einstein.

Basically if you switch to https most proxy servers will act as pass thru which means they lose their caching ability. I would suggest only certain bits of the system use https (eg scheduler, website logon) rather than the whole lot.

---

I've posted some comments in the same thread over at Einstein.

Basically if you switch to https most proxy servers will act as pass thru which means they lose their caching ability. I would suggest only certain bits of the system use https (eg scheduler, website logon) rather than the whole lot.

That is certainly a point to consider, but OTOH, what caching would be affected by this exactly?
For the forum, no caching by the proxy is useful and therefore none should be allowed anyway (you don't want to get a view of the forum as it was minutes ago...it has to be "live"). Also, just having the logon page secured but then later transfer the session credentials (cookies etc) in plain text doesn't help security: it might help against intercepting the password but not against hijacking a session ...

The other big remaining family of web accesses would be downloads. For a single host per proxy, downloading the same file more than once should be a rare thing. But yes, this might be an issue for big "farms" that share one caching proxy. We could indeed exempt those downloads from https.

Cheers
HB

---

I've posted some comments in the same thread over at Einstein.

Basically if you switch to https most proxy servers will act as pass thru which means they lose their caching ability. I would suggest only certain bits of the system use https (eg scheduler, website logon) rather than the whole lot.

That is certainly a point to consider, but OTOH, what caching would be affected by this exactly?
For the forum, no caching by the proxy is useful and therefore none should be allowed anyway (you don't want to get a view of the forum as it was minutes ago...it has to be "live"). Also, just having the logon page secured but then later transfer the session credentials (cookies etc) in plain text doesn't help security: it might help against intercepting the password but not against hijacking a session ...

The other big remaining family of web accesses would be downloads. For a single host per proxy, downloading the same file more than once should be a rare thing. But yes, this might be an issue for big "farms" that share one caching proxy. We could indeed exempt those downloads from https.

Cheers
HB

The main one to exempt would be downloads. We'd want all those data files to be cached if possible.

With the website, I would guess (haven't checked) that the cookie is set when user logs on and gets deleted at log off. Does it change for every page served? Does it change during a session? Does it need to be protect seeing as its already on the users pc.

With the website, I would guess (haven't checked) that the cookie is set when user logs on and gets deleted at log off. Does it change for every page served? Does it change during a session? Does it need to be protect seeing as its already on the users pc.

See my message over at Einstein@Home. For best security, you will want to have the whole session under HTTPS, not just the logon page.

Cheers
HB

---