Weak certificate and obsolete SSL/HTTPS settings on boinc.berkeley.edu

Message boards : Questions and problems : Weak certificate and obsolete SSL/HTTPS settings on boinc.berkeley.edu
Message board moderation

To post messages, you must log in.

AuthorMessage
Necroman

Send message
Joined: 29 Aug 10
Posts: 6
Czech Republic
Message 64687 - Posted: 5 Oct 2015, 7:03:56 UTC

Hi,

I've just noticed that the boinc.berkeley.edu site uses domain certificate with weak SHA1 signature and it's expiring after 2016. This effectively leads to "red untrusted strigethrough symbol" in the Chrome browser and some other browsers as well.

This should be really looked into, because this takes away any trust by possible new BOINC volunteers.

Also the HTTPS/TLS settings is not optimal. The server supports some very weak cipher suites like TLS_RSA_WITH_DES_CBC_SHA and also weak RC4 suites and lot of unnecessary and slow suites as well like SEED and CAMELLIA.

I'd highly recommend, if possible, updating the Apache and OpenSSL libs to current version for best possible security and performance, which will eventually lead to more volunteers willing to help with BOINC scientific project.

For more details see:
https://www.ssllabs.com/ssltest/analyze.html?d=boinc.berkeley.edu
https://wiki.mozilla.org/Security/Server_Side_TLS

Thanks
ID: 64687 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15477
Netherlands
Message 64695 - Posted: 5 Oct 2015, 10:18:52 UTC - in response to Message 64687.  
Last modified: 5 Oct 2015, 10:24:07 UTC

I'd highly recommend, if possible, updating the Apache and OpenSSL libs to current version for best possible security and performance, which will eventually lead to more volunteers willing to help with BOINC scientific project.

Thank you for that.

At the moment the security is grade B, both for Seti@Home and the BOINC domain. Which is better than the grade C we've had for a while after the crash of the BOINC domain server.

The weak certificates are an artifact of using an on-campus (Berkeley) certificate generating service which is free but obviously not perfect. It is already being looked at by the site- and network administrator, but we have to keep in mind that there is little to no money to do these certificate upgrades with.

So, while a cheap certificate could cost only 49 dollars for a year, it's something that has to be paid out of the pocket of the administrator himself, not by the campus. And then times two, three, four or however many servers there are that need these in the network.
ID: 64695 · Report as offensive
Necroman

Send message
Joined: 29 Aug 10
Posts: 6
Czech Republic
Message 64699 - Posted: 5 Oct 2015, 11:37:37 UTC - in response to Message 64695.  
Last modified: 5 Oct 2015, 11:40:23 UTC

Domain certificates can be as cheap as zero $ / year
http://www.startssl.com/
Or soon also on Let's Encrypt:
https://letsencrypt.org/

Or just few $ per year
https://www.ssls.com/ssl-certificates/comodo-positivessl

But it depends, if you want switch to different CA or keep using the current one. There might be some apps or webs using certificate/public key pinning and these might stop working after such change.

At the end we can probably all agree, that this red HTTPS that every user see right now, is not good for the project:



Also regarding the B rating, it can be easily changed to A just by updating the list of supported cipher suites. The recommended list of cipher suites can be found on the Mozilla web in the link above.
ID: 64699 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15477
Netherlands
Message 64700 - Posted: 5 Oct 2015, 14:51:47 UTC - in response to Message 64699.  

I was wrong on stating that the certificate has to be paid by the project administrator himself. It's the UCB that pays for it.

BOINC doesn't use its own web site and domain with an easy to renew certificate that can come from just about anywhere. Both BOINC and Seti use UCB servers, web-addresses, internet and resources, including their security systems and certificates.

The InCommon Server CA certificate is one that is paid for and issued by the University of California at Berkeley. When it's going to be renewed, it will be renewed for the entire campus, at a rate of 15,000 dollars per year.

While it's nice that browsers such as Chrome, Firefox, Pale Moon etc. show whether or not the connection is secure or not, panic strike-throughs such as Chrome uses are unnecessary. If they find the site thoroughly insecure, they'd better not allow a connection to it anymore.

That was something Pale Moon did to the account page for The Elder Scrolls Online, while browsers as Firefox and Chrome allowed the connection to it -it had at the time only an RC4 encryption- Pale Moon actively blocked access to the site. Pale Moon blocks a lot of insecure sites that Chrome and Firefox allow, making you wonder how they really feel about the security of such sites.

When looking at https://boinc.berkeley.edu/:
Pale Moon (25.7.1) shows that the connection here is mixed mode/partially encrypted.
Firefox (41.0.1) shows that I'm on a secure connection, verified by Internet2.
Dolphin (11.4.21) shows I'm on a secure connection and that the certificate is valid and expires on 14/04/2017.
ID: 64700 · Report as offensive
Necroman

