RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt

[Rob Dugal <[e-mail]>]

FYI - Opera 9 will sometimes send a client hello with SSLv3 as the record 
version and TLSv1 as the client version.
In my tests with SSLv3 & TLSv1 enabled it first sends a client hello with 
TLSv1as the record version and TLSv1 as the client version.
If this handshake fails it retries using SSLv3/TLS1. 

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: [e-mail]
PHONE: [phone]
FAX  : [phone]
WEBSITE: www.certicom.com

<[e-mail]> wrote on 07/05/2006 07:33:49 AM:

> Martin,
> 
> While your interpretation of the spec does make sense in general, it
> is exactly the opposite of what most implementations seem to use.
> 
> After some additional work with OpenSSL and Mozilla NSS (see my
> reply to Bodo earlier today), *all* the implementations mentioned so
> far (OpenSSL, Mozilla NSS, Microsoft IE, SunJSSE, GnuTLS, PureTLS)
> seem to send 03,01 in both fields (when V2 hellos are disabled, and
> both SSL3 and TLS1.0 are enabled), and *none* of them seems to ever
> send different values in these fields.
> 
> Since the goal of the specification is to help interoperability, the
> right clarification to this ambiguity should not be based solely on a
> "protocol lawyer reading" of the spec (and declaring most current
> implementations "broken"), but also on what existing widely used
> implementations do.
> 
> But as you and Bodo pointed out, while knowing what existing clients 
> do is useful, it's not sufficient: what existing servers do also
> matters. This requires some further investigation...
> 
> (I do agree that for servers, the best guidance seems to be that
> "when receiving ClientHello, ignore the record version (or at least
> the minor version) and try to parse it anyway").
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: ext Martin Rex [mailto:[e-mail]] 
> > Sent: 03 July, 2006 20:09
> > To: Eronen Pasi (Nokia-NRC/Helsinki)
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
> > 
> > [e-mail] wrote:
> > > 
> > > I agree that the spec is ambiguous in this respect, but I'm not
> > > so sure about what the correct interpretation should be. In 
> > > other words, when a TLS client supports more than one of (SSLv3,
> > > TLSv10, TLSv11), should the record layer version number contain
> > > the lowest supported protocol, or the same value as handshake
> > > layer ClientHello?
> > 
> > It SHOULD contain the lowest protocol version that the client is
> > willing to negotiate.  Anything else is going to cause
> > interoperability problems.  The most interesing question: what does
> > the installed base do today when it receives a client hello with a
> > 3.2 or even 3.3 or 3.4 version the "version" field of the SSL/TLS
> > record protocol AND in the client_version of the ClientHello
> > message.  I expect some servers to choke heavily (and rightfully).
> > 
> > The potential ambiguity is only for the casual reader, there
> > definitely never was an abiguity for the careful protocol
> > implementor.  The SSLv3 spec (which somewhat happened after the
> > fact) does not contain any ambiguity either, because it doesn't
> > define anything other than {3, 0} PDUs and version numbers.
> > 
> > The root of any ambiguity is that the spec fails to clearly seperare
> > version tags for the purpose of negotation (client_version,
> > server_version) and version tags (version) that indicates a
> > particular PDU encoding.
> > 
> > The description of the PDUs in the appendix of SSL/TLS specs contains
> > the protocol version in exactly three distinct variants:
> > 
> >     version
> >     client_version (only in ClientHello and PreMasterSecret)
> >     server_version (only in ServerHello)
> > 
> > All existing specs were NOT ambiguous in that exactly one field was
> > supposed to contain the negotiated version number.  And from the
> > description of the individual PDUs in Appendix A, it should have
> > been obvious to implementors which version field should have been
> > meant, and which one should not have been meant.
> > 
> > There are very few error-free specs, and this particular error (and
> > the correct wording) are fairly easy to figure, IMHO.
> > 
> > 
> > > 
> > > A quick and totally unscientific survey of what some widely used
> > > SSL/TLS implementations do:
> > > 
> > > - OpenSSL (0.9.8)
> > >   - When configured in "both SSLv3 and TLSv10 allowed" mode,
> > >     sends V2 ClientHello.
> > 
> > fine.
> > 
> > >   - When configured in "TLS10 only" mode, sends {03,01} in 
> > >     both fields
> > 
> > fine.
> > 
> > > - Mozilla Firefox 1.5
> > >   - Seems to send V2 ClientHello no matter what the settings??
> > 
> > fine.
> > 
> > > - MS Internet Explorer 6.0
> > >   - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
> > >     sends V3 ClientHello with {03,01} in both fields
> > 
> > broken.
> > 
> > > - SunJSSE (JDK 1.4.2)
> > >   - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
> > >     sends V3 ClientHello with {03,01} in both fields
> > 
> > broken.
> > 
> > > - GnuTLS (10.0.20)
> > >   - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
> > >     sends V3 ClientHello with {03,01} in both fields
> > 
> > broken.
> > 
> > >   - When configured in "SSLv3, TLSv1.0 and TLSv1.1 allowed" mode,
> > >     sends V3 ClientHello with {03,02} in both fields
> > 
> > broken.
> > 
> > > 
> > > In other words: All these implementation seem to follow the
> > > rule that TLSPlaintext.version==ClientHello.client_version, or
> > > use V2 ClientHellos...
> > 
> > Didn't you just say that OpenSSL and Mozilla used a correct behaviour
> > on the client side?
> > 
> > The more interesting question is what SSL/TLS servers do upon receipt,
> > and in particular what they do upon receipt of a high up 
> > version number, like {03,03} or {03,04}.
> > 
> > > 
> > > Given that Yngve's interoperability draft suggests that some
> > > servers incorrectly use the record layer version number for
> > > negotiation, I think the safest clarification would be to 
> > > say that the two version numbers must be equal.
> > 
> > The clarification should say that there's an awfully large installed
> > base that is broken and that the server will likely have to entirely
> > ignore the version number in the record protocol when processing
> > a ClientHello message, and upons sending, should send the lowest
> > version number that they're willing to use.
> > This makes protocol layering not as independent as it should be.
> > 
> > 
> > -Martin
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls