Talk FAQ Secure Sockets Layer Discu

Found at: 0x1bi.net:70/textfiles/file?internet/sslfaq.103

                              SSL-Talk FAQ

             Secure Sockets Layer Discussion List FAQ v1.0.3

                      Wed Dec 12 12:00:00 PST 1997

                           FAQ Maintained by:

               Christopher Allen 

                    Consensus Development Corporation


         The latest edition of this FAQ can always be found at:




  (c) 1996, 1997 Consensus Development Corporation - All Rights Reserved

    All information contained in this work is provided "as is." All

    warranties, expressed, implied or statutory, concerning the accuracy

    of the information of the suitability for any particular use are

    hereby specifically disclaimed. While every effort has been taken to

    ensure the accuracy of the information contained in this work,

    the authors assume(s) no responsibility for errors or omissions, or

    for damages resulting from the use of the information contained


    This work may be copied in any printed or electronic form for

    non-commercial, personal, or educational purposes if the work is not

    modified in any way, that the copyright notice, the notices of any

    other author included in this work, and this copyright agreement

    appear on all copies.

    Consensus Development Corporation also grants permission to

    distribute this work in electronic form over computer networks for

    other purposes, provided that, in addition to the terms and

    restrictions set forth above, Consensus Development Corporation

    and/or other cited authors are notified and that no fees are charged

    for access to the information in excess of normal online charges

    that are required for such distribution.

    This work may also be mentioned, cited, referred to or described

    (but not copied or distributed, except as authorized above) in

    printed publications, on-line services, other electronic

    communications media, and otherwise, provided that Consensus

    Development Corporation and any other cited author receives

    appropriate attribution.

    Comments about, suggestions about or corrections to this document

    are welcomed.  If you would like to ask us to change this document

    in some way, the method we appreciate most is for you to actually

    make the desired modifications to a copy of the posting, and then to

    send us the modified document, or a context diff between the posted

    version and your modified version (if you do the latter, make sure

    to include in your mail the "Version:" line from the posted

    version).  Submitting changes in this way makes dealing with them

    easier for us and helps to avoid misunderstandings about what you

    are suggesting.

    Many people have in the past provided feedback and corrections; we

    thank them for their input.

    In particular, many thanks to:

        Tim Dierks 

        Charles Neerdaels 

        Eric Greenberg 

        Bruce Schneier 

        Tom Weinstein 

        Jonathan Zamick 

    Remaining ambiguities, errors, and difficult-to-read passages are

    not their fault. :)
















This section contains information about the SSL-Talk list.

    The SSL-Talk List is an email list intended for discussion of the

    technical issues of implementing the SSL protocol.

    Past discussions have included issues of software development,

    cryptanalysis of the protocol and of its various implementations,

    testing, interoperability, the applicability of SSL to additional

    TCP-based applications, infrastructure growth questions, etc.

    The discussion list has also become a de facto support pipeline

    about configuring various servers. We'd like to try to keep this

    topic to a minimum, because it takes too much bandwidth.

    SSL is the Secure Sockets Layer protocol. Version 2.0 originated by

    Netscape Development Corporation, and version 3.0 was designed with

    public review and input from industry, and is defined at


    Send mail to the email address 

    with the *subject* being the single word SUBSCRIBE. You need not

    put any text in the body of your message.

    Please do not send requests to the SSL-Talk list.

    Any mail addressed to  will be sent to *all*

    members of the SSL-Talk mailing list.

    To remove your name from the ssl-talk list send mail to the address

     with the *subject* being the single

    word UNSUBSCRIBE. You need not put any text in the body of your


    Please do not send requests to the SSL-Talk list.

    The most common problem is that you are attempting to unsubscribe

    using an email address different than that with which you subscribed

    Check with your mail administrator and make sure that you don't have

    an alias or ".forward" file sending mail to you from another


    Another common problem is that the subdomain of your mailer has

    changed, for example, "mail.consensus.com" has been renamed


    In either case, sending mail with the "From:" line matching the

    account you subscribed with should unsubscribe you from the list.

    If this still doesn't work, send mail to 

    describing your problems unsubscribing, what email addresses you

    think you may have subscribed with, and if you think you may have a

    different mail address subscribed.

    Please don't send mail to the general SSL-Talk list to unsubscribe;

    it will only frustrate you and the rest of the recipients.

    There is a hypertext archive of the list at


    In some cases we have found that this archive occasionally is

    missing some messages -- if you know of any alternative archive

    sites, please let us know.

    We are not aware of any text archives of the list.

    It is the policy of the list to not allow advertising.  However,

    product availability announcements are acceptable, provided

        * The product is *directly* related to SSL;

        * The announcement does not wander too far from the

          topic of SSL;

        * The announcement is limited to an abstract of no more

          than one paragraph and a URL to the full announcement

          text, such as price, terms, features, or a press


        * The announcement is released not more than once per quarter

          per company.

    Subscribers or companies grossly violating these guidelines may be

    removed from the list by the list administrator.