Send message
Joined: 29 Aug 10
Posts: 6
Czech Republic
Message 64714 - Posted: 6 Oct 2015, 6:39:01 UTC - in response to Message 64700.  

If I understand it correctly, UCB is using certificates from InCommon with some kind of yearly subscription fee.
In that case is should be easy to reissue new certificate for boinc.berkeley.edu for free with SHA256 hash algorithm instead of current "insecure" SHA1, that causes the red strike-through in Chrome, because it expires after 2016.
Some details about the SHA1 certificates deprecation is here:
https://wiki.cac.washington.edu/display/infra/Transition+to+InCommon+SSL+Certificates+Signed+with+SHA-2
ID: 64714 · Report as offensive
Profile Gary Charpentier
Avatar

Send message
Joined: 23 Feb 08
Posts: 2462
United States
Message 64722 - Posted: 6 Oct 2015, 13:26:55 UTC - in response to Message 64714.  

In that case is should be easy to reissue new certificate
except for the politics of the Chancellor's Office.
ID: 64722 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15477
Netherlands
Message 64723 - Posted: 6 Oct 2015, 13:45:45 UTC - in response to Message 64714.  

that causes the red strike-through in Chrome, because it expires after 2016.

Justeminus, it only causes a panic in Chrome. Not in any of the other browser families out there. Doesn't that make you wonder why Chrome is panicking over nothing? The connection is encrypted, the certificate is still valid until April 2017. We live in October 2015, why cause a panic now? No one has yet managed to crack SHA-1.

From StackExchange:

No actual break involving SHA-1 and using a structural weakness of SHA-1 has been currently fully demonstrated in academic conditions, let alone in the wild.

The best we have right now is a theoretical collision attack that should allow an attacker to compute a SHA-1 collision with effort "about 2^61", which is huge but still substantially less than the 2^80 resistance expected from a "perfect" hash function with 160-bit output. While 2^61 is within reach of existing technology, it is too expensive for even rich universities to casually indulge into that kind of experiment. So no actual collision has been produced yet. Moreover, for a practical attacker, computing a collision rarely grants a lot of power -- the attacker must usually compute a collisions with some degree of control on the contents of the colliding messages, which may be harder (or not).

Another parameter is that even if SHA-1 is perfect, its output size (160 bits) implies a maximum bound to its collision resistance at about 2^80, which is half a million times 2^61 (so quite more expensive), but at the same time not ultimately expensive. A 2^80 computation can be envisioned with existing technology and resources available on Earth without needing to invoke some sci-fi stuff or breaking laws of physics.

Since switching algorithms in deployed applications takes a lot of time (hey, we are still trying to get people to stop using SSL 3.0 and instead go to TLS 1.0, more than 15 years after TLS 1.0 was published), we'd better get it going now, so that SHA-1 is really phased out when technology has improved to the point that the 2^80 effort has become feasible in practice.


Added to that, we're not a bank. We don't sell insurance. There isn't really a need for encrypted connections to the BOINC web site, and therefore all links coming from the BOINC Manager GUI -and even when you click on that big BOINC logo to the upper right here- are to the HTTP address http://boinc.berkeley.edu/. That's the address most people will use. Only a handful of us who have set our bookmarks to HTTPS are using this connection. And of those, most will use Firefox which -as I said yesterday- shows that the connection is safe.
ID: 64723 · Report as offensive
Necroman

Send message
Joined: 29 Aug 10
Posts: 6
Czech Republic
Message 64740 - Posted: 7 Oct 2015, 6:50:15 UTC - in response to Message 64723.  

Justeminus, it only causes a panic in Chrome. Not in any of the other browser families out there. Doesn't that make you wonder why Chrome is panicking over nothing?

Not just in Chrome. In Opera it shows no green lock that users associate with security. In IE11 and Edge the same, no lock indicator of secure site.
Google and Chrome is here again the most proactive, marking SHA1 as insecure starting in Chrome 46 as far as I know. And if you check this, Chrome even plans sometime in year or two marking all HTTP traffic as insecure.

HTTPS is not just convenience, it's about trust, especially on sites where users use name and passwords for login. Crazy number of users use the same password on most of their sites and capturing login credentials on one site can compromise lot of other online accounts.
And another benefit of having HTTPS is the future support for HTTP/2 protocol, that works only via HTTPS. Apache already supports HTTP/2, nginx should have full support at the end of this year.

But this discussion goes beyond my initial point. In my opinion sites (not just) with login should use properly deployed HTTPS-only, ideally with HSTS, with domain certificates that user can trust on first sight.
ID: 64740 · Report as offensive

Message boards : Questions and problems : Weak certificate and obsolete SSL/HTTPS settings on boinc.berkeley.edu

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.