javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?

Eddie1 · April 27, 2006, 6:44am

Hi,

I am using smack to connect to wildfire server.

I have been trying to root out the source of this problem that I get when I try to vigorously test the login of my client by repeatedly clicking the login button and supply a wrong password. As I keep doing it this error will appear if I click fast enough.

at com.sun.net.ssl.internal.ssl.InputRecord.handleUnknownRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)

at org.jivesoftware.smack.XMPPConnection.proceedTLSReceived(XMPPConnection.java:11 18)

at org.jivesoftware.smack.PacketReader.parsePackets(PacketReader.java:322)

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

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

Does anyone has any clues of why this error happens in smack? Most of the time it will return a “SASL authentication failed” exception. But sometimes the above exception happens.

etenneriello · May 12, 2006, 10:30am

Hi, the same error was catched by my Wildfire istance after a failed login of my client Spark, caused by a TLS negotiation.

I solved it checking the option “Use the OLD SSL port method” in the advanced settings of the client.

Bye

Eugenia

Gaston_Dombiak · May 13, 2006, 4:05am

Hey guys,

That problem has been fixed (JM-669) for the upcoming Wildfire release. You can try using the nightly build version as long as you are not using the server in production.

Regards,

– Gato

nut · May 18, 2006, 3:56am

I’'ve had the same issues, and with servers other than wildfire. I managed to fix it by putting a,

Thread.sleep(1000);[/b]

between my,

XMPPConnection conn = new XMPPConnection(config);[/b]

and my,

conn.login(“user”, “pass”);[/b]

The problem seems be that connection handshaking is kicked off in another thread when the connection object is created. Bad form, I think, in what really has to be a blocking operation. the '‘isConnected()" method doesn’'t seem to return reliable results either.

So anyways, it appears that if you try to login too soon, you end up sending your garbage over the socket while it’‘s still trying sort out protocol stuff. I’'ll log a bug for this, and see what happens.

nut · May 18, 2006, 4:25am

OK, apparently this is where you log bugs. Could someone look at this possible race condition please?

Eddie1 · May 19, 2006, 8:48am

Will try that out after the next wildfire release.

Cheers!

Skip_Dooley · May 22, 2006, 7:44pm

I just posted a similar problem. I also used a delay before login to kludge a fix.

Up to thirty 100 millisecond delays. Under very heavy server load conditions I have seen it make it through all the delays and still fail!

I agree the constructor should be a synchonous blocking operation. You either successfully connect or not.

Srgjan_Srepfler · May 28, 2006, 8:50pm

We have the same problem, we modified the library and added the sleep on the login method. What approach will you take in order to correct this?

Also, why are all the logins synchronized except one?

Skip_Dooley · June 5, 2006, 2:44pm

The one login that is not synchronized is a just a wrapper method for one that is synchronized.

Adding a sleep helps the symptoms of the problem but is not a cure.

If you push the server hard enough and its CPU is loaded by other applications, most virus checkers for PC’'s provide a great CPU/disk load especially if they check compressed files!, then the problem will still occur.

The sleep lessens the occurrence of the problem

Srgjan_Srepfler · June 5, 2006, 3:06pm

So you are confirming this happens on 2.0.2 as well? Is there something we can do to correct this issue or does the lib itself needs refactoring? Perhaps some smart asynchronous pattern or using the new concurrent utils?

Skip_Dooley · June 5, 2006, 7:07pm

I tested using Smack 2.2 and wildfire 2.6-2.6.2.

My test creates 50-shared groups and 150 accounts through a custom plugin.

After creating the account a connection and a login are performed.

This is driven from a command file of sorts. A delay can be inserted between each account creation or it can run wide open (as fast as it can).

Each login takes 4 threads (Smack internal implementation) so over 600 threads.

The server is running on a separate machine usually with some artificial load applied.

At one time each user was a member of each shared group that created an enormous amount of presence traffic as the user amount went up.

These users did not need to know each other’s presence so the “share” was modified so that would not occur.

But the exception still occurs.

In between the connection creation and login a test is made.

if (!this.xmppCon.isUsingTLS ())

