Extensible Messaging and Presence Protocol

from Wikipedia, the free encyclopedia
Extensible Messaging and Presence Protocol
Official logo
Official logo
Family: Internet protocol family
Operation area: Instant messaging
Ports: 5222 / TCP (client-to-server)
5269 / TCP (server-to-server)
Legacy SSL:
5223 / TCP ( SSL )
XMPP in the TCP / IP protocol stack :
application XMPP
transport TCP
Internet IP ( IPv4 , IPv6 )
Network access Ethernet Token
bus
Token
ring
FDDI ...
Standard since: 2004
Standards:

RFC 6120 (Core)
RFC 6121 (IM & Presence)
RFC 6122 (Address Format)
RFC 3922 (CPIM)
RFC 3923 (Encryption)

A simple XMPP network with the servers jabber.org and draugr.de . Green clients are online, yellow clients are currently messaging each other, and small green subclients are a user's individual resources. The brown network is not connected to the internet. The draugr.de server is connected to other IM services (ICQ, AIM, etc.) via XMPP transports.

The Extensible Messaging and Presence Protocol ( XMPP , English for expandable message and presence protocol ; formerly Jabber , English [ ˈdʒæbə (ɹ) ] "(therefore-) babble") is an open standard of a communication protocol, which is used by the Internet Engineering Task Force (IETF) published as RFC 6120, 6121 and 6122. XMPP is based on the XML standard and enables data to be exchanged. Among other things, it is used for instant messaging . Extensions to XMPP are the XMPP Extension Protocols published by the XMPP Standards Foundation (XSF) .

properties

XMPP and its extensions support functions for message transfer, multi-user chat , i.e. conferences with several users, displaying the online status, file transfers, sending digital certificates and many other services. The network architecture is reminiscent of the Simple Mail Transfer Protocol (SMTP). Every XMPP server connected to the Internet can exchange messages with other servers. Connections across provider boundaries are possible. Messages are forwarded from the user to their own server, from there to the external server and then to the recipient. Isolated networks, for example in company intranets, are also possible.

At least one XMPP server (similar to the Mail Transfer Agent ) is required to operate an XMPP network . This can exist as the sole communication interface in an intranet or it can establish connections to other XMPP servers (the “XMPP Federation”) via the Internet.

The so-called " Jabber Identifier " (JID) is used to identify and address users within the XMPP network . This has the form “ alice@example.com”, is similar to an e-mail address and also behaves similarly: This is alicethe user name and example.comthe server with which the user is registered. The concept of " resources " makes it possible to log on to an XMPP server multiple times with one identity.

A great advantage of XMPP is that there are XMPP clients for almost every operating system and in every programming language. However, the solutions differ in the extent to which they support the protocol.

In contrast to other instant messaging protocols used on the Internet, the XMPP protocol is openly documented and is actively being further developed.

Functions

Peer-to-Peer Sessions

With the extension called jingle , XMPP can arrange peer-to-peer sessions. This function is mainly used for IP telephony (VoIP) and is very similar to Session Initiation Protocol (SIP).

After Google had expanded the XMPP protocol to include VoIP functions on August 8, 2005 with the publication of Google Talk , the XMPP Standards Foundation published the specification of the "Jingle Signaling" extension on December 15, 2005, adding P2P to XMPP. Capabilities expanded, as well as the specification of a first application, "Jingle Audio" for VoIP. On the same day, Google released the source code of the program library libjingle , which implements this functionality. Some other XMPP clients then also implemented “Jingle Audio” (e.g. also by using libjingle) so that VoIP functions with XMPP are not only reserved for Google Talk and Windows systems.

In the meantime, there are other applications that use “jingle signaling” - which, for example, negotiates communication through Network Address Translations (NAT) - as a basis. So far, among other things, jingle profiles for video (based on Theora ), User Datagram Protocol (UDP) (usable for agreeing multi-player network games) and the InterAsterisk eXchange have been specified. Multi-frequency dialing (DTMF) has also been implemented for the purpose of backward compatibility with the conventional telephone network .

We are currently working on profiles for data exchange and virtual private networks .

Multi-user chat

XMPP supports conferences with multiple users. Today the specification Multi-User Chat (MUC) is the most common. It supports functions such as role assignment for users within the chat, password-protected or invisible rooms and is backwards compatible with the previous specification group chat . Conference rooms are also represented by Jabber Identifiers . From the point of view of the normal user, multi-user chat is comparable to Internet relay chat (IRC chat) and normally he will not notice the difference.

Communication with other chat networks

Alice sends her message to the XMPP server she is logged on to. This sends the message to the XMPP transport. The XMPP transport forwards them to Bob via the ICQ server.

A special concept of XMPP is that of transport . This means that other networks ( called Legacy Services in XMPP jargon ) such as AOL Instant Messenger (AIM), ICQ , Yahoo Messenger , Gadu-Gadu or Internet Relay Chat (IRC) can be used and interacted with their users. This is also possible for Windows Live Messenger (WLM), but many administrators switch off this transport for legal reasons. The servers transport the messages between the networks without the two users involved having to take special precautions.

A separate account in the respective network is required to communicate with users of a network that is not XMPP compatible. Every user of XMPP can register with transports by submitting their existing login information to this service. These clients must Service Discovery (too German "service discovery" ) support. This makes it possible to search servers for offered transports and to communicate with users of proprietary instant messaging networks without installing additional plugins .

history

Jabber logo

Jeremie Miller began developing a real-time XML streaming protocol in 1998 , which he published in 1999 under the name Jabber. In 2004, the IETF adopted the protocol, with a few changes, as the official standard called the Extensible Messaging and Presence Protocol . Since then, the XMPP Standards Foundation (XSF) has been responsible for the standardization of the protocols based on XMPP, the so-called XMPP Extension Protocols . Peter Saint-Andre is the director and author of most of the XEPs .

distribution

Google was the only provider that the XMPP protocol for e-mail addresses from Gmail offering. This Google Talk service was discontinued in May 2013 for third-party software and is only available for the Google client. In Germany, United Internet's XMPP was used in the GMX / Web.de Multimessenger , which also allowed the integration of other services such as ICQ, Windows Live Messenger and Yahoo Messenger. However, on December 1, 2014, this service was also discontinued. At that time, Google and GMX customers were only able to communicate directly with one another by specifying their e-mail address - without using "transports". The Facebook chat also used the XMPP protocol. In the past, you could therefore talk to Facebook friends using many free chat programs. However, Facebook modified the protocol in May 2015 in such a way that third-party software no longer works properly and the "federation feature", i.e. communication with other XMPP servers, was not supported from the start.

Other well-known clients are Trillian from Cerulean Studios , LJ Chat from LiveJournal , Ovi from Nokia (which also offers a Jabber client for its mobile devices), and Miranda NG .

There are several thousand XMPP servers worldwide. Some private individuals, but also associations such as the Chaos Computer Club , operate their own servers without commercial intent. The Pirate Party also operated a server that has since been discontinued. The XMPP Standards Foundation offers a list of public servers in which operators can register. In addition, there is a bot with the xmpp-server-scanner that automatically queries the server and generates a list with information on availability and supported functions.

In 2009, Cisco Jabber Inc. bought. An integration into own software solutions is planned.

Encryption

The connection between two XMPP clients is always established via at least one XMPP server. If both clients are logged on to two different servers, a connection must also be established between the two servers (client A ↔ server A ↔ server B ↔ client B). Since messages can be intercepted or recorded on this transmission path at every station (and also in between) , it is advisable to encrypt them.

The connection between a client and the server on which this client is logged on can be encrypted using Transport Layer Security (SSL / TLS) ( client-to-server encryption ). SSL connections to the XMPP server were usually offered on port 5223, but now, according to RFC 6120 , TLS connections also use the standard port 5222 via STARTTLS. Some servers also explicitly offer port 5224 for TLS. Client-to-client encryption is certainly the preferred variant for the operator of an XMPP server, since it uses fewer resources on the servers, but it can then no longer understand what content is being transmitted (i.e. it cannot read text messages ), which in turn is beneficial for the client.

Even if the connections of the clients to their respective servers are encrypted, the communication between the servers is a possible point of attack. Many servers therefore encrypt their connections to other servers ( server-to-server encryption). A combination with client-to-server encryption makes sense, as otherwise the connection at the weakest point - i.e. H. where the connection is not encrypted - is vulnerable. If both methods are used, the security is considerably improved, but the servers are still a point of attack, since the data is decrypted on both servers even with a combination of server-to-server and client-to-server encryption. In March 2014, many operators of the large public XMPP servers signed a manifest in which they undertook to offer server-to-server encryption and to switch off insecure protocols such as SSLv2.

End-to-end encryption therefore offers an even higher level of security . By encrypting all data from the source client and then decrypting it again by the respective target client, points of attack are minimized. The connection is necessarily encrypted at all times and the servers cannot decrypt the data they are forwarding. The operator of the server and potential attackers can only draw conclusions about the time, the duration and the approximate scope of a conversation.

One method for end-to-end encryption is OpenPGP . It is based on the principle of asymmetric encryption . The keys remain unchanged over a longer period of time. Each key pair can be clearly assigned to a "key holder". Therefore, with this form of encryption, not only can the "confidentiality" of a data transmission be achieved, but also a "liability ??" in the sense of information security : participants can later use recordings to prove which statements were made by which people in the conversation .

Off-the-Record Messaging (OTR) offers the possibility of making transmissions secure against eavesdropping (“confidential”), but at the same time enabling credible deniability (“non-binding”): After communication has taken place, the content is disputable because the integrity of the messages transmitted is deliberately destroyed in that the temporarily used signature keys are transmitted in plain text after they have been used. This means that no interlocutor can later prove that certain content was actually transmitted, as he could have signed the content himself afterwards. By Perfect Forward Secrecy (PFS) it is also achieved that can not be decrypted in case of loss of private keys previous traffic recordings. This form of encryption is therefore particularly suitable for confidential “ sub-pink ” conversations . The fact that a conversation took place between the participants, however, remains independently verifiable.

OMEMO is an extension of the XMPP protocol that enables end-to-end encryption between users. In addition, OMEMO implements the requirement of Perfect Forward Secrecy and Credible Deniability . All common XMPP servers master this protocol extension, as well as numerous Jabber clients such as B. Gajim , Dino or Conversations .

Since the server-to-server encryption of XMPP cannot be influenced by the end user, because it takes place in the jurisdiction of the server administrators, the greatest possible security for the end user is achieved through the simultaneous use of client-to-server encryption and end-to-end. End encryption achievable.

Extensions such as B. Audio and video chat via Jingle are not encrypted by default.

See also

Norms and standards

XMPP is standardized through several RFCs . There is a main line and associated additions or update RFCs:

First generation:

  • RFC 3920 - Extensible Messaging and Presence Protocol (XMPP): Core , from 2004, replaced by RFC 6120
  • RFC 3921 - Extensible Messaging and Presence Protocol (XMPP): Address Format , supplement from 2004, replaced by RFC 6121
  • RFC 3922 - Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM) 2004 amendment
  • RFC 3923 - End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) , amendment 2004

Second generation:

  • RFC 6120 - Extensible Messaging and Presence Protocol (XMPP): Core , from 2011
    • Update RFC 7590 - Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) , from 2015
    • Update RFC 8553 - DNS AttrLeaf Changes: Fixing Specifications That Use Underscored Node Names , from 2019
  • RFC 6121 - Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence , 2011 addition
  • RFC 6122 - Extensible Messaging and Presence Protocol (XMPP): Address Format , amendment from 2011, replaced by RFC 7622
  • RFC 7622 - Extensible Messaging and Presence Protocol (XMPP): Address Format , from 2015

literature

Web links

Wikibooks: XMPP Compendium  - Learning and Teaching Materials

Individual evidence

  1. ^ First standard RFC 3920, adopted in 2004
  2. Jabber Inc. - About Us ( Memento from April 14, 2010 in the Internet Archive )
  3. Reasons for Jabber
  4. XEP-0166: Jingle
  5. XMPP Standards Foundation Publishes Open VoIP and Multimedia Protocols. ( Memento of the original from May 4, 2007 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. , XMPP Standards Foundation , December 15, 2005  @1@ 2Template: Webachiv / IABot / xmpp.org
  6. XEP-0166: Jingle
  7. XEP-0167: Jingle Audio Media Description Format
  8. Google Talkabout , Sean Egan: Jingle all the way
  9. XEP-0045: Multi-User Chat
  10. XEP-0030: Service Discovery , XMPP Standards Foundation , Version 2.2, January 24, 2006
  11. ^ Ovi Contacts
  12. Archive link ( Memento of the original from September 25, 2015 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / web.jabber.ccc.de
  13. http://wiki.piratenpartei.de/Jabber
  14. Public XMPP Server Directory
  15. Project overview for xmpp-server-scanner at Google Code
  16. Cisco takes over instant messaging provider Jabber
  17. Manifesto on GitHub , accessed November 5, 2014