Heute ist Testbetrieb für rein verschlüsselte Server Verbindungen – ab morgen lassen wir wieder Verbindungen ohne SSL/TLS zu!
Bitte testet eure Server/Betreiber unter xmpp.net, ob diese euch ausreichend Sicherheit bieten!

Nachfolgend das Statement der XMPP Network Admins/ML:

A Public Statement Regarding Ubiquitous Encryption on the XMPP Network

Date: 2013-12-16

Version: 0.5

We, as operators of public services and developers of software

programs that use the XMPP standard for instant messaging and

real-time communication, commit to establishing ubiquitous encryption

over our network on May 19, 2014.

Jabber/XMPP technologies were first released on January 4, 1999, by

Jeremie Miller. Since then, channel encryption using Secure Sockets

Layer (SSL) and Transport Layer Security (TLS) has been optional on

the Jabber/XMPP network. Out of respect for the users of our software

and services, we believe it is time to make such encryption mandatory.

Therefore we commit to the following policies, consistent with the

IETF Internet-Draft “Use of Transport Layer Security in XMPP”

<https://datatracker.ietf.org/doc/draft-saintandre-xmpp-tls/>.

For software implementations:

o support the STARTTLS method in XMPP as specified in RFC 6120,

  including mandatory-to-implement cipher suites and certificate

  validation consistent with RFC 6125

o prefer the latest version of TLS (TLS 1.2), but provide a

  configuration option to negotiate TLS 1.1, TLS 1.0, or SSLv3

  for backward compatibility with existing deployed software

o disable support for SSLv2

o provide configuration options to require channel encryption for

  client-to-server and server-to-server connections

o provide configuration options to prefer or require cipher

  suites that enable forward secrecy

o prefer authenticated encryption (via digital certificates) for

  server-to-server connections; if authenticated encryption is not

  available, provide a configuration option to allow fallback to

  unauthenticated encryption with identity verification using the

  XMPP Server Dialback extension (XEP-0220)

o ideally, provide user or administrative interfaces showing:

  o if a given client-to-server or server-to-server connection

    is encrypted, authenticated, or both

  o the version of TLS and the cipher suite in use

  o details about a server’s certificate

  o a warning about any changes to a server’s certificate

For service deployments:

o require the use of TLS for both client-to-server and

  server-to-server connections, preferably with authentication

  (RFC 6125) but as a fallback using unauthenticated encryption

  in the form of TLS plus Server Dialback

o prefer or require TLS cipher suites that enable forward secrecy

o if possible, deploy certificates issued by well-known and

  widely-deployed certification authorities (it is known that

  multi-tenanted hosting services are unable to obtain or

  manage certificates for hosted domains)

The schedule we agree to is:

January 4, 2014 – first test day requiring encryption

February 22, 2014 – second test day

March 22, 2014 – third test day

April 19, 2014 – fourth test day

May 19, 2014 – permanent upgrade to encrypted network, coinciding

with Open Discussion Day <http://opendiscussionday.org/>

This commitment to encrypted connections is only the first step

toward more secure communication using XMPP, and does not obviate

the need for technologies supporting end-to-end encryption (such as

Off-the-Record Messaging or OTR), strong authentication, channel

binding, secure DNS, server identity checking, and secure service

delegation. Although we have worked to implement and deploy such

technologies and will continue to do so, we believe that encrypting

the traffic on the XMPP network is a necessary precondition to

offering further security improvements.