Re: SSL Certs for Malicious Websites

2016-05-25 Thread Richard Z
On Wed, May 25, 2016 at 11:54:50AM -0400, Eric Mill wrote:
> On Wed, May 25, 2016 at 9:50 AM,  wrote:
> 
> >
> > Why should CAs delegate to or rely on browsers for this type of user
> > protection?  Isn't it better for CAs to remain involved by revoking certs /
> > refusing to issue certs to known bad sites, like CAs have done for at least
> > the past 8 years - why change that now?  Why can't both CAs and browsers
> > work together for maximum user protection?
> >
> 
> Because users use browsers (and choose them). Users don't choose what
> certificates or CAs sites use. So users have no recourse if the CA is
> taking an inappropriate action, and no strong market signal gets sent to
> CAs about the appropriateness of their actions.

users do choose what CAs they use (or rather trust). On every new install
I spend a few minutes reviewing CAs and disabling several dozens of those
which I will never miss.

Richard

-- 
Name and OpenPGP keys available from pgp key servers

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SSL Certs for Malicious Websites

2016-05-25 Thread Richard Z
On Wed, May 25, 2016 at 01:09:53AM -0700, Ryan Sleevi wrote:
> On Tue, May 24, 2016 at 10:25 AM,   wrote:
> > Here's my question -- what do Google and Microsoft do with such reports?  
> > Do they investigate and then put a site on the "bad" list, eg, for 
> > injecting malware?  If not, then no one will stop the malware site.  If yes 
> > -- what criteria does Google (and Microsoft, etc.) use to put the site on 
> > your bad list?
> 
> https://www.microsoft.com/security/portal/mmpc/shared/objectivecriteria.aspx
> https://www.google.com/transparencyreport/safebrowsing/faq/?hl=en#how-do-you-determine-that-a-site-is-unsafe
> 
> > It seems the problem of "what is malware, what is phishing, what is abuse" 
> > must be decided by someone.  My opinion is that CAs at least have to try 
> > (set up a meaningful process, and respond to complaints by following the 
> > process, and in some cases revoking), and not just defer all action to 
> > browsers.
> 
> Unsurprisingly, I disagree. We're debating whether the ability to have
> encryption - which provides an incredibly value service against
> network level attackers - should be coupled with trust.

imho it is debattable whether https-everywhere is worth any tradeoffs 
in CA requirements. If any criminal can easily get EV certificates what
is the point of https?

>  Coupling
> certificates to this can do greater HARM than good - imagine a
> download site that provides general purpose file hosting from users,
> and one user happens to upload malware. If you revoke that
> certificate, you introduce active harm to all the good files being
> downloaded.

How is any harm done here - with or without certificate you have not 
the slightest assurance that any of the files is "good"?

However, when visiting my home-banking site I indeed want the assurance
that the site owning the EV certificate takes full responsibility
for all content.

> Further, the distinction between "Why is it different from browsers"
> is the ability for the end user to have choice. The end user can't
> change the site's certificate.

You can choose to accept any certificate of any site if you think
you want to trust the site whether or not it has been issued by a CA. 
One of my banks did deliberately provide a self signed certificate
(without any CA validation) and asked customers to verify the certificate 
by comparing the fingerprint with a hardcopy sent by surface mail.

Richard

-- 
Name and OpenPGP keys available from pgp key servers

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SSL Certs for Malicious Websites

2016-05-21 Thread Richard Z
On Thu, May 19, 2016 at 05:20:07PM +1000, Matt Palmer wrote:
> On Tue, May 17, 2016 at 11:14:21PM +0200, Richard Z wrote:
> > There are crime friendly providers already and having crime friendly CAs is 
> > something that users would definitely notice.
> 
> Why?  Do users typically notice the crime friendly hosting providers?

they do. You can argue that in absence of crime friendly providers the
criminals have other methods but having rogue providers certainly
makes their business easier.

There should be some reasonable middle ground. CAs can not be responsible 
for the contents served by their clients servers. However, CAs also must 
not knowingly or by gross negligence support malicious operations.

Richard

-- 
Name and OpenPGP keys available from pgp key servers

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SSL Certs for Malicious Websites

2016-05-19 Thread Richard Z
On Tue, May 17, 2016 at 01:04:28AM +, Charles Reiss wrote:
> On 05/16/16 12:22, Richard Z wrote:
> >On Sun, May 15, 2016 at 05:43:39PM -0700, Peter Bowen wrote:
> >
> >>Some CAs may choose to not issue to sites known to inject malware, but
> >>this outside the scope of the SSL requirements.  The EV Guidelines it
> >>very clear that the reputation and actions of the Subject are not in
> >>scope:
> >
> >knowingly issuing/tolerating certificates for sites known to inject
> >malware is
> >* contrary to user expectaions
> >* possible case of criminal felony and a liablility issue
> >
> >So irrespective of what EV Guidelines say there may be other common
> >sense reasons to require revocation of such certificates and I would
> >not want Mozilla to underbid the already minimalistic security
> >promise of TLS.
> >
> >Having an identity established by EV is nice but in most cases of
> >malware attacks the user has no chance to examine this identity if
> >the attack comes in an injected iframe.
> 
> Do you think revoking certificate from malware-injecting sites would have or
> has had meaningful effects on the security received by users?
> 
> I'd note that, even with OCSP hard-fail (not default), revocation takes at
> least the duration of OCSP response validity to reliably take effect, often
> 1 week.
> 
> Even if it did not, CAs seem to be in a very poor position to evaluate
> whether sites are serving malware (compared to, say, browser vendors who run
> programs like the Google Safe Browsing list) or to have nuanced responses to
> tricky cases, like shared web hosts or advertising networks who have some
> customers which are serving malware.

the point is if mozilla would say "we don't care the least if certificates are 
used for illegal or malicious purposes as long as the identity is established" 
it might actually encourage some CAs to search for new business models.
There are crime friendly providers already and having crime friendly CAs is 
something that users would definitely notice.

Richard

-- 
Name and OpenPGP keys available from pgp key servers

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SSL Certs for Malicious Websites

2016-05-16 Thread Richard Z
On Sun, May 15, 2016 at 05:43:39PM -0700, Peter Bowen wrote:

> Some CAs may choose to not issue to sites known to inject malware, but
> this outside the scope of the SSL requirements.  The EV Guidelines it
> very clear that the reputation and actions of the Subject are not in
> scope:

knowingly issuing/tolerating certificates for sites known to inject 
malware is
* contrary to user expectaions
* possible case of criminal felony and a liablility issue

So irrespective of what EV Guidelines say there may be other common
sense reasons to require revocation of such certificates and I would
not want Mozilla to underbid the already minimalistic security
promise of TLS.

Having an identity established by EV is nice but in most cases of 
malware attacks the user has no chance to examine this identity if 
the attack comes in an injected iframe.

Richard

-- 
Name and OpenPGP keys available from pgp key servers

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy