What you’re proposing sounds like an extremely dangerous UI.
It would practically mean that a user would have to be in constant alert if the URL bar changes from the HTTPS one to the HTTP one, as at any time an attacker could intercept any navigation on a webpage with a selfsigned certificate.
More generally: There’s a reason for the push for HTTPS everywhere. As soon as you mix HTTP and HTTPS (or HTTPS with and without webpki certs) you need to consider all kinds of downgrade attacks.
I believe we have a different assumption what the web should and can provide as security. I would argue the web itself can’t provide something better then self signed certs. There are protocols (i.e. HSTS, DANE) witch can get you better security, but there is no security only by the usage of a cert signed by some CA in the trust store of the browser.
In other words if you assume an attacker can active man in the middle some connection, you should also assume the attacker can issue a domain validated cert for your domain.
What you say seems to be completely disconnected from reality.
Everyone can create a selfsigned cert for any domain. You can’t do that for a webpki CA signed cert, however that seems to be your assumption - for which you provide no evidence whatsoever.
Yes anyone can create a cert for my domain. But to attack an connection the attacker needs two more thinks:
First he needs to be able to intercept the connection. Either by tricking the client to connect to him instant of me or by sitting somewhere on the route between me and the client.
Next he needs the computing power to handle every connection he wants to intercept. For one connection this might be somehow feasible, but this doesn’t scale good for many connections.
There are attacker for them this is still feasible and profitable. But a thread model with only these attackers is quite weak, because there are a lot attackers with also can create fake domain authenticated certificates. And for me as user It’s also the better assumption to not trust the Site till I have checked I’m on the right domain and they have set up an extra security protocol. There are sites on the internet where I’m[0] fine with Tofu and a self signed cert. Actually I would prefer DANE with self signed certs.
I don’t think that is how this works at all. You (@satanist) cannot generate a certificate for lobste.rs that any modern browser would accept without any problems, even if you successfully MITM’d the connection from me to the real lobste.rs. Unless (and that’s a biiig “unless”) you just happen to have the ability to sign that cert you made for lobste.rs with some root cert that modern browsers/operating systems trust. But it’s unlikely you don’t, and that no attackers would. Except maybe nation states, or a trusted CA that went rogue/influenced by nation state/whatever (which is a real concern).
Trusted CA’s have been caught with their hand in the cookie jar several times giving out bad certificates. With Certificate Transparency(CT), the hope is, the next time their hand is in the cookie jar, it will at least get noticed. CT is not perfect either, but it’s certainly adding some more trust.
But there is zero reason to think the trusted CA’s won’t find new and interesting ways to subvert CT when possible, since the incentives can be delicious and hard to ignore. Certainly it’s less likely that an average Tootie can get a free trusted cert for lobste.rs these days, but it’s not outside the realm of possible. The best we can really hope for, is it will eventually be noticed(hopefully sooner rather than later).
I’m not sure what do you mean I have understand wrong.
I question two things first is it good to require for all web connection a “secure” channel or can we also live with not secure channels and explain the users that the web is not a secure medium by default? Keep in mind at the moment you get unencrypted connection, when you type a domain in the URL bar.
Second is it reasonable to assume a certificate is trusted and therefor the connection is secure, because it’s signed by one of the 9001 trusted CAs?
I tried in Firefox, but it seems there is no wildcard support. It will be a bit annoying if I have lots of internal domains without HTTPS behind a VPN.
Hi, I’ve worked on this feature on and off and I’d be interested to hear more about your setup.
Do these internal hosts use public IP space? If not, Firefox implements an exception for local IP addresses. For IPv4 that resolves to 10/8 prefix (RFC 1918), 172.16/12 prefix (RFC 1918), 192.168/16 prefix (RFC 1918), 169.254/16 prefix (Link Local - for IPv6 it’s fc00::/7 (Unique Local Address) and fe80::/10 (Link Local Address).
Did you consider using a wild-card HTTPS certificate for all your internal hostnames? I suppose you discarded this approach, but it would be interesting to hear why :)
Do you have a fixed list of hostnames that you could enumerate? If so, would your use case be fixed by some sort of preference that would take a comma-separated list of hostnames? Internally, we’ve implemented storing site exceptions at the origin level (and as a “permission”, rather than in a pref), which makes site-wide or wildcard exceptions a bit tricky, but that’s merely an implementation choice…
Do these internal hosts use public IP space? If not, Firefox implements an exception for local IP addresses. For IPv4 that resolves to 10/8 prefix (RFC 1918), 172.16/12 prefix (RFC 1918), 192.168/16 prefix (RFC 1918), 169.254/16 prefix (Link Local - for IPv6 it’s fc00::/7 (Unique Local Address) and fe80::/10 (Link Local Address).
No. These internal hosts mostly point to 172.16/12.
One of my typical use cases is that I need to access WebSVN (svn.company-name.ad, points to 172.31.x.y, without HTTPS support). If I have not added it to the HTTPS-only mode exception, it will raise a warning.
Did you consider using a wild-card HTTPS certificate for all your internal hostnames? I suppose you discarded this approach, but it would be interesting to hear why :)
To be honest, this is the thing I cannot control :-( And I don’t think other teams in my company have enough resources to do this.
Do you have a fixed list of hostnames that you could enumerate? If so, would your use case be fixed by some sort of preference that would take a comma-separated list of hostnames? Internally, we’ve implemented storing site exceptions at the origin level (and as a “permission”, rather than in a pref), which makes site-wide or wildcard exceptions a bit tricky, but that’s merely an implementation choice…
From my perspective, it would be much better if Firefox could take a comma-separated list. Usually, I have 20-30 internal hosts (same suffix) I would visit on my typical weekdays. Of course, I can add them one by one when it shows a warning, but I think there is a room for UX improvement :)
Out of curiosity, when I used the HTTPS Everywhere extension, why didn’t it raise a warning when I opened an internal host without HTTPS encryption?
Why must it be every time a extreme?
I would like to have https as default, show sites with self signed certs like currently http sites and give me a warning on http sites.
What you’re proposing sounds like an extremely dangerous UI. It would practically mean that a user would have to be in constant alert if the URL bar changes from the HTTPS one to the HTTP one, as at any time an attacker could intercept any navigation on a webpage with a selfsigned certificate.
More generally: There’s a reason for the push for HTTPS everywhere. As soon as you mix HTTP and HTTPS (or HTTPS with and without webpki certs) you need to consider all kinds of downgrade attacks.
I believe we have a different assumption what the web should and can provide as security. I would argue the web itself can’t provide something better then self signed certs. There are protocols (i.e. HSTS, DANE) witch can get you better security, but there is no security only by the usage of a cert signed by some CA in the trust store of the browser.
In other words if you assume an attacker can active man in the middle some connection, you should also assume the attacker can issue a domain validated cert for your domain.
What you say seems to be completely disconnected from reality.
Everyone can create a selfsigned cert for any domain. You can’t do that for a webpki CA signed cert, however that seems to be your assumption - for which you provide no evidence whatsoever.
I think you still misunderstand what I’m saying.
Yes anyone can create a cert for my domain. But to attack an connection the attacker needs two more thinks:
First he needs to be able to intercept the connection. Either by tricking the client to connect to him instant of me or by sitting somewhere on the route between me and the client.
Next he needs the computing power to handle every connection he wants to intercept. For one connection this might be somehow feasible, but this doesn’t scale good for many connections.
There are attacker for them this is still feasible and profitable. But a thread model with only these attackers is quite weak, because there are a lot attackers with also can create fake domain authenticated certificates. And for me as user It’s also the better assumption to not trust the Site till I have checked I’m on the right domain and they have set up an extra security protocol. There are sites on the internet where I’m[0] fine with Tofu and a self signed cert. Actually I would prefer DANE with self signed certs.
[0] I, you might have an other policy
I don’t think that is how this works at all. You (@satanist) cannot generate a certificate for lobste.rs that any modern browser would accept without any problems, even if you successfully MITM’d the connection from me to the real lobste.rs. Unless (and that’s a biiig “unless”) you just happen to have the ability to sign that cert you made for lobste.rs with some root cert that modern browsers/operating systems trust. But it’s unlikely you don’t, and that no attackers would. Except maybe nation states, or a trusted CA that went rogue/influenced by nation state/whatever (which is a real concern).
Trusted CA’s have been caught with their hand in the cookie jar several times giving out bad certificates. With Certificate Transparency(CT), the hope is, the next time their hand is in the cookie jar, it will at least get noticed. CT is not perfect either, but it’s certainly adding some more trust.
But there is zero reason to think the trusted CA’s won’t find new and interesting ways to subvert CT when possible, since the incentives can be delicious and hard to ignore. Certainly it’s less likely that an average Tootie can get a free trusted cert for lobste.rs these days, but it’s not outside the realm of possible. The best we can really hope for, is it will eventually be noticed(hopefully sooner rather than later).
I’m not sure what do you mean I have understand wrong.
I question two things first is it good to require for all web connection a “secure” channel or can we also live with not secure channels and explain the users that the web is not a secure medium by default? Keep in mind at the moment you get unencrypted connection, when you type a domain in the URL bar.
Second is it reasonable to assume a certificate is trusted and therefor the connection is secure, because it’s signed by one of the 9001 trusted CAs?
I tried in Firefox, but it seems there is no wildcard support. It will be a bit annoying if I have lots of internal domains without HTTPS behind a VPN.
Hi, I’ve worked on this feature on and off and I’d be interested to hear more about your setup.
Do these internal hosts use public IP space? If not, Firefox implements an exception for local IP addresses. For IPv4 that resolves to 10/8 prefix (RFC 1918), 172.16/12 prefix (RFC 1918), 192.168/16 prefix (RFC 1918), 169.254/16 prefix (Link Local - for IPv6 it’s fc00::/7 (Unique Local Address) and fe80::/10 (Link Local Address).
Did you consider using a wild-card HTTPS certificate for all your internal hostnames? I suppose you discarded this approach, but it would be interesting to hear why :)
Do you have a fixed list of hostnames that you could enumerate? If so, would your use case be fixed by some sort of preference that would take a comma-separated list of hostnames? Internally, we’ve implemented storing site exceptions at the origin level (and as a “permission”, rather than in a pref), which makes site-wide or wildcard exceptions a bit tricky, but that’s merely an implementation choice…
Thanks for your reply.
No. These internal hosts mostly point to 172.16/12.
One of my typical use cases is that I need to access WebSVN (svn.company-name.ad, points to 172.31.x.y, without HTTPS support). If I have not added it to the HTTPS-only mode exception, it will raise a warning.
To be honest, this is the thing I cannot control :-( And I don’t think other teams in my company have enough resources to do this.
From my perspective, it would be much better if Firefox could take a comma-separated list. Usually, I have 20-30 internal hosts (same suffix) I would visit on my typical weekdays. Of course, I can add them one by one when it shows a warning, but I think there is a room for UX improvement :)
Out of curiosity, when I used the HTTPS Everywhere extension, why didn’t it raise a warning when I opened an internal host without HTTPS encryption?
Re 1) Can you make sure that
dom.security.https_only_mode.upgrade_localis flipped to false in about:config? Firefox should treat IP addresses in 172.16/12 as local according to https://searchfox.org/mozilla-central/rev/32ca4fc265150e7d3d7aa6c6abea088768cf024b/dom/security/nsHTTPSOnlyUtils.cpp#747. Weird.Re 2) Fair enough
Re 3) No idea how HTTPS Everywhere did it..
Yes - it is unmodified (
falseby default).I tried to open a new private window and access the internal host, but no luck.