1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
|
<html>
<head>
<title>AOLserver</title>
</head>
<body>
<h1>AOLserver SSL Configuration Guide</h1>
<p>
<small>
$Header: /cvsroot/aolserver/aolserver.com/docs/admin/nsssl.html,v 1.1 2002/03/07 19:15:34 kriston Exp $
</small>
<p>
<h2>WARNING--READ BEFORE USING NSSSL</h2>
<blockquote>
<font color=red><b>
<p>
<big>EXPORT NOTICE</big>
<p>
This source code is subject to the U.S. Export Administration
Regulations and other U.S. law, and may not be exported or re-exported
to certain countries (currently Afghanistan (Taliban-controlled
areas), Cuba, Iran, Iraq, Libya, North Korea, Serbia (except Kosovo),
Sudan and Syria) or to persons or entities prohibited from receiving
U.S. exports (including Denied Parties, Specially Designated
Nationals, and entities on the Bureau of Export Administration Entity
List).
</b></font>
</blockquote>
<p>
<h2>Introduction</h2>
The nsssl driver supports SSL v2 according to the Netscape SSL
documentation, which you can find at http://developer.netscape.com/.
It was developed using the BSAFE 3 libraries from RSA Data Security at
http://www.rsa.com/.
<p>
While fully functional for providing security over the internet using
the "HTTPS" protocol. This implementation of nsssl supports SSL v2
which by itself is more than adequate for most web sites. Some
seldom-used SSL v2 features that were omitted include client
certificates and the SHA-1 message digest algorithm. The reasoning
behind this is that users browsing the web very seldom have client
certificates, let alone know what they are intended for. Likewise, in
virtually all cases, MD5 is the message digest requested by all
browsers and is fully supported. In any event, we always welcome
contributions to add these features to nsssl.
<p>
<h2>Key Pair and Certificate Request Generation</h2>
<p>
SSL key pair and certificate request generation is handled by a Tcl
script that you source into a stand-alone AOLserver process. To use,
change to your AOLserver's root directory and edit the certificate
information at the top of the "./modules/nsssl/keygen.tcl" file.
<p>
Once you are satisfied with your information, create your key pair and
certificate request by typing:
<p>
./bin/nsd -ft ./modules/nsssl/keygen.tcl
<p>
Your directory will now include two files, "keyfile.pem" and
"certreq.pem." Put the "keyfile.pem" file in a safe place for now.
Send the "certreq.pem" file to your favorite Certificate Authority.
<p>
<h2>What To Do Next</h2>
<p>
After a while, you will receive a signed certificate from your
Certificate Authority in PEM (Privacy-Enhanced Mail) format. Save the
body of the message (and just the body) in a file called
"certfile.pem" and place it and the "keyfile.pem" file into the
"./servers/servername/modules/nsssl/" directory. Edit your nsd.tcl file
to load nsssl.so (or nsssle.so), and verify the location of these two
files in the "ns/server/servername/module/nsssl" section.
<p>
That's it! You're all set and ready to use the SSL v2 protocol to
provide secure access to your web site!
<p>
<h2>Security Notes</h2>
<p>
Due to export, patent, and intellectual property issues with RSA, RC4,
RC2, and some other algorithms, the 40-bit/512-bit export version is
the only binary of nsssl that America Online is permitted to
distribute from http://aolserver.com/. If you wish to use the
128-bit/1024-bit domestic version of nsssl, you will have to obtain
RSA BSAFE 3 libraries from http://www.rsa.com/ and build nsssl on
your own. Unfortunately, we are forbidden to distribute a binary
build of nsssl with 128-bit/1024-bit domestic encryption for the
reasons stated above. We are permitted to distribute a binary build
with 40-bit/512-bit encryption, and we are also allowed to distribute
the nsssl source code itself.
<p>
The "keyfile.pem" is a very sensitive document! Do not let it out of
your hands, do not send it out over the network, and don't delete it.
It contains your server's private key and if it's lost then you must
cancel your certificate, regenerate the key pair, and get it signed
all over again. You should put this in the
"./servers/servername/modules/nsssl/" directory.
<p>
The "certreq.pem" file generated by keygen.tcl should be deleted once
you receive your signed certificate, but it's harmless (but useless)
to keep around.
<p>
The "certfile.pem" file that you will receive from the certificate
authority is very valuable, though it can be handled in a less-secure
fashion. You put this in the "./servers/servername/modules/nsssl/"
directory.
<p>
<h2>Implementation Notes</h2>
<p>
<h3>nsssl vs. nssock</h3>
<p>
If you are familiar with the AOLserver socket driver "nssock," you
may notice that the driver-related portions of nsssl are almost
identical. In fact, they are so alike that nsssl will eventually
merge back into the nssock driver with #ifdefs to enable SSL. This
eliminates lots of duplicated code and should eliminate version skew
if nssock and the AOLserver socket driver API change over time.
<p>
<h3>Running AOLserver in Stand-Alone Mode</h3>
<p>
What's this about running AOLserver just to source a Tcl script?
This was an interesting exercise in using Tcl's extensible C API to
load dynamic objects. The old nsssl module for AOLserver 2.x used
the old web-based admin interface with lots of Tcl code bound to
URL's with ns_register_proc. Partly because of this design, nsssl's
key, certificate, and x.509 handling is a mixture of C and Tcl code.
Since the code as a whole is functional, duplicating the same nsssl
code into an external executable seemed silly.
<p>
<p>
There are three entry points in nsssl:
<br>
Ns_ModuleInit -- for AOLserver's dynamic loader
<br>
Nsssle_Init -- for Tcl's dynamic loader (export version)
<br>
Nsssl_Init -- for Tcl's dynamic loader (domestic version)
<br>
<p>
o When AOLserver starts up as a normal web server, it invokes
Ns_ModuleInit which starts up the socket driver and initializes
SSL. The only Tcl command registered is "ssl_info," a meek
version-reporting function.
<br>
o When AOLserver starts up with ./modules/nsssl/keygen.tcl, the Tcl
"load" command this file asks the Tcl interpreter to load nsssl.so
(or nsssle.so) and invoke Nsssl_Init (or Nsssle_Init) which
registers special key/cert generation Tcl commands and initializes
SSL, but doesn't start up the socket library. When the keygen.tcl
script is finished, it terminates the server and returns.
<br>
In this fashion way we can use the same code for serving pages as
well as generating the key pair and certificate request without
having another cumbersome binary executable hanging around.
<p>
</body>
</html>
|
