On Wed, 11 Apr 2012 00:54:53 -0700 Jesse Ruderman wrote: > 1) If a site sends an STS header
In my opinion STS shouldn't be implemented professionally in it's current state and with browsers treatment of valid dates. I looked to implementing it and then realised that a user with a flat bios battery (such as my mate) would be given DOS to my websites due to an incorrect date and so certificate. I mailed an RFC maintainer but he saw that as a users problem to fix. My mate would have no idea where to get that battery from, never mind fit it unless I found the time and helped him. There must be thousands if not millions like him. SSL needs fixing properly with far less CAs. MITM shouldn't occur but users should be protected as much as possible from it as it is a rediculously possible occurence against the majority. A valid certificate for a different site could also easily fool a user anyway. Maybe (though I think SSL should be fixed at source by controlling cert issue better and only by domain validation as it costs little more to forge a company), accessing a non initially physically user interacted ssl domain could throw a warning across the board (such as redirects), blocking would likely break some sites and maybe email links. > When clearing history, retain the STS bit I can see that being abused for tracking. > When connected to an untrusted wireless network For known untrusted networks it's less of an issue, with hardware keyloggers being a greater risk as things like comodo firewall and various other intenet services or home servers do/can provide VPNs. I don't use the pass manager or form filler except when testing sites, but they seem like reasonable ideas. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
