David E. Ross a écrit :
With a redacted audit report, the presumption
should be that hidden negative information exists that would disqualify
the certification authority from having its root certificate in the NSS
database if such information were disclosed.
any redaction would imply the
Phillip Hallam-Baker a écrit :
also likely to brick a large
number of cell phones as far as online commerce goes.
Which smart phone OS would you expect not to support sha-256 ?
It's likely that any that doesn't 3 years from now will have enough
security holes that it'd not be very
Eddy Nigg a écrit :
If Firefox really uses the CRLDP
No, it has never used the CRLDP to download the CRL.
People need to import the CRL manually and then activate the
auto-update, and nobody does it. What's more if the CRL becomes outdated
for some reason, there will be no warning.
The
On 08/06/2012 18:02, Sid Stamm wrote:
binary-file reputation system based on a whitelist of binaries and
domains, and identifies benign executables as windows users attempt to
download them. Benign executables can bypass any are you sure UI,
making it less annoying to users.
But also a lot
Jim Straus a écrit :
I definitely don't like the Android model. We'll have to figure out
exactly how to communicate permissions requests to users. On the other
hand, an appropriately vetted and signed app could be given permissions
implicitly in a permissions manifest, so the user doesn't
ianG a écrit :
That all worked to contain the problem, and now the 2nd gen attacks are
coming through. E.g., here:
http://financialcryptography.com/mt/archives/001349.html
$45,000 too small for the police to investigate !? The bad guys can
really make a lot of money with impunity.
On 06/09/2011 11:48, Devdatta Akhawe wrote:
[...] if I visit
https://www.secure.com in private browsing mode; Firefox makes a OCSP
request. After closing private browsing mode and going back to the
normal mode, if I go to https://www.secure.com then Firefox caches the
OCSP responses and doesn't
Brian Smith wrote:
See https://twitter.com/#!/scarybeasts/status/69138114794360832:
Chrome 13 dev channel now blocks certain types of mixed content by
default (script, CSS, plug-ins). Let me know of any significant
breakages.
See
Zack Weinberg wrote:
Counterpoint: If the attacker is (or colludes with) a rogue CA, they are
in a position to make the *entire contents* of the certificate be
whatever they want. They can forge EV status
Not really. EV status depends on the root certificate. If we'd lock on
something else,
Zack Weinberg wrote:
a real possibility in the attacker is a nation-state scenarios
*Public* PKI as it is implemented in the browsers does *not* protect
against nation-state attack scenario. It just can't.
A nation-state attack scenario means, amongst other things, the attacker
can get a
On 09/04/2011 00:52, Adam Barth wrote:
- CA locking functionality in HSTS or via CAA
There's significant interest in this feature from chrome-security
as well.
What about EV locking ?
How does a site change CA after he's started enabling CA locking.
Would you enable multiple CA locking
Ben Bucksch wrote:
1. It does indeed give attackers an advantage to know which security
holes I am vulnerable to. [...]
True, a well-written attack could use rendering engine feature changes
to detect the version. But not all security updates are detectable like
that, hopefully very few in fact,
Nassim KACHA wrote:
One speaker at Microsoft has dared to justify the slowness of IE compared
to its competitors by its highest level of security. You should know that
Microsoft makes a wide propaganda in Algeria.
You could oppose to that the following independent report that
integrates a lot
davidwboswell wrote:
I maintain a list of applications that use Mozilla technologies in
their projects and wanted to add more examples of projects that use
NSS.
You obviously forgot to include Google Chrome in the list !! ;-)
___
dev-security
Eddy Nigg wrote:
no CA was here admitted under these conditions for having the code
signing bit turned on.
I'm not saying that at some point in PKI history this wasn't done. It's
not done today and fee free to publicly name the CA which does that.
Last I checked there definitively were some
On 06/02/2010 19:47, Eddy Nigg wrote:
But I guess you would think twice to sign (malicious) code with your
name - any code for that matter.
How hard is it to sign it with a cert you bought with a stolen credit
card number, using the name from the card ?
A 50$ code signing certificate just
Daniel Veditz wrote:
4. Acknowledge privacy is dead and don't worry about it.
I tend to like that solution, but as this weakness will allow email
existence confirmation for spam senders, it's not really adequate here.
___
dev-security mailing list
Johnathan Nightingale wrote:
But with prefetch enabled, they could potentially harvest a significant
amount of information about the contents of your emails by watching all
the prefetch requests
But it will be disclosed anyway if he actually follows the link.
And I get a lot of spam from
Daniel Veditz wrote:
CSP is designed so that mistakes of omission tend to break the site
break. This won't introduce subtle bugs, rudimentary content testing
will quickly reveal problems.
But won't authors fail to understand how to solve the problem, and open
everything wide ? From
Daniel Veditz wrote:
CSP is designed so that mistakes of omission tend to break the site
break. This won't introduce subtle bugs, rudimentary content testing
will quickly reveal problems.
But won't authors fail to understand how to solve the problem, and open
everything wide ? From
Daniel Veditz wrote:
CSP is designed so that mistakes of omission tend to break the site
break. This won't introduce subtle bugs, rudimentary content testing
will quickly reveal problems.
But won't authors fail to understand how to solve the problem, and open
everything wide ? From
Bil Corry wrote:
CSP is non-trivial; it takes a bit of work to configure it properly
and requires on-going maintenance as the site evolves. It's not
targeted to the uninformed author, it simply isn't possible to
achieve that kind of coverage -- I suspect in the pool of all
authors, the majority
Nelson Bolyard wrote:
[...] In NSS 3.12, you must tell NSS every time
it is initialized whether it is using old (Berkeley, default) or new
(Sqlite3) DBs. This may be done in any of (at least) 3 different ways,
including an environment variable, a directory name prefix, or a
programmatic
Nelson Bolyard wrote:
By default, it is still the old single-process cert8 and key3 DBs,
as before.
However, FF 3.5 has the code to support shared-access cert9 and key4 DBs,
based on sqlite3. You can force FF 3.5 to use that by setting an
environment variable.
My understanding is that is you
Eddy Nigg wrote:
[...] When do we expect SSL? On submit or on
password fields in a form[...]
IF page contains form
AND form contains password field
THEN flash insecure form warning
Could be done. But there would better be a cross browser agreement on
this. And coupled with a way to offer
Gervase Markham wrote:
[...]
We just turned hostname display UI for SSL on, according to The Burning
Edge...
This is a nice change, I found out about it on the burning edge too :-)
But, and as the link Eddy just reported shows, the attack is far from
being only for SSL.
I think we should
Boris Zbarsky wrote:
Jean-Marc Desperrier wrote:
But, and as the link Eddy just reported shows, the attack is far from
being only for SSL.
I think we should reconsider the options available to make the domain
name more visible for http connexions.
What about a white version of the hostname
Boris Zbarsky wrote:
Jean-Marc Desperrier wrote:
Which blacklist ? There's a blacklist inside the browser ?
Yes. See
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/libpref/src/init/all.jsrev=3.762mark=704-708#704
I'm left with the feeling this really should have been more
Until a better solution is deployed, here is the work around to make
Moxie Marlinspike's attack ineffective.
- select and copy in your clipboard the character inside the below :
╱
This character looks similar to / but is not the same !
This message is sent in unicode to allow for
Paul Hoffman wrote:
At 7:09 AM +0100 2/24/09, Kaspar Brand wrote:
Kyle Hamilton wrote:
Removal of support for wildcards can't be done without PKIX action, if
one wants to claim conformance to RFC 3280/5280.
Huh? Both these RFCs completely step out of the way when it comes to
wildcard
Gervase Markham wrote:
On 26/02/09 11:49, Jean-Marc Desperrier wrote:
What's truly broken is that the current i18n attack protection relies on
the checking done by the registrar/IDN, and that the registrar/IDN can
only check the second-level domain name component.
Actually, our protection had
Nelson Bolyard wrote:
[...]
Wildcards are not an essential part of this attack. They merely were a
convenience for this demonstration, but the attack could have been done
without using a wildcard cert. Even eliminating wildcard certs altogether
would not stop this attack.
This being said :
Eddy Nigg wrote:
On 02/19/2009 03:30 PM, Jean-Marc Desperrier:
Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n
attack using a *.ijjk.cn certificate.
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
.cn
Johnathan Nightingale wrote:
[...]
- We should turn it ON by default on non-secure connections, because
even though we know full well that the connection is subject to
subversion, we have a nearly-free way to marginally reduce the attack
surface in the background.
- And yes, there should be
Thorsten Becker wrote:
Nelson B Bolyard schrieb:
I think the solution that Jean-Marc outlined above would make some
sense: It would make it a bit easier to visit certain sites, but
disturb permanently if someone visits a site that has no trust anchor
in firefox.
There's a great deal of
Eddy Nigg (StartCom Ltd.) wrote:
Boris Zbarsky:
Could maybe try to brute-force the old key until they come up with a
forged
certificate that an SSL library accepts?
No, not really. It requires the possession of the certificate with the
weak key signed by a CA.
I really don't think that
Jean-Marc Desperrier wrote:
Dan Veditz wrote:
If you change the security.fileuri.origin_policy pref to a traditional
value does it start working again?
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/modules/libpref/src/init/all.jsrev=3.717mark=477-478#477
Try '3' first
Dan Veditz wrote:
If you change the security.fileuri.origin_policy pref to a traditional
value does it start working again?
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/modules/libpref/src/init/all.jsrev=3.717mark=477-478#477
Try '3' first, and if that's still not working try '4'.
Boris Zbarsky wrote:
Alexander Mueller wrote:
However HTTPS does not prevent that the Administrator of the
destination server is acquiring the actual plain text data.
So the .value of this input would already be hashed? Otherwise, this
argument fails: the page can just grab the value and
Armin Mueller wrote:
First i want to say that i am new in this group and that i am not very
versed in security questions.
And, my english not very good, sorry.
Mein Deutsch ist sicher schlimmer ;-)
[...]. These applications
should be run locally and on internet. To have a better overview
40 matches
Mail list logo
