SoylentNews is people
SoylentNews
from the honestly,-it's-for-your-own-good... dept.
Safari will, later this year, no longer accept new HTTPS certificates that expire more than 13 months from their creation date. That means websites using long-life SSL/TLS certs issued after the cut-off point will throw up privacy errors in Apple's browser.
The policy was unveiled by the iGiant at a Certification Authority Browser Forum (CA/Browser) meeting on Wednesday. Specifically, according to those present at the confab, from September 1, any new website cert valid for more than 398 days will not be trusted by the Safari browser and instead rejected. Older certs, issued prior to the deadline, are unaffected by this rule.
By implementing the policy in Safari, Apple will, by extension, enforce it on all iOS and macOS devices. This will put pressure on website admins and developers to make sure their certs meet Apple's requirements – or risk breaking pages on a billion-plus devices and computers.
[...] Shortening the lifespan of certificates does come with some drawbacks. It has been noted that by increasing the frequency of certificate replacements, Apple and others are also making life a little more complicated for site owners and businesses that have to manage the certificates and compliance.
"Companies need to look to automation to assist with certificate deployment, renewal, and lifecycle management to reduce human overhead and the risk of error as the frequency of certificate replacement increase," Callan told us.
We note Let's Encrypt issues free HTTPS certificates that expire after 90 days, and provides tools to automate renewals, so those will be just fine – and they are used all over the web now. El Reg's cert is a year-long affair so we'll be OK.
GitHub.com uses a two-year certificate, which would fall foul of Apple's rules though it was issued before the cut-off deadline. However, it is due to be renewed by June, so there's plenty of opportunity to sort that out. Apple's website has a year-long HTTPS cert that needs renewing in October.
Microsoft is an interesting one: its dot-com's cert is a two-year affair, which expires in October. If Redmond renews it for another two years, it'll trip up over Safari's policy.
(Score: 5, Insightful) by vux984 on Monday February 24 2020, @08:47PM (32 children)
You are half right.
Unless the CA is compromised/keys are brute forced/whatever. certificate revocation is a mess and can't be relied upon. Cycling the certificates isn't ideal, but its the best solution for the public facing internet today. Things SHOULD break on the public internet when security isn't maintained.
The end user of an internet host has ZERO ability to determine whether it is appropriate for the certificate to have changed or not. They aren't privy to the decisions of the IT admins, and have no ability to contact them to inquire. If google changes it's certs and the browser informs me, what am I going to do with that information? Phone them up and ask if there were new certs installed? The only people who should be monitoring the certificates for "suspicious changes" are the very admins responsible for changing them.
Here is where you are right. I agree with you here. And I've advocated ever since Let's encrypt was in beta and the browsers started issuing warnings and making it hard to get to LAN devices that the obvious solution is have an exception for LAN devices. A warning may still be appropriate, but if I'm trying to get to a reserved for LAN use address directly, via the private IP address, from the same subnet, then the browser should still warn me, but it should mostly get out of the way if the cert is expired, or self-signed or something. My LAN attached laser printer or whatever doesn't need to be held to the same certificate standards as the public internet.
Agree to disagree. It ensures the public internet gets maintained. The short cycle times have lead to robust automation and monitoring; instead of fire-and-completely-forget-about-it. I 100% agree with Lets Encrypt's philosophy on that one.
(Score: 2) by bzipitidoo on Tuesday February 25 2020, @12:15AM (23 children)
> keys are brute forced
Hold it. Do you have any idea how long a brute force attack on a reasonably long key would take? It's so easy to make the keys long enough for brute force to be hopelessly impractical, taking quadrillions of years with current computers. Another 10 bits can make it take 1000 times longer, if one wants to be extra sure that advances in speed and core counts won't bring that down to a manageable length of time.
In fact, as I recall, the whole reason for mandatory password expiration was the amount of time it took to brute force the idiotically short passwords to which most early computer systems limited the users. The idea was to force users to change passwords which forces a password cracker to discard whatever progress it has made through the password space. Make the users change passwords frequently enough, and brute force might never make significant progress before having to start over. It was a real dumb bandaid workaround to the real problem that they couldn't be bothered to allow longer passwords than 8 characters. Sheer laziness to have hardcoded an 8 character limit, but a lot of systems had that. Worse, some systems would appear to accept longer passwords, silently truncating them to 8 characters! As late as 2000, I encountered just such a system. The way to tell if a system you're using has such a limit is to set your password to more than 8 characters, and, if it accepts that, then try to log in using just the first 8 characters. If it lets you in, then you know.
Now, somehow, some still swear by this rule of making frequent password/key changes despite there no longer being any need arising from the keys being too short in the first place.
(Score: 2) by sjames on Tuesday February 25 2020, @12:24AM (3 children)
Now, years later, frequently rotating passwords are no longer recommended. It turns out you were just as likely to change your password to something the brute force attack was going to guess next as you were to change away from the unfortunate (for you) next guess.
(Score: 2) by vux984 on Tuesday February 25 2020, @12:59AM (2 children)
It still purges persistent unauthorized access. (e.g. the you gave your password to your assistant one time in an emergency or you got phished/MITMd that one time you used an insecure wifi hotspot and don't know) and years later they still have access...
(Score: 2) by sjames on Tuesday February 25 2020, @01:16AM
It does, but the interval for that can be somewhat longer to avoid people writing their password on a post-it under their keyboard.
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @02:17PM
Yup, the APT is the ONLY thing that password changes affect.
This is why it likely isn't worth it for most things that are susceptible to smash and grab attacks.
(Score: 2) by vux984 on Tuesday February 25 2020, @12:56AM (17 children)
Yes. Sorry. By 'brute forced' I simply meant shorthand for something along the lines of the hash algorithm used on the cert is dated and flawed and mathematicians have devised clever methods of dramatically reducing the searchable key space to the point that hash collisions are practical to force, etc, etc. I understand nobody is brute forcing it.
I mean, i guess, yes, that was PART of it. But it also was and remains to this day a good way to purge existing persistent unauthorized access. If you "gave your assistant your password one time in an emergency" or something 3 years ago, or maybe you got phished and never noticed, if you never change your password, they retain access indefinitely. Years later, the assistant works somewhere for a competitor maybe, but they've still got access to your account. Periodically changing your password closes those doors.
Sure a good hacker will use their access to create themselves a new account or something so they can get in long after their original door is closed. But periodically auditing the accounts that have access can catch that. And maybe your account can't be used to create new accounts but there's enough juicy stuff in it that its still valuable on its own for whatever reason. Rotating your passwords periodically (even if you are using a password manager with big passwords) is STILL a good idea for these reasons.
If you've got 2FA authentication enabled though, then you really don't need to rotate passwords, because the 2FA component is already a rotating password. And adding a rotating password policy to a rotating password is stupid. (hello Datto you listening?)
(Score: 2) by sjames on Tuesday February 25 2020, @01:13AM (16 children)
That happens a lot less often than annually or even every 5 years. The solution is to deprecate certs using the broken hash.
(Score: 2) by bzipitidoo on Tuesday February 25 2020, @01:50AM (1 child)
Exactly. You should change keys/passwords when you have reason to believe they are compromised, and not just because a set period of time has elapsed. Passwords are not perishable items. Good passwords can be compromised, but they aren't going to go "stale" and "rot". Again, the reason for a mandatory timeout period was that was the length of time a brute force attack needed for some unacceptably high odds of achieving a compromise of a password or key. Make the space big enough, which is easy to do, and brute force ceases to be a threat worth worrying about.
A flaw found in a hash algorithm may make brute force practicable, but it is the discovered weakness that did it, not the quickness of the progress that a brute force attack can now make. To wit, if you change passwords, but continue to use the weak hash, you remain essentially as vulnerable as if you'd never changed passwords. Changing passwords is no real defense against that, and doing so anyway is just security theater. You must change hash algorithms.
As to the notion that rotation protects against the unknown, well, no, no it doesn't. You might have forgotten that you gave out your password? Well, a) don't give out your password!! But if you insist, then b) change it immediately after the borrower is finished. It's also easy enough to log in, then let the other person sit at the terminal and drive, so they can do whatever is needed, without you having to tell them your password. If that's not good enough, then you need a different solution that doesn't involve revealing your password. There are many ways to work things to give out necessary access and yet keep those passwords secret and secure. Such as, shared directories.
(Score: 2) by vux984 on Tuesday February 25 2020, @02:33AM
I agree, but nobody suggested that changing passwords is a solution to a weak hashing algorithm.
I'd say it protects against the known. That is -- I *know* lots of users are fuckwits. :)
As someone whose done IT I've been given countless passwords and access to all kinds of things in my role of fixing them or working on them that I didn't want or need, and certainly didn't need persistent access. Where they should have entered their password and let me drive as you aid, or setup a temporary access and then revoked it, but they didn't want to stick around or bother with that so they just left it behind on a note or by email. You can't fix stupid, and sometimes (oftentimes) they're the boss.
Periodically forcing a rotation at least sunsets some of the illicit access that's enabled by this poor password hygiene.
There's nothing I could do to change their behavior, but at least periodically forcing them to rotate them meant that at least just the current secretary and IT consultants likely had access instead of everyone who had ever worked for the company.
The problem isn't generally that the technology to solve this doesn't exist, merely that people refuse to use it, or that there are many places where it hasn't been implemented. There are lots of things that do not offer options. Quickbooks Pro only has one "admin" account, countless devices and services are likewise setup like that. So if multiple people need to share the admin account they have to share that password. Forcing a rotation now and again helps to "reset" who still has access to those resources.
(Score: 2) by vux984 on Tuesday February 25 2020, @01:57AM (13 children)
True, and we do deprecate broken hash algorithms. But when it happens to you really want to wait 5+ years for insecure certs to go away? If we're already in a mode where we're purging certs every few months, its pretty easy to incorporate auditing and maintenance and to upgrade algorithms etc as we go. If nobody is at the wheel because the certs live longer than most employees are likely to stick around then when a deprecation comes along impacted certs are just going to stick around untended until things finally break down.
Plus I originally wrote: "Unless the CA is compromised/keys are brute forced/whatever."
The "CA Compromise" for example is completely orthogonal to hash algorithms. If the CA issues a bunch of certs it shouldn't have for whatever reason, then simply purging all certs regularly is probably the best way to guarantee they get out circulation sooner than later. Certificate revocation lists SHOULD be the solution to that issue, but its a complicated mess to get right as distributing the revocation lists itself a difficult problem to completely solve completely. It's easy for a browser to verify a certificate chain from just from it's own root cert repo and what the site provides but verifying the cert hasn't been revoked needs constant rechecking to another authority and if that connection is blocked or down or anything then you don't know. At least this way improperly issued certs have a short life expectancy so they go away.
I don't think its a perfect solution, but it is a practical and useful measure.
(Score: 2) by sjames on Tuesday February 25 2020, @05:04AM (12 children)
Why would I wait 5 years. If a hash is broken, deprecate the hash itself. That will invalidate any certs using it without regard for their expiration date. They can claim to expire in 2499 if they want, but if the browser isn't trusting certs using MD5 with a 256 bit RSA, it's a moot point.
If a CA issues a bunch of bad certs, the CA's signing key gets revoked. No need for the rest of the world to run on a treadmill just in case. If you don't revoke the CA's key, the bad guys will just dutifully renew their bogus certs annually (and will probably be more careful to not let it lapse than the legitimate cert holder).
Software these days manages to download upgrades and security patches (seemingly) every 4.2 seconds or so, why not a daily incremental from the vendor with the fingerprints of invalid certs? That both lets the whole world get off of the cert renewal treadmill and will make the revoked certs go away 365 times faster than Apple's proposal. This isn't rocket surgery. If the CAs and the browser vendors were at all serious about keeping certs secure, it would have been done years ago without making the rest of the world jump through hoops.
(Score: 2) by vux984 on Tuesday February 25 2020, @08:48PM (11 children)
That does nothing to the users browser unless they update. And I see that is where you are headed.
Ok, but your solution amounts to: instead of millions of website admins having to manage updating certs regularly, billions of end users have to make sure they get updated revocation lists DAILY, instead.
Another avenue for mischief is if a certificate is stolen (copied). Now they can run MITM attacks with it. This can go undetected for a long time. If the certs have short life cycles, the hackers will need to obtain new stolen certs regularly, and maybe the opportunity to steal it was a one-off. In this scenario someone has to also detect and report that the certificate was compromised to get it revoked, which may not happen. Where as if they cycle out regularly, it goes out of circulation even if nobody does anything.
I don't see how you think your solution is anything but making MORE people jump through even MORE hoops. CRLs are more work to manage, more work to distribute, and more work to keep updated, and if a mistake get through the cert lives indefinitely. The short lifecycle on certs is akin to a molten salt reactor -- it requires action to keep working, and it simply shuts down if you stop taking action. That's a better design to one that needs corrective action taken when something is wrong. I.E doing nothing and the cert will die off shortly is better design than trying to actively distribute a revocation notice to everyone on the planet.
(Score: 2) by sjames on Wednesday February 26 2020, @02:18AM (10 children)
AV software already does daily updates. Many browsers already get regular updates to warn of suspected scam sites. They do it witout most people even noticing. If the browser can't get on the internet to download the updated data, it's not going to connect to any spoofed sites anyway.
Good luck going a whole year before the browser itself wants to do an update. Even if the revocation list only updates when the browser does, it still offers a shorter window to exploit a stolen cert than Apple's plan does, and the user will already be doing an update anyway.
I have seen a lot more stories about sites down because of an expired cert than I have sites MITMed (other than by approved corporate firewall proxies on corporate LANs).
If someone grabs a cert and does a MITM, they'll still have a year to get away with it even with the shorter expiration, even if the rightful owner discovers it and issues a revocation.
Keep in mind, revocation lists are already part of the standard, My proposal that it be distributed as diffs to a list rather than being checked against a server one at a time is hardly radical.
(Score: 2) by vux984 on Wednesday February 26 2020, @03:20AM (9 children)
"AV software already does daily updates."
Unless it doesn't. How many of us have seen a system that hasn't done its updates recently for whatever reason or other?
"I have seen a lot more stories about sites down because of an expired cert than I have sites MITMed "
True, but are those stories about sites that are using let's ecnrypt certs with automated renewals or are they stories about sites using long multi-year certs where the person installed it left the company years ago, and the person responsible for it didn't even know it existed. The ones I've read of are mostly the latter kind. :)
All that said, I see this as a belt-and-suspenders situation. I'm not saying we abandon revocation lists; they're the suspenders in this analogy. But cert rotation acts as a failsafe, or the "belt", when the "suspenders" fail.
(Score: 2) by sjames on Wednesday February 26 2020, @10:36AM (8 children)
Unless it's something other than a regular blog or news site where updating cannot be automatic without putting the security of the thing being updated at risk.Or the site is small and decides to just screw certs and goes bact to http. Do you really want to flash your BIOS annually? Your thermostat? Your light bulbs? Care to talk your mom through adding an exception in her browser (if it will even accept that)?
(Score: 2) by vux984 on Wednesday February 26 2020, @06:22PM (7 children)
We seem to have gone in a circle.
I started out by agreeing that your thermostat, lightbulbs, etc (ie local devices on your LAN, connected to via LAN ip address should be treated differently by the browser and that cert rotation is not necessary or appropriate for them.
I am arguing that rotating certs make sense for public facing servers on the internet. And I agree it does not make the same amount of sense for private devices on the LAN. The risk profile is much lower AND the technical burden to do it is much higher and placed on people unlikely to be qualified. So it becomes unreasonable.
And its pretty easy for the browser to know if its been handed an internet ip address, FQDN, or a LAN ip address; so it CAN differentiate between the two. So there's no reason it can't easily enforce rotating current certs when browsing to login.mysuperhost.com and make it hard (like editing the registry hard or manually editing config files hard) to "continue anyway", but still let you connect to 192.168.1.44 with an expired self-signed cert with just a click-through warning.
(Score: 2) by sjames on Wednesday February 26 2020, @08:32PM (6 children)
The problem is, the proposal at hand isn't making such a distinction. Just like Chrome doesn't recognize that connections to localhost present less risk than connecting to something on the open net. Browsers in general seem to be becoming less useful. It's like the major browsers are in a contest to see which one can lop off the most useful parts.
(Score: 2) by vux984 on Wednesday February 26 2020, @08:50PM (5 children)
We are in complete agreement on that, and on Chrome vs localhost too.
Although firefox "developer edition" seems to exist precisely to help alleviate some of this stuff; but of course checking the ink level and changing the network settings on your laser printer aren't "developer tasks". But maybe that's the direction this should go in... chrome for the internet, some chrome-derived fork that has all those restrictions toned down/turned off but it not an internet browser, and it *won't* browse the public internet. Good only for managing local devices and local development, troubleshooting your intranet, connecting to your router, etc. Call it LAN-Browser or something.
You click a link on your laser printer web tool that wants to go to supplies.brother.com and it opens that link in a new window in chrome.
Your local computer & local LAN, and the internet are *not* the same thing. Maybe instead of different settings and security sets for different zones it would simply be better to simply use different applications.
(Score: 2) by sjames on Wednesday February 26 2020, @09:49PM (4 children)
That too might break a number of perfectly reasonable use cases. For example, what if I'm using IPv6 and my LAN is using addresses that could be public but are filtered by my firewall? You as a mere mortal developer simply cannot know.
What is really needed is a way for the user to decide what's OK and what is not. I have no doubt that some people might make bad decisions, but that's the nature of things when you treat adults as adults. Either we accept that it's possible some idiot might toast a shotgun shell or we treat everyone like they're 5 years old and refuse to toast anything but manufacturer approved standard slices of white bread.
How about if something looks like it could be a problem, ask the user and accept their decision? Make sure their choice can be case by case rather than a choice between never for anything or always for everything.
Browsers USED to make it easy to look at the cert, then decide between reject it, accept it just this once, or accept it from now on. It was simple enough to do that you could talk your mom through it if necessary but it would be hard to do it accidentally.
(Score: 2) by vux984 on Wednesday February 26 2020, @10:26PM (3 children)
"For example, what if I'm using IPv6 and my LAN is using addresses that could be public but are filtered by my firewall? You as a mere mortal developer simply cannot know."
My computer knows which hosts are on the LAN and which aren't.
Now if you've got a complicated intranet with routed subnets using public address space, and you want to connect to devices using direct IPV6 addresses on different subnets within the intranet ... shit... your not a regular user. If you made that mess, then you'll figure something out ... throw a secure raspberry pi in each subnet to proxy for you, or setup a VPN, or edit the lan-browser configuration to add your private subnet ranges to the list of "private" ip ranges, and get that updated config signed by a trusted root cert for your organization... same as we trust self-signed/domain joined systems etc. Regular Home users aren't going to be hit by this.
Because (most) users always click "Accept". Few understand the message, and most don't even read it. They just click around until it "works".
Once she's done it a few times, and she's "trained" to do it, then she does it every time. Her laser printer toner status... her bank account phishing email redirecting to a fake site --> Same browser application, same warning message, same solution. The whole reason we don't do this anymore is that regular users consistently get it wrong. Not occasionally get it wrong. Not sometimes get it wrong. CONSISTENTLY GET IT WRONG.
(Score: 2) by sjames on Thursday February 27 2020, @02:06AM (2 children)
Then you should set the config option "child safe" on your mom's browser. If you click the button that says not recommended right on it without knowing what you're doing, you are the architect of your own problem. Kinda like when people use tape to hold the safety down on their lawnmower.
The whole IPv6 thing was simply the first thing that came to my mind you had failed to anticipate that would break things. Your proposed solution is already fairly complex and involved config options you hadn't recognized a need for. Are you sure there aren't a thousand more perfectly reasonable cases neither you nor I have thought of, each requiring more special case configurations?
As far as phishing goes, when I am running a pentest, I just use http to dodge the whole issue. Simple workarounds like that are often easier to implement for scams than they are for legitimate use cases meant to actually be secure.
You might be interested to know that a number of Cisco products will proxy ARP any reachable address on the other side, including the entire internet. I say that to drive home the point that there's just too much out there to smugly implement policy in software rather than sticking to mechanism and leaving policy to the user.
(Score: 2) by vux984 on Thursday February 27 2020, @05:52PM (1 child)
What are people supposed to do that don't have you around to manage their network for them? Meanwhile the printer's chat support will simply tell her to turn off child-safe mode, same as they currently instruct you to 'continue anyway' past the bad cert.
Agreed. But "blame the user" isn't a solution. And it's a bad software design pattern to ask end-users questions they aren't likely to know the answer to; especially security related questions, or to ask them "are they sure?" all day.
I'm aware, and im not sure how that changes anything. I even alluded to it as a potential solution for the ipv6 private routed intranet question.
The point remains, there is almost never a good reason for an *end user* to bypass an expired cert to reach an internet FQDN. There are LOTS of good reasons for end users to bypass expired certs on the LAN. So its an improvement over the status quo. **Even** if its not perfect, it reduces the attack surface, and reduces the number of useless warnings users get.
Sure if a malicious actor has control of your LAN router, and of your localhost lan ip configuration so that it can trick your host into thinking address X is on the LAN, and then they get you to enter that host's IP address directly into the address bar of your browser, so it can arp proxy the packets to an internet host ... then you are so totally pwned anyway that nothing was going to save you.
(Score: 2) by sjames on Thursday February 27 2020, @11:07PM
It's better than Nerfing the world. Better yet, educate the user (No means No) then hope for the best.
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @02:01PM
That would be a crime in fact.
I want to move to Mars.
(Score: 2) by sjames on Tuesday February 25 2020, @12:19AM (1 child)
Let's encrypt is good enough for websites that honestly were fine without encryption, or for user/pass login to various fora, but you need more for your bank or the source for your software updates (for example).
The utter failure to actually implement revocation is not fixed by making changed certs LESS suspicious. Especially under the current sustem where CAs are legion. Have a look at the list of root CAs in your browser. Can you honestly say you've even heard of more than 10% of them? Any one might at any time be fooled into issuing a cert for your bank or Microsoft (the latter has actually happened). For that scenario, lasting for 2 years isn't much different than lasting for a year really, but if the sudden change raised red flags, it would reduce the problem substantially.
(Score: 0) by Anonymous Coward on Tuesday February 25 2020, @05:02AM
Yes I can but then again I deleted most of the root CAs, leaving only ones that I trust.
(Score: 2) by Pino P on Tuesday February 25 2020, @04:34AM (5 children)
True of your home LAN, not so much of a public LAN, such as that in a library or coffee shop. How would a browser running on your laptop or mobile device distinguish your home LAN from a public LAN?
(Score: 2) by vux984 on Tuesday February 25 2020, @09:15PM (4 children)
Why would I be directly connecting to a LAN IP address in my browser in the library or coffee shop? I mean, literally entering in http://192.168.1.44 [192.168.1.44] into the firefox address bar ? Where do you envision this scenario coming up exactly? (PS If you are using DNS, then you need a valid cert -- I'm only excepting direct local IP addresses here.)
We're kind of chasing the wrong problem here. First, I did say that I think in this case the browser should still properly warn you about certificates; it should just be less obnoxious about blocking you if its a LAN connection by IP address. So you would still get a warning at the coffee shop.
And second, remember certs solve two problems:
1) the connection between me and the host is encrypted; so it can't be listened in on by other devices.
self-signed certs satisfy that.
2) I am actually talking to the host I think I am talking to.
If i connect to login.mybank.com; I want to be sure that the computer I'm talking to really is login.mybank.com; and not some other device pretending to be login.mybank.com. A self signed cert fails that, because anyone can self-sign their claim that the host is login.mybank.com. And the whole public signed certificate chain to a trusted root is just to allow me to assert that I trust that only the proper owner of mybank.com can get such properly signed certificates for login.mybank.com; so if this computer has a valid certificate chain, then I trust that it is properly authorized by the owner of mybank.com and it is the computer i think it is.
But if I am connecting to 192.168.1.44; that's not even a name. As long as the device responding is really sending traffic from IP address 192.168.1.44 (which can be verified), then don't I properly know I am talking to the device I asked to talk to?
(Score: 2) by Pino P on Tuesday February 25 2020, @09:58PM (3 children)
Then why does multicast DNS (mDNS) even exist, given that other protocols have changed to make the names it issues unusable?
Nested NATs mean that a device that reports itself as 192.168.1.44 and is in the same room as you might not actually be 192.168.1.44 on your network but instead 192.168.1.44 on a different network.
(Score: 2) by vux984 on Tuesday February 25 2020, @10:29PM (2 children)
"Then why does multicast DNS (mDNS) even exist"
How is that a rebuttal? If you want trust you can't rely on a zero-configuration service that doesn't offer any guarantees.
"Nested NATs mean that a device that reports itself as 192.168.1.44 and is in the same room as you might not actually be 192.168.1.44 on your network but instead 192.168.1.44 on a different network."
Nevertheless I am talking to a device at 192.168.1.44 on the LAN, and that's what i asked the browser to do. That its not THE device i think it is, is on me. LAN IP Addresses are not globally unique. If tell the browser to talk to the device on the LAN at 192.168.1.44 as long as its doing _that_ its done its job the best that can be reasonably expected. Putting certificates on things isn't going to fix it. 192.168.1.44 is still not going to go to the device I thought it was going to; it'll just go to the wrong device with a certificate on it. That's the inherent *risk i take* for using a LAN IP address instead of a FQDN.
(Score: 2) by Pino P on Wednesday February 26 2020, @02:22PM (1 child)
Over the past few years, web browser publishers have begun "deprecating" (Mozilla's word) protocols that do not provide trust [mozilla.org]. Thus as time goes on, "a zero-configuration service that doesn't offer any guarantees" becomes less and less useful.
Hence why the browser does not trust it.
So what's a good way to mitigate such risks for non-technical users, who happen to outnumber the sort of highly technical users who frequent SoylentNews?
(Score: 2) by vux984 on Wednesday February 26 2020, @04:16PM
The point remains that connecting to LAN devices by LAN ip addresses its comparatively low pretty low risk scenario *in the first place*.