<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Not that I have cut any code yet, but...<br>
<br>
As far as I know, the current transfer code only uses the call number
and a transfer id to verify the host. Hardly a security measure, it is
really just to make sure the correct channel is bridged. I hadn't
intended on changing this.<br>
<br>
I was thinking about it, and I figured an attacker would have to be
intercepting the packets to start with (to get the addresses and call
numbers etc). If the intent is to listen in on the call, then
manipulating the
routing is not really relevant (to prevent eavesdropping, use
encryption!). They could just as easily prevent the transfer as make a
man-in-the-middle attack, and still listen in. <br>
<br>
But if an attacker CAN get in the routing path, they can easily inject
IAX packets (like DTMF, audio or whatever). What are the implications
of this?<br>
<br>
It might be made easier by these modifications, although I think it is
possible to do now. Can we use a challenge/response on the transfer
packets? I think ALL packets would need to verify the other end:
TXCNT/TXACC and TXREQ/TXREADY/TXREL? Is it a big risk not to?<br>
<br>
<br>
Tim.<br>
<br>
<br>
<br>
<br>
Benny Amorsen wrote:
<blockquote cite="midm3bqsrg2v7.fsf@ursa.amorsen.dk" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">"TD" == Tim Davies <a class="moz-txt-link-rfc2396E" href="mailto:tim@opensystems.net.au"><tim@opensystems.net.au></a> writes:
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
TD> - always sending the TXACC to where the TXCNT came from, and then
TD> either - resending TXCNTs back to the address that TXCNTs were
TD> received from (if it different from the original address given in
TD> the TXREQ), or - sending an additional TXACC back to where a TXACC
TD> came from, in case the TXCNT never made it. A kind of 3-way
TD> handshake.
Does the IAX protocol or your changes authenticate that it's actually
the right peer you end up talking to? It sounds like a change which
has security implications.
/Benny
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
</pre>
</blockquote>
</body>
</html>