-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/23/2015 04:48 PM, [email protected] wrote: > Before, It was easy to made rule like *.secure.example => https. Now I > would have to write a bulk of test for that. > But when I follow the guide and create foo.secure.example and > bar.secure.example I'm not protected if an attacker creates a new > subdomain evil.secure.example. With wildcard rules I would get a cert > failure, but with the new style guide the client would connect to this > side over http. (See also HSTS includeSubdomains) It is still quite easy to write a wildcard rule. Now you have to demonstrate some examples of affected subdomains: <ruleset name="Example> <target host="*.example.com" /> <test url="http://mail.example.com"; /> <test url="http://shop.example.com"; /> <test url="http://example.com"; /> <rule from="^http:" to="https:" /> </ruleset> The existing ruleset library contains rules with wildcard target hosts, but upon closer inspection many of those rules only rewrite a specific list of subdomains that are known to work. I welcome wildcard rules, provided you've done due diligence that all publicly accessible subdomains function correctly, and included all the ones you can find in your list of test URLs. > Another point are bad servers, that have only a valid cert for the www > prefix. Sadly, that's a very common case. Before it was easy to rewrite > to www, but now I have to write a test for each redirect. I think this > overkill is not planned to be the goal of the ruleset tests. Here is how I would go about writing a rule for that use case: <ruleset name="Example> <target host="*.example.com" /> <test url="http://mail.example.com"; /> <test url="http://shop.example.com"; /> <test url="http://example.com"; /> <test url="http://www.example.com"; /> * <rule from="^http://example.com/"; to="https://www.example.com"; />* <rule from="^http:" to="https:" /> </ruleset> I do appreciate the feedback: This is a tough transition for everyone, but I really think it's necessary to introduce more rigorous testing as we increase the number of rulesets. I'd be very interested in proposals to make the process of writing rulesets and tests less onerous, while also increasing the quality and testability of rulesets. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVEKg/AAoJEKczrZbVKyUhEtsQAI8O+G2cEp9HHvjk2G+ZmSEK AAwMpDfy26LZ2Ai9bqk2nxlCQjbppj+HKOM15hDlhH323s1kJ33BQxYElHGEf7pJ xEp/rz4mM3OLCjq/Gf52/YjwfyVU1ab8+oADtKBnTbN1MulXMii+WNtEcjB0sVyG VHGn7nlbSzeB189zZ8dQFDyuY9sfcPbf58GQECPNTLZBCYku+5Qz2swdiTRnY7jr 43ljQEVLeFlQQQsxEmwGRSlbrCFbvxp3LKOgD2DzA7bAbtYCz++IcZOnxtzzwYMt ugSG40t3PGlKzaKYHHWzIGEMpC3VHHJYlR8gWl2AewgkrKSq5VsAbDjPpHMTJAr+ Vl+2HixIOnbc6CyBhmFKEEzl5/GTZ0CmKBwzwKJ1xUQKW+BJO7UaKZ/k+EhrLTyq U11D0e6Yeb0oceKJ86CHnPz4AI5Fja+VXlWf1fZybVtcnDJfgtAxSm7KO+mMOWrq NjYXmwjXNjNjtC5BmDVwiNqB6eHkOctmE615yLY4vwN6bfywImpSqAGZcSl+X76s cfq/61okpvCwb0URpWqlN/uoPNNMZADJ61gDtsD+5jEyxk6Y1/rM/RbimbmoJl5n 7CYjVU06Mwgv7Pw02qFP6Xz4afIT2RJQdjDap5mAohwEY27dzu7f9jAO11/y79Hw vSsKvj8Tf+S4ldwpVlRy =OWWl -----END PGP SIGNATURE----- _______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
