And yet:
I can never resist to someone saying this :-)
I do see live attack traffic on my server on port 3478. I am certain
it is attack traffic based on the behaviour and specifics, but I won’t go into
details on a public mailing list (feel free to contact me off-list though).
I also know
Am 28.04.21 um 17:37 schrieb Jonas Schäfer:
Hi fellow operators,
TL;DR: STUN/TURN servers are vulnerable to abuse to facilitate reflected
amplified DDoS attacks even with authentication enabled. Roll a few dice and
choose a random port number for your STUN server for the better of the
internet.
ops, that has been rotting in my draft folder for a bit.
Am 14.01.2016 um 15:04 schrieb Andrey Utkin:
On 14.01.2016 15:29, Philipp Hancke wrote:
As I see "ICE candidates" are successfully found on both endpoints (I
look at chrome://webrtc-internals), the media sources are set up, but
As I see "ICE candidates" are successfully found on both endpoints (I
look at chrome://webrtc-internals), the media sources are set up, but
then some magic doesn't happen. It seems irrelevant whether I request
video calls, or audio-only calls.
chrome://webrtc-internals only shows a single peerco
Am 19.08.2014 17:23, schrieb Hiers, David:
Hi,
Are XMPP federation transitive? In other words, if A federates with B, and B
federates with C, can A send traffic to C through B?
Relaying is not supported. This isn't Internet Relay chat :-)
I can't find anything in the RFCs, XEPs, or vendor d
A cynical person could also make a counter-strike: display some warning
popup in the regular XMPP clients each time somebody tries to start a
new chat with a user @gmail.com and doesn't receive a response in 2
minutes. "Warning: the person you have tried to contact uses gmail.com.
It is possibl
Am 19.05.2014 10:35, schrieb Andreas Tauscher:
Hello!
Maybe somebody can enlighten me.
RFC 3920 says in section 5.1.8:
3920 is obsolete. Refer to 6120 and 6125.
[ SNIP ]
As I read this if I have a domain foo.bar an the SRV record points to
im.example.com c2s and s2s has to verify t
Am 15.04.2014 22:35, schrieb Peter Viskup:
Philipp Hancke:
Since most xmpp servers will request peer certificates, the heartbleed
(http://heartbleed.com/) test script from
http://s3.jspenguin.org/ssltest.py
does not work out of the box.
I modified it slightly so it can now detect the handshake
Since most xmpp servers will request peer certificates, the heartbleed
(http://heartbleed.com/) test script from
http://s3.jspenguin.org/ssltest.py
does not work out of the box.
I modified it slightly so it can now detect the handshake done message
when it's after the cert request:
http://hanc
Am 03.02.2014 20:52, schrieb Alexander Holler:
Am 03.02.2014 19:56, schrieb Daniel Pocock:
The Debian stuff is still in the works, had a great discussion with
Matthew and some other free software projects at FOSDEM.
Do you've created a task force which comes to action whenever someone
has the
Am 28.11.2013 10:16, schrieb Andreas Kuckartz:
If it turns out that not even the rather limited requirements regarding
encryption which are stated in the manifesto will be satisfied by a
significant subset of XMPP servers then it well seal the fate of XMPP as
far as I am concerned.
And if the fu
Same here, we can't cut off paying customers.
How many of them are complaining that their counterparts are not
responding anymore (because they use hangouts which don't display or get
messages from federated contacts)?
Technically, as a server developer, it would be possible to continue
to allow Google domains as an exception (this isn't possible with a
simple white/blacklist because of Google Apps hosted domains). Would
this be a positive or negative step to take?
Nack. The whitelist would be on the target of
4) Use an untrusted or invalid certificate.
We can debate about 4) for a long time
We can debate about "untrusted", but we don't need to do that for "invalid".
Am 29.10.2013 18:40, schrieb Jesse Thompson:
On 10/28/2013 2:52 PM, Peter Saint-Andre wrote:
On 10/28/13 1:41 PM, Jesse Thompson wrote:
Are there more details? Specifically, does "hop-by-hop encryption
using SSL/TLS" require strong association between a domain name and
an XML stream as describ
I added two gmail users last week. I suppose it depends on hangouts
status, as suggested by other reports. Maybe you can collect data on
that? Do you have a way to ask them whether they've enabled hangouts or not?
I'm currently recommending people to use gmail chat in gmail and use
hangouts on
Am 11.09.2013 05:56, schrieb Peter Saint-Andre:
[2] openssl s_client -connect jappix.com:5222 -starttls xmpp -CAfile
gandi.crt
try -CApath /etc/ssl/certs instead
On Fri, 24 May 2013, Dave Cridland wrote:
[...]
I think email was different for three reasons:
1) Email came about mostly before the Internet took off - indeed, there's an
argument that the Internet expansion was driven by email, not the other way
around. This placed restrictions on how email
Am 23.05.2013 17:38, schrieb Olle E. Johansson:
Now, with old SSL/TLS the server requiring a client cert had to say
"I only accept client certs from these CA's". With TLS 1.x something
this was removed, which opens up a lot of new possibilities for
self-signed certs verified by other means, like
Am 22.05.2013 20:30, schrieb Peter Saint-Andre:
So the protocol isn't as rich as they want... guess they haven't
understood the "x" part in xmpp.
Well, I see no reason for us to act the jilted lover. :-)
We had an on-and-off affair (2005-2013) but XMPP predated Google Talk and now we
start the
Am 22.05.2013 18:40, schrieb Peter Saint-Andre:
I think it was a bit over-the-top for Chee Chew to claim that the
"majority" of the server-to-server connectivity to the Google Talk
service was established by "organizations or individuals looking to
bombard Google Talk users with chat spam".
htt
On Wed, 22 May 2013, Peter Saint-Andre wrote:
On the other hand, not needing to interoperate with Google Talk might
free us to more aggressively work on network security improvements. I
say let's take this as an opportunity rather than a disappointment.
+1. I wonder what the correlation between
On Thu, 21 Mar 2013, Peter Viskup wrote:
Dear all,
let me share the list of XMPP servers which use 'not secure' SSL certs on
5223 port:
openssl has starttls for xmpp so you could try that on port 5222.
It apparently supports s2s now, too. Or there is a patch that makes it
capable of doing s2s
I mean it'd be nice for mobile or desktop clients
to be able to point new users to a list of possible servers to register an
account on.
From infrequent mod_stats (ejabberds implementation of xep-0039) queries
to several servers on the list this doesn't seem to happen often.
Am 11.01.2013 14:14, schrieb Dave Cridland:
[...]
In Google's case, they have stated very clearly, and very often, that
mh... any pointers? ISTR something related to gmail and pop3s...
TLS authentication is essentially somewhere between very difficult and
impossible for them to deploy, and (q
On Fri, 11 Jan 2013, Mathias Ertl wrote:
I consider this a bug on your side, TLS is a required feature for
s2s-connections. Please fix the issue, as you are currently blocking
It is required to implement, not to deploy.
[...]
We already had some 'excessive' discussion about it with Peter
Saint-Andre this year and didn't 'solve' it. The only outcome of it was
that the Jabber.sk service is still not listed in the list of public
services and the only reason is that it's using certificate signed by
our internal CA.
Am 04.09.2012 18:56, schrieb Dave Cridland:
My understanding is that they're both difficult problems to tackle without
a lot of data processing and analysis, but that a key issue is that freely
The problems get two orders of magnitude harder if you can not trust
your local users.
available
Josemar Müller Lohn wrote:
But, anyway, if you ask for a SRV record to your DNS, it will only search
for a SRV entry in the internal table and answers it.
Dave and I have been testing this moments ago... amazingly, it works out
of the box with bind on the serverside, code based on Arnt Gulbran
Tomasz Sterna wrote:
Dnia 2010-01-20, śro o godzinie 22:13 +, Dave Cridland pisze:
FYI, during our testing in the run up to jabber.org this time, I
happened to notice what an impact DNS is to S2S setups, and that
running a local caching resolver is a huge help to an XMPP service.
Assumi
Dave Cridland wrote:
On Sat Nov 21 12:07:33 2009, Philipp Hancke wrote:
Peter Saint-Andre wrote:
As I always say, we don't need to be perfect, just more difficult to
attack than other networks. Part of raising the cost (mostly the cost in
time) would involve requiring TLS with CA-i
Peter Saint-Andre wrote:
As I always say, we don't need to be perfect, just more difficult to
attack than other networks. Part of raising the cost (mostly the cost in
time) would involve requiring TLS with CA-issued certificates for s2s
(perhaps we can get there eventually!). But as you say there
Maissel, Joe wrote:
Since deploying XMPP federation with gmail.com back in November, we
experience intermittent service problems. As far as we know, and
according to Google, the problem is experienced only by our domains -
credit-suisse.com and credit-suisse.tv. Other domains running the same
s
ReK2 GNU/Linux schrieb:
I only apply the ticket 256 patch
http://jabberd2.xiaoka.com/attachment/ticket/256/jabberd-256.patch
that did the trick for me, looks like google have changed something this
last weekend to only allow TLSv3? is odd because this been working before
with out the patch.. oh
34 matches
Mail list logo
