Smtp server generates wrong credentials

[BSchwarte]

Hi there!

I run Wingate 6.6.4 Build 1338 prof. on WinXP SP3 german. Since last week, i experience a strange problem with the WG mailserver:
The mailserver submits wrong credentials when it tries to deliver a mail to the ISP's mailserver (auth. required).
I tracked it down to the following:
Wingate generates a wrong Base64-encoded username as to be seen in the logfile-excerpt!

02/07/14 15:20:12 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 220 <servername> Welcome to Nemesis ESMTP server
02/07/14 15:20:12 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de C=>: EHLO <Wingate machine name>
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 250-<servername>
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 250-STARTTLS
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 250-AUTH LOGIN PLAIN
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 250-AUTH=LOGIN PLAIN
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 250-SIZE 120000000
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 250 HELP
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de C=>: STARTTLS
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 220 OK
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de C=>: EHLO <Wingate machine name>
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 250-<serverame>
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 250-AUTH LOGIN PLAIN
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 250-AUTH=LOGIN PLAIN
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 250-SIZE 120000000
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 250 HELP
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de C=>: AUTH LOGIN
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de <=S: 334 VXNlcm5hbWU6
02/07/14 15:20:13 127.0.0.2 <system> 0000015630 Debug: smtp.1und1.de C=>: c2VyxxxxxxxxxxxxxxxxxxxxxxxxLmRlAA==

This username in cleartext (which i do not post here) should translate to
'c2VyxxxxxxxxxxxxxxxxxxxxxxxxLmRl', but Wingate adds two Null-databytes ('AA') and two filler-bytes ('==')
Since the cleartext-string is a username/mailadress, it obviously does not contain Null-bytes and it's length is exactly 24 characters==>32 Base64-values,
so there is no need for any fill-bytes at the end.
Needless to say that the ISP's server regards this as 'invalid credentials'.
I triple-checked the settings in WG configuration, even checked the corresponding registry-entries - no Null-bytes there!
I tried manual logon using telnet and the abovementioned - correct - Base64-username and the corresponding password
and as expected it was accepted by the ISP-Server.
Similar problem when using AUTH PLAIN: Three Nullbytes at the end of the credential-string.

Can anybody shed some light on this??

TIA
Burkhard Schwarte

[adrien]

Hi

so this ran for ages without any problem, then it started failing to auth?

I wonder if the password stored is corrupted somehow. Did you try re-entering the password into the known server configuration?

Regards

Adrien

[BSchwarte]

Hi Adrien,

yes, it worked for several years and started to fail last week. I think, that the ISP (1und1.de) applied an update or conf.-change, that led to stricter credential-checks.
And yes, i re-entered the password, i even deleted the gateway-configuraion, stopped WG, checked in registry that the entries where gone and re-entered the gateway incl. username/password- with the same results. Since the password is not visible even in the debug-logs, i suspect the same problem with the appended NULLS there.
FYI: 1und1.de is the biggest hoster/ISP in germany. Their customers count by the millions,and they are among the international top5 webhosters and registrars, so i think they know perfectly well what they are doing ;-)
Best regards
B. Schwarte

[BSchwarte]

Hi Adrien,

I've got additional information for you:

Debug-log from another test - different username/password, same Wingate-machine, same maildomain, same smtp-server; AUTH PLAIN:

02/06/14 23:50:34 Debug: smtp.1und1.de <=S: 250-smtp.1und1.de
02/06/14 23:50:34 Debug: smtp.1und1.de <=S: 250-AUTH LOGIN PLAIN
02/06/14 23:50:34 Debug: smtp.1und1.de <=S: 250-AUTH=LOGIN PLAIN
02/06/14 23:50:34 Debug: smtp.1und1.de <=S: 250-SIZE 120000000
02/06/14 23:50:34 Debug: smtp.1und1.de <=S: 250 HELP
02/06/14 23:50:34 Debug: smtp.1und1.de C=>: AUTH PLAIN AGFsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxMQA=
02/06/14 23:50:34 Debug: smtp.1und1.de <=S: 535 Authentication credentials invalid

RFC4616 says clearly, how the string is to be composed:

...
PLAIN SASL Mechanism

