12 ms·

What is sorely lacking today is an encryption solution for the intranet. When you are transferring confidential data (such as salary info) over the network in i

What is sorely lacking today is an encryption solution for the intranet. When you are transferring confidential data (such as salary info) over the network in intranet situation we need to encrypt the information to prevent casual snooping using tools such as Wireshark. We don't need to verify the identity of the server because that's typically not a problem on the intranet. 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.)

ryandrake 5y ago
> We don't need to verify the identity of the server because that's typically not a problem on the intranet. 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?
- gruez 5y ago
  It helps against passive observers. This might not be very important over wired, but on WPA-PSK setups, knowing the network password allows you to eavesdrop on communications by any of the computers.
  - staticassertion 5y ago
    Why would an attacker in your intranet who's looking at your network traffic be passive? When people talk about passive attackers they're talking about the NSA/ your ISP, not someone who's hands-on-keyboard sniffing traffic. There's virtually no reason to do encryption without authentication in your intranet.
- spijdar 5y ago
  Encryption without signing is arguably more useful than not encrypting at all, although there's an argument that non-signed encryption gives a false sense of security that encourages bad practice. 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.
qbasic_forever 5y ago
> we need to encrypt the information to prevent casual snooping using tools such as Wireshark. We don't need to verify the identity of the server because that's typically not a problem on the intranet. 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.
- AnIdiotOnTheNet 5y ago
  I think that's exactly what parent is getting at though: it's a pain to manage certs for your own internal stuff and even worse for third party stuff in your environment. Rather than say "well, just hire more IT people" we should really come up with a simpler and easier solution if we want to actually see adoption.
  - qbasic_forever 5y ago
    Like I said, spend some time to investigate the space. There are lots of tools to ease the burden of running your own internal CA. For example: https://smallstep.com/certificates/ https://smallstep.com/certificates/ But really you probably want to use your OS' group machine management systems, like AD on Windows, to handle this with lots of machines.
    - deleted 5y ago
      [deleted]
    - hultner 5y ago
      That looks really nice, bookmarked for later. In general I agree with the previous commenter, Let’s Encrypt made TLS easy on the public net, but for small teams/organizations TLS in local networks with local host names is still a pain.
tinus_hn 5y ago
The simple solution is a local certificate authority which is added to the users’ browsers. It can deliver certificates automatically or manually. 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.
- JoshTriplett 5y ago
  > The simple solution is a local certificate authority which is added to the users’ browsers. It can deliver certificates automatically or manually. 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.)
  - tinus_hn 5y ago
    If you are the authority yourself, you can just commit to not giving out certificates outside a specific domain.
    - JoshTriplett 5y ago
      If you're the authority you can restrict the certificate authority to a given set of domains, but that's if you're the authority. I'd like browsers to give users control over that, to trust a CA in a limited fashion for only a subset of domains without trusting it to MITM the web.
zaik 5y ago
You can get a Let's Encrypt certificate for an internal subdomain: https://security.stackexchange.com/questions/103524/lets-encrypt-for-intranet-websites#121187 https://security.stackexchange.com/questions/103524/lets-enc...
- Hamuko 5y ago
  Yeah, this. I have a dedicated domain for my internal network (it's just 9€ per year so might as well) and just use a LE certificate with the DNS verification, so no need to have any external web traffic.
- dheera 5y ago
  One of the problems of that is now you need to list all your internal IP addresses in a public DNS server. It shouldn't theoretically be an issue but it might be stuff you don't want to just lay out there in public view just in case. 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.
  - Hamuko 5y ago
    >One of the problems of that is now you need to list all your internal IP addresses in a public DNS server. You don't actually. You can just have them resolve in your local DNS server alone. My current setup is that the public DNS records for my internal network just return CNAME records, so "mail.myserver.com" has a CNAME record to "mail.myserver.internal" and my private DNS server has an A record for "mail.myserver.internal".
    - jbverschoor 5y ago
      Still, you're exposing your infrastructure. It's kind of nice to know that there is a mongo1.profiles.company.com somewhere.
      - Hamuko 5y ago
metafunctor 5y ago
If you have servers in your intranet, but don’t have enough expertise to install a CA server and a CA certificate on end-users’ machines, maybe move to a cloud based solution instead of hosting your own.
- qbasic_forever 5y ago
  This is the hard truth. With a business and internal data, _especially_ customer data, you need to think of the liability if any of that data leaks or is accessed inappropriately. It will not look good in a lawsuit if a judges asks why data was so easily stolen and your response is that you didn't know some exploit was possible and didn't want to pay for experts to secure access to it. Managing certs, securing an internal network, etc. are just part of an ever evolving and changing security and threat landscape. You need to dedicate resources like time and money to constantly stay on top of it.
  - dvdkon 5y ago
    Many vendors of internal tools don't have cloud offerings and even if they did, I wouldn't trust it considering their current security record. It would be a good CYA strategy, but that's about it.
  - iso1631 5y ago
    Yes, it's far more sensible to use something from a company that really understands security like Solarwinds rather than run your own nagios install. /s
- dec0dedab0de 5y ago
  Self signed certs on an internal network are more secure than CA signed cert on a cloud.
  - magicalist 5y ago
    > Self signed certs on an internal network are more secure than CA signed cert on a cloud. Not if your threat model is someone who already has access to the local network (which has no one managing it) snooping on traffic.
austincheney 5y ago
I thought about that, but have not fulfilled it. I wrote an application designed to be private and one-to-one. This particular application allows sending of texts, and file system segments directly from the browser. Encryption would just be a matter of one time public key exchange. I can do that just using the Node crypto API. No central authority needed... yet. 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.
Telemakhos 5y ago
It sounds like you just want to encrypt individual files. Most major office software suites like MS Office will have an encryption feature so that you can password-protect spreadsheets. The other easy solution requires certs, but not the kind you're thinking of: if you want to protect individual files and know who should have access, you could encrypt them using openssl (maybe write an app to wrap it up nicely) and S/MIME certs that could also encrypt your internal email. If you know what you're doing, you can provision out those keys and keep a copy in escrow for data retention policy and accountability.
- whoisburbansky 5y ago
  This works if you're emailing random files around for all information transfer, but it feels like GP is talking about the case where such information is accessed through intranet websites?
- wizzwizz4 5y ago
  > Most major office software suites like MS Office will have an encryption feature so that you can password-protect spreadsheets. 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.
slownews45 5y ago
There is a good one, but everyone is pushing the craptastic / megasize management solutions - so I don't think there is anyone out there yet for the 15 machine non AD (or light AD) domain type setups with third party stuff. 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.
- vbernat 5y ago
  That's already what Firefox does. Despite not saying it clearly, if you accept a self-signed certificate, it will be used as long as it does not change.
- deleted 5y ago
  [deleted]
- staticassertion 5y ago
  > Let's say in a rather far out case someone spoofs internal resolution. 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.
  - altantiprocrast 5y ago
    > Good thing everyone is already trained to click through certificate warnings. With a proper UI there would be different messages when a cert mismatches compared to when a new cert is seen or the previous cert was about to expire. (Quite like Gemini browsers)
irrational 5y ago
I work for a Fortune 500 company with a huge IT department, and even we have trouble with this. Some intranet sites will work on certain browsers but not others because of certificate issues. So, it is clearly a problem for both large and small companies.
thayne 5y ago
Not to mention that if you set up an internal CA, it is a huge pain to add the CA to browsers, since most browsers don't use the system trusted CAs.
- devrand 5y ago
  Though most (all?) do support enterprise policies via GPO that would cover the vast majority of enterprise use cases.
  - thayne 5y ago
    which has to be managed separately for every combination of OS and browser. If all employees use chrome on windows, that's not too bad, but if you have employees using a variety of different setups, it it is more complicated to set up.
- bawolff 5y ago
  Which ones other than firefox don't? (And firefox has a config option)
yodelshady 5y ago
Yup, but I'd go even simpler. Imagine An OS-level switch to put arbitrary network traffic over TLS. 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.
- amarshall 5y ago
  Direct p2p over Wireguard or similar is a solution here.
- gsich 5y ago
  I imagined it and it looks like SSH.
- rolisz 5y ago
  That's what Tailscale does. I use it to encrypt communication between my devices (both on home network and when I'm away) and it works like a charm.
