The adj_port buffer was only 5 bytes wide, so we were truncating any
port numbers >= 10000 that were written to this variable as snprintf
ensures the last byte is null.
FS-4354 --resolve
On some compilers this fixes the build.
gcc reports:
error: format not a string literal and no format arguments
clang reports:
error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
When we're terminating ZRTP to an IVR or to a leg which is not
ZRTP-capable, there's no way for us to make an intelligent decision
about whether this flag should be set. For a client to consider the
SAS as verified, however, both sides need to set this flag. By always
setting this flag on our side, we leave the decision completely in the
hands of the client where we hope there is a careful human.
Signed-off-by: Travis Cross <tc@traviscross.com>
I don't see this command being used anywhere. Since I don't like to touch core files unless absolutely necessary I'm reverting these two changes. I've emailed the author, Tamas, for an explanation. The other patches for FS-3432 (merged in now) appear to work fine without this commit.
This reverts commit fbcb862265.
In a sofia profile, you can now set the parameter tls-timeout to a
positive integer value which represents the maximum time in seconds
that OpenSSL will keep a TLS session (and its ephemeral keys) alive.
This value is passed to OpenSSL's SSL_CTX_set_timeout(3).
OpenSSL's default value is 300 seconds, but the relevant standard
(RFC 2246) suggests that much longer session lifetimes are
acceptable (it recommends values less than 24 hours).
Longer values can be useful for extending battery life on mobile
devices.
Signed-off-by: Travis Cross <tc@traviscross.com>
There are a lot of codecs these days, and some clients offer all of
them. If we run out of space in this buffer our local SDP will get
silently truncated, which will cause a difficult to diagnose error in
Sofia-SIP.
Thanks to Anthony Minessale.
FS-4293 --resolve
This error was causing us to call generate_m with a buffer length that
was less than the strlen of the buffer we were passing. The result
was truncated local SDP which would cause sofia to fail if the
truncation was in a particularly bad place.
Thanks to Anthony Minessale for the fix and working with me to
diagnose the issue.
FS-4293 --resolve
ZRTP passthrough mode allows two ZRTP-capable clients to negotiate an
end-to-end security association through FreeSWITCH. The clients are
therefore able to be certain that the FreeSWITCH instance mediating
the call cannot eavesdrop on their conversation.
Importantly, this capability is maintained across multiple FreeSWITCH
hops. If widely deployed, this enables a global network architecture
where two people can speak securely with strong cryptographically
protected authentication and confidentiality.
With this commit we implement a zrtp-passthru mode that handles all
the details of the negotiation intelligently. This mode can be
selected by setting the boolean parameter inbound-zrtp-passthru in the
sofia profile. This will also force late-negotiation as it is
essential for correctly negotiating an end-to-end ZRTP security
association.
When an incoming call with a zrtp-hash is received and this mode is
enabled, we find the first audio and the first video zrtp-hash in the
SDP and store them as remote values on this channel. Once a b-leg is
available, we set the local zrtp-hash values on that channel to the
remote zrtp-hash values collected from the a-leg.
Because zrtp-passthru absolutely requires that the channels negotiate
the same codec, we offer to the b-leg only codecs that the a-leg can
speak. Once the b-leg accepts a codec, we will force that choice onto
the a-leg.
If the b-leg sends us zrtp-hash values in the signaling, we store
those as remote values on the b-leg and copy them to the local values
on the a-leg.
At this point, each leg has the zrtp-hash values from the other, and
we know we can do ZRTP passthrough mode on the call. We send the
b-leg's zrtp-hash back to the a-leg in the 200 OK.
We then enable UDPTL mode on the rtp streams for both the audio and
the video so that we don't interfere in the ZRTP negotiation.
If the b-leg fails to return a zrtp-hash in the signaling, we set up a
ZRTP security association with the a-leg ourselves, if we are so
equipped. Likewise, if the a-leg fails to send a zrtp-hash in the
signaling, we attempt to set up a ZRTP security association ourselves
with the b-leg.
The zrtp-passthru mode can also be enabled in the dialplan by setting
the boolean channel variable zrtp_passthru. If enabled in this
manner, we can't force late-negotiation, so the user would need to be
sure this is configured.
If ZRTP passthrough mode is not enabled in either manner, this change
should have no effect.
Channel variables for each of the various zrtp-hash values are set,
though it is anticipated that there is no good reason to use them, so
they may be removed without warning. For checking whether zrtp
passthrough mode was successful, we provide the channel variable
zrtp_passthru_active which is set on both legs.
Though not implemented by this commit, the changes here should make it
more straightforward to add correct zrtp-hash values to the signaling
and verify that correct hello hash values are received when FreeSWITCH
is acting as a terminating leg of the ZRTP security association.
A historical note...
This commit replaces the recently-added sdp_zrtp_hash_string method,
commit 2ab1605a88.
This prior method sets a channel variable from the a-leg's zrtp-hash,
then relies on the dialplan to export this channel variable to the
b-leg, where it is put into the SDP.
While it was a great start and wonderful for testing, this approach
has some drawbacks that motivated the present work:
* There's no good way to pass the zrtp-hash from the b-leg back to
the a-leg. In fact, the implementation seems to send the a-leg's
zrtp-hash back to the originating client in the 200 OK. This is
not correct.
* To support video, we'd need to have a separate dialplan variable,
and the dialplan author would need to deal with that explicitly.
* The API is problematic as it requires the dialplan author to
understand intricate details of how ZRTP works to implement a
correct dialplan. Further, by providing too fine-grained control
(but at the same time, not enough control) it would limit our
ability to make the behavior smarter once people started relying on
this.
This amends commit 7bd9efc7f5.
We changed away from using unsigned here because it caused a warning
on Windows. Using the more specific type, however, is causing a
warning on gcc-4.7 (it notices that the switch statement contains
values not present in the specified enum type). So we're switching
back to unsigned here while keeping the type casts and hoping that
keeps Windows happy.
This amends commit 7bd9efc7f5.
Using the more explicit typedef causes gcc to warn about the
incompatible types for the reasons noted in the earlier commit
message. This is why we just used the unsigned type earlier so we
could avoid all this casting.
The things we do to make Windows happy...
According Jeff Lenk, Windows Visual Studio doesn't understand that
people use the char type for non-null-terminated byte arrays, so it
throws a warning about this that causes the build to fail on Windows.
As the initial value for the ZID doesn't really matter here one iota,
just null-terminate it on Windows.
libzrtp's sas_is_verified field is a uint32_t, but zrtp_verified_set
expects a uint8_t. This is a boolean field, so it doesn't matter one
way or the other. gcc doesn't care, but Windows Visual Studio
apparently throws a warning about this.
The callback here receives both zrtp_protocol_event_t and
zrtp_security_event_t events. The latter is numbered contiguously to
the former. Still, it's a bit confusing to have to pick one as a
type, but apparently this fixes a warning on Visual Studio on Windows.
Thanks to Jeff Lenk.
Brian and I talked about this and concurred on the reversion here.
Part of the point of the ZRTP pass-through mode code is that it allows
two legs to have a ZRTP-enabled call even if FS doesn't have ZRTP.
This reverts commit f0aa4ab390.
Anthony Minessale