91–100 of 290 posts
Earlier quoted context omitted.
> Lots of organizations struggle to fully set up trust for the private CA on all internal systems. Made worse by the fact phone OSes have made it very difficult to install CAs.
And in on some platforms and configurations, impossible. Same with the .dev domain
Earlier quoted context omitted.
Do you mean to say that your biggest frustration with HTTPS on .internal is that it requires a private certificate authority? Because I'm running plain HTTP to .internal sites and it works fine.
There's some every packet shall be encrypted, even in minimal private VPCs lore going on. I'm blaming PCI-DSS.
Let's start with the obvious; wifi. If you're visiting a company and ask the receptionist for the wifi password you'll likely get it.
Next are eternity ports. Sitting waiting in a meeting room, plug your laptop into the ethernet port and you're in.
And of course it's not just hardware, any software running on any machine makes the LAN just as vulnerable.
Sure, you can design a LAN to be secure. You can make sure there's no way to get onto it. But the -developer- and -network maintainer- are 2 different guys, or more likely different departments. As a developer are you convinced the LAN will be as secure in 10 years as it is today? 5 years? 1 year after that new intern arrives and takes over maintainence 6 weeks in?
What starts out as "minimal private VPC" grows, changes, is fluid. Treating it as secure today is one thing. Trusting it to remain secure 10 years from now is another.
In 99.9% of cases your LAN traffic should be secure. This us the message -developers- need to hear. Don't rely on some other department to secure your system. Do it yourself.
My biggest frustration with .internal is that it requires a private certificate authority. Lots of organizations struggle to fully set up trust for the private CA on all internal systems. When you add BYOD or contractor systems, it's a mess. Using a publicly valid domain offers a number of benefits, like being able to use a free public CA like Lets Encrypt. Every machine will trust your internal certificates out of t…
Do you mean to say that your biggest frustration with HTTPS on .internal is that it requires a private certificate authority? Because I'm running plain HTTP to .internal sites and it works fine.
For example, you won't be able to run internal videocalls (no access to webcams!), or a web page able to scan QR codes.
Here's the full list:
* https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
A true hassle for internal testing between hosts, to be honest. I just cannot run an in-development video app on my PC and connect from a phone or laptop to do some testing, without first worrying about certs at a point in development where they are superfluous and a loss of time.
My biggest frustration with .internal is that it requires a private certificate authority. Lots of organizations struggle to fully set up trust for the private CA on all internal systems. When you add BYOD or contractor systems, it's a mess. Using a publicly valid domain offers a number of benefits, like being able to use a free public CA like Lets Encrypt. Every machine will trust your internal certificates out of t…
Do you mean to say that your biggest frustration with HTTPS on .internal is that it requires a private certificate authority? Because I'm running plain HTTP to .internal sites and it works fine.
I’m going to go right on using .lan.
Earlier quoted context omitted.
Do you mean to say that your biggest frustration with HTTPS on .internal is that it requires a private certificate authority? Because I'm running plain HTTP to .internal sites and it works fine.
There's some every packet shall be encrypted, even in minimal private VPCs lore going on. I'm blaming PCI-DSS.
Turn on crypto, don’t be lazy
Earlier quoted context omitted.
> Lots of organizations struggle to fully set up trust for the private CA on all internal systems. Made worse by the fact phone OSes have made it very difficult to install CAs.
And in on some platforms and configurations, impossible. Same with the .dev domain
My biggest frustration with .internal is that it requires a private certificate authority. Lots of organizations struggle to fully set up trust for the private CA on all internal systems. When you add BYOD or contractor systems, it's a mess. Using a publicly valid domain offers a number of benefits, like being able to use a free public CA like Lets Encrypt. Every machine will trust your internal certificates out of t…
Earlier quoted context omitted.
Do you mean to say that your biggest frustration with HTTPS on .internal is that it requires a private certificate authority? Because I'm running plain HTTP to .internal sites and it works fine.
Try running anything more complicated than a plain and basic web server! See what happens if you attempt to serve something that browsers deem to require a mandatory "Secure Context", so they will reject running it when using HTTP. For example, you won't be able to run internal videocalls (no access to webcams!), or a web page able to scan QR codes. Here's the full list: * https://developer.mozilla.org/en-US/docs/Web…
Earlier quoted context omitted.
Number one reason that comes to mind is you prevent the possibility of information leakage. You can't screw up your split-dns configuration and end up leaking your internal IP space if everything is .internal. It's much the same reason why some very large IPv6 services deploy some protected IPv6 space in RFC4193 FC::/7 space. Of course you have firewalls. And of course you have all sorts of layers of IDS and air-gaps…
What about things like cookies, storage, caching, etc.. If my job has ` https://testing.internal ` and some company I visit also has ` https://testing.internal ` ...