On 30/05/14 18:53, Joshua Cranmer wrote:
Forgive me, but that sounds like I'm going to propose a solution with
one glaring flaw that has always sunk it in the past, and then gloss
over that flaw by saying 'I don't have the security experience - someone
else fix it'.
Actually, that is
On (2014年05月29日 23:01), Mike Hoye wrote:
On 2014-05-28, 9:07 PM, Joshua Cranmer wrote:
Two more possible rationales:
1. The administrator is unwilling to pay for an SSL certificate and
unaware of low-cost or free SSL certificate providers.
2. The administrator has philosophical beliefs
On 29/05/14 07:01, Mike Hoye wrote:
It's become clear in the last few months that the overwhelmingly most
frequent users of MITM attacks are state actors with privileged network
positions either obtaining or coercing keys from CAs,
I don't think that's clear at all. Citation needed.
I think
On 28/05/14 17:49, Joshua Cranmer wrote:
* Insufficiently secure certificate (e.g., certificates that violate
CA/Browser Forum rules or the like. I don't know if we actually consider
this a failure right now, but it's a reasonable distinct failure class
IMHO)
We would refuse e.g. a cert
On 5/30/2014 12:00 PM, Gervase Markham wrote:
On 28/05/14 17:49, Joshua Cranmer wrote:
We have an excellent chance to try to rethink CA infrastructure in this
process beyond the notion of a trusted third-party CA system (which is
already more or less broken, but that's beside the point). My
On 2014-05-28, 9:07 PM, Joshua Cranmer wrote:
Two more possible rationales:
1. The administrator is unwilling to pay for an SSL certificate and
unaware of low-cost or free SSL certificate providers.
2. The administrator has philosophical beliefs about CAs, or the CA
trust model in general,
On Thursday, May 29, 2014 1:30:20 AM UTC+3, somb...@gmail.com wrote:
We do want
all users to be able to access their email, but not by compromising the
security of all users. ...
This decision was made based on a risk profile of ...
So it looks like we know well enough what the best approach
Seems like we will have to implement some sort allow invalid certs (it makes
me really sad that the system administrators and/or managers of tcl and
telefonica seem
slow to understand the risks of allowing MITM for user credentials).
I like Brian Smith's proposal to add some visual indicator
On 05/28/2014 09:30 PM, Brian Smith wrote:
On Wed, May 28, 2014 at 5:13 PM, Andrew Sutherland
I agree this is a safe approach and the trusted server is a significant
complication in this whole endeavor. But I can think of no other way to
break the symmetry of am I being attacked or do I just
On Thu, May 29, 2014 at 2:03 PM, Andrew Sutherland
asutherl...@asutherland.org wrote:
This is a good proposal, thank you. To restate my understanding, I think
the key points of this versus the proposal I've made here or the variant in
the https://bugzil.la/874346#c11 ISPDB proposal are:
*
On 05/29/2014 07:12 PM, Brian Smith wrote:
On Thu, May 29, 2014 at 2:03 PM, Andrew Sutherland
asutherl...@asutherland.org wrote:
It seems like you would be able to answer this as part of the scan of the
internet, by trying to retrieve the self-hosted autoconfig file if it is
available. I
On 05/28/2014 06:30 PM, Andrew Sutherland wrote:
== Proposed solution for exceptions / allowing connections
There are a variety of options here, but I think one stands above the
others. I propose that we make TCPSocket and XHR with mozSystem take
a dictionary that characterizes one or more
Regarding the current certificate exception mechanism:
* there is only a single certificate store on the device and therefore
that all exceptions are device-wide
This is an implementation detail - it would not be difficult to change
exceptions to per-principal-per-app rather than just
Thanks for the overview of a real problem, Andrew.
(I recall having to add an exception for a Mozilla Root CA to
access email at one time.)
Andrew Sutherland writes:
I propose that we use a certificate-observatory-style mechanism to
corroborate any invalid certificates by attempting the
Andrew,
Le 29 mai 2014 à 09:13, Andrew Sutherland asutherl...@asutherland.org a écrit
:
My imagined rationale for why someone would use a self-signed certificate
amounts to laziness.
being one of those persons using a self-signed certificate, let's enrich your
use cases list ;)
I use a
On 05/28/2014 07:22 PM, Karl Tomlinson wrote:
(I recall having to add an exception for a Mozilla Root CA to
access email at one time.)
It's fairly common that there exist multiple aliases to access a mail
server but the server does not have certificates available for all of
them. In the
On 5/28/2014 5:30 PM, Andrew Sutherland wrote:
tl;dr: We need to figure out how to safely allow for invalid
certificates to be used in the Firefox OS Gaia email app. We do want
all users to be able to access their email, but not by compromising
the security of all users. Read on if you work
On 05/28/2014 08:37 PM, Karl Dubost wrote:
Le 29 mai 2014 à 09:13, Andrew Sutherland asutherl...@asutherland.org a écrit
:
My imagined rationale for why someone would use a self-signed certificate
amounts to laziness.
being one of those persons using a self-signed certificate, let's enrich
Andrew,
Le 29 mai 2014 à 09:50, Andrew Sutherland asutherl...@asutherland.org a écrit
:
Trusting you as a human doesn't translate into protecting the users of your
server from man-in-the-middle attacks.
How do you translate the human trust into the technical trust infrastructure
supported
On 5/28/2014 7:13 PM, Andrew Sutherland wrote:
My imagined rationale for why someone would use a self-signed
certificate amounts to laziness. (We've been unable to determine what
the rationale is for using invalid certificates in these cases as of
yet.) For example, they install dovecot on
On 05/28/2014 06:01 PM, Karl Dubost wrote:
Andrew,
Le 29 mai 2014 à 09:50, Andrew Sutherland asutherl...@asutherland.org a
écrit :
Trusting you as a human doesn't translate into protecting the users of your
server from man-in-the-middle attacks.
How do you translate the human trust into
On Wed, May 28, 2014 at 5:13 PM, Andrew Sutherland
asutherl...@asutherland.org wrote:
On 05/28/2014 07:16 PM, David Keeler wrote:
* there is only a single certificate store on the device and therefore
that all exceptions are device-wide
This is an implementation detail - it would not be
Le 29 mai 2014 à 10:25, David Keeler dkee...@mozilla.com a écrit :
But without verifying that the certificate they received is the
certificate you created, those users are open to attack.
agreed.
My intent in the discussion is NOT Let's not verify the certificate is valid
but to allow the
23 matches
Mail list logo
