To secure Login or not to secure Login?

[matrixx]

We use the secure login option for DA where http://www.clientsdomain.com:2222 (not real obviously) forwards to https://IP:2222 as I thought this was the best and safest way of doing things.

However redirecting to https://IP:2222 always gives 2 securecert errors, firstly a not trusted cert error then a domain mismatch error - I guess we could get around the 1st error by adding a certificate issued from a 'known' cert authourity instead of a self issued cert but we would still get the second cert alert as the cert isn't issued to the IP address.

We've had a couple of people questioning this recently and over time have also had peoples browsers not allowing the forwarding to the login page due to the cert errors.

Does anyone else do it this way or do you feel secure enough without the secure login?

Anyone had any issues due to using the insecure login?

Is there really a 'credible' risk to using an insecure connection nowadays?

Would really appreciate knowing some others opinions and practices.

Maybe someone has found a way around the errors to keep secure?
Cheers,

Rob

 

[DirectAdmin Support]

Hello,

The port 2222 https forwarding from http is only there as a convenience, and shouldn't really be relied upon to get your users to where they're supposed to go. Make sure that any links they have go to the correct https location.

I've seen some admin's move DA to port 2223 https, and run apache on 2222 to do the proper forwarding from http to https with the correct hostname.

Anytime you pass a password over plaintext you do run the risk of your password being sniffed, usually by a server that your packets run through (someone with access at a datacenter). However, I have never actually heard of anyone being affected by this possibility.

Related guides:
Setting up DA with SSL:
http://help.directadmin.com/item.php?id=15

Setting up DA to listen on http 2222 and https 2223:
http://www.directadmin.com/features.php?id=492

John

 

[nobaloney]

John,

I just read your link, and I'm not sure if you can run DA without SSL on port 2222 and securely on port 2223 or not. I hope you'll verify for us.

Thanks...

And I wanted to point out that the main problem with password sniffing isn't just at the ISP, but even there is a significant problem.

There are lots of Windows exploits that set desktop NICs into promiscuous mode, listening on all IP#s they see; this could cause a password to be delivered directly to a criminal organization.


And there are lots of Linux rootkits that do exactly the same, so if your server isn't on it's own private subnet, the same thing could be happening at the data center.

We recommend protecting the DA login with a commercial Secure Certificate (to avoid the unknown Certificate popup), and also changing the outgoing welcome messages to always show:

https://hostname.example.com:2222/

as the login to use for the control panel.

An alternative, depending on your response to my question at the top of this post would be to continue using an insecure login for user logins on port 2222, and to always do your own admin level logins (since admin is most dangerous) on port 2223.

Either way, though, we prefer to give our (not always sophisticated) users, a secure way to log into their account.

Jeff

 

[resolveit]

Removing the "d" flag in /etc/rc.d/init.d/directadmin causes directadmin not to start, if I add te "d" flag it works without a problem. How do I fix this problem?

 

[DirectAdmin Support]

I just read your link, and I'm not sure if you can run DA without SSL on port 2222 and securely on port 2223 or not. I hope you'll verify for us.

Yes, you can have both. Just use the default port=2222 and SSL=0, but then also have ssl_port=2223.
Make sure all th ssl cert/key's are setup.
The "ssl_port" option ignores the SSL option, ssl is always on for that port.

John