Web Server Authentication Is Still Broken(rx4g.com)
rx4g.com
Web Server Authentication Is Still Broken
https://rx4g.com/2013/09/09/web-server-authentication-is-still-broken/
1 comments
Ok, I am building a new site. Which, if any, of these approaches are viable for me to implement today in an easy and reliable way?
None, because all of these approaches require browser support to be at all usable.
That's what I was afraid of.
Let's say I have a small captive group of more savvy users--just the site admins, for instance. Are any of these approaches worth looking into for them?
Let's say I have a small captive group of more savvy users--just the site admins, for instance. Are any of these approaches worth looking into for them?
Actually, without installing extra software, you can drop all the root CAs and do Trust-on-First-Use (TOFU) with a limited set of browsers. It's possible with Firefox desktop, for example. Painful and error-prone, but doable. As with the SSH model, as long as you trust your initial authentication, future authNs where the pubkey changes will give you a warning because it will necessarily be a new cert.
For admins, put the site behind a firewall with only SSH ports open, make them SSH into it, set up a SOCKS proxy, and connect through localhost.
socks is overly complex for the problem, especially if you have several sites you do this for. Port forwarding is simple, and you can port forward to many different sites and the routing is obvious.
ssh -L1234:localhost:80 adminhost.yourdomain.com
then hit http://localhost:1234/ in your browser to reach port 80 on adminhost.yourdomain.com.
Simple and clear. The user isn't accidentally going to do their personal browsing over the admin network.
Make sure that the server on adminhost is only listening on localhost (and/or that port 80 is firewalled off to the outside world)
This is what I do everywhere I need to trust a http interface.
I even make customers do it some places (e.g. if they have access to VNC for KVM guests) but it does require a certain caliber of user.
ssh -L1234:localhost:80 adminhost.yourdomain.com
then hit http://localhost:1234/ in your browser to reach port 80 on adminhost.yourdomain.com.
Simple and clear. The user isn't accidentally going to do their personal browsing over the admin network.
Make sure that the server on adminhost is only listening on localhost (and/or that port 80 is firewalled off to the outside world)
This is what I do everywhere I need to trust a http interface.
I even make customers do it some places (e.g. if they have access to VNC for KVM guests) but it does require a certain caliber of user.
Sorry, by "admins" I meant folks who log into the Web administrative interface through a browser, but have elevated permissions. Specifically, can I reduce the chance that a cert attack will allow MITM for these users' browser sessions. We do very carefully protect shell access on the server itself.