To help anyone looking at the SSL code, here are a few tips I've found handy.
[TOC]
In order to use a debugger with the NSS library, it helps to build NSS yourself. Here's how I did it:
First, read Network Security Services and/or Build instructions.
Then, to build the most recent source tarball:
cd $HOME
wget ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_12_RTM/src/nss-3.12-with-nspr-4.7.tar.gz
tar -xzvf nss-3.12-with-nspr-4.7.tar.gz
cd nss-3.12/
cd mozilla/security/nss/
make nss_build_all
Sadly, the latest release, 3.12.2, isn't available as a tarball, so you have to build it from cvs:
cd $HOME
mkdir nss-3.12.2
cd nss-3.12.2
export CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
cvs login
cvs co -r NSPR_4_7_RTM NSPR
cvs co -r NSS_3_12_2_RTM NSS
cd mozilla/security/nss/
make nss_build_all
Sadly, I don't know of a nice way to do this; I always do
hammer --verbose net > log 2>&1
then grab the line that links my app and put it into a shell script link.sh, and edit it to include the line
DIR=$HOME/nss-3.12.2/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/lib
and insert a -L$DIR
right before the -lnss3
.
Note that hammer often builds the app in one, deeply buried, place, then copies
it into Hammer for ease of use. You'll probably want to make your link.sh
do
the same thing.
Then, after a source code change, do the usual hammer net
followed by
sh link.sh
.
Then, to run the resulting app, use a script like
Create a script named run.sh
like this:
#!/bin/sh
set -x
DIR=$HOME/nss-3.12.2/mozilla/dist/Linux2.6_x86_glibc_PTH_DBG.OBJ/lib
export LD_LIBRARY_PATH=$DIR
"$@"
Then run your app with
sh run.sh Hammer/foo
Or, to debug it, do
sh run.sh gdb Hammer/foo
There are several flavors of logging you can turn on.
-
SSLClientSocketNSS
can log its state transitions and function calls usingbase/logging.cc
. To enable this, editnet/base/ssl_client_socket_nss.cc
and change#if 1
to#if 0
. Seebase/logging.cc
for where the output goes (on Linux, it's usually stderr). -
HttpNetworkTransaction
and friends can log its state transitions usingbase/trace_event.cc
. To enable this, arrange for your app to callbase::TraceLog::StartTracing()
. The output goes to a file namedtrace...pid.log
in the same directory as the executable (e.g.Hammer/trace_15323.log
). -
NSS
itself can log some events. To enable this, set the environment variablesSSLDEBUGFILE=foo.log SSLTRACE=99 SSLDEBUG=99
before running your app.
http://wiki.wireshark.org/SSL describes how to decode SSL traffic. Chromium SSL
unit tests that use net/base/ssl_test_util.cc
to set up their servers always
use port 9443 with net/data/ssl/certificates/ok_cert.pem
, and port 9666 with
net/data/ssl/certificates/expired_cert.pem
This makes it easy to configure
Wireshark to decode the traffic: do
Edit / Preferences / Protocols / SSL, and in the "RSA Keys List" box, enter
127.0.0.1,9443,http,<path to ok_cert.pem>;127.0.0.1,9666,http,<path to expired_cert.pem>
e.g.
127.0.0.1,9443,http,/home/dank/chromium/src/net/data/ssl/certificates/ok_cert.pem;127.0.0.1,9666,http,/home/dank/chromium/src/net/data/ssl/certificates/expired_cert.pem
Then capture all tcp traffic on interface lo, and run your test.
Read https://developer.mozilla.org/en/NSS_Memory_allocation and do
export NSS_DISABLE_ARENA_FREE_LIST=1
before valgrinding if you want to find where a block was originally allocated.
If you get unsymbolized entries in NSS backtraces, try setting:
export NSS_DISABLE_UNLOAD=1
(Note that if you use the Chromium valgrind scripts like
tools/valgrind/chrome_tests.sh
or tools/valgrind/valgrind.sh
these will both
be set automatically.)
If you have nonconfidential questions about NSS, check the newsgroup. The NSS maintainer monitors that group and gives good answers.