staticassertion 5y ago
> 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.) 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?
- sam_lowry_ 5y ago
  Because Active Directory.
  - staticassertion 5y ago
    Could you elaborate? There's Azure AD, or you could do yourself a massive favor and not use AD at all. And like... why would you want AD and an intranet but not someone to manage it at all? Recipe for disaster. The simplest solution to this problem, by far, is to just avoid it entirely. Don't have an intranet. Don't manage AD. Just don't do those things. Pick an identity provider, pick a file sharing service, pick a video chat service, and set up SSO for them. It's 0 maintenance, far safer, and far easier to use.
  - geofft 5y ago
    AD has a built-in certificate authority, and installs the root CA on domain-joined machines....
LinuxBender 5y ago
They way I have dealt with this in the past was to buy a wildcard subdomain cert and only use that subdomain internally. The downside is that you have to delegate that subdomain from your public DNS to your internal DNS or do split horizon/split view. Both have caveats and require some thinking ahead. This is not a free solution, but I would consider it affordable for any small business. It is certainly much less complicated than setting up internal CA's and avoids the opex expenses of managing an internal CA and greatly simplifies managing certificate expiration. e.g. *.internal.some.tld You may even be able to find a CA that will sell you a SAN cert with multiple wildcard subdomains listed. They lose money doing this and most will require you to buy a different wildcard cert for each sub-domain. There are no technical or CAB limits to wildcard subdomain SAN certs, only business policy per CA. If CAB have added any recent restrictions that I am unaware of, it would be for purely monetary reasons as the SAN RFC's have no restrictions on the number of names last I checked. e.g. one wildcard SAN cert with names like *.sfo1.dev.some.tld *.uk1.dev.some.tld *.dev.some.tld
- xyzzy_plugh 5y ago
  > This is not a free solution FWIW 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.
nijave 5y ago
You can use a VPN e.g. overlay network As an added bonus, it keeps working regardless of your location
air7 5y ago
I think that if you are worried about someone sniffing salary info in your org, there are deeper problems to sort out. 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.
nine_k 5y ago
How come there is none? 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?
- beebmam 5y ago
  This is exactly right. PKI is for everyone. It's really quite simple once you learn how it works! Here's a great explanation that covers a ton: https://smallstep.com/blog/everything-pki/ https://smallstep.com/blog/everything-pki/
  - schoen 5y ago
    One SmallStep for a LAN, one giant leap for LANkind?
- paulddraper 5y ago
  > flash drive 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.
  - nine_k 5y ago
    If you have a really small office with 10 desktops / laptops, you may consider that deploying puppet / chef / saltstack / whatever is overkill. Walking around with a flash drive is just faster.
    - chousuke 5y ago
      But it's not more consistent if you need to change something. Having declarative desired state configuration is useful for any environment, even when n = 1. I would definitely deploy a configuration management solution for 10 hosts; it takes a couple hours of work to do properly and you can do it without a server initially (though a central server provides other benefits)
1vuio0pswjnm7 5y ago
"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." 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/ 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.
- geofft 5y ago
  I'm not sure I follow your argument, because, first, no major browser maker is in the business of selling their web browser software, and second, if you're using the browser maker's software to verify the server, you already have access to it. So even if they were selling it, you've already paid for it. 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.
geofft 5y ago
Name your internal services after some valid DNS domain that you own. Options include - 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 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 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).
deleted 5y ago
[deleted]
isatty 5y ago
My "internal" (local hosts + server nodes) are on its own VPN with wireguard. Even with a VPN, I've letsencrypt provided certs on some of em because it's nice, but it's not strictly necessary. People being able to know that I've things running in my own /8 is not a major security problem.
gerdesj 5y ago
"What we need is ... blah blah blah ... technology" is rarely what you want when you start on this path. 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.
bawolff 5y ago
> We don't need to verify the identity of the server because that's typically not a problem on the 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.
deleted 5y ago
[deleted]
beermonster 5y ago
> 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 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.
WhyNotHugo 5y ago
Make your own organisational CA, and use that. This covers both passive AND active attackers with access to your network.

ryandrake 5y ago

> We don't need to verify the identity of the server because that's typically not a problem on the intranet. 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?

gruez 5y ago
It helps against passive observers. This might not be very important over wired, but on WPA-PSK setups, knowing the network password allows you to eavesdrop on communications by any of the computers.
- staticassertion 5y ago
  Why would an attacker in your intranet who's looking at your network traffic be passive? When people talk about passive attackers they're talking about the NSA/ your ISP, not someone who's hands-on-keyboard sniffing traffic. There's virtually no reason to do encryption without authentication in your intranet.
spijdar 5y ago
Encryption without signing is arguably more useful than not encrypting at all, although there's an argument that non-signed encryption gives a false sense of security that encourages bad practice. 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.

qbasic_forever 5y ago

> we need to encrypt the information to prevent casual snooping using tools such as Wireshark. We don't need to verify the identity of the server because that's typically not a problem on the intranet. 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.

AnIdiotOnTheNet 5y ago
I think that's exactly what parent is getting at though: it's a pain to manage certs for your own internal stuff and even worse for third party stuff in your environment. Rather than say "well, just hire more IT people" we should really come up with a simpler and easier solution if we want to actually see adoption.
- qbasic_forever 5y ago
  Like I said, spend some time to investigate the space. There are lots of tools to ease the burden of running your own internal CA. For example: https://smallstep.com/certificates/ https://smallstep.com/certificates/ But really you probably want to use your OS' group machine management systems, like AD on Windows, to handle this with lots of machines.
  - deleted 5y ago
    [deleted]
  - hultner 5y ago
    That looks really nice, bookmarked for later. In general I agree with the previous commenter, Let’s Encrypt made TLS easy on the public net, but for small teams/organizations TLS in local networks with local host names is still a pain.

tinus_hn 5y ago

The simple solution is a local certificate authority which is added to the users’ browsers. It can deliver certificates automatically or manually. 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.

JoshTriplett 5y ago
> The simple solution is a local certificate authority which is added to the users’ browsers. It can deliver certificates automatically or manually. 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.)
- tinus_hn 5y ago
  If you are the authority yourself, you can just commit to not giving out certificates outside a specific domain.
  - JoshTriplett 5y ago
    If you're the authority you can restrict the certificate authority to a given set of domains, but that's if you're the authority. I'd like browsers to give users control over that, to trust a CA in a limited fashion for only a subset of domains without trusting it to MITM the web.

zaik 5y ago

You can get a Let's Encrypt certificate for an internal subdomain: https://security.stackexchange.com/questions/103524/lets-encrypt-for-intranet-websites#121187 https://security.stackexchange.com/questions/103524/lets-enc...