This section contains general information on SSL and the SSL

    The current version is 3.0, as documented at


    Errata to the SSL 3.0 Specification is periodically posted on

    the SSL discussion list, and is available at


    Netscape has submitted SSL 3.0 to the IETF-TLS Working Group

    as an Internet Draft (see the section 4.5 of this FAQ for more

    info on TLS):


    The previous version of SSL, version 2.0 is documented at


    There is a brief overview and FAQ on Netscape security called

    "On Internet Security", available at


    There is a brief introduction on how Netscape uses public key

    cryptography in the SSL protocol called "Using Public Key

    Cryptography" at


    An overview on certificates and VeriSign's Digital IDs is at


    The online version of the technical specifications for the SSL 3.0

    protocol is at


    A PostScript version is also available at


    A FAQ for SSLeay, a freeware implementation of the SSL 2.0 protocol

    is available at


    A rather broad list of public key related documents, with a focus on

    certificates and standards can be found at


    WebCompare offers a list of security features supported by over 100

    different servers and clients at


    Currently it is not very accurate. If you know of changes please

    contact David Strom .

one place I can go to find out?

    There is an impressive "International Law Crypto Survey" of

    cryptographic laws and regulations throughout the world at


    RSA Data Security, Inc. offers an Acrobat version of their

    "Frequently Asked Questions: Export" at


    Other information on US export issues can be found on

    the Electronic Frontier Foundation's web site at


    Canadian export issues are converted at



This section contains information on how the SSL protocol interacts

Netscape Navigator "Network Preferences" menus?

    A proxy server is a computer program that resides on your firewall

    and acts as a conduit between your computer and the broader

    Internet. In addition to acting as network guardian and logging

    traffic, a proxy server can also provide an enterprise cache for

    files as well as replication and site-filtering services.

    Any application which needs to communicate through a proxy has to

    negotiate with the proxy first before continuing through the

    firewall. Netscape Navigator works with many different types of

    proxies (such as the CERN proxy server and their own Netscape Proxy

    Server) and gateways that use the SOCKS protocol.

    One problem with SSL-based traffic is that it does not work with

    caching and replication with proxy servers. For a proxy server to

    support SSL it must either support SOCKS, or use a special SSL

    Tunneling protocol. The Netscape Proxy Server supports both

    SOCKS and the SSL Tunneling protocol.

    SSL was designed to provide security between client and server and

    to avoid any kind of 3-way man-in-the-middle attack. Thus SSL cannot

    be proxied through traditional application level firewalls (such as

    the CERN proxy server), because SSL considers a proxy server to be

    a middleman.

    The simplest alternative to this problem is to use a packet

    filtering firewall. You set it up to open a reserved and trusted

    port for the SSL+HTTP or SSL+NNTP services (443 or 563 respectively)

    allowing all traffic on those ports to be passed through

    unrestricted. The risk with this solution is that an internal

    attacker could attempt to use these trusted ports without using SSL

    and there is no way for the firewall to know.

    SSL also can work with gateways that support the SOCKS protocol, a

    protocol independent proxy mechanism. SOCKS is a generic byte

    forwarding gateway between client and server, and generally works

    at the socket level. If all you want is TCP/UDP restrictions based on

    client IP or server IP, SOCKS works fine.

    However, most non-SSL HTTP proxies work at the protocol level and

    have the ability to understand header information related to the

    protocol. This goes beyond SOCKS to allow the firewall administrator

    to use the header information for filtering and/or monitoring the

    traffic. Also, SOCKS does not offer the firewall administrator

    enough information about the request to let it decide whether to

    allow it, and to log the request.

    A more secure approach is to use a firewall that supports the SSL

    Tunnelling CONNECT extension method as described in the Internet



    In SSL Tunneling, the client initiates an SSL connection via normal

    HTTP, then handshakes and creates a secure connection to the server

    via a byte-forwarding tunnel. The proxy has access to the

    client-proxy request headers, but the session is encrypted.  Once

    the handshake occurs, the proxy acts just like a SOCKS gateway. This

    allows the firewall to monitor the requests, but not the traffic.

    The biggest difference between the two methods is that when using

    SOCKS, DNS resolution is the responsibility of the client, whereas

    when requests are forwarded through a proxy, DNS resolution is the

    responsibility of the proxy.

    The are three additional things that the SSL Tunnelling mechanism

    does with the proxy server that do not happen when using SOCKS:

        * The client sends a "user agent" message (for example,


        * The proxy can send to the client an authorization request

          allowing the administrator to use passwords to control external

          Internet access.

        * The standard is more easily extensible. For example, the client

          could, in theory, send the URL being requested (or anything

          else) to the firewall. However, there is no standard to support

          this behavior and as far as we know there are no products which

          do it.

    The Netscape Proxy Server supports the SSL Tunnelling CONNECT

    extension method for tunnelling SSL, and the use of the proxy is

    described in


    Another solution, also available using the Netscape Proxy Server, is

    that the proxy server can spoof SSL on behalf of the internal

    client. The proxy will initiate SSL between itself and other servers

    on the Internet, but be unsecure inside the firewall between the

    proxy server and the client.

    This compromise means that client authentication is not possible;

    only server authentication of the remote sites is available.

    However, you gain the ability for client authentication between the

    client to the proxy. The administrator must decide which is more

    important, until such time as a better solution arises. The

    description of this feature of the Netscape Proxy Server is at


    Reverse proxies are a solution for serving secure content inside

    a firewall to outside clients. For the Netscape Proxy Server

    this is described at


    It is possible for a proxy server to hold both client and server

    keys for its internal clients. This allows SSL sessions to be

    carried out twice: once between the client and proxy server, and

    again between the proxy server and the secure server.  Thus, the

    proxy server can to listen in on the conversation without having the

    private keys of external servers. Clearly this isn't reasonable for

    the general internet, but it is a viable solution for corporate

    requirements inside a firewall.

    The current 2.1 beta of the Netscape Proxy Server supports this

    feature. It can be used as described above, or simply to create a

    secure tunnel between sites across an insecure network. This is

    really multiple sessions of SSL, not an end-to-end secure


    This means that 2.1 beta has full SSL support as opposed to just SSL

    tunneling.  It can therefore do client authentication and serve

    documents like a secure server, or request documents like an

    SSL-enabled client. SSL doesn't allow recursive encryption, so by

    using it this way you lose the transparency of the proxy and get

    multiple segments of secure connections, rather than a single

    end-to-end connection.

    A proxy server must just pass SSL directly through without caching.

    Theoretically SSL can transparently secure any TCP based protocol

    running on any port if both sides know the other side is using SSL.

    However, in practice, separate port numbers have been reserved for

    each protocol commonly secured by SSL -- this allows packet

    filtering firewalls to allow such secure traffic through.

    As of September 1996, SSL has the following port numbers reserved

    with the Internet Assigned Numbers Authority (IANA), a part of the

    Internet Engineering Task Force (IETF):

        Keyword     Decimal    Description

        -------     -------    -----------

        https       443/tcp    https

        ssmtp       465/tcp    ssmtp

        snews       563/tcp    snews

        ssl-ldap    636/tcp    ssl-ldap

        spop3       995/tcp    SSL based POP3

    The name sftp conflicts with a protocol called simple file transfer

    protocol. As far as we can tell, no one has yet applied for a port

    for 'ftps', nor does it appear in the SSL 3.0 specification.

    However, some companies have begun to use port 990 for ftps

    informally until it is officially registered.


This section contains more detailed information on the SSL protocol.

message interceptors?

    Yes. Both the client and the server provide part of the random data

    used to generate the keys for each connection. (The client and

    server random portions from the connection that initiates a session

    are also used to generate the master secret associated with that

    session.) Additionally, each record is protected with a MAC that

    contains a sequence number for the message.

there have to be a one-to-one mapping between write() calls on the

client/server and SSL records? Is there some other blocking

taking place when user data is being sent?

    The record layer takes a data stream from the higher layers and

    fragments it into records. If the write is longer than 2^14 bytes

    (with headers), the record layer will generate multiple records.

    Multiple writes can be condensed into a single record.

    Yes, SSL relies on an underlying reliable protocol to assure that

    bytes are not lost or inserted. There was some discussion of

    reengineering the future TLS protocol to work over datagram

    protocols such as UDP, however, most people at a recent TLS meeting

    felt that this was inappropriate layering.

t? Exchanging random numbers that are encrypted with the server's (or
client's) public key would seem to be an adequate way of getting the

    Anonymous DH key exchange doesn't require the use of certificates.

    Ephemeral DH allows you to use signing-only certificates, and it

    protects the session from future compromise of the server's private

    key. Another advantage of DH is that the patent expires next year.

out of them yet?

    TLS is the Transport Layer Security Working Group of the IETF

    (Internet Engineering Task Force). It is the working group

    responsible for moving transport layer protocols such as SSL

    through the standards tracks.

    IETF working groups do most of their activities through mailing

    lists and thrice-annual IETF meetings. The first official IETF-TLS

    Working Group meeting was June 1996 in Montreal. (Before then it was

    an unofficial BOF "birds of a feather" group.)

    The home page for the IETF-TLS Working Group is at


    The discussion list for IETF-TLS is at IETF-TLS@CONSENSUS.COM. You

    subscribe and unsubscribe by sending to IETF-TLS@CONSENSUS.COM with

    subscribe or unsubscribe in the SUBJECT of the message. Archives of

    the list are at


    The minutes for the last IETF-TLS Working Group meeting in

    San Jose in December of '96 are at


    The minutes for the IETF-TLS Working Group meeting in Montreal in

    June of '96 are in two messages at:



    There was a day-long pre-Montreal meeting in Palo Alto of May in '96

    the minutes of which give a fairly complete list of old technical

    issues and possible solutions. The minutes of this meeting are at


    A number of internet-draft documents have been submitted to the

    IETF-TLS Working Group.

    The TLS Protocol 1.0

    (Current Version 01 with Change Bars from 00):


            (157637 bytes, expires August '97)

    The TLS Protocol 1.0 (Old Version 00):


            (147284 bytes, expires May '97)

    Modifications to the SSL protocol for TLS:


            (9271 bytes, expires May '97)

    Secure FTP over SSL:


            (14238 bytes, expires June '97)

    Addition of Kerberos Cipher Suites to Transport Layer

    Security (TLS):


            (9664 bytes, expires May '97)

    Addition of Shared Key Authentication to Transport Layer

    Security (TLS):


            (16885 bytes, expires May '97)

    The SSL Protocol Version 3.0:


            (147476 bytes, expires May '97)

    The following internet drafts are expired, but are of historical


    Tunneling SSL Through a WWW Proxy (originally



            (9242 bytes, expired December '95)

    SSH Transport Layer Protocol (originally



            (44411 bytes, expired December '96)

    Another useful document is the "Request to the IANA to Regularize

    TLS/SSL Port Numbers"


            (Thu, 13 Feb 1997 01:06:00 -0800):

    It hasn't been truly "disavowed", but weaknesses have been

    discovered such that some people believe that an alternative should

    be found. These weaknesses were found by Dr. Hans Dobbetin

     of the German Information Security Agency

    in a paper called "Cryptanalysis of MD5 Compress" dated May 2, 1996.

    A postscript version of the paper is at


    SSL uses MD5 in combination with SHA for all negotiation. It also

    uses MD5 alone in most negotiated cipher suites. However, in these

    cases it is used with the HMAC construction, which strengthens it

    such that there are no known problems with this construction.

    It has been proposed with TLS to start phasing out all use of MD5.

the numbers 0x36 and 0x5c were chosen?

    The purpose of the construction of a "keyed-MAC" in the form of

    HASH(K,pad2,HASH(K,pad1,text)) was proposed by the cryptographer

    Hugo Krawczyk of IBM as much more secure alternative to traditional

    MACs. In a paper last year he demonstrated a proof that even if the

    hash function was relatively weak (as MD5 has since proven itself to

    be) the addition of the secret key in the function makes it

    significantly more secure. The particular method proposed by

    Krawczyk is now known as an HMAC.

    The particular construction that Netscape uses for SSL is based on

    the original internet-draft of last November, and since that time it

    has been revised such that it XOR the pads rather than appending

    them -- a nice consequence of which is that pads are of the same

    size whether you use MD5 or SHA and it also allows for long keys and

    has some security advantages. Our understanding is that this version

    of HMAC has now been approved and will soon be assigned an RFC. The

    current draft is at


    In the proposals we've seen for the IETF-TLS Working Group the

    scheme SSL 3.0 uses will be replaced by the official RFC HMAC


    The particular pad bytes used are the ones defined in Krawczyk's

    original HMAC paper.  We believe that they are relatively arbitrary.

    The salient property is that half the bits differ: the hamming

    distance between 0x36 and 0x5c is 4 out of a possible 8. We don't

    know if the fact that each of the pads also has a hamming weight of

    4 is significant or not.

    SSLeay is able to do SSL 2.0 client authentication, however, we

    don't know of any browsers that support SSL 2.0 client


    SSLRef 3.0 and SSL Plus are two toolkits that now support SSL 3.0

    client authentication.

    There is no formal conformance testing, but Netscape does currently

    offer an interoperability test server that has been used to test

    conformance with many other implementations of SSL 3.0. This server

    is located at


    VeriSign also has an "Authentic Site" program listing various sites

    that use SSL authentication. Also included is a test page that

    requires that you present a valid VeriSign client certificate.

    More information on the Authentic Site program is at


    Some other sites that client authentication can be tested against




    Security improvements:

    1.  SSL 2.0 is vulnerable to a "man-in-the-middle" attack.  By

    editing the list of ciphersuite preferences in the hello messages,

    an active attacker can invisibly edit the list of ciphersuite

    preferences in the hello messages to invisibly force both client and

    server to use 40-bit encryption.  SSL 3.0 defends against this

    attack by having the last handshake message include a hash of all

    the previous handshake messages.

    2.  SSL 2.0 uses a weak MAC construction, although post-encryption

    seems to stop attacks.  This is fixed in 3.0.

    3.  SSL 2.0 feeds padding bytes into the MAC in block cipher modes,

    but leaves the padding-length field unauthenticated, which could

    allow active attackers to delete bytes from the end of messages.

    This, too, is fixed in 3.0.

    4.  In SSL 3.0, the Message Authentication Hash uses a full 128 bits

    of keying material, even when using an Export cipher.  In SSL 2.0,

    Message Authentication used only 40 bits when using an Export


    Functionality improvements:

    5.  In SSL 2.0, the client can only initiate a handshake at the

    beginning of the connection.  In 3.0, the client can initiate a

    handshake routine, even in the middle of an open session.  A server

    can request that the client start a new handshake.  Thus, the

    parties can change the algorithms and keys used whenever they want.

    6.  SSL 3.0 allows the server and client to send chains of

    certificates. This allows organizations to use a certificate

    hierarchy that is more than two certifications deep.

    7.  SSL 3.0 has a generalized key exchange protocol.  It allows

    Diffie-Hellman and Fortezza key exchanges and non-RSA certificates.

    8.  SSL 3.0 allows for record compression and decompression.

    Backward compatibility:

    9. SSL 3.0 can recognize an SSL 2.0 client hello and fall back to

    SSL 2.0.  An SSL 3.0 client can also generate an SSL 2.0 client

    hello with the version set to SSL 3.0, so SSL 3.0 servers will

    continue the handshake in SSL 3.0, and SSL 2.0 server will cause the

    client to fall back to SSL 2.0.


    10.  SSL 3.0 separates the transport of data from the message layer.

    In 2.0, each packet contained only one handshake message.  In 3.0, a

    record may contain part of a message, a whole message, or several

    messages.  This requires different logic to process packets into

    handshake messages.  Therefore, the formatting of the packets had to

    be completely changed.

    11.  Cipher specifications, handshake messages, and other constants

    are different.


This section contains information on certificates used by the SSL

    Netscape describes their framework for web-based key generation and

    certificate issuing on their web pages at



    Netscape has documented their SSL 2.0 certificate format at


    When establishing a secure connection in SSL, many SSL clients

    applications, including Netscape's Navigator, check the common name

    of the certificate against the name of the site in the URL. If it

    doesn't match, the client application warns the user. Thus the

    preferred format of a common name of an SSL server

    is a simple DNS name like "www.consensus.com".

    To support multiple servers you can use a round-robin DNS to send

    each request for "www.consensus.com" to different IP addresses. As

    Netscape Navigator does not check to see that the IP address matches

    the original domain name (reverse-IP), this will work for each

    round-robin server.

    Netscape's Navigator will also allow for some simple pattern

    matching. Netscape has documented a number of different possibilities

    in their SSL 2.0 Certificate Format web pages at


    Note, however, none of these regular expression/pattern matching

    choices are accepted by VeriSign. In the past they have accepted

    server certificate common names with regular expressions, but these

    are no longer allowed.

    Other CAs may have different policies regarding use of regular

    expressions in common names.

    DNS is not a secure name service, and trying to treat it like one

    could be a security hole. The purpose of checking the common name

    against the URL is to make sure that at least the user's expectation

    of what site the user is visiting is not compromised.

names) for its certificates?

    Yes, Netscape requires distinguished names.

    VeriSign, the default CA (Certificate Authority) used by Netscape

    and most other WWW browsers has a FAQ at


    Entrust has a primer on Web Security with an emphasis on

    Certificate Authorities at


    There is also a good resource of links to a variety of certificate

    technical and policy issue sites available at


    We know of these CAs:

        EuroSign - The European Certification Authority


        COST Computer Security Technologies 

        Thawte Consulting 

        Nortel Entrust,

            Browser Certs 

            Server Certs 

    In addition, we have heard that GE and the US Postal Service may be

    announcing CA services, but we don't have web pages for them.

    There is some support for creating your own CA in SSLeay; there is

    information on how to integrate it with Netscape available at


    The purpose of a Certificate Authority is to bind a public key to

    the common name of the certificate, and thus assure third parties

    that some measure of care was taken to ensure that this binding

    is valid. A measure of a Certificate Authority is their "Policy

    Statement" which states what measures they take for each class of

    certificate they offer to ensure that this binding of identity

    with public key is valid.

    Attribute Certificates are a new type of certificate proposed by

    Netscape. These are signed objects that assert additional properties

    about a particular identity certificate.

    An attribute cert has no associated key pair and consequently cannot

    be used to establish identity. Informally, one can think of them as

    a mechanism for extending the attributes of an identity certificate

    without requiring that the identity certificate be reissued.

    More details of the proposal are at



This section offers specific implementation details of different SSL

clients and servers that are not specific to the protocol.


Sub-section 6.1 is maintained by Eric Greenberg  --

any comments or questions should be sent to him.

Netscape plug-in interfaces available as part of LiveConnect in Netscape

    It will not be in 3.0, but Netscape is looking at it for a future


over by https?

    Navigator 3.0 has an option to allow caching of data fetched

    over SSL connections. The default setting is to not cache data.

    In Navigator 2.0, documents fetched using SSL were cached in the

    same way as non-SSL documents. You could use the "Pragma: no-cache"

    HTTP header to disable caching for a particular page. In Navigator

    1.0 documents fetched with SSL were not cached.

    No, Netscape has never encrypted documents that are stored in the


ndicates that the server supports 6 ciphers for SSL 2.0 and 6
ciphers for SSL 3.0. However, the Encryption|Security Preferences

menu in the server Manager displays only 2 choices for SSL 2.0 and 3

choices for SSL 3.0. How can I select the other choices?

    You have the export version of the server which supports only the

    ciphers displayed. If you want to use the others, you must

    use the US-only (non-export) version.

to unlock certificate databases. Will these be configurable?

    At this point no mechanisms exist in Netscape's Navigator, and

    therefore aging is not configurable. Presumably the future of

    personal certificate databases requires smartcards, but until that

    time aging is an application specific function.

areas? Is Netscape working with any standards bodies or other groups on

    Netscape has been participating in a number of working groups

    interested in standard security APIs. At this point Netscape has not

    adopted a single security API approach or committed to a specific

    proposed standard security API. Eventually Netscape may use all or

    some subset (or perhaps none) of these specific architectures.

    Netscape welcomes customer comments or suggestions on this topic.

"custom" RSA code?  More specifically, is Netscape using BSAFE 3.0?

    BSAFE 3.0 is currently being integrated in all of Netscape's

    products. Netscape has modified portions of the BSAFE API to improve

    efficiency in the heavy load environment of their products, but

    Netscape continues to integrate the upgraded code from RSA as

    soon as practical.

other SSL implementations?

    We can't speak to which specific implementations have been testing

    against our server. Netscape does currently offer an

    interoperability test server that has been used to test conformance

    with many other implementations of SSL 3.0. This server is located




    SSL 3.0 allows for authentication-only (and even encrypt only)

    methods. Algorithm selection is negotiated by the client and the

    server. The Navigators "Security Preferences:General" allow the

    user to define per algorithm overrides for each SSL2 or SSL3


    Yes, even though SSL 3.0 supports encrypt-only (through the

    SSL_DH_anon_WITH_DES_CBC_SHA ciphersuite), there are many possible

    attacks against it, and we recommend against using it. SSL *MUST*

    have strong authentication at the record layer or it becomes open to

    some attacks. It doesn't matter if the application has

    authentication at the application layer.

take care of changing them automatically?

    In the Netscape 2.0 servers, if the server's public key is longer

    than 512 bits, it generates a temporary 512-bit export key at

    start-up time. This key is regenerated only when the server is

    restarted. Netscape does it this way because generating a key can

    take several seconds.

    The 500 transaction limit is only a guideline and largely depends on

    how valuable the information being encrypted is.  For information

    for which you worry about how often the key is regenerated you

    should probably be using something stronger than a 40-bit symmetric

    key anyway.

accepting root certificates for future use?

    Root keys for CA (Certificate Authority) certificates are loaded

    through an automatic process using an SSL connection to a previously

    unknown CA. Also new releases of the Navigator have added additional

    CA root keys.

    Presumably in the future loading a root cert object through a local

    process, such as from disk, LDAP, or other out-of-band mechanism,

    will be a supported addition or in place of the present method of

    connecting to a trusted server and downloading the certificate


 what X.509v3

certificate extensions will the release 3.0 Navigator use?

    The following extensions are supported in some way by Navigator 3.0:



    A button will appear on the Document Info page for server's whose

    certificate (or CA's cert) contains these extension. When the button

    is pressed the CA will be queried via HTTP GET, and will display a

    dialog to indicate to the user if the cert is good or not.


    If a user attempts to use a client certificate that has expired, a

    dialog will be displayed warning them that their cert has expired,

    and if this extension exists, a button will be on the dialog that

    will bring up a window displaying the URL.


    A button will be displayed on the Document Info for server certs

    that contain this extension. When press a window displaying the

    policy URL will be opened.


    This extension is used in place of the common name when it exists to

    verify the domain name of the site.


    A Netscape-specific place for comments.

or CA revocation URL?

    There is no automatic revocation check. As mentioned above, a button

    allowing manual checks is displayed on the Document Info page. This

    feature was added because some people needed revocation, but we did

    not have time to support full CRLs. In a future release we will

    support CRLs, and possibly other forms of revocation technology.


The text for sub-section 6.2 was grabbed from various documents

found at


    Internet Explorer 3.0 provides support for SSL versions 2.0 and 3.0

    and for Private Communication Technology (PCT) version 1.0. It will

    include support for the Transport Layer Security Protocol (TLS),

    which is being considered by IETF.

    Client authentication as implemented by Microsoft Internet Explorer

    3.0 is interoperable with popular Web servers that support secure

    sockets layer (SSL) 3.0 client authentication.

    Microsoft is working to extend the complete set of technology

    components necessary for webmasters to incorporate client

    authentication in their Web applications. This includes extending

    Windows NT(r) Server operating system support for challenge and

    response and the SSL 2.0 protocol used by Microsoft Internet

    Information Server to also include support for client authentication

    through the SSL 3.0 protocol.


This section offers specific details of different SSL development

toolkits that are not specific to the protocol.


This subsection contains information on SSLRef 3.0 which was

codeveloped by Netscape Communications Corp. of Mountain View,

California  and Consensus Development

Corporation of Berkeley, California .

    SSLRef 3.0 is a reference implementation of the SSL (Secure Sockets

    Layer) protocol. SSLRef 3.0 is intended to aid and accelerate

    developers' efforts to provide security within TCP/IP applications.

    It can also be used to qualify other implementations of version 3.0

    of the SSL protocol.

    SSLRef 3.0 consists of a software library, distributed as ANSI C

    source-code, that can be compiled on Windows 95/NT and Solaris

    platforms and then linked into TCP/IP application programs. SSLRef

    3.0 was also designed to be easily ported to a wide variety of

    other platforms and operating systems.

    More information on SSLRef can be found at


    If you are a US citizen you can download SSLRef 3.0 at


    The SSLRef 3.0 distribution includes a license for non-commercial

    use. For commercial licensing, send mail to .

    The SSLRef 3.0 commercial license is Part Number 70-01128-00 and the

    price is $30,000. The license agreement is a flat one-time fee, not

    a recurring royalty.

    SSLRef 3.0 may not be exported. However, the encryption options in

    SSLRef 3.0 can be limited to make exportable products.

    SSLRef 3.0 does not include an RSA/BSAFE license for required

    cryptographic functions. Most users would use BSAFE or RSAREF.

        For BSAFE information contact RSA at


        For RSAREF information contact Consensus Development at



This sub-section contains information specific to the SSL Plus: SSL

Development Corporation of Berkeley, California


    SSLRef 3.0 was written by Netscape Development Corporation and

    Consensus Development Corporation. SSL Plus is a derivative of

    SSLRef 3.0, is fully supported and offers unique value-added


    SSL Plus 1.0 includes support, updates, upgrade to TLS when spec is

    completed, a VeriSign certificate request tool, a "signer" file

    format for storing keys and certificates, is qualified for

    additional platforms, and system integration services are available.

    SSLRef 3.0 offers 5 ciphersuites:

      * Unprotected


      * RSA authenticated, unencrypted, with MD5


      * RSA authenticated with exportable RC4 encryption, and MD5


      * RSA authenticated with DES encryption, and SHA


      * Diffie-Hellman anonymous key exchange with DES encryption,

        and SHA


    SSL Plus 1.0 adds support for an additional 6 ciphersuites (with

    more planned for the future):

      * RSA authenticated, unencrypted, with SHA


      * RSA authenticated with non-exportable RC4 encryption, with

        MD5 or SHA

        (SSL_RSA_WITH_RC4_128_MD5 & SSL_RSA_WITH_RC4_128_SHA)

      * RSA authenticated with Triple-DES encryption, with SHA


      * Diffie-Hellman anonymous key exchange with RC4 encryption,

        with MD5

        (SSL_DH_anon_WITH_RC4_128_MD5 &


      * Diffie-Hellman anonymous key exchange with Triple-DES

        encryption and SHA

        (SSL_DH_anon_WITH_RC4_128_MD5 &


    For more information on SSL Plus features see


    There is no relationship between SSLRef 2.0 and SSL Plus -- SSL Plus

    is based on the SSLRef 3.0 which was not based on SSLRef 2.0.

    A non-commercial license of SSL Plus is not available, only

    commercial licenses. However, evaluation versions are available upon

    signing a non-disclosure and beta test agreement.

    The price for SSL Plus is $40,000, and includes a one-year standard

    support contract. Premium support is available for an additional

    fee.  The license agreement is a flat one-time fee, not a recurring


    SSL Plus toolkit may not be exported. However, products built with

    SSL Plus may limit the encryption options to exportable algorithms

    and thus be able to be exported.

    SSL Plus does not include an RSA/BSAFE license for cryptographic

    functions required.  Most users would use BSAFE or RSAREF:

        For BSAFE information contact RSA at


        For RSAREF information contact Consensus Development at


    Copies of the evaluation NDA and beta agreement, the standard

    product license agreement, and standard support contract for

    SSL Plus are located at


Winsock 2.0? Which Winsock would you recommend using to test our

SSL? Does it matter if Winsock 1.1 or 2.0 architecture is used?

    No -- SSL Plus is designed to be transport independent and work with

    both socket and stream styles of I/O. SSL Plus includes some

    examples of using WinSock 1.1 in the Win32 builds of our sample

    code. However, we recommend that you write your own callback code if

    you want better handling of your I/O than what our sample routines


TCP/IP stack layers?

    The short answer is that you insert SSL Plus between your I/O and

    your application code.

    Basically, you call SSL Plus instead of your read and write. SSL

    Plus does its stuff and calls your callback code to do the I/O. Data

    comes through your I/O routines, through SSL Plus, and then finally

    to your application.  SSL Plus only manages the data flowing through

    the connection; it does not handle setting up and tearing down the

    underlying network connection; your application should open the

    network connection, then hand it off to SSL Plus for SSL handshaking

    and data transfer. (This step is not shown in the diagram).



        | Application |



             | I/O Calls



        | WinSock     |



             | TCP Calls



        | Internet    |


    SSL Plus:


        | Application |



             | SSL I/O Calls


         -------------     I/O Callbacks   --------------------

        | SSL Plus    | <---------------->| Your Callback Code |

         -------------                     --------------------


                                                    | I/O Calls



                                              | WinSock     |



                                                    | TCP Calls



                                              | Internet    |


architecture, the application need only chose an appropriate SSL

enabled service provider. Does SSL Plus support this?

    As you noted, with WinSock 2.0 there is some discussion of

    functionality that allows you to create a module that you could add

    to WinSock 2.0.

    At this time we do not believe that this functionality is actually

    shipping (as Microsoft was supporting PCT but is now supporting

    SSL 3), but we do know that it is part of their plans. See the

    MS-ISF (Microsoft Internet Security Framework) description at


    We can't speak to when or if Microsoft will add it to their system

    software, or if another third-party offers such a module.

    Meanwhile, there has been some discussion on what changes might be

    required under WinSock 2.0 to do SSL located at


    In the future (post version 1.1, see our features page) we may offer

    either more robust sample callback code for WinSock 1.1 and/or 2, or

    we may actually write our own WinSock 1.1 substitute or 2.0 module

    that you call as you would call WinSock and avoid the callbacks

    all together. Neither would be available before the end of the year.

    SSL Plus 1.0 includes support for processor yielding during

    cryptographic operations. Because developers provide their own I/O

    routines, they can do yielding during I/O. Our examples do not

    demonstrate I/O yielding.

"SSL_RSA_EXPORT_WITH_RC4_40_MD5" -- where are they defined?

    They are found in include/cryptype.h, but are actually defined

    by the SSL 3.0 spec.

    In the file ciphers.c there is an array of values and implementation

    pointers for supported cipher suites.

    Yes. The order affects the preference; in general, the highest one

    on the client's list which the server supports will be selected.

    No, it is configured at compile time. We will be adding runtime

    support in the near future because it will be needed for future test


    Not at this time. If there is a specific customer requirement, or if

    a compression cipher suite is defined we expect to support it in the

    future, but otherwise we have no plans here.

copied, encrypted, then enqueued on the SSL write queue. The function

then returns. What thread services the write queue? How is the

thread created?

    The write queue is serviced by the public function called

    SSLServiceWriteQueue(). It is called in a number of places in

    ssltrspt.c, including with every call to SSLWrite(). Data to be

    written is sent to the I/O layer as you exit out of the write

    function (for example, right near the bottom of SSLWrite).

    If SSLWrite() returns SSLWouldBlockError, then make a call to

    SSLServiceWriteQueue() to service the write queue. (You could

    instead make a call to SSLWrite() with more data to be written, but

    this is unlikely.)

    The write queue is not serviced by a separate execution thread. The

    write queue mechanism was designed to support non-blocking I/O

    without undue overhead.

the length argument should be replaced with the number of bytes

actually read. In practice, this doesn't seem to be happening. What

am I doing wrong?

    The difficulty is that it's hard for SSL to precisely emulate the

    behavior of Unix-style socket calls.

    The problem is that you are using SSL Plus in its blocking mode; if

    you return SSLWouldBlock from your I/O Read callback, the library

    will return the data it has along with the SSLWouldBlock error.

    The best way to solve this is to always know how much data you're

    waiting for and request exactly that much. I know this doesn't work

    with a lot of free-form Internet protocols.

    Alternatively, you would like the call to block until it gets some

    data, then return it to you, even if it's less than 512 bytes.

    Ideally, you'd like to do this without busy-looping the CPU waiting

    for data. The best way to do this using SSL Plus is to write a

    wrapper for SSLRead() which does the following:

        * Make a blocking select() call until there is some data

          available on the TCP/IP connection over which you're speaking

          SSL. This will cause you to block in a friendly way until data


        * Call SSLRead(). If zero bytes are returned from the read,

          loop and do the select() again. Otherwise, return whatever

          came back.

        * Make your Read() callback non-blocking. The easiest thing to

          do is to check how much data is available on the incoming

          connection and return SSLWouldBlockErr if you can't completely

          fulfill the request. (You can optionally read what data there

          is and return it first; this won't affect functionality).

    This will result in the following behavior:

    1. Your program will block gracefully in the select() call until

       something arrives on the connection.

    2. You will then ask SSL Plus to read some data.

    3. SSL Plus will ask the Read() callback to read the header of the

       next record (3 or 5 bytes).

    4. The Read() callback will fulfill that, if possible

    5. SSL Plus will ask to read the body of the record (whose length

       will be equal to how much data was sent by the other side, plus

       MAC and encryption padding).

    6. The Read() callback will fulfill that, if possible.

    7. If the amount of data received is greater than or equal to how

       much was requested in 2., the data will be returned

    8. Otherwise, go back to 3.

    What will happen in practice looks something like this: because the

    SSL peer on the other end of the connection generates record layer

    records monolithically, and they're relatively small, the header and

    content of a record will arrive at your machine all together. Thus,

    when your select() call returns, you will be able to successfully

    read a header and body without blocking. When SSL Plus goes to read

    another one, your Read() callback will see that there's no data

    available on the connection (assuming another record hasn't arrived)

    and return SSLWouldBlockErr. SSL Plus will then return the data it

    has received and the error SSLWouldBlockErr; you can return that

    data as a partial completion of the desired read.

    If a partial record arrives, your select() will wake up, but SSL

    Plus won't be able to decrypt and check a complete record before the

    Read() callback returns SSLWouldBlockErr; thus, your read will

    return with zero bytes returned. Since this isn't the behavior your

    client expects, you should select() again until more data arrives,

    hopefully completing the record.

    Long term (SSL Plus 1.1 time frame) we'd like to develop a more

    elegant solution and API to this type of problem. We welcome


    There is no information stored in the session database which can't

    be passed between processes. Specifically, there is no pointer

    indirection. Of course, you'll have to figure out how to pass

    session database records (and their changes or deletions) between

    processes; that is not part of SSL Plus.


This sub-section contains information specific to the SSLeay

toolkit developed by Eric Young 

    There is a very complete SSLeay FAQ at:



..Christopher Allen                  Consensus Development Corporation..

..                 1563 Solano Avenue #355..

..                                             Berkeley, CA 94707-2116..

..Home of "SSL Plus:                      o510/559-1500  f510/559-1505..

..  SSL 3.0 Integration Suite(tm)" ..