Ssl suggestions

1

Looking at the SSL cipher suite list, there are some real insecure ones in there. Maybe someone could have a looksee at the library that’s shipping, at least before Beta-1 or R1.

I see TLS_DHE_RSA_WITH_DES40_CBC_SHA, TLS_RSA_WITH_RC2_CBC_40_MD5, TLS_RSA_WITH_RC4_40_MD5, and TLS_DHE_DSS_WITH_DES40_CBC_SHA, which are mentioned in various online pieces as very bad.

Also there’s TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_DHE_RSA_WITH_DES_CBC_SHA, TLS_DHE_DSS_WITH_DES_CBC_SHA, and TLS_RSA_WITH_DES_CBC_SHA, all of which aren’t given much better review than the first group. There may be other things in there that should be evaluated, so maybe an expert opinion (not mine, which is NOT expert) is a good idea. There may be new ciphers that have been issued since Haiku’s version of the library (whether they’re good or bad, I don’t know).

The current lib uses TLS compression (which is considered bad), uses TLS 1.0, which was given bad reviews under certain conditions, and does not use TLS 1.2, which is considered better than TLS 1.0 under most conditions (non-expert opinion of what I’ve read). I think SSL3 isn’t very good either, but probably should be evaluated. There could be more issues with the current setup (again - I’m not claiming to be any expert) - so it may be nice to check on this before R1- in any case.

2

Hi,

It is a bit unclear what you are testing here. Is it the OpenSSL library? Is it the web browser? Is it something else?

OpenSSL itself needs to support everything, if the user wishes to use unsecure encodings it's their choice (just like we support plain http alongside https).

On the browser side, it is also sometimes useful to be backward compatible (unsecure https access to a site with weak ciphering is better than no access to the website at all). However the web browser should warn about it.

3

PulkoMandy:

I’m not really referring to the browser, per se. Anything that makes a TLS connection will use lower level facilities than the browser. With the old WebPositive, the chain was libssl/curl/WebPositive. In that case, the ssl was handled by libssl, but curl could be compiled to use/notuse certain features. So, while either curl or libssl could be configured to include/exclude certain features, it is better to do it at a lower level in the case of other programs that do not use curl for TLS connections. I’m definitely not an openssl expert, so take this with a grain of salt :slight_smile:

I’m not sure how the new Webpositive works, and whether it is using curl anymore. If not, then the feature set changes would have to be made at a lower level than curl.

  • Ron
4

PulkoMandy:

Another angle: in the instance of polarssl (what I use on Haiku) - almost all of the changes mentioned in this thread would be made by recompiling polarssl’s libpolarssl.a, and then compiling libcurl to use that static library (which is what I’ve done).

As far as where to draw the line on various features - that’s a judgement call. Some of the cipher suites listed above are called deadly perilous in online remarks. I’d think they’d be not much better than plaintext (but a little maybe). Might keep the neighborhood grandmother out of your stuff. I’m not the expert though :slight_smile:

Other distros are making certain decisions at the lowest ssl lib level (where the issues are critical while other feature decisions are left to higher app levels.

The biggest danger may be the breakage of SHA1 (and probably SHA256 too), and the subsequent destruction of all abilities to authenticate anything anywhere, at least with certificates, which is something I think has actually happened :slight_smile: Again - I’m not the expert.

5

I hope I’m not being too impolite with a triple post, but there is one more thing to mention. The current WebPositive (as of h48882) is pretty much letting the defaults (the whole range) come through (which is what you’re referring to in your response). Whether that is good or not is a judgement. But, other distros are limiting the stuff with the worst publicity - at some level (either low (lib) or high (app), depending on distro).

In the previous post (which I can’t edit) I made a mis-statement. I said, “…then the feature set changes would have to be made at a lower level than curl.” That’s not necessarily true, of course. I made a similar statement about polarssl, which I modified at a lower level so that the curl program (as opposed to the library) would exhibit the features I wanted. It was easier for me to just change libpolarssl, but I certainly could have done it at a higher level.

So, each lib or app can hard wire things, or just leave it up to the user. I suspect that app level stuff may be more subject to misconfigurations and unintended overrides, however. Also, some of the items I mentioned are really exploit vulnerabilities, which should be mitigated at the lowest level possible. Maybe that would prompt an upgrade to another version, rather than just tweaking features.

It’s better to give all the options to the applications, of course. Yet, I think a probable reason that some distros limit things at maybe a lower level has to do with the way the https handshake is done. The browser* submits a list of acceptable (to the browser) suites, but THE SERVER gets to choose which one to use. Some servers will choose the poorest suite, because it’s faster to process (for the server). It’s kind of a problem for the https protocol.

So, I understand your idea to alert or warn in the browser. Maybe, it’s the user who should decide whether the use of a particular suite is “deadly” or not. Some distros go with that idea, and some restrict choices on the basis that many users are unsavvy. It’s a hard choice, and one often avoided so as not to be culpable in any way. So, that’s why (as a non expert) - I stay away from those kinds of decisions. :slight_smile:

I ain’t the expert - but I might have guessed some of the parameters. I’m just digging holes in the ground, sniffin some bones. Any user of Webpositive can just go to https://www.ssllabs.com/ssltest/viewMyClient.html to get a pretty good grasp of the situation. I considered it to be “too wide open” - so switched to polarssl. I chose that library because it made tweaking out the bad cipher suites and protocol versions pretty easy. What I did in the polar lib probably could have been done at a higher level, but it was convenient for me to change the low end. Since the browser accepts all that the lower libraries permit (AFAIK), the only alternative would have been to modify curl or the browser itself. I’ve been leaving that up to the Haiku devs :slight_smile:

  • “Browser” is a misnomer. It’s really “the client” which may be curl, a custom ssl lib, etc.
6

https://www.ssllabs.com/ssltest/viewMyClient.html is not the only site to use for checking, but it seems to give a better breakdown of the issues.

7

TLS 1.2 isn’t supported by openssl 1.0.0 anyway. This would require a switch to 1.0.1.

8

Yes - that’s true. Still, out of the box, openssl supports too many really crap cipher suites. Probably just as bad is the non support for OCSP stapling. The polarssl I’m using doesn’t support OCSP either. Polarssl does support tls1.2 for quite a while though. There’s one good thing you get with Windoze, Apple, and GNUtls - is automatic certificate revocation list checking. Since american ISPs have proxied all their customers, the infrastructure to decrypt everything pretty easily is in place. All it takes is a forged cert or one that is on a revocation list and your ssl doesn’t check it. If SHA1 is broke (I think it is) - then that’s all certificates from all sites. You’re forced plaintext, 24/7.

I guess some certs are now using SHA256 - but that uses the same general build structure. IMO - one torpedo sinks the whole fleet. Some people say OCSP stapling introduces more issues to deal with. So, I’m not necessarily a fan boy - but where to turn? Some libs/clients do straight OCSP checks on CA servers. But, these servers are heavily loaded, and some clients just ignore them altogether after a timeout. Also - it’s possible one’s IP may be exposed in those kinds of scenarios. Then, there are issues with SSL renegotiation that all the libraries are now beginning to reevaluate. And - there’s the initiative to put https-everywhere switches in https headers (I think that’s a good idea if you don’t build it into the browser).

If you look at https://www.ssllabs.com/ssltest/viewMyClient.html, you’ll see your stapling status towards the bottom of the page. That’s one thing that’s attractive about gnuTLS.

Another site, where you can see your preferred suite list, is at https://cc.dcsec.uni-hannover.de - but it doesn’t tell you whether you’re susceptible to various attacks, like the ssllabs link does.

Again, I must disclaim myself as a non expert. It’s all my unmitigated opinion and/or conjecture, injected wth tidbits of collected info, the veracity of which I am presenting absolutely no positive evidence.

9

Unless you point us to patches or build recipes that disable cipher suites, your suggestion isn’t going anywhere.

Gentoo: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl/

Fedora: http://pkgs.fedoraproject.org/cgit/openssl.git/tree/

Please find and document your findings, then open a bug report.
10

I’ve been looking at nss and gnutls as well, but those are less “drop in” friendly for apps built with openssl. There’s a compatibility layer I’m looking at.

11

[quote=korli]Unless you point us to patches or build recipes that disable cipher suites, your suggestion isn’t going anywhere.

Gentoo: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl/

Fedora: http://pkgs.fedoraproject.org/cgit/openssl.git/tree/

Please find and document your findings, then open a bug report.[/quote]

Yes - I tend to use the wrong medium for this kind of thing. Trac is bad for me because I’m so verbose (being the self described novelist :slight_smile: ). Some people have pinned me as being a little OC about some things.

As far as submitting a patch goes, my experience with openssl’s innards is pretty limited. I probably have a somewhat better idea about polarssl’s innards, but am pretty sure I’d not want the responsibility. Haiku’s not using it anyway.

But - as far as documenting the overall view, and submitting it as a bug report - that I think I’ll do. It’ll probably be a series of tickets, since some things are low level lib oriented, and some are app oriented.

12

But - thanks for pointing me to trac. I’ll learn to use the official procedure, eventually :slight_smile:

13

IIRC the problem with most OpenSSL alternatives is that they all come under the GPL or even more restrictive licenses. This means it is problematic to rely on these, as it would make it more difficult to make a non-GPL-tainted Haiku build (or, at least, that build would come with no SSL support at all).

This is why our focus would be more on LibreSSL. However, this one does needs the OS to provide several security features (a reliable entropy source, for example) in the form of specific syscalls which we would have to copy from one of the *BSD or from Linux. It needs some development work, and also some skills with crypto/security things to make sure everything is working as it should.

14

[quote=PulkoMandy]IIRC the problem with most OpenSSL alternatives is that they all come under the GPL or even more restrictive licenses. This means it is problematic to rely on these, as it would make it more difficult to make a non-GPL-tainted Haiku build (or, at least, that build would come with no SSL support at all).

This is why our focus would be more on LibreSSL. However, this one does needs the OS to provide several security features (a reliable entropy source, for example) in the form of specific syscalls which we would have to copy from one of the *BSD or from Linux. It needs some development work, and also some skills with crypto/security things to make sure everything is working as it should.[/quote]

It is true that the licenses of many of the alternatives would conflict. Polarssl has been sold to ARM Ltd (Yes, that one!) and they are going to re-issue the software under the Apache license. The problem with Polarssl is it’s not entirely a “drop in” replacement like Libressl might be (since Libre was Openssl fork). Polarssl works easily with curl only because curl has already accommodated the differences, and can be compiled with Polarssl simply by selecting a different configuration option. Other applications that were originally built with Openssl in mind, would have to be ported, which would require unknown number of changes. Probably Libressl would be more “compatible” with existing software (meaning less code to fix). The Open/Libre branch of SSL has a much larger ecosystem of apps, while polarSSL was narrow and targeted.

I’m not suggesting any particular library or changing (necessarily) to a new one. They all have their pluses and minuses, including the current one, so it’s a tough decision for you guys to make. I know the devs would want a lib that doesn’t require constant security “updates” - wouldn’t that be nice? LOL.

I just noticed on the website that Openssl was supposed to have OCSP stapling since 9.8g. Haiku has a later version than that. So, I see that it’s really curl that is the roadblock. As of last month, curl had not implemented the OpenSSL back-end for OCSP stapling. Curl has the OCSP stapling set up only for the GNUtls and NSS back-ends. In your blog, I see that a while ago you made changes to bring Openssl bad-cert messages up into the browser. Good on you for that! The revoked cert messages won’t come until curl is changed, I guess. Does the new WebPositive still use curl or has that been changed?

15

I removed the less desirable cipher suites from Polarssl just by removing them from ssl_ciphersuites.c and config.h and making minor changes in a couple other files - it was easy. I removed everything except PFS suites (perfect forward secrecy). By default, Polarssl is just like Openssl in that it allows some pretty awfully outdated cipher suites. Note that you shouldn’t do the extraction in the kitchen without rubber gloves. There are some interdependencies that have to be done correctly, and I’m not saying I got it all right. Seems to work, though. Everything (curl dependent) on my new Haiku instance is limited to PFS suites, because I trimmed libpolarssl so heavily.

This would not work with the general Haiku distribution, because such a strong limitation makes some sites unreachable. So (just trying to figure out how to word this for the bug report) - would it make more sense to control things at the browser level in a manner similar to the way the SSLeuth plugin does it in Firefox? Or is that giving too much power to the user?

16

While you’re at it, you could put https-everywhere functionality in the browser - all user select-able, and way ahead of the other distros, where it has to be installed as a plugin, bringing on security issues related with the download site. Of course, enabling the browser with this power might be considered a security issue itself. And - what if “mixed cipher” sites don’t work properly? A bank’s stuff works wrongly because some vulnerable cipher suite was disallowed out of the whole site (which otherwise uses decent suites). Any site that does that… well I don’t want to go there. Your real security is limited by the least powerful cipher-suite used. Breaking a mixed cipher-suite site may be why all the crap cipher suites are enabled. Boy, is the internet ever monumentally broke. There are all types of headaches to consider, from allergies to migraines.

Is it better to ignore everything (even though the security is thuswise zero). Or - try to fix it and fall a notch short. Legally, I think the former is quite a bit better, unfortunately. One would necessarily have to conflate “ignorance” and “ignore”. (I’m not a lawyer either, in addition to being a non-expert) So, now that the devs know, you must completely excise all ssl functionality. LOL Does putting more power in the hands of the user diffract that significantly? I guess it depends on which country you live in. Anyway, every distro has to dance these hoops when they go officially live (R1). It’s good to get thinking about it early. I’m glad the Haiku devs are brave. Go warriors!

17

I did say I might be a little OC. I was looking at another distro yesterday (a surprisingly popular one) - and saw that the crap suites were allowed all the way through the chain and supplied by the browser in the preferred suite list. WHile this may be due to worries about breaking mixed cipher sites (just as bad as mixed content sites) - it’s more likely that they reailze that SHA1 and all its cousins have been buggered, and it’s hopeless. If you live in a country where all the ISPs have put all their customers on proxies (raising a hand here) - you probably don’t stand a chance anyway. All the talk of cipher suites is moot.

18

The browser is not using curl anymore, we have our own http backend now. It would need to be modified to support PolarSSL, but that is not necessarily a bad thing - the API is also one of the reasons OpenSSL isn’t a good choice for security, and it is not even fully documented.

We would need to change BSecureSocket to use a different backend, and that's it. All native Haiku apps are using BSecureSocket and will benefit from the changes.

In current nightlies you already get the certificate warning. The message is a bit generic, and doesn't show the complete certificate details. Moreover, there is no way in the UI to add an exception for the certificate so you have to click on the "continue" button for each and every request. So, some improvements needs to be done on the UI, and on allowing certificate exceptions.

19

[quote=PulkoMandy]The browser is not using curl anymore, we have our own http backend now. It would need to be modified to support PolarSSL, but that is not necessarily a bad thing - the API is also one of the reasons OpenSSL isn’t a good choice for security, and it is not even fully documented.

We would need to change BSecureSocket to use a different backend, and that's it. All native Haiku apps are using BSecureSocket and will benefit from the changes.

In current nightlies you already get the certificate warning. The message is a bit generic, and doesn't show the complete certificate details. Moreover, there is no way in the UI to add an exception for the certificate so you have to click on the "continue" button for each and every request. So, some improvements needs to be done on the UI, and on allowing certificate exceptions.[/quote]

Sorry for the previous, overly caffeinated response. Anyway, thanks for the info, and the great work to bring up the cert alerts. You’re getting there, in spite of naysayers like myself. :slight_smile:

When you start looking at this stuff, it’s like you’ve picked up an old plank that’s been lying on the ground, and you jump back when it reveals a thousand silverbugs zipping and flashing all around, diving under the mushrooms to avoid the light. Most people don’t have a clue about all the intricatcies of the wicked world you’re trying to save them from. It’s thankless labor - but good on you for it.

20

Don’t let me be the one to steer you to polarssl. Make any library decision with your independent research. I don’t know if polar (now called tls.mbed) is any better than anything else. It’s easier code to read, I’ll say that. Theoretically, it could be great, but you know how theories are. Einstein’s are being shaken as we speak. I don’t have an expert level grasp of all the code in it, so anything I say about it should’nt be your deciding factor.

You make it sound like it could be a switchable module type of thing, where a number of backends could exist (Libre, Polar, Open, etc), and the user (or configurator) could pick his own poison. That could be a flexible option.

Another thing to consider is that a lot of the world’s https traffic over the years has been handled by only a few ssl clients, so that some servers are tied into the idiosyncracies of those clients (and vice versa). I think I may occasionally be running into that situation when trying to connect to servers using the polarssl client I’ve set up. I’m not sure what’s happening there, and it doesn’t seem to happen very often, but certain combinations of client and server may be problematic, requiring redress. Multiple versions and features that don’t mix well (a problem with all/many of the ssl libraries out there) may complicate the scene. Many of the known exploits for ssl in general are associated with the use of a version/feature only when it’s used in combination with something else (feature or version). Little bit of a nightmare. It’s just another thing to consider. I’m pretty laid back, others aren’t, so ya gotta consider all the libraries, and whether they’ll work for your clientele.

I think where polar (mbed) shines is where there’s a pretty static setup (VPN, as example). It’s very small, usually statically linked, and often used in embedded situations. It’s completely self contained, so will compile on any platform. I like it for those reasons, as it makes a very good platform for a tinkerer. I’m not saying it’s perfect. But heck - maybe it is. I doubt it though. I’d guess even the tls.mbed people aren’t saying it’s perfect. With the current situation on the internet, that’d probably be an insane statement to make.

It could be there’s real merit in the switchable scheme, that let’s you plug in your choice - libre, open, nss, etc … to make both the tinkerers and the general population (way less forgiving) happy.