| ▲ | rlpb 3 days ago |
| Indeed they are compatible. However HTTPS is often unnecessary, particularly in a smaller organisation, but browsers mandate significant unnecessary complexity there. In that sense, brwosers are not suited to this use in those scenarios. |
|
| ▲ | freeopinion 3 days ago | parent | next [-] |
| If only browsers could understand something besides HTTPS. Somebody should invent something called HTTP that is like HTTPS without certificates. |
| |
|
| ▲ | tedivm 3 days ago | parent | prev | next [-] |
| I really don't see many scenarios where HTTPS isn't needed for at least some internal services. |
| |
| ▲ | donnachangstein 3 days ago | parent [-] | | Then, I'm afraid, you work in a bubble. A static page that hosts documentation on an internal network does not need encryption. The added overhead of certificate maintenance (and investigating when it does and will break) is simply not worth the added cost. Of course the workaround most shops do nowadays is just hide the HTTP servers behind a load balancer doing SSL termination with a wildcard cert. An added layer of complexity (and now single point of failure) just to appease the WebPKI crybabies. | | |
| ▲ | progmetaldev 3 days ago | parent | next [-] | | Unfortunately, for a small business, there are many software packages that can cause all sorts of havoc on an internal network, and are simple to install. Even just ARP cache poisoning on an internal network can force everyone offline, while even a reboot of all equipment can not immediately fix the problem. A small company that can't handle setting up a CA won't ever be able to handle exploits like this (and I'm not saying that a small company should be able to setup their own CA, just commenting on how defenseless even modern networks are to employees that like to play around or cause havoc). Of course, then there are the employees who could just intercept HTTP requests, and modify them to include a payload to root an employee's machine. There is so much software out there that can destroy trust in a network, and it's literally download and install, then point and click with no knowledge. Seems like there is a market for simple and cheap solutions for internal networks, for small business. I could see myself making quite a bit off it, which I did in the mid-2000's, but I can't stand doing sales any more in my life, and dealing with support is a whole issue on it's own even with an automated solution. | |
| ▲ | imroot 3 days ago | parent | prev | next [-] | | What overhead? Just about every web server these days supports ACME -- some natively, some via scripts, and you can set up your own internal CA using something like step-ca that speaks ACME if you don't want your certs going out to the transparency log. The last few companies I've worked at had no http behind the scenes -- everything, including service-to-service communications was handled via https. It's a hard requirement for just about everything financial, healthcare, and sensitive these days. | | |
| ▲ | donnachangstein 3 days ago | parent [-] | | > What overhead? [proceeds to describe a bunch of new infrastructure and automation you need to setup and monitor] So when ACME breaks - which it will, because it's not foolproof - the server securely hosting the cafeteria menus is now inaccessible, instead of being susceptible to interception or modification in transit. Because the guy that has owned your core switches is most concerned that everyone will be eating taco salad every day. |
| |
| ▲ | brendoelfrendo 3 days ago | parent | prev | next [-] | | Sure it does! You may not need confidentiality, but what about integrity? | | |
| ▲ | donnachangstein 3 days ago | parent [-] | | It's a very myopic take. Someone that has seized control of your core network such that they were capable of modifying traffic, is not going to waste precious time or access modifying the flags of ls on your man page server. They will focus on more valuable things. Just because something is possible in theory doesn't make it likely or worth the time invested. You can put 8 locks on the door to your house but most people suffice with just one. Someone could remove a piece of mail from your unlocked rural mailbox, modify it and put it back. Do you trust the mail carrier as much as the security of your internal network? But it's not really a concern worth investing resources into for most. | | |
| ▲ | growse 3 days ago | parent [-] | | > Someone that has seized control of your core network such that they were capable of modifying traffic, is not going to waste precious time or access modifying the flags of ls on your man page server. They will focus on more valuable things. Ah, the "both me and my attackers agree on what's important" fallacy. What if they modify the man page response to include drive-by malware? |
|
| |
| ▲ | tedivm 3 days ago | parent | prev [-] | | I'm afraid you didn't read my response. I explicitly said I can't see a case where it isn't needed for some services. I never said it was required for every service. Once you've got it setup for one thing it's pretty easy to set it up everywhere (unless you're manually deploying, which is an obvious problem). |
|
|
|
| ▲ | therealpygon 3 days ago | parent | prev [-] |
| And it is even more trivial in a small organization to install a Trusted Root for internally signed certificates on their handful of machines. Laziness isn’t a browser issue. |
| |
| ▲ | rlpb 3 days ago | parent [-] | | How is that supposed to work for an IoT device that wants to work out of the box using one of these HTTPS-only browser APIs? | | |
| ▲ | metanonsense 3 days ago | parent [-] | | I am not saying I‘d do this, but in theory you could deploy a single reverse proxy in front of your HTTP-only devices and restrict traffic accordingly. |
|
|
