1 / 63

Unified Communications

Unified Communications. Information Loss Through the Front Door. This Federation Thing. Federation is an Old Story. Bob wants to send Alice a message, but he only knows her email address Bob doesn’t have any details about Alice’s mail server or who delivers his message

flavia-newman
Télécharger la présentation

Unified Communications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Unified Communications Information Loss Through the Front Door

  2. This Federation Thing

  3. Federation is an Old Story Bob wants to send Alice a message, but he only knows her email address Bob doesn’t have any details about Alice’s mail server or who delivers his message How does Bob find the path to Alice?

  4. MX: Gluing Email Together DNS provides the answer; MX records bind domains together • The two domains can find each other and exchange messages without previously knowing anything about the other party • This is federation • The two domains may authenticate one another • Each domain trusts the other to authenticate and identify their own user Non-authoritative answer: yahoo.com MX preference = 1, mail exchanger = mta5.am0.yahoodns.net yahoo.com MX preference = 1, mail exchanger = mta6.am0.yahoodns.net yahoo.com MX preference = 1, mail exchanger = mta7.am0.yahoodns.net

  5. The Many Names of IM Instant messaging has failed at this for many years Multiple networks, multiple protocols, multiple user identities Instant messaging vendors want to own your attention

  6. IM Federation Instant messaging is finally catching up to email You can have a single identity and still chat with all of your friends. That’s IM federation Instead of one protocol per network you now have SIP Or more importantly, you have XMPP

  7. XMPP A brief and biased primer

  8. What is XMPP? The Extensible Messaging and Presence Protocol A layer 7 transport to build flexible protocols Bound to other transports including TCP and HTTP A structured XML document built over time where each element creates another protocol element 3 main building blocks that are called stanzas

  9. <message> The building block of Instant Messages in XMPP A message has a body It can also have more • A subject • A thread <message type="chat" from="bob@gmail.com/Psi+" to="alice@yahoo.com" id="aadaa"> <body>a simple IM message</body> </message>

  10. <message> A message can get very complicated It can support multiple languages, threading references, XHTML formating… Values can be UNICODE because the XML character encoding should be UTF-8 <message type="chat" from="bob@gmail.com/Psi+" to="alice@yahoo.com" id="aadaa" xml:lang="en"> <subject>A big example</subject> <subject xml:lang="fr">A big example</subject> <body>a simple IM message</body> <body xml:lang="fr">I don’t speak French</body> <thread parent="07a9311b">ef993107</thread> <html xmlns="http://jabber.org/protocol/xhtml-im"> <body xmlns="http://www.w3.org/1999/xhtml"> <p>I can<span style="font-style: italic">get</span> complicated</p> </body> </html> </message>

  11. <message> But more importantly, it’s UDP or Push A message with an arbitrary <xs:any/> payload is sent to a specific address You may get an error response back, but it’s not required While <message/> began as an IM it’s a building block for any kind of protocol <message type="chat" from="bob@gmail.com/Psi+" to="alice@yahoo.com" id="aadaa"> <composing xmlns="http://jabber.org/protocol/chatstates"/> <request xmlns="urn:xmpp:receipts"/> </message> <message type="chat" from="bob@gmail.com/Psi+" to="alice@yahoo.com" id="aadaa"> <error type="cancel"> <gone xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"> alice@yahoo.com </gone> </error> </message>

  12. <presence> <presence /> is multi-purpose It allows a resource to request access to information, to confirm or deny that access, and to send asynchronous updates when information changes And just like <message> it’s a communications model for building more complex protocols: Publish-Subscribe or Broadcast Publish-Subscribe: <presence from="bob@gmail.com" to="alice@yahoo.com" id="e7ff18" type="subscribe"/> <presence from="alice@yahoo.com" to="bob@gmail.com" id="pres1" type="subscribed"/> Update Broadcast: <presence from="bob@gmail.com/Psi+" to="alice@yahoo.com"> <show>away</show> <status>I am not here to take your call right now</status> </presence> Join the Group Channel #xmpp_chat with nickname bobryan: <presence from="bob@gmail.com/Psi+" to="xmpp_chat@gmail.com/bobryan" id="a814df"> <x xmlns="http://jabber.org/protocol/muc"/> </presence>

  13. <presence> Presence relationships are long-lived • Persistently stored in a database, and the server is responsible for maintaining them Presence relationships are one-way • Bob may subscribe to Alice, but that doesn’t mean Alice subscribes to Bob This is very different than SIP, and can offer challenges in bridging the two protocols

  14. <iq> IQ is Request-Response and it’s the workhorse of new XMPP interactions The requests have a type of getor set and must receive a response of result or error Requests must have at least one element in them that defines the request, and a successful result will have elements that contain the answer IQs can address anything which can be named: users, user endpoints, servers, components, channels… <iqfrom="bob@gmail.com/Psi+" to="alice@yahoo.com" id="e7ff18" type="get"> … must have an element that defines the request … </iq> Query the roster: <query xmlns="jabber:iq:roster"/> Query information about an entity: <query xmlns="jabber:iq:disco#info"/>

  15. Extensible XMPP started in 1999 As such, there may be a little baggage to deal with • 2 official collections of RFCs + “pre-standard” • 314 registered extensions (XEPs), some with multiple versions But XMPP is designed for extension. It makes it really easy. It tries to advertise everything and let the user make their own choices

  16. So Why All the XMPP Talk?

  17. IM is a Social Toy, Right?

  18. Business Critical Functionality

  19. Security’s a User Problem Phishing& SPIM Malware Regulatory Compliance • Sarbanes Oxley • HIPPA • Many others… We’re OK now

  20. But IM Grew Up It’s now Unified Communications, and instant messaging is just a useful after-thought Unified Communications market estimates* • $100’s M in 2007, $4B in 2011 PBX replacement lifecycle is 3-7 years

  21. Meet your Next Phone It’s an IM client It’s a video phone It shares presentations, applications, yourdesktop… It’s always on It builds on many different protocols andhasdriver level access to your media devices And it is running on everything: your laptop,your desktop, your desk phone, your iPad,your mobile phone, in your web browser,in SharePoint…

  22. FinServ and the IM Clearing House Since 1999 banks have tried to create a single, federated IM community But the bankers stayed where the money was

  23. What the Private Sector Can’t Do For 10 years Fortune 500 companies couldn’t get the industry to standardize Governments and the US Department of Defense have spoken

  24. And Hello Federation And the Department of Defense required what the business community has only been able to dream about All instant messaging and presence systems approved for sale to the US DoD must federate over XMPP and interoperate between vendors http://www.disa.mil/Services/Network-Services/UCCO/~/media/Files/DISA/Services/UCCO/UCR2008-Change-3/12UCR08Chg3Section57.pdf

  25. The Front Door And what you can find if you open it

  26. <stream:stream> The stream is the XMPP transport It provides flow control, error handling, and a growing number of extension protocols In server 2 server it is uni-directional • Stanzas flow from Client to Server • Each end initiates their own stream • The bidi extension addresses this interesting design choice Streams inherently have insecure introduction problems; TLS is negotiated from a clear-text beginning

  27. Client Initiation Two different rule sets • Client 2 Server, the jabber:client namespace • Server 2 Server, the jabber:server namespace One version to cover more than a decade of rule changes • Also can get “no version” • Version=“0.9” This begins the “client to server” XML document <?xml version="1.0"?> <stream:streamxmlns="jabber:server" xmlns:stream="http://etherx.jabber.org/streams" from="google.com" to="yahoo.com" version="1.0">

  28. Server Response The server starts the same way, agreeing to namespace and reversing the to and from The server also sends the <stream:features>, the capabilities of the server “at this stage” The client selects based on capabilities, like TLS cipher suites And like TLS cipher suites… you can downgrade <stream:features> <starttlsxmlns="urn:ietf:params:xml:ns:xmpp-tls"/> <compression xmlns="http://jabber.org/features/compress"> <method>zlib</method> </compression> <bidixmlns="urn:xmpp:features:bidi"/> <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"> <mechanism>EXTERNAL</mechanism> <mechanism>DIGEST-MD5</mechanism> <mechanism>PLAIN</mechanism> </mechanisms> <dialbackxmlns="urn:xmpp:features:dialback"> <errors/> </dialback> </stream:features>

  29. What Should Happen Each time an important feature is negotiated, the client must re-start the stream (over the same transport) So order for jabber:server should be: • <starttls/> with a <required/> and nothing else (establish stream security) • Client negotiates TLS and sends a new <stream:stream> • <mechanisms/> with a <required/> and nothing else (establish client authentication) • Client negotiates SASL authentication and sends a new <stream:stream> • Other features as appropriate But if you offer it the client can choose, and the previous slide said you can proceed without TLS, without authentication, and without even the weak DialBack mechanism

  30. The XMPP Stream (S2S)

  31. Taking Advantage of Complexity http://www.ldelgado.es/index.php?dir=aplicaciones/xmpploit Not surprisingly people get it wrong A requirement for encryption and no plain-text passwords is subverted even when the server requires TLS to communicate

  32. A Little More Clearly <stream:stream from="gmail.com" id="79E36D297FCCA359" version="1.0" … xmlns="jabber:client"> <stream:features> <starttlsxmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls> <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-tls"> <mechanism>X-GOOGLE-TOKEN</mechanism> <mechanism>X-OAUTH2</mechanism> </mechanisms> </stream:features> But even after stating that TLS and a non-password authentication mechanism are required, gmail.com will still accept a plaintext stream authenticated with a plaintext password.

  33. Why Cheat When You Are Invited? The front door is open _xmpp-server._tcp.{the domain you’re interested in} points the way to jabber:server handler for the domain The bar to entry is hopefully a TLS implementation, a DNS entry, and a certificate that matches your domain name… but Important Bank may not want to talk to you They will almost certainly talk to gmail.com, live.com, yahoo.com, or another PIC (public internet cloud) provider So what can we discover without directly messaging a user?

  34. Asking the Right Questions

  35. Narrowing the Field

  36. XEP-114: Jabber Components If we can get a component connection we have a trusted place on the XMPP network Perhaps we could brute-force passwords and gain external component status Practically, this isn’t rolled out in a way that gives us a large enough target space

  37. XEP-115: Entity Capabilities Offers new nodes to Service Discovery Advertised through <c/> elements in <presence> stanzas Presence requires a direct message to a user and will likely pop up an Accept/Deny dialog

  38. XEP-163: Personal Eventing Protocol The most interesting thing you can get here is GPS location changes if the client broadcasts this data Broadcast comes through <presence> stanzas Presence requires a direct message to a user and will likely pop up an Accept/Deny dialog

  39. XEP-85: Chat State Notifications Knowing that the user is typing isn’t what we’re going for

  40. So What IS Interesting? Service Discovery: walking the discovery chain tells us what the server implements, what components are connected, and anything else that the server decides to advertise Multi-User Chat: the meta-data available about a company through channel names, descriptions, configurations, and user lists can be staggering if the company is indiscrete Vcard-temp: it’s more useful than you think

  41. Service Discovery: Disco#Info Tell me everything I want to know about you <iq from='example.com' to=‘bob@example.com/Psi+' type='result' id='c783849d'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='server' type='im' name='Isode M-Link 15.1v3'/> <identity category='pubsub' type='pep'/> <identity category='directory' type='user'/> <feature var='http://jabber.org/protocol/disco#info'/> <feature var='http://jabber.org/protocol/disco#items'/> <feature var='urn:xmpp:ping'/> <feature var='vcard-temp'/> <feature var='http://jabber.org/protocol/commands'/> <feature var='http://jabber.org/protocol/compress'/> <feature var='jabber:iq:auth'/> <feature var='jabber:iq:private'/> <feature var='jabber:iq:version'/> <feature var='urn:xmpp:blocking'/> <feature var='jabber:iq:search'/> </query> </iq>

  42. Service Discovery: Disco#Items Tell me what other names you think I might be interested in <iq from='example.com' to=''bob@example.com/Psi+' type='result' id='64b47a0b'> <query xmlns='http://jabber.org/protocol/disco#items'> <item jid='chat.example.com' name='chat.example.com'/> <item jid='bob@example.com'/> </query> </iq> <iq from='chat.example.com' to=‘bob@example.com/Psi+' type='result' id='8d2d3db4'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='conference' name='chat.example.com' type='text'/> <feature var='http://jabber.org/protocol/muc'/> <feature var='http://jabber.org/protocol/muc#unique'/> </query> </iq>

  43. Disco#Items on a MUC Component Once you know you have a conference server, you can ask for channel names <iq from='chat.example.com' to='bob@example.com/Psi+' type='result' id='881a2076'> <query xmlns='http://jabber.org/protocol/disco#items'> <item jid='water_cooler@chat.example.com' name='I am a room title.'/> <item jid='closed@chat.example.com' name='Closed, Go Away'/> <item jid='open@chat.example.com' name='Open Discussion'/> </query> </iq>

  44. Meta-Data: Disco#Info on a Channel And the channel name allows you to ask for channel configuration and channel user lists <iq from='closed@chat.example.com' to='bob@example.com/Psi+' type='result' id='e8e0611c'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='conference' name='Closed Channel'type='text'/> <feature var='http://jabber.org/protocol/muc'/> <feature var='http://jabber.org/protocol/muc#unique'/> <feature var='muc_membersonly'/> <feature var='muc_public'/> <feature var='muc_passwordprotected'/> <feature var='muc_persistent'/> <feature var='muc_nonanonymous'/> <x xmlns='jabber:x:data' type='result'> <field var='FORM_TYPE' type='hidden'><value>http://jabber.org/protocol/muc#roominfo</value></field> <field label='Description' var='muc#roominfo_description' type='text-single'> <value>This is a listed, moderated, member-only, password-protected, persistent room.</value> </field> <field label='Subject Modifiable' var='muc#roominfo_subjectmod' type='boolean'><value>1</value></field> <field label='Current Occupants' var='muc#roominfo_occupants' type='text-single'><value>0</value></field> </x> </query> </iq>

  45. User List: Disco#Items on a Channel If you ask a channel for items, it gives you back the list of users The names are not “usernames”, they’re channel nicknames A user can have a different nickname per channel but clients define a more structured experience <iq from='open@chat.example.com' to='bob@example.com/Psi+' type='result' id='9f2584ae'> <query xmlns='http://jabber.org/protocol/disco#items'> <item jid='open@chat.example.com/Swift Boddington'/> <item jid='open@chat.example.com/dick'/> </query> </iq> Swift Boddingtonis the swift.im client which uses the full name by default. Dick is from Psi+ which defaults to the username.

  46. Group Chat is About Community Metadata needs to be available. It helps create a useable community, and external partners are part of that community Humans love meaningful names; they help drive choice and decision • bigbank_libor_research@example.com • “Using Bermudan SWAPTIONs to limit BIGBANK exposure” • Does example.com do business with BIGBANK and consider them a risk? Other data can be just as revealing • Is a room public or private? • Is the room invite-only, members-only, password protected? • Who spends time in the room? New employees or the heads of major divisions? And configuration can guide your actions • Does the channel accept XHTML input and messages from non-members? • Will the channel reveal full user JIDs to channel participants and is it an open channel? • Can you request vCard information for channel participants?

  47. Group Chat Visually

  48. But Getting to Users is Hard XEP-191: Simple Communications Blocking • You shouldn’t be able to enumerate users based on response differentiation • Or tell that someone is blocking you • Messages, Presence Probes, and IQs should all receive the same error: service-unavailable To find out about a user you need to know their full JID… the JID for a connected resource

  49. What is a JID?

  50. Disco#Info on a User We can use MUC nicknames to guess at valid usernames, but to enumerate an existing account we also require a resource ID.

More Related