Hamuko 5y ago
Yeah, this. I have a dedicated domain for my internal network (it's just 9€ per year so might as well) and just use a LE certificate with the DNS verification, so no need to have any external web traffic.
dheera 5y ago
One of the problems of that is now you need to list all your internal IP addresses in a public DNS server. It shouldn't theoretically be an issue but it might be stuff you don't want to just lay out there in public view just in case. 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.
- Hamuko 5y ago
  >One of the problems of that is now you need to list all your internal IP addresses in a public DNS server. You don't actually. You can just have them resolve in your local DNS server alone. My current setup is that the public DNS records for my internal network just return CNAME records, so "mail.myserver.com" has a CNAME record to "mail.myserver.internal" and my private DNS server has an A record for "mail.myserver.internal".
  - jbverschoor 5y ago
    Still, you're exposing your infrastructure. It's kind of nice to know that there is a mongo1.profiles.company.com somewhere.
    - Hamuko 5y ago

metafunctor 5y ago

If you have servers in your intranet, but don’t have enough expertise to install a CA server and a CA certificate on end-users’ machines, maybe move to a cloud based solution instead of hosting your own.

qbasic_forever 5y ago
This is the hard truth. With a business and internal data, _especially_ customer data, you need to think of the liability if any of that data leaks or is accessed inappropriately. It will not look good in a lawsuit if a judges asks why data was so easily stolen and your response is that you didn't know some exploit was possible and didn't want to pay for experts to secure access to it. Managing certs, securing an internal network, etc. are just part of an ever evolving and changing security and threat landscape. You need to dedicate resources like time and money to constantly stay on top of it.
- dvdkon 5y ago
  Many vendors of internal tools don't have cloud offerings and even if they did, I wouldn't trust it considering their current security record. It would be a good CYA strategy, but that's about it.
- iso1631 5y ago
  Yes, it's far more sensible to use something from a company that really understands security like Solarwinds rather than run your own nagios install. /s
dec0dedab0de 5y ago
Self signed certs on an internal network are more secure than CA signed cert on a cloud.
- magicalist 5y ago
  > Self signed certs on an internal network are more secure than CA signed cert on a cloud. Not if your threat model is someone who already has access to the local network (which has no one managing it) snooping on traffic.

austincheney 5y ago

I thought about that, but have not fulfilled it. I wrote an application designed to be private and one-to-one. This particular application allows sending of texts, and file system segments directly from the browser. Encryption would just be a matter of one time public key exchange. I can do that just using the Node crypto API. No central authority needed... yet. 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.

Telemakhos 5y ago

It sounds like you just want to encrypt individual files. Most major office software suites like MS Office will have an encryption feature so that you can password-protect spreadsheets. The other easy solution requires certs, but not the kind you're thinking of: if you want to protect individual files and know who should have access, you could encrypt them using openssl (maybe write an app to wrap it up nicely) and S/MIME certs that could also encrypt your internal email. If you know what you're doing, you can provision out those keys and keep a copy in escrow for data retention policy and accountability.

whoisburbansky 5y ago
This works if you're emailing random files around for all information transfer, but it feels like GP is talking about the case where such information is accessed through intranet websites?
wizzwizz4 5y ago
> Most major office software suites like MS Office will have an encryption feature so that you can password-protect spreadsheets. 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.

slownews45 5y ago

There is a good one, but everyone is pushing the craptastic / megasize management solutions - so I don't think there is anyone out there yet for the 15 machine non AD (or light AD) domain type setups with third party stuff. 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.

vbernat 5y ago
That's already what Firefox does. Despite not saying it clearly, if you accept a self-signed certificate, it will be used as long as it does not change.
deleted 5y ago
[deleted]
staticassertion 5y ago
> Let's say in a rather far out case someone spoofs internal resolution. 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.
- altantiprocrast 5y ago
  > Good thing everyone is already trained to click through certificate warnings. With a proper UI there would be different messages when a cert mismatches compared to when a new cert is seen or the previous cert was about to expire. (Quite like Gemini browsers)

irrational 5y ago

I work for a Fortune 500 company with a huge IT department, and even we have trouble with this. Some intranet sites will work on certain browsers but not others because of certificate issues. So, it is clearly a problem for both large and small companies.

thayne 5y ago

Not to mention that if you set up an internal CA, it is a huge pain to add the CA to browsers, since most browsers don't use the system trusted CAs.

devrand 5y ago
Though most (all?) do support enterprise policies via GPO that would cover the vast majority of enterprise use cases.
- thayne 5y ago
  which has to be managed separately for every combination of OS and browser. If all employees use chrome on windows, that's not too bad, but if you have employees using a variety of different setups, it it is more complicated to set up.
bawolff 5y ago
Which ones other than firefox don't? (And firefox has a config option)

yodelshady 5y ago

Yup, but I'd go even simpler. Imagine An OS-level switch to put arbitrary network traffic over TLS. 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.

amarshall 5y ago
Direct p2p over Wireguard or similar is a solution here.
gsich 5y ago
I imagined it and it looks like SSH.
rolisz 5y ago
That's what Tailscale does. I use it to encrypt communication between my devices (both on home network and when I'm away) and it works like a charm.

staticassertion 5y ago

> 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.) 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?

sam_lowry_ 5y ago
Because Active Directory.
- staticassertion 5y ago
  Could you elaborate? There's Azure AD, or you could do yourself a massive favor and not use AD at all. And like... why would you want AD and an intranet but not someone to manage it at all? Recipe for disaster. The simplest solution to this problem, by far, is to just avoid it entirely. Don't have an intranet. Don't manage AD. Just don't do those things. Pick an identity provider, pick a file sharing service, pick a video chat service, and set up SSO for them. It's 0 maintenance, far safer, and far easier to use.
- geofft 5y ago
  AD has a built-in certificate authority, and installs the root CA on domain-joined machines....

LinuxBender 5y ago

They way I have dealt with this in the past was to buy a wildcard subdomain cert and only use that subdomain internally. The downside is that you have to delegate that subdomain from your public DNS to your internal DNS or do split horizon/split view. Both have caveats and require some thinking ahead. This is not a free solution, but I would consider it affordable for any small business. It is certainly much less complicated than setting up internal CA's and avoids the opex expenses of managing an internal CA and greatly simplifies managing certificate expiration. e.g. *.internal.some.tld You may even be able to find a CA that will sell you a SAN cert with multiple wildcard subdomains listed. They lose money doing this and most will require you to buy a different wildcard cert for each sub-domain. There are no technical or CAB limits to wildcard subdomain SAN certs, only business policy per CA. If CAB have added any recent restrictions that I am unaware of, it would be for purely monetary reasons as the SAN RFC's have no restrictions on the number of names last I checked. e.g. one wildcard SAN cert with names like *.sfo1.dev.some.tld *.uk1.dev.some.tld *.dev.some.tld

xyzzy_plugh 5y ago
> This is not a free solution FWIW 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.

nijave 5y ago

You can use a VPN e.g. overlay network As an added bonus, it keeps working regardless of your location

air7 5y ago

I think that if you are worried about someone sniffing salary info in your org, there are deeper problems to sort out. 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.

nine_k 5y ago

How come there is none? 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?

beebmam 5y ago
This is exactly right. PKI is for everyone. It's really quite simple once you learn how it works! Here's a great explanation that covers a ton: https://smallstep.com/blog/everything-pki/ https://smallstep.com/blog/everything-pki/
- schoen 5y ago
  One SmallStep for a LAN, one giant leap for LANkind?
paulddraper 5y ago
> flash drive 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.
- nine_k 5y ago
  If you have a really small office with 10 desktops / laptops, you may consider that deploying puppet / chef / saltstack / whatever is overkill. Walking around with a flash drive is just faster.
  - chousuke 5y ago
    But it's not more consistent if you need to change something. Having declarative desired state configuration is useful for any environment, even when n = 1. I would definitely deploy a configuration management solution for 10 hosts; it takes a couple hours of work to do properly and you can do it without a server initially (though a central server provides other benefits)

1vuio0pswjnm7 5y ago

"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." 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/ 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.

geofft 5y ago
I'm not sure I follow your argument, because, first, no major browser maker is in the business of selling their web browser software, and second, if you're using the browser maker's software to verify the server, you already have access to it. So even if they were selling it, you've already paid for it. 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.

geofft 5y ago

Name your internal services after some valid DNS domain that you own. Options include - 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 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 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).

deleted 5y ago

[deleted]

isatty 5y ago

My "internal" (local hosts + server nodes) are on its own VPN with wireguard. Even with a VPN, I've letsencrypt provided certs on some of em because it's nice, but it's not strictly necessary. People being able to know that I've things running in my own /8 is not a major security problem.

gerdesj 5y ago

"What we need is ... blah blah blah ... technology" is rarely what you want when you start on this path. 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.

bawolff 5y ago

> We don't need to verify the identity of the server because that's typically not a problem on the 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.

deleted 5y ago

[deleted]

beermonster 5y ago

> 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 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.

WhyNotHugo 5y ago

Make your own organisational CA, and use that. This covers both passive AND active attackers with access to your network.