On Tue, Jan 19, 2016 at 9:38 PM, Ryan Sleevi <
ryan-mozdevsecpol...@sleevi.com> wrote:
> On Tue, January 19, 2016 5:38 pm, Eric Mill wrote:
> > If your experience with MD5 supports the notion that removing support
> for
> > it in the enterprise hurt user security in some other way, such as
> cau
On Tue, January 19, 2016 5:38 pm, Eric Mill wrote:
> If your experience with MD5 supports the notion that removing support for
> it in the enterprise hurt user security in some other way, such as causing
> enterprises to lock their users to older versions of Chrome for a long
> period of time,
On Tue, Jan 19, 2016 at 4:15 AM, Ryan Sleevi <
ryan-mozdevsecpol...@sleevi.com> wrote:
> On Mon, January 18, 2016 9:05 pm, Eric Mill wrote:
> > Really? Given your last few years of experience, if you could time
> travel
> > back to 2012, you would tell Past Ryan Sleevi to make a different
> deci
On 19/01/2016 10:15, Ryan Sleevi wrote:
On Mon, January 18, 2016 9:05 pm, Eric Mill wrote:
Really? Given your last few years of experience, if you could time travel
back to 2012, you would tell Past Ryan Sleevi to make a different decision
at that time about adding a flag for MD5 support i
On Mon, January 18, 2016 9:05 pm, Eric Mill wrote:
> Really? Given your last few years of experience, if you could time travel
> back to 2012, you would tell Past Ryan Sleevi to make a different decision
> at that time about adding a flag for MD5 support in the enterprise?
Yes.
> Was there sig
On Mon, Jan 18, 2016 at 11:24 PM, Ryan Sleevi <
ryan-mozdevsecpol...@sleevi.com> wrote:
>
> > There isn't in Chrome, and here's the bug thread where the
> > Chrome team denied fervent requests by someone behind an enterprise
> > firewall to add MD5 support in behind a command line flag:
>
> That
On Mon, January 18, 2016 7:20 pm, Eric Mill wrote:
> I was suggesting not deciding a year ahead of time that enterprise apathy
> will be too overwhelmingly powerful to even try pushing on, in the
> specific
> case of SHA-1 deprecation.
Chrome has already decided this, as has (in effect) Micros
On Mon, Jan 18, 2016 at 8:46 PM, Ryan Sleevi <
ryan-mozdevsecpol...@sleevi.com> wrote:
Because of this, anyone who has ever supported enterprise software is
> aware of the all too present necessity for enterprise flags. That is,
> off-by-default configuration flags that can change or alter behavio
On Mon, January 18, 2016 12:26 pm, Eric Mill wrote:
> On Mon, Jan 18, 2016 at 10:19 AM, Richard Barnes
> wrote:
>
> > ...
> >
> > One thing that has been proposed is to have an exception for local
> > roots,
> > i.e., to let non-default trust anchors continue to use SHA-1 for some
> > more
> > t
On Mon, January 18, 2016 3:01 pm, Jakob Bohm wrote:
> I was attempting to avoid the even-harder-to-debug error where behavior
> depends on how a root cert was added to the configuration.
I think you underestimate the challenges to debugging your solution proposes.
It's fairly easy to understand
On 18/01/2016 22:18, Richard Barnes wrote:
On Mon, Jan 18, 2016 at 11:07 AM, Jakob Bohm wrote:
On 18/01/2016 16:19, Richard Barnes wrote:
"Failed" might be a bit strong :) We had a temporary setback.
Like the blog post says, we're working on more precisely characterizing
how
widespread an
On Mon, Jan 18, 2016 at 3:26 PM, Eric Mill wrote:
> On Mon, Jan 18, 2016 at 10:19 AM, Richard Barnes
> wrote:
>
>> ...
>>
>> One thing that has been proposed is to have an exception for local roots,
>> i.e., to let non-default trust anchors continue to use SHA-1 for some more
>> time. What do f
On Mon, Jan 18, 2016 at 11:07 AM, Jakob Bohm wrote:
> On 18/01/2016 16:19, Richard Barnes wrote:
>
>> "Failed" might be a bit strong :) We had a temporary setback.
>>
>> Like the blog post says, we're working on more precisely characterizing
>> how
>> widespread and how broken these middleboxes
On Mon, Jan 18, 2016 at 10:19 AM, Richard Barnes
wrote:
> ...
>
> One thing that has been proposed is to have an exception for local roots,
> i.e., to let non-default trust anchors continue to use SHA-1 for some more
> time. What do folks here think about that idea?
>
That seems like a choice t
On 18/01/2016 16:19, Richard Barnes wrote:
"Failed" might be a bit strong :) We had a temporary setback.
Like the blog post says, we're working on more precisely characterizing how
widespread and how broken these middleboxes are, before taking steps to
re-enable the SHA-1 restrictions. I stil
"Failed" might be a bit strong :) We had a temporary setback.
Like the blog post says, we're working on more precisely characterizing how
widespread and how broken these middleboxes are, before taking steps to
re-enable the SHA-1 restrictions. I still think we're on track for turning
off SHA-1
We failed because of MITM certs:
https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/
But you can set security.pki.sha1_enforcement_level manually.
Am 16.01.2016 um 00:16 schrieb gdelgad...@gmail.com:
> it's early 2016 and wondering if a decision ha
it's early 2016 and wondering if a decision has been made on the dates?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
To be clear, we have not decided on any hard cutoff date for SHA-1, much
less made it July 1.
January 1, 2017 and July 1, 2016 are both options under consideration. I
expect that we will try to come to a final decision some time in early
2016, once we have more data about how quickly people seem
On Friday, November 6, 2015 at 7:15:31 PM UTC-5, Rick Andrews wrote:
> > - We are re-evaluating when we should start rejecting all SHA-1 SSL
> > certificates (regardless of when they were issued). As we said before,
> > the current plan is to make this change on January 1, 2017. However, in
>
> - We are re-evaluating when we should start rejecting all SHA-1 SSL
> certificates (regardless of when they were issued). As we said before,
> the current plan is to make this change on January 1, 2017. However, in
> light of recent attacks on SHA-1, we are also considering the
> feasibilit
On Thursday, November 5, 2015 at 3:27:45 PM UTC-5, Kathleen Wilson wrote:
> On 11/5/15 11:34 AM, s...@gmx.ch wrote:
> > It seems that we are going to untrust SHA-1 generally on July 1, 2016
> > [1]. Do we already have a bug number for this?
>
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=94251
On 11/5/15 11:34 AM, s...@gmx.ch wrote:
It seems that we are going to untrust SHA-1 generally on July 1, 2016
[1]. Do we already have a bug number for this?
https://bugzilla.mozilla.org/show_bug.cgi?id=942515
I think certificates with 'notAfter >= 2017-7-1' should get a triangle
instead of
It seems that we are going to untrust SHA-1 generally on July 1, 2016
[1]. Do we already have a bug number for this? I can't find any.
I think certificates with 'notAfter >= 2017-7-1' should get a triangle
instead of the lock icon from now.
[1]
https://blog.mozilla.org/security/2015/10/20/continui
On 2015-10-21 22:18, s...@gmx.ch wrote:
There was also a plan for certificates with 'notAfter >= 2017-1-1'
(still valid in 2017+).
Chrome already shows a broken https icon for them.
See https://sha1-2017.badssl.com/
This was discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=942515
So m
There was also a plan for certificates with 'notAfter >= 2017-1-1'
(still valid in 2017+).
Chrome already shows a broken https icon for them.
See https://sha1-2017.badssl.com/
This was discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=942515
Am 21.10.2015 um 10:17 schrieb Kurt Roeckx:
On 2015-10-20 20:39, Kathleen Wilson wrote:
- We are re-evaluating when we should start rejecting all SHA-1 SSL
certificates (regardless of when they were issued). As we said before,
the current plan is to make this change on January 1, 2017. However, in
light of recent attacks on SHA-1, we are
All,
We've posted a security blog to provide current status and direction on
phasing out SHA-1 certs:
https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/
Of particular note:
- In Firefox 43 we plan to show an overridable “Untrusted Connection”
error when
28 matches
Mail list logo
