| # Debuggin SSL on Linux | 
 |  | 
 | To help anyone looking at the SSL code, here are a few tips I've found handy. | 
 |  | 
 | [TOC] | 
 |  | 
 | ## Building your own NSS | 
 |  | 
 | 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](http://www.mozilla.org/projects/security/pki/nss/nss-3.11.4/nss-3.11.4-build.html) | 
 | and/or | 
 | [Build instructions](https://developer.mozilla.org/En/NSS_reference/Building_and_installing_NSS/Build_instructions). | 
 |  | 
 | Then, to build the most recent source tarball: | 
 |  | 
 | ```shell | 
 | 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: | 
 |  | 
 | ```shell | 
 | 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 | 
 | ``` | 
 |  | 
 | ## Linking against your own NSS | 
 |  | 
 | 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 | 
 |  | 
 | ## Running against your own NSS | 
 |  | 
 | Create a script named `run.sh` like this: | 
 |  | 
 | ```sh | 
 | #!/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 | 
 |  | 
 | ## Logging | 
 |  | 
 | There are several flavors of logging you can turn on. | 
 |  | 
 | *   `SSLClientSocketNSS` can log its state transitions and function calls using | 
 |     `base/logging.cc`.  To enable this, edit `net/base/ssl_client_socket_nss.cc` | 
 |     and change `#if 1` to `#if 0`. See `base/logging.cc` for where the output | 
 |     goes (on Linux, it's usually stderr). | 
 |  | 
 | *   `HttpNetworkTransaction` and friends can log its state transitions using | 
 |     `base/trace_event.cc`. To enable this, arrange for your app to call | 
 |     `base::TraceLog::StartTracing()`. The output goes to a file named | 
 |     `trace...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 | 
 |     variables `SSLDEBUGFILE=foo.log SSLTRACE=99 SSLDEBUG=99` before running | 
 |     your app. | 
 |  | 
 | ## Network Traces | 
 |  | 
 | 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. | 
 |  | 
 | ## Valgrinding NSS | 
 |  | 
 | 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.) | 
 |  | 
 | ## Support forums | 
 |  | 
 | If you have nonconfidential questions about NSS, check | 
 | [the newsgroup](http://groups.google.com/group/mozilla.dev.tech.crypto). | 
 | The NSS maintainer monitors that group and gives good answers. |