Author Topic: Updating the UI: Network / Remote Control Screen  (Read 14075 times)

DDR

  • Krontech
  • Full Member
  • *****
  • Posts: 111
    • View Profile
    • Krontech
Updating the UI: Network / Remote Control Screen
« on: September 21, 2018, 09:23:38 PM »
So, something I just realized here is that - now that we have Debian up and running - we need a way to configure network access. This covers HTTP for the web app, the HTTP control API itself, and SSH access to the root of the camera. Now, a word of warning - I'm a UI designer, not a network admin or security expert, so I'm actually somewhat unsure of this design. Please call me out on my mistakes.


For configuring access to the web interface, it wouldn't do if just anyone could log on to our cameras and control them by default. Someone might go and make a web page that gave you control of a random camera, and we wouldn't want that. I figure requiring a password to be set before enabling web control will avoid that problem nicely. It's also probably all we can do anyway, since anything more, such as 2-factor authentication, is much more effort and complexity than it's worth in this scenario. We may not be able to use HTTPS anyway, so whatever credentials are set will somehow wind up transmitted in plain text anyway. We can hash the password, at least, but it's still fundamentally insecure. This would be all fine over a local network without access to the internet at large, but the internet has a habit of getting into places it shouldn't. :-\ Realistically… though… it would probably be fine. But still. Sheesh. I'd like to do this properly if I can.


For SSH access to a Linux machine, given the amount of malware that's out there trying to log on to everything, best practise is to use key-based authentication. We could use a password, but I think that is inviting disaster given the sheer volume of shit that will be thrown at the camera. Since anyone wanting to SSH into the camera will probably have used SSH before, and since key-based authentication is quite common, I assume it's quite reasonable to require it to access the Chronos CLI.

We could have a password and *then* let you set up key-based authentication on your own, but I think most people will honestly just set the password and get on with whatever they need to do.

Connecting via the MiniUSB would bypass all access control. Since you have physical access, you could just reprogram the camera firmware anyway, so there's no reason to deal with any of this. :D


With all this in mind, I've mocked up two versions of a network control screen.

Version 1:


In version 1, we've laid out remote control, api access, and ssh access authentication.

Tapping on one of the SSH keys in the list will highlight it and show an X, and tapping the X will delete that key so it can't be used to log on anymore. (All keys grant access to log on as the root user. This can be changed later by logging on and setting up users as you want, if you want. Since the Chronos is running a Debian Linux under the hood in this instance, you can do whatever you'd do on a traditional server. I don't really anticipate wanting to manage users though, so I've made no allowances for it in the UI.)

I've made the screen lockable, not that it's worth very much since anyone can pop out the system MicroSD card and fiddle with the saved settings on it. I might just remove the button entirely, since perhaps it confers a false sense of security.

You can also click the underlined address to bring up a QR code. I don't like typing things in, much simpler to just scan and be taken to the mobile app. ;D

Version 2:


In version 2, which I like quite a bit more, I unified the HTTP API and web app controls. The web app uses the HTTP API to control the camera, so you can't really have one without the other. I figure if you're just using the HTTP API, it's not a big deal if the web app is being served in the background. You can just ignore it. Unifying the controls also freed up enough space to display the IPv4 and IPv6 addresses' QR codes on screen, which I think is less confusing. We don't use the underline anywhere else in the back-of-camera UI.

One alternative to this layout might be to drop IPv6 address entirely () and put a longer description in that space. It would be nice to use IPv6 to expose the cameras on the internet, though, since stable IPv4 addresses are getting harder to come by these days.

Note: The web address section only shows up after you've enabled the network interface. The "Next Address" button only shows up if there's more than one active network interface - ie, you've plugged in MicroUSB and Ethernet, and maybe WiFi if we can get it working reliably. It'll cycle through the things which are plugged in.

So, as always, please tell me you think. The best time to change designs is while they're still on the drawing board. :)
« Last Edit: September 21, 2018, 09:29:28 PM by DDR »

BiduleOhm

  • Jr. Member
  • **
  • Posts: 85
    • View Profile
Re: Updating the UI: Network / Remote Control Screen
« Reply #1 on: September 22, 2018, 06:53:24 AM »
For SSH I think you need to add a field for the port because leaving the SSH server on port 22 is not a good idea (the vast majority of automated attacks by bots are on the default port, if you can change it you avoid 95 % of them).

NiNeff

  • Full Member
  • ***
  • Posts: 169
    • View Profile
Re: Updating the UI: Network / Remote Control Screen
« Reply #2 on: September 22, 2018, 12:06:07 PM »
For SSH I think you need to add a field for the port because leaving the SSH server on port 22 is not a good idea (the vast majority of automated attacks by bots are on the default port, if you can change it you avoid 95 % of them).
This is then just security by obscurity and therefore not really secure. It might also break (badly designed) stuff which relies on the defaults. I do however like the general idea to be able to change the port using the UI.

I've made the screen lockable, not that it's worth very much since anyone can pop out the system MicroSD card and fiddle with the saved settings on it. I might just remove the button entirely, since perhaps it confers a false sense of security.
Indeed, get rid of the locking. It's less stuff to implement and more screenspace!

In version 2, which I like quite a bit more, I unified the HTTP API and web app controls. The web app uses the HTTP API to control the camera, so you can't really have one without the other. I figure if you're just using the HTTP API, it's not a big deal if the web app is being served in the background. You can just ignore it. Unifying the controls also freed up enough space to display the IPv4 and IPv6 addresses' QR codes on screen, which I think is less confusing. We don't use the underline anywhere else in the back-of-camera UI.
I also prefer version 2. However displaying 2 QR Codes next to each other is confusing and might be error-prone. Maybe only ever display one type of IP and add a button to switch? Like "display IPv6" ?

note: The web address section only shows up after you've enabled the network interface. The "Next Address" button only shows up if there's more than one active network interface - ie, you've plugged in MicroUSB and Ethernet, and maybe WiFi if we can get it working reliably. It'll cycle through the things which are plugged in.
Then perhaps call the button next interface or next adapter. I had to read your description to figure it out, but it should be obvious from just looking at the picture.

So, as always, please tell me you think. The best time to change designs is while they're still on the drawing board. :)
I like it in general!

BiduleOhm

  • Jr. Member
  • **
  • Posts: 85
    • View Profile
Re: Updating the UI: Network / Remote Control Screen
« Reply #3 on: September 22, 2018, 01:53:34 PM »
Of course it should not be the only element in your security, it's just a very simple way to avoid the majority of attacks.

DDR

  • Krontech
  • Full Member
  • *****
  • Posts: 111
    • View Profile
    • Krontech
Re: Updating the UI: Network / Remote Control Screen
« Reply #4 on: September 26, 2018, 06:56:05 PM »
Thank you for the feedback, NiNeff and BiduleOhm. I've spent a few hours here going back and redesigning the screen, and it has really benefited. :D

Version 3:


Of course it should not be the only element in your security, it's just a very simple way to avoid the majority of attacks.
Exactly, BiduleOhm.

Re SSH:
It might also break (badly designed) stuff which relies on the defaults. I do however like the general idea to be able to change the port using the UI.
I've never come across anything that's been unable to deal with nonstandard SSH ports either, since it's so common. However, I can definitely see some networks could be locked down in weird ways. I've added it to the design. :)

For SSH I think you need to add a field for the port because leaving the SSH server on port 22 is not a good idea (the vast majority of automated attacks by bots are on the default port, if you can change it you avoid 95 % of them).
Hm, probably best to make it easy, then. Plus, I was able to add the actual command to connect in that space. :)

Indeed, get rid of the locking. It's less stuff to implement and more screenspace!
Gone! The illusion of security is worse than insecurity itself.

I also prefer version 2. However displaying 2 QR Codes next to each other is confusing and might be error-prone. Maybe only ever display one type of IP and add a button to switch? Like "display IPv6" ?
Given the relatively poor support of ipv6 overall, I've removed it from the GUI entirely. I think it would just cause confusion for the most part when it inevitably didn't work. ipv6 is still be available through the command-line interface, and it should be visible in the connected devices on your network as well.

Then perhaps call the button next interface or next adapter. I had to read your description to figure it out, but it should be obvious from just looking at the picture.
You're right. I've made a drop-down menu so you can select what network interface you're viewing. It says what you're connecting through, so you don't have to guess now. Thank you for calling me out on that. I think I did some rather bad design work there in retrospect.
« Last Edit: September 26, 2018, 07:03:32 PM by DDR »

NiNeff

  • Full Member
  • ***
  • Posts: 169
    • View Profile
Re: Updating the UI: Network / Remote Control Screen
« Reply #5 on: September 27, 2018, 01:51:51 PM »
Looks very promising!

one more thing again:  wouldn't the "enable network interface" checkbox make sense as very first item since everything else depends on it? maybe grey out all the features not working if the net is disabled.
Also, does not enabling the network interface still leave the possibillity to connect via USB? If so that should be mentioned somewhere, preferably in the manual ;D

DDR

  • Krontech
  • Full Member
  • *****
  • Posts: 111
    • View Profile
    • Krontech
Re: Updating the UI: Network / Remote Control Screen
« Reply #6 on: September 27, 2018, 06:27:56 PM »
wouldn't the "enable network interface" checkbox make sense as very first item since everything else depends on it? maybe grey out all the features not working if the net is disabled. Also, does not enabling the network interface still leave the possibillity to connect via USB? If so that should be mentioned somewhere, preferably in the manual ;D

Hm, this is actually a fairly deep question now that I look in to it. After talking it over with my colleagues, we've decided the problem is not as neat as I'd initially thought.

We figure that connecting via the microusb cable is a special case. Since you have to be physically present for this, you always get access to SSH and the remote control app this way. You connect your computer to the camera via USB, visit the URL it says to, and it should "just work". SSH will ask for a password, but the remote control app will not. This is non-configurable, and will always work, and will definitely be mentioned in the manual. :)

If you plug in ethernet or (hopefully!) a wifi dongle, the camera will be accessible over the local network at 192.168.*.*. If you access the app this way, it will ask for a password. SSH still asks for a password as well.

If you go into the settings and check the Enable Remote HTTPS/SSH Access boxes, you can access your camera from anywhere on the internet. (Provided you can route to it.) However, since everyone on the internet can now route to your camera, this is left off by default. HTTPS will be supplied by a self-signed certificate, which you'll have to click through a warning to accept. However, I don't think there's actually any other way for us issue a cert for a device-hosted web app, and I definitely don't want to expose the camera control through non-secure HTTP the internet at large. :-\

Since the default is now to *not* allow SSH from the internet, I'm comfortable with simply setting a password for SSH. You should still use key-based authentication for SSH if you allow access from the wider internet, but you can turn that on from the command-line.

To that end, I've mocked up two new variants of the screen.

Version 4:



Version 5:


NiNeff

  • Full Member
  • ***
  • Posts: 169
    • View Profile
Re: Updating the UI: Network / Remote Control Screen
« Reply #7 on: September 28, 2018, 03:57:50 AM »

We figure that connecting via the microusb cable is a special case. Since you have to be physically present for this, you always get access to SSH and the remote control app this way. You connect your computer to the camera via USB, visit the URL it says to, and it should "just work". SSH will ask for a password, but the remote control app will not. This is non-configurable, and will always work, and will definitely be mentioned in the manual. :)
Good choice! "It just works" should always be the goal :D

Since the default is now to *not* allow SSH from the internet, I'm comfortable with simply setting a password for SSH. You should still use key-based authentication for SSH if you allow access from the wider internet, but you can turn that on from the command-line.
How are you actually checking that the connected interface is "just" LAN? I'm not too familiar with "advanced" network setups...

Other than that I prefere version 4! It has a sowewhat clearer outline. Will there be an additional screen to manage certs or will whe have to set them up using the WebApp/ SSH?

And one very minor nit-picky detail: the port is set to 22 but the command shows 22786 :P

BiduleOhm

  • Jr. Member
  • **
  • Posts: 85
    • View Profile
Re: Updating the UI: Network / Remote Control Screen
« Reply #8 on: September 28, 2018, 04:10:49 AM »
I prefer the v4 because the only difference seems to be the text "Visit the [...] for remote control" which is a bit useless (we all know what to do with an URL) and use interface real estate.
« Last Edit: September 28, 2018, 04:12:29 AM by BiduleOhm »

DDR

  • Krontech
  • Full Member
  • *****
  • Posts: 111
    • View Profile
    • Krontech
Re: Updating the UI: Network / Remote Control Screen
« Reply #9 on: October 02, 2018, 07:48:35 PM »
How are you actually checking that the connected interface is "just" LAN? I'm not too familiar with "advanced" network setups...
For SSH, we can restrict logons to the 192.168.x.x subnet. This subnet is not publicly routable, so it isn't accessible from the internet at large.

Will there be an additional screen to manage certs or will whe have to set them up using the WebApp/ SSH?
I think you'll have to accept a self-signed certificate. Certs are very much tied to domain names, and since the camera doesn't have a domain name it can't really be certified as being "at that domain". The whole HTTPS system falls down a bit for embedded software, unfortunately. :-\

And one very minor nit-picky detail: the port is set to 22 but the command shows 22786 :P
Oh shoot! Totally missed that one. xD

I prefer the v4 because the only difference seems to be the text
I moved the interface up into the header, since it selects what information is shown too. But yeah, not too much difference between the two.

BiduleOhm

  • Jr. Member
  • **
  • Posts: 85
    • View Profile
Re: Updating the UI: Network / Remote Control Screen
« Reply #10 on: October 03, 2018, 01:09:58 AM »
For SSH, we can restrict logons to the 192.168.x.x subnet. This subnet is not publicly routable, so it isn't accessible from the internet at large.

AFAIK you can route anything to anything.

DDR

  • Krontech
  • Full Member
  • *****
  • Posts: 111
    • View Profile
    • Krontech
Re: Updating the UI: Network / Remote Control Screen
« Reply #11 on: October 05, 2018, 04:03:39 PM »
ARIN says they're reserved for private use. I'm not sure what the implications are, though.

Quote from: ARIN link=https://www.arin.net/knowledge/address_filters.html
Note that only a portion of the "172" and the "192" address ranges are designated for private use. The remaining addresses are "public," and routable on the global Internet.

I figure it'll be fine in most cases - anyone setting up a nonconforming network either knows what they're doing or have larger security issues.