Users will want to see which hosts have an STS state in their profile, and also may want to clear the state of some or all of the STS hosts. We should implement a UI that lets them add hosts (with no expiration) and also view/delete existing hosts with STS permissions. See attached image for an example of the UI as implemented in the ForceTLS add-on.

Initial whack at a patch. This adds UI like the one in attachment 452010 [details], and also adds a line to the site permissions tab in the page info dialog.

Fixed a few bugs.

The goal of the work in bug 573176 and its followups is to remove most of those old-style manager interfaces, so perhaps this would be better integrated into about:permissions.

(In reply to comment #3) > The goal of the work in bug 573176 and its followups is to remove most of > those old-style manager interfaces, so perhaps this would be better > integrated into about:permissions. I completely agree: we should work this into the about:permissions UI. Making this block that about:permissions meta bug.

Adding Boriss to the cc list for design work. This is also something we may want to talk about in bug 658097.

Sid, I looked at this patch to start to figure out what I would need to do to include STS in about:permissions. I tried looking in MXR for sts/forcehttps and sts/includeSubdomains, but I couldn't find them, and instead I found sts/use and sts/subd. Did the strings for the permissions change since this patch was written? Are there any other changes I need to take into account? Boriss, I'm thinking this permission pref would be better represented as a checkbox, rather than a menulist. Thoughts on that? We'd need to vary the UI pattern anyway if we add a way to flip the subdomain permission as well.

(In reply to comment #6) > Sid, I looked at this patch to start to figure out what I would need to do > to include STS in about:permissions. I tried looking in MXR for > sts/forcehttps and sts/includeSubdomains, but I couldn't find them, and > instead I found sts/use and sts/subd. Did the strings for the permissions > change since this patch was written? Are there any other changes I need to > take into account? Yes, that patch is stale, sorry. I've uploaded a new one that is less stale, though may not apply cleanly to trunk.

I should add that the patch in attachment 534842 [details] [diff] [review] updates the nsIStrictTransportSecurityService.idl interface to help the UI set HSTS state without fiddling with permissions. This is important since HSTS has to respect private browsing mode (which the permission manager does not) and making that transparent to all who use the HSTS interface makes life easier.

See also bug 685405, "Add strict-transport-security indicator to Larry".

Unfortunately, even though v3.01 chrome://forcetls/content/firstrun.html claims it would visualize the HSTS in permissions, I don't see them there :( FF v16.0.2

it seems that my server properly sends the header?

Ralf: Did you apply the patch in this bug before checking? This isn't in Firefox yet (and the patch is kind of old, so perhaps it doesn't work anymore.

apologies for not being clear. On http://forcetls.sidstamm.com/ I read: <<Firefox 4+ Users: ... If you want the Force-TLS User Interface and the ability to manually force sites, the newest version (3.0.1) of Force-TLS will do that for you.>> So, since the patch isn't part of the trunk yet, I thought that I can see whether the site is HSTS already now without patching. The good news is that after a couple of firefox restarts, my server's headers are now detected as well. Great.

Oh, I see. You installed the force-tls add-on. Maybe *that add-on* is broken. Send an email to forcetls@sidstamm.com with a bug report (there's currently no UI for this built into Firefox).

Wikimedia is not going to send HSTS with a long max-age unless this is fixed, it's too risky. If some government blocks HTTPS connections to us, what can we tell the affected users other than "don't use Firefox"?

(In reply to Tim Starling from comment #15) > Wikimedia is not going to send HSTS with a long max-age unless this is > fixed, it's too risky. If some government blocks HTTPS connections to us, > what can we tell the affected users other than "don't use Firefox"? "Clear Recent History" -> "Site Preferences" works for now.

(In reply to Tim Starling from comment #15) > Wikimedia is not going to send HSTS with a long max-age unless this is > fixed, it's too risky. If some government blocks HTTPS connections to us, > what can we tell the affected users other than "don't use Firefox"? How about the following? "Your access to Wikimedia services is being tampered with or otherwise censored by an unknown attacker. We chose to protect your privacy by design and have ensured that the secure web services of Wikimedia will fail in a closed manner. This ensures that attackers will be detected but in some cases, they may thwart your access to the largest collection of human knowledge ever created and made freely available. You may wish to consider using an anonymizing service to access the Wikimedia services you desire to reach. It is unknown what this attacker may do with your reading list or by monitoring your editing habits. We hope you'll think carefully about your situation and to understand the risks in your environment as we certainly cannot do this for you. You may access this service insecurely at http://we.are.under.surveillance.wikipedia.org at your own risk." If you do happen to have a side channel to talk to your users, I suppose it would be useful to teach them about the things they need to know in order to solve their larger problems. Firefox isn't the problem here - surveillance and censorship is the problem. Passing the buck to reduce support costs or issues is also a problem but one that may be solved by the Wikimedia and Wikipedia community. I'd like Wikimedia to support strong privacy protections for all of their users by default. The fact that some places somewhere might censor is a poor reason to not try to protect everyone else, everywhere. Teaching users to remove the security properties that Firefox brings to the table is pretty awful. Unless you also teach those people about surveillance, censorship and the reasons that networks spy on those users, it seems rather dangerous actually. On another note - a UI for HSTS would be a welcome addition. To see which sites are actually interested and actively engaged in using Firefox supported privacy and security enhancement is a useful improvement.

(In reply to Jacob Appelbaum from comment #17) > On another note - a UI for HSTS would be a welcome addition. To see which > sites are actually interested and actively engaged in using Firefox > supported privacy and security enhancement is a useful improvement. That use case might be better served by bug 711816.

I have three concerns about a checkbox labeled "Always access content from this site securely": 1) It sounds like a great thing (why would I *not* check it?) but it breaks most sites. 2) Unchecking and rechecking it may confusingly turn a time-limited site-requested STS into a permanent user setting. 3) It's not clear whether the permanent user setting will be cleared by "Clear Recent History" -> "Site Preferences".

(In reply to Jesse Ruderman from comment #19) > I have three concerns about a checkbox labeled "Always access content from > this site securely": > > 1) It sounds like a great thing (why would I *not* check it?) but it breaks > most sites. What does break mean in this case? Perhaps it can fail in a graceful way that teaches the user about the kind of failure? If it was intentional censorship, I'd say that is a security success and a web browsing failure in one. If it is the case that the site can't be accessed securely, it suggests that the box shouldn't be available without an active probing or some kind of (gah) wizard. > > 2) Unchecking and rechecking it may confusingly turn a time-limited > site-requested STS into a permanent user setting. Perhaps there can be a clock to keep state for such a thing? > > 3) It's not clear whether the permanent user setting will be cleared by > "Clear Recent History" -> "Site Preferences". If a user forces it - shouldn't it be "Clear Recent History" -> "User Site Security Preferences" rather than being buried inside of Site Preferences?

User-triggered STS would prevent individual pages from working properly if they (1) are not available over SSL, or (2) have mixed active content when loaded over SSL. Firefox can't know if the entire site will work correctly by probing a single URL.

(In reply to Jesse Ruderman from comment #21) > User-triggered STS would prevent individual pages from working properly if > they > (1) are not available over SSL, or Agreed. > (2) have mixed active content when loaded over SSL. Also, the different kinds of content seem to matter - ie: javascript over http? no thanks. css? no thanks. Oh actually, everything that comes in over HTTP is a nightmare. I think port 80 - as in unencrypted, unauthenticated, and likely to be the subject of tampering is from an era long gone. > > Firefox can't know if the entire site will work correctly by probing a > single URL. There may be a way to learn over time and mixed content on the front page is a dead give away. It wouldn't be perfect but it might be useful.

(In reply to Jacob Appelbaum from comment #17) > How about the following? > > "Your access to Wikimedia services is being tampered with or otherwise > censored by an unknown attacker. We chose to protect your privacy by design > and have ensured that the secure web services of Wikimedia will fail in a > closed manner. This ensures that attackers will be detected but in some > cases, they may thwart your access to the largest collection of human > knowledge ever created and made freely available. You may wish to consider > using an anonymizing service to access the Wikimedia services you desire to > reach. It is unknown what this attacker may do with your reading list or by > monitoring your editing habits. We hope you'll think carefully about your > situation and to understand the risks in your environment as we certainly > cannot do this for you. You may access this service insecurely at > http://we.are.under.surveillance.wikipedia.org at your own risk." That kind of moralizing might start to grate after a while. You know, "Hello people of Syria, we Americans have an important message for you. Your government is invading your privacy and that is bad! You should do something about it!" (Syria have actually blocked us before.) Sometimes people just want to get their homework done, and don't want to attract a knock at the door by googling for censorship circumvention keywords. But yes, changing the domain name is a possibility, although it is somewhat more complicated on the server side. And in the absence of a reliable side channel, it would be more difficult for users to discover the new domain name than to work out how to access the old one. (In reply to Jesse Ruderman from comment #19) > I have three concerns about a checkbox labeled "Always access content from > this site securely": I would have thought something along the lines of a link or button labelled "clear saved security settings" would be the way to go, perhaps placed after a description of what the security settings are (whether HTTPS mode is forced, expiry time, any other STS header options that are worth telling the user about).

I wish there was a better way to manage this setting per site. I currently use the settings in Larry but that only helps for site's I've already visited whereas I want to be able to import my list of sites I know to support it beforehand. The biggest issue I have is for sites that don't let you connect to their base domain like example.com and redirect you to the sub-domain www.example.com. They use other sub-domains too but since I can't go to example.com and check the boxes to always connect securely and on sub-domains too I have to verify every sub-domain which is problematic because most times the sub-domain isn't displayed in the address bar but embedded in content on the page.

This would be really great for projects like HTTPS-Everywhere.

See Also: Bug 1334048