[HTTPS-Everywhere] what does HTTPS-Everywhere consider a "valid" X.509 certificate? [was: Re: Custom rules]

Mike Perry mikeperry at fscked.org
Wed Oct 20 05:26:02 PDT 2010


We're wandering way off-topic here. HTTPS-Everywhere has no interest
in altering the default certificate acceptance behavior of Firefox.

If someone writes a patch that allows users to easily disable/enable
rules that force HTTPS for sites with certs that don't match common
names and/or require non-standard CAs or alternate trust models, we
will accept that patch. We also will accept specially flagged rules
after that patch is implemented, tested, reviewed and merged. We will
even allow said patch to automatically enable these rules if a 3rd
party certificate verification addon such as Perspectives is
installed, or if it is possible to automatically detect alternate
trust models.

But we will never accept patches to change how the browser deals with
certificates or certificate errors. This is outside of our scope, and
unexpected behavior as well. I would suggest you take these types of
proposals to addons/projects that are more directly involved in the
certificate management process.

Thus spake Eitan Adler (lists at eitanadler.com):

> Given that there is absolutely no security lost in my proposal I
> assume that either a) I am not understanding the reason for the
> opposition to the proposal or b) my proposal is not being understood
> correctly.
> 
> I will try to clarify my proposal - and if this is what others are
> opposed can you please clarify why.
> 
> In cases where a user makes a HTTP (not secure) connection and a safe
> HTTPS connection can not be guaranteed (ie the certificate is self
> signed) there should be an option for the browser to transparently
> connect using HTTPS but not offer any indication that it is making a
> "secure" connection (because that might be a lie).
> 
> The user has no expectation of security and the user is not being
> mislead into believing (s)he is secure. However you have successfully
> raised the bar for the attacker and encrypted otherwise unencrypted
> communication.
> 
> Note that this does not affect situations where the user believes he
> is secure nor does it affect situations where the user attempts a
> httpS request but it fails due to having a bad certificate.
> 
> On Tue, Oct 19, 2010 at 7:51 PM, Eitan Adler <lists at eitanadler.com> wrote:
> > ....
> >> Stated another way, all our locks are bump-keyable. Here's your bump key:
> >>
> >
> > Do you not use locks on your doors?
> >
> >
> > --
> > Eitan Adler
> >
> 
> 
> 
> -- 
> Eitan Adler
> _______________________________________________
> HTTPS-everywhere mailing list
> HTTPS-everywhere at mail1.eff.org
> https://mail1.eff.org/mailman/listinfo/https-everywhere

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20101020/4bbb6008/attachment.sig>


More information about the HTTPS-everywhere mailing list