It's debatable if those are actually facts but perhaps some perspective will help the conversation. I'll use this case as a launching point:* Users are, quite reasonably, focused on the viewport. After all, that's where the content is and where the task is. Many people simply never see the
Hi Richard,I was hoping to do some community organizing in here before going to the CA's individually. Some thoughts:Going to a CA and demanding (?) that they revoke certs is not a normal situation and I'm expecting some will push back. It would be advantageous to have a more unified voice to
FIDO has its shortcomings, too, and its users can be victims of phishing just as much as anyone else. All you need is the right inducement. For example...Passwords: Enter your password now or your account will be frozen.Tokens: Enter the token code now or your account will be frozen.FIDO: Swipe
According to SSL Pulse there are 738 sites that are vulnerable to Heartbleed: https://www.trustworthyinternet.org/ssl-pulse/I just don't see how that can be tolerated. I'm assuming this data means we have sites that are presenting valid certs even though their private keys can be (and may have
Thanks Hubert. I was guessing about 1,000 sites so seeing 3,000 is better but
still small. What I didn't expect is that fewer than 50,000 sites present
themselves as being secure in the first place. That's smaller than it ought to
be.
The real shocker however is how many sites exhibit known
I'll address the DoS thing momentarily but first I'm curious if there's any data out there on how widely deployed HSTS currently is and/or to what extent site/domain owners are committing to support it going forward?Also are the cases where self-DoS might occur well known? The cases I can think of
So I read through RFC 6797 and see that some of my concerns are addressed there. Still, I would like to have a better understanding of Mozilla's implementation since there is user agent flexibility that's open to interpretation. One other thing that isn't clear to me is how complete the Mozilla
Hi Anne,
Just to clarify, are you saying that effective in FF release ?? that a
document obtained via https will allow only https for all subsequent
retrievals, images and js, etc. alike?
To the larger discussion, I have 2 questions: 1) what is the specific message
you'd like to convey to
Hi Jeremy,
Could you (or anyone) elaborate a bit on the use cases where short lived certs
are desirable?
Are there really cases where the extra 50 bytes (or whatever) for the
revocation info is too great a burden? Or is the desire really to short
circuit the revocation checks? Or...?
I'm
Thanks for sharing this Jeremy. I'm still reading through it myself but one
thing that jumps out at me is the implicit(?) allowing for the same key to be
used for SSL and code signing.
From a security standpoint that's a horrible idea. I'll elaborate if desired,
but I first wanted to find out
Agreed. Enforcing a rule like this would be limited, so here's what I'm hoping
to see:
1) Strong, clear, unambiguous wording in the specs so that we can take away the
I didn't know argument. Nobody should ever think it's okay to use the same
key in multiple ways.
2) Policies and checks put in
In your rush to judgment you arrived at the wrong conclusions, Ryan. No problem, though, as I'll recap my points in a bit. But first:The cert in question has as its root the utn-userfirst-hardware certificate. That appears to be a 2048-bit cert. If the wildcard cert should not have been issued
I should have included the dates. Validity period is November 2010 to 2015. Anyone at Comodo care to comment?
I've encountered a wildcard end-entity certificate on a live server that chains
directly to the root cert. There is no intermediate certificate and the root is
in the Mozilla trust store.
I assume this is a frowned upon practice that will be stopped as the BRs are
adopted and such certs expire
What are the current rules or algorithms in place when dealing with some mixture of http and https content in Firefox?A case I'm thinking about is a drive-by download situation. If the main page is loaded by https but there are subsequent requests for files (images, js, css, fonts, iframes,
Does Mozilla have a stated plan to include CT in its products?
The issues Ben lists sound like reasonable concerns but it seems this is
putting the cart before the horse. The linchpin of CT is being able to turn on
hard-fail when the SCT is missing or doesn't agree with the logs--or whatever
It is a separate discussion. I wanted only some sort of statement from Mozilla
about time frames and anticipated functionalities, if there are any.
If the scope of CT is being narrowed to focus only on the use of log files as
an auditing and compliance facility, that is something even I might
DANE will never happen, let's just acknowledge that, if for no other reason
than DNSSEC will never happen. It will take years to get enough support for
DANE (by both browsers and websites) to even judge how well it works. And
there is no guarantee it will work that well.
OneCRL itself will be
Curious to know the process by which cert holders will get their certs added
to these lists. How much of that flow and the necessary security measures have
been worked out?
Original Message
From: Richard Barnes
Sent: Thursday, August 7, 2014 3:59 PM
To: Rob Stradling
Cc:
Hi Wallas,Setting aside Ryan's petulance, if I may, I think the simple answer to all your questions can be stated thusly: no one is in charge and we depend on people doing the right things.Mostly I think that works out OK but there's just no escaping that much of the PKI system relies on nothing
I agree with Ryan: new audit by new auditor. Since PWC did a mediocre job last
time why would we expect a different result this time?
Original Message
From: Ryan Sleevi
Sent: Tuesday, August 5, 2014 5:41 PM
To: Kathleen Wilson
Reply To: ryan-mozdevsecpol...@sleevi.com
Cc:
OK, sure. Short answer is that I'm not that concerned--at least I don't think
I'm that concerned.
Regarding single points of failure, I think we'll need to rely on domain owners
and server admins to put pressure on their CA's to make sure the system
availability for the OCSP responders is
I like the general idea here. It's similar to how you download a file in the
background while still giving it the name and directory you want. In this case
you are downloading content while simultaneously deciding if it is trustworthy.
That said there are 2 issues to consider. The first is
This an interesting issue Kaspar and I appreciate you raising it. I also
personally appreciate you framing it in terms of trust because that's really
what is at issue here.
The whole idea of revocation is a gaping hole in the PKI landscape. The ability
to say don't trust me is so poorly
Well let's be clear about one thing: in Firefox land (as in others) there is no such thing as revocation; there is only changing the code.I think what Kathleen is saying is that starting Jan 1, Mozilla would like to take out the code supporting certs with small keys. What needs to be negotiated
Let's start with the basics: what is the cert subject, serial number, date info? None of the four browser notices provided any of that. Surely there is no reason to keep it secret, is there?
Brian,I was thinking it would be beneficial if ANSSI would provide a host:port that would have the bad chain installed. This allows for anyone to check if their browser has been updated to un-trust the intermediate.I make this suggestion in addition to the points you raise below, and I think
I would hope not! And yet...Firefox has no revocation checking right now (or if you prefer, for the last 17 years). So what's a Firefox user to do...besides not use
This is good information, Kathleen, and I'm certainly in favor of making improvements. I do wish there was more info on the report author and any affiliations he might have.That said I can't find clear, unambiguous detail on what CRL capabilities are actually working in Firefox, and for which
Changing the subject line because compliance is at the heart of this issue. I also would like to thank Brian for his comment below, because it seems we're discussing less the merits of CRLs and more rationalizing the cost to implement.Regarding the merits, here's a simple case that I hope will
30 matches
Mail list logo
