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 Locatio
The other way to have a MITM situation is if the CloudFlare network becomes
compromised. The amount of damage a hacker can inflict is significantly greater
now because of both the Universal SSL and Keyless SSL offerings.
To your issue, John, are you requesting a change to the Firefox UI or is
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 ar
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
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
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 v
With proper planning, redundant equipment, and so forth, the perceived outage can be zero (that means 100% availability). Keep in mind you have 2 sets of customers: the people who purchase your service and the people who rely on your judgment as to who should or should not be trusted.Notifying you
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
I've thought a lot about this and for my money I don't think a UI indicator is the right solution for a a difficult problem like encouraging and rewarding good security practices. I realize my sphere of influence is limited so I’ll just offer the following perspective for whatever it may be worth:T
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 im
OK, thanks Matt. So the security improvement is because it's a server config
plus persistent memory on the client side.
What is the thinking in Firefox (assume Thunderbird will be similar?) for
handling of all the different cases that arise with it? I'm thinking of how
persistent is the HSTS k
I was hoping to learn that images too would get blocked. I'm not sure I can think of all the ways to exploit this hole in security but certainly a browser defect in image handling is one of them.I'm sure blocking such http requests would break some sites but has anyone performed research or analys
So what is the reason to use HSTS over a server initiated redirect? Seems to
me the latter would provide greater security whereas the former is easy to
bypass.
Original Message
From: Henri Sivonen
Sent: Monday, September 22, 2014 7:56 AM
On Wed, Sep 17, 2014 at 6:20 PM, Richard Barnes
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 th
Hi Gerv, you've been busy! The cases Jeremy identified (thanks, Jeremy!) are all good problems to address and while I'm not unsympathetic I don't necessarily find them all that compelling. The situations involving network meddling by someone in power is especially troubling and goes beyond what I'm
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 al
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 i
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
I should have included the dates. Validity period is November 2010 to 2015. Anyone at Comodo care to comment?
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 dire
Hmmm...
I'll just assume that all the "prior to Effective Date" conditions are
satisfied but both the end and root certs are 2048-bit. I can't speak to how
actively or widely used the cert is nor how costly it would be to replace other
than to say I've seen it on a half dozen different hosts.
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, etc.
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 ag
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
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: mozilla-dev-tech-c
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
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: mozilla-dev-security
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 that some of this performance data is concerning but I'm not ready to
give up on OCSP just yet because I don't see any choice in the matter: OCSP
hard fail has to be done.
The fact that end entity certs can not be revoked is a major gap in Internet
security right now. That gap should b
In terms of the messaging behind any iconography, I would like to see something
precise and perhaps more objective than, say, labels like
secure/not-secure/good-luck-with-that. Those words can have different meanings
depending on the context but the issues being addressed are pretty well
define
Hi Kathleen, I was looking over the spreadsheet and noticed that some CA's who
are transitioning to a new chain are actually reporting the expiry and last
dates of issuance. I'm glad to see that and now have 2 questions.
1. When CA's report a transition from one root or chain to another, do y
Maybe Kathleen can provide some perspective here, but I think the threat
landscape is this: what is the impact when certificate issuers lose control of
their private keys? Might everyone be at risk or can we limit the impact to
certain groups of people. If you have a technical constraint then t
You make a good point that requiring users to abandon a master password in
order to use the sync service is counter to good security practices.
I would encourage Mozilla to not only allow master passwords with sync but also
require master passwords in the first place. An unsecured password repo
Thanks for pointing out my oversight, Rob. When I read that first paragraph I
skipped over the first word, which is an important first word!
I was a little thrown by the last sentence, "a single issuing CA". I took that
to mean root cert, but I guess they meant any intermediate within the chain?
By my reading of the Microsoft requirements using separate intermediates is
insufficient: they must be root certificates.
I'm not familiar with their reasoning behind that but I can imagine cases where
that could be a good idea (a consequence of Heartbleed perhaps). Whatever the
case may be, i
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 99.9
DoS is a concern but I'm not sure how big of a concern it really is.
If I'm a miscreant I would not want to create a DoS situation because it
probably won't help me meet my goals. Letting people realize I'm trying to
trick them is counter-productive after all. If I'm a government agent trying
I can't believe anyone actually worries about captive portals, but there are
lots of things I don't understand so
Snark aside, there is a flaw in the reasoning that Adam (imperialviolet.org)
and the rest of the good folks at Google have put forth regarding OCSP. The
logic boils down to a p
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 tha
I didn't watch the video but I did read what's on the website. My take is that
the solution proposed is merely ok. It's not great but it's not terrible either.
Where I would say the idea falls short is in the problem statement. While CA's
do make for easy targets of criticism for their central r
If you go back and check Bugzilla I think you'll find Mozilla is pretty open
and documents all requests from the NSA.
CRLs are gone and not coming back and that is fine...except that OCSP, in
practice, is not as dependable as we need it.
Original Message
From: John Nagle
Sent: Thursday, Ap
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 impl
That's the great part about this, Rob, you don't actually have to revoke anything. The certs will just stop working at some point. I'm being somewhat facetious but
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 the
I would suggest that there are 3 things for Mozilla to impress upon the participants in the trusted store program:1) Compliance with relevant specs and policies. This is important not only to ensure proper, secure interoperability but also to create a level playing field. As Tim Moses points out t
I would like to point out that the ANSSI MITM intermediate cert situation presents many of the same problems as cert theft. Namely:1) A software download and install is the only remedy (which should bother people). Not everyone will be able to upgrade, and not everyone will upgrade. Those who can'
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 it
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?
Sure, there are other ways to accomplish malware infection, but the issue remains: if I steal your certificate, I can use it anyway I want and there is no way for you to stop me...and that's a big problem.
We've also talked about indicating the BR version against which the cert is issued. I would encourage the CABF folks to include that as well in any such "BR Cert Issuance Extension".
Oops, hit send by mistake. I realize that "stolen cert" is not accurate, strictly speaking, but I think it might paint a better picture of the the situation that leads to the risk/danger...?In any case, thanks for providing that link Kathleen. It is informative but the situation Netcraft describes
Thanks for correcting me on what's in the BR. It seems to me when spend so much time in this forum talking about the dates I figured this stuff was already in there.Regarding browsers checking and blocking forward dated certs, I agree and would expect that browsers would behave that way. Outside o
Finally getting back to this one, and renaming the subject
Peter G and Peter B are correct and the reality in the embedded world is that if you want to provide some sort of service (https or otherwise) to an embedded device with known limitations and a software update is not possible, then you have play any number of games with certificates.
There are a couple good points here, starting with hard-fail. Why is it not already turned on by default? What is the argument against it? An even better question is how many people in this forum have turned it on, and what has your experience been? I just turned it on myself...once I found the stu
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 F
I was hoping to see more responses on this issue. Does that mean people agree it's a problem but aren't sure what to do about it? Is it a small problem because Firefox already does OCSP and all the CA's do too? Or...?
I don't have a strong opinion but I think it's okay to emphasize that we expect the POC to update Mozilla about new POCs.Up to you, though.
Kathleen, Is it captured somewhere that the CA will provide Mozilla with updated contact info if a new person becomes the point of contact for the CA? I wasn't sure.
I think what you've said here, Brian, is basically what I was looking for. Actually I wanted you to tell me I'm completely misinformed and these are the ways people will be protected. I'm thinking it might be appropriate to have some sort of communique sent out to the CA's so that all of them unde
And...this is a great way for hackers, fraudsters, and the NSA (is there a difference?) to attack users of Firefox. All I have to do is steal a private key, grab the cert chain, and I can go about setting up a fake site that will ensnare hapless surfers. It might not be a perfect attack but it doe
Perhaps instead I should have said it's a minus-seventeen-years exploit? :-) Seriously, though, anyone who has ever issued a CRL was basically wasting valuable electro
I think that is correct, Matthias.What's more is that anyone who issues an end-entity cert will be unable to stop FF from using that cert in the future--without OCSP setup--until the expiration date. (I'll need someone to correct me on that.)I gotta believe there are people out there who issue(d)
So if this really is the case, it seems to me that this constitutes a zero day vulnerability in Firefox. I don't mean to sound alarmist but...???
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 vers
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 ill
67 matches
Mail list logo
