I wish the invalid SSL cert warning and the password field on HTTP warning could be permanently disabled for all private IP ranges. They are incredibly annoying.
this post was submitted on 22 Jan 2024
68 points (100.0% liked)
Firefox
449 readers
1 users here now
A place to discuss the news and latest developments on the open-source browser Firefox
founded 4 years ago
MODERATORS
That would mean malware can use your local ip and hostfile for mitm attacks.
Isn't it already game over if malware can write into your hostfile? At least on Windows you need some elevated access for it, which means such malware could just read/write the target program's memory directly instead of resorting to clunky MitM.
If malware can write my hosts file it's probably all over anyways, it has admin access and just keylog everything and pull passwords directly from browsers.
I'm not saying it should be the default, I just want an about:config option to disable them (they used to have one for the insecure password field but it no longer works).
Pretty much the only place where I see them. Let’s hope we can disable it in the future.
I have not seen that unless it's some sort of new feature, but if so, that will get quite annoying, quite fast as I access my server locally via HTTP with the IP address.
You can add exclusions
Pressing "Continue to HTTP Site" actually adds it to the allow-lists already which is quite handy (if it weren't for the annoying delay now...)
I wonder if there's a way to do that on mobile.
I don't believe you can get rid of that screen, or the newly added delay, if you have firefox set to HTTPS Only mode
Looking at the support site, the only exceptions that seem to exist there are on a per-site basis: https://support.mozilla.org/en-US/kb/https-only-prefs
You could try poking around in the about:config I guess just in case it hasn't been documented yet.
Edit: added link and extra info
Note that I only want to get rid of the delay before being allowed to press the button, not the screen itself. I want an HTTP connection to remain an action I must explicitly initiate (as it should be).
Does security.dialog_enable_delay work on that?
It does not. It's also 5s, not 1s, so that couldn't have been it.
Btw, Googling that option, I found out that there's a reason for this delay and it's security: https://www.squarefree.com/2004/07/01/race-conditions-in-security-dialogs/
That timeout should indeed only last the value of security.dialog_enable_delay, so 1s. If it is 5s for you, it would be nice if you write a bug report, maybe with a screen recording.
Huh, after a restart it appears to honour that setting; it's now 1s and that's an acceptable security trade-off.
I'm not 100% sure but there may have been an update that was applied by the restart.
I also noticed that and I assume it's because they want people to actually read the warning and not just click continue without thinking.