Ok, I see now what your argument is about. And I would be against training users on bad habits too, but I don't feel that this is a bad habit we should be avoiding.
Enter the world of URL shortening services <https://en.wikipedia.org/wiki/URL_shortening> out there, training users every single day. Or the fact that this is the type of redirect, which Cisco supports for Finesse load balancing <https://supportforums.cisco.com/discussion/13095011/cisco-finesse-failover-behavior> ? On Thu, Oct 20, 2016 at 6:27 PM, Norton, Mike <[email protected]> wrote: > It is not so much about compromising the redirect server, or cloud vs > in-house, as compromising users' behaviour. Phishing is an attack on user > behaviour (getting them to believe a fake site is real). By teaching users > that it is perfectly normal to be redirected from the officially documented > URI that they remember, to some complicated technical-looking URI that they > don't comprehend, you are leaving them vulnerable to phishing. You want the > normal user experience to be immediately obviously different than that link > in the email message from "I.T. Department" asking to "verify your > account," that redirects to some sneaky obfuscated URI hosting a fake login > page. Redirects make it hard for users to tell if they actually ended up at > the page they intended to, thus it is a way by which they could be tricked > into using a fake page (phishing). > > -mn > > Sent from my Windows Phone > ________________________________ > From: Anthony Holloway > Sent: 20/10/2016 5:05 PM > To: Norton, Mike > Cc: Cisco VoIP Group > Subject: Re: [cisco-voip] DNS Friendly Names and URL Paths > > So the cloud is a scary place, I see that. I wouldn't want to expose > anyone to an extra risk. You could just avoid the whole attack vector > thing by deploying a 100% on-prem solution though, no? And if you cannot > trust your internal servers, then you're screwed either way. > > Also, you cannot just throw out "attack vector" and "phishing" without > backing that up. What sources can you cite that URL redirects are security > risks? And not open redirect services either. The services I am referring > to would not be open redirects<https://en.wikipedia.org/wiki/URL_ > redirection#Security_issues>, rather they are protected/private, because > you have to configure your own DNS to make it happen. URL shortening > services are in use in our daily lives and they rely on the same exact > techniques<https://en.wikipedia.org/wiki/URL_shortening#Techniques> I'm > talking about here: HTTP 3XX Redirects. So, I'm not saying I'm a security > expert, but I don't think it's fair to just say "It might get compromised, > therefore it's bad." Otherwise, everything we do is bad, because > everything is at risk. Even SSL itself<http://heartbleed.com/>. > > The problem with the reverse proxy/L7 load balance might be seen at the > finesse level, as only a simple redirect is supported today, but otherwise, > I would love more intelligence in the routing decision versus static > redirects. > > And yes, of course, you could simply not bother, but seriously, I have yet > to see an environment where bookmarks are pushed and documentation says > "Look at your bookmarks to login to finesse." Instead, it has been a URL > given to the users via documentation. > > Perhaps a landing page akin to Google's old iGoogle<https://en.wikipedia. > org/wiki/IGoogle> could be used to ease the distribution and launching of > app URLs. Some apps already have something simliar. Like when you go to > the UCCX landing page there's a link for AppAdmin and CUIC. Too bad > there's no link for Finesse. And too bad it looks like garbage. And too > bad there's not like a single landing page for CUCM, CUC, UCCX, etc. > > On Thu, Oct 20, 2016 at 5:14 PM, Norton, Mike <[email protected]< > mailto:[email protected]>> wrote: > I would be a bit wary of HTTP redirects being a convenient attack vector > for phishing. Especially if they are happening over unencrypted HTTP and > across the Internet. But even just behaviorally, I don’t think it is a good > practice to get users comfortable seeing the “official” URIs be redirected > to ugly technical-looking URIs. Makes it easier to trick them into using a > fake page. If they’re used to always seeing a memorable simple and pretty > URI, then they’re more likely to notice when something is amiss. > > An alternative would be to rewrite URIs with a reverse proxy (or L7 load > balancer). This would avoid the need for redirects and would keep the > user’s browser pointed at a nice pretty URI. As a security bonus, you’d be > able to firewall direct L3 access to the application service, and also your > client machines wouldn’t need to be allowed to access weird ports. > > Another option is to just not bother with friendly names, push > favourites/bookmarks into users’ browsers (e.g. via group policy, mdm) and > train them to get to the applications that way. > > -mn > > > From: cisco-voip [mailto:[email protected]<mailto:cisco- > [email protected]>] On Behalf Of Anthony Holloway > Sent: October-20-16 1:07 PM > To: Cisco VoIP Group <[email protected]<mailto: > [email protected]>> > Subject: [cisco-voip] DNS Friendly Names and URL Paths > > Since the list is slow this week.... > > Ever since the push for DNS and FQDN over IP Address, I have been giving > application servers a Subject Alternative Name (SAN) so that users > accessing Self-Care Portal, Finesse, etc. do not have to be bothered with > server names. > > E.g., > Instead of this: > > https://mspvmcucm001.company.com/ucmuser > > They would be able to use this: > > https://myphone.company.com/ucmuser > > That works pretty well, and Tomcat certs are easily signed to support the > extra alias. > > However, when it comes to UCCX, it's a little more complicated with the > following example: > > https://finesse.company.com:8445/desktop > > Because the alias is not exactly fitting for all things on UCCX, such as: > > https://finesse.company.com:8444/cuic > > That's confusing, and also because the user still has to remember the port > and path on the end. > > https://finesse.company.com will not automatically take you to > https://finesse.company.com:8445/desktop > > Today I had a co-worker ask me how it might be possible to have both: > > A) A different alias for each sub-component of the application server > (E.g., Finesse vs CUIC) > > B) Have the port and path appended automatically > > I decided that a shim would be appropriate here. We would take the > various aliases, send them to a web server, which would then initiate an > HTTP Header Location redirect to the appropriate port and path. > > A PHP example could be: > > URL: https://agent.company.com/ > PHP: <?php header('Location: https://mspvmuccx001.company. > com:8445/desktop''); exit; ?> > > This uses the HTTP Location<https://en.wikipedia.org/wiki/HTTP_location> > header, which sends an HTTP 3XX response code to the client and let's them > know where to go to get the "right" page. Unfortunately, that does mean > that the address changes in your browser from the first URL to the second > URL. This isn't terrible, but it does mean that you'll still want a > friendly looking CNAME record for your host still, as I described above. > > But, this would require me to install a web server in each environment and > configure it, or ask for shared web server space. A better solution? The > cloud! > > I stumbled across a public service that does just this. The cloud service > I found is: > > https://www.easyredir.com/ > > They have both paid and a free plans: > > https://www.easyredir.com/free-url-redirection > > I was able to set this up in about 10 minutes and it works exactly like I > have explained above. I have no affiliation to them, and I'm sure there's > other services out there. > > Icing on the cake I suppose, I was even able to take a public domain > record (E.g., company.com<http://company.com>) and redirect it to a > private domain record (E.g., company.local), proving that your application > servers need not be accessible from the internet. > > In fact, your target url doesn't even have to be a public domain either. > > E.g., > https://agent.company.local can point to https://mspvmuccx001.company. > local:8445/desktop > > The only requirement is that your client PC can resolve the private record > (.local) to the public service host (on easyredir.com<http://easyredir.com>), > and that the returned redirect location (.local again) is also accessible > to your client PC. > > Has anyone come across something like this before? How are you solving > all the different ports and paths now under your administrative domain? > > This does not replace your need for a smart load-balancer in the case of a > server failure, though Finesse should at least redirect you to the Master > node, should your DNS record point to the Slave. > >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
