Re: Debugging a SSL transaction on Firefox 2.0.x

[Nelson Bolyard]

Peter Djalaliev wrote:

> To enable the SSL debugging statements, you need to set the SSLTRACE
> environment variable.  Possible values are 0-60 (0=no dubugging,
> 60=lots)

The maximum value is 127, IIRC.  However, it may be that presently
we are not using values larger than 60.

I specifically did NOT recommend this to Pedro for many reasons,
including:

- He should take the simplest approach to diagnosing the problem first,
and not take the more difficult approaches unless/until the simple
ones fail to explain the problem,

- Turning this on is like drinking from a fire hose.  You get TONS of
output. Quickly leads to information overload.

- It can be quite difficult for someone who is not familiar with the
code to interpret.  The feature exists to help the code's developers
debug the code, not as a general SSL line monitoring tool (which
ssltap is).

- There is no debug tracing inside the PKCS#11 crypto module.  The only
way to get the actual values of the Pre-master secret and Master secret
is to use libSSL's "bypass" feature, which alters its behavior.

I suspect this is all orders of magnitude more complicated than Pedro
needs just to see what's going on.

> IMHO, this is ~~confusing~~.  We are using one debugging mechanism to
> print out statements within NSS and another one within the rest of
> NSPR/Mozilla.  

That's true.  NSS's tracing was written years before NSPR came along.

> What's more, the two mechanism don't even provide the
> same functionality - the NSS debugging macros allow you to display
> buffer contents, while the NSPR ones don't.  The NSPR mechanisms allow
> you to output to a file instead of standard output, while the NSS ones
> don't.

Not true in the current NSS code.
There are 3 environment variables related to NSS tracing:

SSLTRACE  Set to trace level (0-127)
SSLDEBUG  Set to debug level (0-127)
SSLDEBUGFILE  set to file path name.  NSS uses stderr if this is not set.

These features are available ONLY in DEBUG builds of NSS.

> 
> Can we simplify this whole thing?  Can we get rid of SSLTRACE,
> PRINT_BUF and SSL_TRACE altogether

No.  There is no need to do that.  Those macros are not a problem.
Eliminating them is not part of the solution.

> and use PR_LOG and the related NSPR macros within NSS, too?

Those macros invoke functions found in ssltrace.c.  In the end, all the
actual debug/trace I/O is done in one function, ssl_Trace, in that file.

It might be possible to modify ssl_Trace to use PR_Log instead of fputs.
I don't presently know enough about PR_Log to know how feasible that is.

> For this purpose, we would need to enhance the NSPR debugging macros with
> something equivalent to NSS's PRINT_BUF.

Nah.  No need to replace any of NSS's trace/debug formatting functions.
Just get them to use NSPR.

> If we do this, I think we will achieve uniformity with
> what's used in other Mozilla modules and we will also allow NSS users
> to pipe their debugging statements into a file (which I think it quite
> useful when stdout is not available - e.g. embedded apps)

Again, the ability to output to a file is in NSS today.

> Given this, we can also write a nice documentation module on
> "debugging NSS" in the NSS documentation wiki that Wan-Teh maintains.

I think a better name would be "Tracing SSL Protocol Processing".

Feel free to document the extant NSS features.  If we change libSSL's
DEBUG/Trace features to use NSPR, that should be a small change to the
documentation.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Debugging a SSL transaction on Firefox 2.0.x

[Nelson Bolyard]

Jean-Marc Desperrier wrote:

> The main difference between Fx 2 and Fx 1.5 is that 56 bits ciphers are
> now by default disabled.

That is one of the big differences.

IINM, other big differences include:

- SSL2 support disabled, client hellos are now SSL3, not SSL2.
- Added support for TLS hello extensions

Of these, I would say that TLS hello extensions have experienced the
most problems, due to servers that do not ignore them (which the RFCs
require) and instead reject the connections.

The removal of SSL2 support has led to problems with SSL2-only servers.

The removal of support for the old "export" ciphers has also caused
some problems, but I'd say not as many as either of the other two.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Debugging a SSL transaction on Firefox 2.0.x

[Peter Djalaliev]

Hello,

To enable the SSL debugging statements, you need to set the SSLTRACE
environment variable.  Possible values are 0-60 (0=no dubugging,
60=lots)

If this doesn't work for you (I suppose it depends on your embedding
environment), you can place PR_LOG statements within the NSS's SSL
code.  To get these debugging statements enabled, you need to set
NSPR_LOG_MODULES environment variable.  If you can't display the
debugging output to standard output or the equivalent, you need to set
the NSPR_LOG_FILE environment variable.  This will output the
debugging statements into a file of your choosing.

