Closed GoogleCodeExporter closed 8 years ago
Original comment by vanaryon
on 3 Jun 2011 at 8:57
Also, in addition to the IP detection to know if we are local or not, adding a
configuration option would be great, to define the hosts to connect unencrypted
(useful for clustering on a trusted local network).
Original comment by vanaryon
on 3 Jun 2011 at 8:59
I was wondering if it would be better to have the client send an option which
says that TLS is not required, because currently if the server advertizes TLS,
NXB automatically tries to negotiate it.
Original comment by dhruvb...@gmail.com
on 4 Jun 2011 at 9:42
Or maybe it makes sense to do a STARTTLS only if it is REQUIRED by the server
and not otherwise. What do you think? I like the idea of having TLS on by
default, but in the case of local XMPP server, it is an unnecessary overhead.
If the XMPP server says that it is not <required/>, then NXB can be made to
skip TLS negotiation.
Original comment by dhruvb...@gmail.com
on 4 Jun 2011 at 9:51
Using secure=true|false (see the BOSH XEP).
But the client does not always know it is connecting to a local server. It is
just to make it more lightweight, you know.
I have seen JHB doing this thing: when the IP is 127.0.0.1, they disable TLS in
every case. The proof here:
http://svn.jwchat.org/jhb/trunk/src/org/jabber/JabberHTTPBind/Session.java
(search for the "localhost" term in the file). ;)
Original comment by vanaryon
on 4 Jun 2011 at 9:52
Yes, it seems to be a good thing.
So NXB disables TLS if we are local AND the server does not require it?
Original comment by vanaryon
on 4 Jun 2011 at 9:54
How would you know that the server is local? (Just trying to think it
through)... I mean unless "route" is specified, this would be complicated. It
would involve getting all local interfaces and checking, etc... besides, in a
larger deployment, it is not necessary that the XMPP & BOSH server will be on
the same machine - in our current deployment, we have a cluster on BOSH servers
running on different machines connecting to XMPP servers on a separate machines.
I guess just disabling TLS if not <required/> should do the trick. What do you
say?
Original comment by dhruvb...@gmail.com
on 4 Jun 2011 at 10:16
I think in your case ejabberd would NOT be sending the <required/> tag, so it
should work out for you. Please could you check and let me know?
Original comment by dhruvb...@gmail.com
on 4 Jun 2011 at 10:20
I don't think disabling TLS in case of not <required /> is not a good solution,
it's a security leak.
I think the best solution is to have a list of hosts to connect to without any
encryption in the option, without any <required /> check. When the connect host
match with one host in the array, NXB will not initiate a TLS session.
That's the easiest way, I think!
Original comment by vanaryon
on 4 Jun 2011 at 10:46
Actually, it is a security leak for those connecting their not-local account
using NXB, if their server does not require TLS, like jabber.fr through
jappix.com's NXB.
Original comment by vanaryon
on 4 Jun 2011 at 10:53
Yes, even facebook (iirc) doesn't require TLS and it would be bad to not enable
TLS for such networks.
So, the rule would be what you mentioned earlier. If the "to" attribute in the
<body/> element is present in the list of domains to NOT enforce TLS with AND
TLS is NOT required by the XMPP server for the "to" domain, then do NOT
STARTTLS. Sounds good?
Original comment by dhruvb...@gmail.com
on 4 Jun 2011 at 11:11
The reason I want to use the <required/> tag is because if some day you change
the config. on ejabberd and forget to remove the exception in the config. file,
all new connections will fail. With the <required/> check, incorrect config.
won't result in anything disastrous.
Original comment by dhruvb...@gmail.com
on 4 Jun 2011 at 11:16
Yep, it's the best solution I think ;)
Original comment by vanaryon
on 4 Jun 2011 at 1:59
Commit #258 should fix this
Original comment by dhruvb...@gmail.com
on 5 Jun 2011 at 9:20
It works perfectly, thanks a lot :)
Original comment by vanaryon
on 5 Jun 2011 at 10:12
General way to reduce OpenSSL memory usage anywhere:
http://journal.paul.querna.org/articles/2011/04/05/openssl-memory-use/
Original comment by dhruvb...@gmail.com
on 5 Jun 2011 at 1:45
Original issue reported on code.google.com by
vanaryon
on 3 Jun 2011 at 8:57