Hi,
[great debian openssl f**kup]
some CAs have started to take action actively.
I have started a new thread about this with an example why a blacklist
is the only way to go.
- allow limiting CA certificates to certifying certain domains (for
example, I want my universities CA to be able to
Hi,
Please read the thread about Debian keys first:
I did (now completely), but most of it seems to be a discussion about
CAs (not) revoking keys. As I understand it, if the CA does use only a
normal CRL (and not OCSP), firefox won't care. At least the
proof-of-concept attack on the akamai key
Hello all,
I have proposed a few changes to SSL handling in response to the debian
openssl disaster. I also mentioned earlier that a way to limit CAs
would be nice, giving quite hypothetical cases where it would be
useful. With the recent Commodo verification failure and the MD5
weakness just
Why is this relevant to this mailing list?
Because there was a security failure in one of the Firefox trusted CAs
allowing anyone to get fake certificates. This event and the reaction
of the CA are important to determine if the CA is (still) trustworthy.
It's the same as the Commodo thing.
MD5 is not secure for applications that blindly sign inputs from
non-trusted parties that can predict the content of the part of the
message before the submitted text. This is an attack on the
collision-resistance of the function.
I assume that for a cryptographic hash function to be called
Hi,
you can download all compromised keys by yourself. They are widely
published.
Has anyone actually published all (or all interesting) weak private
keys for SSL? I know such a release exists for SSH (which AFAIK uses a
different exponent or something like that) and I know it is easily
Hi,
[weak keys]
Some of them can be found here:
http://metasploit.com/users/hdm/tools/debian-openssl/
I know, but they are SSH only as far as I can see. Is there such a
release for SSL? And would you consider such a release a good idea? (I
see little value for both attackers and legitimate
Hi,
I think there is an SSL blacklist as well.
Yes, there is. I am specifically asking if someone has published the
actual private key data - the actual keys, not a list. I do not know if
it would be good for such a list to become public as it would make
exploiting the vulnerability easier
Hi,
Let's say I'm a hacker with access to a public kiosk,
[...]
I then install that version of Firefox on the kiosk.
Simple: You should not be able to do that (if the kiosk is correctly
configured). If the hacker can install arbitrary code, he could also
install a rootkit with a keylogger or
I was playing around with the KEYGEN html tag, but I did not find any
documentation on how the generated keys can be accessed. key3.db is
growing, so the keys are probably saved, but is there some UI to
view/manage/export/delete such keys in Firefox? And how can a web site
use this key
I did of course google and I did find the site you linked, but it did
not help me much, as I found no information what has to happen
server-side (or links to such information). I understand that the key
is generated, stored and a SignedPublicKeyAndChallenge POSTed to the
server. I had not
Hi,
Test server at https://ssltls.de
none of the two images is visible with my Fx3.6. I don't give any
guarantees about my prefs and addons, though.
Jan
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Especially the certlock Firefox extension they propose
Certificate Patrol seems to do the same.
--
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention FROM NG
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the
Hi,
I'd like to put my key3db, cert8db on a USB pen drive to have a
portable soft token with some user certs that I can use from several
PCs (work, home) that all run Firefox.
While this is not exactly the solution you asked for, you might use a
portable firefox where the full profile
Hi,
Given users' tendency to click-through security warnings, would it
not perhaps be better for that box to be UNchecked by default?
No. If its a legitimate selfsign cert, its best to store it - then the
user won't be bothered but a real attack (changed cert again) would
trigger the warning
Am 2011-06-10 15:54, schrieb Kai Engert:
If you want an easier solution, you could write a client that integrates
keyserver lookup by doing the web request from within your email client,
and ask the user to solve the captcha in a popup message.
Maybe offer a download of the e-mail? This way,
Am 2011-06-12 18:49, schrieb Michael Ströder:
With which MIME-type?
message/rfc822 seems appropriate, the same that is used if you attach an
e-mail to another (or use forward as attachment).
Of course, you could also use application/xml after wrapping it into an
XML document ;-)
And how
Am 2012-02-19 02:46, schrieb Stephen Schultze:
Brian, any thoughts on this? Is this something we should be holding out
for, or should we look to other approaches?
A different interesting approach for a punishment could be removal of
the ability to create Sub-CAs. This would not put a CA out
Am 2012-02-19 06:00, schrieb Stephen Schultze:
Yes, but it would also break all existing certs issued by that CA that
are in the wild, which is one of the reasons that Mozilla has been so
resistant to removing roots in the first place.
Why? The point was only breaking the certs signed by
Am 2012-02-20 12:59, schrieb Gervase Markham:
I don't think this would be terribly practical. If the length constraint
was 1, then the CA would need to issue all subscriber certs directly off
the root - which is a strongly discouraged practice. If the length
constraint was 2, then the CA could
20 matches
Mail list logo
