> In summary, there’s no compelling reason to keep the security interstitial when visiting HTTPS resources presenting self-signed certificates on intranet IP addresses.
Ah, yes, it's totally legit https://accounts.google.com served by 10.254.127.1, because someone responded with
accounts.google.com A 10.254.127.1
so a browser now should shut up and trust it[0]
> the question of how to present such requests when the server in question is identified by a private IP on the intranet is hopefully a lot more clear-cut and more of an oversight than a purposeful decision
No, it's not 'more clear-cut'. The browser has no idea if this thing you are accessing is a legit device you want to use or it's a planted honey-pot by a malicious actor and you were redirected there somehow[1]
Overall, it's another 'x y problem'. The actual problem here is what browsers are conditioned to act dumb and scare people away, because ... there is no other way to make Regular Joe to just click Next-Next-Accept when he is trying to access his bank website and he would do it anyway because he doesn't understand what is written there and he needs to pay his bills!
Yes, it's bother for me what even I is forced to do a dance to even actually see the cert contents, which would tell me instantly where the problem, but I don't see a 'clear-cut' way solve both the security and usability, without compromising the security.
Yes, browsers should give a more descriptive errors when the cert's SANs doesn't much the hostname, instead of just trying to scare away the user.
[0] yeah, I know about cert pinning. Google has it, but what about your bank? Your corporate? Your bank and corporate when you aren't living in the US?
[1] if you have the access to the router than you can banally redirect 10.254.127.1 to any routeable address with a simple DNAT rule. 'But muh router is secure!' - yes, yours is secure (at least until you are proven wrong), but what about a WiFi hot-spot at the nearest Starbucks? Hotel WiFi? Etc?
I don't see why a browser would "just trust" that because it is a private IP - the TLD is what matters. When you hit an internet TLD you should play by internet rules, when you hit a LAN TLD (or IP range) you could play by LAN rules. The judgement being decided by where the domain in the http request, not the final destination of any DNS lookups
If you directly went to 10.254.127.1, or some-domain.lan, that should validate differently to going to accounts.google.com
The exact issue I explained - for you it would be a local IP, even if the actual destination is anywhere else => no checks.
> TLD is what matters
bankofamerica.com.lan
It can't be used in the wild, compared to bankofamerica.com.security.itdept.xyz in the email, but it opens a way for a directed attacks to be way easier. Especially considering the awful security record of most 'SOHO' routers out there.
Sure, you can respond with evil bit set to zero for IoT devices...
Just to be clear I mean if the browser bar says accounts.google.com, you get the internet "level" validation. Regardless if the IP resolved by malicious dns is 10.0.1.1
This would be an extension of the recent HSTS preload list trend of associating a particular TLD (e.g. .dev) with a particular mechanism, and would not affect other tlds than (say) .lan or ip ranges
Ah, yes, it's totally legit https://accounts.google.com served by 10.254.127.1, because someone responded with
so a browser now should shut up and trust it[0]> the question of how to present such requests when the server in question is identified by a private IP on the intranet is hopefully a lot more clear-cut and more of an oversight than a purposeful decision
No, it's not 'more clear-cut'. The browser has no idea if this thing you are accessing is a legit device you want to use or it's a planted honey-pot by a malicious actor and you were redirected there somehow[1]
Overall, it's another 'x y problem'. The actual problem here is what browsers are conditioned to act dumb and scare people away, because ... there is no other way to make Regular Joe to just click Next-Next-Accept when he is trying to access his bank website and he would do it anyway because he doesn't understand what is written there and he needs to pay his bills!
Yes, it's bother for me what even I is forced to do a dance to even actually see the cert contents, which would tell me instantly where the problem, but I don't see a 'clear-cut' way solve both the security and usability, without compromising the security.
Yes, browsers should give a more descriptive errors when the cert's SANs doesn't much the hostname, instead of just trying to scare away the user.
[0] yeah, I know about cert pinning. Google has it, but what about your bank? Your corporate? Your bank and corporate when you aren't living in the US?
[1] if you have the access to the router than you can banally redirect 10.254.127.1 to any routeable address with a simple DNAT rule. 'But muh router is secure!' - yes, yours is secure (at least until you are proven wrong), but what about a WiFi hot-spot at the nearest Starbucks? Hotel WiFi? Etc?