On Mon, Feb 23, 2009 at 4:33 PM, Dean Willis <[email protected]> wrote:
> So, what are the implications for the SIP world? Well, for starters vendors need to make sure any UI that represents "this call is secure" display can't be subject to the favicon.ico trick some browsers have. think: Call-Info: <http://evil.attacker.com/padlock.jpg>;purpose=icon SIP UIs also need to ensure that they can't fall for other display-name tricks, i.e: From: "HSBC Bank" <sips:mybankmanager%40hsbc.co.uk%3e%20%20%20%20%20%20%20%20%20%20%[email protected]>;tag=xxx (it would appear the phone on my desk will indeed fall for something like this) The SSLstrip attack relies on a MITM being able to modify a HTTP response *before* getting to the HTTPS page (i.e, rewriting the links a user would normally click, such as "<a href="https://login.hsbc.co.uk";>My Account</a>"). A parallel to this attack in SIP is if a SIPS URI is first learnt through a non TLS requests, which upgrades to TLS and uses a UI hack like the one above, or even redirect to a sips URI hosted on the attackers server (resulting in a padlock, all be it the wrong one), which then forwarded the call to le bank. again, this is partially a UI design issue, and we need to ensure that UAC vendors display who the certificate has been issued to [1] as well at the identty of the remote endpoint. Luckily for us, the same sort of attack will be far harder in SIP once DNSSEC is in place (if it ever is :)) in the end to end model, as we use NAPTR for indicating the transport, this there is no risk of rewriting the response, as it will come through TLS even when non sips call in a "secured" domain; HTTPS doesn't have this. a User typing in "[email protected]" will - at least in the end to end model - result in a NAPTR RRset for hsbc.co.uk's SRV records and only TLS transports (assuming a bank was sensible and only has TLS transports), which results in another (secured by DNSSEC) SRV lookup lookup for their proxies, which then is sent via TLS to them. The worry comes when a user types "sip:[email protected]" which goes over TCP/UDP (non TLS) to a service provider, which then could return a 302 to sips:[email protected], as then we fall into the same trap as the SSLstrip MITM attack. In other words, a SIP call initiated over a non TLS transport can never be "upgraded" (via, for example, a 3xx) to TLS without being subject to this (albeit lack of user-awareness/UI design) attack. ~ Theo 1 - Although this has some issues too, obviously. -- Theo Zourzouvillys Chief Technical Officer VoIP.co.uk Sent from: Bicester Oxfordshire United Kingdom. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