To enable any PR_LOG debugging , I believe you also need to have
compiled Firefox as a debug build:

./configure --enable-debug --enable-debug-modules --enable-debugger-
info-modules.  I know this sucks, given how much time Firefox takes to
recompile.


IMHO, this is ~~confusing~~.  We are using one debugging mechanism to
print out statements within NSS and another one within the rest of
NSPR/Mozilla.  What's more, the two mechanism don't even provide the
same functionality - the NSS debugging macros allow you to display
buffer contents, while the NSPR ones don't.  The NSPR mechanisms allow
you to output to a file instead of standard output, while the NSS ones
don't.

Can we simplify this whole thing?  Can we get rid of SSLTRACE,
PRINT_BUF and SSL_TRACE altogether and use PR_LOG and the related NSPR
macros within NSS, too?  For this purpose, we would need to enhance
the NSPR debugging macros with something equivalent to NSS's
PRINT_BUF.  If we do this, I think we will achieve uniformity with
what's used in other Mozilla modules and we will also allow NSS users
to pipe their debugging statements into a file (which I think it quite
useful when stdout is not available - e.g. embedded apps)

Given this, we can also write a nice documentation module on
"debugging NSS" in the NSS documentation wiki that Wan-Teh maintains.

What do you all think about that?

Regards,
Peter Djalaliev


On Mar 8, 12:16 pm, "Pedro DeKeratry" <[EMAIL PROTECTED]> wrote:
> Our device implements the following ciphers:
>
> #define USE_SSL_RSA_WITH_RC4_128_MD5
> #define USE_SSL_RSA_WITH_RC4_128_SHA
> #define USE_SSL_RSA_WITH_3DES_EDE_CBC_SHA
> #define USE_TLS_RSA_WITH_AES_128_CBC_SHA  /* must define USE_TLS */
> #define USE_TLS_RSA_WITH_AES_256_CBC_SHA  /* must define USE_TLS */
>
> The RC4 ciphers are enabled in about:config. One thing I have not
> figured out is how to force Firefox to use TLS instead of SSL.
>
> I will try the ssltap utility mentioned by Nelson and see what it uncovers.
>
> Thanks,
> Pedro
>
> On 3/8/07, Jean-Marc Desperrier <[EMAIL PROTECTED]> wrote:
>
> > Pedro DeKeratry wrote:
> > > The company I work for produces an embedded device that contains an
> > > SSLv3/TLSv1.0 implementation.
> >  > [...] Firefox 2.0.x does not. The browser sends a
> > > RST at the end of nearly every initial SSL handshake.
>
> > Do you have a list of the ciphers you implement in your device ?
>
> > The main difference between Fx 2 and Fx 1.5 is that 56 bits ciphers are
> > now by default disabled.
> > ___
> > dev-tech-crypto mailing list
> > [EMAIL PROTECTED]
> >https://lists.mozilla.org/listinfo/dev-tech-crypto


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

Re: migrating mozilla keystore to java built in keystore

[kirvesrinta]

This error:

> #
> # An unexpected error has been detected by HotSpot Virtual Machine:
> #
> #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x77c47a64, pid=720,
> tid=2368
> #
> # Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode)
> # Problematic frame:
> # C  [MSVCRT.dll+0x37a64]
> #
> # An error report file with more information is saved as hs_err_pid720.log
> #
> # If you would like to submit a bug report, please visit:
> #  http://java.sun.com/webapps/bugreport/crash.jsp
> #

has to do with JNI and loading the dll.

Marko


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

Re: Debugging a SSL transaction on Firefox 2.0.x

[Pedro DeKeratry]

Our device implements the following ciphers:

#define USE_SSL_RSA_WITH_RC4_128_MD5
#define USE_SSL_RSA_WITH_RC4_128_SHA
#define USE_SSL_RSA_WITH_3DES_EDE_CBC_SHA
#define USE_TLS_RSA_WITH_AES_128_CBC_SHA  /* must define USE_TLS */
#define USE_TLS_RSA_WITH_AES_256_CBC_SHA  /* must define USE_TLS */

The RC4 ciphers are enabled in about:config. One thing I have not
figured out is how to force Firefox to use TLS instead of SSL.

I will try the ssltap utility mentioned by Nelson and see what it uncovers.

Thanks,
Pedro

On 3/8/07, Jean-Marc Desperrier <[EMAIL PROTECTED]> wrote:

Pedro DeKeratry wrote:
> The company I work for produces an embedded device that contains an
> SSLv3/TLSv1.0 implementation.
 > [...] Firefox 2.0.x does not. The browser sends a
> RST at the end of nearly every initial SSL handshake.

Do you have a list of the ciphers you implement in your device ?

