NuSphere Forums Forum Index
NuSphere Forums
Reply to topic
Site Admin

Joined: 13 Jul 2003
Posts: 8338
Reply with quote
No I won't tell you to stop using SSL, not at all. It's a valid environment for the debugger and everything should work fine and actually working fine for many customers. If you're using in prod, meaning with a real SSL cert, not self-signed, it's not a common case and there could be some problems we haven't seen.
I guess ALPN and SNI might cause some problems -- they are part of SSL protocol. Does your server restrict SNIs, for instance? I saw this problem reported by customers who work with CloudFlare env. Or we may have issues with cert chain validation in the HTTPS client that is used in the Wizard.
(RE huge fees associated with SSL certs, FYI some companies provide SSL certs for free as long as you're using their resources, not cheapest though, just a hint)

As of CLI -- it's cli, command line interface, an environment that has nothing to do with your web servers at all. It means that SSL is not applicable to this mode at all. If you select both WEB and CLI mode in the Wizard, does it work?

_________________
The PHP IDE team
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 28 Sep 2013
Posts: 84
Location: Pantin, IDF, France
Reply with quote
dmitri wrote:
No I won't tell you to stop using SSL, not at all. It's a valid environment for the debugger and everything should work fine and actually working fine for many customers. If you're using in prod, meaning with a real SSL cert, not self-signed, it's not a common case and there could be some problems we haven't seen.
I dispatch my debugging tests across prod servers, backup servers and home copy of them.

If I use a prod server, that I tend to avoid, it is generally into a test copy of the actual production virtual server into a side-by-side directory, and because I sometimes need resources that couldn't be easily available on test copies (a 10 Gb database, for example).

And why would I want to use a self-signed certificate where I can use a real Let's Encrypt one for the same price? Smile
This also has the advantage of better validating the changes that I make in the test servers before copying them to the prod ones.
dmitri wrote:
I guess ALPN and SNI might cause some problems -- they are part of SSL protocol. Does your server restrict SNIs, for instance? I saw this problem reported by customers who work with CloudFlare env. Or we may have issues with cert chain validation in the HTTPS client that is used in the Wizard.

I never digged inside the SSL configuration. I installed it using the default Apache values.

Let's Encrypt, however, strongly suggests to use some of their tunings, so I include a file (provided by Let's Encrypt) containing this in all of my SSL virtual servers:
Code:
# This file contains important security parameters. If you modify this file
# manually, Certbot will be unable to automatically provide future security
# updates. Instead, Certbot will print and log an error message with a path to
# the up-to-date file that you will need to refer to when manually updating
# this file. Contents are based on https://ssl-config.mozilla.org

SSLEngine on

# Intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLOptions +StrictRequire
All SSL tunings that I could have made should be there.

dmitri wrote:
(RE huge fees associated with SSL certs, FYI some companies provide SSL certs for free as long as you're using their resources, not cheapest though, just a hint)

The only company from which I could use resources is my hosting provider, OVHcloud.
The only SSL certificate resource that OVHcloud provides for free is … Let's Encrypt. Smile

But thank you for the hint, anyway. Smile
dmitri wrote:
As of CLI -- it's cli, command line interface, an environment that has nothing to do with your web servers at all. It means that SSL is not applicable to this mode at all. If you select both WEB and CLI mode in the Wizard, does it work?
I already told that into my September 27th, 2023 (French time) message here.

CLI tests succeed if I use them along with HTTP into the same project wizard (while the HTTP one fails).
CLI tests fail if I use them alone, without HTTP, into their own project wizard.

I understand this is absolutely not logical.

Despite CLI has nothing to do with web servers, I intensively use CLI on my servers for fetching external data (from open data sources), processing them, and putting the result into a database which HTTP scripts next use for displaying.

These CLI scripts are triggered by CRON tasks.
Once per minute.

As this is not handled inside the same directories, I use separate projects for debugging them.
CLI and HTTP scripts share some common libraries, however.
View user's profileFind all posts by GingkoSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 8338
Reply with quote
With CLI it was a simple typo in code that led to this non-logical error. With SSL/web mode - it still requires some more investigation and correlation. Can you update SSLProtocol and add -TLSv1.3 ? This will leave 1.2 version only. Then re-start web and re-check in the wizard.
One more question -- if you ignore wizard failure(s) and just save the results, does the project work and successfully starts debugging in CLI and HTTP modes?

_________________
The PHP IDE team
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 28 Sep 2013
Posts: 84
Location: Pantin, IDF, France
Reply with quote
dmitri wrote:
With CLI it was a simple typo in code that led to this non-logical error. With SSL/web mode - it still requires some more investigation and correlation. Can you update SSLProtocol and add -TLSv1.3 ? This will leave 1.2 version only. Then re-start web and re-check in the wizard.
Ok.
It seems to work if I add -TLSv1.3.

I tried this on a test server.
I'd like to avoid this on a server used for production, however.
dmitri wrote:
One more question -- if you ignore wizard failure(s) and just save the results, does the project work and successfully starts debugging in CLI and HTTP modes?

Seems to work also, yes.

But by the way, this leads me to another issue:
Is there a way to force or disable IPv4 or IPv6 on connection account basis (especially when using SSH) rather than globally?
I ran into some issues of this kind when running these last tests on local systems, and the only workaround that I found was entering the addresses as numeric IPs rather than by using domains names, because I don't want to block IPv6 where it works (thus for all projects) for the only reason that it leads to problems elsewhere.
View user's profileFind all posts by GingkoSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 8338
Reply with quote
So the issue is there only if combination of multiple factors took place -- web site is SSL, TLS version is 1.3, probably there is also dependency on Cipher and DH/EC exchange schema used as a part of TLS 1.3 and it's only happens in the Wizard.
You see, there is a good explanation why there were no complaints. Oh well, wrong, when posted suggestion to check the project itself pretending the Wizard had succeeded -- I picked the idea from the reports submitted by two customer who said Wizard froze for dozen seconds, then failed, but after all the debugger worked fine for their projects, making 3 reports total. Not too overwhelming. Thanks for the efforts.
As you see, neither debugger nor tunnel are root cause for the failure.
As of you latest post you just added, I open new thread because this one will eventually be resolved with next build. Please post details in that thread, including logs from your server. BTW if you posted logs in the course of this issue, it would save us a day or two, may be even more -- because definitely debugger posted issue in the log and did connected to the IDE and IDE started debug session but locked up because funny openssl has funny implementation of SSL_read tha locks up even though previous call to select() returned readable. Well, it's clear what's wrong with openssl and how to work this bug around, nm.
Also I renamed this topic to reflect what's been happening.

_________________
The PHP IDE team
View user's profileFind all posts by dmitriSend private messageVisit poster's website
Project Wizard fails to test debugger on some SSL webs
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 5 Hours  
Page 2 of 2  

  
  
 Reply to topic