Thanks, the PR works. :-)

I have tested this item successfully on a4f1749

@roland-d maybe we should send a error message that we cant enable that?

@zero-24 I am not sure if we should do that. You could even take it further, not even give the option to change if there is no SSL.

If we have an option present and when you set that option nothing changes then there should be a message explaining why

@brianteeman Fair enough. Can you suggest a sentence to use? I can add it to this PR.

If I understand the PR correctly then how about

HTTPS has not been enabled as it is not available on this server

On 25 March 2016 at 09:39, RolandD notifications@github.com wrote:

@brianteeman https://github.com/brianteeman Fair enough. Can you
suggest a sentence to use? I can add it to this PR.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9584 (comment)

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

This PR has received new commits.

CC: @JoshuaLewis

Sounds like a good text to me, I have updated the PR and this will now show the following upon saving:

Thank you

On 25 March 2016 at 09:48, RolandD notifications@github.com wrote:

Sounds like a good text to me, I have updated the PR and this will now
show the following upon saving:

[image: image]
https://cloud.githubusercontent.com/assets/359377/14042099/0bd22100-f277-11e5-80e1-85d8dbd1823f.png

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9584 (comment)

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I have tested this item successfully on d6d79c5

I have tested this item unsuccessfully on d6d79c5

My server is https capable and the notice appears.

I think this happens because you are only checking ssl:// transport.

I have no SSL, just TLS. Also i have an invalid cert because it's a test server but should use https too.

See http://php.net/manual/en/transports.inet.php

Wouldn't it be better to test an https connection (json to be faster like the URL used in keepalive for instance)?

@andrepereiradasilva I don't have access to an TLS setup so didn't test it nor thought about it :)

We could also check the tls:// transport if ssl:// fails.

As for the certificate, we are not checking if it is valid or not, just if it is there.

Wouldn't it be better to test an https connection

I did that at first but got mixed results. I don't think there is anything wrong using the transport check if we add the tls:// options, is there?

sure, then check tls too.

ssl is deprecated and is being removed.
So the order should be the opposite, first check tls and then ssl

See https://tools.ietf.org/html/rfc7568

Yes, you are correct, I read that already just didn't express it that way :)

Would it be possible to test it against your test server?

of course, make the changes and i will test

This PR has received new commits.

CC: @andrepereiradasilva, @brianteeman, @JoshuaLewis

@andrepereiradasilva I made the changes, since I can't test them I have been guessing ;)

I have tested this item successfully on f804bbe

I just did the "Testing on a SSL enabled site" part on a TLS only HTTPS server.

@roland-d just tested the "Testing on a non-SSL enabled site" part with nginx.

I disabled the HTTPS in my host and it doesn't work. It fallbacks to the default nginx host SSL server_name _; so it saves the config and then redirects to HTTPS, since in the default server that URI doens't exist got a HTTP not found or forbidden error.

And, even if i remove the default host, it doesn't work: it saves the config and then redirects to HTTPS, since HTTPS doens't exist i got a HTTP 500 error.

I have tested this item unsuccessfully on f804bbe

tested unsuccessfully (see comments above)

@andrepereiradasilva

And, even if i remove the default host, it doesn't work:

Well we would need to check what feedback is received in this case. Would it be possible to get access to this site so I can test and debug it?

I have tested this item unsuccessfully on f804bbe

I don't agree having PHP checking the x.509 certificate opening a socket to the site.

Why?

1) The machine running PHP maybe have an outdated CA certificate repository

2) The PHP host can be running even with no openssl compiled in it, but this doesn't mean the website (not the server!) is not HTTPS capable (e.g. but you may have an TLS termination proxy in front of your site)

3) Even if it's letsencrypt.org epoch and i'm a big fan of https everywhere, there are many sysadmins that use dummy ssl certificate while testing sites, i don't agree that validating the certificate is the way to detect HTTPS capability, HTTPS can be enable even with a certificate not trusted for testing.

@creativeprogramming Apart from telling me all the reasons you don't want this, perhaps you can also share how you think this should be solved?

As I stated before, the validity of the certificate is not being checked, we merely check if there is a certificate.

In addition I would like to say that there is currently no mechanism at all to prevent users from locking themselves out by forcing the HTTPS connection. Even though this won't be a 100% solution at least it is a step forward and we can enhance it's implementation where needed.

Points 1 and 3 are invalid as the certificate is not checked for anything other than existing. Point 2 is rare and atypical and the benefit of not killing peoples web sites is far greater. I'm not even sure if in scenario 2 you would even be correct to set this option anyway

i also think is good if we find a working solution for this. It should always be avoidable sending the user to the configuration.php.

reggarding....

2) The PHP host can be running even with no openssl compiled in it, but this doesn't mean the website (not the server!) is not HTTPS capable (e.g. but you may have an TLS termination proxy in front of your site)

Point 2 is rare and atypical and the benefit of not killing peoples web sites is far greater. I'm not even sure if in scenario 2 you would even be correct to set this option anyway

is not so uncommon. i have a lot websites like this.

Anyhow, IMHO the point is, if this is not very reliable you could find yourself without the ability to add HTTPS in a site that clearly support it.

So, IMHO i still think it would be better to make an https request with JHttp to check if server is HTTPS capable. that way you don't care if the termination is a server, a proxy or anything or even if is using TLS or SSL.

would something like this work?:

try
{
    $options = new \Joomla\Registry\Registry;
    $options->set('userAgent', 'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0');
    $options->set('transport.curl', array(CURLOPT_SSL_VERIFYPEER => false));
    $http     = JHttpFactory::getHttp($options);
    $host     = JUri::getInstance()->getHost();
    $uri      = 'https://' . $host . JURI::base(true) . '/';
    $headers  = array('Host' => $host);
    $timeout  = 10;
    $response = $http->head($uri, $headers, $timeout);
}
catch (RuntimeException $e)
{
    $data['force_ssl'] = 0;

    // Also update the user state
    $app->setUserState('com_config.config.global.data.force_ssl', 0);

    // Inform the user
    $app->enqueueMessage(JText::_('COM_CONFIG_ERROR_SSL_NOT_AVAILABLE'), 'notice');
}

UPDATED: updated since we have to have cookies to use the admin URL

Not tested but the theory sounds ok

"So, IMHO i still think it would be better to make an https request with JHttp to check if server is HTTPS capable. that way you don't care if the termination is a server, a proxy or anything or even if is using TLS or SSL."

Sounds like a great method that accommodates most if not all situations of HTTPS. I'm hoping this gains traction. :-)

@roland-d

With this code i have no issues. don't know if will work on all cases, but works in mine, please check it

// Check if we need to verify the HTTPS request.
if ((int) $data['force_ssl'] !== 0 && (int) $data['force_ssl'] !== (int) JFactory::getConfig()->get('force_ssl', '0'))
{
    try
    {
        // Make an HTTPS request to check if the site is available in HTTPS.
        $host    = JUri::getInstance()->getHost();
        $options = new \Joomla\Registry\Registry;
        $options->set('userAgent', 'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0');
        $options->set('transport.curl', array(CURLOPT_SSL_VERIFYPEER => false));
        $response = JHttpFactory::getHttp($options)->get('https://' . $host . JUri::root(true) . '/', array('Host' => $host), 10);

        // If available in HTTPS check also the status code.
        if (!in_array($response->code, array(200, 301, 302, 303, 304, 305, 306, 307, 308, 309, 310, 503)))
        {
            throw new RuntimeException('HTTPS version of the site returned an invalid HTTP status code.');
        }
    }
    catch (RuntimeException $e)
    {
        $data['force_ssl'] = 0;

        // Also update the user state
        $app->setUserState('com_config.config.global.data.force_ssl', 0);

        // Inform the user
        $app->enqueueMessage(JText::_('COM_CONFIG_ERROR_SSL_NOT_AVAILABLE'), 'warning');
    }
}

This PR has received new commits.

CC: @andrepereiradasilva, @brianteeman, @creativeprogramming, @JoshuaLewis

@andrepereiradasilva Your code works fine for me as well. I have updated the PR. Thank you.

Just something else that came to mind since we are nitpicking. Should we change the wording of Force SSL to Force HTTPS as we may not be using SSL but TLS ;) What do you think?

@roland-d That actually makes a lot of sense. Especially if more methods are created in the future for HTTPS. Personally I would make that as a separate PR due to potential disagreement.

People are a lot more familiar with seeing HTTPS than SSL or TLS, despite their popularity. This is due to seeing it often in the url address bar. It's more versatile, accurate, and better known to say "Force HTTPS". :-)

There is already a PR to change the language throughout joomla

@roland-d @JoshuaLewis see: #9588

This PR has received new commits.

CC: @andrepereiradasilva, @brianteeman, @creativeprogramming, @JoshuaLewis

Pefect, I have left that change out and only updated the code description.

I have tested this item successfully on 16a8f91

The latest version of the PR still allows for a lockout. Without a certificate, this PR makes it so that you can't force HTPPS in the Joomla configuration which is a good thing. However if your site has forced HTTPS enabled, had a certificate, but has the certificate removed later on, you will be once again locked out of the site completely.

