Nelson B wrote:
Yahel Zamir wrote:
Hi Everyone,
I am using NSS for a server application, a multi-threaded program
running on Linux. I have encountered a number of questions, and would be
glad to know if anyone has more information. My questions are based on
following the "Overview of an SSL Application" (
http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslintro.html).
1.
When writing an application that uses NSS, I would expect all Platform
Dependent configuration to reside in some configuration file, so that
the build process of the whole application will not need to be aware of
these details. However, the platform name and other properties appear
again and again in the Include path, the Library search path and in
command line defines, as you can see below - the command is copied from
running "make" in SSLsample, and contains many references to Linux,
Unix, x86 etc. Am I missing something here?
... -DLINUX1_2 -Di386 -D_XOPEN_SOURCE -DLINUX2_1 -ansi -Wall -pipe
-DHAVE_STRERROR -DLINUX -Dlinux -D_POSIX_SOURCE -D_BSD_SOURCE-DXP_UNIX
-DDEBUG -UNDEBUG -DDEBUG_yahel -D_REENTRANT
-I../../../../dist/Linux2.4_x86_glibc_PTH_DBG.OBJ/include
-I../../../../dist/public/nss -I../../../../dist/private/nss
Linux2.4_x86_glibc_PTH_DBG.OBJ/server.o
Linux2.4_x86_glibc_PTH_DBG.OBJ/sslsample.o
../../../../dist/Linux2.4_x86_glibc_PTH_DBG.OBJ/lib/libsectool.a
-Wl,-rpath,'$ORIGIN/../lib'
-Wl,-rpath-link,../../../../dist/Linux2.4_x86_glibc_PTH_DBG.OBJ/lib
-L../../../../dist/Linux2.4_x86_glibc_PTH_DBG.OBJ/lib -lssl3 -lsmime3
-lnss3 -L../../../../dist/Linux2.4_x86_glibc_PTH_DBG.OBJ/lib -lplc4
-lplds4 -lnspr4 -lpthread -ldl -lc
The scheme of naming built directories that way allows us to build NSS in
the same source tree on many platforms (via NFS or CIFS) simultaneously.
The builds and their results do not clash because they use separate
directories.
Is this a problem for you? You're not required to keep the files in the
directories where they are built, nor in directories with the same names
as where they are built.
Essentially I have an existing build system, which I would like to keep
as simple as possible. Therefore I try to avoid any -D flags and so on.
Wan-Teh Chang has replied that these are excessive, so I'm fine now...
2.
How can I build using only static libraries?
You can't. For SOME of NSS's libraries, it is possible to link with the
.a instead of the .so. But that is not true of all the relevant libraries.
You really should use the shared libs. The symbols "exported" by those
shared libs are (mostly) the "public" symbols, the symbols that are
documented and intended for use by non-NSS code. If you use the .a files,
you are likely to use private symbols.
We do not guarantee backwards compatibility of private symbols. Private
symbols may change in any release. So you should stick with public ones.
OK.
3.
How should an application generate error strings? The examples at
SSLsample do a very strange trick. On the other hand, selfserv on my
machine simply finds no error string (for example, when using a bad
certificate database, error "-8174").
I suggest you look at SECU_PrintError for guidance. Sounds like you've
found another bug in SSLSample.
SECU_PrintError seems to be for *printing* an error string rather than
*getting* one. Did you mean SECU_Strerror?
selfserv uses SECU_Strerror, but this is a private function. in
addition, on my machine it does not find an error string for -8174, for
example.
See also Wan-Teh Chang's reply.
4.
It is explained that we can either configure a listen socket for SSL
using SSL_ConfigSecureServer(), or listen in the regular manner and then
configure enable SSL on the socket created by PR_Accept().
EIther way, it is necessary to call SSL_ConfigSecureServer.
Is SSL_ConfigSecureServer() just an elegant way to enable SSL on all
sockets created from some listen socket, and nothing else? Does it add
any security?
It is the sole means by which you configure the certificates and private
keys on the SSL server socket.
I will rephrase my question: does it make any difference whether I do
the SSL configuration (1) on the listen socket, or (2) on the socket
created by PR_Accept (except the need to call SSL_ResetHandshake() in
the latter case) ?
By the way, the SSL reference seems to be incorrect in saying that
"SSL_ConfigSecureServer ... Configures a listen socket ...".
(http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html#1217647).
5.
Is there a simple example of an NSS client and server? I understand that
the SSLsample example are not considered good enough. However, selfserv
and strsclnt are rather complicated, since they handle numerous
configuration options.
SSLsample is the simplest example NSS has.
OK.
6.
bug report - in function setupSSLSocket() of SSLsample/client.c, any
failure leads to closing tcpSocket, even after SSL_ImportFD(), which
replaces tcpSocket by sslSocket.
It's not a bug. You will find that the value returned by SSL_ImportFD
is the same as the value of "fd" (the second argument) passed to it.
OK. Although it would be safer to make sure that they are equal, I guess.
Thanks,
Yahel Zamir.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
