Printer Services Mail Archive: PS> SSL/3.0 and TLS/1.0 detai

PS> SSL/3.0 and TLS/1.0 details and references

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Jan 14 2003 - 13:00:10 EST

  • Next message: BERKEMA,ALAN C (HP-Roseville,ex1): "PS> [PSI]: minutes 01/14/03"

    Hi folks, Tuesday (14 January 2003)

    At today's PSI Telecon, we agreed that a conforming PSI Client, Print
    Service, or Target Device that claims to support secure operation MUST
    support either: (a) Netscape SSL 3.0; or (b) IETF TLS 1.0 (version
    "3.1" over-the-wire).

    I further propose that a conforming PSI Client, Print Service, or Target
    Device that claims to support secure operation MUST NOT negotiate down
    to Netscape SSL 2.0 (to avoid compromised session security).

    Per my action item from today's PSI Telecon, below are some details from
    the IETF TLS 1.0 spec (RFC 2246) about fallback to Netscape SSL 3.0.

    Cheers,
    - Ira McDonald
      High North Inc

    ------------------------------------------------------------------------
    References for SSL and TLS specs:

    [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
             Corp., Feb 9, 1995.

    [SSL3] Frier, Karlton, Kocher, "The SSL 3.0 Protocol", Netscape
             Communications Corp., Nov 18, 1996.

    [TLS10] Dierks, Allen, "The TLS Protocol Version 1.0", RFC 2246,
             January 1999.
             - version "3.1" over-the-wire
             ftp://ftp.isi.edu/in-notes/rfc2246.txt

    [TLS11] Dierks, Rescorla, "The TLS Protocol Version 1.1",
             work-in-progress, October 2002.
             - version "3.2" over-the-wire
             ftp://ftp.ietf.org/internet-drafts/
             draft-ietf-tls-rfc2246-bis-02.txt

    ------------------------------------------------------------------------
    Excerpt from "The TLS Protocol Version 1.0" (RFC 2246, January 1999):

    E. Backward Compatibility With SSL

       For historical reasons and in order to avoid a profligate consumption
       of reserved port numbers, application protocols which are secured by
       TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
       connection port: for example, the https protocol (HTTP secured by SSL
       or TLS) uses port 443 regardless of which security protocol it is
       using. Thus, some mechanism must be determined to distinguish and
       negotiate among the various protocols.

       TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
       is easy. TLS clients who wish to negotiate with SSL 3.0 servers
       should send client hello messages using the SSL 3.0 record format and
       client hello structure, sending {3, 1} for the version field to note
       that they support TLS 1.0. If the server supports only SSL 3.0, it
       will respond with an SSL 3.0 server hello; if it supports TLS, with a
       TLS server hello. The negotiation then proceeds as appropriate for
       the negotiated protocol.

       Similarly, a TLS server which wishes to interoperate with SSL 3.0
       clients should accept SSL 3.0 client hello messages and respond with
       an SSL 3.0 server hello if an SSL 3.0 client hello is received which
       has a version field of {3, 0}, denoting that this client does not
       support TLS.

       Whenever a client already knows the highest protocol known to a
       server (for example, when resuming a session), it should initiate the
       connection in that native protocol.

       TLS 1.0 clients that support SSL Version 2.0 servers must send SSL
       Version 2.0 client hello messages [SSL2]. TLS servers should accept
       either client hello format if they wish to support SSL 2.0 clients on
       the same connection port. The only deviations from the Version 2.0
       specification are the ability to specify a version with a value of
       three and the support for more ciphering types in the CipherSpec.

     Warning: The ability to send Version 2.0 client hello messages will be
              phased out with all due haste. Implementors should make every
              effort to move forward as quickly as possible. Version 3.0
              provides better mechanisms for moving to newer versions.

       The following cipher specifications are carryovers from SSL Version
       2.0. These are assumed to use RSA for key exchange and
       authentication.

           V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
           V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
           V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
           V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
                                                      = { 0x04,0x00,0x80 };
           V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
           V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
           V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };

       Cipher specifications native to TLS can be included in Version 2.0
       client hello messages using the syntax below. Any V2CipherSpec
       element with its first byte equal to zero will be ignored by Version
       2.0 servers. Clients sending any of the above V2CipherSpecs should
       also include the TLS equivalent (see Appendix A.5):

           V2CipherSpec (see TLS name) = { 0x00, CipherSuite };



    This archive was generated by hypermail 2b29 : Tue Jan 14 2003 - 13:00:44 EST