-
Notifications
You must be signed in to change notification settings - Fork 565
/
proto_tls_admin.xml
634 lines (600 loc) · 21.4 KB
/
proto_tls_admin.xml
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
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
<!-- Module User's Guide -->
<chapter>
<title>&adminguide;</title>
<section id="overview" xreflabel="Overview">
<title>Overview</title>
<para>
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.
</para>
</section>
<section>
<title>History</title>
<para>
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.
</para>
<para>
The TLS support was simultaneously added in both projects. In SER,
the support was committed in a separate <quote>experimental</quote>
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.
</para>
<para>
Starting with OpenSIPS 2.1, the TLS has been moved to a separate
transport module, that implements the more generic Transport
Interface.
</para>
</section>
<section>
<title>Scenario</title>
<para>
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.
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
For such a mechanism to work, the following requirements must be met:
</para>
<itemizedlist>
<listitem>
<para>
all UA must have set as outbound proxy their home server.
</para>
</listitem>
<listitem>
<para>
all SIP servers must authenticated all the calls generated by
their own users.
</para>
</listitem>
<listitem>
<para>all SIP servers must relay the calls generated be their
user to a trusted domain via TLS.
</para>
</listitem>
</itemizedlist>
<para>
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).
</para>
<para>
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.
</para>
<para>
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:
</para>
<itemizedlist>
<listitem>
<para><emphasis>CISCO ATA</emphasis> - it has 4 pre-defined
ringing types. The Alert-Info header must look like
<quote>Alert-info: Bellcore-drX EOH</quote> where X can be
between 1 and 4. Note that 1 is the phone default ringing tone.
</para>
</listitem>
<listitem>
<para><emphasis>CISCO 7960</emphasis> - it has 2 pre-defined
ringing types and the possibility of uploading new ones.
The <quote>Alert-Info</quote> header must look like
<quote>Alert-info: X EOH</quote> 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!!).
</para>
</listitem>
<listitem>
<para><emphasis>SNOM</emphasis> - The <quote>Alert-Info</quote>
header must look like <quote>Alert-info: URL EOH"</quote> where
URL can be a HTTP URL (for example) from where the phone can
retrieve a ringing tone.
</para>
</listitem>
</itemizedlist>
</section>
<section id="dependencies" xreflabel="Dependencies">
<title>Dependencies</title>
<section>
<title>&osips; Modules</title>
<para>
The following modules must be loaded before this module:
<itemizedlist>
<listitem>
<para>
<emphasis>tls_openssl</emphasis> or <emphasis>tls_wolfssl</emphasis>,
depending on the desired TLS library
</para>
</listitem>
<listitem>
<para>
<emphasis>tls_mgm</emphasis>.
</para>
</listitem>
</itemizedlist>
</para>
</section>
<section>
<title>Dependencies of external libraries</title>
<para>
The following libraries or applications must be installed before
running &osips; with this module loaded:
<itemizedlist>
<listitem>
<para>
<emphasis>None</emphasis>.
</para>
</listitem>
</itemizedlist>
</para>
</section>
</section>
<section>
<title>&osips; Exported parameters</title>
<para>
All these parameters can be used from the opensips.cfg file,
to configure the behavior of &osips;-TLS.
</para>
<section id="param_listen" xreflabel="listen">
<title><varname>listen</varname>=interface</title>
<para>
Not specific to TLS. Allows to specify the protocol
(udp, tcp, tls), the IP address and the port where the
listening server will be.
</para>
<example>
<title>Set <varname>listen</varname> variable</title>
<programlisting format="linespecific">
...
socket= tls:1.2.3.4:5061
...
</programlisting>
</example>
</section>
<section id="param_tls_port" xreflabel="tls_port">
<title><varname>tls_port</varname> (integer)</title>
<para>
The default port to be used for all TLS related operation. Be
careful as the default port impacts both the SIP listening part
(if no port is defined in the TLS listeners) and the SIP sending
part (if the destination URI has no explicit port).
</para>
<para>
If you want to change only the listening port for TLS, use the port
option in the SIP listener defintion.
</para>
<para><emphasis>
Default value is 5061.
</emphasis></para>
<example>
<title>Set <varname>tls_port</varname> variable</title>
<programlisting format="linespecific">
...
modparam("proto_tls", "tls_port", 5062)
...
</programlisting>
</example>
</section>
<section id="param_tls_crlf_pingpong" xreflabel="tls_crlf_pingpong">
<title><varname>tls_crlf_pingpong</varname> (integer)</title>
<para>
Send CRLF pong (\r\n) to incoming CRLFCRLF ping messages over TLS.
By default it is enabled (1).
</para>
<para>
<emphasis>
Default value is 1 (enabled).
</emphasis>
</para>
<example>
<title>Set <varname>tls_crlf_pingpong</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("proto_tls", "tls_crlf_pingpong", 0)
...
</programlisting>
</example>
</section>
<section id="param_tls_crlf_drop" xreflabel="tls_crlf_drop">
<title><varname>tls_crlf_drop</varname> (integer)</title>
<para>
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
<emphasis>tls_crlf_pingpong</emphasis> parameter.
</para>
<para>
<emphasis>
Default value is 0 (disabled).
</emphasis>
</para>
<example>
<title>Set <varname>tls_crlf_drop</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("proto_tls", "tls_crlf_drop", 1)
...
</programlisting>
</example>
</section>
<section id="param_tls_max_msg_chunks" xreflabel="tls_max_msg_chunks">
<title><varname>tls_max_msg_chunks</varname> (integer)</title>
<para>
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 server performance).
</para>
<para>
<emphasis>
Default value is 4.
</emphasis>
</para>
<example>
<title>Set <varname>tls_max_msg_chunks</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("proto_tls", "tls_max_msg_chunks", 8)
...
</programlisting>
</example>
</section>
<section id="param_tls_cert_check_on_conn_reusage" xreflabel="cert_check_on_conn_reusage">
<title><varname>cert_check_on_conn_reusage</varname> (integer)</title>
<para>
This parameter turns on or off the extra checking/matching of the
TLS domain (SSL certificate) when comes to reusing an existing TLS
connection. Without this extra check, only IP and port of the
connections will be check (in order to re-use an existing connection).
With this extra check, the connection to be reused must have the same
SSL certificate as the one set for the current signaling operation.
</para>
<para>
This checking is done only when comes to send SIP traffic via TLS and
it is applied only against connections that were created / initiated
by OpenSIPS (as TLS client). Any accepte connection (as TLS server) will
automatically match (the extra test will be skipped).
</para>
<para>
<emphasis>
Default value is 0 (disabled).
</emphasis>
</para>
<example>
<title>Set <varname>cert_check_on_conn_reusage</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("proto_tls", "cert_check_on_conn_reusage", 1)
...
</programlisting>
</example>
</section>
<section id="param_tls_trace_destination" xreflabel="trace_destination">
<title><varname>trace_destination</varname> (string)</title>
<para>
Trace destination as defined in the tracing module. Currently
the only tracing module is <emphasis role="bold">proto_hep</emphasis>.
Network events such as connect, accept and connection closed events
shall be traced along with errors that could appear in the process.
For each connection that is created an event containing information
about the client and server certificates, master key and network layer
information shall be sent.
</para>
<para>
<emphasis role="bold">WARNING: </emphasis>A tracing module must be
loaded in order for this parameter to work. (for example
<emphasis role="bold">proto_hep</emphasis>).
</para>
<para>
<emphasis>
Default value is none(not defined).
</emphasis>
</para>
<example>
<title>Set <varname>trace_destination</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("proto_hep", "hep_id", "[hep_dest]10.0.0.2;transport=tcp;version=3")
modparam("proto_tls", "trace_destination", "hep_dest")
...
</programlisting>
</example>
</section>
<section id="param_trace_on" xreflabel="trace_on">
<title><varname>trace_on</varname> (int)</title>
<para>
This controls whether tracing for tls is on or not. You still need to define
<xref linkend="param_tls_trace_destination"/>in order to work, but this value will be
controlled using mi function <xref linkend="mi_tls_trace"/>.
</para>
<emphasis>
Default value is 0(tracing inactive).
</emphasis>
<example>
<title>Set <varname>trace_on</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("proto_tls", "trace_on", 1)
...
</programlisting>
</example>
</section>
<section id="param_trace_filter_route" xreflabel="trace_filter_route">
<title><varname>trace_filter_route</varname> (string)</title>
<para>
Define the name of a route in which you can filter which connections will
be trace and which connections won't be. In this route you will have
information regarding source and destination ips and ports for the current
connection. To disable tracing for a specific connection the last call in
this route must be <emphasis role="bold">drop</emphasis>, any other exit
mode resulting in tracing the current connection ( of course you still
have to define a <xref linkend="param_tls_trace_destination"/> and trace must be
on at the time this connection is opened.
</para>
<para>
<emphasis role="bold">IMPORTANT</emphasis>
Filtering on ip addresses and ports can be made using <emphasis role="bold">
$si</emphasis> and <emphasis role="bold">$sp</emphasis> for matching
either the entity that is connecting to &osips; or the entity to which
&osips; is connecting. The name might be misleading (<emphasis role="bold">
$si</emphasis> meaning the source ip if you read the docs) but in reality
it is simply the socket other than the &osips; socket. In order to match
&osips; interface (either the one that accepted the connection or the one
that initiated a connection) <emphasis role="bold">$socket_in(ip)</emphasis> (ip) and
<emphasis role="bold">$socket_in(port)</emphasis> (port) can be used.
</para>
<para>
<emphasis role="bold">WARNING:</emphasis> IF <xref linkend="param_trace_on"/> is
set to 0 or tracing is deactived via the mi command <xref linkend="mi_tls_trace"/>
this route won't be called.
</para>
<emphasis>
Default value is none(no route is set).
</emphasis>
<example>
<title>Set <varname>trace_filter_route</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("proto_tls", "trace_filter_route", "tls_filter")
...
/* all tls connections will go through this route if tracing is activated
* and a trace destination is defined */
route[tls_filter] {
...
/* all connections opened from/by ip 1.1.1.1:8000 will be traced
on interface 1.1.1.10:5060(opensips listener)
all the other connections won't be */
if ( $si == "1.1.1.1" && $sp == 8000 &&
$socket_in(ip) == "1.1.1.10" && $socket_in(port) == 5060)
exit;
else
drop;
}
...
</programlisting>
</example>
</section>
<section id="param_tls_handshake_timeout" xreflabel="tls_handshake_timeout">
<title><varname>tls_handshake_timeout</varname> (integer)</title>
<para>
Sets the timeout (in milliseconds) for the SSL handshake sequence to complete.
It may be necessary to increase this value when using a CPU intensive cipher
for the connection to allow time for keys to be generated and processed.
</para>
<para>
The timeout is invoked during acceptance of a new connection (inbound) and
during the wait period when a new session is being initiated (outbound).
</para>
<para><emphasis>
Default value is 100.
</emphasis></para>
<example>
<title>Set <varname>tls_handshake_timeout</varname> variable</title>
<programlisting format="linespecific">
param("proto_tls", "tls_handshake_timeout", 200) # number of milliseconds
</programlisting>
</example>
</section>
<section id="param_tls_send_timeout" xreflabel="tls_send_timeout">
<title><varname>tls_send_timeout</varname> (integer)</title>
<para>
Sets the timeout (in milliseconds) for the send operations to complete
</para>
<para>
The send timeout is invoked for all TLS write operations, excluding
the handshake process (see: tls_handshake_timeout)
</para>
<para><emphasis>
Default value is 100.
</emphasis></para>
<example>
<title>Set <varname>tls_send_timeout</varname> variable</title>
<programlisting format="linespecific">
param("proto_tls", "tls_send_timeout", 200) # number of milliseconds
</programlisting>
</example>
</section>
<section id="param_tls_async" xreflabel="tls_async">
<title><varname>tls_async</varname> (integer)</title>
<para>
If the TLS connect and write operations should be done in an
asynchronous mode (non-blocking connect and
write). If disabled, OpenSIPS will block and wait for TLS
operations like connect and write.
</para>
<para><emphasis>
Default value is 0 (disabled).
</emphasis></para>
<example>
<title>Set <varname>tls_async</varname> variable</title>
<programlisting format="linespecific">
param("proto_tls", "tls_async", 1) # enable async TLS
</programlisting>
</example>
</section>
<section>
<title><varname>tls_async_max_postponed_chunks</varname> (integer)</title>
<para>
If <emphasis>tls_async</emphasis> is enabled, this specifies the
maximum number of SIP messages that can be stashed for later/async
writing. If the connection pending writes exceed this number, the
connection will be marked as broken and dropped.
</para>
<para>
<emphasis>
Default value is 32.
</emphasis>
</para>
<example>
<title>Set <varname>tls_async_max_postponed_chunks</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("proto_tls", "tls_async_max_postponed_chunks", 16)
...
</programlisting>
</example>
</section>
<section>
<title><varname>tls_async_local_connect_timeout</varname> (integer)</title>
<para>
If <emphasis>tls_async</emphasis> is enabled, this specifies the
number of milliseconds that a connect will be tried in blocking
mode (optimization). If the connect operation lasts more than
this, the connect will go to async mode and will be passed to tls
MAIN for polling.
</para>
<para>
<emphasis>
Default value is 100 ms.
</emphasis>
</para>
<example>
<title>Set <varname>tls_async_local_connect_timeout</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("proto_tls", "tls_async_local_connect_timeout", 200)
...
</programlisting>
</example>
</section>
<section>
<title><varname>tls_async_handshake_timeout</varname> (integer)</title>
<para>
If <emphasis>tls_async</emphasis> is enabled, this specifies the
number of milliseconds that a TLS handshake should be tried in blocking
mode (optimization). If the handshake operation lasts more than this,
the write will go to async mode and will be passed to tls MAIN for
polling.
</para>
<para>
<emphasis>
Default value is 10 ms.
</emphasis>
</para>
<example>
<title>Set <varname>tls_async_handshake_timeout</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("proto_tls", "tls_async_handshake_timeout", 100)
...
</programlisting>
</example>
</section>
</section>
<section id="exported_mi_functions" xreflabel="Exported MI Functions">
<title>Exported MI Functions</title>
<section id="mi_tls_trace" xreflabel="tls_trace">
<title>
<function moreinfo="none">tls_trace</function>
</title>
<para>
</para>
<para>
Name: <emphasis>tls_trace</emphasis>
</para>
<para>Parameters: </para>
<itemizedlist>
<listitem>
<para>trace_mode(optional): set tls tracing on and off. This parameter
can be missing and the command will show the current tracing
status for this module( on or off );
Possible values:
<itemizedlist>
<listitem><para> on </para></listitem>
<listitem><para> off </para></listitem>
</itemizedlist>
</para>
</listitem>
</itemizedlist>
<para>
MI FIFO Command Format:
</para>
<programlisting format="linespecific">
opensips-cli -x mi tls_trace on
</programlisting>
</section>
</section>
</chapter>