On 02/15/2015 08:25 AM, [email protected] wrote: > But the browser ties to reconnect using 'www.host.TLD'. Should we let > the browser do this redirect itself (and redirect again to https) or > should we overwrite this redirect and directly connect to 'https://www.'? If a target host doesn't answer on port 80, or the name doesn't exist, we shouldn't include it in the ruleset. We don't expect that there will be links on the web to the nonexistent host, so we don't lose much in terms of ability to rewrite URLs. > Another problem that I found are incomplete certificate chains. The > browser correct them with an extra download, but > https-everywhere-checker returns: 60, 'SSL certificate problem: unable > to get local issuer certificate' > > This should return a warning instead of an error. Good point! I think we are also missing some of the most current certificates from Firefox, which I plan to update: https://support.google.com/dfp_sb/answer/2524536?hl=en. If we still have issues after updating those, we may want to install the transitive closure of those certificates, from the SSL Observatory.
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
