Self-signed certificates used to be the solution in this situation. But browser makers have made it significantly harder, if not impossible to use self-signed certificates, by not allowing the user to visit sites that have self-signed certificates.
We need a simple solution for this -- a solution that works even for small businesses that do not have an IT department. (That means installing certificates on each end-user's machine is not a reasonable solution.)
If somebody is on your network snooping on packets with wireshark, they can easily be poisoning ARP or DNS to redirect and man in the middle all your traffic too.
Your complaints come down to certificate management. Spend some time looking at group policy and cert management tools--there are tons of things in this space. Or... hire a IT person to do it, that's how business works. X509 certs are well established and trusted as a way of securing internal networks. They aren't perfect and they have some warts, but deployed properly they are secure.
Set up DNS in whatever way you prefer. Give each service a name.
Create a self-signed root cert, push it to all machines via whatever administrative update tool you use, or just walk around a small office with a flash drive.
Create an intermediate cert. From it, create certs for all services that need one, and push them.
Voilá, you can use https without warnings.
Am I missing something?
The OP was specifically talking about a small business with no IT. I'd say it applies equally to a home.
I'm sure there's some ways to manage all the non-domain-connected computers, phones, tablets, chromebooks and other stuff in my house (which is going to vary by ecosystem) and "push" a root cert out, but I sure don't want to spend the time to learn all that just to secure a web app I have running.
The magic of Lets Encrypt is you run something on the server you're securing, and a few minutes later you're done -- it works with everything.
Any trusted "intermediate" certificate in X.509 is allowed to be a CA, so it can be used to sign certificates for any domain. If an attacker gets the private key for that certificate which has been manually installed on everyone's PC, they can impersonate any website, including external web mail, etc, until someone manually removes the certificate again from all the PCs.
In the past when we've used custom CAs for test environments, I've preferred to just deal with the TLS warnings instead of trusting a non-standard CA on the computers I use.
I think that "simple" is the key word here.
Running your own DNS server isn't necessarily as easy as just using something like NameCheap or another domain name provider with a DNS manager. There probably are somewhat easy DNS servers out there, but in the case of BIND, the configuration format feels obtuse, things break in interesting ways and you'll probably need at least 2 of those servers for more resiliency.
Furthermore, you are assuming that there even is an administrative tool that can push certificates there in the first place, which isn't necessarily true in many environments. And then you also run into the fact that now you need to manage a PKI with all of the certificates, CSRs and now you'll also spend some of your time renewing all of the certificates.
Contrast all of those processes with just having the following in your Caddy web server's configuration (for public sites):
my-public-site.com {
reverse_proxy 10.0.4.5:8080
}
Here's a great explanation that covers a ton: https://smallstep.com/blog/everything-pki/
Congratulations, you've just installed a massive security risk in an organisation that barely understands the word certificate
Make sure to get the mobile devices too.
But yeah, that is the solution. Works great on all platforms.
---
The only time you run into problems with tech is if you try MITM/corporate proxy shenanigans.
The solution would be to allow self signed + pinning.
You click to a new box on your network with a self signed cert. Instead of blocking you basically (yes, you can flag flip, go to advanced etc etc), it says, hey this is self signed cert, do you want to pin it? You say yes. It pins that cert to that internal IP.
Now you've got encryption.
Let's say in a rather far out case someone spoofs internal resolution. You are generally already owned at that point, but if they redirect IP X to a new cert, browser could have a popup saying - heads up, the cert for this IP now mismatches. Be very careful and do the current basic block/lockout approach.
Seems trivial. Why wouldn't they?
> You are generally already owned at that point
Well, you might be, since your network is relying on self signed certificates with no PKI.
> heads up, the cert for this IP now mismatches.
Good thing everyone is already trained to click through certificate warnings.
Or you could just do PKI properly and avoid the entire issue, or not have an intranet and avoid the entire issue.
Also you might just not want a domain like "my-top-secret-project.amazon.com" to actually exist and resolve to an IP (even if an intranet IP) in public DNS, but you might still want an easy-to-remember intranet hostname that employees can use.
So if you do split-horizon, don't put an A/AAAA-entry into the internet-facing side, instead use the ACME DNS challenge as described in the sibling comments.
I have a NAS, HomeAssistant, some random local-only IoT-type stuff, Plex, Pi-hole, and a handful of several other web applications running. Running my own PKI and having to manually distribute root cert to my non-domain PC let alone even think about how to install root certs on the various Android/iOS stuff I have: no thanks.
I can think of several scenarios where a small business (with no IT) would have local servers but no dedicated IT (and where a full PKI infrastructure is a big burden): for example poor internet connectivity, or very high bandwidth costs.
e.g.
*.internal.some.tld
e.g. one wildcard SAN cert with names like
*.sfo1.dev.some.tld
*.uk1.dev.some.tld
*.dev.some.tldFWIW I use letsencrypt for this, for free. The only downside is having a central set of HTTPS routers (e.g. nginx) that hold the wildcart certs to terminate TLS. If you spread your hosts across sites it can be annoying.
- use split DNS, where hostnames like "hr.example.com" resolve on your internal network but not externally
- use split DNS for a subdomain, so everything under "corp.example.com" points at your internal network and you use https://hr.corp.example.com (which might be easier to manage - you just reserve "corp.example.com" on your public DNS)
- buy a completely separate domain name like examplecorp or something
- go full beyondcorp and make https://login.corp.google.com available on the public internet, and rely on SSL + strong authentication (like two-factor) instead of people being on the internal network (as a bonus, this approach to IT makes things more straightforward if, hypothetically, there was a global pandemic forcing people to not be in the office for over a year, idk, that might not be a realistic business risk)
Now that your services are running on a DNS name you control, you can get real, valid SSL certificates for them. Assuming you didn't go with that last option, you can
- use Let's Encrypt DNS challenges, by temporarily adding TXT records mapping to your internal names
- use Let's Encrypt HTTPS challenges, by temporarily (or permanently) running a web server in external DNS that corresponds to your internal names
- pay for a wildcard certificate from a vendor, which costs under $100/year
The one risk here is that names of all real SSL certificates are logged publicly (for Certificate Transparency, to help track mis-issuance). So if you happen to enjoy running web servers named things like secret-plan-to-acquire-foobarcorp-on-july-30.corp.example.com, then you want to go with the wildcard option. If the names you have are things like "hr" or "wiki", you'll be fine with the Let's Encrypt option.
This approach requires no installing of certificates on end-user machines and no asking users to click through any dialogs and no risk of people on the internal network spoofing websites and doing a man-in-the-middle attack (which is only ever so slightly harder than using Wireshark).
The problem is that identities can be faked easily if the application allows anybody to spin up a new instance/identity with few commands. The standard solution to this is centrally managed certificates (certificate authority). A user should always challenge the identity of the remote party against an agreed upon third party to verify trust before any encryption occurs. This is more challenging.
Sorry, not a security expert. What is the point of encrypting if you're not also sure you're sending the encrypted data to the right entity?
However,
> we need to encrypt the information to prevent casual snooping using tools such as Wireshark.
Given this goal, signing is necessary. If you're not signing the encryption, you can use a tool like Wireshark combined with Bettercap to man-in-the-middle the encrypted session, and there's no point.
I don't know about now, but in the .xls days that wasn't encryption. You could bypass it by rewriting the file's header.
I'm sure you'd need various switches for edge cases, custom keys etc, but... imagine. Quick and dirty network apps? Half the security battle is done. Crusty endpoint security solutions downgrading your encryption? No need. Malware sending an encrypted traffic? Stands out like a sore thumb, because it's the only thing not sending cleartext to the socket.
Yes, if your OS is compromised, your processes encryption is. Guess what - that's already the case.
That comes with other perils which is why the browser behaviour these days is like this. In browsers you can still trust the certificate by adding a manual exception if you want to persist with this route.
Better would be to create an in-house CA (easyca maybe) so that the CA cert can be added rather than lots of individual ones.
LetsEncrypt works when you are able to prove you are the owner of the object in the CN. They have a few auth plugins that try and verify this ownership in an automated way but none of them work (without some workarounds) for internal hosts e.g. you're using private IP blocks and potentially made-up DNS zones on your intranet you don't necessarily own them. e.g. you want a certificate for 192.168.1.1 with the domain foo.localdomain.
This is one of the services provided by Microsoft Windows servers, or you can roll your own. It’s not hard and scales whatever way you want.
Expecting browser vendors to weaken security to avoid this tiny amount of work is backwards and will never happen.
I wish it was possible to add a certificate authority and restrict its usage to non-Internet servers (e.g. *.company.example).
(This is theoretically possible if the CA bakes that in, though not all TLS stacks support that. It isn't possible via local browser configuration.)
In my company (I'm the MD), salary info is pretty open and I believe income is proudly and publicly published in Sweden for all individuals but I do understand your reticence.
Do you actually need encryption or even a computer to get the message across? What about whispering?
If you want to ensure confidentiality then you need to agree on your standards with your partners. You have no choice in this matter. Rapidly you are in a technical debate on standards. Apart from the channel, are you sure you are safely getting the data in and out? Think about things like side channel attacks eg someone listening to your keyboard. Get the tin foil out!
I'll give you this for free, right now: TLS is a very decent way of creating a tunnel between you and your partner. So is IPSEC and probably WireGuard, also a SSL tunnel.
There is no such thing as a simple way to do confidential comms, just like there is no simple way to build a suspension bridge. I studied Civil Engineering at Plymouth Polytechnic in Devon and the building industry collapsed in the UK as I graduated in 1991. Building a bridge is quite complicated but for the end user it is a piece of piss to drive their car across it.
You say that self-signed is broken but all browsers and modern OS's allow you to import CA certs. You can generate a CA cert with a one liner with openssl and if you are careful you can be pretty sure things are secure. I trust my own CAs far more than anyone else's.
You cannot have simple solutions for confidential comms. If there was such a thing then James Bond would use it too, and he doesn't.
As an added bonus, it keeps working regardless of your location
There isn't really something like "casual sniffing". It has to be done deliberately and with full intent. Not to mention with the right timing or long duration and non trivial technical knowledge. It isn't really possible to protect against such an adversary (for example, even with self signed certs, he can mitm the connection and resign it himself), and therefor imo, its better not give a false sense of security.
This covers both passive AND active attackers with access to your network.
I don't get it. Why even have an intranet then? Use Google Drive to share files, or Dropbox, or whatever. Why do you have an intranet at all if you don't want to manage an intranet?
Casual snooping with wireshark isn't typically a problem on an intranet either. The difficulty of both attacks are a somewhat similar level, it really doesn't make sense to care about one but not the other imo.
What business are browser makers in. How do they make money. Why are browser makers the ones deciding what users should and should not be allowed to do.
Which goal is more important to the browser maker:
1. protect the user against the possibility of the wrong recipient possibly receiving an encrypted message (which she cannot decrypt)
2. require that the user must use the browser maker's software to "verify" the server (via a certificate)^1
The underlying assumption with #2 is that the user has no possible means of verifying a certificate other than the browser maker's software. Like on a corporate intranet, on a home LAN, I use another program, a proxy bound to the loopback, to verify certificates.
Chrome throws a warning "Your connection is not private. Attackers might be trying to steal your information from ____". That's a guess and it's wrong. The connection is from the browser to the loopback. The server certificate has already been verified by the proxy. I do not expect Chrome to figure that out, the warning is fine (the keylogger is creepy), but I do expect an option in the browser to turn off certificate verification. This is not an uncommon option in other TLS-enabled software.
It is very difficult for me to believe that Google's self-interest does not factor into these design decisions. It is always possible to spin the explanation for any design decision at a "tech" company to be for the benefit of users. That does not necessarily mean it is the whole truth. It may not be full disclosure. We have no way of knowing. Facebook and Twitter collected phone numbers under the guise they needed them for "authentication" but it was later shown they were using them for advertising. Then 533 million Facebook user accounts many which included phone numbers became available to the public, not just "friends".
https://www.wired.com/story/twitter-two-factor-advertising/
1. Consider that we just witnessed the browser maker with the most users, who also has the majority of search engine users, video hosting users, webmail users, online ad services users, etc., etc., launch an experiment and proposal to start tracking users through its browser instead of via cookies. Ideally, it would be best for users if this company, which effectively controls much of the world's web traffic through its search engine, did NOT also make a web browser.
Google's self-interest does factor into these decisions, though: Google's interest is in making more people use and trust the internet. The more people who feel comfortable buying things online, for instance, the more ads they'll click from online sellers. The more businesses who feel comfortable selling things online, the more ads they'll buy, and thus the more profit Google will get.
So it's important to Google that the internet remains perceived as a secure and trustworthy place to do business. If users are in the business of making judgment calls about certificates, some fraction of the time they'll be wrong - and they aren't going to say "Oh, I made a mistake," they're going to say (correctly, even) "Oh, doing secure transactions on the web is too difficult."
There are a whole lot of ways in which Google's interests are badly biased against end users, and as you mention FLOC is a perfect example. Wanting the web to be secure is not actually one of them, though.
Because they just keep making life more difficult for websites that don't need SSL.
So now in addition to seeing a scary icon on the url bar with a scary message, my users are going to have to click past an interstitial banner just so they can visit a website and read silly travel stories. Chromium will try their best to convince them to leave, lest some nefarious agency on their home wifi substitute alternate silly travel stories that somehow cause them harm. In the 20 years the site has been live, I skeptical that this has happened often enough that we need to get Google involved.
It's frustrating.
For me, it comes down to two things:
1. Privacy. When I'm on non-private networks, its nice to have assurance that other people aren't able to get the specific contents of what I'm viewing.
2. ISP bad behavior. A number of ISPs have been doing things like injecting ads or other trackers into plain-HTTP sites. https://www.infoworld.com/article/2925839/code-injection-new...
As a small side bonus, it also reduces navigation latency by several RTTs, as there is no longer the need for a connection to port 80 HTTP that only always gets redirected to HTTPS.
As well as preloading your corporate web site, HSTS preloading can be done hierarchically. For example all of .google, .dev, and .foo is HSTS preloaded, sites in those TLDs don't have plaintext HTTP in modern browsers. Perhaps some day the US government will preload .gov
(Plaintext HTTP still works for these names, a tool like curl doesn't obey HSTS -- it just can't be done in your web browser because it'll get upgraded to an HTTPS request)
Certificates are free now and not necessarily any more difficult to install and maintain than any of the other software you need to run even a basic website. It's something relatively simple I can do to ensure the integrity of the content I want people to look at, so why not?
Google wants to control the entire Internet, and that means centralising power. HTTPS requires certificates issued by a small list of CAs, and they can revoke them too.
Combine that with Google's efforts and those of others of locking down the whole stack (all in the name of "security", of course), and you can see just how much power to censor "inconvenient" information they've accumulated.
People like to cheer on the companies fighting the "bad guys", not giving a second thought to letting them have more power --- nor considering that this power may one day even be used against them. Of course, this power will initially only be used for fighting malware and phishing. Then they'll start revoking sites for "misinformation"...
There's a good reason why SciHub and LibGen are accessible via plaintext HTTP.
"Those who give up freedom for security deserve neither", as the classic saying goes.
The push for HTTPS everywhere started with HR4681[1] both of which were reactions to Snowden revelations.
> Beyond the silly "bad people might tamper with the cat picture you're shown" one that is always given?
Someone who is able to tamper with the cat picture you are seeing can also inject arbitrary code into your computer, so there is that.
Also, thanks to the push for HTTPS everywhere, a large volume of traffic now goes through CloudFlare enabling them to do that on behalf of state actors etc (I am not claiming they do it, but it is kind of ironic that the least friction thing for me to enable HTTPS on a whole bunch of sites was to put a MITM ;-)
Totally love CloudFlare BTW. The free level covers what I need. Still, it is ironic.
[1]: https://www.nu42.com/2014/12/https-everywhere-and-hr4681.htm...
Someone can just inject arbitrary code into your computer using a site with an SSL cert. It's very easy to get a free one nowadays, judging from the other threads. Why are middle-men so important to protect against? The site owners are the usual source of attacks.
I think it is just that Google wants exclusive access to your data. With http, your ISP can also understand your browsing habits. Then they devalue Google's ad profile that they have painstakingly created. So Google is pushing for https, which would exclude ISPs and other intermediaries from profiling you. Note that Google's ability to spy on you is un-curtailed since you are using Chrome and even signing in with your google account.
(the less cynical interpretation is that all the other non-ad content on that website is also valuable and shouldn't be modified in transit)
I had the idea that browsers were showing a grayed-down padlock for standard HTTPS certificates (ie, "connection is encrypted") vs a full-blown green icon with the company name next to it for the HTTPS certificates that also validate identity (DV? EV? I don't recall the meanings and acronyms).
I guess that's where we should go now: make HTTPs the default (thus showing a standard icon that doesn't call for any attention), a big red ugly icon alerting non-encrypted connections, and a green one with identity attached meaning you can indeed trust this particular site to really be your bank.
[1] https://chromium.googlesource.com/chromium/src/+/HEAD/docs/s...
[2] https://typewritten-archive.cynthia.re/writer/ev-phishing/
[3] https://arstechnica.com/information-technology/2017/12/nope-...
For example, suppose you go to https://som.example/ which is the web site for "Somex Ample" products. You don't trust "mere" DV certificates for som.example, which you believe may be purchased by bad guys, but you're comfortable because "Somex" has purchased an expensive EV certificate for "Somex Ample" of Springfield.
You fill out a form on the secure web page, and hit submit. But, unlike you, your web browser intentionally has no idea who "Somex Ample" are and no interest in whether they spent a lot of money on their certificate. When the server it reaches has a boring DV certificate for som.example that's fine, the browser compares this name to the name in the HTTPS URL and it matches exactly so that's fine. The browser sends your form data to this server, gets back a 30x redirect and then (maybe after some more bounces) gets a fresh web page to show you. This page might come with one of those shiny EV certificates you like, or it might not. Either way, that form data you were careful to only fill out on the "safe" EV page, went to a server without an EV certificate.
So, getting rid of the separate UI indication for EV was largely reflecting a reality that already existed. The DNS name is correct because the browser always verifies that matches at every step, but if you're relying on something else it's on you.
The other way was an issue as well. We could only get an EV cert for our real/primary company name, but not the subordinate name we had registered for our B2C business. That would mean that our customers would see the correct URL, but the EV would show the name of a company they didn't know.
Put another way users think "This site is secure" not "I am securely connected to the site I think I am".
Also I would include government websites to this list.
The sites on it are not set apart visually for the same reasons that browser vendors stopped distinguishing EV certificates.
This was noticed when a Google engineer went on holiday, and stayed at a hotel with dodgy Wi-Fi that copypasted ad scripts into anything that looked like jQuery. Said engineer realized that his laptop was still getting hit with the hotel's ads for months afterwards, because it had managed to poison one of those "JavaScript CDNs" that a lot of other sites use.
This is, of course, an attack - a hotel that can get an ad script onto arbitrary sites by rewriting one unencrypted request can also add a script that, say, siphons information off of any other site it got included into.
There are a whole bunch of says that they can do that. The obvious way is that a lot of my blog is about programming, and so I have code on my blog people can copy/paste. If a MITM can modify that (perhaps by injecting something with font-size-zero), that directly harms my readers, and selfishly, that reflects poorly on me - it makes it look like I'm trying to harm my readers.
I also have prose blog posts where I express advice or opinions. If I write about, say, security advice, and that advice has been modified to be bad, that also harms my readers and reflects poorly on me. Why would someone do that? I don't know, there are lots of trolls on the internet. More interestingly, I also write about my religious beliefs. If someone modifies a post to make me look like I'm one of the most egregiously bigoted people of my religion, that would also be harmful to my readers and reflect poorly on me, and the casual reader might not notice that the post is out of character, and there are a lot of people on the internet who are angry at my religion.
Also, even if I didn't have any such information, a MITM could add a cryptominer or something to my blog - something that accesses no private information but still consumes my visitors' CPU and battery - would harm my readers and reflect poorly on me.
- A man-in-the-middle may replace your innocent content with something unpleasant. This is both bad for the viewer, and harms your reputation (even if it wasn't your fault).
Not even touching on the fundamentally flawed trust model behind https, here's a sample of recent stories about expired certificates:
https://news.ycombinator.com/item?id=25132182
https://news.ycombinator.com/item?id=24237400
https://news.ycombinator.com/item?id=24187920
https://news.ycombinator.com/item?id=22227266
2. Don't. Your web host should be doing it for you.
2. You sure place a lot of trust into third parties.
Current status: https://www.chromestatus.com/feature/6196703843581952
I used https://datatracker.ietf.org/doc/html/rfc2289 for login which is simpler and uses less energy than public/private key encryption and quantum safe out of the box.
Google of course has a root cert and is making sure less people can make web sites by building more protocol extensions that the average joe can afford to keep up with.
I expect to be severly down voted but it's ok, I'm used to it by this point. Truth is always downvoted by vested interests to higher degree than average joes are willing to upvote it.
Your comment would have been fine without the last bit, albeit light on justification for your position to make the arguments.
Attempting to guilt-trip people that you want to reach is not an effective strategy, and potentially getting downvoted does not validate your position.
Certificates are a bamboozle of power (who/why/how some entity gets a root cert) and the waste they involve is simply not worth it.
---
- HTTP/2 has head of line issues = it's not better than HTTP/1.1.
- HTTP/3 has adoption issues and ossification of a protocol is THE feature.
- WebSockets are a similar ordeal.
I use HTTP/1.1 Comet Stream and it works very well, it's simpler and can scale "joint parallel" on multiple cores.
---
I'm a bit weary that after 5 years of telling HN to force comment upon downvote nothing has happened.
Your downvote needs to be official otherwise it's unclear who thinks what.
Eventually the HN database will leak and then it will be pretty clear who has downvoted what, so it's only a matter of time anyway.
We generally live in a RFC1918 n stuff world which describes "internal" and "external". IPv6 focusses the boundary between you and me in a different way.
Why should my browser decide what I do on my own home network?
Why should a mere tool pontificate about stuff that I know more about than the kids who developed it? Fine, I should probably develop my own browser in ASM but I don't speak nonsense. I sort of know what a processor register is but it would probably bully me.
I am increasingly seeing top down decisions from monstrously huge corporations "for my own good" and I am increasingly getting worried. I rant at my elected government officials because that is what they are for (I don't really) but commercial corps are increasingly insinuating themselves into important discussions and their moral stance is undecipherable.
It's particularly telling when the most downvoted comments contain the most truth.
The decision might not be for your own good specifically, but ultimately the defaults affect 1B+ people. And the huge majority of those people do not understand many of the words that are in you post. You are an outlier and that will mean that product decisions will often not be focused at you.
Never really thought about that, but I guess it's pretty obvious. I can totally see my folks downloading/buying god-knows-what from a site because they see that lock icon.
This last change is obvious and needed but was probably left as a last step because people have been taught to look for it at some point. Glad to see it gone, even just ‘cause Safari puts it in the middle of the URL bar and I keep clicking on it by mistake. Hopefully they’ll drop it to by 2024
The type of server software developer who years ago searched Stack Overflow for how to "fix" the problem of certificate errors, now just uses the plaintext HTTP calls where possible, and thus avoids needing to "fix" the problem by not having any security.
And there's a bunch of completely automated stuff that genuinely does need plaintext HTTP on purpose. OCSP requests, for example, are plaintext HTTP. When you realise what they're for this is obvious, if I need an OCSP check to do HTTPS, but I need HTTPS to do an OCSP check, then I have infinite recursion.
Edit: Oh, here we go: https://chromiumdash.appspot.com/schedule
This is for Chromium and not Chrome, though:
...
Feature Freeze Thu, Jul 29, 2021
...
Stable Cut * Tue, Sep 14, 2021
Stable Release Tue, Sep 21, 2021
...
python -m http.server → you have a web server that you can use for ad-hoc needs.
Coding TLS into a web framework is hard. Ah, I should use a proxy? So installing a TLS on a proxy is hard. Ah, I should use caddy with LE? Sure (I use it for years), now how do I do that for 10.2.3.10?
I understand why HTTPS is useful (to encrypt your traffic, certainly not "to know you are on the right server"), but it is a failure form the start - usability-wise.