Heute NUR verschlüsselte Server-zu-Server Verbindungen möglich!

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.