[HTTPS-Everywhere] new ruleset style guide is less secure

Mon Mar 23 16:56:48 PDT 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/23/2015 04:48 PM, sjw at gmx.ch 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.