PHP needs libcurls support for TLS-PSK with OpenSSL

[h6w]

Hi. I wanted to reopen the PR #394 however it seems to be locked to collaborators.

I've been tracing down a problem alerted to by the BareOS Backup System which recently moved to TLS communication between all components in the system, defaulting to TLS-PSK. However, the user interface WebUI is written in PHP. PHP uses libcurl with OpenSSL for which the discussion went stale several times, despite some people saying it was in use and others were forced to choose other options (like WolfSSL). The current advice by BareOS is to downgrade to an unencrypted connection or change all encryption to a personal CA.

I have an open bug report for PHP here: https://bugs.php.net/bug.php?id=79280

Why does TLS-PSK work with libcurl with WolfSSL but not OpenSSL? I would have thought that OpenSSL was more prevalent.

Can we please review this PR again with a mind to getting it included in a near future release?

[bagder]

#394 was closed since it went stale a long time ago. Anyone is free to work on what they think we should merge and I propose creating a new PR then. This is a feature-request and as such we won't keep it open for long but probably add it to TODO if nobody acts on it.

[h6w]

Yes, that's why I'm asking to reopen it. It's having an effect downstream but it seems that people are willing to name-call on PHP/libcurl (and encourage "no security" optons) rather than get to the bottom of the problem.

My questions are valid, though. There has been other work done since that would make this PR easier, AFAICT. Why support WolfSSL this way but not OpenSSL?

[bagder]

Why support WolfSSL this way but not OpenSSL?

Everything curl supports is there because someone wrote the code and did the necessary work to have it merged. We welcome new features and changes that improve curl.

Things that we still not support are features and code that still haven't been written or completed to a satisfactory level and thus we don't support those things.

[h6w]

That doesn't really answer my question. I understand how development works. This is not a question about development process.

My question was about the intersectionality between this feature in different implementations. When the OpenSSL feature was originally proposed, there was no support for TLS-PSK, now we have a WolfSSL implementation of the featureapproved, shouldn't an OpenSSL version of the feature be easier to get to a satisfactory level?

From reading PR #394 it appears as though we got very close to a satisfactory level. I would quite willingly put time and effort into this. Unfortunately, I'm not an expert on the SSL protocol, so forgive me if there is something hugely missing that is obvious to you.

[bagder]

shouldn't an OpenSSL version of the feature be easier to get to a satisfactory level?

Possibly, but #394 also added the new libcurl options + code for libcurl and they're still not there. And we need documentation and test cases.

it appears as though we got very close to a satisfactory level

That's my perception as well.

I would quite willingly put time and effort into this. Unfortunately, I'm not an expert on the SSL protocol,

I'm not an SSL expert either. We will of course appreciate help as this seems like a requested feature.

[baryluk]

Hi, I also wanted to comment on #394, but can't. I would be very interested in having TLS-PSK in libcurl and curl. The software is for monitoring and control of many devices, both over internet on local networks, and I find TLS-PSK more convenient to setup, than other methods in general. I already do have server side working, and confirmed using openssl s_client to work (tested few cipher over TLS1.3). I am considering using WolfSSL too, but would prefer to stick to OpenSSL (or the leaner derivatives) probably for most of the software.

[bagder]

Unfortunately, voicing support is not enough. Someone also needs to do the actual work.

[h6w]

Yeah, I think @baryluk, like myself, is questioning why a feature request would be closed if it hasn't been completed or dismissed as impossible or not a feature that anyone would want. I understand that noone has time for it right now, but then it also wouldn't draw anyone's attention to work on because there's no open issue to close.

[bagder]

I hear you. But keeping issues with "good ideas" open would quickly give us hundreds of issues that just linger around and makes it much harder for us to work with the bugs we actually want to use the issue tracker for. In order to avoid this problem, we close feature-requests and add ideas to the TODO document. TLS-PSK is mentioned there. This is how we work.

Ideas and feature requests are super easy and we drown in them. Implementing and making ideas reality is the hard part.

If you want to suggest we change the way we work on issues and feature-requests, then please bring the discussion to the curl-library mailing list and we can talk about it.