392743 - Mail & news clients don't autmatically recover from TLS intolerant servers

Status: NEW

(MailNews Core :: Networking, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

mozilla's https clients all have a feature in their networking code, 
whereby they automatically recover from SSL/TLS handshake failures with
flawed https (SSL) servers, and succeed without user intervention.
The Mail & News clients do not do that automatic recovery with 
IMAPS, SMTPS, POP3S, etc. servers.  They should.

Background:

The SSL 3.0 protocol was carefully designed and specified to permit the 
addition of new features in subsequent versions of SSL, while still keeping
the clients of these newer versions compatible with servers of the older
SSL 3.0 protocol.  The design allowed an SSL 3.0 server to receive a 
handshake message from a client with a newer version of SSL (a version 
that might contain new things unknown in SSL 3.0) and still be able to 
successfully negotiate an SSL 3.0 connection.  The design called for 
servers to IGNORE things they don't understand.  This was designed into 
the SSL 3.0 protocol, but it was untested for many years ... until 
SSL 3.1 (better known as TLS) came along.  

When TLS came along, we quickly discovered that MANY SSL 3.0 server 
implementations had incorrectly implemented SSL 3.0, and so they could NOT
successfully negotiate an SSL 3.0 connection when the newer client sent 
an initial handshake message with any of the newer SSL 3.1 (TLS) features.
Such SSL 3.0 servers became known as "TLS Intolerant".  

Mozilla developers devised a means whereby clients could detect a failure
that implies TLS intolerance, and then automatically retry the connection
after switching to SSL 3.0.  Most of the work is done in PSM.  PSM signals
the calling network software to retry the connection, and PSM does the 
disabling of TLS (switching to NSS 3.0) and remembering that the server 
is TLS intolerant after that.  The only requirement on the higher layer 
networking protocol code is that it must retry the connection, on a new
socket, when it gets the indication to do so frmo PSM.

Kai described it this way: 
"PSM sees the failure, which is in the list of TLS-intolerance-error-codes, 
and remembers the site as intolerant.  PSM translates the SSL error code 
into a more generic error code (connection reset I think), which [tells]
the application code "let's retry". We know this works with he https 
protocol code. We know this is unreliable with mail protocol code. [...]
The mail protocol code does not retry the connection, but reports 
a general problem with the mail server. Still, PSM has know the 
knowledge the site is TLS intolerant, so when the user manually sends 
the message again, PSM will fall back to without-TLS."

This automatic retry is way overdue.  Bugs like bug 368611 might not have 
been reported if this feature had been working in mailnews code.  
Implementing this feature in the mail/news protocols could make a marked
improvement in user satisfaction.

Comment 1

[David :Bienvenu]

the IMAP code does in general retry, actually, so I assume we're primarily talking about SMTP and POP3.

Is there any documentation on the error codes we might expect to see in this situation?

Comment 2

[Kai Engert (:KaiE:)]

(In reply to comment #1)
> the IMAP code does in general retry, actually, so I assume we're primarily
> talking about SMTP and POP3.
> 
> Is there any documentation on the error codes we might expect to see in this
> situation?


PSM only uses a single error code for proposing such a "retry" condition:

  PR_CONNECT_RESET_ERROR

Comment 3

[Marcin Cieślak (:saper)]

UW-IMAPD automatically shutdowns STARTTLS connection with presenting a SSL23 client hello, see

http://mailman2.u.washington.edu/pipermail/imap-uw/2005-July/000136.html
http://mailman2.u.washington.edu/pipermail/imap-uw/2005-July/000103.html


I think this is related to bug 460419 and/or bug 412834. Maybe we should have a TLS intolerance logic changed?

For example, maybe after using STARTTLS in IMAP and SMTP or STLS in POP3 we should always attempt to do TLSv1 only? 

RFC2487 and RFC2595 do not explicitly forbade SSLv3, but they refer only to the  RFC 2246 TLSv1 protocol.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Let's get clear on some things.
There's no such thing as an "SSL23" client hello.  Even if some application
program somewhere has some code that refers to such things, they do not 
exist.  

There are SSL2 client hellos, and there are SSL 3.x client hellos.

TLS (which is SSL 3.1) and SSL 3.0 share the same client hello format.
Both TLS and SSL 3.0 allow client hellos to be sent in SSL2 hello format.
However, as you've observed, it is customary for protocols that use the 
StartTLS feature to always use the SSL 3.x client hello format, and many
servers do not accept any other format following StartTLS negotiation.