The main difference between Fx 2 and Fx 1.5 is that 56 bits ciphers are
now by default disabled.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


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

Re: Using MSVC as a cross compiler

[Wan-Teh Chang]

Neil wrote:

Nelson Bolyard wrote:

In the usual places where NSS documentation is found. Here's a helpful 
google search.


 

I couldn't find any reference to cross-compilation in that search. It 
seems that Bugzilla bug 104541 has the most helpful information.


Nelson may have missed that you asked for "specific reference
to cross compilation".  Our build instructions for NSS in its
stand-alone configuration do not cover cross compilation.  Sorry.

Wan-Teh

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

Re: Using MSVC as a cross compiler

[Wan-Teh Chang]

Neil wrote:

Wan-Teh Chang wrote:

You'll see that the Mozilla developers override these make variables 
used by the NSS coreconf build system when cross-compiling NSS:


199 ifdef CROSS_COMPILE
200 DEFAULT_GMAKE_FLAGS += \
201 NSINSTALL="$(NSINSTALL)" \
202 NATIVE_CC="$(HOST_CC)" \
203 CC="$(CC)" \
204 CCC="$(CXX)" \
205 LINK="$(LD)" \
206 AS="$(AS)" \
207 AR='$(AR) $(AR_FLAGS:[EMAIL PROTECTED]@)' \
208 RANLIB="$(RANLIB)" \
209 RC="$(RC) $(RCFLAGS)" \
210 OS_ARCH="$(OS_ARCH)" \
211 CPU_ARCH="$(TARGET_CPU)" \
212 $(NULL)
213 SKIP_CHK=1
214 endif


Yes, and this is the cause of the third issue in my original post :-( I 
wonder why NSS uses LINK instead of LD?


NSS uses LD on Unix (including Linux and Mac OS X), and
LINK on Windows, to refer to the linker.  The use of RC
(resource compiler, a tool used only on Windows) in the
above makefile snippet also suggests that the
cross-compilation targets included Windows.  See
http://lxr.mozilla.org/security/source/security/coreconf/WIN32.mk#45http://lxr.mozilla.org/security/source/security/coreconf/WIN32.mk#45

Wan-Teh

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

Re: Debugging a SSL transaction on Firefox 2.0.x

[Jean-Marc Desperrier]

Pedro DeKeratry wrote:

The company I work for produces an embedded device that contains an
SSLv3/TLSv1.0 implementation. 

> [...] Firefox 2.0.x does not. The browser sends a

RST at the end of nearly every initial SSL handshake.


Do you have a list of the ciphers you implement in your device ?

The main difference between Fx 2 and Fx 1.5 is that 56 bits ciphers are 
now by default disabled.

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

Re: Using MSVC as a cross compiler

[Neil]

Nelson Bolyard wrote:


Neil wrote:
 


Nelson B wrote:


I suggest that you first try to get NSS to build for you in its stand-alone 
configuration, using only NSS's makefiles and not any of the other mozilla 
products' makefiles.
 


Where would this be documented, with specific reference to cross compilation?


In the usual places where NSS documentation is found. Here's a helpful google 
search.


 

I couldn't find any reference to cross-compilation in that search. It 
seems that Bugzilla bug 104541 has the most helpful information.


--
Warning: May contain traces of nuts.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Using MSVC as a cross compiler

[Neil]

Wan-Teh Chang wrote:

None of the NSS developers cross-compiles NSS.  (The closest thing we 
do to cross-compilation is to build the Windows CE binaries on Windows 
2000/XP.)  So we're not familiar with how the Mozilla developers 
cross-compile NSS.


I don't think many Mozilla developers cross-compile NSS either ;-) 
except perhaps Intel Mac -> PPC.


You'll see that the Mozilla developers override these make variables 
used by the NSS coreconf build system when cross-compiling NSS:


199 ifdef CROSS_COMPILE
200 DEFAULT_GMAKE_FLAGS += \
201 NSINSTALL="$(NSINSTALL)" \
202 NATIVE_CC="$(HOST_CC)" \
203 CC="$(CC)" \
204 CCC="$(CXX)" \
205 LINK="$(LD)" \
206 AS="$(AS)" \
207 AR='$(AR) $(AR_FLAGS:[EMAIL PROTECTED]@)' \
208 RANLIB="$(RANLIB)" \
209 RC="$(RC) $(RCFLAGS)" \
210 OS_ARCH="$(OS_ARCH)" \
211 CPU_ARCH="$(TARGET_CPU)" \
212 $(NULL)
213 SKIP_CHK=1
214 endif


Yes, and this is the cause of the third issue in my original post :-( I 
wonder why NSS uses LINK instead of LD?


--
Warning: May contain traces of nuts.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto