Nice explanation of how STS works; I’ll consider that when I get my own HTTPS-enabled website. By the way, I don’t understand why the STS header can’t specify a more general host (like *.<a href="http://example.com">example.com</a>), nor why it needs to expire at all.<br>
<br>My discussion of <a href="http://secure.eff.org" target="_blank">secure.eff.org</a> is obviously about those cases where HTTPS Everywhere is not being used or the EFF rule is not enabled, in which case STS should do the job instead, but won’t in this case. Since the EFF is a big believer in STS, why don’t they make it work?<br>
<br>As for the certificate errors, rules like:<br><br><rule from="^https?://(de-de|www\.)?facebook\.de/" to="<a href="https://www.facebook.com/">https://www.facebook.com/</a>"/><br><br>help to avoid certificate errors when a request like<br>
<br><a href="https://de-de.facebook.de/">https://de-de.facebook.de/</a><br><br>is generated by something else (besides HTTPS Everywhere). (<a href="http://de-de.facebook.de">de-de.facebook.de</a> uses a certificate that’s only trusted for <a href="http://facebook.com">facebook.com</a>) I’m arguing that we should be more actively encouraging the writing of rules like this (Admittedly I haven’t found any built-in rulesets where this applies and hasn’t already been done, but it does apply to Adobe, for one.).<br>
<br><div class="gmail_quote">On Thu, Dec 30, 2010 at 0625 (UTC-8), <span dir="ltr"><<a href="mailto:https-everywhere@lists.grepular.com" target="_blank">https-everywhere@lists.grepular.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>On 30/12/2010 0556 (UTC-8), Drake, Brian wrote:<br>
<br>
[snip]<br></div>
<br>
> Therefore, if STS is disabled on <a href="http://secure.eff.org" target="_blank">secure.eff.org</a> <<a href="http://secure.eff.org" target="_blank">http://secure.eff.org</a>>,<br>
<div>> then that domain is open to all the problems of not using HTTPS at all;<br>
> if it is enabled, then <a href="http://secure.eff.org/wiretapping" target="_blank">http://secure.eff.org/wiretapping</a> (for example)<br>
> will be rewritten to <a href="https://secure.eff.org/wiretapping" target="_blank">https://secure.eff.org/wiretapping</a> and fail (except<br>
> for users using HTTPS Everywhere or some other rewriting software!).<br>
<br>
</div>HTTPS-Everywhere usually negates the need for STS for sites with<br>
rulesets. You will not visit a http version of the site in the first place.<br>
<div><br>
> The other changes to rulesets are, in some cases, “micro-optimisations”;<br>
> in other cases, they avoid certificate errors. Avoiding certificate<br>
> errors seems like something we should pursue more actively, at least by<br>
> adding a note to the ruleset-writing instructions and any other<br>
> appropriate place.<br>
<br>
</div>I believe all the existing rulesets which are enabled by default do not<br>
have any certificate errors. That is how it is *supposed* to be anyway.<br>
There are a few rules which generate certificate errors but they are set<br>
to disabled by default.<br>
<div><div></div><div><br>
--<br>
Mike Cardwell <a href="https://secure.grepular.com/" target="_blank">https://secure.grepular.com/</a> <a href="https://twitter.com/mickeyc" target="_blank">https://twitter.com/mickeyc</a><br>
Professional <a href="http://cardwellit.com/" target="_blank">http://cardwellit.com/</a> <a href="http://linkedin.com/in/mikecardwell" target="_blank">http://linkedin.com/in/mikecardwell</a><br>
<a href="http://PGP.mit.edu" target="_blank">PGP.mit.edu</a> 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F<br>
_______________________________________________<br>
HTTPS-everywhere mailing list<br>
<a href="mailto:HTTPS-everywhere@mail1.eff.org" target="_blank">HTTPS-everywhere@mail1.eff.org</a><br>
<a href="https://mail1.eff.org/mailman/listinfo/https-everywhere" target="_blank">https://mail1.eff.org/mailman/listinfo/https-everywhere</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Brian Drake<br><br>Alternate (slightly less secure) e-mail: <a href="mailto:brian@drakefamily.tk" target="_blank">brian@drakefamily.tk</a><br>Alternate (old) e-mail: <a href="mailto:brianriab@gmail.com" target="_blank">brianriab@gmail.com</a><br>
<br>Facebook profile: <a href="https://ssl.facebook.com/profile.php?id=100001669405117" target="_blank">Profile ID 100001669405117</a><br>
Twitter username: <a href="https://twitter.com/BrianJDrake" target="_blank">BrianJDrake</a><br>Wikimedia project username: <a href="https://secure.wikimedia.org/wikipedia/meta/wiki/User:Brianjd" target="_blank">Brianjd</a> (been inactive for a while)<br>
<br>All content created by me Copyright © 2010 Brian Drake. All rights reserved.<br><br>