If an attacker can cause a device to make an authenticated request to
a service via TLS while including a payload of the attacker's choice
in that request, and if TLS compression is enabled, the attacker can
uncover the plaintext authentication information by making a series of
guesses and observing changes in the length of the ciphertext.
This is CVE-2012-4929.
FS-6360 --resolve
Thanks-to: Brian West <brian@freeswitch.org>
Cisco 7925G seem to work only with the correct conference_id2 and
rtptimeout set, so add protocol 11 definition fields and set
conference_id2 correctly.
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Nathan Neulinger <nneul@neulinger.org>
Cisco 7925g send access status message with just 8 byte of payload data.
Since we don't interpret the unknown 3rd field anyway, remove it. This
will prevent the first register to fail.
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Nathan Neulinger <nneul@neulinger.org>
WiFi phones like the 7925g may take longer than just one second to
acknowledge the open receive message. Increase the timeout to 5 seconds.
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Nathan Neulinger <nneul@neulinger.org>
Previously we disallowed anonymous Diffie-Hellman, but there are other
kinds of null-authentication TLS suites. In particular, disallowing
AECDH is important now that we support elliptic-curve Diffie-Hellman.
This was momentarily called force_send_silence_when_idle, but that was
non-obvious as you had to set that value to true to be able to not
send silence when idle. This name describes the purpose much better.
We were handling the "send silence but not comfort noise" case in both
silence_stream_file_read and switch_generate_sln_silence. This
changes the former to rely on the latter.
If set to true, this prevents us from overriding the value of
send_silence_when_idle. When that is unset or set to zero and SRTP is
engaged, we typically override the value because many devices can't
handle gaps in the SRTP stream.
This variable is mostly for testing whether particular devices can
handle this behavior. Use at your own risk.
In commit 55d01d3defed4bfdc74704dbea0da9548a97a979 we set
send_silence_when_idle to -1 rather than 400 when SRTP is engaged.
But this left no way to enable white noise silence when desired.
When SRTP is engaged we can't simply not send RTP because it breaks
too many devices. So we need to prevent send_silence_when_idle from
being unset or being set to zero. This change allows it to be set to
other values so as to feed white noise rather than all zeros into the
codec.
When the channel variable send_silence_when_idle was set to zero,
switch_ivr_sleep was calling SWITCH_IVR_VERIFY_SILENCE_DIVISOR on it
anyway, causing it to be set to 400. The only way to get the behavior
of not sending silence when idle was to unset the variable completely.
This corrects the behavior such that setting the value to zero has the
same effect as leaving it unset.
write(3) can write fewer bytes than was requested for any number of
reasons. The correct behavior is to retry unless there is an error.
If there is an error, try to unlink the file; no sense in leaving
corrupted data laying around.
The default value of libdir is (unexpanded) '${exec_prefix}/lib'. In
the non-FHS path this is fine because it only ends up in a variable
where it will be expanded later. By using this to define modulesdir
we let it slip into a define where it made no sense.
When --enable-fhs is passed to configure, we set all paths by default
in a way compliant with FHS, the Filesystem Hierarchy Standard.
http://www.pathname.com/fhs/
Each path may still be overridden by passing the specific flag for it.
This shows the cipher name, TLS version, the number of cipher bits and
algorithm bits, and a description of the cipher in Sofia's debug
logging output on level 9.
Unlike fread(3), read(3) will return -1 on error. We were assigning
the result of read to a potentially unsigned variable, and passing the
result down to switch_xml_parse_str() where it would end up
determining how many bytes to malloc(3).