The mechanism consists of a single message, a string of [UTF-8]
encoded [Unicode] characters, from the client to the server. The
client presents the authorization identity (identity to act as),
followed by a NUL (U+0000) character, followed by the authentication
identity (identity whose password will be used), followed by a NUL
(U+0000) character, followed by the clear-text password
...

Fortunately, the original credential-string in the debug-log contains the password, so we have got this situation:

Decoding of the original string from the log shows:
<NO AUTHORIZATION_IDENTITY><NULL><CORRECT USERNAME><NULL><CORRECT_PASSWORD><NULL><NULL>
This is definitely not correct, since the Password does not end with Nulls!
To me, this looks as if the 'C'-style string-terminators (double NULL in case of Unicode/UTF) are passed to the BASE64-encoding function and the result is presented to the ISP-Server, who doesn't like that.
Maybe that helps

Best regards
Burkhard Schwarte

[BSchwarte]

Hi Adrien,

I've got additional information for you:

Debug-log from another test - different username/password, same Wingate-machine, same maildomain, same smtp-server; AUTH PLAIN:

02/06/14 23:50:34 Debug: smtp.1und1.de <=S: 250-smtp.1und1.de
02/06/14 23:50:34 Debug: smtp.1und1.de <=S: 250-AUTH LOGIN PLAIN
02/06/14 23:50:34 Debug: smtp.1und1.de <=S: 250-AUTH=LOGIN PLAIN
02/06/14 23:50:34 Debug: smtp.1und1.de <=S: 250-SIZE 120000000
02/06/14 23:50:34 Debug: smtp.1und1.de <=S: 250 HELP
02/06/14 23:50:34 Debug: smtp.1und1.de C=>: AUTH PLAIN AGFsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxMQA=
02/06/14 23:50:34 Debug: smtp.1und1.de <=S: 535 Authentication credentials invalid

RFC4616 says clearly, how the string is to be composed:

...
PLAIN SASL Mechanism

The mechanism consists of a single message, a string of [UTF-8]
encoded [Unicode] characters, from the client to the server. The
client presents the authorization identity (identity to act as),
followed by a NUL (U+0000) character, followed by the authentication
identity (identity whose password will be used), followed by a NUL
(U+0000) character, followed by the clear-text password
...

Fortunately, the original credential-string in the debug-log contains the password, so we have got this situation:

Decoding of the original string from the log shows:
<NO AUTHORIZATION_IDENTITY><NULL><CORRECT USERNAME><NULL><CORRECT_PASSWORD><NULL><NULL>
This is definitely not a valid credential string, since the Password does not end with Nulls!
To me, this looks as if within Wingate, the 'C'-style string-terminators (double NULL in case of Unicode/UTF) are passed to the BASE64-encoding function and the result is presented to the ISP-Server, who doesn't like that.
Maybe that helps

Best regards
Burkhard Schwarte

[adrien]

Hi

looks like you're right and it's encoding the terminating NULL as well in the Base64 encoding function. I'll check the code when I get into the office and let you know for sure.

We re-wrote all this for WinGate 7, are you able to test a later version? 6.6.4 is so old we would have quite a bit of difficulty to patch a bug in it and deploy.

Regards

Adrien

[BSchwarte]

Hi!

Thanks for the quick replies!
I think, i can test with a newer version on another machine - probably on my home-machine, since i don't like the idea of fiddling around with the client's live machine. This will take a short time for setting it up, creting a testaccount with the notorious ISP etc.
BTW: Given the fact, that the bug is gone (or gets fixed) in a newer version: What about the client's existing license??

Happy bugtracking
B. Schwarte

[BSchwarte]

Hi!

I've set up a testmachine with WG 7.3.1 using same email settings as before, and it works like a charm!
So, if the existing WG6-license can be reused with that newer (if not the actual) version, i will update the live machine an the topic is settled...

Thnaks again for your support

B. Schwarte

[adrien]

Hi

it's possible the client's existing WinGate 6 license will work in WinGate 7 or even 8. It depends on the expiry date of the version protection that comes with the license (each new license comes with 1 year version protection, which can be optionally renewed).

If version protection was current as at 1 Jan 2011, then the license is able to be used in WinGate 7.x
If version protection was current as at 1 Jun 2013, then the license is able to be used in WinGate 8.x

Otherwise version protection on the license would need to be renewed, at a cost of 40% of the list price of the license. This will make the license eligible to run in WinGate 8.

Regards

Adrien