{

try

{

this.log.error (“TLS not ready sleep 100 milliseconds”);

Thread.sleep (100);

}

catch (InterruptedException ie)

{

this.log.error (“sleep interrupted”);

return false;

}

this.xmppCon.login (this.jabberUser, this.jabberPassword, “Smackaroo”, true);

When the server fumbles an SSL sequence the error occurs (I am assuming)

I will see 1-30 sleeps mostly just 1. If a login is attempted before the TLS is ready, the exception will occur.

Point here is the connection should not return successful if TLS is not ready or any other error and it does. So the loop buys a little time that works in “most” not all occurrences.

Therefore, my saying of, “If it can fail it will fail”

Most folks do pretty lightweight testing which is sufficient with a single user GUI XMP client although some folks have seen a similar problem just repeatedly pushing a login button. Kind of a reverse slot machine, the jackpot being when it throws the exception.

Have also tested with server on a dual processor 3Ghz machine.

skip

Skip_Dooley · June 5, 2006, 7:10pm

Also see my original post in a different thread

http://www.jivesoftware.org/community/thread.jspa?threadID=19926&tstart=0

if you haven’'t already seen it.

Srgjan_Srepfler · June 5, 2006, 11:31pm

Thanks sdooley, my problem is that we are not building a client but we’‘re using the smack indirectly through the MULE ESB xmpp provider, so if these thing happen we are loosing a critical channel for notification to our backend. And we are very uncomfortable if something like this happens. Are you a developer on the library? Can we hear from the dev’‘s when and how do they plan to address this issue? Perhaps they should use something like the Future object and block the return until the Future has been returned? (I’'m just blabbing, I have no concrete experience with real concurrent programming )

Skip_Dooley · June 6, 2006, 12:36pm

I am a software developer but am not involved with development of any Jive software proper. We are developing applications which use Smack and Wildfire currently.

Skip_Dooley · June 7, 2006, 12:30pm

See

http://www.jivesoftware.org/community/thread.jspa?threadID=19926&tstart=0

The problem is the SSL negotiation thread is still chatting while trying to perform a login and thusly mixing messages on socket confusing the SSL negotiation

LG1 · June 7, 2006, 10:14pm

Hi,

Alex did create SMACK-140 so we hope that it will be fixed soon.

LG

PS: Please don’'t spend points for this info when you mark this question as answered.

Skip_Dooley · June 9, 2006, 5:20pm

Latest tests indicate that KeepAlive is a culprit for this exception.

To prove this theory, I have a 100 user login test from one test app.

Normally, I run KeepAlive at a reasonable 10 secs. Occasionally error is thrown and that is on a loaded system, difficult to pinpoint because error cannot be created on demand.

I decided to reduce the KeepAlive to 100 milliseconds. Wham exception is thrown EVERYTIME on 1st connection. Increasing in 100 millisecond increments it became more stable around 800 ms.

Set KeepAlive to 0, problem goes away.

Comment out the write of a space in KeepAlive thread but leaving the flush also makes problem go away!

I am trying to determine a fix but thus far have been unable to pinpoint the problem.

So KeepAlive kills…

Oh, disable TLS, problem does not occur either.

Gaston_Dombiak · June 9, 2006, 5:27pm

Hey Skip,

Super cool finding!!! I tried several times to catch this error and after making some server changes the error seemed to be fixed but your explanation makes total sense to me. That would explain the randomness of this problem and it also explains the problem since the keep alive thread can be sending data over the socket during TLS negotiation thus breaking it.

I will now check the code and will try to check in a fix in a moment.

Thanks again,

– Gato

Srgjan_Srepfler · June 9, 2006, 8:35pm

Will this be a fix for Wildfire or Smack? When can we hope to see a official release that includes it? Is there a chance this will fix apps that use the smack library or will they need to be recompiled? Where can we do these modifications?

Message was edited by: schrepfler

Gaston_Dombiak · June 9, 2006, 8:51pm

Hey Srgjan,

This is a Smack fix. In the next url=http://www.jivesoftware.org/nightly.jspnightly build[/url] you will find the bug fix. Just replace the old smack.jar with the new one and give it a try.

Regards,

– Gato