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 restricions 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
    sufficient information regarding the request such that it can fully
    log and/or evaluate the request in order to allow or deny it.

    A more secure approach is to use a firewall that supports the SSL
    Tunnelling CONNECT extension method as described in the Internet
    draft
        <ftp://ftp.internic.net/internet-drafts/draft-luotonen-ssl-tunneling-02.txt>

    In the case of 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, and once
    the handshake occurs the proxy acts identically to a SOCKS gateway.
    This will allow the firewall to monitor the requests, but not the
    traffic itself.

    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 user agent is sent (for example,
          "Mozilla/3.0/Macintosh").

        * A proxy authorization is sent which allows you 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 to the
          firewall (or anything else). 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 this SSL Tunnelling CONNECT
    extension methods for tunnelling SSL, and its use is described in
        <http://developer.netscape.com/library/one/sdk/proxy/unixguide/ssl-tunl.htm>

    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, as only server authentication is
    available of the remote sites, however you gain the ability for
    client authentication to the proxy. It's up to the administrator as
    to which is more important, until such time as a better solution
    arises. The description of this feature in the Netscape Proxy Server
    is at
         <http://developer.netscape.com/library/one/sdk/proxy/unixguide/ssl-tunl.htm#518342>

    Reverse proxies are a solution for serving secure content inside
    a firewall to outside clients. For the Netscape Proxy Server
    this is described at
        <http://developer.netscape.com/library/one/sdk/proxy/unixguide/revpxy.htm>

    It is possible for a proxy server to hold both client and server
    keys for its internal clients, allowing SSL sessions to be carried
    out twice (once between the client and proxy server, and again
    between the proxy server and the secure server) and thus allow the
    proxy server 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 above, or simply to create a secure
    tunnel between sites across an unsecure network. This is really
    multiple sessions of SSL, and not really an end-to-end secure
    connection. This means that 2.1 beta has full SSL support (as
    opposed to just SSL tunneling) and 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 when used in this fashion, you lose the transparency
    of the proxy and get multiple segments of secure connections,
    rather than a single end-to-end connection.


3.3) Since SSL is supposed to withstand replay attacks, does this
preclude proxy servers from caching the data?

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


3.4) What ports does SSL use?

    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, seperate 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


3.5) Do you have any information on sftp?

    The name sftp conflicts with a prococol called simple file transfer
    protocol. As far as we can tell ftps has not been applied for, nor
    does it appear in the SSL 3.0 specification.


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

4) SSL PROTOCOL QUESTIONS

This section contains more detailed information on the SSL protocol.


4.1) Does SSL protect users from replay attack by eavesdroppers or
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.


4.2) The record protocol sits underneath the other protocols, right?
It appears that information can be sent only in blocks. Does
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.


4.3) It appears that there is no way in the SSL protocol to
resynchronize blocks if they get out of synch. Is that true?

    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.


4.4) Why does SSL3 have Diffie-Hellman encryption at all? What good is
it? 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
secret bits across. Why have DH as well?

    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.


4.5) What is TLS? What happened at these meetings? Has anything come 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 TLS
    working group meeting was June 1996 in Montreal. (Before then it was
    an unofficial BOF "birds of a feather" group.)

    The discussion list for IETF-TLS is at IETF-TLS@W3.ORG. You
    subscribe and unsubscribe by sending to IETF-TLS-REQUEST@W3.ORG with
    subscribe or unsubscribe in the SUBJECT of the message. Archives of
    the list are at
        <http://lists.w3.org/Archives/Public/ietf-tls>

    There was a day-long pre-Montreal meeting last May in Palo Alto, the
    minutes of which are at
        <http://lists.w3.org/Archives/Public/ietf-tls/msg00185.html>

    These minutes give a fairly complete list of technical issues and
    possible solutions.

    The minutes for the official TLS working group meeting in Montreal
    are in two messages at
        <http://lists.w3.org/Archives/Public/ietf-tls/msg00217.html>
        <http://lists.w3.org/Archives/Public/ietf-tls/msg00212.html>


4.6) When did MD5 get "disavowed"?

    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
    <dobbertin@skom.rhein.de> 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
        <http://www.cs.ucsd.edu/users/bsy/dobbertin.ps>.

    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.


4.7) Can anyone explain to me the purpose of pad1 and pad2, and why
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
        <ftp://ftp.internic.net/internet-drafts/draft-ietf-ipsec-hmac-md5-00.txt>

    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
    technique.

    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.


4.8) Are you aware of any SSL toolkits supporting client authentication?

    SSLeay is able to do SSL 2.0 client authentication, however, we
    don't know of any browsers that support SSL 2.0 client
    authentication.

    SSLRef 3.0 and SSL Plus are two toolkits that now support SSL 3.0
    client authentication.

4.9) What SSL implementations should I test against?

    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
        <https://www3.netscape.com/>

    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
        <http://www.verisign.com/authentic/>

    Some other sites that client authentication can be tested against
    are
        <https://www.bassandco.com/secure/>
        <https://in-103.infospace.com/>


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

5) CERTIFICATE RELATED QUESTIONS

This section contains information on certificates used by the SSL
protocol.


5.1) How does Netscape handle client certificates in Navigator 3.0?

    Netscape describes their framework for web-based key generation and
    certificate issuing on their web pages at
        <http://home.netscape.com/eng/security/certs.html>


5.2) What is the format of the SSL certificates used by Netscape
Navigator?

    Netscape has documented their SSL 2.0 certificate format at
        <http://home.netscape.com/newsref/std/ssl_2.0_certificate.html>.


5.3) I am distributing load on several different web servers and I
don't want to have to have a different certificate for each. How can
I do this?

    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