The current version of this PR is still an improvement to the current situation, but it would be nice to prevent lockouts in the future. The first version of this PR worked perfectly on my end. However I understand that it did not play well with TLS hence why it was changed up.

For those wondering why you would ever remove a certificate from your site, it has to do with testing reasons and trying to figure out underlying problems with extensions. I love HTTPS, but it is another thing to look out for when making sure things run smoothly. ;-) Due to the added benefit of this PR I'll still mark it as a successful test.

I have tested this item successfully on 16a8f91

@JoshuaLewis Apart from removing a certificate users can also remove the configuration.php or manually edit the configuration.php to bring down their site. We can't fix everything but at least it's harder now to bring down your site :)

I guess then the admin will just have to be extra careful when disabling HTTPS for testing reasons. ;-)

Removing a certificate is at least more cumbersome than changing a dropdown box :P

True.

Removing the certificate would be intentional, just as removing a configuration.php file would typically be intentional. The unintended part is being locked out of one's site as a result. But I suppose that if one was to remove a certificate intentionally, forgets to change the Joomla configuration (force SSL), then odds are they know how to change the configuration.php file to unlock them from the site.

My intention for bringing this aspect up is another layer of convenience in case of a mistake on the admins end and of course for less threads about getting locked out of one's Joomla site. ;-) I accidentally made this mistake last week which is why I brought it up as an issue. But again, I appreciate that this PR fixes part of the issue.

You are correct, if you know how to install/remove a certificate, you are no longer a beginner.

To sort of fix the removal of a certificate we would need to check on every page load if the certificate exists, this I think is overkill. It would be best to document what to do if you get such an error.

I assumed the same was true with the PR (in terms of checking each time). I agree that we would not want to use more system resources than what is needed. So does this PR make it so that it only checks for the certificate when changing the Joomla configuration?

This PR only checks when saving the global configuration and if the setting has changed and the setting is not set to Don't use.

Excellent, that's exactly what we want then. :-) I'm currently battling the flu, so pardon me being a little thick on this subject. The head ache is not helping either. Anyways, should be RTC soon.

No worries, get well soon. I have set it to RTC :)

@roland-d the @joomla-cms-bot is not happy :p

@roland-d i have just one question: has this been tested in sites without internet access? (e.g. intranets)

@andrepereiradasilva I didn't test it on an intranet but I wonder if it makes a difference. The code is calling the site you are on, so it should be reachable already. Or am I mistaken here?

@zero-24 I will check, didn't get a message though :/

The code is calling the site you are on, so it should be reachable already. Or am I mistaken here?

Is the server cannot connect to the internet, will it fetch the https page?

@roland-d you need to set the issue RTC on Jissues to make @joomla-cms-bot happy :)

I have tested this item ? unsuccessfully on 16a8f91

Hi,

Using J3.6.2, started from a "Force HTTPS": "Administrator Only" setup.

• Detection result was wrong.
• Worse: It downgraded the settings value to "None".

DETAILS:

Prelude/Side Note: In J 3.5.1 (before upgrading from 3.5.1 -> 3.6.0 -> 3.6.2) the preview link in the top right corner of the backend did link to the https website when called from the https backend (even on "Force SSL: None") = it kept me on the same security level (expected behaviour).
After upgrading to 3.6.2 the link refers to the http-link always, no matter what the "Force HTTPS" setting does state (unexpected behaviour !!).

Tried to "Force HTTPS: Entire Site". - BUT setting this switch resulted in
1) an false "Warning
HTTPS has not been enabled as it is not available on this server."
(I am even calling the backend through https - what is the "test" like to be positive here?).
2) Joomla CHANGING my setting from "Administrator Only" to "None", thus decreasing security level (!bad!), and every try to reset it through the backend does fail.

So, what do you need to correct this behaviour? How do you check that there is "no SSL certificate present"

• Using a self-signed certificate (openSSL), PKCS #1 SHA-256 with RSA-Encryption
• working in a development environment with HTTP_AUTH (maybe relevant?)

PS: No idea if this will fix the non-https link yet. In the end I do not expect a change by this.

Thanks ahead,
sailor

please open a new issue. This is closed / merged into 3.6.0

Reviewing the current implementation in administrator/components/com_config/model/application.php line 121 ff.
Yes, the routine does ignore existing http-authentication parameters (which could be taken from the existing session).
@roland-d: Would you please review the commit and adjust respectively? Please let me know if I can be of any help.

@sailor16 you can make a Pull Request for that, or else open an issue (this PR is already merged).

I opened https://issues.joomla.org/tracker/joomla-cms/11735.
Is it possible to close this issue for comments if this is not the right way to follow up?

@sailor16 we don't look conversations, sometimes there is something to say :-)