General cipher security level

[ronald-scheckelhoff-trac]

This "bug" report is in a gray area between bug report and suggestion. The latest nightly I've tested (hrev 48882) allows the use of 40 bit ciphers. These are generally considered very bad to use, and easily broken. Many out-of-the-box distros disallow them completely (Linux, etc). However; it's a sticky issue because some sites that require these antiquated cipher suites may break if the browser/ssllib/network substrate doesn't allow them.

This "bug/not-bug" is therefore something that requires a judgement to be made, rather than just pointing to a particular coding problem. I'm not the expert here, but I can look at other distros that have tackled it differently. For instance, GNUtls on FreeBSD, by default, doesn't allow anything less than 128 bits. Whether this is a problem to be handled at a low level (libs) or a high level (apps) is also a matter of judgement.

IMO this should be looked at prior to R1, maybe beta, and should include scores of other security related issues, including protocol, cert, security vulnerability, and cipher issues. Maybe this is solved (or not) by a simple upgrade of the affected library versions, but I'm sure my opinion of this is not as good as the official Haiku security-dev gurus. :-)

To see the ciphersuite list currently provided by the Haiku software stack, use Webpositive and go to ​https://www.ssllabs.com/ssltest/viewMyClient.html

[ronald-scheckelhoff-trac]

In my opinion, the number of servers that might refuse a connection because 40 bit cipher suites were not allowed is very small. Hence, I don't think we need them. It's just a non expert opinion tho...

[waddlesplash]

Personally, I don't really see why we should worry about this too much. Yes, 40-bit is insecure, but then again the sites that support 2048-bit TLS will use that instead. So on that front it's not really an issue.

Since everything runs as root for compatibility reasons, we aren't really secure anyway, so someone who really cares about security will want to avoid Haiku until we switch to multiuser (after R1).

[anevilyak]

Replying to waddlesplash:

Personally, I don't really see why we should worry about this too much. Yes, 40-bit is insecure, but then again the sites that support 2048-bit TLS will use that instead. So on that front it's not really an issue.

Except that's not the case, which is likely why this ticket was brought up to begin with: ​http://www.kb.cert.org/vuls/id/243585

[ronald-scheckelhoff-trac]

Replying to anevilyak:

Replying to waddlesplash:

Personally, I don't really see why we should worry about this too much. Yes, 40-bit is insecure, but then again the sites that support 2048-bit TLS will use that instead. So on that front it's not really an issue.

Except that's not the case, which is likely why this ticket was brought up to begin with: ​http://www.kb.cert.org/vuls/id/243585

Yes, and some servers tend to pick lower security cipher suites because they represent less overhead. Even Google will do this. Given a choice between DHE-RSA-WITH-AES256-SHA384 and an RC4 suite, it'll pick the RC4 suite. It's the server that gets to choose from your submitted suite list.

[ronald-scheckelhoff-trac]

The previous comment leads me to an RC4 discussion. It's also considered problematic. So far as the root=nosecurity theory, I don't think that's one hundred percent true. Anyway, it's good to move things ahead as you go, rather than wait until you're multiuser.

[axeld]

Multi user is just one method to make an operating system more secure, and it doesn't really have much to do with securing Haiku from any vulnerabilities; being able to decrypt your SSL connections is a serious issue.

[waddlesplash]

And now we have a more sane default ciphers list (initially from me, and modified by PulkoMandy) that does not have 40-bit ciphers.