138961 - SMTP over SSL fails when certificate based authentication is required

Status: VERIFIED DUPLICATE of bug 98399

(Core Graveyard :: Security: UI, defect, P2)

Description

[danilo]

when using the mail component of mozilla 1.0rc1 the following problem occurs:

if the smtp server requires autentication based on the client certificate
mozilla does not return the requested certificate. This causes the connection
to be closed by the server side and sending the mail fails with usual
message box shown by mozilla.

The server side is implemented using stunnel connected to port 465 via xinetd.
The following command line is used

stunnel -v2 -A /myCA/cacert.pem -l /usr/lib/sendmail -n smtp -- sendmail -bs

AFAIR in mozilla 0.9.9 the authentication work when stunnel was connected to
port 25. Due to the missing "port" option it was not possible to test it on
port 465 but this should not matter.

Comment 1

[Thomas Lußnig]

this not only apear on stunnel also with regular sendmail (TLS enabled)
and there are no cert send to sendmail. It would nice to recive an
notify if this become fixed. Also with 0.9.9 it do not work.

Comment 2

[Mitchell Stoltz (not reading bugmail)]

->PSM

Comment 3

[Stephane Saux]

Does your web server do only ssl client auth or does it degrade to name/pwd over
ssl if the cert is not presented.

I do ssl client auth for smtp all the time, without any problem.

Comment 4

[danilo]

No, the server (in my case stunnel) does not fall back to user/pw auth
if no cert is presented. 

The relevant part of the log shows that the problem is the missing
cert

bert stunnel[19247]: Using 'sendmail' as tcpwrapper service nameApr 21 15:13:17
bert stunnel[19247]: stunnel 3.22 on i386-redhat-linux-gnu PTHREAD+LIBWRAP with
OpenSSL 0.9.6b [engine] 9 Jul 2001
bert stunnel[19247]: sendmail connected from 192.168.1.7:1351
bert stunnel[19247]: SSL_accept: error:140890C7:SSL
routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate

what does work is encrypted connection via ssl, i.e. the server does not
request the client certificate (stunnel called w/o -v2 option)

Comment 5

[Stephane Saux]

cc nelsonb.

More questions:
What are your prefs for security->certificates->{select automatically, ask every
time}?  I assume that the cert you're using is trusted on the client side.
How is the server configured with respect to listing the CAs accepted for
signing the client-auth certificate?  There may be an issue there if the list
doesn't contain the correct CA.

Comment 6

[danilo]

It doesn't matter whether I select automatic or manual selection of certificates.
I tried both.
The /myCA/cacert.pem is the CA certificate used to issue the client certificate

The log below shows the debug output of stunnel during a connection attempt:

 Apr 29 07:21:09 myserver stunnel[19335]: Using 'sendmail' as tcpwrapper service
name
Apr 29 07:21:09 myserver stunnel[19335]: stunnel 3.22 on i386-redhat-linux-gnu
PTHREAD+LIBWRAP with OpenSSL 0.9.6b [engine] 9 Jul 2001
Apr 29 07:21:09 myserver stunnel[19335]: sendmail connected from 141.44.25.29:57396
Apr 29 07:21:09 myserver stunnel[19335]: SSL_accept: Peer suddenly disconnected
Apr 29 07:21:09 myserver xinetd[1191]: EXIT: smtps pid=19335 duration=30(sec)
Apr 29 07:26:03 myserver xinetd[1191]: START: smtps pid=19450 from=192.168.2.3
Apr 29 07:26:03 myserver stunnel[19450]: Using 'sendmail' as tcpwrapper service name
Apr 29 07:26:03 myserver stunnel[19450]: Snagged 64 random bytes from /dev/urandom
Apr 29 07:26:03 myserver stunnel[19450]: RAND_status claims sufficient entropy
for the PRNG
Apr 29 07:26:03 myserver stunnel[19450]: PRNG seeded successfully
Apr 29 07:26:03 myserver stunnel[19450]: Certificate:
/usr/share/ssl/certs/stunnel.pem
Apr 29 07:26:03 myserver stunnel[19450]: cert_defaults is 2
Apr 29 07:26:03 myserver stunnel[19450]: cert_dir is
Apr 29 07:26:03 myserver stunnel[19450]: cert_file is /myCA/cacert.pem
Apr 29 07:26:03 myserver stunnel[19450]: installing defaults where not set
Apr 29 07:26:03 myserver stunnel[19450]: Loaded verify certificates from
/myCA/cacert.pem
Apr 29 07:26:03 myserver stunnel[19450]: Set verify directory to
/usr/share/ssl/trusted
Apr 29 07:26:03 myserver stunnel[19450]: stunnel 3.22 on i386-redhat-linux-gnu
PTHREAD+LIBWRAP with OpenSSL 0.9.6b [engine] 9 Jul 2001
Apr 29 07:26:03 myserver stunnel[19450]: sendmail started
Apr 29 07:26:03 myserver stunnel[19450]: sendmail connected from 192.168.2.3:1046
Apr 29 07:26:03 myserver stunnel[19450]: Local mode child started (PID=19451)
Apr 29 07:26:03 myserver stunnel[19450]: Remote FD=6 initialized
Apr 29 07:26:03 myserver stunnel[19450]: Negotiations for smtp(server side) started
Apr 29 07:26:03 myserver stunnel[19450]: RFC 2487 detected
Apr 29 07:26:03 myserver stunnel[19450]:  <- 220 myserver.mydomain.com ESMTP
Sendmail 8.11.6/8.11.6; Mon, 29 Apr 2002 07:26:03 +0200.
Apr 29 07:26:03 myserver stunnel[19450]:  -> 220 myserver.mydomain.com ESMTP
Sendmail 8.11.6/8.11.6; Mon, 29 Apr 2002 07:26:03 +0200. + stunnel..
Apr 29 07:26:03 myserver stunnel[19450]:  <- EHLO mydomain.com.
Apr 29 07:26:03 myserver stunnel[19450]:  -> 250-mydomain.com. Welcome..
Apr 29 07:26:03 myserver stunnel[19450]:  -> 250 STARTTLS..
Apr 29 07:26:03 myserver stunnel[19450]:  <- STARTTLS.
Apr 29 07:26:03 myserver stunnel[19450]:  -> 220 Go ahead..
Apr 29 07:26:03 myserver stunnel[19450]: SSL state (accept): before/accept
initialization
Apr 29 07:26:03 myserver stunnel[19450]: SSL state (accept): SSLv3 read client
hello A
Apr 29 07:26:03 myserver stunnel[19450]: SSL state (accept): SSLv3 write server
hello A
Apr 29 07:26:03 myserver stunnel[19450]: SSL state (accept): SSLv3 write
certificate A
Apr 29 07:26:03 myserver stunnel[19450]: SSL state (accept): SSLv3 write
certificate request A
Apr 29 07:26:03 myserver stunnel[19450]: SSL state (accept): SSLv3 flush data
Apr 29 07:26:09 myserver stunnel[19450]: SSL alert (write): fatal: handshake failure
Apr 29 07:26:09 myserver stunnel[19450]: SSL_accept: error:140890C7:SSL
routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
Apr 29 07:26:09 myserver stunnel[19450]: sendmail finished (0 left)

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

