-
Web Configuration page - Should I bother with TLS/SSL?
Posted by David Chamberlain on 20 Mar, 2018 22:38 -
For an embedded device I am working on we have a dedicated configuration Ethernet port. A tech would connect their laptop and navigate to a web address of the device via a static IP address. We would return a little web application that allows them to configure various settings of this device. It is a Linux disto and we are not particularly resource constrained.
The question is should I use TLS/SSL to secure the channel or not bother with that.
Reasons not to bother are
- A certificate from a trusted CA will expire in about 2 years and the device is expected to have a much longer service life.
- The device is offline (with respect to the internet) so installing updated certificates is going to be a PITA.
- The configuration port is only meant to be accessed via a direct link and is not 'normally' connected to any network.
- self signed certificates are blocked (Chrome) or throw warnings that just look bad to our end users.
- We could ask techs to install our certificate as a trusted but that's also a pain (likely on Windows laptops)
Reasons to bother are
- We can not guarantee a tech will not try and connect the configuration port to a switch or some other network exposing the unsecured interface to that network.
- When we get this device externally pen tested it's likely they will mark the unsecured channel as a security risk on the report, and this will cause our customers to ask questions.
- I personalty would prefer to have this channel encrypted.
We could require a OpenSSL connection and transport the web app over HTTP but OpenSSL will have the same certificate issues as above?
If we use basic HTTP authentication ONLY on the app then those credentials could be leaked easily. So for me it's almost as good as having no security. Of course if I did that the customer would be given the ability to change the user/pass later.
Even if we could use a certificate it would be BEST that each device had a unique certificate, and this could get costly and hard to deploy / manage.
Another idea if it's totally unsecured is to have the interface disable itself after some time after power-up.
Just wondering how others here have approached, compromised on or otherwise implemented this.
Thanks
+ Attachments and other options -
Dont use a webinterface, you can not get it secure. There are 1000s exploits you dont want to defend against them all the time.
OpenSSL needs updates to, certificates needs updates, spare yourself the trouble unless it is a requirement from someone who knows his stuff, not some marketing wanker.
Use SSH instead, you could close it after a few minutes if you want. Just use a strong username password and make them unique per device , absolutely no default stuff. -
Disclaimer: I'm not a security person. You should probably ask your security auditors about what you should do.
You won't be able to get a certificate from a CA for an ip address. If you want to go with HTTPS, your only options is self-signed.
I suggest you go with just HTTP, and instead try and make sure the device is only connected directly to a technician's computer.
I think a way to achieve this is (I have not tested this) to force the device to only have an ip address from the link-local block, so it's unlikely that anyone will connected to it, unless they are connected to the same network and is specifically looking for it. I believe this also has the added benefit of allowing windows to connect to it without a dhcp server, since windows will assign itself a link-local address when it can't find a dhcp server. -
HTTPS will not work through a bare IP address. It requires a domain name. Therefore, you will either need a network to have a DNS server (through Internet connection?), or your technician will have to manually edit "/etc/hosts" on his computer.
Also, storing the certificates with private keys (which if stolen may be used to impersonate your identity) on devices which you ship all over the world looks like pure madness to me. -
IMHO you should assume the device will be connected to an internal network at some point so it is likely to see some hack attempts from worms/malware. Perhaps your best bet will be to use your own certificates and require these to be installed in the browser. This way you avoid needing (acces to) a third party to validate the certificates. If you are brave you can use these certificates as authentification too so you don't need the user to enter a password.
Make sure the business model allows to cover the costs for security updates.
@Northguy: HTTPS will work without access to a DNS server / internet (been there, done that). Only when a certificate needs verification from a third internet access is required. -
To reduce the risk of numpties leaving it connected to their LAN, why not implement: If the configuration LAN port is detected as connected, disable normal operation and offer your preferred configuration interface.
-
HTTPS will not work through a bare IP address. It requires a domain name.
Bluntly, wrong. See RFC 3779 - "X.509 Extensions for IP Addresses and AS Identifiers".
-
Leave it off by default, but give the option of adding a certificate if the user wants to.
-
Thanks for the ideas.
@Kjelt : Actually I like this idea, but only if I was the only person interacting with the equipment. A few flaky reasons for requiring a web interface is a) We are dealing with the sort of tech's who break in to a cold sweat at the sight of a console prompt b) management will want to plaster our logo all over it. So a visually pleasing GUI is the way to go and the web interface seems like the simplest. I guess I could write a desktop app that wraps the scary SSH stuff but installing third-party applications requires all sorts of additional regulatory hoops in our particular space.
@All aside from the Domain/IP question - CA certs are generally out of the question because they cap out at a 2 year lifespan and need our gear to be working for 5 years minimum.
@NorthGuy : Yes having the certs stolen off the device is a valid risk in our case.
@amyk : Yeah it's desirable to give the customers the option of what they want to use but I feel most will opt for the easy way. As it can be added later I'll definitely add it to the TODO list.
@nctnico : Again requiring the users to install the certificates is probably a bit much to ask. But we could do it if we have too. We already have an internal procedure called "How to make IE trust a self-signed certificate in 20 irritating steps"
- [EDIT: source]
Thanks again for the feedback, I'll have a think but I am leaning towards llkiwi2006 suggestion here of going plain old HTTP, filtering by source IP, having the config interface up for a couple of minutes after bootup, and requiring a configurable user / pass combination on the web app.
-
HTTPS will not work through a bare IP address. It requires a domain name.
Bluntly, wrong. See RFC 3779 - "X.509 Extensions for IP Addresses and AS Identifiers".
Think about it. If you can get a valid certificate for 192.168.1.1, so can anyone else. Therefore, such certificate wouldn't really let you authenticate the identity of the server. Certificates only work because certification authorities verify your identity and your connection with the domain name.
-
HTTPS will not work through a bare IP address. It requires a domain name.
Bluntly, wrong. See RFC 3779 - "X.509 Extensions for IP Addresses and AS Identifiers".
Think about it. If you can get a valid certificate for 192.168.1.1, so can anyone else. Therefore, such certificate wouldn't really let you authenticate the identity of the server. Certificates only work because certification authorities verify your identity and your connection with the domain name.
You said "HTTPS will not work through a bare IP" and "[HTTPS] requires a domain name". This is not the same as "is impractical because..." which appears to be what you were really trying to say, with which I'd largely agree, but it's not the same as will not work. I can assure you that HTTPS will work fine with a bare IP address as I've done it many times.
Indeed in the early days of the web it was quite common to bind a certificate to both a name and an IP address because at the time you couldn't serve HTTPS for more than one domain name from the same IP address because TLS SNI didn't exist.
Anyway, you'll only get a valid certificate for 192.168.1.1 from the kind of CAs that are rapidly getting dropped out of Mozilla and Google's CA lists precisely because they *did* issue certificates for 192.168.1.1, multiple times!
Although it's an unusual requirement you can get certificates for IP addresses and a strong hint as to who might need to do that is in the second part of that title "AS Identifiers" - think firing up BGP sessions before you have the luxury of DNS or even transit connections to the rest of the world and yet need to authenticate the far end. As it is this route toward BGP security has turned into a backwater.
There's a section in the "CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates" on validating IP addresses for the issuance of certificates:3.2.2.5. Authentication for an IP Address
For each IP Address listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant has control over the IP Address by:
1. Having the Applicant demonstrate practical control over the IP Address by making an agreed?upon change to information found on an online Web page identified by a uniform resource identifier containing the IP Address;
2. Obtaining documentation of IP address assignment from the Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC);
3. Performing a reverse?IP address lookup and then verifying control over the resulting Domain Name under Section 3.2.2.4; or
4. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant has control over the IP Address to at least the same level of assurance as the methods previously described.
Note: IPAddresses may be listed in Subscriber Certificates using IPAddress in the subjectAltName extension or in Subordinate CA Certificates via IPAddress in permittedSubtrees within the Name Constraints extension. -
Quote
b) management will want to plaster our logo all over it. So a visually pleasing GUI is the way to go
Tell them they will be on the news soon, everyone will hear about their company.
Another IoT device that is used to launch DDOS attacks.
Lesson1) Never ever built an internet facing server unless you know exactly what you're doing eg five years of experience and rigurously pentested.
Lesson 2) make sure you're device has no "public profile/footprint" so it can be easily found over the globe using Shodan. Hint corporate logo is red flag.
3) attend the SANS5.42 class and know what you are up against before making decisions.
This was my job for a few years, i did do SANS, got my license, it is a mess out there and becoming worse.
Only thing I can advise you is to hire an expert consultant where people listen to before it is too late.
Brand damage is hard to turn back.
-
Tell them they will be on the news soon, everyone will hear about their company.
Got it, don't put logo on to avoid potential brand damage
-
Got it, don't put logo on to avoid potential brand damage
PMSL!
Actually the fact that certificates for freestanding embedded devices are a non starter is a real problem, especially as the browser makers are getting ever hotter on wanting everything to be HTTPS, to the point that it may well become difficult to use a non HTTPS server.
My thing is broadcast industry products, where a web page on a trivial processor is the obvious way to configure the things, but there is no expectation of an internet connection. This interacts badly with a combination of corporate IT pushing for HTTPS everywhere and CAs that will not issue me a certificate for the entire /32 address space (Boring of them!), with an expiry time measured in a few tens of years or so.
Fact is, I don't really need authentication, I don't even really need crypto, you are not getting into the box without a password, which takes care of the authentication thing, and a page that just configures a mess of audio routing is not exactly going to have PI entered into it, over the wire crypto is mainly a defence against MITM which is not a big threat in my threat modelling, that is what VPNs at the switch are for.
Regards, Dan. -
Let me start by saying I am no expert on this, but I am just wondering...
If you make the device have its own LAN with its own ip-range & subnet mask, can it be found/connected to if it is connected to another lan?
I though I can't connect to a device on my home lan if it has its own lan? -
That is NAT (Network address translation) hiding your internal lan (Which usually uses unroutable addresses in the 192.168.xx or 10.xx ranges) from the outside world, it is not a given, and you can punch holes in it my telling your router to connect port XXXX on the outside to address YYYY port ZZZ on your internal network.
Regards, Dan. -
I didn't mean for the outside world, but just in the local lan
Does NAT also work on internal LAN? -
I didn't mean for the outside world, but just in the local lan
Well, no. NATs sits on the edge of a LAN and in that sense, it is a router. But it isn't really relevant to your question if I understand it correctly.
Does NAT also work on internal LAN?
Even if you were to set your device to a completely different IP than what your LAN normally uses, it is still very much accessible by other devices on the same LAN segment. -
Ah. ok thanks
But since topicstarter says device is powerfull enough, can't you then install a firewall or something to block any traffic not in the same subnet or maybe block addresses not served by its own DHCP ? -
- The configuration port is only meant to be accessed via a direct link and is not 'normally' connected to any network.
You can overcome this by not making it a network port.
[...]
- We can not guarantee a tech will not try and connect the configuration port to a switch or some other network exposing the unsecured interface to that network.
- When we get this device externally pen tested it's likely they will mark the unsecured channel as a security risk on the report, and this will cause our customers to ask questions.
Make it a USB service port. Name it "service port".
What you can then do is:
- Enumerate as Thumb Drive and CDC.
* On the (read only) thumbdrive you can put the GUI programs.
* On the CDC you can use telnet communications.
Or even enumerate as USB Network adapter to still show a webpage. You will still have the IP problems, what IP and mask do you need to set, what others are on the pc?I think a way to achieve this is (I have not tested this) to force the device to only have an ip address from the link-local block
You'd have no way of easily accessing the webpage with linl-local IP addresses.
If you want to use a LAN port, and do not want to have it networked, fix it's IP and only accept one other IP address. If the customer wants to network it. The customer must enable it, and the device is "secure" by default. -
Fixed IP does not fly when you have potentially a few dozen of the things on the LAN, and when addresses are assigned centrally.
This assumption that a LAN must somehow have something to do with the internet is what gets me, we routinely have local area nets that are just that, local.
It would be nice to still be able to serve web pages on them without having to jump thru stupid hoops that only actually apply to the WAN use case.
Really the security boundary should be at the edge of the LAN, which pretty much means that packets crossing that boundary (In either direction) are untrusted (and thus that Turing completeness in web programming languages is a bug not a feature when that traffic comes from outside the local network). No amount of TLS changes that untrusted status because all you are really doing is moving the threat to the risk of a server being owned.
Ideally browsers would look at the source IP for the network traffic and apply different rules depending on the origin, if it is local subnet (and NOT the gateway address) you can do different things to what you do if it is coming in from the WAN, maybe some sort of VLAN style tagging by the border router?
Regards, Dan. -
Just use a strong username password and make them unique per device , absolutely no default stuff.
Which absolutely SUCKS for automated deployments etc, and that is becoming a big thing these days. Zero touch provisioning even!
I work in telco, so I speak from my experience in this industry...
Gear does not come with a certificate installed. Most of the time management is done via command line (SSH for example), or for more complicated systems (optical transport for example) usually via a vendor supplied application - that might use SNMP under the hood, or maybe even telnet to talk TL1 or some other language to the device, so things like IPSEC become important.
Make the command line easier to use - use numbered menus etc to appease the CLIphobes. I avoid web interfaces where at all possible as usually they have a limited/crippled subset of functionality than is available via the CLI.
Locking the management interface to the link local subnet would also suck. Telco networks are managed and monitored from far and wide, usually through a secured side channel, maybe with IPSEC as well. Being able to configure the IP address of a device in a management subnet assigned to a particular location is essential to be able to remotely manage and monitor the device and what ever is connected to it.
I dont know what industry this device is for, but some of the suggestions made here make me shudder. If you have to physically sit yourself in front of a device to be able to manage it, youre doing it wrong IMO.
True, software that involves crypto etc can occasionally require updates - spend the time and make that an easy process. If people dont secure their networks properly that is their problem. Dont cripple your product to protect against the maybe situations that end users might come up with, otherwise when something happens they might point the finger at you for leaving a hole - if it is ever discovered and not just kept in the back pocket of some three letter government organisation for later...
Network security is organisational policy - not equipment vendor responsibility. Provide tools like access lists/firewalls that can be utilised as part of an organisations security policy, follow any particular laws/legislation/industry rules that may be applicable to you, but dont try and be clever about it. -
In this post you stateFor an embedded device I am working on we have a dedicated configuration Ethernet port. It is a Linux disto and we are not particularly resource constrained.
Look at some things in above.
Linus can/does use internal servers and some are web based.
Here the host address is "LocalHost" which has an IP starting with 127 for IPV4 and good security has a firewall that prevents access to all but programs running on device.
Note that in my view counting on local network addresses for security is very bad idea. This is counting on the security of all devices connected to network being secure. Just one bad device and all security is gone.
Unless you want to get known for building old stuff you also need to use modern and secure as foundation.
This implies that IPv4 & IPv6 should be supported at this time.
To get good control security you need to add a base of physical access to device. For example,
A button that has to be pressed on device to start low level security build.
A key printed on device to just allow network device with that key to connect at this reduced security.
That is a simple two factor authentication and should only be used to create a more secure connection.
To talk to a device on Ethernet you just need two things unless security prevents it, The IP address & Port.
You can add DNS to make it easer and if done correctly you can add DNS security in the process.
Now with linux as a foundation you can do better then bare CLI access via SSH.
SSH allows use of certificates in place of passwords. The SSH server can add security basted on connecting IP address.
The SSH client has some security you can use to get started.
One problem with CLI is users getting the config wrong.
CLI config can also be a huge pain.
This is where something like "Ansible" can be a big help.
Ansible lets a client program use SSH to work with the SSH host with little to no added software needed on host.
If there is network connectivity then one to thousands of devices can be configured. Ansible will let you verify that host is configured properly matching the facts that Ansible program is using. Notice "HOST" & network connective here.
If you can connect to a new linux host with SSH, Ansible could setup the whole system with little user effort.
You can use Ansible to check and/or configure the local host also.
Think of the fine details here. With the Ansible program you can quickly make a clone of a device or build a replacement for a failed device.
As Ansible will run on window, Mac & Linux computers, Complicated things just got very easy, checkable & upgradeable.
This is all possible with the open source version of Ansible which is a subset of Ansible Tower.
If you use Ansible properly it can save a lot of time.
You could use it to build, update, config & test device before shipment.
And use it at client site to make it easy & more secure.
You can use powerful tools and still keep is simple.
You can give you end user very powerful tools and still keep it simple.
Still a very good idea to have someone better at security looking over your shoulder.
With Ansible written in Python, your users that want to check can look at what ansible program will do if they want.
It also shows how easy a system can be hacked with little knowledge
Security is only good as it's weakest link.
-
You can also use a client side certificate and have the device validate the authenticity of the client.
-
From the client you can get better security by using two certificates, one for device and second for user.
When you are prevented from using two, you can still have a certificate for user & device.
So better security is just a matter of being able to create a certificate which is something that linux can easily do.
Most systems actually use many certificates