Jag har inte tittat särskilt mycket på den korta arkitektur-idé NSA publicerade - Mobility Capability Package 2012 - men kan allmänt tycka att SIP är ett intressant teknikområde när det kommer till säkerhet. Det samma för SSL.
Både SSL (och TSL) liksom SIP tittade jag på av och till medan jag kommersiellt arbetade med IT- och informationssäkerhet. Att hitta på webben kring SIP är bl.a. några tester jag gjorde åt IDG för produkter från Ingate respektive Intertex vilka båda (det finns en del SIP-teknik i Sverige även om nu Ingate sedan många år har japanska ägare med NTT):
SIP gör hela skillnaden | sartryck.idg.se
Brett stöd för SIP | sartryck.idg.se
När det gäller SSL och implementation finns alltid en tydlig risk som väl illustrerar vad man kan förvänta sig finns och behöver hantera generellt för många andra protokoll och troligen också SIP. Biblioteken för SSL-stöd är brutalt komplexa och inte i någon "formella-språk-mening" utan C-defines på C-defines. Säkerhetsdefekter både avseende felkodning relaterat till minnesfel finns att hitta och det gäller ju även "kringstöd" för ASN.1, BER m.m.
Emellertid givet NSA:s tidigare arbete med deras säkrade Linux kan vi ju se något konkret som visar att de har förståelse för denna grupp av säkerhetsproblem även om det inte är generellt för mjukvaruleverantörer. Problemen går också att hantera genom inkapsling med säkerhetslager runt om kring, filtrering av indata som går in från nätet oavsett om det direkt är genererat eller resultatet av själva protokollets olika tillståndsförändringar, liksom också i operativ system lägga stöd för att minska problematiken med minnesfel och jämförbart besläktat.
En till sida av samma problem är att protokoll-fel i implementation i meningen att odefinierade tillstånd kan vara möjliga att hamna i troligen finns. Vanligen för SSL är min tro (men ej uppdaterad med senare versioner av OpenSSL) att dessa antagligen oftast är ofarliga. Risker finns nog oftare när ej vanliga objectives binds till tillstånd ex. vissa former av IDS-lösningar.
Låt oss nu ta en snabbtitt på hur de tänker sig samspelet SSL (TSL) och SIP:
Och i ord:
"1. Device is powered on.
2. Monitoring service starts on device.
3. Configurable initialization program ensures that only authorized applications and operating
system components are loaded, and that the system is in a known secure state.
4. Once the system is fully booted and in a secure state, the user can access the device by
entering the required pin or passphrase to unlock the screen lock.
5. When the screen is unlocked, and before any other activities, a second passphrase or
password is entered to decrypt the device's memory, which also stores any required keys.
6. The user starts the VPN, which establishes a tunnel from the device to the infrastructure.
7. Upon establishment of the VPN, the user registers to the Session Initiation Protocol (SIP)
server via a Transport Layer Security (TLS) connection. This TLS connection is tunneled
through the VPN connection.
8. Once the user is registered with the SIP server, they will be able to send or receive calls."
Det tycks som ett område värt att tänka på i alla fall.
Out-of-context
Och i den bisarra sidan av PDF får vi när vi kopierar password från dokumentet:
ƉĂƐƐǁŽƌ
Och efterföljande för några ord också några av i engelskan ovanligare tecknen. Kanske något "samspel" runt UTF-8 glegget mellan PDF-stödet, Linux och Chrome. Det mest redundanta av tecknen torde vara Ƌ som vi i Wikipedia kan läsa inte längre används:
"It was used in the Zhuang alphabet from 1957 to 1986, when it was replaced by the digraph nd."
Jag står igen fascinerar över hur PDF-läsare både kan lyckas och misslyckas med att tolka texten. Den i Chrome på min Linux fungerar nästan alltid perfekt medan den enklare på min SonyEricsson Xperia ibland hamnar riktigt fel.
Foto:
Kommentera