I'll wager that one of the following things is happening:

a) server is sending the client an empty list of names of CAs trusted to 
issue SSL client certs, or

b) client has no cert issued by any of the CAs in the server's list. 

In either case, the client's behavior is correct.

Comment 8

[danilo]

No, neither is the case. By experimenting a while I found that it works when I
turn off TLS support on the server side (stunnel Option -n smtp). In this case
Mozilla does not use TLS and is able to connect and identify itself correctly.

The bug seems to be somewhere in the TLS code on the client side, as  the
comment of Thomas Lußnig indicates that mozilla also does not cooperate with
sendmails TLS.

Comment 9

[John Unruh]

Sending to Mail/News

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

No resolution to this report can be made until we know what the server
really requested from the client, and what certs the client had.  

Recently, a bug report superficially similar to this one was shown to be 
invalid.  The server simply was not requesting any cert from the browser. 
We were able to determine that because the server in question was available 
on the Internet for testing.  Since the server in this bug report is not 
apparently available, the submittor needs to do the following for this 
bug to be confirmed:

1. use a program like ssltap or ssldump to collect ALL the details of
the SSL handshakes, especially the full details of the certificate 
request message that the server sends to the client.  The ssltap progam 
can handle startTLS connections.  Attach the output to this bug report.  

Once that output has been examined, if it shows that the server did send 
a properly formatted request to the client, and the client responded with a 
no-certs response, then 

2. We'll ask you for more info about your personal cert, the one that you
think should have been sent back in response to the cert request.  
In particular, we need to see that the cert's issuer name matches one of
those issuer names sent by the server in the cert request message, and that 
you have the private key for that cert. (We don't need the private key itself.)

Other background info:

Port 465 is typically used for wrapping smtp in SSL/TLS.  That is, when a
client connects to port 465, it typically does an SSL/TLS handshake 
immediately, and doesn't start SMTP until after the SSL/TLS handshake is 
done.  The entire smtp connection is wrapped with SSL/TLS.  
I think this is how stunnel behaves without the "-n smtp" option.  
AFAIK, mozilla does NOT support this mode of operation for smtp.

In contrast, on port 25, the smtp protocol starts in the clear, and the use
of SSL/TLS is negotiated using STARTTLS.  SSL/TLS starts in the middle of 
the smtp connection.  mozilla supports this.  I think this is the behavior 
of stunnel with the -n smtp option.  This is generally done only on port 25.
A client that connects to port 465 would not be expected to behave this way.

Comment 11

[Kai Engert (:KaiE:)]

Assigning back to PSM, I don't think it's a problem in mail/news.

Comment 12

[John Unruh]

I would suggest marking this invalid due to lack of response from the reporter, 
or mark a duplicate of bug 98399.

Comment 13

[John Unruh]

*** This bug has been marked as a duplicate of 98399 ***

Comment 14

[John Unruh]

Verified.