Spun-off from bug 413630... Web-based protocol handlers that we ship by default should use https:// when possible. Otherwise they may become a tempting attack vector for evil-doers on public networks. (eg sniffers, DNS redirects, etc.) Protocol handlers that can result in an authentication page (eg, mailto --> a Gmail login) should probably require SSL. Other uses should base SSL requirements on a balance of security, server-side performance, the likelyhood private data will be exchanged, perception of Firefox as "secure by default", how the web service might already be used, etc.

According to the security review, http://wiki.mozilla.org/User:Dmose:Protocol_Handler_Security_Review, this is not a requirement.

I think the part you're talking about is: "a problem, but not of the magnitude of add-on downloads, because this code doesn't execute locally with privs. Decided to continue to allow handler sites to determine whether or not to require SSL." That seems to be talking in regards to the risk of allowing a web site to install a non-SSL protocol handler URL. And that's fine, there are reasonable use cases for protocol handlers without SSL What I'm saying in this bug, though, is that for handlers we *ship* with we should require SSL when appropriate.

I'm perfectly fine with *wanting* them to be https, and in fact I try to do that. But it's not a requirement from my point of view.

Which of them support it at the moment? Can we get a quick patch whipped up? Axel: is your point that we needn't cause all the localizers to do this work? I'm happy for this to be an en-US only thing, but if, f.e., GMail supports us using their https:// address, we should definitely do it.

I can see both sides of this: on the one hand, it would be a non-zero improvement in security. On the other hand, if the ISP isn't using https as their main entry point in normal usage their users are already fairly exposed, and this wouldn't change that. Last I heard (a year or three ago), Yahoo supported https as an entry point, but defaulted to http, because of the cost of setting up https connections at scale. Whether that's still true, I don't know.

My point is that we didn't communicate https as a requirement to any of our partners. Not to 30 boxes, not to yahoo, not to google, not to microsoft, not to any of our international partners. I'm all for preferably taking https URLs over http, but requiring https puts up a different level of infrastructure. And server load is different, too, as dmose pointed out. I just think we shouldn't change our messaging to potential partners a week before RC. As for en-US, we currently only have 30boxes and yahoo. Not sure about 30 boxes, CCing Manuel Deschamps for input on whether using https on compose.mail.yahoo.com is a good or not.

Yahoo Mail only uses https during the login sequence. I know that mail has tried to acquired encryption hardware for https but the price is prohibited. https://composer.mail.yahoo.com does not work. https://mail.yahoo.com will redirect you to http://mail.yahoo.com if you already have a valid session.

I think I'm with Axel here regarding the timing of making this change. We made the original decision having thought about this stuff, and I think it was a sane one. We didn't explicitly consider the idea of having our set of defaults use a more conservative policy than what was allowed in the general case. A reasonable argument can certainly be made for this, but a reasonable argument can be made for not doing it too. I don't think this is such a big deal that we should add in a new requirement at this point in the game.

(In reply to comment #7) > https://mail.yahoo.com will redirect you to http://mail.yahoo.com if you > already have a valid session. This is what I'd consider a fair compromise between security and the cost of SSL. Full-session SSL isn't needed, since it's no worse than existing usage. The session-initiation part is different, though... Users should be able to trust their browser to do the safe thing by default, and explaining how to use the feature safely would be awkward. One scenario I'm worried about is the inevitable stink someone will raise that "omg, Firefox isn't secure, hackers can steal ur passwordz!" While such a claim is overstated, the problem is that we'd be stuck without a practical workaround (other than telling people to disable the feature), we get into the mess of changing the URL of already-installed handlers, and there's the unknown of the fix being blocked on waiting for support from the provider. (In reply to comment #6) > I just think we shouldn't change our messaging to potential partners a week > before RC. Yes, that's a concern, but we shouldn't simply give up on security because of schedule pressure.

To expand on my last point a bit... There are sort of two issues here: * Should we require https urls for in-product handlers? * How do we achieve that, given our current starting point? It would not be unreasonable to adopt the first, and deal with the second with a migration plan.

(In reply to comment #9) > Full-session SSL isn't needed, since it's no worse than existing usage. > The session-initiation part is different, though... Users should be able to > trust their browser to do the safe thing by default, and explaining how to use > the feature safely would be awkward. This sounds like an oversimplification to me. The session-initiation is exactly the same as existing usage too: in the existing case, the use goes to their webmail site manually, and whether or note that uses SSL is entirely provider-dependent. So we're still at exactly the same security level as the status quo. I do agree that working towards this requirement would be an improvement on the status quo and is worth doing. > One scenario I'm worried about is the inevitable stink someone will raise that > "omg, Firefox isn't secure, hackers can steal ur passwordz!" While such a > claim is overstated, People can and will continue to make mistakes analyzing the security characteristics of browser operation. Making those decisions based on what people might think rather than based on what we believe to be reasonable analysis isn't a desirable goal, I'll assert. > the problem is that we'd be stuck without a practical > workaround (other than telling people to disable the feature) A workaround to what problem that we don't already have today? As I stated above, I believe the security characteristics of session initiation without forcing the providers to use SSL are exactly the same as manually-initiated webmail compose.

Missed string freeze, so removing late-l10n. We can do this for en-US, and get the other locales on updates if need be. cc'ing Mic: wherever possible, we should be using HTTPS for web based protocol handlers.

thanks on comment #12 (on axel's radar as well). and i believe this is also reflected in the public documentation we've been pointing providers to on mdc

Not going to block on this, we should absolutely be switching where appropriate though.

per comment #12 and #14, to be clear, we are using https wherever possible and many l10n locales will require a post RC1 update (in response to "if needs be" in comment #12, it will be needed ;) thanks.

mconnor (or anyone) can I reconfirm that we do not _require_ https?

we don't require at this point, we just strongly encourage

Raising this again for 3.1. Kaminsky's discovery of serious DNS flaws makes it all the more important that we do this.

Not going to block on this for 1.9.0.2 but we should probably block on it for 1.9.0.2. Who can own this bug?

And by 1.9.0.2, I meant 1.9.0.3 which is now 1.9.0.4. Do we have a list of which protocol handlers are currently not https (all of them?)? Separate bugs for updating each one is probably needed as we'll need Kev to clear them, I believe? Correct me if I'm wrong.

CCing Stas and Seth, that should be on their lap. The policy is, AFAICT, still as Kev pointed out in comment 17, i.e., we try to get https, but not require. Whether 'require' is the right option should probably depend on protocol, too, and on the authentication requirements on the server. 30 boxes for example let's you view an ical without logging in, so I don't necessarily see a good reason to have that go through https. mailto urls in general might be a different case, as those will require user authentication.

I agree with comment 21; it feels like encouragement but not hard blocking is the right thing to do here, especially when some of the protocol handlers might not require an exchange of user credentials. Kev: we should be strongly encouraging, though, yes.

AFAICT, the last two got fixed in bug 840699 and bug 840705.

At least for en-US. cc-ing Flod to see if we've done the same already for localizations.

(In reply to Mike Connor [:mconnor] from comment #24) > At least for en-US. cc-ing Flod to see if we've done the same already for > localizations. That's bug 994248. We have a couple of locales with pending questions, but the rest is OK.