Avoid DNS lookup during XMPPConnection.connect

Nebojsa_Mihajlovic · October 20, 2012, 10:12am

Hi,

I’m working as developer in sustaining of one application which is basically Instant Message app. Our customer wants to login to XMPP server over VPN. For security reasons, they do not want any entries in Windows hosts file and also DNS over VPN is forbidden (I don’t know exact reason but its a fact). They will connect to XMPP server by using IP address and they are aware of it.

Problem is that during XMPP login process - TLS handshaking is broken. XMPPConnection.connect is executed fine, but XMPPConnection.login fails.

Here are XMPP message sent:

<stream:stream to=“pasternak.pst” xmlns=“jabber:client” xmlns:stream=“http://etherx.jabber.org/streams” version=“1.0”>

my_username

<stream:stream to=“pasternak.pst” xmlns=“jabber:client” xmlns:stream=“http://etherx.jabber.org/streams” version=“1.0”>

</stream:stream>

and received:

<stream:stream xmlns:stream=‘http://etherx.jabber.org/streams’ xmlns=‘jabber:client’ xml:lang=‘en-US.UTF-8’ id=‘48C183909B1’ from=‘pasternak.pst’ version=‘1.0’>

stream:features</stream:features >

<stream:stream xmlns:stream=‘http://etherx.jabber.org/streams’ xmlns=‘jabber:client’ xml:lang=‘en-US.UTF-8’ id=‘48D5D924CBD’ from=‘pasternak.pst’ version=‘1.0’>

stream:features</stream:features >

<stream:stream xmlns:stream=‘http://etherx.jabber.org/streams’ xmlns=‘jabber:client’ xml:lang=‘en-US.UTF-8’ id=‘48D5D924CBD’ from=‘pasternak.pst’ version=‘1.0’>

stream:featuresPLAINUSER_DEFINED_MECHANISM</stream:features>

Here is output:

java.net.SocketException: Connection reset

at java.net.SocketInputStream.read(Unknown Source)

at sun.security.ssl.InputRecord.readFully(Unknown Source)

at sun.security.ssl.InputRecord.read(Unknown Source)

at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)

at sun.security.ssl.SSLSocketImpl.waitForClose(Unknown Source)

at sun.security.ssl.HandshakeOutStream.flush(Unknown Source)

at sun.security.ssl.Handshaker.kickstart(Unknown Source)

at sun.security.ssl.SSLSocketImpl.kickstartHandshake(Unknown Source)

at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source

)

at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at org.jivesoftware.smack.XMPPConnection.proceedTLSReceived(XMPPConnecti

on.java:806)

at org.jivesoftware.smack.PacketReader.parsePackets(PacketReader.java:26

at org.jivesoftware.smack.PacketReader.access$000(PacketReader.java:43)

at org.jivesoftware.smack.PacketReader$1.run(PacketReader.java:70)

connection.login() Exception

No response from the server.:

I have reproduced it on my maching by manuall blocking remote port 53 (DNS).

After few days of investigation I have found following issue SMACK-344.

org.jivesoftware.smack.SASLAuthentication - currentMechanism.authenticate(username,connection.getServiceName(), password);

That’s why I thought that by switching from smack-3.1.0 which is used in our application, to smack-3.2.2 - problem will be solved. But, I’m still experiencing this issue in my test app.

Basically, my question is: is there any way to avoid DNS reverse lookup during XMPPConnection.login()?

Any other hint is also appreciated.

Regards,

Nebojsa

LG1 · October 21, 2012, 7:28am

Is this error caused because the packets are blocked (server/firewall sends a reset pacekt) - Does it work when the packets simply time out (firewall drops the packet silently)?

The server sends its certificate which does likely contain a “common name” (which is not the IP address), so the client tries to verify that the “common name” matches the name/IP address it is using.

Nebojsa_Mihajlovic · October 22, 2012, 8:51pm

Thank you very much for your response LG.

I would not say that server/firewall sends a reset packet (or I missing something in wireshark capture).

In certificate we have common name which is not IP address - and it semm that client tries to verify it with IP address since I can see STANDARD QUERY PTR (reverse DNS lookup) in wireshark capture. Is there any way to verify non-ip-address certifacate with ip-address or to skip reverse DNS lookup somehow?

Gerg_Ay · October 24, 2012, 3:32pm

I could be wrong, but that doesn’t sound like something that’s called for by the protocol – maybe just logical, or… maybe considered good practice in some circles, though I’d find that argument a bit dubious because…

If you put in user@hostname before you hit login, you’re already looking at your hosts file, drawing a blank, and moving on to the network DNS server, who (unless there’s major shenanigans going on of course, but by that time, you’re already screwed if that’s the case), who has provided the program’s underlying network stack with the IP of the XMPP server you’re about to start a dialogue with…
… then consider the fact how many hosts, even where it could maybe be construed as something that actually tangibly counts, say for a mail server in operation on the internet, even a good half of those haven’t bothered to make their reverse PTR name match up with their A name.

2.5) I read the top again and I see now that you said the user is only using the IP instead of a hostname…

…so without much doubt, I’d posture that this is more likely just one of those “feature” style bugs. (Though I’d love to be wrong… anybody?!) I mean … let’s think about it logically, just because the network has a different name for a server than it has for itself, doesn’t mean you should automatically throw away a certificate with a mis-matched cn, ESPECIALLY if the TCP session that your computer just partook in happened to be from the proper IP address! Apart from ripping out that ridiculous bit of code, I don’t see how you’re going to stop the reverse DNS request from going out (I presume it’s windows… though modifying even an open-source OS’s network stack to exclude one of the most basic network services because your admins are too lazy to not run their network like buffoons sounds equally appalling).

Before I just now came to grasps with the utter ludicrousness … of your admins’ request regarding DNS queries, and that you were already using the IP address rather than a hostname to begin with, I was going to suggest messing with ipconfig to temporarily render the OS too… ignorant to bother knowing who to ask about DNS mappings, and next I was going to suggest (if possible) throwing a socks4a or socks5 proxy at the XMPP client (as they, at least when their protocols are implemented correctly, handle any DNS queries themselves, upstream of the requesting party (so as to not “leak” the true source IP address via a tiny UDP DNS packet & its’ subsequent reply), but I don’t think any of that is going to help you. Sorry if I sound a little hard on your admin(s) … but being a network admin myself, I just never understand the ones who insist on making the simplest problems the into the hardest ones simply because they’re too dumb or lazy to think outside the box a little. I mean, c’mon, the hardware guarding and running your corporate VPN was so poorly configured, and your co-workers so untrustworthy that the admin is scared of what might happen if, god forbid(!), anybody resolving names over the network? LOL … give me a break!!! Slap him up-side the head and tell him to get off his ass and fix your friggin PTR record problem!!! LOL!

Nebojsa_Mihajlovic · November 19, 2012, 9:50pm

Thank you guys .Unfortunatelly issue is not resolved, but your answer helped me so much to better understand this issue.