forked from OpenSIPS/opensips
/
README
425 lines (299 loc) · 13.1 KB
/
README
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
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
TLS module
Peter Griffiths
unknown
Klaus Darilion
enum.at
Edited by
Klaus Darilion
Edited by
Bogdan-Andrei Iancu
Edited by
Cesc Santasusana
Edited by
Klaus Darilion
Edited by
Christian Lahme
Edited by
Ionut-Razvan Ionita
Copyright © 2005 Voice Sistem SRL
Copyright © 2005 Cesc Santasusana
Copyright © 2006 enum.at
Copyright © 2013 Secusmart GmbH
Copyright © 2015 OpenSIPS Solutions
__________________________________________________________
Table of Contents
1. Admin Guide
1.1. Overview
1.2. History
1.3. Scenario
1.4. Dependencies
1.4.1. OpenSIPS Modules
1.5. OpenSIPS Exported parameters
1.5.1. listen=interface
1.5.2. tls_port (integer)
1.5.3. tls_crlf_pingpong (integer)
1.5.4. tls_crlf_drop (integer)
1.5.5. tls_max_msg_chunks (integer)
2. Developer Guide
2.1. TLS_SERVER
2.1.1. SSL data per connection
2.1.2. tls_print_errstack
2.1.3. tls_tcpconn_init
2.1.4. tls_tcpconn_clean
2.1.5. tls_blocking_write
2.1.6. tls_read
2.1.7. tls_fix_read_conn
3. Frequently Asked Questions
List of Examples
1.1. Set listen variable
1.2. Set tls_port variable
1.3. Set tls_crlf_pingpong parameter
1.4. Set tls_crlf_drop parameter
1.5. Set tls_max_msg_chunks parameter
Chapter 1. Admin Guide
1.1. Overview
TLS, as defined in SIP RFC 3261, is a mandatory feature for
proxies and can be used to secure the SIP signalling on a
hop-by-hop basis (not end-to-end). TLS works on top of TCP.
DTLS, or TLS over UDP is already defined by IETF and may become
available in the future. This module also implements TLS
related functions to use in the routing script, and exports
pseudo variables with certificate and TLS parameters.
1.2. History
The TLS support was originally developed by Peter Griffiths and
posted as a patch on SER development mailing list. Thanks to
Cesc Santasusana, several problems were fixed and some
improvements were added.
The TLS support was simultaneously added in both projects. In
SER, the support was committed in a separate “experimental” CVS
tree, as patch to the main CVS tree. In OpenSIPS, the support
was integrated directly into the CVS tree, as a built-in
component, and is part of stable OpenSIPS since release
>=1.0.0.
1.3. Scenario
By the increased number of providers the SIP world is
continuously growing. More users means more calls and more
calls means a high probability for a user to receive calls from
totally unknown people or, in the worst case, to receive
unwanted calls. To prevent this, a defense mechanism must be
adopted by the SIP provider. Since only the called user is
fully able to classify a call as being unwanted, the SIP
server, based on all information regarding the call should
notify the user about the desirability of the call. Information
like the caller domain, the received source or the incoming
protocol can be very useful for a SIP server to establish the
nature of the call.
As this information is quite limited, is very improbable for a
server to be able detect the unwanted calls - there are many
calls that it cannot predict anything about its status (neutral
calls). So, instead on alerting the called user about unwanted
calls, the server can notify the user about calls that are
considered trusted - calls for which the server is 100% sure
there are not unwanted.
So, a trust concept must be defined for SIP servers. Which
calls are trusted and which are not? A call is trusted if the
caller can be identify as a trustable user - a user about we
have reliable information.
Since all the user from its domain are authenticated (or should
be), a SIP server can consider all the calls generated by its
user as trusted. Now we have to extend the trust concept to the
multi-domain level. A mutual agreement, between several
domains, can establish a trusting relationship. So, a domain
(called A) will consider also as trusted calls all the calls
generated by user from a different domain (called B) and
vice-versa. But just an agreement is not enough; since the
authentication information is strictly limited to a domain (a
domain can authenticate only its own user, not the user from
other domains), there is still the problem of checking the
authenticity of the caller - he can impersonate (by a false
FROM header) a user from a domain that is trusted.
The answer to this problem is TLS (Transport Layer Security).
All calls via domain A and domain B will be done via TLS.
Authentication in origin domain plus TLS transport between
domains will make the call 100% trusted for the target domain.
For such a mechanism to work, the following requirements must
be met:
* all UA must have set as outbound proxy their home server.
* all SIP servers must authenticated all the calls generated
by their own users.
* all SIP servers must relay the calls generated be their
user to a trusted domain via TLS.
Based on this, a server can classify as trusted a call for one
of its user only if the call is also generated by one of its
users or is the call is received from a trusted domain ( which
is equivalent with a call received via TLS). Untrusted call
will be calls received from users belonging to untrusted
domains or from users from trusted domains, but whose calls are
not routed via their home server (so, they are not
authenticated by there home servers).
Once the server is able to tell if the call is trusted or not,
the still open issue is about the mechanism used by server to
notify the called user about the nature of the incoming call.
One way to do it is by remotely changing the ringing type of
the called user's phone. This can be done by inserting special
header into the INVITE request. Such feature is supported by
now by several hardphones like CISCO ATA, CISCO 7960 and SNOM.
This phones can change their ringing tone based on the present
or content of the "Alert-Info" SIP header as follows:
* CISCO ATA - it has 4 pre-defined ringing types. The
Alert-Info header must look like “Alert-info: Bellcore-drX
EOH"” where X can be between 1 and 4. Note that 1 is the
phone default ringing tone.
* CISCO 7960 - it has 2 pre-defined ringing types and the
possibility of uploading new ones. The “Alert-Info” header
must look like “Alert-info: X EOH” where X can be whatever
number. When this header is present, the phones will not
change the ringing tone, but the ringing pattern. Normally,
the phone rings like [ring.........ring..........ring]
where [ring] is the ringing tone; if the header is present,
the ringing pattern will be
[ring.ring.........ring.ring........]. So, to be able to
hear some difference between the two patterns (and not only
as length), its strongly recommended to have a highly
asymmetric ringing type (as the pre-defined are not!!).
* SNOM - The “Alert-Info” header must look like “Alert-info:
URL EOH"” where URL can be a HTTP URL (for example) from
where the phone can retrieve a ringing tone.
1.4. Dependencies
1.4. Dependencies
1.4.1. OpenSIPS Modules
The following modules must be loaded before this module:
* tls_mgm.
OpenSIPS TLS v1.0 support requires the following packages:
* openssl or libssl >= 0.9.6
* openssl-dev or libssl-dev
OpenSIPS TLS v1.1/1.2 support requires the following packages:
* openssl or libssl >= 1.0.1e
* openssl-dev or libssl-dev
1.5. OpenSIPS Exported parameters
All these parameters can be used from the opensips.cfg file, to
configure the behavior of OpenSIPS-TLS.
1.5.1. listen=interface
Not specific to TLS. Allows to specify the protocol (udp, tcp,
tls), the IP address and the port where the listening server
will be.
Example 1.1. Set listen variable
...
listen = tls:1.2.3.4:5061
...
1.5.2. tls_port (integer)
Sets the default TLS listening port.
Default value is 5061.
Example 1.2. Set tls_port variable
...
modparam("proto_tls", "tls_port", 5062)
...
1.5.3. tls_crlf_pingpong (integer)
Send CRLF pong (\r\n) to incoming CRLFCRLF ping messages over
TLS. By default it is enabled (1).
Default value is 1 (enabled).
Example 1.3. Set tls_crlf_pingpong parameter
...
modparam("proto_tls", "tls_crlf_pingpong", 0)
...
1.5.4. tls_crlf_drop (integer)
Drop CRLF (\r\n) ping messages. When this parameter is enabled,
the TLS layer drops packets that contains a single CRLF
message. If a CRLFCRLF message is received, it is handled
according to the tls_crlf_pingpong parameter.
Default value is 0 (disabled).
Example 1.4. Set tls_crlf_drop parameter
...
modparam("proto_tls", "tls_crlf_drop", 1)
...
1.5.5. tls_max_msg_chunks (integer)
The maximum number of chunks that a SIP message is expected to
arrive via TLS. If a packet is received more fragmented than
this, the connection is dropped (either the connection is very
overloaded and this leads to high fragmentation - or we are the
victim of an ongoing attack where the attacker is sending the
traffic very fragmented in order to decrease our performance).
Default value is 4.
Example 1.5. Set tls_max_msg_chunks parameter
...
modparam("proto_tls", "tls_max_msg_chunks", 8)
...
Chapter 2. Developer Guide
2.1. TLS_SERVER
2.1.1. SSL data per connection
Each TLS connection, incoming or outgoing, creates an SSL *
object, where configuration inherited from the SSL_CTX * and
particular info on that socket are stored. This SSL * structure
is kept in OpenSIPS as long as the connection is alive, as part
of the “struct tcp_connection *” object:
...
struct tcp_connection *c;
SSL *ssl;
/*create somehow SSL object*/
c->extra_data = (void *) ssl;
ssl = (SSL *) c->extra_data;
...
2.1.2. tls_print_errstack
void tls_print_errstack(void);
Dumps ssl error stack.
2.1.3. tls_tcpconn_init
int tls_tcpconn_init( struct tcp_connection *c, int fd);
Called when new tcp connection is accepted
2.1.4. tls_tcpconn_clean
void tls_tcpconn_clean( struct tcp_connection *c);
Shuts down the TLS connection.
2.1.5. tls_blocking_write
size_t tls_blocking_write( struct tcp_connection *c, int fd,
const char *buf, size_t len);
Writes a memory chunk in blocking mode (syncron).
2.1.6. tls_read
size_t tls_read( struct tcp_connection *c);
Reads from a TLS connection. Return the number of bytes read.
2.1.7. tls_fix_read_conn
void tls_tcpconn_clean( struct tcp_connection *c);
Shuts down the TLS connection.
Chapter 3. Frequently Asked Questions
3.1.
Where can I post a question about TLS?
Use one (the most appropriate) of the OpenSIPS mailing lists:
* User Mailing List -
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
* Developer Mailing List -
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Remember: first at all, check if your question wasn't already
answered.
3.2.
How can I report a bug?
Accumulate as much as possible information (OpenSIPS version,
opensips -V output, your OS (uname -a), OpenSIPS logs, network
dumps, core dump files, configuration file) and send a mail to
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Also you may try OpenSIPS's bug report web page:
http://www.opensips.org/pmwiki.php?n=Development.Tracker
3.3.
How can I debug ssl/tls problems?
Increase the log level in opensips.cfg (debug=4) and watch the
log statements in syslog.
Install the ssldump utility and start it. This will give you a
trace of the ssl/tls connections.
3.4.
What is the difference between the TLS directory and the TLSOPS
module directory?
The code in the TLS directory implements the TLS transport
layer. The TLSOPS module implements TLS related functions which
can be used in the routing script.
3.5.
Where can I find more about OpenSIPS?
Take a look at http://www.opensips.org/.
3.6.
Where can I post a question about this module?
First at all check if your question was already answered on one
of our mailing lists:
* User Mailing List -
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
* Developer Mailing List -
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
E-mails regarding any stable OpenSIPS release should be sent to
<users@lists.opensips.org> and e-mails regarding development
versions should be sent to <devel@lists.opensips.org>.
If you want to keep the mail private, send it to
<users@lists.opensips.org>.
3.7.
How can I report a bug?
Please follow the guidelines provided at:
https://github.com/OpenSIPS/opensips/issues.