HTTPS is pain in the neck and _currently_ I hate it from the bottom of my heart.
TLTR: if you have a commercial service or device running in a local network forget HTTPS and service workers, use HTTP and HTML5 appcache.
-- RANT starts here --
It would be lovely when every website and webapp uses HTTPS. But for a significant amount of them it's just not f..... possible without driving users completely insane.
If the HTTPS server doesn't (and never will) have a public domain forget about encryption and security, forget about using service workers. The following examples can't, by the love of god, ever provide HTTPS without completely f..cking up user experience due self signed certificates warnings:
1) internal corporation services, websites and webapps.
2) services that run in a local private network like on a Raspberry Pi.
3) webapps which are served via public HTTPS website, but need to talk via CORS to local unsecured services, like to a Philips hue bridge, or any other IoT device which is in the local network but only provides HTTP. These will enlight the users with a shiny mixed-content warning.
.... JUST use self-signed certificates, they said.
NO.
For normal users the UX of self-signed certificates is just non existent, it's a complete mess! It will scare the sh't out of users and will almost always look like your service is plain malware.
It looks much more secure to serve a good'ol HTTP site with no encryption at all.
> 1) internal corporation services, websites and webapps
If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy? And how would you feel if people on the same LAN could see and modify all your interactions with those services?
2) services that run in a local private network like on a Raspberry Pi
Depending on the type of service you may or may not want TLS. If you visit the service by IP address and specific port anyway, you can easily add an exception for your internal IP. This will never be used like so by non-tech-savvy people.
3) webapps which are served via public HTTPS website, but need to talk via CORS to local unsecured services
I cannot think of any reason to /not/ want to use HTTPS on this. It's horrible how things like the Philips Hue bridge work and rely on insecure HTTP to control your home lighting.
Don't blame browsers for warning people for their insecure systems and appliances. Instead blame their creators or manufacturers as they're the ones who can fix this situation.
> It's horrible how things like the Philips Hue bridge work and rely on insecure HTTP to control your home lighting.
The Philips hue bridge REST API is accessible in the local network like http://192.168.1.123/api/ .... which is great since apps/wepapps can talk to the bridge without a cloud or philips server inbetween.
And this is the very problem, it's not possible for Philips to add HTTPS support to the hue bridge without some sort of cloud roundtrip to a Philips server, keeping the very cool feature to talk only within the local network to the bridge.
Because how could that be deployed without self-signed certificates and the usual browser exceptions and warnings?
If it is an http API, you don't really need a public certificate. You can have a long term selfsigned certificate on the device and you check that the thumbprint hasn't changed every time you connect from your client. These big warning windows are for connecting to it from a browser, not a RestClient.
Cross-domain is needed, otherwise an app/webapp couldn't talk to the bridge since the bridge only serves the REST API.
However in order to send control commands and query light states the app/webapp needs to authenticate and create a account, which is only possible for a few seconds after pressing a physical bridge button.
We have the same issue with Glowing Bear (https://github.com/glowing-bear/glowing-bear). It's a web frontend for an IRC client (WeeChat) that connects directly to WeeChat via WebSockets. Sort of like self-hosted irccloud without a cloud. We really want everyone to use encrypted connections [0] and push people onto the TLS version of Glowing Bear. But some people host their WeeChat on their local network, and you can't (realistically) get a certificate for a local IP. So for those people we need to open an unencrypted websocket (ws://1.2.3.4), which isn't possible from an https site. Ideally we'd like to disallow unencrypted connections to non-local destinations but that's practically impossible to determine in JS. It's a super annoying problem.
Disallowing unsafe websockets from secure origins is one of those policies that is a really good idea 99.5% of the time but for those last 0.5% of use cases, it's a major pain in the bum.
[0] WeeChat has a /exec command to execute arbitrary commands, and the client has access to that --- not great when you transmit your password in plain text.
> it's not possible for Philips to add HTTPS support to the hue bridge without some sort of cloud roundtrip to a Philips server
I don't see why not. The alternative is freedom. Philips doesn't have to lock their devices. That's a choice they made, sadly the choice that most companies make.
> Because how could that be deployed without self-signed certificates and the usual browser exceptions and warnings?
The fact that your browser warns you about insecure communication happening from that web page, that's a good thing. Even iff you deliberately choose accept that and believe that there's no other way for this particular service/device.
The simple fact that you accept some insecure traffic, doesn't make it secure.
> > it's not possible for Philips to add HTTPS support to the hue bridge
> I don't see why not.
That's not a constructive argument. I don't see how they could make it work?
Even if they somehow solve the problem of giving these devices domain names and even if they generate separate private key for each unit, the key and cert are going to be embedded in the firmware and a sufficiently sophisticated attacker will just extract them and become able to impersonate some Philips device.
How the user of another device is going to tell whether he is connecting to his device or to malicious neighbor impersonating neighbor's device to establish Philips-signed HTTPS with the victim and then another connection to victim's device and MITM the victim?
You would have to make all users install a trusted certificate authority tied to their individual device. Which is a UX disaster in current browsers and also a security disaster, because if this becomes a norm, sooner or later somebody will sell you a toy device bundled with a CA crafted to give him the ability to impersonate any website. And you'll trust this CA because you want to play with the toy.
This maybe could be made to work with some improvements in browser UI. Make it easier to add new roots of trust. Make it easier to learn and/or limit what websites these certs will be authorized to authenticate. But nothing like that exists now.
> The fact that your browser warns you about insecure communication happening from that web page, that's a good thing. [...] The simple fact that you accept some insecure traffic, doesn't make it secure.
True. As somebody pointed out elsewhere in this thread, this warning will become another EU cookie banner nothingburger.
> > > it's not possible for Philips to add HTTPS support to the hue bridge
> > I don't see why not.
> That's not a constructive argument. I don't see how they could make it work?
Missing from your quote: The alternative is freedom. Philips doesn't have to lock their devices.
If Philips (and other companies, obviously this doesn't relate to just Philips) would provide a community access to their devices and software rather than locking them out, I believe that this problem would not exist.
The original issue is that having a public website (used over TLS) that interacts with local network devices without TLS shows warnings about insecure communication. Again, the warning is shown because it /is/ insecure. There are plenty alternatives of securely interacting with an IOT device. Plain HTTP from a public website is just not one of them. For example, look at how Apple's Homekit has implemented that. Homekit is not usable from a public web page in a web browser. That's a good thing. (aside: I'm not a big fan of Homekit but their security is not bad)
So if vendors are annoyed with browser warnings, it's because /they/ are doing the wrong thing, not the browsers.
> sufficiently sophisticated attacker will just extract them and become able to impersonate some Philips device
Just like on any website. Just because something isn't 100% unbreakable, doesn't mean it's a bad idea (you do lock your doors, don't you?)
> Missing from your quote: The alternative is freedom. Philips doesn't have to lock their devices.
> If Philips (and other companies, obviously this doesn't relate to just Philips) would provide a community access to their devices and software rather than locking them out, I believe that this problem would not exist.
The problem is technical and won't be fixed by just opening the software.
> There are plenty alternatives of securely interacting with an IOT device.
Please name just one which works for webapps, beside HTTPS.
> So if vendors are annoyed with browser warnings, it's because /they/ are doing the wrong thing, not the browsers.
Homekit is nice but not available to webapps, apps of course can take advantage of several security mechanisms.
My whole rant is about browsers and HTTPS in non public networks.
For webapps which want to talk to IoT devices there is only HTTPS and there is _no_ sane way to provide robust, local!, access to a LAN device via HTTPS.
Here are some requirements: (actually real, I'm working on a IoT'ish product)
* webapp must be served via HTTPS, either from the IoT device or vendor site
* it just works! if webapp served from IoT device, the user shall not be required to install certificate or set exception (because it then looks like scary as hell malware)
* the webapp must work offline (service worker or appcache) without internet connection
* webapp must be able to talk directly to the device, no cloud or vendor server inbetween
* the IoT device which provides a secured REST API might be in in a LAN which is NOT connected to the internet --
so the '<random-stuff-id>.vendor.com DNS resolves to device IP with an Lets Encrypt CA' approach won't work here (otherwise nice hack)
To my knowledge it's technically not possible to build such a HTTPS secured webapp in a local network today without breaking the mentioned requirements.
I think this is part of the larger problem of the relentless "cloud first" movement that the whole industry seems to have adopted. I feel like there isn't any new software, device or standard in development by now that doesn't demand constant internet access and a dedicated background service. Even basic things that should have no business relying on internet access get swalloed by that. (Browsers, operating systems, cars...)
The economic incentives that push everyone in that direction are obvious but I think in the end that will lead to more harm than good.
That being said, I can understand that making IoT devices directly accessible from web page JS fü could cause some security headaches:
As an example, apparently a lot of recent exploits were caused by programs opening a loopback-only REST service for IPC. Those services weren't secured because, hey, if someone can talk to loopback, the system is compromised anyway. The developers didn't realize that any webpage open in a browser can do that via script (respecting CORS) and so even loopback services should be considered exposed to the internet.
I can imagine that an IoT device offering a browser-accessible REST interface might cause similar non-obvious attack vectors. So at the least, it would have to implement some kind of user management and authentication - which might be challenging for small devices.
I think what we really need is some kind of dedicated standard for browsers talking to things on the LAN. Such a standard could then handle discovery, certificate management and authentication/permissions in one go - and would enable browsers to present a good UI for those steps.
However, right now everyone seems to busy developing intricate rube-goldberg machines[1] to care and the agenda of the browser vendors seems to go in the opposite direction - so I don't have high hopes.
I think practically, the most feasible step right now is to forego browsers and build an app instead. Then you have to deal with the headaches of app development but at least you get a nice user experience without any backend services...
> The problem is technical and won't be fixed by just opening the software.
I strongly disagree. Main reason is that if Philips opened their firmware to the public, it would have had different protocols by now than just HTTP with a poor mans JSON API.
> Homekit is nice but not available to webapps, apps of course can take advantage of several security mechanisms.
That's why basically my point is to /not/ use a web app to control local insecure IOT devices.
> Please name just one which works for webapps, beside HTTPS.
Use locally resolvable DNS names and wildcard certificates signed by commonly trusted (public) CAs. It's been done before (Plex does something like this IIRC).
* update: I just noticed another comment [1] that mentions Plex with a link to some technical details [2].
> it would have had different protocols by now than just HTTP with a poor mans JSON API.
Sure, but now you can't control the gadget from the browser and the vendor needs to write an application or something for whatever shitty OS you want to use.
> Use locally resolvable DNS names and wildcard certificates signed by commonly trusted (public) CAs. It's been done before (Plex does something like this IIRC).
Not that simple. Public CAs will likely only give you certs for domains you own (like plex.direct) and your users generally don't have nameservers authoritative for such domains on their LANs (maybe you could pull it off if you are a router vendor, but not with IoT light bulbs) so they have to query your public nameserver and the system fails without Internet connection.
And there is no easy solution: if your light bulb could register an xxx.philips.com domain via UPnP on your router or via SMB on your Windows box, it would be very much unclear what exactly should prevent it from registering philips.com as well.
> Just like on any website. Just because something isn't 100% unbreakable, doesn't mean it's a bad idea (you do lock your doors, don't you?)
Don't you think it's a completely different thing to extract keys from a remote server (try https://news.ycombinator.com/ for example) and a physical gadget you own?
Doubly so if the gadget is open source, as you apparently prefer.
Not really, for a hacker both are remote servers, aren't they? I agree that in practice many security updates are not provided for IOT devices (another reason for FOSS), so it might get easier and at the same time less relevant to extract the keys.
If a gadget is open source doesn't mean the private keys are.. Most internet servers are running open source software (BSD, Linux).
In my opinion the manufacturer should /not/ have your gadget's private key. But that's not really related to this problem.
I was talking about a different scenario: I buy the same kind of light bulb you own, extract its private key and use it to either:
1. impersonate your light bulb, because they both have the same key
2. impersonate my light bulb, because you and your browser can't tell the difference
To prevent such attacks, each device needs its own certificate and key and then furthermore you need one of the following:
1. each certificate is signed by a unique CA which you add to your browser's list of trusted CAs so that it doesn't trust other devices' certs because they are signed by different CAs
2. each device has a globally unique domain and you type this domain into the browser
> 1. impersonate your light bulb, because they both have the same key
Definitely don't give both the same key.
> 2. impersonate my light bulb, because you and your browser can't tell the difference
Who cares if you can impersonate your own lightbulb?
> 1. each certificate is signed by a unique CA
This doesn't change either scenario. If they shared a key then custom CAs don't stop impersonation. If each device has its own key and CA then they still can't impersonate your device, and they still can impersonate their device.
> 2. each device has a globally unique domain and you type this domain into the browser
Typing in "jzhf.hue.com" sound easier than figuring out what IP has been assigned to the device.
> Who cares if you can impersonate your own lightbulb?
For MITM - you think you are connecting to your device, actually it's my proxy (DNS spoof, ARP spoof, TCP hijack, ...), you still get the green bar in your browser saying "über secure Philips lightbulb", you just don't know it's mine because the domain matches and it's signed by the same CA (assuming neither of these protections is in place).
> If each device has its own key and CA then they still can't impersonate your device, and they still can impersonate their device.
Without manual installation of my CA your browser won't accept the certificate ripped from my device.
You said in another post that providing correct address is better than per-device CA. No doubt it's more convenient in a commercial product, assuming you can solve the DNS problem somehow (which doesn't seem possible without working Internet connection or editing hosts file). From pure security standpoint though, I feel like per-device CA has an added advantage of resistance to typosquatting. But it's getting academic now, it's hard to squat if it takes buying a physical device with the right ID.
Plex achieves this with a very convoluted setup [1] - they set up a DNS server so that 1-2-3-4.625d406a00ac415b978ddb368c0d1289.plex.direct returns IP address 1.2.3.4, then they issue a single user a wildcard certificate for *.625d406a00ac415b978ddb368c0d1289.plex.direct
Of course, you have to get a special deal from a CA at who-knows-what-cost - likely meaning open source projects need not apply. And you get a dependency on cloud infrastructure, if they stop issuing certs you end up in a bad place. And you get a giant, ugly URL. And you have to make a DNS lookup so traffic leaves your network anyway.
It's an ugly solution with a lot of downsides - but I doubt the CA/Browser Forum plans to give people much choice in the matter, so it's their way or the highway :-|
wildcard certs are not a solution to this problem. Sharing a private cert with all customers isn't what the solution does. every customer gets their own cert
second letsenrypt has low limits of 20 certs per week. so imagine VLC added a Plex like streaming feature. they'd need far far more than 20 certs a day given how large their user base is
wildcard certs are not a solution to this problem. Sharing a private cert with all customers isn't what the solution does. every customer gets their own cert
That's not what I mean. I mean the same solution as described by michaelt above, that is, provide a different wildcard cert per user.
second letsenrypt has low limits of 20 certs per week. so imagine VLC added a Plex like streaming feature. they'd need far far more than 20 certs a day given how large their user base is
Remember that the limit is only on the number of new users; Let's Encrypt has a renewal exemption that lets you renew your certs even after hitting the 20/week limit. So while it might still not be enough for VLC, I don't think it's a problem for most projects. Plus you can always use more than one domain.
Pretty much any open source project that was to need certs similar to plex would pass this limit the moment they mentioned it on HN. Why should an open source projected have to register hundreds of domains just to handle this case? Someone else gave a long list of the number of devices and services running in his house that need certs like plex. Effectively every router, nas, IP camera, and other networked device that exposes a web interface and therefore every open source project that does those, OpenWRT for example, FreeNAS, ZoneMinder, etc...
BTW, who really is Let's Encrypt, why should I trust them, why should I trust they won't disappear once plain HTTP is no longer supported by cargo-cult-security-conscious browsers?
It seems to me like providing certificates isn't exactly free, in itself.
once plain HTTP is no longer supported by cargo-cult-security-conscious browsers
There already are people talking about such possibility and some even appear to believe it would be a good idea.
Of course what happens then is that without Let's Encrypt you are stuck paying other CAs to have anything published on the Web at all.
<tinfoil hat on>LE is a conspiracy of CAs to phase out unencrypted HTTP and ensure them infinite money stream.
<tinfoil hat off>Even if it isn't, LE will disappear five months after their mission is done because what the heck, why bother.
I just wonder if there is any reason to believe that users of LE are any smarter than kids accepting free candy from pedos? Maybe there are reasons but I just haven't heard them yet.
Ah, I think I'm missing an assumption you're making: that LE is indispensable (or almost) for browsers to deprecate HTTP.
Personally, I think the deprecation (as in, the warning bells and reduced priority, not full blocking) was going to happen anyway, and LE was mostly inconsequential, even if it makes the transition easier.
As for LE being a CA conspiracy, I don't think that makes much sense considering their funders (eg. Mozilla, Google) and those funders relationships with existing CAs (see WoSign, Symantec). But anything's possible.
> That's not a constructive argument. I don't see how they could make it work?
Give each one a subdomain that resolves to its local IP, and give it a valid certificate for that subdomain.
> extract them and become able to impersonate some Philips device.
Or the attacker could just have a real, non-impersonated Philips device. If the user deliberately points their browser at the wrong device's site, nothing can save them. This is a very different problem from securing access to the correct site.
> You would have to make all users install a trusted certificate authority tied to their individual device.
That's not true, and I don't even understand what benefit that would have.
If you have a way to deliver a CA, instead you should deliver the correct address of the device. This makes 'MitM' impossible without any downsides.
>If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy?
If you control physical hardware, and you control all the users on it (as a corporate network), then you can know that nothing is amiss.
>And how would you feel if people on the same LAN could see and modify all your interactions with those services?
The fact that they physically can doesn't mean they will.
For 2 & 3:
https has two modes: self signed, and certified. Certified requires that you have a public facing domain name, such as "news.ycombinator.com". Devices on private networks can't have public domain names. Consumer devices on public networks could have domain names, but this would be very difficult to configure. Without a domain name, https must be done as self signed.
With self signed, when you first interact with the server, it could be anyone. Self signed https only gives you the guarantee that any further interaction besides this first one are with the same server as the first one. It should be clear that you can still be MITMed under this mode, so long as the attacker can intersect the first message you send after a reboot. If you're scared of network ninjas sneaking into your house in the middle of the night and intersecting your packets, self signed https is no better than http.
>With self signed, when you first interact with the server, it could be anyone. Self signed https only gives you the guarantee that any further interaction besides this first one are with the same server as the first one.
If I create a CA and install that CA's public key in my browser, then use that CA to sign the cert for a device on my network, why exactly will it "be anyone"?
Unrelated, but this push for HTTPS for everything isn't without downsides. Many apps gather extensive data when running on my devices and they communicate that data back to some central location, sometimes under the guise of functionality, sometimes straight up nefariously, but always with a side effect of giving that central entity a complete record of what I'm doing and often also exfiltrates my data (contacts, etc.)
Honestly, I've been tempted to set up a transparent TLS terminating proxy at my home to give myself some possibility of seeing wtf is coming and going from my network.
> If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy?
Because a crap ton of Linux software comes with its own set of bundled root CAs instead of using the system defaults. Welcome to the configuration nightmare that is setting up Anaconda, npm, AWS CLI, Python (Requests library), Git, etc. for working with something like Zscaler.
The issue is that Zscaler may have flaws, and that even if the validation is performed flawlessly then the introduced risk is not zero…
Usually one would have to trust the root CAs, but with TLS interception we have to trust the trust of the MiTM software in the root CAs. This increases the attack surface instead of decreasing it.
For a security appliance it’s a pretty bad job; sure, there may be reasons why you want to look into traffic, but then the aim is to control the communication. And control doesn’t come for free.
> 1) internal corporation services, websites and webapps.
For this use case companies usually provide an internal CA, which signs their certificates and is trusted by all company machines. We have various customers which do this and it works just fine.
Small companies/small groups of developers have no idea how to implement and manage this, but think that it should be easy.
I've recently been approached by a group of developers to enable SSL on their internal sites. When I mentioned that this would take some time, the response was "why can't you just use LetsEncrypt?"
I replied that LE only works on external facing sites, not internal sites. The next response was "fine, why don't we make it all external facing?"
I'm still trying to explain that their CI server (Jenkins, with its history of remotely exploitable vulnerabilities), and their internal OAuth2 server should not be public facing.
Google is moving away from network-centric security and VPNs. See https://cloud.google.com/beyondcorp/ . The threat model is a bit different but you could also follow their approach and put an auth proxy in front of Jenkins and deploy it on the public Internet.
But yeah, don't expose Jenkins to the Internet directly. Last month I saw a Jenkins instance that was mining bitcoins. The worm had used one of Java's serialisation vuln to get in the box and install the miner.
Not at all, it means the proxy can be attacked over the Internet. Just like the VPN can be attacked over the Internet. Once you're past that it's the same story.
Specifically... LetsEncrypt, and most other CAs no longer issue certs for domains that are not legal ccTLDs or gTLDs.
Not so many years ago, Microsoft recommended that organisations used [companyname].local as their internal DNS zone[1], as .local will never be an external zone, so there would be no conflict. Then along came cloud integration and increased need for edge services, and .local no worked well as a solution. Servers needed certs with both the local domain and a new external domain in their certs which became a security nightmare. Then (about a year ago) CAs stopped issuing certs for domains that weren't sub-domains of proper TLDs, which all but killed the concept of these internal non-legal domains.
So, unless you are prepared to roll your own CA, AND instruct your internal (non MS-domain members) users how to manually install an untrusted cert, signing internal sites that do not have a legal domain name, is a complete non-starter.
---
[1] Now of course they recommend a sub-domain of your public domain name (site1.company.com), or a reserved public domain name that you don't use externally (site1-company.com). Which is all well and good, but what about the 100s of legacy kit you've got on the old name... ~sigh~
It is pretty easy to manage your own CA, make a Debian VM, install something like XCA and it is literally click a few buttons to generate and issue certificates and set up certificate authority root certificates.
And why would I trust a company I work at to be able to sign certificates for every single website on the internet? Especially if I need to install that root certificate on a personal device?
If you need such a device to do your job, maybe ask them to provide one so you can keep work off your personal device anyway? I disconnected my phone and so forth from work email and other services some time ago, and I'm not going back!
Why would you need to install it in a personal device? Just add an exception. It's still better than plain HTTP since you can check the fingerprint against your work PC, which already validated the cert.
This fails utterly when you can't control your clients. My student society for example ran into this problem. Students bring their own laptops and installing our root certificate on all of them is infeasible (if they even would allow us to do so). As a consequence, we need to expose critical internal services on the public internet, some of which contain private user data.
Additionally, if you let anyone bring their own device in a diverse semi-public environment like a school, you owe it to the students and faculty alike to provide them with some protection against creative types placing fake wifi access points in busy places, trying to play man-in-the-middle for any credentials and other stuff sent to your local services. HTTPS does that.
Using a proper FQDN for each service only makes everything easier to maintain.
A public domain name costs the price of a coffee (and less than a raspberry pi) and you can get a certificate for free with Let's Encrypt. There is really no reason to resort to a private CA unless you want to MITM your client's connection.
You don't need to expose your server to the public internet to use let's encrypt. I use DNS authorization and it works perfectly.
Even if you could I would highly recommend against doing that, given that this would grant you access to every https connection that isn't hpkp secured.
I actually have all webservices in my home network secured by https, all you need to do is click a cheap vps, install nginx and tinc, and then proxy /.well-known/acme-challenge/ to your internal servers. Either setup domain or ip hijacking so the public IP is routed inside your lan. Done.
If I can do this for me and my cat in my spare time, you can do this for your university.
If you can’t control your clients - maybe use a captive portal style landing page with a link to install the local certificate or something along those lines, it’s also useful to have a wireless network (SSID/VLAN) for BYOD that just has internet access and as such doesn’t need the very and one that has access to internal services that does.
Western Digital solves #2 and #3 for the MyCloud EX4 by somehow issuing real browser-trusted certs to each device for the domain device<mac_address>.wd2go.com using their intermediate CA "Western Digital Technologies Certification Authority" (https://www.censys.io/certificates/eb94f8e2c8d0c8338bb8ba40e...), which is in turn issued by COMODO. Now, not everyone has an intermediate CA locked to their own domain, but maybe that's the issue? X.509 has the ability to restrict CAs to particular domains (e.g. see the "path constraint" on WD's CA in the info link above), so if it was easy to be issued a CA cert for your own domain, couldn't that be a potential solution to this problem?
1) internal company webapps just install company root cert and create properly signed certs under corporate internal CA. Installing the certificate across network is easily automatable on windows, OSX and Linux. The only issue is Firefox as it uses its own trust store. Any senior admin who can't figure it out with the resources available (plenty of information available online) should be replaced days it is not that hard.
2) with regards to raspberry pi, will anyone who can write code can learn to also create their own CA the only difference is probably no automation of adding to the trust store likely however it is only a 2-3 click install in most cases.
You are assuming that you control all client machines. Unfortunately it is not always possible and far from the admin technical decision.
The admin usually can't fire the upper management.
It's possible to purchase certs signed by pre-trusted CAs extremely cheaply ($9/year/name) that can then be used on internal services. This is not a difficult problem to solve.
You can't buy certs for non.public.domain.local. So you must control the CA list at all client machines and use a self signed cert.
The assumptions that there is a solution to the problem do not take in consideration that some times these changes are not possible.
If I were to choose everyone would be using public domains with DNS zone view for public / private environments but Microsoft DNS service don't even support it.
Also why do I get a certificate warning that looks the same for an IP (https://192.168.1.1) which you can not buy certificates? What about 10.x.x.x or even 127.0.0.1? As far as I know you can also no longer purchase a certificate for public IPs.
Just watch how consumer router manufactures are going to work around this by either re-educating their users to ignore the red warnings or only selling cloud managed and locked devices which sucks for everyone.
If you're in a corporate intranet environment, you ought to have an intranet CA, as well as the means to distribute the CA's certificates securely to all deployed machines within the intranet.
I dislike intranet CAs because they allow your company to intercept and play MITM with every other website you visit (except for certificate-pinned websites)...
I'd prefer that Chrome write "insecure" if there's a non-public CA in your chain.
1) Every employee of every company needs to have some level of trust in their company. They trust their company to make payroll, and they trust their company at a reasonably high level to follow local laws and regulations, including reporting threats and violations against their physical safety. That doesn't mean that employees should trust their employers with their deepest darkest secrets and life savings, or that there aren't different types of trust, just that trust is a spectrum, and arguing that you should fully trust every one of the shadowy public CAs pre-installed in your OS and browser, that you know absolutely nothing about and have not personally vetted nor have personal relationships with, but not the intranet CA your employer operates, is rather clearly an irrational assertion.
2) If you decide not to trust your employer's CA, and your employer has provided you with a machine to access intranet sites, then you clearly cannot trust accessing Internet sites for personal reasons on your employer-provided device, not because the CA cannot be trusted but because it's irrational to distrust the CA but also trust the employer-provided device, which may have a keylogger and other tracking software installed.
3) If you decide not to trust your employer's CA and your employer operates a BYOD environment, then you are free to bring a separate device for work purposes, on which you trust your employer's CA but refrain from accessing personal accounts, instead only accessing personal accounts on devices which your employer doesn't know about.
Minor nitpick regarding the "except for certificate-pinned websites" part:
HPKP does not validate pins if they resolve to a user-installed trust anchor like an intranet CA. The RFC [1] leaves behavior undefined (see Section 2.4), and I'm not aware of any popular implementation that would honor the pin in case of a user-installed certificate.
This can be incredibly frustrating if you're trying to protect against MITM attacks; but at the same time, I can follow the browser developers' line of thought that goes "if we were to enforce it, users would just jump ship to the next available browser".
It depends on what they're used for but I agree that many companies seem to spy on their employees this way.
Commonly I only allow internal CAs for specific internal websites and not allow them to MITM just any website. On occasion this meant not being able to use the company's wifi and deal with 4g instead.
Sorry but I have to call BS on that. I always bring my own device and never have bypassed certificate errors. A company will either have certificates for their own apps (commonly running on specific subdomains of their own domain) or have their own internal CA that you can trust on your own device.
Certificate errors on "internal" web apps are just as bad as on the rest of the internet.
If you trust a company's internal CA then aren't you trusting them to issue certificates for every website and not just their own? Isn't that dangerous?
All browsers can tell you what certificate signed the one in use. Unfortunately a recent chrome UI change made this a pain to get to.in chrome, into the other browsers just clicking on the lock in the address bar, it soon becomes obvious if the company is mitm all SSL connections.
Because a normal person will "just click the lock in the address bar" on every single HTTPS website he visits to make sure his company isn't MITMing him, right?
You can get a certificate for a local IP address. If you own foo.com, you can get a cert for local.foo.com from letsencrypt that points to 192.168.1.5. Obviously you can't use HTTP verification, but you can use DNS verification, point _acme-challenge.local.foo.com to a public server and run certsling or another acme client on that server.
> It looks much more secure to serve a good'ol HTTP site with no encryption at all.
Not for long it won't: Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS.
>1) internal corporation services, websites and webapps.
If this is an internal corporation service, why don't you bake your own self-signed root certificate into every computer in your network? Then you can generate as many certificates from your own root as you like, and they'll all magically be valid on corporate computers.
> 1) internal corporation services, websites and webapps.
That one's straightforward. Set up a corporate CA and use it for your internal certificates. Or, operate your corporate services on your real domain name, and use real publicly-trusted certificates - whichever is easier.
Clients need the CA cert in their trust store, not servers. Client get it by the act of enrolling into AD or FreeIPA domain.
On the docker side (or rather on the reverse proxy that provides access to them) you are solving different problem and it does not matter whether the key/cert is provided by your internal CA or third-party one.
The problem is you can't do this for every Docker image you have, particularly for a large organization. It defeats the whole point of having base images if you need "include" Dockerfiles. If Docker had a way to build from multiple base images, that might fix the issue, but I believe they removed that bug/feature a while back.
Have every local machine get something that is internet-routable to a public machine that allows you to get a certificate, then on your corporate DNS, just serve the local machine it's supposed to go to and you can use that cert.
You could use Let's Encrypt for this and have free certs.
> 1) internal corporation services, websites and webapps.
When firefox started throwing warnings on my intranet sites that are accessed via OpenVPN i did this:
1) move all internal sites to valid FQDN
2) push dns settings over openvpn so that clients resolve the names with the internal dns service and dont leak names. Names withing the vpn resolve to internal ip addresses.
3) set up a catch-all website, point the wildcard *.company.name domain to it and mada letsencrypt certs for the internail domains/
4) copy the valid certs to the intranet webserver. Done. Everything working ok.
TLTR: if you have a commercial service or device running in a local network forget HTTPS and service workers, use HTTP and HTML5 appcache.
-- RANT starts here --
It would be lovely when every website and webapp uses HTTPS. But for a significant amount of them it's just not f..... possible without driving users completely insane.
If the HTTPS server doesn't (and never will) have a public domain forget about encryption and security, forget about using service workers. The following examples can't, by the love of god, ever provide HTTPS without completely f..cking up user experience due self signed certificates warnings:
1) internal corporation services, websites and webapps.
2) services that run in a local private network like on a Raspberry Pi.
3) webapps which are served via public HTTPS website, but need to talk via CORS to local unsecured services, like to a Philips hue bridge, or any other IoT device which is in the local network but only provides HTTP. These will enlight the users with a shiny mixed-content warning.
.... JUST use self-signed certificates, they said.
NO.
For normal users the UX of self-signed certificates is just non existent, it's a complete mess! It will scare the sh't out of users and will almost always look like your service is plain malware.
It looks much more secure to serve a good'ol HTTP site with no encryption at all.