Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PHP needs libcurls support for TLS-PSK with OpenSSL #5081

Closed
h6w opened this issue Mar 12, 2020 · 9 comments
Closed

PHP needs libcurls support for TLS-PSK with OpenSSL #5081

h6w opened this issue Mar 12, 2020 · 9 comments

Comments

@h6w
Copy link

@h6w h6w commented Mar 12, 2020

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
Copy link
Member

@bagder bagder commented Mar 12, 2020

#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
Copy link
Author

@h6w h6w commented Mar 13, 2020

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
Copy link
Member

@bagder bagder commented Mar 13, 2020

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.

@bagder bagder closed this as completed in 51fde33 Mar 15, 2020
@h6w
Copy link
Author

@h6w h6w commented Apr 16, 2020

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
Copy link
Member

@bagder bagder commented Apr 16, 2020

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
Copy link

@baryluk baryluk commented Sep 15, 2020

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
Copy link
Member

@bagder bagder commented Sep 15, 2020

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

@h6w
Copy link
Author

@h6w h6w commented Sep 15, 2020

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
Copy link
Member

@bagder bagder commented Sep 16, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants