Re: Cross-Compilation of NSS for MIPS platform fails.

[Wan-Teh Chang]

Hi,

On Tue, Mar 15, 2016 at 10:13 PM,  <ramyasivanesa...@gmail.com> wrote:
> Hi,
>  I have been trying to cross compile NSS 3.21 for MIPS-Linux platform, but am 
> facing a lot of build issues. First I built nspr with mipsel toolchain and it 
> compiled without any errors.
>  While compiling NSS , I am getting the following error :
>
> {standard input}: Assembler messages:
> {standard input}:79: Error: unrecognized opcode `bswap $2'
> make[3]: *** 
> [mipsel-linux3.13_x86_glibc_PTH_DBG.OBJ/mipsel-linux_SINGLE_SHLIB/sha_fast.o] 
> Error 1
>
>  Hence, I would like to know whether cross-compilation of NSS is supported 
> for MIPS. If so, kindly give the links of the documentation.

Yes, cross-compilation of NSS is supported for Linux MIPS. The
procedure is tedious, requiring setting several makefile variables to
appropriate values, and is not documented on the NSS website.

The best source of information is the build scripts for the NSS
packages in Linux distributions such as Debian, Fedora, and Gentoo,
and a makefile in Firefox.

Here is the Firefox makefile that compiles NSS. Search for
"CROSS_COMPILE" in that makefile, and you will see which NSS makefile
variables need to be set:

http://mxr.mozilla.org/mozilla-central/source/config/external/nss/Makefile.in#187

It may be worthwhile to cross-compile Firefox for MIPS and inspect the
build log file for the command line. I think that would be easier than
trying to parse that makefile.

>  Also, after some modifications, I was able to build NSS, but while running I 
> am getting errors related to database. Error log is as follows :
>
>  Error initializing NSS without a persistent database: NSS error code: -5925
>
>  So, how shall I proceed to rectify this error?

Error code -5925 is PR_CALL_ONCE_ERROR:

http://mxr.mozilla.org/nspr/source/pr/include/prerr.h

That narrows down the failure to a small number of locations:
http://mxr.mozilla.org/nss/search?string=PR_CallOnce

Look at the PR_CallOnce calls in lib/freebl, especially
lib/freebl/loader.c. I suspect the dlopen() call of libfreebl3.so
failed because it could not find libfreebl3.so. I suggest you
investigate in that direction.

By the way, are you using a MIPS development board such as Creator
Ci20 that I can easily buy to reproduce your problem?

Wan-Teh Chang
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Verifying a signature using NSS

[Wan-Teh Chang]

On Wed, Feb 10, 2016 at 11:50 PM, WebDoctor  wrote:
> Hi,
>
> I'm working in a Firefox extension that will use some cryptographic 
> operations.
>
> The problem I found is that when I sign data using the private key in the 
> server-side, I couldn't find any appropriate function in NSS to do public key 
> signature validation.
>
> I tried to use PK11_Verify, but this function is not listed as public 
> function in nss3.dll, so I got the error "Couldn't find function PK11_Verify 
> to declare".
>
> What can I do to verify a signature using NSS?

You can use PK11_Verify (declared in "pk11pub.h") or the VFY_xxx
functions declared in "cryptohi.h" to verify a signature.

NSS Technical Note 5 has sample code for PK11_Verify:

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/nss_tech_notes/nss_tech_note5

You can also look at how it is used in ssl3con.c:

http://mxr.mozilla.org/nss/ident?i=PK11_Verify

PK11_Verify is a public function exported from nss3.dll. We should
find out why you couldn't use it.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: AES-256 vs. AES-128

[Wan-Teh Chang]

On Tue, Dec 1, 2015 at 8:55 AM, Julien Vehent  wrote:
>
> AES-NI is fast enough that we shouldn't have to care:
>
> $ openssl speed -evp aes-256-gcm
> type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
> aes-256-gcm 385250.93k   983154.24k  2011460.35k  2620519.76k  3048865.79k

Intel's low-end CPUs don't have AES-NI. For example, Pentium G3258
("Anniversary Edition"), launched in Q2 2014, doesn't have AES-NI:
http://ark.intel.com/products/82723/Intel-Pentium-Processor-G3258-3M-Cache-3_20-GHz

Neither does this Pentium model, launched in Q1 2015:
http://ark.intel.com/products/87358/Intel-Pentium-Processor-G3470-3M-Cache-3_60-GHz

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)

[Wan-Teh Chang]

On Mon, Oct 7, 2013 at 11:17 AM, Brian Smith br...@briansmith.org wrote:

 I think it is likely that some vendors of NSS-based products with very
 conservative backward-compatibility guarantees, like Oracle and maybe
 Red Hat, may need to continue supporting SSL 2.0 in their products due
 to promises that they've made. If so, either we should create a branch
 for these organizations to maintain, or we should create a branch of
 libssl without SSL 2.0.

The burden of maintaining the branch should fall on the people who
still need SSL 2.0, so we should remove SSL 2.0 from the trunk. It is
not that hard for a competent NSS developer to support an NSS 3.15
branch for another three years.

Note: we will keep the ability on the server side to handle a
ClientHello in the SSL 2.0 format.

Removing SSL 2.0 is an important step to clean up the SSL library
because it blocks some other cleanups, such as the handling of
handshakes and receive (gather) buffers.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: set default on for SHA2 for TLS1.1+ on firefox

[Wan-Teh Chang]

On Mon, Oct 7, 2013 at 12:02 PM, Brian Smith br...@briansmith.org wrote:

 If you are referring to something other than the TLS_*_SHA256 cipher
 suites, please be more specific as to what you are referring to.

Brian,

If you can enable TLS 1.2 by default in Firefox, that should make
Mountie happy. Besides the HMAC-SHA256 cipher suites, the AES-GCM
cipher suites also make it possible to do TLS without using SHA-1 at
all.

TLS 1.1 still contains hardcoded use of MD5 and SHA1 in the protocol.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS documentation proposal

[Wan-Teh Chang]

On Thu, Sep 5, 2013 at 9:42 AM, Elio Maldonado Batiz
elio.maldonado.ba...@gmail.com wrote:

 If you have a mozilla-bugzilla account please log a bug. If not then one of
 us could do it on your behalf.

Milan already filed a bug report for his doxygen patch:
https://bugzilla.mozilla.org/show_bug.cgi?id=912360

Wan-Teh Chang
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Wan-Teh Chang]

On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco cvie...@mozilla.com wrote:
 Hello Brian

 I think this proposal has 3 sections.
 1. Unifing SSL behavior on browsers.
 2. Altering the criteria for cipher suite selection in Firefox (actually
 NSS)
 3. removing certain cipher suites from the default firefox ciphersuite.

 On 1:
 I dont see the point, but I am not against.

 On 2:
 The proposal is not clear. I want an algorithmic definition. For example in
 nss we can see in sslenum.c :
 -strong ciphers before weaker
 - national ciphers before international
 - faster ciphers before slow ciphers.

 But your proposal it not clear. Here is my reverse engineering of the
 criteria to get to your list:

 1. Message Authentication: MD5 last.
 rationale: security
 2. Key exchange (round1): PFS before non-PFS suites
rationale: privacy, goal stop supporting non-PFS suites.
 3. Bulk encoding (round1): aes(all variations) before national ciphers
 before 3des before rc4 before des before export ciphers before null.
   rationale: security, aes is the most studied cipher both in implementation
 and theory. RC4 has shown
 weakness.
reationale2 performance: 3des is slow and does not provide much security
 over the other ciphers.
 4. Authentication (round1) : DSS last
rationale: it is not really used, want to deprecate.

 5. Key Exchange (round2): ECDH before DHE.
rationale: ECDH allows negotiation form client.
 6. Bulk encoding (round 2): 128 AES before 256 AES
rationale: performance and minimal security gains.
 7. Message Authentication: authenticated encryption (GCM) before SHA before
 SHA256 before sha384
a. AEAD before HMAC : performance
b. sha ordering: performance
 8. Authentication: RSA before ECDSA
 a. RSA before ECDSA : performance
 b. DSA last: not in use

 This criteria gets to your ordering proposal. What do you think of
 re-framing your list in a criteria like this? (note national ciphers could
 go in step 6 instead of step 3).

Camilo, I think you reverse-engineered Brian's criteria correctly.

The new criteria seem fine. I would prefer ECDSA over RSA for authentication.

 Not adding:
 TLS_(EC?)DHE_RSA_WITH_AES_(128|256)_CBC_SHA256
 Disagree I dont think a potential performance issue should prevent us from
 deploying that suite as there could be sha1 attacks that we dont know of. If
 we have enough space in the handshake I see no problem in including them.
 Removal seems like a premature optimization.

The way HMAC-SHA1 uses SHA1 is much more complicated than the way
public key signatures use SHA1. This is why SHA1 collision attacks
usually don't affect the security of HMAC-SHA1.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Wan-Teh Chang]

On Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling rob.stradl...@comodo.com wrote:

 Wan-Teh, why do you think Firefox should specify a preference for ECDSA over
 RSA?

Because ECDSA is more secure than RSA, and ECC implementations will
become faster over time.

The ordering of RSA and ECDSA is really a symbolic gesture right now
because they each require a certificate, and very few websites have
both an RSA certificate and an ECDSA certificate.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

The NSS_SURVIVE_DOUBLE_BYPASS_FAILURE build option will be removed in NSS 3.15.1

[Wan-Teh Chang]

NSS has a build option NSS_SURVIVE_DOUBLE_BYPASS_FAILURE that enables
some code in the SSL library to turn off PKCS #11 bypass mode
automatically if the attempt to bypass PKCS #11 fails:

http://mxr.mozilla.org/security/search?string=NSS_SURVIVE_DOUBLE_BYPASS_FAILURE

I believe nobody is using that build option. I am going to remove that
build option so that the ss-ssl3.hs.messages structure member is only
used for one purpose: to buffer handshake messages until we establish
which handshake hash functions to use. This will simplify the logic of
determining when to stop buffering handshake messages.

If you are using the NSS_SURVIVE_DOUBLE_BYPASS_FAILURE build option,
please let me know. If you call SSL_CanBypass before enabling the PKCS
#11 bypass mode, you should not need the
NSS_SURVIVE_DOUBLE_BYPASS_FAILURE build option.

Thanks,
Wan-Teh Chang
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Fwd: Re: No such instruction building NSS

[Wan-Teh Chang]

On Mon, Jun 10, 2013 at 3:43 PM, Robert Relyea rrel...@redhat.com wrote:

 Yeah, you need to use the new assembler on RHEL-5:

 As root:
 yum install binutils220

 As user:
 export PATH=/usr/libexec/binutils220:$PATH

 Then do you your build.

Bob, could you add the above to the NSS build instructions page at
https://developer.mozilla.org/en-US/docs/NSS_reference/Building_and_installing_NSS/Build_instructions
?

Kai previously documented these steps in the NSS 3.14.2 release notes
( 
https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14.2_release_notes#New_in_NSS_3.14.2
), but they should also be in the NSS build instructions.

Thanks,
Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Changing the recommended list archive (as Google's archive is incomplete)

[Wan-Teh Chang]

Kai,

Thank you for creating the NSPR 4.10 and NSS 3.15 releases.

I have just announced the NSPR 4.10 release in the NSPR newsgroup:
http://mozilla.6506.n7.nabble.com/ANNOUNCE-NSPR-4-10-Release-tc280660.html
http://permalink.gmane.org/gmane.comp.mozilla.devel.nspr/1698
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.tech.nspr/ic6OqaDBU-Y


(Not sure which is the preferred way to refer to a newsgroup posting.)

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: SIGSEGV on 64bit HP-UX with shlibsign (NSS 3.14.3)

[Wan-Teh Chang]

On Tue, May 21, 2013 at 12:11 AM, Ashwani Kadian
ashwani.kad...@oracle.com wrote:
 Hi All,

 In NSS 3.14.3 build process, shlibsign crashes while trying to sign 
 libsoftokn3.sl on HP-UX 64 bit machine. It works fine on 32 bit HP-UX.

 mozilla/security/nss/cmd/shlibsign/HP-UXB.11.11_64_OPT.OBJ/shlibsign -v -i 
 mozilla/security/nss/cmd/shlibsign/../../../../dist/HP-UXB.11.11_64_OPT.OBJ/lib/libsoftokn3.sl

 moduleSpec configdir='' certPrefix='' keyPrefix='' secmod='' flags=noCertDB, 
 noModDB

 Generate a DSA key pair ...

 Segmentation fault

 There is a already a bug (HYPERLINK 
 https://bugzilla.mozilla.org/show_bug.cgi?id=703812Bug 703812) filed in 
 Bugzilla for this but there are no updates on that for a long time.

 If anyone of you have faced this issue earlier then can you please share any 
 solution/workaround to this crash.

I will post comments in the bug report.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS - PKCS #11 Test Suites build problems (2013)

[Wan-Teh Chang]

Hi Tiago,

On Fri, Feb 15, 2013 at 11:34 AM, TIAGO ALVES alvesfons...@ibest.com.br wrote:

 I saw previous messages that reported build problems in the NSS - PKCS
 #11 Test Suites.

 I would like to know if those issues have already been addressed?

We never had the time to retrieve the source code of the missing tools
and open-source them. By now it is too late because none of the
current NSS team members have access to the source code of the missing
tools.

 My interests are in pkcs#11 soft-tokens and I would like to evaluate
 my implementation using the tests provided by the nss source, and,
 then, to test my token in the mozilla browser.

Perhaps you can join the newly formed PKCS #11 working group in OASIS
and suggest that a PKCS #11 test suite be created?

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

[ANNOUNCE] NSS 3.14.2 Release

[Wan-Teh Chang]

[NOTE: NSS 3.14.2 does not include a fix for the attacks described in
the paper Lucky Thirteen: Breaking the TLS and DTLS Record Protocols
(http://www.isg.rhul.ac.uk/tls/). An upcoming NSS patch release will
address the attacks.]

Network Security Services (NSS) 3.14.2 is a patch release for NSS 3.14.
The bug fixes in NSS 3.14.2 are described in the Bugs Fixed section
below. NSS 3.14.2 should be used with NSPR 4.9.5 or newer.

The release is available for download from
https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_14_2_RTM/src/

For the primary NSS documentation pages please visit
https://developer.mozilla.org/en-US/docs/NSS

New in NSS 3.14.2

* NSS will now make use of the Intel AES-NI and AVX instruction sets
  for hardware-accelerated AES-GCM on 64-bit Linux systems.
* Initial manual pages for some NSS command line tools have been added.
  They are still under review, and contributions are welcome. The
  documentation is in the docbook format and can be rendered as HTML
  and UNIX-style manual pages using an optional build target.

New Types:
* in certt.h
  - cert_pi_useOnlyTrustAnchors
* in secoidt.h
  - SEC_OID_MS_EXT_KEY_USAGE_CTL_SIGNING

Notable Changes in NSS 3.14.2

* Bug 805604 - Support for AES-NI and AVX accelerated AES-GCM was
  contributed by Shay Gueron of Intel. If compiled on Linux systems in
  64-bit mode, NSS will include runtime detection to check if the
  platform supports AES-NI and PCLMULQDQ. If so, NSS uses the optimized
  code path, reducing the CPU cycles per byte to 1/20 of what was
  required before the patch
  ( https://bugzilla.mozilla.org/show_bug.cgi?id=805604 and
  https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pdf).
  Support for other platforms, such as Windows, will follow in a future
  NSS release. ( https://bugzilla.mozilla.org/show_bug.cgi?id=540986 )
* SQLite has been updated to 3.7.15.
* Bug 816853 - When using libpkix for certificate validation,
  applications may now supply additional application-defined trust
  anchors to be used in addition to those from loaded security tokens,
  rather than as an alternative to.
  ( https://bugzilla.mozilla.org/show_bug.cgi?id=816853 )
* Bug 772144 - Basic support for running NSS test suites on Android
  devices.This is currently limited to running tests from a Linux host
  machine using an SSH connection. Only the SSHDroid app has been
  tested.
* Bug 373108 - Fixed a bug where, under certain circumstances, when
  applications supplied invalid/out-of-bounds parameters for AES
  encryption, a double free may occur.
* Bug 813857 - Modification of certificate trust flags from multiple
  threads is now a thread-safe operation.
* Bug 618418 - C_Decrypt/C_DecryptFinal now correctly validate the
  PKCS #7 padding when present.
* Bug 807890 - Add support for Microsoft Trust List Signing EKU.
* Bug 822433 - Fix a crash in dtls_FreeHandshakeMessages.
* Bug 823336 - Reject invalid LDAP AIA URIs sooner.

Bugs fixed in NSS 3.14.2

* 
https://bugzilla.mozilla.org/buglist.cgi?list_id=5502456;resolution=FIXED;classification=Components;query_format=advanced;target_milestone=3.14.2;product=NSS

Compatibility

NSS 3.14.2 shared libraries are backward compatible with all older NSS
3.x  shared libraries. A program linked with older NSS 3.x shared
libraries will work with NSS 3.14.2 shared libraries without recompiling
or relinking. Furthermore, applications that restrict their use of NSS
APIs to the functions listed in NSS Public Functions will remain
compatible with future versions of the NSS shared libraries.

Feedback

Bugs discovered should be reported by filing a bug report with
bugzilla.mozilla.org (product NSS).
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS 3.14.2 BETA 3 tagged ; NSS 3.14.2 BETA 3 + one patch now required to build mozilla-central

[Wan-Teh Chang]

On Mon, Jan 28, 2013 at 4:34 AM, Kai Engert k...@kuix.de wrote:

 I commented on the patch for bug 834091 that you included in
 mozilla-central in the bug. It seems you are adding a new API to mozilla
 desktop that hasn't been fully reviewed nor checked in to NSS yet.

 https://bugzilla.mozilla.org/show_bug.cgi?id=834091#c25

I believe Brian Smith followed the right process here to document the
private patch.
But I agree that we should work to get that patch reviewed and checked in to NSS
with a high priority.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS 3.12.5 - Bug 665814 - (CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets -76)

[Wan-Teh Chang]

On Thu, Jan 24, 2013 at 1:52 AM, Sergey Emantayev
sergey.emanta...@gmail.com wrote:

 For the reference, I'm attaching the back ported fix for the 3.12.5, with no 
 warranties.
[...snipped]
 --- nss-3.12.5-orig/mozilla/security/nss/lib/ssl/sslimpl.h  Tue Jan 15 
 16:40:47 2013
 +++ nss-3.12.5/mozilla/security/nss/lib/ssl/sslimpl.h   Wed Jan 16 15:12:23 
 2013
 @@ -337,6 +337,8 @@ typedef struct sslOptionsStr {
  unsigned int enableDeflate  : 1;  /* 19 */
  unsigned int enableRenegotiation: 2;  /* 20-21 */
  unsigned int requireSafeNegotiation : 1;  /* 22 */
 +unsigned int _enableFalseStart_notInUse : 1;  /* 23 */
 +unsigned int cbcRandomIV : 1;  /* 24 */
  } sslOptions;

  typedef enum { sslHandshakingUndetermined = 0,
 --- nss-3.12.5-orig/mozilla/security/nss/lib/ssl/sslsock.c  Tue Jan 15 
 16:40:47 2013
 +++ nss-3.12.5/mozilla/security/nss/lib/ssl/sslsock.c   Wed Jan 16 15:14:16 
 2013
 @@ -183,6 +183,8 @@ static sslOptions ssl_defaults = {
  PR_FALSE,   /* enableDeflate  */
  0,  /* enableRenegotiation (default: never) */
  PR_FALSE,   /* requireSafeNegotiation */
 +PR_FALSE,   /* enableFalseStart - not in use   */
 +PR_TRUE /* cbcRandomIV*/
  };

It should be unnecessary to reserve a bit for enableFalseStart, but it
is harmless to do so.

By the way, it should be safe to back port the patch to NSS 3.12.5, as
you have done.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Attempting to Link to Mozilla NSS Libraries causes Undefined Reference Error

[Wan-Teh Chang]

2012/11/27 Brian Teh tehhzs...@gmail.com:

 THUNDERBIRD_LDFLAGS =  -L$(THUNDERBIRD_OBJDIR_PATH)/mozilla/dist/lib \
-lxpcomglue_s\
-lxpcom  \
-lmozalloc   \
-lnss\
-lnssb   \
-lnssutil\
-lnspr4  \
-lplds4  \
-lplc4   \
-shared  \
$(NULL)

This shows you are linking with NSS static libraries. You should link
with NSS shared libraries, which have different file names.

Replace -lnss -lnssb -lnssutil with -lnss3 -lnssutil3.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS 3.14 release

[Wan-Teh Chang]

On Wed, Oct 24, 2012 at 10:19 PM, Julien Pierre
julien.pie...@oracle.com wrote:

 The following changes may be problematic :

 1) * New default cipher suites

 ( https://bugzilla.mozilla.org/show_bug.cgi?id=792681 )

 The default cipher suites in NSS 3.14 have been changed to better
 reflect the current security landscape. The defaults now better match
 the set that most major Web browsers enable by default.

 This doesn't just affect browsers. There are other client apps that were
 written with the existing defaults in mind.

Any client apps that care about the exact cipher suites enabled need
to enable and disable each cipher suite explicitly. This Chromium code
in this file can be used as code example:

http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/nss_ssl_util.cc?revision=151846view=markup

Search for Explicitly enable exactly those ciphers with keys of at
least 80 bits in that page. You can use different criteria
appropriate for the client app.

 I could understand if this change was only about removing cipher suites that
 have had vulnerabilities removed from the default list. But this not the
 case, and some ciphers were also added.
 It would appear to be a binary compatibility problem. Some applications may
 not behave as intended without both a source change and recompilation, ie.
 some ciphers will be enabled when they are not expected to be.
 This change will break one of the test suites we have with our web server
 and traffic director applications, in particular.

 If this change was done in order to save a few lines of code in the browser
 at the cost of breaking existing applications, it doesn't seem like a good
 tradeoff.
 In the past, binary compatibility was always maintained for minor NSS
 releases. Was it the deliberate intent of NSS 3.14 to break binary
 compatibility ?

You need to change your tests to explicitly enable the desired cipher
suites and disable the undesired cipher suites, and not depend on the
defaults. Sorry about the inconvenience.

In year 2012, AES cipher suites, rather than (single) DES cipher
suites, should be enabled by default. We decided to break this
compatibility to improve security. This is also why we disabled SSL
2.0 by default in NSS 3.13
(https://bugzilla.mozilla.org/show_bug.cgi?id=593080). Note that we
waited another two years to change the cipher suite defaults. I think
this is already very conservative.

 3)* Support for TLS 1.1 (RFC 4346) has been added

 ( https://bugzilla.mozilla.org/show_bug.cgi?id=565047 )

 To better support TLS 1.1 and future versions of TLS, a new version
 range API was introduced to allow applications to specify the desired
 minimum and maximum versions. These functions are intended to replace
 the now-deprecated use of the SSL_ENABLE_SSL3 and SSL_ENABLE_TLS socket
 options.

 Q: will unmodified applications that use the deprecated interfaces still
 continue to work identically ? This appears to be the case from reading the
 above bug, but I want to make sure that is correct.

Yes, I confirm that.

 4) SSL PKCS#11 bypass is now conditionally built.
 https://bugzilla.mozilla.org/show_bug.cgi?id=745281

 ...
 I would like to know if the bypass feature got tested when the patch was
 created, and whether it will still be getting tested at all going forward
 other than at Oracle.

Yes. The default NSS build still compiles the SSL PKCS#11 bypass code.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: libnss x86 DRNG

[Wan-Teh Chang]

On Tue, Oct 2, 2012 at 7:45 PM, Michael Demeter
michael.deme...@intel.com wrote:

 Continuation would then be to eliminate any unnecessary work being
 done to increase the randomness..Since the HW generated values
 can be used directly. This could help a small little bit in performance
 (but that is a secondary effect)…

The code in mozilla/security/nss/lib/freebl/drbg.c implements one of the
deterministic random bit generators (DRBGs) specified in NIST SP
800-90 (the Hash_DRBG). It is necessary for FIPS 140-2 validation.
For this reason NSS can't use hardware-generated values directly.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Creating PKCS7 object using NSS

[Wan-Teh Chang]

On Sat, Aug 11, 2012 at 5:37 AM, Gökçen Eraslan
gokcen.eras...@gmail.com wrote:

 When I traced the code I see that  sec_pkcs7_create_signed_data call
 returns successfully but sec_pkcs7_add_signer fails.

 Trace is like that:

 sec_pkcs7_add_signer - CERT_VerifyCertificate - CERT_VerifyCertChain
 - CERT_FindBasicConstraintExten - cert_FindExtension

 and finally cert_FindExtensionByOID function returns
 SEC_ERROR_EXTENSION_NOT_FOUND.

 My full patch is here: http://pastebin.ca/2179231

 Can anybody help me about that error? I need to create a PKCS7 object
 and encoded it via SEC_PKCS7Encode. May my certificate be the problem?

Perhaps the CA certificate of your signing certificate does not have
the basic constraint extension?  That's what I concluded from the call
stack you provided and the SEC_ERROR_EXTENSION_NOT_FOUND error code.

Also, it's better to use the new CMS functions in
mozilla/security/nss/lib/smime instead of the old PKCS7 functions.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Building NSS with VS2008, Statically Linking the CRT

[Wan-Teh Chang]

On Thu, Jul 12, 2012 at 3:20 AM, Sam Laidler
sam.laid...@the-logic-group.com wrote:

 I want to distribute NSS without the MS redistribution package. When I read 
 the following,
 I got the impression that it should be theoretically possible:

 https://developer.mozilla.org/en/USE_STATIC_LIBS

That page describes the USE_STATIC_LIBS variable for Mozilla's build system.
Unfortunately NSS's build system has a same-named variable that has a different
meaning.  Bob Relyea was talking about the USE_STATIC_LIBS variable in the
NSS build system in his reply.

There is an old patch for NSS that allows you to build NSS against msvcrt.dll,
which is present in Windows:
https://bugzilla.mozilla.org/show_bug.cgi?id=79

You can give that a try.  You need to be very familiar with build
systems though.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Is there an ETA yet for when Firefox will use libpkix by default?

[Wan-Teh Chang]

Rob,

Please fix the bug in the old certificate verification library.  Thanks.

Are you going to use the approach outlined by Nelson in bug 479508 and
bug 482153?

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS 3.12.5.0: Error '-8152' (SEC_ERROR_INVALID_KEY) when connecting to ssl-enabled servers

[Wan-Teh Chang]

On Mon, May 21, 2012 at 5:21 AM, Bernhard Thalmayr
bernhard.thalm...@painstakingminds.com wrote:
 Hi Wan-Teh, Nelson, could it be that this error is also raised by the client
 if the client can not 'participate' in ssl client-auth?

Yes, this is possible.

 Unfortunately I only got a text-output of 'ssldump', not sure if this is
 would be helpful.

 The end of the handshake shows ...

 1a0: f3 6e fc 04  ab 79 e1 13                            | .n...y..
   0: 0d 00 2b 36                                         | ..+6
      type = 13 (certificate_request)
      length = 11062 (0x002b36)
         CertificateRequest {
            certificate types[3] = { 01 02 40 }
            certificate_authorities[11056] = {

                List Truncated

            }
         }
   0: 0e 00 00 00                                         | 
      type = 14 (server_hello_done)
      length = 0 (0x00)
   }
 }
 ]

This shows a client certificate was requested.

 -- [
 (7 bytes of 2)
 SSLRecord { [Mon May 14 13:25:27 2012]
   0: 15 03 00 00  02                                     | .
   type    = 21 (alert)
   version = { 3,0 }
   length  = 2 (0x2)
   fatal: bad_certificate
   0: 02 2a                                               | .*
 }

The - arrow is from client to server.  As Nelson said, most likely
the public key in the server's certificate is bad.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS 3.12.5.0: Error '-8152' (SEC_ERROR_INVALID_KEY) when connecting to ssl-enabled servers

[Wan-Teh Chang]

On Tue, May 8, 2012 at 7:33 PM, Nelson B Bolyard nel...@bolyard.me wrote:

 Bernhard,
 I think the most likely explanations are these:

 1) Server certificate has a public key that is too small, too large, has a
 too small public exponent (if RSA), an unknown key type, or a key for an
 Elliptic Curve that is not supported by NSS.

 2) Some other certificate in the server's cert chain has one of the above
 problems.

 3) The server is attempting to use Server Key Exchange for forward
 secrecy, and the key it is offering for that purpose has one of the problems
 mentioned above.

 4) The server is selecting a cipher suite that is incompatible with the type
 of key in its public key certificate.

Nelson is right.

I looked into a check we added recently for 3).  It was added in NSS 3.12.7:
https://bugzilla.mozilla.org/show_bug.cgi?id=554354

Since you're using NSS 3.12.5.0, that makes 3) less likely, but still possible.

 Ii suggest you use tcpdump or ssltap to get a trace of your own.

Yes.  To track this down, we need the server's certificate chain and the
Server Key Exchange handshake message, if it is used.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Provide own CA

[Wan-Teh Chang]

On Mon, May 7, 2012 at 9:20 AM, Marc Patermann
hans.mo...@ofd-z.niedersachsen.de wrote:
 Hi,

 I posted my issue on Thunderbird-Enterprise before and Ludovic Hirlimann
 sent me here.

 I created an own CA and put the cert in cert8.db by GUI in Thunderbird 10
 ESR.
 As far as I understand it, the way to go is to put the corresponding
 cert8.db file in defaults/profile in the program directory. (Which works for
 mimetypes.rdf.)

 For what I tested it does not work. On a blank profile cert8.db is always
 the original file, my CA is never included.
 If I copy back cert8.db by hand, the CA is in there. So the file itself is
 fine, but it seams to be never used.

 What did I do wrong?

Hi Marc,

Perhaps the cert8.db file in defaults/profile in the program directory
is not being used by Mozilla programs?

If that's true, then I'm afraid that you will need to add your CA
to every profile, rather than relying on defaults/profile in the
program directory.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Feedback on DOMCryptInternalAPI

[Wan-Teh Chang]

David,

Here are my review comments on https://wiki.mozilla.org/DOMCryptInternalAPI:

1. I don't understand the difference between the two methods that
generate key pairs:
PKGenerateKeyPair
SigGenerateKeyPair

2. PKEncrypt just need a public key, not a key pair.

3. I suggest not assigning 0 to any algorithm enumerator.  This allows
the use of 0 as an invalid value. We can't use -1 because the type is
unsigned long.

So ALGORITHM_RSA should be 1 and ALGORITHM_DSA should be 2.

4. Like PKDecrypt, Sign just needs aKeyID, which represents a private key.

5. Verify should take a public key.

6. The second arguments of Sign and Verify should have the same name
(because the refer to the same thing) and the name should not imply it
is encrypted (such as aPlaintext and aClearBytes).  You can use
'message' as the argument name.

7. When verifying a MAC, the byte comparison must be constant time to
avoid leaking timing info.  Leaking timing info of MAC verification
could be problematic in some situations.  This issue is described in
https://groups.google.com/group/keyczar-discuss/browse_thread/thread/5571eca0948b2a13

So I suggest adding a verify() method to the CryptoHmac interface, so
that we can implement the verify() method with constant time byte
comparison.

Wan-Teh Chang
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: cert8.db rewrite reasons and exceptions?

[Wan-Teh Chang]

On Wed, Apr 4, 2012 at 12:47 PM, Anders Rundgren
anders.rundg...@telia.com wrote:

 Mozilla should IMO rather hook into the
 other vendors cryptographic solution, possibly at the expense of NSS.

 According to a [colleage] of mine Chrome even use the platform's SSL
 implementation!  Well, not in *NIX since there is no such thing...

Yes, early versions of Chrome used the platform's SSL implementation.
That strategy became restrictive when we needed the server name
indication extension support but it isn't available by the SChannel
library on Windows XP.  Today Chrome uses the SSL implementation from
NSS, but still uses the platform's certificate and key store and the
platform's certificate verification function.

On Linux Chrome uses the NSS sqlite certificate and key databases in
$HOME/.pki/nssdb, as proposed in
https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX.

Using the platform's certificate and key store has worked well in
general.  There are some minor problems due to uneven support of
features across versions of the platform.  For example, ECC
certificates are not supported on Windows XP, and SHA-256 certificate
support on Windows XP requires service pack 3.

As for hooking into other vendors cryptographic solution -- in my
biased opinion, although some OS vendors cryptographic solutions are
indeed better than NSS, NSS is still better than others.  My current
recommendation is to only use the platform certificate and key store
(and the trusted root certificate list, if appropriate for your
product). This may require using the OS vendors cryptographic library
for private key operations because private keys cannot be extracted
from the platform key store in general.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Alternative for SGN_DecodeDigestInfo

[Wan-Teh Chang]

On Wed, Apr 4, 2012 at 4:39 PM, Brian Smith bsm...@mozilla.com wrote:

 I don't know what platform JV is on, but I know on Mac OS X,
 all the internal symbols in FreeBL and maybe other libraries
 are exported. This is how the Firefox Sync developers got
 so far in developing their JavaScript implementation of J-PAKE
 based on FreeBL's internal math library; they did all their
 development and testing on Mac OS X and when they were done,
 they were surprised to find they were using functions that you
 can't even reference on Windows (and Linux?).

 I am not sure if there is something we can do about this problem
 for Mac OS X.

The NSS makefiles should restrict the symbols exported from
the dynamic shared libraries on Mac OS X:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/coreconf/rules.mkrev=1.83mark=316,343-347#316

Perhaps that makefile rule is not working as intended?  Or
perhaps Firefox Sync developers were using the static
library libfreebl.a (which loads libfreebl3.dylib at run time)
on Mac OS X?

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Certificate verification regression in NSS 3.13.2

[Wan-Teh Chang]

If you maintain the NSS package in an OS distribution, please read this
announcement.

NSS 3.13.2 has a regression when we removed the support for Netscape
international step-up certificates.  The bug report for this regression
is NSS bug 737802 (https://bugzilla.mozilla.org/show_bug.cgi?id=737802).

This bug affects the CERT_PKIXVerifyCert function, which is based on
libpkix.  The classic NSS certificate verification functions, such
as CERT_VerifyCert and CERT_VerifyCertificate, are not affected unless
they have been configured to use libpkix internally by using either the
NSS_ENABLE_PKIX_VERIFY environment variable or the
CERT_SetUsePKIXForValidation function.

I will make an NSS 3.13.4 release soon to fix this regression.  In the
meantime, you can apply the patch in NSS bug 737802 to the NSS source
tree.  The URL for the patch is
https://bug737802.bugzilla.mozilla.org/attachment.cgi?id=608587

Thanks to Rob Stradling of Comodo for reporting the bug and providing a
patch.

Wan-Teh Chang
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Mozilla Team-about the upcoming branding changes at Symantec/VeriSign, and working to implement them in Mozilla/Firefox

[Wan-Teh Chang]

On Fri, Mar 9, 2012 at 9:56 AM, Brian Smith bsm...@mozilla.com wrote:

 The second question is: Should we change the string in the display of the 
 *root* certificate from VeriSign, Inc. to Norton.

Ideally this string should come from the certificate.  The fundamental
purpose of a certificate is to bind a public key to a name.  If the
displayed name is not in the certificate, that will confuse the user
when he opens the certificate viewer dialog and sees no mention of
Norton in the certificate.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Review of changes to the HTTP spec

[Wan-Teh Chang]

On Thu, Jan 19, 2012 at 1:43 AM, Brian Smith bsm...@mozilla.com wrote:
 HTTPbis seems to be in its final stages. Although it is supposed to be a
 somewhat minor revision, quite significant changes have been made to
 the spec. We should review the changes and make sure we provide our
 feedback before it is too late. In particular, if there is some change that
 we think we will not implement because we think the change is bad for
 whatever reason, we should push back on the change. That is probably
 the only useful feedback we could have this late in the game.

Brian,

Did you mean to post this message to the dev-tech-network discussion group?

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Removal of NSS and/or NSPR from the API exposed to addons

[Wan-Teh Chang]

On Wed, Jan 18, 2012 at 2:44 PM, Brian Smith bsm...@mozilla.com wrote:
 Mike Hommey wrote:
 Please note that this is going to be a problem on systems that have
 system nspr and nss libraries that other system libraries use.

 I am intending to avoid changing how NSS is linked on Linux, at least at the 
 beginning.

On Linux and other Unix platforms where NSS is available as a system library,
we cannot ask third-party code to not use NSS.  It is best for libxul
to continue
to link with NSS as shared libraries on those platforms.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

[Wan-Teh Chang]

On Wed, Jan 4, 2012 at 3:51 PM, Brian Smith bsm...@mozilla.com wrote:

 But, it is a little distressing that Google Chrome seems to avoid libpkix
 whenever possible, ...

This is not true.  In fact, Google Chrome is an early adopter of libpkix,
and works very hard to fix or work around the bugs in libpkix.  (Google
Chrome uses the libpkix in system NSS, so it has to work around
libpkix bugs before the fixes appear in system NSS.)

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS 3.13.1 release to fix regression caused by NSS 3.13 bug 693228

[Wan-Teh Chang]

On Tue, Oct 18, 2011 at 2:41 PM, Brian Smith bsm...@mozilla.com wrote:
 Will we release a special update to NSS 3.13 to fix the regression bug 
 693228, or will we wait until the next release?

NSS 3.13.1 will be that special update to NSS 3.13 to fix bug 693228
and any other regressions we know of.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [ANNOUNCE] NSS 3.13 Release

[Wan-Teh Chang]

On Mon, Oct 17, 2011 at 1:11 AM, Gen Kanai gka...@gmail.com wrote:

 4. Ported to iOS. (Requires NSPR 4.9.)
 Hi Wan-Teh,

 Thank you for this notice.

 I'm more just curious but do we know of any publicly software shipping
 for iOS that uses NSS 3.13?

I don't know of any.  FYI, here is the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=680878

Note: the patches showed that for the functionality used
by NSS, iOS is almost the same as Mac OS X.  Other
than build system changes, the only difference is that
the _NSGetEnviron() function is not available.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

[ANNOUNCE] NSS 3.13 Release

[Wan-Teh Chang]

NSS 3.13 has been released.  The CVS tag is NSS_3_13_RTM.
The source tar file can be downloaded from
https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_13_RTM/.

You can find the new features and bug fixes in NSS 3.13 with this
Bugzilla query:
https://bugzilla.mozilla.org/buglist.cgi?list_id=1496878resolution=FIXEDclassification=Componentsquery_format=advancedtarget_milestone=3.13product=NSS

Some notable changes include:

1. SSL 2.0 is disabled by default.

2. A defense against the SSL 3.0 and TLS 1.0 CBC chosen plaintext attack
demonstrated by Rizzo and Duong (CVE-2011-3389) is enabled by default.
Set the SSL_CBC_RANDOM_IV SSL option to PR_FALSE to disable it.

3. SHA-224 is supported.

4. Ported to iOS. (Requires NSPR 4.9.)

5. Added PORT_ErrorToString and PORT_ErrorToName to return the
error message and symbolic name of an NSS error code.

6. Added NSS_GetVersion to return the NSS version string.

7. Added experimental support of RSA-PSS to the softoken only
(by Hanno Böck, http://rsapss.hboeck.de/).

Wan-Teh Chang
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How is the official for NSS in coverity?

[Wan-Teh Chang]

On Fri, Oct 14, 2011 at 10:14 AM, Elio Maldonado emald...@redhat.com wrote:
 Hi all,

 NSS is listed as its own project and as a rung 1 project at
 http://scan.coverity.com/rung1.html
 if I understand correctly means there is an official contact for nss.

 I need to see the results of the nss coverity scans for nss but I must
 first register and be vouched for as as legitimate contributor by the
 official contact. Who is that official contact?

I guess it's Nelson.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Mozilla NSS and DANE

[Wan-Teh Chang]

On Thu, Oct 13, 2011 at 3:54 AM, Pontus Ericson kpc.eric...@gmail.com wrote:
 Hi

 I mailed this mailinglist a few weeks ago regarding the development of
 DNS-based certification authentication for S/MIME.

 I am now starting the project fully and I'm going to use Thunderbird/Mozilla
 NSS in the development. I was not part of the mailinglist at the time of my
 first mail so if any answer to that mail got directed to the list I did
 sadly not recieve it.

Hi Pontus,

Here is the reply I sent last time:

  Are you sure DANE can be used to verify email certificates?  We don't
  use DNS to resolve email addresses.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Explicitly distrusted certificates in certdata.txt (NSS built-in root CA certificate list)

[Wan-Teh Chang]

Florian Weimer reported this issue to us.

The certdata.txt file in the NSS source tree
(http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/builtins/certdata.txt)
is the master source of the NSS built-in trusted root CA list, so
people have written scripts to extract the trusted root CA
certificates from this file.  Florian Weimer provided us with the
following examples:
https://atlaswww.hep.anl.gov/twiki/bin/view/UsAtlasTier3/FetchingCA-bundle
http://cblfs.cross-lfs.org/index.php/OpenSSL
http://curl.haxx.se/docs/parse-certs.txt

Originally certdata.txt contained only trusted root CA certificates,
so some of those scripts may have relied on that fact and ignore the
trust objects for certificates in that file.

After the two CA break-in incidents this year, certdata.txt started to
contain several explicitly distrusted certificates.  Scripts that
extract trusted root CA certificates from certdata.txt must now check
the trust objects.

Here are the instructions.

For each trust object in certdata.txt, you can find the associated
certificate object in two ways:
1. By matching the issuer and serial number pair (the CKA_ISSUER and
CKA_SERIAL_NUMBER attributes).  This method is recommended because
this is the method NSS itself uses.
2. By matching the certificate SHA-1 hash (the CKA_CERT_SHA1_HASH
attribute).  Only the trust objects have this attribute.  The
certificate objects do not have this attribute, so you'll need to
compute SHA-1 over the certificate data yourself.

After you match a trust object to a certificate, check the
CKA_TRUST_SERVER_AUTH, CKA_TRUST_EMAIL_PROTECTION, and
CKA_TRUST_CODE_SIGNING attributes in the trust object.

In the current version of certdata.txt, these attributes may have only
three possible values:
- CKT_NSS_TRUSTED_DELEGATOR: this means the CA is trusted for that purpose.
- CKT_NSS_TRUST_UNKNOWN: this means the CA is not trusted for that
purpose, but is trusted for some other purpose.
- CKT_NSS_NOT_TRUSTED: this means the certificate (which may not be a
CA) is explicitly distrusted.

Note: I recommend that the scripts assert that these attributes only
have these three values, so that it can detect when this assumption is
no longer true.

The scripts must exclude the certificates whose trust objects contain
CKT_NSS_NOT_TRUSTED in any of the CKA_TRUST_SERVER_AUTH,
CKA_TRUST_EMAIL_PROTECTION, and CKA_TRUST_CODE_SIGNING attributes.

Wan-Teh Chang
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS patch for TLS timing attack on elliptic curve cyrptography

[Wan-Teh Chang]

On Fri, Sep 23, 2011 at 2:02 PM, Douglas Stebila doug...@stebila.ca wrote:
 Perhaps someone will take a look at this forlorn bug and patch?

 https://bugzilla.mozilla.org/show_bug.cgi?id=660394

Yes, I can take a look at the patch.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Thunderbird/Mozilla NSS and DANE

[Wan-Teh Chang]

On Thu, Sep 22, 2011 at 5:22 AM, Pontus Ericson kpc.eric...@gmail.com wrote:
  Hi.

 My name is Pontus Ericson and I'm a computer science student at the Royal
 Institute of Technology in Stockholm, Sweden. I am currently doing my master
 thesis where I will explore the possibility of deploying DANE (DNS-based
 Authentication of Named Entities) to S/MIME. The goal is to move
 certification from CA's to validating certificates directly with the DNS.
 Thus I will modify (among other things) how certificates are validated and
 enrolled, thus I am looking for a mail client to use during this project.

Are you sure DANE can be used to verify email certificates?  We don't
use DNS to resolve email addresses.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

[ANNOUNCE] NSS 3.12.11 Release

[Wan-Teh Chang]

The NSS 3.12.11 release is now available.  The CVS tag is NSS_3_12_11_RTM.
The source tarball can be downloaded from
https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_12_11_RTM/src/

The bugs fixed in NSS 3.12.11 can be found with this Bugzilla query:
https://bugzilla.mozilla.org/buglist.cgi?list_id=1105376resolution=FIXEDclassification=Componentsquery_format=advancedtarget_milestone=3.12.11product=NSS

plus the following bug:

Bug 668397: Crash when verifying certificate chain containing Fortezza
certificates
(the smaller patch for NSS_3_12_BRANCH only)

Wan-Teh Chang
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Protecting PRNG against malicious users / multiple independent PRNG states

[Wan-Teh Chang]

On Tue, Jul 26, 2011 at 1:30 PM, Brian Smith bsm...@mozilla.com wrote:
 Mozilla would like to expose a secure PRNG (basically, a wrapper around 
 PK11_GenerateRandom) to JavaScript content:
 https://bugzilla.mozilla.org/show_bug.cgi?id=440046

 There is some agreement that we should maintain separate PRNG state for each 
 origin (roughly: domain name), and that all those states should be separate 
 from the PRNG state used internally. PK11_GenerateRandom currently shares the 
 PRNG state across all callers. Does anybody disagree about this separation 
 being necessary?

I just want to note my objection to this proposal before I forget
again.  I won't repeat the arguments given by Nelson Bolyard and Marsh
Ray.

Wan-Teh Chang
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: nss build on windows

[Wan-Teh Chang]

On Fri, Apr 29, 2011 at 6:30 AM, Nate Hoellein natehoell...@gmail.com wrote:
 Hi - I'm attempting to build nss on windows and getting the following
 output:

 code
 $ make nss_build_all
 cd ../coreconf ;  make
 make[1]: Entering directory `/c/mozilla/security/coreconf'
 cd nsinstall; make export
 make[2]: Entering directory `/c/mozilla/security/coreconf/nsinstall'
 make[2]: Nothing to be done for `export'.
 make[2]: Leaving directory `/c/mozilla/security/coreconf/nsinstall'
 cd nsinstall; make libs
 make[2]: Entering directory `/c/mozilla/security/coreconf/nsinstall'
 make[2]: Nothing to be done for `libs'.
 make[2]: Leaving directory `/c/mozilla/security/coreconf/nsinstall'
 make[1]: Leaving directory `/c/mozilla/security/coreconf'
 make: *** No rule to make target `../../nsprpub/configure', needed by
 `../../nsp
 rpub/WINNT6.0_gcc_DBG.OBJ/config.status'.  Stop.
 /code

 I followed the instructions from here:
 http://www.mozilla.org/projects/security/pki/nss/nss-3.7.7/nss-3.7.7-build.html

The build instructions for current versions of NSS are at
https://developer.mozilla.org/en/NSS_reference/Building_and_installing_NSS/Build_instructions

 Feels like I'm missing something very small, any advice would be
 appreciated.

 Running with vs 2008 with all environment variables set.

If you use Visual Studio (the default), your WINNT6.0_gcc_DBG.OBJ
directory name should not have _gcc in it.  You may have set the
environment or build variable NS_USE_GCC=1 incorrectly.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Policy Update Discussion: Third-Party SubCAs

[Wan-Teh Chang]

On Thu, Apr 28, 2011 at 4:50 AM, Jean-Marc Desperrier jmd...@gmail.com wrote:

 BTW isn't there somewhere a page with the corespondance between NSS and
 Firefox version ? I believe there is one, but can't find it again.

The page is 
http://www.mozilla.org/projects/security/pki/nss/mozilla-nss-versions.html.
I haven't updated it for a long time.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Policy Update Discussion: Third-Party SubCAs

[Wan-Teh Chang]

On Wed, Apr 27, 2011 at 6:42 AM, Jean-Marc Desperrier jmd...@gmail.com wrote:
 Jean-Marc Desperrier wrote:

 Johan Sys wrote:

 [...]
 We did some tests with name constraints with positive results:
 SubCA with name constraint as follows :
 Permitted
 [1]Subtrees (0..Max):
 DNS Name=.goodcompany.globalsign
 Excluded=None

 Issued cert www.goodcompany.globalsign passes. Anything else in CN or
 SAN, including hostname and IP addresses gives the expected
 ‘The Certifying Authority for this certificate is not permitted to
 issue a certificate with this name.
 (Error code: sec_error_cert_not_in_name_space)’ in Firefox.

 I'm very surprised actually. I thought bug 479393 / 651246 (use libpkix
 for all certificate validation) was needed for this to work properly.

 Will forward this to mozilla.dev.tech.crypto to get some info about how
 it can work.

The classic certificate verification functions in NSS support name
constraints.  It is not necessary to use libpkix.

The only recent change in this area is
https://bugzilla.mozilla.org/show_bug.cgi?id=394919, fixed in NSS
3.12.7.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS 3.12.5 'libssl3:SSL_OptionGet' not returning?

[Wan-Teh Chang]

On Mon, Apr 11, 2011 at 1:45 AM, Bernhard Thalmayr
bernhard.thalm...@painstakingminds.com wrote:
 Hi experts,

 I'm experiencing an interesting issue.

 OpenAM url-policy agent, which is using NSS/NSPR, 'hangs' when trying to
 establish a connection to an SSL-enabled server.

 OS: Solaris10
 Machine: Sun Fire T2000 (CMT)
 NSS: 3.12.5
 NSPR: 4.8.2


 Trussing the process shows the following ...

 3226/1:                97.4203 getpeername(20, 0xFFBFE140, 0xFFBFE0DC,
 SOV_DEFAULT) Err#134 ENOTCONN
 3226/1@1:       97.4217 - libssl3:SSL_ImportFD() = 0x3a0a98
 3226/1@1:       97.4223 - libssl3:SSL_OptionGet(0x3a0a98, 0x1, 0xffbfe217,
 0xfed6f270)
 3226/1@1:       97.4430   - libnspr4:PR_GetIdentitiesLayer(0x3a0a98, 0x1,
 0x42daa8, 0xfecdca21)
 3226/1@1:       97.4646   - libnspr4:PR_GetIdentitiesLayer() = 0x3a0a98
 3226/1@1:       97.4652   - libnspr4:PR_EnterMonitor(0x4328f0, 0x1,
 0x3a0a98, 0x1)
 3226/1@1:       97.4863   - libnspr4:PR_EnterMonitor() = 0x4328f0
 3226/1@1:       97.4869   - libnspr4:PR_EnterMonitor(0x432968, 0x1,
 0x4328f8, 0x1)
 3226/1@1:       97.5079   - libnspr4:PR_EnterMonitor() = 0x432968
 3226/1@1:       97.5085   - libnspr4:PR_ExitMonitor(0x432968, 0x1,
 0x432970, 0x1)
 3226/1@1:       97.5308   - libnspr4:PR_ExitMonitor() = 0
 3226/1@1:       97.5315   - libnspr4:PR_ExitMonitor(0x4328f0, 0x1,
 0x432970, 0x1)
 3226/1@1:       97.5529   - libnspr4:PR_ExitMonitor() = 0

 The truss ends with this ... no further info.

It's bad that the getpeername() call failed with ENOTCONN.
NSS calls getpeername() to determine if the TCP socket
is connected:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/sslsock.crev=1.70mark=1232,1265#1230

You should find out why OpenAM url-policy agent is
calling SSL_ImportFD on a TCP socket that's not
connected.

 Could you pleas advice me how to track down this issue?

Build NSS/NSPR and OpenAM url-policy agent with debug
symbols, and attach dbx to the process to get the stack
traces of all the threads?

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Initialization of PKCS#11 crypto module changed since NSS 3.12.5?

[Wan-Teh Chang]

On Thu, Apr 21, 2011 at 1:06 PM, Bernhard Thalmayr
bernhard.thalm...@painstakingminds.com wrote:
 Hi experts, according to
 'https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables'
 PKCS#11 crypto module will throw an error if not initialized by the process
 which will use it (even it has been initialized by the parent process).

I guess you're referring to the NSS_STRICT_NOFORK environment variable.

 It seems this behaviour has been changed with NSS 3.12.9 or
 (3.12.8,3.12.7,3.12.6) as I don't get an error using NSS 3.12.9 but NSS
 3.12.5.

 I've read all available release notes but could not find a hint when and why
 this has changed.

 So the question arises ...do I have to change the way of initializing NSS or
 not?

In the bugs fixed in NSS 3.12.6 - 3.12.9:
https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXEDclassification=Componentsquery_format=advancedproduct=NSStarget_milestone=3.12.6target_milestone=3.12.7target_milestone=3.12.8target_milestone=3.12.9

I believe this bug, fixed in NSS 3.12.9, causes the change you observed:
https://bugzilla.mozilla.org/show_bug.cgi?id=610843

It seems that you need to call the new SECMOD_RestartModules function
in the child process.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS 3.9.12 core-dump in SSL_OptionGet

[Wan-Teh Chang]

On Wed, Apr 20, 2011 at 3:27 AM, Bernhard Thalmayr
bernhard.thalm...@painstakingminds.com wrote:
 Hi experts, it would be great if some could shed some light on the
 following

 OpenAM web-agents are using NSS/NSPR for outbound connections.

 I get a core-dump of Apache http server when agent is doing outound
 ssl-connection on Solaris 10 SPARC (32bit-apache httpd and nss)

 pstack shows me...

 bash-3.00# pstack httpd-core-nss-3.12.9-DBG | more
 core 'httpd-core-nss-3.12.9-DBG' of 15276:      /usr/apache2/bin/httpd -k
 start
  fe444b70 SSL_OptionGet (dde48, 1, ffbfe847, fff8, f9, ddfec) + 3d8
  fe6a2844
 __1cDsmiKConnectionMsecureSocket6MrknDstdMbasic_string4Ccn0CLchar_trai
 ts4Cc__n0CJallocator4Ccrk3bpnKPRFileDesc__9A_ (ffbff104, 177214, 177218,
 fe7
 5c9e9, dde48, fe7807b0) + 84

 I've built NSS 3.12.9 with debug flags [... omitted...]

Since the NSS libraries are debug builds, please open the
core file with gdb to get a better stack trace (that has
function argument names and source file names and line
numbers), and print the values of the relevant variables.

SSL_OptionGet is a simple function.  There are only
a couple of places where it is likely to crash:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/sslsock.crev=1.70mark=755,809#754

It seems that the second argument passed to SSL_OptionGet
is 1, which is SSL_SECURITY:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl.hrev=1.41mark=96#95

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS 3.9.12 core-dump in SSL_OptionGet

[Wan-Teh Chang]

On Wed, Apr 20, 2011 at 7:46 AM, Bernhard Thalmayr
bernhard.thalm...@painstakingminds.com wrote:
 Thanks for the pointer Wan-Teh

 meanwhile I already used dbx and got this ...

You're right.  I haven't used Solaris for a long time.  If
you compile the code with Sun Studio compilers, you
should use dbx.

 Current function is SSL_OptionGet
  809       *pOn = on;
 current thread: t@1
 =[1] SSL_OptionGet(fd = 0x135d48, which = 1, pOn = 0xffbfe7df), line 809 in
 sslsock.c
  [2] smi::Connection::secureSocket(0xffbff09c, 0x201ec4, 0x201ec8,
 0xfe75c9e9, 0x135d48, 0xfe7807b0), at 0xfe6a2844


 The related agent-code looks like this ... I think it's not correct...

 if (SECSuccess == secStatus) {
                sslMethodName = SSL_OptionSet;
                {
                    bool state;
                    secStatus = SSL_OptionGet(sslSocket,SSL_SECURITY,
 (PRBool*)state);

Yes, that code is wrong.

The third-argument of SSL_OptionGet is PRBool *pOn, so
the local variable 'state' should be declared as 'PRBool' instead
of 'bool'.

PRBool is the same as 'int', which is 4 bytes.
'bool' is apparently one byte because the address of 'bool state'
is 0xffbfe7df.  Note the 'f' (= decimal 15) at the end, which is
not a multiple of 4.

If you change the last two lines to:

   PRBool state;
   secStatus = SSL_OptionGet(sslSocket,SSL_SECURITY, state);

that should fix the crash.  Note that the compiler may have warned
about the wrong argument type, which could be why the (PRBool*)
was added (incorrectly).

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Certificate Problem in FF 4

[Wan-Teh Chang]

On Fri, Apr 8, 2011 at 12:50 PM, Honza Bambas hon...@allpeers.com wrote:
 I'm getting the no issuer chain error even when I first visit the
 https://crm.ausnetservers.net.au link with an empty (clean) profile - so
 there is certainly no cert exception nor any additional certificates.

 I don't think this is a Firefox bug.  If you feel opposite please provide
 more info how to reproduce.

Honza,

Thank you for looking.

The SSL Certificate message from https://crm.ausnetservers.net.au
contains only one certificate.  It is missing the intermediate CA
certificate for
  CN=RapidSSL CA,O=GeoTrust, Inc.,C=US

So this is a server misconfiguration.

The missing intermediate CA can be downloaded from
http://rapidssl-aia.geotrust.com/rapidssl.crt
and imported into Firefox to work around this server
misconfiguration.  Note: do NOT check any of the
Trust this CA to xxx checkboxes when importing
an intermediate CA certificate into Firefox.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: CERT_PKIXVerifyCert does not recognize bogus certificates contained in nssckbi.dll

[Wan-Teh Chang]

On Thu, Apr 7, 2011 at 5:26 AM, Joachim Lingner
joachim.ling...@oracle.com wrote:
  Hi,

 I am testing NSS 3.9.12 with CKBI 1.82 on Windows. To verify that the bogus
 certificates are recognized as such I run vfychain. The certificates are
 exported from the Windows certificate store.

 Having vfychain use CERT_VerifyCertificate gives me this output


 [../nss/wntmsci12.pro/bin]$ ./vfychain.exe -d db -p  www-google.cer
 Chain is bad!
 PROBLEM WITH THE CERT CHAIN:
 CERT 0. Builtin Object Token:Bogus Google :
  ERROR -8171: Peer's certificate has been marked as not trusted by the user.
 [../nss/wntmsci12.pro/bin]$

 Same with all other bogus certificates.
 Now using the CERT_PKIXVerifyCert function:

 [../nss/wntmsci12.pro/bin]$ ./vfychain.exe -d db -pp  -g leaf www-google.cer
 Chain is good!
 [../nss/wntmsci12.pro/bin]$

 Let nss use CRL distribution points proves that the invocation of vfychain
 is correct:

 [../nss/wntmsci12.pro/bin]$ ./vfychain.exe -d db -pp  -g leaf -m crl
 www-google.cer
 Chain is bad!
 PROBLEM WITH THE CERT CHAIN:
 CERT 1. Builtin Object Token:UTN USERFirst Hardware Root CA [Certificate
 Authority]:
  ERROR -8180: Peer's Certificate has been revoked.
 [../nss/wntmsci12.pro/bin]$

 WireShark confirms that the CRL is being fetched via HTTP Get.

 In both cases the nssckbi.dll is loaded from the db folder, as specified by
 the -d switch. I confirmed this by using the ProcessMonitor.

 Have I overlooked something? Can someone confirm this?

Hi Joachim,

I confirm this bug.  I also discovered this bug last Friday:
https://bugzilla.mozilla.org/show_bug.cgi?id=647364

Bob Relyea is working on this bug.

I wrote a patch as a proof of concept for fixing the
CERT_PKIXVerifyCert bug.  Bob will write the real fix.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Promote performance improvements from #559508 and #559510 to 3.12.10?

[Wan-Teh Chang]

On Thu, Apr 7, 2011 at 3:02 PM, Robert Relyea rrel...@redhat.com wrote:

 I had thought these were in, but I was thinking of a different bug with
 a patch by Aleksey. I've marked these as target 3.12.10.

I just checked in the patches in NSS bugs 559508 and 559510 on the
NSS_3_12_BRANCH.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Problems Building NSS on Mac OS X 10.6 (64-bit)

[Wan-Teh Chang]

On Wed, Mar 30, 2011 at 6:45 AM, Kaspar Brand m...@velox.ch wrote:

 Sounds good. security/nss/lib/jar is currently the other place which
 also depends on the NSS_X* macros, i.e. it should be a header file which
 can be used by files outside freebl, too.

I see.  security/nss/lib/util/secport.h is a header where we can define
these NSS_* macros.  It already defines a few such macros:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/util/secport.hrev=1.23mark=53-74#49

The only problem is that secport.h is a public header, so those
NSS_* macro definitions will also be seen by NSS customers.

Another option is to fix security/nss/lib/jar so that it doesn't
use the NSS_X86_OR_X64 macro.  lib/jar is only used by
the NSS command-line tools modutil and signutil, so it isn't
important to rely on x86/x86_64 processors' ability to do
unaligned memory access.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Problems Building NSS on Mac OS X 10.6 (64-bit)

[Wan-Teh Chang]

On Tue, Mar 29, 2011 at 11:21 AM, Mark Mentovai m...@chromium.org wrote:

 I would avoid this. -Xarch_arch is implemented as an Apple GCC
 driverdriver option and isn’t available in mainline GCC or even the
 Apple GCC’s CPU-specific frontends (such as i686-apple-darwin10-
 gcc-4.2.1). -Xarch_arch would allow things to work with Apple GCC and
 would even enable single-pass universal builds, but would ruin things
 for users of non-Apple GCC. NSPR and NSS have striven to be flexible
 with respect to build configurations in the past. I’d be surprised if
 either project were now willing to mandate that Apple GCC (or some
 other Apple-supplied compiler) would be the only compiler that could
 be used to target Mac OS X or Darwin.

Mandating Apple compilers is fine.  Until one or two years ago,
NSPR and NSS were using the -Wmost flag, which is an Apple
extension.  I was the one who noticed the problem.  That's
strong evidence that no one else had tried to compile NSPR
or NSS on the Mac with non-Apple GCC.

But we should use -Xarch_arch only if it offers a simpler solution
than defining arch-specific macros in lib/freebl/blconfig.h.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS in Summer of Code?

[Wan-Teh Chang]

On Wed, Mar 2, 2011 at 3:23 AM, Gervase Markham g...@mozilla.org wrote:

 Usually, we prefer mentors to propose projects because then we know that the
 project is something the mentor is interested in mentoring, and we can
 assess the project as being of an appropriate size and complexity.

Hi Gerv,

Thank you for the clarification.  I proposed two projects.
- OCSP improvements
- Add new crypto algorithms to the NSS softoken

Re: shared SQLite NSS databases: we should start that work as soon
as the Mozilla trunk reopens for post-Firefox 4 development.  Hopefully
it won't fall through the cracks again.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Freezing and making available to js the mp_int bignum package API

[Wan-Teh Chang]

The inability to allocate mp_int variables on the stack is not as bad
as it seems.  This is because the 'dp' array inside an mp_int still
needs to be allocated from the heap.  An mp_new function can allocate
the mp_int structure and the 'dp' array in one shot if the number of
digits needed is known in advance.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS in Summer of Code?

[Wan-Teh Chang]

On Wed, Feb 23, 2011 at 3:26 AM, Gervase Markham g...@mozilla.org wrote:
 Hi NSS team,

 Are any of you interested in submitting a proposal for a Summer of Code
 project for Bugzilla this year, and mentoring it?
 https://wiki.mozilla.org/Community:SummerOfCode11:Brainstorming

Hi Gerv,

I just expressed my interest in being a mentor for an NSS project on that page.

Do mentors need to propose projects?  I thought it's the students who
should submit proposals as part of the applications.  I think it's
better that way because it implies the student is motivated to solve
that particular problem.  Please advise.  Thanks.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Freezing and making available to js the mp_int bignum package API

[Wan-Teh Chang]

On Mon, Feb 28, 2011 at 9:03 AM, Jean-Marc Desperrier jmd...@gmail.com wrote:
 Hi,

 There was some talk last october about accessing the mp_int API from
 javascript, and so freezing it in order to make it available as a frozen
 API.

 Nelson concluded that the one difficult point would be to freeze the mpdigit
 structure, since it currently has machine/processor-version dependent
 definitions.

 I just got interested in trying to revive this subject.
 First, what should serve as the reference definition of the mp_int API ?
 Would it be just
 http://mxr.mozilla.org/security/source/security/nss/lib/freebl/mpi/mpi.h ?

I guess that's the file.  You may need to download the original MPI
distribution and find out which headers are considered the public
header.

 Second, at one point I found this
 http://swtch.com/plan9port/man/man3/mp.html which not in fact exactly the
 same API, but which gave me an interesting idea as inside it the mpint
 functions are completely separated from the mpdigit functions.

 What not use as a public freezed API a version of the API that simply
 removes everything that uses mp_digit ?
 mp_digit is only an optimization in case the manipulated number is small, I
 believe that in many cases this optimization is not very significant. Not
 using it in the public API would not really have a performance impact, and
 would make things much easier I believe.

If you make the mp_int structure opaque, you won't need to
expose the mp_digit type.  So this is certainly a viable
solution.  The downside is that you won't be able to allocate
mp_int local variables; everything mp_int variable needs to
be allocated from the heap.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Path building in Thunderbird

[Wan-Teh Chang]

On Thu, Feb 17, 2011 at 7:10 AM, Stephen Hanna sha...@juniper.net wrote:
 Does Thunderbird support certification path building? If so, how
 is it enabled and configured?

Hi Steve,

I am confused by your question.  An S/MIME client obviously must
support certification path building by default.  Did I miss something?

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: JSS socket closing fix?

[Wan-Teh Chang]

On Tue, Feb 15, 2011 at 8:19 AM, David B Hinz dbh...@raytheon.com wrote:

 Was there a bug fix to JSS 4.2.5, 4.3, or 4.3.1 that dealt with a problem
 with sockets not being closed properly when a client application was
 shutting down?

I don't know which bug you're referring to.

This Bugzilla query returns all the bugs fixed in JSS:
https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXEDclassification=Componentsquery_format=advancedproduct=JSS

This Bugzilla query returns the bugs fixed in JSS 4.2.5, 4.3, or 4.3.1:
https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXEDclassification=Componentsquery_format=advancedproduct=JSStarget_milestone=4.2.5target_milestone=4.3target_milestone=4.3.1

Do you see the bug you're looking for?

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Support for TLS snap start and next-protocol-negotiation extensions in NSS

[Wan-Teh Chang]

On Mon, Jan 31, 2011 at 1:55 AM, mandeep alluru reddy.mand...@gmail.com wrote:
 Hello Everyone,

 I am new to using NSS and have been exploring the features of NSS for
 the past two weeks. I would like to know if NSS supports TLS Next-
 Protocol-Negotiation and TLS snap start extensions. I would be glad if
 you give me some information in this regard.

There is an NSS patch for TLS next protocol negotiation:
https://bugzilla.mozilla.org/show_bug.cgi?id=547312

Because the extension number (0xff01) is still experimental, we can't
check it into NSS.

There is a client-side NSS patch for TLS snap start.  It is in the
Chromium source tree.  Since NSS requires a TLS feature to be
implemented on both client and server sides, I haven't attached that
patch to Bugzilla.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: FireFox v3.0.1 of Windows uses SSLv2 Record Layer even when SSLv2 is disabled

[Wan-Teh Chang]

On Sun, Jan 30, 2011 at 1:32 AM, Nelson B Bolyard nel...@bolyard.me wrote:

 Firefox doesn't send TLS client hellos to servers that fail to complete
 ANY handshake with ANY version of SSL or TLS some number of times in a row
 when it has tried sending TLS client hellos.  Once it decides the server
 is incompatible with TLS client hellos, it stops trying to do that
 and falls back on some OLD OLD behavior where it sends SSL 3.0 client
 hellos encapsulated in SSL 2 records.  They're actually SSL3 hellos,
 but the point is that the server has failed too many times.

Here is the fallback code (in Firefox 3.0.x) that Nelson mentioned:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/manager/ssl/src/nsNSSIOLayer.cpprev=1.166mark=3134-3135,3145-3154#3134

3134   // Let's see if we're trying to connect to a site we know is
3135   // TLS intolerant.
3136   nsCAutoString key;
3137   key = nsDependentCString(host) + NS_LITERAL_CSTRING(:) +
nsPrintfCString(%d, port);
3138
3139   if (nsSSLIOLayerHelpers::isKnownAsIntolerantSite(key)) {
3140 if (SECSuccess != SSL_OptionSet(fd, SSL_ENABLE_TLS, PR_FALSE))
3141   return NS_ERROR_FAILURE;
3142
3143 infoObject-SetAllowTLSIntoleranceTimeout(PR_FALSE);
3144
3145 // We assume that protocols that use the STARTTLS mechanism
should support
3146 // modern hellos. For other protocols, if we suspect a site
3147 // does not support TLS, let's also use V2 hellos.
3148 // One advantage of this approach, if a site only supports the older
3149 // hellos, it is more likely that we will get a reasonable error code
3150 // on our single retry attempt.
3151
3152 if (!forSTARTTLS 
3153 SECSuccess != SSL_OptionSet(fd, SSL_V2_COMPATIBLE_HELLO, PR_TRUE))
3154   return NS_ERROR_FAILURE;
3155   }

I think it is fine to delete the SSL_OptionSet(fd,
SSL_V2_COMPATIBLE_HELLO, PR_TRUE) call now.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Force usage of a certificate for client authentication

[Wan-Teh Chang]

On Thu, Jan 27, 2011 at 6:06 AM, Martin Boßlet
martin.boss...@googlemail.com wrote:

 But I again checked the trust settings for the CA certificates.
 They're fine...

Did you check your client certificate in Firefox 4 to make sure it's
imported correctly?

In Firefox 4, open Options (or Preferences)  Advanced  Encryption 
View Certificates  Your Certificates.  Is your client certificate
listed?

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Force usage of a certificate for client authentication

[Wan-Teh Chang]

On Wed, Jan 26, 2011 at 4:38 AM, Martin Boßlet
martin.boss...@googlemail.com wrote:

 I want to authenticate to a server using TLS client authentication, so
 I imported a PKCS#12 file for this purpose.
 Unfortunately the certificate is from an internal CA that does neither
 issue keyUsage, extendedKeyUsage
 nor NetscapeCertType extensions.

If the client certificate doesn't have any of those extensions, NSS
should allow all uses:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certdb/certdb.crev=1.109mark=453,458-459,469-470#448

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certdb/certdb.crev=1.109mark=692,703-705#691

 From reading previous posts I gathered that when selecting acceptable
 certificates, an acceptable candidate
 must contain the digitalSignature keyUsage and also the
 extendedKeyUsage clientAuthentication.
 I looked through NSS sources and found the following in certdb.c:

 case certUsageSSLClient:
            requiredKeyUsage = KU_DIGITAL_SIGNATURE;
            requiredCertType = NS_CERT_TYPE_SSL_CLIENT;
            break;

 Is this the code that controls whether a certificate is considered as
 a viable candidate?

I think so.  I am not familiar with that part of the NSS code, so I
can't summarize the certificate selection algorithm.  But I think a
client certificate without any of those extensions should be allowed
for all uses.

I wonder if you didn't import the PKCS #12 file correctly, or it's
missing a required intermediate CA certificate.  Please open Tools 
Options  Advanced  Encryption  View Certificates  Your
Certificates.  Does it show the client certificate you imported?

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Problems Building NSS on Mac OS X 10.6 (64-bit)

[Wan-Teh Chang]

On Wed, Jan 19, 2011 at 8:08 PM, Nathan Craike ncra...@gmail.com wrote:
 Is it possible to build the 32-bit version on a 64-bit Mac? The Mac OS X man 
 page for gcc describes an Apple only option -arch:

 -arch arch
            Compile for the specified target architecture arch.  The 
 allowable values are
            i386, x86_64, ppc and ppc64.


 ...but same error occurs (the failing assertion) if I run the make script 
 with this option, as below:

 ncraike@ncraikework 15:54:40 ~/Installs/nss-3.12.9/mozilla/security/nss
 $ CC=gcc -arch i386 CXX=g++ -arch i386 make nss_build_all

The correct command is to pass CC and CXX (or rather, CCC, which is
the variable name used by NSS) to make as make variables as opposed to
environment variables:

$ make nss_build_all CC=gcc -arch i386 CCC=g++ -arch i386

 If I set the USE_64 environment variable:

 ncraike@ncraikework 16:00:09 ~/Installs/nss-3.12.9/mozilla/security/nss
 $ USE_64=1 make nss_build_all

Similarly, this should be

$ make nss_build_all USE_64=1

although passing USE_64=1 as an environment variable also works.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS 3.12.5: Error '-8023' ... how to track it down?

[Wan-Teh Chang]

On Wed, Jan 12, 2011 at 2:38 PM, Robert Relyea rrel...@redhat.com wrote:
 On 01/12/2011 01:26 PM, Bernhard Thalmayr wrote:
 331569088[1bd1610]: C_UnwrapKey
 331569088[1bd1610]:   hSession = 0x6
 331569088[1bd1610]:   pMechanism = 0x7fffcd592ea0
 331569088[1bd1610]:   hUnwrappingKey = 0x8
 331569088[1bd1610]:   pWrappedKey = 0x36ac9bc
 331569088[1bd1610]:   ulWrappedKeyLen = 48
 331569088[1bd1610]:   pTemplate = 0x7fffcd592cf0
 331569088[1bd1610]:   ulAttributeCount = 6
 331569088[1bd1610]:   phKey = 0x36bfd58
 331569088[1bd1610]:     CKA_SIGN = CK_TRUE [1]
 331569088[1bd1610]:     CKA_VERIFY = CK_TRUE [1]
 331569088[1bd1610]:     CKA_CLASS = CKO_SECRET_KEY [8]
 331569088[1bd1610]:     CKA_KEY_TYPE = 0x10 [8]
 331569088[1bd1610]:     CKA_DERIVE = CK_TRUE [1]
 331569088[1bd1610]:     CKA_VALUE_LEN = 3000 [8]
 331569088[1bd1610]:       mechanism = CKM_DES3_ECB
 331569088[1bd1610]:   *phKey = 0x54
 The extra data here is dumping out interesting values inside the
 parameters passed to C_UnwrapKey. The list of CKA_ = X are
 dumping out the template sent in pTemplate. CKA_VALUE_LEN looks wrong to
 me, I don't know if tehre is some byteswap issue here.

I looked into the CKA_VALUE_LEN issue.  I found that our PKCS #11
logger prints CKA_VALUE_LEN as a hex dump.  So
3000 [8]
means a sequence of 8 bytes:
0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00

On a little-endian system (such as x86/x64), this is 48 decimal, which
is the length of the SSL/TLS master secret.

I filed an NSS bug https://bugzilla.mozilla.org/show_bug.cgi?id=625491
to improve the logging of CKA_VALUE_LEN, with a patch.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS 3.12.5: Error '-8023' ... how to track it down?

[Wan-Teh Chang]

On Thu, Jan 13, 2011 at 2:53 AM, Bernhard Thalmayr
bernhard.thalm...@painstakingminds.com wrote:

 It might be helpfull if SSLTRACE and PKCS#11 could log a timestamp to help
 in correlation.

You can add 'timestamp' to the NSPR_LOG_MODULES environment variable.  See
http://www.mozilla.org/projects/nspr/reference/html/prlog.html#25306

This should add timestamps to PKCS #11 logging.  I don't know if
SSLTRACE is based on NSPR logging...

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS 3.12.5: Error '-8023' ... how to track it down?

[Wan-Teh Chang]

On Wed, Jan 12, 2011 at 2:02 PM, Bernhard Thalmayr
bernhard.thalm...@painstakingminds.com wrote:

 Am'I wright that 'C_DeriveKey' is actually 'NSC_DeriveKey' in
 http://mxr.mozilla.org/security/source/security/nss/lib/softoken/pkcs11c.c ?

Yes.  C_DeriveKey is a function pointer.  It points to the
NSC_DeriveKey function.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Firefox PSM locks NSS

[Wan-Teh Chang]

On Tue, Jan 11, 2011 at 4:48 AM, Irune Prado Alberdi ipr...@zylk.net wrote:

 Up to this point I can properly work with my certificates in firefox but when 
 I try to simultaneously access it via certutil I get blocked
 pre
 ~/.pki/nssdb$ certutil -d sql:. -K -h izenpe
 /pre

This doesn't block when I run Google Chrome, which uses ~/.pki/nssdb.
I didn't test with Firefox.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Firefox PSM locks NSS

[Wan-Teh Chang]

On Tue, Jan 11, 2011 at 4:48 AM, Irune Prado Alberdi ipr...@zylk.net wrote:

 While if I terminate the pkcs11 session in firefox I can successfully acces 
 the token
 pre
 $ certutil -d sql:. -K -h izenpe
 certutil: Checking token Builtin Object Token in slot NSS Builtin Objects
 certutil: no keys found
 certutil: Checking token NSS Generic Crypto Services in slot NSS Internal 
 Cryptographic Services
 certutil: no keys found
 certutil: Checking token NSS Certificate DB in slot NSS User Private Key 
 and Certificate Services
 certutil: no keys found
 certutil: Checking token IZENPE in slot Gemplus GemPC Twin 00 00
 Enter Password or Pin for IZENPE:
  0 rsa      ad22bafb47cd03a443ee3c04e4914f5cc52a   PRUEBAS EFACTUR
 /pre

Perhaps it's the IZENPE token, not the NSS sqlite3 DB, that blocks certutil.

The first slot, NSS Builtin Objects, doesn't use sqlite3, so this
shows a later slot can block certutil from output anything.  So any
later slot, not just the NSS DB slot, could be the cause of the
blocking.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS meeting.

[Wan-Teh Chang]

Bob,

Thank you for writing the meeting notes.  I will also be out next week.

NSPR 4.8.7 Beta 2 looks good.  The only additional patch I may include
in NSPR 4.8.7 is the second patch in
https://bugzilla.mozilla.org/show_bug.cgi?id=604263.

Re: NSPR IPv6: for reasons I don't remember and can't find in CVS
history, Darin Fisher and I decided to not use the AI_ADDRCONFIG flag
when we updated NSPR to use getaddrinfo().  Not using AI_ADDRCONFIG is
causing performance problems in some computers.  So there is a recent
push to use AI_ADDRCONFIG.  The only problem I know of with
AI_ADDRCONFIG is that it may prevent you from connecting to
localhost in some computers.  So after we change NSPR to use
AI_ADDRCONFIG, we will need to deal with the potential localhost
problem.  But the localhost problem is less serious than the
performance problem of not using AI_ADDRCONFIG.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: importing leaf cert into NSS db via JSS

[Wan-Teh Chang]

Dave,

I can help you write a patch to fix this problem.

The (-8157) Certificate extension not found part in the error message:
  org.mozilla.jss.crypto.NoSuchItemOnTokenException: Expected user
cert but no matching key?: (-8157) Certificate extension not found
is most likely wrong (a stale error code).  Please try to track that down
and fix it.

I would go with adding an importNonUserCertPackage method,
or add a new method that exposes both the boolean noUser
and boolean leafIsCA parameters of the native method
importCertPackageNative.

Note: importCertPackage is documented to detect and handle
user certificates automatically, so ideally we should try to make
it work as documented.  This may require adding a new
native method to do that.  To avoid duplicating too much code,
some refactoring of the existing native method
importCertPackageNative would be necessary.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS ss-sec.uncache is NULL

[Wan-Teh Chang]

Hi passfree:

On Wed, Nov 24, 2010 at 9:32 AM, passfree passf...@googlemail.com wrote:

 I am developing a generic SSL pipe XPCOM component which can be used
 on any Input/Output stream pair. So far it sort of works but I am
 facing one problem and I am not sure how to deal with it. The problem
 arrises when a client connects to a server but refuses to continue
 because of certificate errors. Lets say that we have an input stream
 from a ServerSocket. This input stream is wrapped with my SSL pipe
 component. If the client connects but refuses to continue, due to the
 SSL certificate is invalid for the current domain name, the code will
 fail with a crash within ssl3con.c, ssl3_HandleAlert function, on the
 following line:

    if (level == alert_fatal) {
        ss-sec.uncache(ss-sec.ci.sid);

 The reason it fails is because ss-sec.uncache is set to null, 0, i.e.
 nothing there to access.

 The question is why is this happening and what I should do to fix the
 problem. Perhaps I need to init my ssl fd differently?

You are running into a variant of NSS bug 540535:
https://bugzilla.mozilla.org/show_bug.cgi?id=540535

Your report shows both SSL3_SendAlert and ssl3_HandleAlert
have this problem.

You can avoid this problem by configuring an SSL server session
ID cache, with either a SSL_ConfigServerSessionIDCache or
SSL_ConfigMPServerSIDCache call.

If you build NSS from source code, can you print in the
debugger if ss-sec.ci.sid is NULL at that point?  Then,
please try changing the code to:

   if (level == alert_fatal) {
   if (ss-sec.uncache) {
   ss-sec.uncache(ss-sec.ci.sid);
   }

Does that fix the problem?  Thanks.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Plan B for J-PAKE in Fennec B3 / Firefox B9 -- exposing MPI to Firefox for one beta cycle

[Wan-Teh Chang]

On Thu, Nov 18, 2010 at 3:08 PM, Brian Smith bsm...@mozilla.com wrote:
 (Note that this is to: dev-tech-crypto)

 Short Version: We are looking at taking a private patch for one Firefox beta 
 cycle in
 mozilla-central to export the MPI functions from FreeBL on all platforms in 
 our private
 copy of NSS. Then, we could push the next NSS 3.12 release to the week after
 American Thanksgiving instead of the week of American Thanksgiving. Please 
 let me
 know if you know of a reason why this wouldn't work.

Firefox's private copy of NSS is maintained by the PSM module owners:
https://wiki.mozilla.org/Modules/All#Security_-_Mozilla_PSM_Glue

You'll need to get review+ from a PSM module owner.  Just like a good QA
team should not ignore critical test failures in spite of an imminent deadline,
a good code reviewer should not allow a fellow programmer to cut serious
corners in coding in spite of an imminent deadline.

We are not talking about an Alpha or developer preview release.
This is Firefox Beta 9/ Fennec Beta 4.  At this point in the release
cycle, shouldn't we be fixing only release blocker bugs, rather than
rushing new features in?

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Can a ssl3.ca_list be configured on a model file descriptor?

[Wan-Teh Chang]

On Tue, Nov 9, 2010 at 9:23 PM, Wolter Eldering
wolter.elder...@vanad.com.cn wrote:

 Hi Wan-Teh,

 I was wondering if you found my patches useful? Or maybe I can help in any
 way.

Hi Wolter,

Thank you for attaching your patches and test results to bug 595134:
https://bugzilla.mozilla.org/show_bug.cgi?id=595134

I'm sorry that I had not reviewed your patches until you pinged me.
I believe that the performance problem that some Linux Chrome users
ran into is different, because they don't have any certificates in the
NSS certificate DB.  Their performance problem is caused by merely
accessing the NSS certificate DB in a network filesystem (NFS to
be specific).

I looked at your patches quickly, and I can tell you understand
what the problem is.  I'll need to ask Bob Relyea to review your
patches, as he knows SQLite much better than I do.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Fennec M8 Code - HTTPS Links not working

[Wan-Teh Chang]

On Wed, Oct 27, 2010 at 10:25 PM, Ashok Subash subash.as...@gmail.com wrote:

 Now i could initialize NSS successfully and created the cert and key
 db using SQL Lite as the database.
 Now am getting a SSL Connect error when browsing secure site like
 gmail.com

What's the error code when SSL Connect fails?

 So i check the options in about:config of Firefox 3.6.11 and saw ssl2
 disabled and ssl3 enabled.
 Also there is big list of encryption and authentication algo options
 which are enabled and disabled.

 Do i need to enable the same set of options for Fennec too?

I think so.  Isn't Fennec the mobile version of Firefox?

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Fennec M8 Code - HTTPS Links not working

[Wan-Teh Chang]

On Sat, Oct 23, 2010 at 5:06 AM, Ashok Subash subash.as...@gmail.com wrote:

 Hi Wan-Teh,

 I hope i can disable the NSSDBM module without affecting anything else
 in static DLL approach. I'm assuming it will be then SQLite for
 storing all the certs and keys.

Yes, that's correct.

 I'm planning to debug with an empty directory and i hope NSS will
 create the required DBs. Please confirm.

Yes.  You must create the directory where the DBs will reside, but I
remember NSS will create the DBs if they don't exist.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Fennec M8 Code - HTTPS Links not working

[Wan-Teh Chang]

On Fri, Oct 22, 2010 at 8:33 AM, Ashok Subash subash.as...@gmail.com wrote:

 Is there any other files that i need to port other than NSPR.

Probably not.  NSS depends on the following:
- Standard C Library
- NSPR

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Usage of FreeBL and FreeBL/mpi through JavaScript in Firefox 4 Sync

[Wan-Teh Chang]

On Thu, Oct 21, 2010 at 3:53 PM, Nelson B Bolyard nel...@bolyard.me wrote:

 I'd say the interfaces to those functions (more precisely, their
 signatures) are quite frozen.  The mp_int bignum package API is so
 frozen as to have become something of a standard of its own.  There
 are now at least 3 different implementations known to me that are all
 API compatible, differing only in the content of the (opaque) mp_int
 structure itself.

 Speaking only for myself, I have no objection to offering the mp_int
 bignum API as a public API out of freebl3.  They're not presently
 exported from the freebl shared lib at all, but IMO, they could be.
 We merely wanted to minimize the exported API.

We also need to undo some processor-version-specific type definitions.
An example is the mp_digit type for 64-bit Solaris SPARC.  mp_digit
is defined differently for different versions of the SPARC v9a processors:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/Makefilerev=1.115mark=420-432#420

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS and PKCS#11 Certificate+Private key

[Wan-Teh Chang]

On Sun, Oct 10, 2010 at 7:45 AM, Matej Kurpel mkur...@gmail.com wrote:

 What turned out to be the problem, was that
 the CK_BBOOL values were 4-bytes and not 1 byte in size. Took some hours and
 some hair to discover, but hopefully someone finds this if he has the same
 problem and solves it right away :)

CK_BBOOL is ultimately defined as 'unsigned char', so it is one byte in size.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/util/pkcs11t.hrev=1.20mark=70,78-79#69

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: to make all libraries static

[Wan-Teh Chang]

Hi Dmitry,

I published unsupported patches for using NSS as static libraries in
https://bugzilla.mozilla.org/show_bug.cgi?id=534471.  (Please do not
post questions in that bug report.  I want to keep the bug report
focused on the patches.)  You're welcome to try them.  Note that I
didn't go all the way -- the built-in trust root CA certificates
module (nssckbi.dll) is still a separate DLL.

On Fri, Oct 8, 2010 at 9:25 AM, Dmitry Sokolov branc...@mail.ru wrote:
 I mean the architecture of the NSS does
 not really require shared modules of code, do it?

It doesn't require shared modules of code for the built-in crypto
module (softokn3.dll), but it needs to be able to load third-party
crypto modules (such as smart cards or alternative software crypto
modules) as shared modules of code.  My patch changes NSS to link with
the softokn3.dll code statically, but still allows NSS to load
third-party crypto modules dynamically.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Support for SSL False Start in Firefox

[Wan-Teh Chang]

On Tue, Oct 5, 2010 at 6:28 AM, Jean-Marc Desperrier jmd...@gmail.com wrote:
 Hi,

 Google is currently communicating about how they will use SSL False Start to
 accelerate the web, even if it means breaking a small fraction of
 incompatible site (they will use a black list that should mitigate most of
 the problem).
 See http://news.cnet.com/8301-30685_3-20018437-264.html

 Am I right that there is currently no bug and no plan to make available in
 Firefox the False Start support that's has been included in NSS in bug
 525092 ? (as noted here
 https://bugzilla.mozilla.org/show_bug.cgi?id=525092#c24 making it minimally
 available requires one call to set the SSL_ENABLE_FALSE_START option, and a
 preference to optionally disable it. Handling the black list is more work, I
 don't know if Google plans to make their list a public resource, maybe
 Wan-Teh Chang can tell)

It was added, and then disabled by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=583908
https://bugzilla.mozilla.org/show_bug.cgi?id=591523

The False Start blacklist is a public resource.  It is published in
the Chromium source tree.

Disabling False Start in Firefox 4 was the right decision because
without additional changes to NSS or PSM, the failures caused by False
Start are nondeterministic, depending on the arrival times of the
client's Finished message and the first application data record.
Nondeterministic failures make debugging very difficult. In addition,
the Mozilla team is uncomfortable using a blacklist.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Can a ssl3.ca_list be configured on a model file descriptor?

[Wan-Teh Chang]

On Fri, Sep 24, 2010 at 11:12 PM, Wolter Eldering
wolter.elder...@vanad.com.cn wrote:

 I've added my patches and some test results to bug:
 https://bugzilla.mozilla.org/show_bug.cgi?id=595134

Thank you very much!

 I needed to start chrome like this: chrome-linux/chrome-wrapper
 --single-process --enable-dnssec-certs to get the environment variables to
 be seen by chrome

You should not use the --single-process option.  It is intended
for testing only.

The filesystem speed test in NSS softoken is broken with the
current version of sqlite, so we have to set the environment
variable NSS_SDB_USE_CACHE=yes to force it to use cache.

I remember I also had to start chrome from the command line
to get the NSS_SDB_USE_CACHE=yes environment variable
to be seen by chrome.  Or I may have modified the chrome
wrapper script to set the environment variable in it.

 I also added the  --enable-dnssec-certs because I noticed from the code that
 CERT_GetCertChainFromCert is called. As far as I can see the whole chain
 will be build with again and again. each certificate in the chain takes
 about 4 sqlite queries.

You may have misunderstood the effects of --enable-dnssec-certs.
I seem to remember with --enable-dnssec-certs, Chrome will still
go through the normal certificate verification code path if the server's
certificate (or rather, public key) is not in DNS.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Can a ssl3.ca_list be configured on a model file descriptor?

[Wan-Teh Chang]

On Sun, Sep 19, 2010 at 12:39 AM, Wolter Eldering
wolter.elder...@vanad.com.cn wrote:

 Because we deal with a large number of certificates I've also have some
 patches to reduce the number of queries to the sql: type database.
 And a patch that will make the NSS_SDB_USE_CACHE=yes perform much better. We
 use NSS_SDB_USE_CACHE=yes so we can access it from gfs2.

 What's the best way to submit these patches?

Hi Wolter,

The best way to submit your NSS patches is to
file NSS bug reports on the problems your patches
are intended to address, and then attach the patches
as attachments to the bug reports.

Here is an example:
https://bugzilla.mozilla.org/show_bug.cgi?id=597622

I am especially interested in your patches for
reducing the number of queries to the sql: databases,
and for making the NSS_SDB_USE_CACHE=yes
perform much better.  Some of the Linux Chrome
users run into serious SSL performance problems
that were linked to their sql: databases being on
NFS.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

[Wan-Teh Chang]

On Mon, Aug 30, 2010 at 8:12 AM, Brian Smith br...@briansmith.org wrote:
 Wan-Teh Chang wrote:
 I propose that we remove SSL 2.0 support from the NSS trunk (NSS 3.13).

 Would this include support for SSLv2-v3 upgrade hellos?

I forgot to talk about this issue.  We'll need to keep the
server-side code that handles SSLv2-compatible ClientHello.

 Can you share any information you have about how common SSL-2.0-only servers
 are?

I don't have this info, but the products that need to support
SSL 2.0 can stay with NSS 3.12.x.

 It is easier to remove SSL 2.0 with short notice from client products than
 it is from server products. For this and many other reasons, it is worth
 considering splitting the codebase into client, server, and shared
 components (at least at the source code level). Then this decision could be
 done independently for client and server products and Windows desktop
 products can avoid shipping large chunks of (effectively) dead
 security-critical code.

This is a good goal, but it can be a very intrusive change.
I'm going for the most bang for the buck.

I do think ssl3con.c is too big.  At 9503 lines, it takes a
long time to load ssl3con.c in mxr.mozilla.org, and that
hurts developer productivity.  (I use MXR to help me
understand the code.)  So if we're going to break ssl3con.c
into parts, we can follow your suggestion -- client, server,
and shared.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How important is FIPS-140 compliance and PKCS#11 interoperability to Firefox, Chrome, etc.?

[Wan-Teh Chang]

On Fri, Aug 27, 2010 at 2:05 PM, Brian Smith br...@briansmith.org wrote:
 In accepting patches to implement TLS 1.2 and/or AES-GCM cipher suites, is a
 (potentially-)FIPS-140-compliant implementation required? Or, would it be
 acceptable in the short-term to have an implementation that is known to be
 non-compliant and thus disabled in FIPS mode?

It is fine to be non-FIPS compliant when you add new crypto
algorithms to the NSS softoken.  You should do this work on
the NSS trunk.  NSS customers who must use a FIPS-validated
softoken can stay on the NSS_3_12_BRANCH.

I can review your patches.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Proposal to remove SSL 2.0 support from NSS trunk (NSS 3.13)

[Wan-Teh Chang]

I propose that we remove SSL 2.0 support from the NSS
trunk (NSS 3.13).

SSL 2.0 is an old and insecure protocol.  No products
should be using SSL 2.0 today.  But removing the SSL
2.0 code from NSS has one major benefit to the continual
development of NSS's SSL library: it'll make the code
base easier to maintain.

Compared with the mainstream SSL 3.0/TLS 1.0 code
in NSS, the SSL 2.0 code was written in a different style
and worse, uses some data structures in a different way.
This confuses people like me who are still learning our
way around the code base but need to add new features.
In addition, when we fix a bug, we always wonder if we
should also fix the bug in the SSL 2.0 code path.

As we add TLS 1.1 and TLS 1.2 code, it also makes
sense to remove the SSL 2.0 code to reduce the code
size.

If no one objects, I will be happy to do the work.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Port Mozilla NSS/JSS to smart phone platform

[Wan-Teh Chang]

On Wed, Aug 25, 2010 at 1:39 PM, msm Li mlim...@gmail.com wrote:

 First thing first, does Mozilla have such plan to port NSS/JSS to smart
 phone
 platform ?

Mozilla doesn't use JSS, so Mozilla is unlikely to work on
porting JSS to new platforms.

Mozilla is porting NSS to Android.  I have not seen any
NSS patches for iPhone, so I don't know if Mozilla is
porting NSS to iPhone.

I am interested in the project you proposed.  Why do you
want to port JSS?

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: JSS and EC Signature algorithms

[Wan-Teh Chang]

On Wed, Aug 18, 2010 at 3:47 AM, David Stutzman
david.stutz...@nospam.dstutz.com wrote:

 If I query the Mozilla-JSS provider for the algorithms it supports, I get
 the following EC Signature algorithms:
 SHA1withEC
 SHA256withEC
 SHA384withEC
 SHA512withEC

 Is there any way to change/add some aliases so the Mozilla-JSS provider uses
 the official JCE naming?

It seems very straightforward to add algorithm aliases:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/jss/org/mozilla/jss/JSSProvider.javarev=1.34mark=106-113#103

 I know I can probably go in and change the way JSS reports the algorithm to
 the JCE, but won't I run into trouble with needing the signed crypto
 provider?

Yes, you will.  You can apply for your own signing certificate
for the Mozilla-JSS provider.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PKCS#11 module: C_GetAttributeValue problems

[Wan-Teh Chang]

On Wed, Aug 11, 2010 at 1:18 PM, Matej Kurpel mkur...@gmail.com wrote:
  Hello,
 I am trying to implement a PKCS#11 module for my diploma thesis. It is
 intended to be used with thunderbird. I am using opensc pkcs11-spy module to
 debug it. I have a problem for quite some days I don't seem to be able to
 solve myself.
 At first, thunderbird searches for token certificates
 (CKA_CLASS=CKO_CERTIFICATE and CKA_TOKEN=TRUE). I am returning an object
 with handle 0x1 (letting thunderbird know I have such a certificate). Later,
 thunderbird asks for its attributes CKA_TOKEN and CKA_LABEL but gives
 zero-sized buffers for both values. This is where my problem lies - I don't
 know what to return and if I have to fill the values in the template or not.
 According to the specification (if I understood correctly), I should return
 CKR_BUFFER_TOO_SMALL and fill the ulValueLen properties to the length of the
 two attribute values, which makes perfect sense.

I think this is correct.

I don't know why Thunderbird doesn't call C_GetAttributeValue again
with the right buffer sizes.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PKCS#11 header files: license and updating to the newest version

[Wan-Teh Chang]

On Mon, Aug 2, 2010 at 12:10 PM, Brian Smith br...@briansmith.org wrote:
 I read a rumor that Mozilla received explicit permission from RSA labs to
 distribute the PKCS#11 header files under the Mozilla tri-license. Does
 anybody know anything about that, and how I can verify it?

That's also what I heard.  I don't know how to verify it.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Assertion when using SEC_ASN1EncodeItem with subtemplate

[Wan-Teh Chang]

On Fri, Jul 30, 2010 at 11:29 AM, Nelson B Bolyard nel...@bolyard.me wrote:

 I think you're right.  I filed
 https://bugzilla.mozilla.org/show_bug.cgi?id=583308
 with a patch to fix at least one problem.

I ran Hanno's test program in a debugger.
I saw the problem that Hanno reported, that
the ASN.1 encoder calls SEC_ASN1GetSubTemplate
one time too many.

The first SEC_ASN1GetSubTemplate call is caused
by the SEC_ASN1_OPTIONAL flag.

The second SEC_ASN1GetSubTemplate call, which
causes the assertion failure, is caused by the
SEC_ASN1_EXPLICIT flag.

Using this MXR query for SEC_ASN1_POINTER,
you can see that no ASN.1 templates use
SEC_ASN1_POINTER with SEC_ASN1_EXPLICIT:
http://mxr.mozilla.org/security/search?string=SEC_ASN1_POINTER

So it's not surprising the ASN.1 encoder may have
problems with the
SEC_ASN1_POINTER | SEC_ASN1_EXPLICIT
combination.

So one solution is to not use a pointer field in the
structure.  But I understand you want the field to
be a pointer because it is optional.  Then I found
that NSS deals with such an optional field with an
explicit tag by using a PointerTo template.
Here is an example in mozilla/security/nss/lib/certhigh/ocsp.c:
http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/ocsp.c#1188

Here is Hanno's code modified to use a PointerTo template:

SEC_ASN1_MKSUB(SECOID_AlgorithmIDTemplate)

const SEC_ASN1Template MY_PointerToAlgorithmIDTemplate[] = {
{ SEC_ASN1_POINTER, 0, SEC_ASN1_SUB(SECOID_AlgorithmIDTemplate) }
};

const SEC_ASN1Template MY_RSAPSSParamsTemplate[] =
{
   { SEC_ASN1_SEQUENCE, 0, NULL, sizeof(SECKEYRSAPSSParams) },
   { SEC_ASN1_OPTIONAL | SEC_ASN1_CONSTRUCTED | SEC_ASN1_EXPLICIT |
 SEC_ASN1_XTRN | SEC_ASN1_CONTEXT_SPECIFIC | 0,
 offsetof(SECKEYRSAPSSParams, hashAlg),
 MY_PointerToAlgorithmIDTemplate },
   { 0 }
};

SECStatus
PSSU_EncodeDER(SECItem *dest, CK_RSA_PKCS_PSS_PARAMS *in)
{
   SECKEYRSAPSSParams *pss_params;
   PRArenaPool *arena;
   SECItem *ret;
   unsigned int i;

   arena = PORT_NewArena(DER_DEFAULT_CHUNKSIZE);
   pss_params = PORT_ZAlloc(sizeof(*pss_params));
   pss_params-hashAlg = PORT_ZAlloc(sizeof(SECAlgorithmID));

   SECOID_SetAlgorithmID(arena, pss_params-hashAlg, SEC_OID_SHA256, NULL);

   ret = SEC_ASN1EncodeItem(arena, NULL, pss_params,MY_RSAPSSParamsTemplate);

   PORT_FreeArena(arena, PR_FALSE);
   return SECSuccess;
}

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Assertion when using SEC_ASN1EncodeItem with subtemplate

[Wan-Teh Chang]

On Mon, Jul 26, 2010 at 6:07 AM, Hanno Böck ha...@hboeck.de wrote:
 Hi,

 Just recently, the templates for decoding the RSA-PSS ASN1 parameters got
 added to cvs head (in cryptohi/seckey.c).

 Currently I'm working on implementing the creation of PSS signatures, so I
 need them also to encode. My naive thought was that SEC_ASN1EncodeItem is used
 pretty much the same as QuickDERDecodeItem, just the other way round.

 For testing, I tested with a stripped-down version of the template containing
 only the first entry. Though what I get is:
 Assertion failure: theTemplate-sub != NULL, at secasn1u.c:93


 From the error, I assume it has something to do with the subtemplate. If that
 helps, by some try and error I found out that when removing SEC_ASN1_EXPLICIT,
 no assertion appears (thouhg it'll obviously produce a wrong DER struct).
 Is there something special I need to care about when doing encoding vs.
 decoding ASN1?


 The code looks like this:


 SEC_ASN1_MKSUB(SECOID_AlgorithmIDTemplate)

 const SEC_ASN1Template MY_RSAPSSParamsTemplate[] =
 {
    { SEC_ASN1_SEQUENCE, 0, NULL, sizeof(SECKEYRSAPSSParams) },
    { SEC_ASN1_OPTIONAL | SEC_ASN1_CONSTRUCTED | SEC_ASN1_EXPLICIT |
          SEC_ASN1_XTRN | SEC_ASN1_POINTER | SEC_ASN1_CONTEXT_SPECIFIC | 0,
          offsetof(SECKEYRSAPSSParams, hashAlg),
          SEC_ASN1_SUB(SECOID_AlgorithmIDTemplate) },
    { 0 }
 };

Hanno,

I am not familiar with the ASN.1 templates in NSS.

I'm afraid that you'll need to run the code in a debugger
to understand what the ASN.1 encoder is doing and
why it doesn't like your template.

Another idea is to look at the ASN.1 templates in
NSS that are used for encoding.  See if they have
something different from your template.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Need help troubleshooting TLS Handshake error: CKR_ATTRIBUTE_VALUE_INVALID

[Wan-Teh Chang]

On Tue, Jul 27, 2010 at 10:09 AM, Pat lync...@gmail.com wrote:
 Hello,

 Can anyone explain what is going wrong with the following scenario?

 Using NSPR 4.8, NSS 3.12.6, JSS 4.3.1 with JDK 1.6_21 on Windows XP
 Professional SP 3.  FIPS mode is enabled.

 I'm trying to open an LDAP connection to an LDAP server (Apache
 Directory Server) running locally on the same system.  Both SSL
 contexts (server and client) are configured to use the KeyManager
 (PKCS11 KeyStore), TrustManager and SecureRandom obtained from the
 SunPKCS11-NSS provider.

 I have enabled the debug logging for the TLS handshake and I can see
 that both sides are using the same certificate for identification and
 that this certificate as well as the appropriate CA certificates are
 being found in the NSS database.

 When executing the code with FIPS mode disabled, the handshake is
 successful.  However, with FIPS mode enabled, the following stacktrace
 is produced:

 2010-07-27 08:51:02,154;48156;ERROR;ds.DsServiceImplLiveTest;
 (main);Client:
 javax.net.ssl.SSLException: java.security.ProviderException: Could not
 generate premaster secret
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:
 190)
        at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:
 1623)
[...omitted...]
 Caused by: java.security.ProviderException: Could not generate
 premaster secret
        at
 sun.security.pkcs11.P11TlsRsaPremasterSecretGenerator.engineGenerateKey(P11TlsRsaPremasterSecretGenerator.java:
 87)
        at javax.crypto.KeyGenerator.generateKey(DashoA13*..)
        at
 com.sun.net.ssl.internal.ssl.RSAClientKeyExchange.init(RSAClientKeyExchange.java:
 91)
        at
 com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:
 673)
        at
 com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:
 230)
        at
 com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:
 529)
[...omitted...]
 Caused by: sun.security.pkcs11.wrapper.PKCS11Exception:
 CKR_ATTRIBUTE_VALUE_INVALID
        at sun.security.pkcs11.wrapper.PKCS11.C_GenerateKey(Native Method)
        at
 sun.security.pkcs11.P11TlsRsaPremasterSecretGenerator.engineGenerateKey(P11TlsRsaPremasterSecretGenerator.java:
 81)
[...omitted...]

The stack trace of the exception shows that the C_GenerateKey call
used to generate the premaster secret failed with
CKR_ATTRIBUTE_VALUE_INVALID.

Since there is Sun Java code involved, I won't be able to fully
debug this.  I'll give you some hints on how I would debug
this, and hopefully you can track this down.

1. Search in the NSS source tree for CKR_ATTRIBUTE_VALUE_INVALID
to identify the places where CKR_ATTRIBUTE_VALUE_INVALID may
be returned:
http://mxr.mozilla.org/security/ident?i=CKR_ATTRIBUTE_VALUE_INVALIDfilter=

Focus only on the files in security/nss/lib/softoken, as the SunPKCS11
provider is only using the softoken of NSS.

2. Since you get this error when the NSS softoken is in FIPS mode,
security/nss/lib/softoken/fipstokn.c is worth a look.

In FIPS mode, the PKCS #11 C_Foo function is mapped to the
FC_Foo function in security/nss/lib/softoken/fipstokn.c.

So C_GenerateKey becomes FC_GenerateKey:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/softoken/fipstokn.crev=1.28mark=1292,1300-1307#1291

NSC_GenerateKey is the common implementation of C_GenerateKey
between FIPS and non-FIPS mode.  So you see clearly that
FC_GenerateKey does some special checks for FIPS mode,
and then invoke the common code.

One of the special check is that the caller must specify that
the new key be sensitive (CKA_SENSITIVE), which means
the new key cannot be exported in unencrypted form.  If this
check fails, FC_GenerateKey returns CKR_ATTRIBUTE_VALUE_INVALID.

Given the info you provided, this is most likely the place
where the NSS softoken failed with CKR_ATTRIBUTE_VALUE_INVALID
in FIPS mode.  If so, I'm afraid that the fix is to modify
sun.security.pkcs11 to be able to generate and use
RSA premaster secrets with the CKA_SENSITIVE
attribute set.

If this is not the failure spot, then you can use the method
I outlined above to track this down.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: JSS/NSS library dependencies on Windows XP

[Wan-Teh Chang]

I can suggest two things to help track this down.

1. Find out which DLLs require IESHIMS.DLL and WER.DLL.
This should be a chain of DLL dependencies that ultimately
leads to an NSS or NSPR DLLs (the culprit).  Right now I
don't know what the culprit is.

The NSPR DLLs are:
nspr4.dll, plc4.dll, plds4.dll, or
libnspr4.dll, libplc4.dll, libplds4.dll

The NSS DLLs are:
nss3.dll, nssutil3.dll, softokn3.dll, freebl3.dll, nssdbm3.dll,
smime3.dll, ssl3.dll, nssckbi.dll

2. Find out the environment variable that we need to set
to change the target Windows version for Windows SDK.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: JSS/NSS library dependencies on Windows XP

[Wan-Teh Chang]

Hi Cad,

On Mon, Jul 19, 2010 at 10:56 AM, Caden.smith Smith
caden.smith...@gmail.com wrote:

 Just for your information, here is the tree:

 JSS4.DLL
  NSPR4.DLL
    ADVAPI32.DLL
      SECUR32.DLL
        NETAPI32.DLL
          DNSAPI.DLL
            MPRAPI.DLL
              SETUPAPI.DLL
                SHELL32.DLL
                  SHDOCVW.DLL
                    MSHTML.DLL
                      IEFRAME.DLL that finally requires IESHIMS.DLL and WER.DLL

Thanks a lot.  There is no unexpected dependency.
NSPR4.DLL is known to depend on ADVAPI32.DLL.
Here is the linker flag:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/src/Makefile.inrev=1.57mark=196,200#196

The symbols NSPR4.DLL imports from ADVAPI32.DLL
have to do with access control for files:
ADVAPI32.dll
  1001D000 Import Address Table
  100207C4 Import Name Table
 0 time date stamp
 0 Index of first forwarder reference

   1F AllocateAndInitializeSid
   72 CopySid
  130 GetLengthSid
  154 GetTokenInformation
  1F1 OpenProcessToken
  11A FreeSid
  2B0 SetSecurityDescriptorDacl
   10 AddAccessAllowedAce
  170 InitializeAcl
  2B1 SetSecurityDescriptorGroup
  2B2 SetSecurityDescriptorOwner
  171 InitializeSecurityDescriptor

So I think the solution is most likely in figuring out the environment
variable that controls the target Windows version for Windows SDK.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: JSS/NSS library dependencies on Windows XP

[Wan-Teh Chang]

Hi Paul,

IESHIMS.DLL, WER.DLL, NCRYPT.DLL, and BCRYPT.DLL
are all Windows system DLLs.  So you cannot copy them
from one version of Windows to another version of Windows.
System DLLs should already be installed on a system.

In particular, NCRYPT.DLL and BCRYPT.DLL are newly
added in Vista, so they don't exist in XP.

The root problem is that your jss4.dll depends on IESHIMS.DLL
and WER.DLL.  Perhaps your jss4.dll was built for Vista and
later only?  Just a wild guess.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Problem building NSS with mozilla-build and mozillatools

[Wan-Teh Chang]

Hi Cad,

If you use MozillaBuild, do not use Netscape's wintools.
MozillaBuild is a one-stop shopping package and gives
you everything you need (except the compiler) to build
NSS.

To fix your build problem:
1. Remove Netscape's wintools from your computer.
2. Use make instead of gmake.

Details: your build problem is caused by using the GNU
make from Netscape's wintools (named gmake) with
the MSYS shell from MozillaBuild.  If you use
the GNU make from MozillaBuild (named make),
it'll work.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Purpose of refusing to renegotiate with non-RFC-5746 servers

[Wan-Teh Chang]

On Tue, May 25, 2010 at 11:06 AM, Marsh Ray ma...@extendedsubset.com wrote:

 But by that logic, the client should refuse to handshake at all with a
 non-RFC-5746 server. (In reality that eventually needs to become the
 default behavior).

I agree.  A strict client should refuse an initial handshake with a
legacy server.  If a client is willing to perform an initial handshake
with a legacy server, it should also be willing to perform a renegotiation
initiated by that server.

To answer Matt's original question: yes, it is intended to throw a
roadblock into the use of vulnerable servers to force them to upgrade.
I believe another rationale is that a legacy server can also be made
not vulnerable by disabling renegotiations, so if a legacy server
initiates a renegotiation, it is definitely vulnerable.

 I suspect that some of the security.ssl.* parameters may equally apply
 to server side uses of NSS, in which case it is clearly a useful mitigation.

Those parameters are Mozilla client preferences.  None of the
Mozilla clients (Firefox, Thunderbird, etc.) act as SSL servers.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto