gt;
>
> I'm not quite familiar with building NSS with gyp and ninja. Do I need to
> provide some additional flag in order for me to be able to debug NSS (if
> needed)?
>
> Thanks..
Hi Usha,
I've confirmed this issue and filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1630458 to track the resolution.
Thanks,
Kevin
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
> On Fri, Jan 24, 2020 at 3:12 AM SIC/IAIK wrote:
> The ckpAttributes that you have viewed in the debugger is actually an array
> with multiple ckAttributes. Specifically 1073742353 is the CKA_WRAP_TEMPLATE
> attribute.
> I traced the error down to this NSS git com
> I agree that deploying token-based security mechanisms may take time in many
> countries; so interim security mechanisms are desirable.
True but SSL should be secure too. Not just SSL from banks.
I don't know the details of J-Pake etc., but if it could verify a
fingerprint to a domain the user
> I can't think of a single in-the-wild attack on Firefox that could have
> been fixed by flipping a pref, unless you count disabling Javascript
> entirely which people wouldn't accept.
Actually many would especially if noscript is not available.
I thought finally firefox had an easy flip switch
> To Kevin's point about hardcoding known badd addons, I don't think that works
> given the length of the release cycle (up to 4 months to get from Nightly to
> stable), and that would be much less responsive than the blocklist ping
> already offers. Looking at bugzilla, input.mozilla.org I see
> I think this is a great idea, and I strongly support the necessary APIs for
> self-healing. Misbehaving addons have a huge impact on Firefox security. Even
> though the blocklist ping supports disabling misbehaving addons, being able
> to revert hijacked preferences (such as search) would be a
> Also, it's worth bearing in mind that the number of bits is a
> distractor. All the weakness comes from elsewhere, so fiddling around
> with the bits is just so much numerology that amuses NIST and numerate
> managers and others. It does little for overall security.
Well it is not a distrac
> Sure, but warnings are useless. Some people -- us -- might follow them.
> Most have been trained for so long to click through them that they no
> longer read them. Click-thru syndrome is a sad result of unreliable
> systems: if the False Negatives (wrong warnings) are too frequent, and
>
> 2. Limited cert lifetimes mean that if an algorithm starts to look dodgy
> (e.g. as MD5 did) we can move the industry to new algorithms without
> having to worry about 20-year end-entity certs. This is why we have been
> pushing in the CAB Forum for shorter max cert lifetimes. It's the CAs
> who
> and the thread Subject is spot on.
How about
War on mixed content - why not?
Warnings have been popping up for as long as I can remember so the
likely hood is that if they haven't fixed the site, they have chosen not
to. I could understand an argument that the warning could have changed
to a
> > I'm trying to argue that current non-EV certification process is no good
> > and self-signed certificates can be used to provide equal security in
> > practice. Then we can discuss if browsers should display some kind of
> > "secure" indicators for HTTPS connections with non-EV certs/self-si
> On Wednesday, 14 August 2013 12:21:15 UTC+3, Kevin Chadwick wrote:
> > > This is because the cheapest CAs do so bad work that the
> > > security is very close to self signed cert.
> >
> > Please show me evidence of startssl being less secure than some of th
> > So now you trust a user writable reference over a non writable installed
> > CA crt (I hope soon to be replaced by website provided keys signed by
> > mozilla/Google)
>
> Are you trying to say that there is a meaningful class of attacks that can
> modify user's bookmark store and still not
> On Thursday, 15 August 2013 12:23:18 UTC+3, Gervase Markham wrote:
> > On 14/08/13 07:09, Mikko Rantalainen wrote:
> >
> > > I'd say that such a bookmark would be highly probably safe, if that
> > > bookmark did include fingerprint for the site public key (*not CA key
> > > fingerprint*) and th
> Say you have an HTTPS bookmark to your bank. You visit it (your techie
> friend told you "always use this bookmark for your bank, and you'll be
> safe"),
So now you trust a user writable reference over a non writable installed
CA crt (I hope soon to be replaced by website provided keys signed by
> This is because the cheapest CAs do so bad work that the security is very
> close to self signed cert.
Please show me evidence of startssl being less secure than some of the
big CAs that have had major incidents. You only need to send them a csr
too.
Then realise that we should be concentrati
> Chrome's implementation is a little less secure since
> it does not block mixed iframes and mixed xhr. However, they are working
> on improving their Mixed Content Blocker.
I wouldn't be surprised if this is because it would break some
of Google's sites. You can't even navigate Google plus wi
> But, also, if a certificate feature isn't important enough for mobile*, then
> why is it important for desktop? We should be striving for platform parity
> here.
Please, that is not sane logic. The best should be strived for on each
platform. Firefox mobile is great and perhaps the only secure
> Unnecessary RPC should be avoided wherever possible to aid secure
> chroots and/or complete sandboxing.
Firefox did start requiring dbus after initial startup for config and
would shutdown but this seems to have been fixed now, not sure
when exactly as I stopped using the sandbox. :-)
--
_
> Slides for the talk can be found here -
> https://people.mozilla.com/~tvyas/SecEngBrownBag.pdf
A few thoughts.
I presume HSTS will have an about:config disable option as otherwise it
will really annoy users and may threaten HSTS's existence for the many
with dead laptop and dead bios batteries
On Mon, 12 Nov 2012 11:45:04 -0500
Johnathan Nightingale wrote:
> It's true that sometimes non-security changes have major security
> impacts (c.f. session restore making people more willing to apply
> updates). I also agree that each poster in our newsgroups represents
> a constituency (100x may
On Fri, 27 Jul 2012 09:26:45 -0700 (PDT)
Ian Melven wrote:
> Can you elaborate more on how dbus is used for config ?
When running a sandfox type chroot all kernel backed grsecurity chroot
escape prevention features can be enabled without any workaround or
errors except for.
http://en.wikibooks.
> Do you know how other people have solved this with Firefox?
I presume you have looked at sandfox. I stripped that down a bit and
made it work on a more secure system setup for my purposes. Firefox
dbus reliance for the simple task of config is a little annoying here.
--
___
> > I don't see why multiple standard queries has
> > any bearing, dns queries are cheap.
>
> No-find TLD queries are surprisingly slow. Try a few.
No problem here, maybe a second longer. I can't switch tab quick
enough. drill responds immediately. Do you suggest a method of testing
that?
> >> It'll be confusing, but the fact of the matter is that the "OS service
> >> calls" are pretty broken for cases when you might have more than one
> >> hostname to resolve and might care about doing other things at the same
> >> time (like in a browser, say)
> >
> > I can understand why an OS
> >
> > p.s. mozilla uses it's own malloc which is annoying because OpenBSDs is
> > so much better!!!
>
> We've done extensive tests and believe jemalloc is the best available
> malloc for the way we use memory; however, I don't know that we've
> tested specifically against OpenBSD malloc. In
> It'll be confusing, but the fact of the matter is that the "OS service
> calls" are pretty broken for cases when you might have more than one
> hostname to resolve and might care about doing other things at the same
> time (like in a browser, say)
I can understand why an OS wouldn't listen to
> Are you aware of actual plans to allow A records for TLDs? I don't have
> links to earlier discussion offhand, but I recall the consensus being
> that that shouldn't be allowed at all.
I wouldn't be surprised if disallowing that was one of the stipulations
for pressing ahead but the money may
> Top-level A records are already allowed. Try
>
> http://ai/
Hmm GTLDs FAQ says one of the requirements is a minimum of three
letters so from what registrar is this?
Why not do something good every day and install BOINC.
___
> Many of the TLDs are from domain speculators who want to resell
> domains, but a sizable fraction are world-famous brands.
I'm surprised at that at £118,000 and $25,000 per domain per year.
You can become a registrar of .co.uk for £160 per year.
Apparently they are non profit but there may be
On Mon, 11 Jun 2012 13:45:26 -0700
Sid Stamm wrote:
> Can you elaborate here? I'm interested to hear your thoughts.
Leaving aside server/device security which may affect user security and
also completely anonymised data matching to connection details or
substitued user ids. An example being home
Proper OS security against malware is the way to go but of course the
average user is far off that at the moment. That will change.
http://www.h-online.com/security/news/item/Anti-virus-software-out-of-its-league-with-Stuxnet-and-Flame-1604467.html
___
On Mon, 11 Jun 2012 08:57:35 -0700
Sid Stamm wrote:
> One of my worries is that blacklists get big really fast and won't be as
> feasible on mobile devices (cost of updating the lists, downloading and
> storing them).
Is this the browsers domain especially with heavy criticism of bloated
browsers
On Fri, 08 Jun 2012 15:02:27 -0700
Sid Stamm wrote:
> we have to think about whether Firefox users will be
> willing to trade some of their download history for the protection
> offered by the system and a less in-your-face download UI. I believe
> they will.
I'm assuming there would be a disabl
On Wed, 06 Jun 2012 17:06:45 +0100
Gervase Markham wrote:
> Unless it never works. If we announce we are not going to support this
> hijacking of barewords, and perhaps get other browser vendors to join us
> (I suspect Chrome would be keen; this is a problem for them) .
Where's this come from any
On Thu, 19 Apr 2012 11:13:05 +1000
ianG wrote:
> So this is one of those cases where the browser is right, *and* the user
> is right, and they are both in disagreement.
This is one of those cases where the browser is right, *and* the user
is right, but the website is wrong.
The website should u
On Mon, 16 Apr 2012 13:02:32 -0700
Tanvi Vyas wrote:
> Invisible Flash is often used as an audio
> > fall-back when a particular codec isn't supported natively by the
> > browser.
Maybe there's other invisible flash. I wouldn't really know as I only
use it occasionally, except on my tvs and there
On Fri, 13 Apr 2012 10:52:50 -0700
Johnathan Nightingale wrote:
> I think Joe's framing here is exactly right. Not only do I not want to make
> our developer tools first-run experience less pleasant by adding warnings,
> but I also doubt that easily-dismissed warnings would be genuinely effectiv
This came across an android dev list. I hope mozilla can avoid anything
similar. I knew android permissions could be bypassed by
pre-installed apps, app communication etc., but I didn't realise how bad
the situation was. Your probably already aware but just in case.
"https://viaforensics.com/secu
On Fri, 13 Apr 2012 16:25:26 +0300
Henri Sivonen wrote:
> (Dunno how important this
> concern is. That is, I don't know how realistic it is for a MITM to
> gain the capability to fake non-EV certificates but not to gain the
> capability to fake EV certificates.)
EV certs are pointless except for
On Wed, 11 Apr 2012 11:20:17 -0700
Eric Chen wrote:
> We are also interested in a defense for this. The defense that we came up
> with is actually very similar to proposal 1) and 3)
If you can work it without STS, do so as anything that turns users away
will not get widespread adoption especially
On Wed, 11 Apr 2012 00:54:53 -0700
Jesse Ruderman wrote:
> 1) If a site sends an STS header
In my opinion STS shouldn't be implemented professionally in it's
current state and with browsers treatment of valid dates. I looked to
implementing it and then realised that a user with a flat bios batter
On Fri, 6 Apr 2012 17:06:22 -0700 (PDT)
Ian Melven wrote:
> i think this is something we should probably leave to plugin vendors
> to implement (as Adobe has recently done with silent update for the Firefox
> Flash plugin)
Probably yeah but I can't believe how long adobe have been criticised
for
Looks like a good start.
especially
> 3) Your proposal means all privilege are granted up front at app
> install: Nope, we should not confuse authentication with
> authorization. For authenticated apps the initial trust decision just
> grants the app the right to request those sensitive privileg
On Sat, 31 Mar 2012 20:28:14 +1100
ianG wrote:
> "However, unlike [their competition], Apple promises its service to be
> highly secure and reliable."
>
> And they will achieve that.
On what basis do you believe that, just transport security.
I have a solution for this and Apple and Google are
On Fri, 30 Mar 2012 13:56:12 -0700
Kyle Hamilton wrote:
> Besides... the browsers aren't the ones who can enforce this, the
> Payment Card Industry contracts and audits are.
The browsers hold the cards if they get consensus between them that is.
PCI would have to adapt to the browsers decision ot
On Fri, 30 Mar 2012 12:15:02 +0100
Kevin Chadwick wrote:
> p.s.
>
> >> On 3/29/2012 3:42 AM, Kevin Chadwick wrote:
> >>> On Tue, 27 Mar 2012 18:29:29 -0700 John Nagle wrote:
> >>
> >>>> Anything that takes a credit card
and validate business identity information,
> digitally sign it, and send it to the browser, Firefox should display it
> properly.
That encourages the problem of misplaced trust.
p.s.
>> On 3/29/2012 3:42 AM, Kevin Chadwick wrote:
>>> On Tue, 27 Mar 2012 18:29:29 -0700 J
On Thu, 29 Mar 2012 08:38:29 -0700
John Nagle wrote:
Ok so it's sort of an improvement such as only the ip/domain which is
verified being shown on the cert reducing possible misleading but hasn't
actually dealt with the main problems at all. In fact as far as I can
tell it will just be a waste of
On Tue, 27 Mar 2012 18:29:29 -0700
John Nagle wrote:
> How can a free CA afford to validate its customers?
>
Check out startssl.com. It's only a few cpu cycles to certify a
domain via email or html file which is the only unforgeable level of
cert. Yes security of the key needs to be paid for
What are the plans to fix SSL. Would it be good to have a collaborated,
IE, Firefox, Chrome single free CA (like startssl) where the rogue CA
issue is prevented and security could be handled properly by eventually
removing all other CAs from browsers.
A domain control check could be automated via
On Thu, 22 Mar 2012 13:15:59 -0700
Yvan Boily wrote:
If you were going to do this, it should be global. A fingerprint
checked self-signed is actually more secure than a CA signed one. Also
someone's bios battery might have just run out of juice giving a
default date.
_
On Thu, 22 Mar 2012 23:45:47 -0700
Lucas Adamski wrote:
Untrusted
> They might want to capture audio or video input to stream to a server or
> process client-side,
Input from?
What's the distinction here, only via e.g. a flash plugin with it's own
permissions? Stories of phones without camera
On Thu, 22 Mar 2012 22:47:47 +1100
ptheriault wrote:
> I get your point about adding extra attack surface, but my thought was SSL
> has a fairly narrow and heavily tested attack surface compared to whatever
> signed/secured format is used. (i.e. an attacker could send unsigned
> malformed pages
On Thu, 22 Mar 2012 12:50:33 +1100
ptheriault wrote:
> 1. I can't think of any reason not to deploy privileged applications over
> SSL, and the more strict the better (HSTS, limited certs, additional checks
> etc)
I offer SSL on for example mail servers. It gripes me that companies
like Yahoo
On Wed, 21 Mar 2012 16:32:36 -0400
Jim Straus wrote:
> New standard, It would need to be run through standard committee(s).
In what way. There must be RFCs and has anyone looked at exactly how
jarsigner relates.
___
dev-security mailing list
dev-se
On Wed, 21 Mar 2012 17:05:44 -0500
Ian Bicking wrote:
> - Use developer keys so uploads are signed; or continue to add new or
> better authentication over time to keep the uploading process secure
> - Keep a public log of updates
> - Remove or revert code that was found to be malicious (i.e., Mozi
On Wed, 21 Mar 2012 21:23:29 -0400
Jim Straus wrote:
> > - Remove or revert code that was found to be malicious (i.e., Mozilla could
> > remove that code, not wait for the developer to act)
>
> That is a good point. Mozilla could retain the code in either case, but in
> the base of signed ma
On Tue, 20 Mar 2012 23:21:54 +
lkcl luke wrote:
> good analysis of the alternative distributions. their analysis is
> shown here:
>
> https://wiki.archlinux.org/index.php/Package_signing#How_signing_is_implemented_in_other_distributions
I fired that page across earlier without such a good i
On Tue, 20 Mar 2012 22:08:01 +
lkcl luke wrote:
> please do instead consider
> this to be a funny joke, which i am sharing *with* you, rather than
> being one who is laughing *at* you. i trust that you understand that
> the difference is vital. one is a personal insult - tantamount to
> tec
On Tue, 20 Mar 2012 17:40:02 +
Kevin Chadwick wrote:
> Your right though there's little to
> stop another company using safeapps.nets work to get another only
> signed by author copy and sign it with supertrus...@safeapp.net.
Also if a verifier builds the source as debian do
On Wed, 21 Mar 2012 01:01:55 +1100
ianG wrote:
> If each site does their own code-review, then they lose. That's because
> I can run a site that downloads off that site, and then pass on the
> benefit of the code-review. I leach off of the costs incurred off the
> primary site, and I can spen
On Mon, 19 Mar 2012 19:37:15 +
lkcl luke wrote:
> i do not ask you to judge such decision-making but i simply make you
> aware of it, such that if you find such actions questionable you can
> take it into account, such as by replying to messages which have been
> sent to you (directly or as pa
On Mon, 19 Mar 2012 19:57:20 +
Gervase Markham wrote:
> Turning off updates, including security updates, doesn't sound to me
> like an awesome solution to the problem of being nagged about them...
>
> "Hey, if you cancel your fire insurance, you don't get nagging letters
> every year tellin
On Mon, 19 Mar 2012 12:31:05 +
Ben Francis wrote:
> A user granting permissions
> expresses trust in the people hosting a web site/app, not the code itself.
No, it can be and is both or either. Take android. Some apps I trust
the author and hope he's responsible with his signing infrastructur
On Mon, 19 Mar 2012 11:53:48 +1100
ianG wrote:
> On 19/03/12 08:19 AM, Kevin Chadwick wrote:
> > On Sun, 18 Mar 2012 12:30:35 +1100
>
>
> On the MITM - FUD or validated threat?
http://www.h-online.com/security/news/item/28C3-New-attacks-on-GSM-mobiles-and-security-measures-
On Sun, 18 Mar 2012 12:30:35 +1100
ianG wrote:
> We could decide it is
> not a worry and accept it (SSH).
OpenSSH, A highly successful program with far less exploits.
> Or we could decide that it is a worry
> and decide to address it as our #1 threat (SSL).
A potentially highly successful
On Fri, 16 Mar 2012 13:16:54 -0700
Jonas Sicking wrote:
> It would
> have to be through some mechanism other than through the web server to
> add any level of security.
>> It could use a few gpg keyservers and a mozilla website and take the average
>> reporting
>> any odd keys to mozilla.
Or ev
On Sat, 17 Mar 2012 14:56:18 +1100
ianG wrote:
> No, that assumes the attacker is waiting and intercepting every web
> server request. In practice, he is not.
This should be assumed and should not matter especially as GSM is so
easily decrypted, coupled with a rogue CA makes gpg or atleast a
mo
On Fri, 16 Mar 2012 13:11:37 -0700 (PDT)
David Chan wrote:
> SSL doesn't protect us from a server compromise scenario. Though that
> doesn't matter if the store is a permissions granter, since a
> compromised store can just grant all permissions to rogue app X.
You need a security policy for priv
On Sat, 17 Mar 2012 03:17:15 -0700
Andreas Gal wrote:
> Web apps should use the same basic security model the web itself uses.
You mean the model that everyone in security is saying should be
replaced as soon as practical and agreed upon. You could still use
openssl but you should use more featur
On Fri, 16 Mar 2012 12:39:31 -0700
Jonas Sicking wrote:
> As I've stated, I don't want to force app developers to have to their
> code inspected by stores, nor do I want to force stores to review
> developers code. And if a code review hasn't happened I don't see what
> signing the code buys anyon
On Fri, 16 Mar 2012 13:16:54 -0700
Jonas Sicking wrote:
> It would
> have to be through some mechanism other than through the web server to
> add any level of security.
It would be best to bundle them with the hardware or bundle mozillas
key that other keys are signed or revoked with. Otherwise y
On Fri, 16 Mar 2012 11:29:25 +
Gervase Markham wrote:
> Certainly, app updates are a pain on Android - it nags me if I ignore
> them, and if I accept them, it nags me about different ones tomorrow.
If you don't need background data. You can disable that and get no
automatic update checks.
__
On Fri, 16 Mar 2012 13:49:23 +
lkcl luke wrote:
Have you considered using the grsecurity arm patch for the kernel (not
to do with permissions, just security, as I don't think RBAC works on
ARM yet, according to a document from the THALES defence contractor
anyway).
> i've contacted the NSA SE
On Fri, 16 Mar 2012 13:08:54 +
Ben Francis wrote:
> > Surely there should be no central authority for permissions requests other
> > > than the user?
I'd say that's correct but hopefully a repo type store or verified
source store may come along and rather than users checking mozilla.inc
a
On Thu, 15 Mar 2012 22:45:56 +
Ben Francis wrote:
> Web apps should be hosted, not packaged. How do you sign code that's
> constantly changing? Sometimes when web apps are updated there are
> different versions of resources on different nodes of a cluster behind a
> load balancer, or different
On Wed, 14 Mar 2012 17:09:00 -0700 (PDT)
David Chan wrote:
> The analogous idea in the B2G world would be that Mozilla,
> telcos, company foo could all run their own stores. If a user doesn't like
> the policies of the existing stores, they can start their own. However,
> there wouldn't be a wa
On Sun, 11 Mar 2012 23:01:49 -0700
Jonas Sicking wrote:
> A natural way that
> > this occurs is that you have separate "read" and "write" permissions, and
> > then you create a new action that involves both read and write actions.
>
> So far I don't think we've run into this need. I'd be curiou
On Sun, 11 Mar 2012 21:11:48 -0400
David Barrera wrote:
> SSL works well for authentication and as Jonas points out, it is well
> understood by developers and the community.
Actually the whole security community is looking for ways to fix SSL
Google chrome has announced a lookup website. SSL loo
On Sat, 10 Mar 2012 16:08:44 +
lkcl luke wrote:
> if such a strategy (execution of assembly code) is OUTRIGHT BANNED and
> will NEVER BE CONSIDERED, then and only then can the security model be
> dramatically simplified.
I think this notion also applies as a whole and the key is flexibility
f
On Sat, 10 Mar 2012 00:33:36 +
lkcl luke wrote:
> in the case of the debian distribution, that's encoded into the
> /etc/apt/sources.list file. if users edit that file and start adding
> e.g. "deb http://debian-multimedia.org";
If your looking at distro package signing. archlinux.org has ju
On Tue, 6 Mar 2012 18:28:15 -0800
Adrienne Porter Felt wrote:
> For example, there is relatively little risk attached to
> letting an app turn your Bluetooth on or off.
Are you nuts, how about a local app via qr code phishing switching
it on and then a stack exploit by a local attacker or attac
On Wed, 7 Mar 2012 09:26:31 -0800
Adrienne Porter Felt wrote:
> > > For example, there is relatively little risk attached to
> > > letting an app turn your Bluetooth on or off.
> >
> > How about a local app introduced via qr code phishing switching
> > it on and then a stack exploit by a local
On Tue, 6 Mar 2012 18:28:15 -0800
Adrienne Porter Felt wrote:
> For example, there is relatively little risk attached to
> letting an app turn your Bluetooth on or off.
How about a local app introduced via qr code phishing switching
it on and then a stack exploit by a local attacker or attacker
On Wed, 07 Mar 2012 13:26:13 +0100
Jean-Marc Desperrier wrote:
> > the system highlighting the
> > more dangerous ones requested but also maximising user configurability
> > and overrides is always best
>
> No, you're still dodging the difficult part by providing information to
> the user, l
On Wed, 07 Mar 2012 10:16:11 +0100
Jean-Marc Desperrier wrote:
> The Android model is broken, but so was the permission pop-up model.
A good default determined by authors with the system highlighting the
more dangerous ones requested but also maximising user configurability
and overrides is alway
On Tue, 24 Jan 2012 15:33:37 -0800 (PST)
Ian Melven wrote:
>
> Hi Kevin,
>
> in a current FF 9 release I see the following prefs :
>
> javascript.options.jitprofiling.chrome;true
> javascript.options.jitprofiling.content;true
> javascript.optio
Currently the only web browser I've found that runs with grsecurity/pax
with all security features such as "PAX" Mprotect and RANDMMAP is Opera.
"http://pax.grsecurity.net/docs/mprotect.txt";
"http://en.wikibooks.org/wiki/Grsecurity/Appendix/PaX_Flags";
I care more about security than javascript
Firefox 3.5 is compatible with several add-ons to help manage your
passwords. Some of them are pwgen, Billeo, Password Exporter and
Master Password Timeout.
https://addons.mozilla.org/en-US/firefox/addon/12715
___
dev-security mailing list
dev-security@li
90 matches
Mail list logo
