Production environment should redirect to TLS

[CINJ]

@Chordian thanks for such an awesome tool. Use it literally every day while at work :)

Not sure if there is a reason for this, but the live version of DEEPSID allows HTTP and also HTTPS, however, if you try and log into the HTTP version, at least under CHROME, it will cause a failure, throw up an alert to email you, and just stay logged out. A bit of investigation showed me that the security package I am using was blocking credentials being sent unencrypted... I would expect this issue will happen to other users for sure.

This issue does not occur when the site is loaded with HTTPS instead of HTTP protocol in the browser.

To solve this issue (and not pass user credentials unencrypted) it would make sense to simply redirect all HTTP calls to HTTPS in your Apache configuration which can be done in the website config file. Let me know if you require an example. Happy to help.

Regards
Joe
aka ZIGGY / DEFAME

[Chordian]

I actually briefly had it on HTTPS a long time ago but then bumped it back to HTTP again due to an issue I can no longer recall any details about.

Anyway, I'll make a note of going HTTPS again and I'll see how it goes.

[CINJ]

To simplify the TLS deployment, consider using Certbot: https://certbot.eff.org/ which is a simple frontend to LetsEncrypt - this makes life a lot simpler than having to pay for SSL certs etc. The Certbot provides 'auto-renewal' capability to give you set and forget.

[Chordian]

Thank you for the information, but the HTTPS/SSL thing is part of the web hotel I'm using and I don't have to pay extra to use it.

[Chordian]

I just tested logging in a user both on HTTP and HTTPS. No problems in Google Chrome that I could see.

[tobozo]

Being able to login with HTTP is the problem: it exposes the credentials.

Login page standard requirements: if TLS is available and the client supports it, then a redirection to a TLS context is implicitely done before sending the credentials.

The rule of thumb is to never show a login form when location.protocol is not https:, and instead provide a link to the HTTPS version of the login page.

That login page can eventually use some javascript logic to prevent being used in the wrong context:

if (location.protocol !== 'https:') {
    location.replace(`https:${location.href.substring(location.protocol.length)}`);
}

but ideally this should be enforced with HSTS and redirection rules on the server side

[Chordian]

Good point. I have now made sure HTTP is always redirected to HTTPS on the server side.

As mentioned in a comment in 2019, there was a reason for going HTTP but I can't remember what that was anymore. If it's still a problem I'll deal with it differently if it emerges again.

[tobozo]

I can't remember what that was anymore

some http elements hardcoded in the page maybe? browsers can silently block non-tls content when in tls mode, and this applies to third party elements too (e.g. pulling a vulnerable jQuery version from a google CDN instead of hosting it locally)

[Chordian]

Maybe. I just made a quick smoke test running across all SID handlers, tabs and folders.

Seems to work fine in HTTPS, apart from CGSC not being able to show his site. He uses HTTP. I'll have a look at it.

[Chordian]

The CGSC site refuses to work in DeepSID because it's using HTTP.

I'll try writing to Peter at the CGSC site and ask him if he can go HTTPS with it.

[Chordian]

He answered back that his cheap hosting option doesn't have an HTTPS option. I'll use a link instead.