View Full Version : Weird problem with smtp-auth and tls patch
Hi everyone,
I'm having a really weird problem with the qmail-1.03-jms1.6b patch.
I've patched qmail-1.0.3 per the patch instructions and it compiles fine.
I've made a certificate and put that in the right spot, and can successfully test the SMTP AUTH and TLS using the brilliant howto here:
http://qmail.jms1.net/test-auth.shtml
The problem is that when I then do an AUTH and try to send a test message, I get this error:
29368:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:288:
The message is delivered succesfully, but in the case of using this with a normal client (ie: Thunderbird) it reports that it couldn't send the message, but then it ends up in my INBOX.
I've searched FAR AND WIDE for a solution to this error message and I can't find anything that is helpful. Please, if anyone has a solution, or has a working auth+tls implementation on Solaris x86 let me know!
Below is the output when I follow the auth+tls testing howto:
SSL handshake has read 1119 bytes and written 356 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: 7196C4D79B88DD8B162733F4DABB55FA4E47B91855DFA14895 8A15751036E38C
Session-ID-ctx:
Master-Key: 5872A5D8DD8FD379B6685E8BE9A405D1964A8059BED25CEF98 948B5256242FF3F485AD0E0EFFA262D4FA2915CB68CEBC
Key-Arg : None
Start Time: 1131446689
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
220 mail.mydomain.com ESMTP
AUTH PLAIN [__________________________]
235 ok, go ahead (#2.0.0)
mail to: ian@mydomain.com
250 ok
rctp from: ian@mydomain.com
502 unimplemented (#5.5.1)
rcpt from: ian@mydomain.com
250 ok
data
354 go ahead
test
.
29472:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:288:
bash-3.00#
I have investigated this problem further, I really need some help on this!
Some more information:
1. Sending email without TLS and without AUTH works (to my domain)
2. Sending email with only TLS works
3. Sending email with only AUTH works (modified the source to allow this)
4. Sending email with TLS and AUTH fails
The error occurs when the client is connected with TLS and AUTH and they issue a "." to indicate end of data.
Using the -debug with openssl shows that when qmail-smtp gets the "." something is sending the plain text string "unix" over the wire and breaking the SSL connection.
I am not smoking crack, check out the openssl output below:
read from 0x80ece18 [0x80f2a05] (48 bytes => 48 (0x30))
0000 - d0 07 1b 8f c7 7d 01 6c-09 b0 b3 3e 3b 2e cf 27 .....}.l...>;..'
0010 - d8 06 c5 25 ac 75 34 5d-6d 48 20 9b 9a 81 05 b4 ...%.u4]mH .....
0020 - b4 88 49 42 59 9d 3c 2d-4f e0 e4 91 b0 23 75 44 ..IBY.<-O....#uD
354 go ahead
test
write to 0x80ece18 [0x80f7210] (74 bytes => 74 (0x4A))
0000 - 17 03 01 00 20 6d 39 d9-5b 67 2f fa 40 ff 49 17 .... m9.[g/.@.I.
0010 - 0a a1 56 d3 e5 f1 91 67-b0 de 6a 15 23 c9 0c b7 ..V....g..j.#...
0020 - d5 09 6d 37 7d 17 03 01-00 20 c2 bb e5 56 29 c1 ..m7}.... ...V).
0030 - c0 bf 7c a7 cf b7 c6 09-61 ef e8 8a c1 c7 ca 44 ..|.....a......D
0040 - 4c 40 15 7f 15 8c 16 af-4b a9 L@......K.
.
write to 0x80ece18 [0x80f7210] (74 bytes => 74 (0x4A))
0000 - 17 03 01 00 20 89 62 17-19 27 29 36 e3 48 bf 99 .... .b..')6.H..
0010 - 96 77 05 e1 d0 4a 7b 9f-d6 6a 3b ec f7 7c a0 c9 .w...J{..j;..|..
0020 - 22 51 64 05 88 17 03 01-00 20 e5 a7 21 bc f8 a8 "Qd...... ..!...
0030 - 54 8c af 09 cf 3d c1 4e-b9 40 b3 38 2d 0f 60 59 T....=.N.@.8-.`Y
0040 - 62 e5 f0 2c 00 a5 ae 86-55 61 b..,....Ua
read from 0x80ece18 [0x80f2a00] (5 bytes => 5 (0x5))
0000 - 75 6e 69 78 unix
0005 - <SPACES/NULS>
write to 0x80ece18 [0x80f7210] (37 bytes => 37 (0x25))
0000 - 15 6e 69 00 20 be 1e 63-68 99 b4 4e c7 cd 56 ab .ni. ..ch..N..V.
0010 - a6 f9 74 6d 64 7c b2 09-24 31 88 15 bf 1f 12 0a ..tmd|..$1......
0020 - a4 af 61 96 ba ..a..
2846:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:288:
write to 0x80ece18 [0x80f7210] (37 bytes => 37 (0x25))
0000 - 15 6e 69 00 20 89 fe 1c-a9 d4 cf 7e ba 99 b1 aa .ni. ......~....
0010 - 8d 76 09 9a 62 85 b2 fd-80 95 41 f6 01 18 a2 bf .v..b.....A.....
0020 - 80 e4 31 26 99 ..1&.
Playing around with qmail-smtp.c, I've also determined that:
- Although an error occurs (and Thunderbird says there was a problem delivering the mail) the email actually arrives!
- If authenticate() is bypassed and TLS is enabled, the problem wont occur
- Using some out() debug messages, it appears that the problem occurs at this line inside the blast() function: substdio_get(&ssin,&ch,1);
I've tried solaris cc AND gcc, and I've also tried 6c-test1.patch and 6c-test4.patch with no luck.
I really hope JMS can help me!!!
Master-Key: 5872A5D8DD8FD379B6685E8BE9A405D1964A8059BED25CEF98 948B5256242FF3F485AD0E0EFFA262D4FA2915CB68CEBC
this long number is your secret key, which you have now published on the internet. you need to generate a new key pair as soon as possible, otherwise you are throwing away the benefit of any SSL or TLS because anybody who knows what they're doing with this number can re-generate your .pem file.
as for the problem... the first thing i need is the full un-edited command line that starts your SMTP service. if something is printing "unix" in the middle, it may be helpful to know what is running in the pipeline and therefore might be able to print the message at that particular point in time.
you also mentioned that you altered the source for some reason- what specifically did you change and why?
and for my benefit, please move the question to the mailing list. forums are not my thing- i have an account here but i don't have the time to check into five different forums every day. the mailing list at least shows up in my mailbox where i can't miss it...
this long number is your secret key, which you have now published on the internet.
oops, thanks.
you also mentioned that you altered the source for some reason- what specifically did you change and why?
I only commented out the check for TLS before AUTH in qmail-smtp.c, just to see if it was specifically AUTH causing the problem.
and for my benefit, please move the question to the mailing list.
Done.
(Posted to the mailing list)
Hi everyone,
I have fixed this, turns out it was a problem with qmail-scanner and perl's syslog function.
By default qmail-scanner-queue.pl is configured to write syslog using a socket, which doesn't work on solaris:
unix dgram connect: Socket operation on non-socket at /dev/fd/3 line 2878
To fix:
edit /var/qmail/bin/qmail-scanner-queue.pl
change line 100:
setlogsock('unix');
- to -
setlogsock('stream');
Verify this works with:
qmail-scanner-1.22/contrib/test_installation.sh -doit
This problem has a nasty side effect of breaking auth + tls, because the error message makes it to the client and breaks the SSL connection.
regards,
Ian.
I only commented out the check for TLS before AUTH in qmail-smtp.c, just to see if it was specifically AUTH causing the problem.
editing the source wasn't needed- you may want to read the web page again. the ALLOW_INSECURE_AUTH variable does exactly this.
for your users' sake i hope you remembered to put the source code back the way it was, and that you don't use the ALLOW_INSECURE_AUTH option on a live server, because it allows the users' passwords to cross the internet in plain text. that was the whole reason i added that security check in the first place, to keep people with packet sniffers from getting my users' passwords (which i *was* seeing happen, at two of the ISPs where i used to work.)
Of course I undid my changes on the production server!
I don't think you should be so critical of my debugging. I was trying to solve a problem on a test server, and part of my process of understanding qmail was to put out() messages to follow the code path.
Your website is great, and I did read about the ALLOW_INSECURE_AUTH, but in my case I was trying to find the cause of a particularly obscure problem, therefore I did this as part of learning how qmail-smtp works.
Although I've fixed the problem, I think there is potentially a problem with the way pipes are handled when AUTH is enabled, because it allows stderr to come through to the client in plain text.
Of course I undid my changes on the production server!
I don't think you should be so critical of my debugging. I was trying to solve a problem on a test server, and part of my process of understanding qmail was to put out() messages to follow the code path.
Your website is great, and I did read about the ALLOW_INSECURE_AUTH, but in my case I was trying to find the cause of a particularly obscure problem, therefore I did this as part of learning how qmail-smtp works.[.
i wasn't trying to criticize, just offering a reminder not to leave your server in an insecure state by forgetting to remove the changes..... and it was meant as much for the benefit of people who may read this afterward as it was for you.
Although I've fixed the problem, I think there is potentially a problem with the way pipes are handled when AUTH is enabled, because it allows stderr to come through to the client in plain text.
i haven't seen it happen in any of my testing, with 6b or with 6c-test4. the stderr channel from vchkpw (and later from /bin/true, if the AUTH is successful) ends up on the stderr channel for qmail-scanner, which ends up on the stderr channel of qmail-smtpd, which ends up being routed to multilog.
a way to test this might be to write a shell script which sends a message to stderr (i.e. "echo testing 1>&2") and then does "exit 0", and then have qmail-smtpd run your script instead of calling /bin/true. you should see the "testing" message appear in your qmail-smtpd log, rather than being sent to the client. if not, they you will have found a bug and i will need to try and duplicate it on my system so i can find and fix it...
vBulletin® v3.6.8, Copyright ©2000-2009, Jelsoft Enterprises Ltd.