Re: Signing using JS in Safari
Hi Anders, Thanks for your mail. Is there any proprietary solution that's named Message Pro or so?? On Apr 6, 5:26 pm, Anders Rundgren anders.rundg...@telia.com wrote: Hi, Since there are no standards in this space most banks and e-governments use proprietary (but cross-browser) Java plugins. In the EU there are at least 10 different national schemes. Chrome and Safari presumably do not support any pre-configured solution since no such solution has gotten any traction worth mentioning. There is a lot of stuff you can buy though... Anders Sunny wrote: Hi, I'm not able to find any literature on the topic of Signing data using Digital Certificates with JS in Safari browser. like, in Firefox, we have window.crypto.signtext() method that you can call from Java script to select a certificate and sign the data using the certificate. For IE, we have a CAPICOM plug-in to do that. Do we have anything in chrome/safari that will help signing using Digital Certificates in java script? Please let me know. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Signing using JS in Safari
Hi Sunny, I haven't heard about Message Pro. Here is an open source (free) applet plugin: http://www.openoces.org/index.html It is used in Denmark and maybe somewhere else as well. In Sweden the government has spent some $30M over the years on: http://nexussafe.com/en/Products/Nexus-Personal IMO, both solutions are inferior but since they are actually used it doesn't really matter :-) It interesting to note that many signature plugins come with an authentication plugin which unifies the PKI GUI which using TLS is quite terrible. Some crypto people think that replacing TLS-client-cert-auth with an application-level authentication mechanism is a bad thing but there are tons with drawbacks using TLS-client-cert-auth and there is no hope for improvements and the alternatives are already in place. Even USPTO have selected an Java applet for PKI login... Anders Sunny wrote: Hi Anders, Thanks for your mail. Is there any proprietary solution that's named Message Pro or so?? On Apr 6, 5:26 pm, Anders Rundgren anders.rundg...@telia.com wrote: Hi, Since there are no standards in this space most banks and e-governments use proprietary (but cross-browser) Java plugins. In the EU there are at least 10 different national schemes. Chrome and Safari presumably do not support any pre-configured solution since no such solution has gotten any traction worth mentioning. There is a lot of stuff you can buy though... Anders Sunny wrote: Hi, I'm not able to find any literature on the topic of Signing data using Digital Certificates with JS in Safari browser. like, in Firefox, we have window.crypto.signtext() method that you can call from Java script to select a certificate and sign the data using the certificate. For IE, we have a CAPICOM plug-in to do that. Do we have anything in chrome/safari that will help signing using Digital Certificates in java script? Please let me know. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
Matt McCutchen wrote: On Apr 6, 5:54 am, Jean-Marc Desperrierjmd...@gmail.com wrote: Matt McCutchen wrote: An extended key usage of TLS Web Server Authentication on the intermediate CA would constrain all sub-certificates, no? You are here talking about a proprietary Microsoft extension of the X509 security model. No, I'm talking about the Extended Key Usage extension defined in RFC 5280 section 4.2.1.12. I repeat, you *are* talking about a proprietary Microsoft extension, which is to take into account the EKU inside path validation. The EKU as defined in section 4.2.1.12 of RFC 5280 only applies to the certificate that contains it, it has no effect on certification paths that include that certificate. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On Apr 7, 4:54 am, Jean-Marc Desperrier jmd...@gmail.com wrote: Matt McCutchen wrote: On Apr 6, 5:54 am, Jean-Marc Desperrierjmd...@gmail.com wrote: Matt McCutchen wrote: An extended key usage of TLS Web Server Authentication on the intermediate CA would constrain all sub-certificates, no? You are here talking about a proprietary Microsoft extension of the X509 security model. No, I'm talking about the Extended Key Usage extension defined in RFC 5280 section 4.2.1.12. I repeat, you *are* talking about a proprietary Microsoft extension, which is to take into account the EKU inside path validation. The EKU as defined in section 4.2.1.12 of RFC 5280 only applies to the certificate that contains it, it has no effect on certification paths that include that certificate. Ah, you are right. Bummer! We do need a way to limit the intermediate certificate to SSL server usage, otherwise it will be difficult to anticipate and close off all the possibilities for abuse with other EKUs. I will raise this with the PKIX working group. The Microsoft behavior makes complete sense to me, so maybe it could just be adopted by the standard. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On 2010-04-07 01:54 PST, Jean-Marc Desperrier wrote: Matt McCutchen wrote: On Apr 6, 5:54 am, Jean-Marc Desperrierjmd...@gmail.com wrote: Matt McCutchen wrote: An extended key usage of TLS Web Server Authentication on the intermediate CA would constrain all sub-certificates, no? You are here talking about a proprietary Microsoft extension of the X509 security model. No, I'm talking about the Extended Key Usage extension defined in RFC 5280 section 4.2.1.12. I repeat, you *are* talking about a proprietary Microsoft extension, which is to take into account the EKU inside path validation. The EKU as defined in section 4.2.1.12 of RFC 5280 only applies to the certificate that contains it, it has no effect on certification paths that include that certificate. Once RFC 3280 and 5280 were published, that did indeed become the specification of EKU. But long before that, both Netscape (where NSS originated) and Microsoft did just what Matt is describing, and they still do. I can point to some email from former a Microsoft PM (product? project? program? manager) saying that Microsoft adopted it because their competition was already using it, and that Microsoft has no plans to stop it. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On Apr 3, 9:45 am, Jean-Marc Desperrier jmd...@free.fr wrote: It's the sites that need to catch on those updates. And web developers can have power to influence those sites to update. FWIW, I am a DreamHost customer and I just submitted a support ticket with them to close the vulnerability for customer sites (initially by refusing client-initiated renegotiation, eventually by implementing safe renegotiation). -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On Apr 4, 6:48 am, Eddy Nigg eddy_n...@startcom.org wrote: It's trivial from the logical point of view. That's easy for you to say. Even things that are logically trivial are easy to miss unless one goes carefully over every single step of the process. For instance, I used a little script to check certificates against private CAs for three months before I realized that validating against the CA that owns the CN is the wrong thing to do when the certificate might have matched the expected hostname using a SAN. Logically trivial, but I wasn't thinking carefully and I missed it. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On Apr 7, 12:47 am, Kurt Seifried k...@seifried.org wrote: What about www.paypal.com[NULL].yourcompany.com? I assume that would be allowed by the name constraint with respect to fixed software, but still hit some older software that has the NULL certificate bug. I think www.paypal.com[NULL].yourcompany.com would match the name constraint, but it isn't important, since modern software will not allow that to match a requested hostname of www.paypal.com. If some people are still using software that is vulnerable, that's their fault; we can't let them tie our hands indefinitely. I'm also curious what about www.paypal.com[lotsof spaces or underscores or something like that].yourcompany.com? Spaces are not a problem because Firefox will not parse a URL where the hostname contains a space. Barring spaces, this is the same concern raised in the Problematic Practices for wildcard certificates, except that the name constraints allow multiple labels (i.e., dots): https://wiki.mozilla.org/CA:Problematic_Practices#Wildcard_DV_SSL_certificates Personally I'm not worried about this weak attempt to fool the user. It will be pretty obvious when the Larry button shows yourcompany.com (browser.identity.ssl_domain_display = 1) or the whole www.paypal.com__.yourcompany.com (2). -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 4/4/2010 10:41 PM, Daniel Veditz wrote: On 4/3/10 9:30 AM, johnjbarton wrote: If the *users* of Firefox are truly in jeopardy, then this alert should be provided to *users*. Since this alert is not shown to users I can only assume that in fact there is no practical threat here. You're putting this message in the Error Console because you can. We plan on alerting users in a future update. This is fair warning to server operators and those who are debugging their sites. If this is a real threat don't users deserve a fair warning now? How is it ok to let users be compromised only for a while? The Firefox 3.6.3 release shows how Mozilla can react if it knows about a real threat. So I have to conclude that you believe this threat is not significant. In that case working to close this potential problem is a laudable work we all thank you for. Just please choose a more appropriate communications channel. jjb -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On Wed, 2010-04-07 at 09:55 -0700, johnjbarton wrote: On 4/4/2010 10:41 PM, Daniel Veditz wrote: On 4/3/10 9:30 AM, johnjbarton wrote: If the *users* of Firefox are truly in jeopardy, then this alert should be provided to *users*. Since this alert is not shown to users I can only assume that in fact there is no practical threat here. You're putting this message in the Error Console because you can. We plan on alerting users in a future update. This is fair warning to server operators and those who are debugging their sites. If this is a real threat don't users deserve a fair warning now? I fully agree! If users are vulnerable now, they should be warned now, (bug 535649 comment #15). The counterargument (comment #24) is that showing the broken SSL UI for almost all sites will quickly neutraliz[e] the awareness/protection it might offer, but I think my proposal for a yellow Larry button (comment #62) partially addresses this concern. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Memory leak fixes
Hi,
While going through fixing memory leaks in CHASM[1], I fixed some leaks
within NSPR and NSS. Here's a list of the leaks that CHASM exposed
(doing minimal things with NSS, basically just hashing):
* The error tables are not cleaned up. This is the most invasive
change since it adds a new public function
(nspr_CleanupPRErrorTables) which cleans up *all* error tables. This
means that anything that calls this cleans up every error table that
has been installed. Unfortunately, I see no better way of handling
this since everything is already not threadsafe. This is then called
in PR_Cleanup (The positioning may be too early, but I put it in
reverse order that PR_InitStuff does). A note was also added to the
PR_Cleanup comment.
* Clean up the TPD pointer within _PR_CleanupTPD.
* Call PL_ArenaFinish when cleaning up the arenas.
These patches have made CHASM run silently (as far as NSS/NSPR are
concerned, glibc has a leak in it yet) under valgrind.
I ran the tests, but many failed due to my machine not having a fully
qualified domain name. Since these changes affect cleanup, they
*probably* don't affect other things, but I can set up a machine with a
proper fqdn and rerun the tests (with and without my patches). Thanks.
--Ben
[1]http://chasmd.org
Index: nsprpub/pr/include/prerr.h
===
RCS file: /cvsroot/mozilla/nsprpub/pr/include/prerr.h,v
retrieving revision 3.10
diff -u -r3.10 prerr.h
--- nsprpub/pr/include/prerr.h 10 May 2007 01:21:41 - 3.10
+++ nsprpub/pr/include/prerr.h 7 Apr 2010 20:03:17 -
@@ -276,6 +276,7 @@
#define PR_MAX_ERROR (-5924L)
extern void nspr_InitializePRErrorTable(void);
+extern void nspr_CleanupPRErrorTables(void);
#define ERROR_TABLE_BASE_nspr (-6000L)
#endif /* prerr_h___ */
Index: nsprpub/pr/include/prerror.h
===
RCS file: /cvsroot/mozilla/nsprpub/pr/include/prerror.h,v
retrieving revision 3.14
diff -u -r3.14 prerror.h
--- nsprpub/pr/include/prerror.h28 May 2007 14:48:26 - 3.14
+++ nsprpub/pr/include/prerror.h7 Apr 2010 20:03:17 -
@@ -304,6 +304,17 @@
/***
+** FUNCTION:PR_ErrorCleanupTables
+** DESCRIPTION:
+** Unregisters all error tables with NSPR.
+**
+** NOT THREAD SAFE!
+**
+***/
+NSPR_API(void) PR_ErrorCleanupTables();
+
+
+/***
** FUNCTION:PR_ErrorInstallCallback
** DESCRIPTION:
** Registers an error localization plugin with NSPR. May be called
Index: nsprpub/pr/src/linking/prlink.c
===
RCS file: /cvsroot/mozilla/nsprpub/pr/src/linking/prlink.c,v
retrieving revision 3.108
diff -u -r3.108 prlink.c
--- nsprpub/pr/src/linking/prlink.c 30 Mar 2010 19:01:52 - 3.108
+++ nsprpub/pr/src/linking/prlink.c 7 Apr 2010 20:03:18 -
@@ -249,8 +249,6 @@
*/
void _PR_ShutdownLinker(void)
{
-/* FIXME: pr_exe_loadmap should be destroyed. */
-
PR_DestroyMonitor(pr_linker_lock);
pr_linker_lock = NULL;
@@ -258,6 +256,9 @@
free(_pr_currentLibPath);
_pr_currentLibPath = NULL;
}
+
+PR_FREEIF(pr_exe_loadmap-name);
+PR_FREEIF(pr_exe_loadmap);
}
/**/
Index: nsprpub/pr/src/misc/prerr.c
===
RCS file: /cvsroot/mozilla/nsprpub/pr/src/misc/prerr.c,v
retrieving revision 3.11
diff -u -r3.11 prerr.c
--- nsprpub/pr/src/misc/prerr.c 10 May 2007 01:21:41 - 3.11
+++ nsprpub/pr/src/misc/prerr.c 7 Apr 2010 20:03:18 -
@@ -127,3 +127,7 @@
void nspr_InitializePRErrorTable(void) {
PR_ErrorInstallTable(et);
}
+
+void nspr_CleanupPRErrorTables(void) {
+PR_ErrorCleanupTables();
+}
Index: nsprpub/pr/src/misc/prerrortable.c
===
RCS file: /cvsroot/mozilla/nsprpub/pr/src/misc/prerrortable.c,v
retrieving revision 3.8
diff -u -r3.8 prerrortable.c
--- nsprpub/pr/src/misc/prerrortable.c 25 Apr 2004 15:01:01 - 3.8
+++ nsprpub/pr/src/misc/prerrortable.c 7 Apr 2010 20:03:18 -
@@ -217,6 +217,26 @@
}
PR_IMPLEMENT(void)
+PR_ErrorCleanupTables()
+{
+struct PRErrorTableList *et;
+
+et = Table_List;
+
+while (et) {
+struct PRErrorTableList *cet;
+
+cet = et-next;
+
+PR_FREEIF(et);
+
+et = cet;
+}
+
+Table_List = NULL;
+}
+
+PR_IMPLEMENT(void)
PR_ErrorInstallCallback(const char * const * languages,
PRErrorCallbackLookupFn *lookup,
PRErrorCallbackNewTableFn *newtable,
Index:
Re: Memory leak fixes
On Wed, 7 Apr 2010 16:18:41 -0400 Ben Boeckel maths...@gmail.com wrote: While going through fixing memory leaks in CHASM[1], I fixed some leaks within NSPR and NSS. Ben, thanks for the work here. Always great to have outside contributions for Mozilla projects. Open source is what makes this project great. If you wouldn't mind, would you please submit your patches directly via Bugzilla[0] so they can be processed appropriately? You'll need to split your patch into separate NSS and NSPR parts, as they are tracked as separate products, but if you can get your patches filed in Bugzilla, I'm sure the NSS and NSPR developers would love to review them. https://developer.mozilla.org/en/Getting_your_patch_in_the_tree has some good information on how to get your patch landed. Let us know if you have any questions. Thanks again for your contribution! ~reed [0] https://bugzilla.mozilla.org/ -- Reed Loden - r...@reedloden.com -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Memory leak fixes
In article 20100407160150.2b5d0637.r...@reedloden.com you wrote: On Wed, 7 Apr 2010 16:18:41 -0400 Ben Boeckel maths...@gmail.com wrote: While going through fixing memory leaks in CHASM[1], I fixed some leaks within NSPR and NSS. Ben, thanks for the work here. Always great to have outside contributions for Mozilla projects. Open source is what makes this project great. If you wouldn't mind, would you please submit your patches directly via Bugzilla[0] so they can be processed appropriately? You'll need to split your patch into separate NSS and NSPR parts, as they are tracked as separate products, but if you can get your patches filed in Bugzilla, I'm sure the NSS and NSPR developers would love to review them. Sure[1][2]. https://developer.mozilla.org/en/Getting_your_patch_in_the_tree has some good information on how to get your patch landed. Let us know if you have any questions. Thanks again for your contribution! ~reed [0] https://bugzilla.mozilla.org/ --Ben [1]https://bugzilla.mozilla.org/show_bug.cgi?id=557922 (NSPR) [2]https://bugzilla.mozilla.org/show_bug.cgi?id=557925 (NSS) pgphkQv30CI2Z.pgp Description: PGP signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Alerts on TLS Renegotiation
On 2010/04/07 10:43 PDT, Matt McCutchen wrote: On Wed, 2010-04-07 at 09:55 -0700, johnjbarton wrote: On 4/4/2010 10:41 PM, Daniel Veditz wrote: We plan on alerting users in a future update. This is fair warning to server operators and those who are debugging their sites. If this is a real threat don't users deserve a fair warning now? I fully agree! If users are vulnerable now, they should be warned now, (bug 535649 comment #15). The counterargument (comment #24) is that showing the broken SSL UI for almost all sites will quickly neutraliz[e] the awareness/protection it might offer, And that argument is now being successfully used by a lot of companies who make products that directly face the end users. They use it to avoid doing ANYTHING about this problem. They say we can't start to warn users until a majority of the servers on the net have gotten fixed, so that a minority generate the errors. And so users go unwarned, and they remain blissfully ignorant of their vulnerability. Coinsequently, they put no pressure on servers to get fixed. Consequently, there is NO pressure on servers to get fixed, and servers are not getting fixed at all rapidly. Inconveniencing the users is a NECESSARY part of getting this vulnerability fixed. Without that, the servers have NO INCENTIVE to lift a finger to fix this. but I think my proposal for a yellow Larry button (comment #62) partially addresses this concern. Maybe, but you'll have to sell it to product makers who'd prefer not to annoy their users at all if their lives don't depend on it. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
