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
