Hi Thijs, Excellent work! Many kudos for all the effort that you're (et al) putting in! Two suggestions:
1. I like the way how tool-tips are used to explain why a particular item is good/bad, but those hints are not available everywhere. Could you add more of them please? 2. There is no visual hint that offering a PLAIN authentication mechanism is a bad thing, pre-TLS (other than that it's stated in the tooltip of the word PLAIN). Perhaps some kind of color or badge or grade-cap could be applied. Regards, Guus On 22 October 2015 at 11:23, Thomas Camaran <[email protected]> wrote: > hi, how i can add a cache copy of xmpp.net on my server? > > 2015-10-22 11:09 GMT+02:00 Thijs Alkemade <[email protected]>: > >> Hello all, >> >> As discussed previouson this list, xmpp.net was down for a while due to >> hardware failure. It is now back up on a different server. Most of it is >> working again, but some tables on the stats page are still broken. >> >> While doing that, I also made some updates to the test, inspired by the >> updates to ssllabs.com: >> >> * Grades will be capped to B if SSLv3 is supported. The grade will be F if >> SSLv3 is the highest protocol version supported. >> >> * Grades will be capped to C if RC4 is used with TLS 1.1 or TLS 1.2. >> >> * The size of the DH parameters now impacts the key exchange score. >> >> * Grades will be capped to B when using DH parameters of less than 2048 >> bits. >> >> * Grades will be capped to C if TLS compression is enabled. >> >> * Grades will be capped to C when TLS 1.2 is not supported. >> >> >> Additionally, the DHE group and the ECDHE curve that were used are now >> stored, >> to see how much the Logjam attack [1] impacts XMPP servers. >> >> With just a couple of days of data, here's some statistics on the >> standard DH >> groups used: >> >> count | group_name >> -------+---------------------------------------------------------------- >> 1 | RFC 3526 3072-bit MODP Group >> 1 | RFC 3526 4069-bit MODP Group >> 1 | draft-ietf-tls-negotiated-ff-dhe-10 ffdhe2048 >> 1 | RFC 2409 Second Oakley Group >> 1 | RFC 3526 8192-bit MODP Group >> 12 | RFC 3526 2048-bit MODP Group >> 14 | Java sun.security.provider default 512-bit prime >> 22 | Java sun.security.provider default 1024-bit prime >> 60 | Java sun.security.provider default 768-bit prime >> 131 | >> 157 | RFC 5114 1024-bit MODP Group with 160-bit Prime Order Subgroup >> >> This means only 131 of these 410 servers are using custom DH parameters. >> 60 >> servers are using a common 768-bit DH group and 14 servers using a common >> 512-bit prime (which are likely using DHE-EXPORT, so vulnerable to >> logjam). >> >> [1] estimates that breaking a 768-bit prime is within reach for an >> academic >> team. The version replies from the servers using the 768-bit prime >> indicates >> they are running Openfire 3.7 - 3.10 or Tigase 5.2.1. All other Openfire >> servers are using the Java sun.security.provider default 1024-bit prime >> (probably the difference between Java 7 and Java 8). >> >> [1] further estimates that breaking a few commonly used 1024-bit groups >> would >> be in range for a nation-state attacker and the RFC 5114 1024-bit MODP >> Group >> is used a lot. Version replies show these servers are running ejabberd >> 2.1 - >> 15.09. >> >> It appears ejabberd 15.06 added an option to set your own dh parameters >> [2], I >> strongly recommended to upgrade and generate your own parameters. If you >> are >> running Openfire (or are using ejabberd and unable to update), you might >> want >> to disable DHE completely and rely on ECDHE instead. >> >> [1] = https://weakdh.org/ >> [2] = https://www.ejabberd.im/node/24959 >> >> Best regards, >> Thijs >> >> >> >
