Horrific design issue


  • Suppose you get "stuck" trying to connect the Teleport to a WiFi network that needs authentication (in itself a UI mess on the Teleport).

    Then suppose something goes wrong -- either in the process or, more likely in the Teleport's (buggy) implementation.

    What happens is you end up "stuck" on that wireless network in the Teleport with no way to reset it -- short of leaving the area.

    If you then try to reset the Teleport, guess what? You reset it COMPLETELY -- and since you are remote, there's no way to repair it with the base unit in the remote network.

    Brain dead.


  • @alex-neihaus Hi Alex! This is why the setup manual recommends enabling remote access. It's a must with Teleport if you ever need to reset it.


  • Where do you enable remote access once everything has been setup? I'm looking at the url and on the phone app and not finding it anywhere 😞


  • Well on the app, I tapped the lines in the upper left and hit "remote access", then it says remote access enabled, but I see no way to disable it and tapping on it again only says remote access enabled again?


  • @brian-hellman Remote access requires Google or Facebook authentication. If you tap on 'Log Out', remote access will be disabled.


  • @ubnt-gunars I'm authenticated using Google so doing what I did above worked?


  • @brian-hellman It looks like you've enabled it. If you want to disable, then tap on 'Log Out'.


  • @ubnt-gunars You cannot access remote access if the AmpliFi is in bridge mode. Apparently.

    I asked "support" about this (specfically, what ports should I forward to the AmpliFi from the EdgeRouter X that is my router) and got back the answer that I should use the port forwarding in the latest firmware that's designed to permit the Teleport through the router. (That works, BTW, as long as the Teleport at the other end isn't connected to a WiFi network that requires authentication -- a whole separate set of issues).

    Nope, it's brain dead (and insecure, since you apparently only allow Oauth2 logins from the most evil providers on the planet -- Google and Facebook) to design a flow in which it might be necessary for a remote user to access a local LAN resource in order to establish the connection.

    Repeat: brain dead.


  • @alex-neihaus What's your proof that using Oauth2 via Google and/or Facebook is insecure? I've heard of no such thing.


  • @shane-milton Good question.

    Google uses Oauth2 for sure: https://developers.google.com/identity/protocols/OAuth2.

    But taking a page from ubnt's refusal to describe how the Teleport works, Facebook doesn't clearly identify its login authentication protocols: https://developers.facebook.com/docs/facebook-login.

    A company that won't (or can't) explain its use of open protocols is, by definition, doing security incorrectly insecure. Security by obscurity is no security at all. Security is hard -- if you don't allow people to understand the pieces you used and how you put them together, you probably did it wrong.

    Facebook is a special case of derision for me: they turn people into product. They've consistently made it hard for people to control their identities on their platform and have been slow to accept responsibility for their role in the last US elections. In short, they are the 800 pound platform with the ethics of a small-time crook. You wanna trust them, go ahead.

    But I bought a product from ubnt and would think they have enough talent to come up with an authentication system other than relying on these two questionable providers. I don't understand why I have to trust either Google or Facebook to use features in the product I bought from ubnt.

    Lemme ask you this: suppose every time you wanted to start your car, you had to call your local indoor carpet salesman or life insurance saleswoman? Would you be happy with the car, even if it was a BMW or Cadillac?


  • @alex-neihaus:

    I'm with you in that Facebook turns its users into its products. However, how you and I feel about their business model does not mean that their OAuth implementation is insecure.

    Facebook doesn't clearly identify its login authentication protocols

    OAuth is clearly identified here, which was linked to by the link you gave to me via a link labelled Security. Just because they have additional options for certain scenarios, and not all of them are OAuth, also doesn't mean they're insecure.

    I hate Facebook. You don't have to convince me of that. However, if you're going to claim that their OAuth2 implementation is insecure, that is something that I need to be convinced of, hence why I asked.

    Security by obscurity is no security at all. Security is hard -- if you don't allow people to understand the pieces you used and how you put them together, you probably did it wrong.

    This doesn't sound like proof that it's insecure. It sounds like rationale for why you're assuming it's insecure. I get where you're coming from but this is far from proof that it's insecure. That said, what are you wanting them to explain exactly that they're not explaining? What are you claiming is undocumented?


  • What I want is simple: a way to log in to my remote AmpliFi from the app that does not use external services' authentication.

    Oh, I want to be able to log in when the AmpliFi is in bridge mode behind another router.


  • @alex-neihaus I won't argue with those desires one bit. Very reasonable things to want. 🙂

    What I want is simple: a way to log in to my remote AmpliFi from the app that does not use external services' authentication.

    I recommend you propose this in their Suggestions forums over here. I'd guess they chose this implementation due to the fact that this is a consumer-focused product. Their prosumer/business-focused UniFi products certainly have other options.

    Oh, I want to be able to log in when the AmpliFi is in bridge mode behind another router.

    This sounds like a problem and hopefully @UBNT-Gunars or somebody else can still help you with this problem, or identify it as a broken edge case so they can fix it or get some documentation produced to help you through a work-around. Unfortunately, I just can't help. I do recommend you continue pursuing this specific problem in this thread to keep it on focus. 🙂


  • As a side note, my router is configured in bridge mode behind another router (custom built Linux system). You have to give the Amplifi router a static IP, then you can configure a port to forward allowing remote access. That being said though, I am using Google to auth 😛


  • @Alex-Neihaus: I just checked and remote access works when the router is in bridge mode. We do have our own authentication mechanism that's used by UniFi, but we haven't made it available for AmpliFi yet.


  • @brian-hellman @UBNT-Gunars Just to be clear, I am not asking about remote access, which "works" (as long as you don't need to connect the Teleport to a WiFi hotspot with its own login). I've forwarded a port to the router and it sorta, kinda, works.

    My complaint is about remote management access from the iOS app to the AmpliFi at the remote end. If you get a pairing-approval request at the Teleport and you're remote and the AmpliFi is behind a router in bridge mode then there is no way to access it to accept the remote request from the iOS app.

    Brain dead.


  • @alex-neihaus So if I understand correctly, you're looking for a process to pair a new (reset) teleport with the base remotely that doesn't rely upon federation with any other provider than UBNT federation servers, correct? Essentially, all pairing would take place over that channel rather than communicating over the local network.

    I just want to re-clarify the ask as this thread has been in a number of places.

    I actually like that you bring the devices together to fully pair. If you just did adoption/pairing over the account, someone who took your credentials could easily get a full time tunnel into your network because they could both request the adoption and accept it over the same channel. Now, if they added in some secondary factor, I do agree it'd be nice to have the freedom to totally reset the thing wherever and could simplify the process overall. But only with that secondary factor would I be interested in that.

    @UBNT-Gunars Does resetting actually break the pairing? I didn't think it did since I reset mine a dozen times before we even had the ability to break the pairing.


  • @alex-neihaus said in Horrific design issue:

    If you get a pairing-approval request at the Teleport and you're remote and the AmpliFi is behind a router in bridge mode then there is no way to access it to accept the remote request from the iOS app.

    As I said, remote access (or remote management as you call it) works even with the router in bridge mode.


  • @michael-eckhoff said in Horrific design issue:

    Does resetting actually break the pairing?

    It doesn't break the pairing that requires physical presence, but it will trigger a request for pairing confirmation. If you have remote access enabled in the app, you can do this remotely. It doesn't matter if the router is in bridge mode or if it's behind several layers of NAT. Remotely confirming pairing will still work.


  • @alex-neihaus so you cannot use the iOS app with remote administration enabled unless you are local to the router with is in bridge mode? That seems odd...

    For the longest time mine was also in bridge mode and I never had any issues using the remote administration (through Google) accessing the router.

    Now if you can access the app and see your network but you never get the pairing request, that would be a different issue, one that I experienced only once.


Log in to reply
 

Looks like your connection to AmpliFi was lost, please wait while we try to reconnect.