Jump to content

Computer Nerd Kev

Member Since 12 Jul 2014
Offline Last Active Jul 26 2020 09:33 AM

Posts I've Made

In Topic: Problem with Git setup

26 July 2020 - 09:30 AM

The clone URL in the video is for SSH access and Heliohost accounts don't allow this (except on the VPS accounts).
There's a banner at the top of the CPanel Git config. page in my account that says:

Warning: Your system administrator must enable shell access to allow you to view clone URLs.

Git also supposably supports HTTP/S URLs, not that I fully understand how this works for uploading.
I tried it once by creating a git repo under ~/public_html/, but although I tried hard, I couldn't get it to work (I can't find my notes on this, so not sure what the exact errors were). The Git documentation is far from clear on how HTTP-hosted repos work (though I don't find it particularly clear about anything for that matter).

In Topic: [Solved] Non-SSL SMTP Port Requires SSL

26 July 2020 - 08:50 AM

Well as it turns out I've now managed to get msmtp to build with SSL/TLS support, and got my old email MUA to use it instead of the built-in MTA (which took a bit more scripting than I expected), so I can do SMTP with encryption on port 465 now.


So whether or not you want to change the default so that SMTP works unencrypted, I don't need it now personally. Ideally I would still prefer the option to use unencrypted SMTP in case of future troubles though.


Thanks for the explainations and for looking into this.


Now to try and set up an MRA/MDA for the IMAP side of things...

In Topic: [Solved] Non-SSL SMTP Port Requires SSL

26 July 2020 - 02:20 AM

It's intentional because AUTH PLAIN is a security issue.

Technically it doesn't have to be AUTH PLAIN, it could be AUTH CRAM-MD5 (or similar) for a little more security, but I'm not sure if this is relevent to the rest of your reply because that's nothing to do with STARTTLS or SSL/TLS in general. The AUTH method is just the way of specifying the password, with methods that make it more secure do so over unencrypted connections.


Require clients to connect with SSL or issue the STARTTLS command before they are allowed to authenticate with the server. [?]

Disabling this option will significantly decrease the security of the server by allowing the plaintext transmission of authentication credentials.

I've actually turned this off briefly a few times to confirm this exact problem was the issue with my apps, but since it's a security issue I turned it back on and found more secure solutions once I knew where the problem was.



Well the security risk is that without SSL/TLS the authentication details can be read by someone snooping on the connection. That won't compromise the server itself (it's the same info as in the logs that I posted), but of course they can use them to get passwords that other people use to send email. That's why I was only looking to do it with one account where security isn't very important and the password isn't used for anything else. Similar to how FTP and HTTP CPanel/Webmail is enabled even though they're unencrypted, presumably for people who aren't concerned about a targeted attack on their account.

There is an argument that someone snooping on all of the internet traffic that goes to Heliohost (eg. a hacked machine or rogue employee at the datacentre or an ISP) could pick out the passwords for all Heliohost email accounts that users connect to without encryption. Then they could use Heliohost for sending spam out via other user's accounts - without an easy way of blocking them (if they connect from a large range of IP addresses).

So from that perspective it could be a risk to the whole server because if it gets Heliohost on spam blacklists, and can't be fixed while there are users connecting unencrypted to their email, it would affect all users on the system.

But Tommy does accept webmail logins over unencrypted HTTP at port 2085, which is just as bad as unencrypted SMTP (maybe worse because I'm not sure if there's anything like CRAM-MD5 for HTTP) for security of authentication details. Also IMAP on port 143 works without SSL/TLS. As the same passwords are used with SMTP for sending email, then that risk is still open via those routes.

Sorry for the lecture, I'm just trying to cover all sides of the topic. Security stuff always gets complicated.

I'd be looking for newer software. If the software is old enough to need this option turned off, it's old enough to have god knows how many other security issues. I have a PHP mail client from 2011 installed on my account, and even it supports STARTTLS...


Technically the software I'm using does support STARTTLS and SSL/TLS directly on port 465. This still works on other servers. The trouble is that the encryption library used by my software is old and Tommy's software no longer supports any of the encryption methods that it can use. That's presumably because they've all got security issues, so I am resigned to trying to upgrade eventually (complicated by me wanting to use software that isn't maintained - I'm currently looking at installing a separate MDA and MTA (msmtp from the first SSL log) instead of the ones built into my old MUA, but what do you know I'm having trouble getting the SSL support to compile...).

I'm not trying to draw Heliohost into my own world of software frustration, and do plan to get my Email working everywhere over the latest encryption eventually. This was just an attempt at a quick fix for one account where encryption doesn't matter in the first place, and seeing as unencrypted connections are allowed for pretty much everything else (including webmail and IMAP) it seemed unlikely that SMTP was deliberately meant to be SSL-only. If it is deliberate, then I think the logic is a bit inconsistent, but I won't tell you to re-evaluate everything just for the sake of my temporary issue, not unless you want to anyway.

In Topic: [Solved] Account Inactivity Immunity Lost

28 May 2020 - 11:17 PM

Ah right, that's OK. I wasn't sure if I'd remembered it correctly, but the description disappeared after the fundraiser was closed and the page wasn't archived by the Wayback Machine, so I trusted my "optimistic" recollection of it.

In Topic: host local web server for testing

16 May 2020 - 04:03 AM

If the OP's internet connection for the server is via mobile broadband, as he suggests, then the problem likely goes a bit deeper than port blocking.


Many (most?) mobile broadband ISPs use Carrier-grade NAT, which prevents any inbound connections from reaching a computer "inside".


To make a server accessible from the internet via such a connection, the only option is to have the server first open a connection to the client via SSH. Then the client is configured to send HTTP requests to a port that communicates via the open SSH tunnel to the server. It would indeed be preferable that the client connects on a port other than 80, so that it can still connect to other websites on the internet using that port, but this bypasses any port blocking implemented by the ISP.


I remember now that the actual term for this is a "reverse tunnel". This is one example for a web server (look at the reply to the first answer for what worked).


It's also suggested there that setting up a VPN is another solution.


The issue with this is that someone has to specifically configure this on the client before it can connect. So if, for example, you want to test integration with a service like PayPal IPN that makes inbound HTTP requests to the server, it won't help you because you can't set up PayPal's "client" to use your SSH tunnel (or VPN). I use mobile broadband for my home internet connection myself, so for this I resigned to uploading to Heliohost and doing the final testing there.


The software is OpenSSH. It may work on Windows via Cygwin, but I suspect you'd be in for a lot of headaches trying to make that work. Best if both server and client are running Linux, BSD, Mac OS, or some other UNIX-based OS.


If you just want to test with a device that can't run the web server itself (eg. a smart phone), I suggest that connecting it to the same LAN (router) as your server computer would be much easier and more reliable than doing SSH Tunneling over the internet.