GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


archive: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 <Christopher@consensus.com>
                  Consensus Development Corporation
                      <http://www.consensus.com/>
       The latest edition of this FAQ can always be found at:
        <http://www.consensus.com/security/ssl-talk-faq.html>
         <http://www.consensus.com/security/ssl-talk-faq.txt>
        <ftp://ftp.consensus.com/pub/security/ssl-talk-faq.txt>
(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
  herein.
  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 <TimD@consensus.com>
      Charles Neerdaels <chuckn@netscape.com>
      Eric Greenberg <ericg@netscape.com>
      Bruce Schneier <schneier@counterpane.com>
      Tom Weinstein <tomw@netscape.com>
      Jonathan Zamick <JonathanZ@consensus.com>
  Remaining ambiguities, errors, and difficult-to-read passages are
  not their fault. :)

CONTENTS

  1) THE SSL-TALK LIST
  2) GENERAL SSL QUESTIONS
  3) USING PROXIES, GATEWAYS AND FIREWALLS WITH SSL
  4) SSL PROTOCOL QUESTIONS
  5) CERTIFICATE RELATED QUESTIONS
  6) SSL IMPLEMENTATION QUESTIONS
      6.1) NETSCAPE QUESTIONS
      6.2) MICROSOFT QUESTIONS
  7) SSL TOOLKIT QUESTIONS
      7.1) SSLREF QUESTIONS
      7.2) SSL PLUS QUESTIONS
      7.3) SSLEAY QUESTIONS

1) THE SSL-TALK LIST

This section contains information about the SSL-Talk list.

1.1) What is 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.

1.2) What is SSL?

  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
      <http://home.netscape.com/eng/ssl3/index.html>

1.3) How do I subscribe to SSL-Talk?

  Send mail to the email address <ssl-talk-request@netscape.com>
  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.

1.4) Once I am subscribed, how to I send mail to SSL-Talk?

  Any mail addressed to <ssl-talk@netscape.com> will be sent to *all*
  members of the SSL-Talk mailing list.

1.5) How do I unsubscribe from SSL-Talk?

  To remove your name from the ssl-talk list send mail to the address
  <ssl-talk-request@netscape.com> with the *subject* being the single
  word UNSUBSCRIBE. You need not put any text in the body of your
  message.
  Please do not send requests to the SSL-Talk list.

1.6) I've tried unsubscribing several times from SSL-Talk but it doesn't

seem to work – what can I do?

  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
  address.
  Another common problem is that the subdomain of your mailer has
  changed, for example, "mail.consensus.com" has been renamed
  "server.consensus.com".
  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 <sslref@netscape.com>
  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.

1.7) Where is SSL-Talk archived?

  There is a hypertext archive of the list at
      <http://coho.stanford.edu/~hassan/hymail/ssl/current/>
  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.

1.8) May I post commercial announcements regarding SSL products?

  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
        release;
  • 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.

2) GENERAL SSL QUESTIONS

This section contains general information on SSL and the SSL

protocol.

2.1) What is the current version of the SSL protocol?

  The current version is 3.0, as documented at
      <http://home.netscape.com/eng/ssl3/index.html>
  Errata to the SSL 3.0 Specification is periodically posted on
  the SSL discussion list, and is available at
      <http://home.netscape.com/eng/ssl3/ssl-errata.html>
  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):
      <ftp://ds.internic.net/internet-drafts/
          draft-ietf-tls-ssl-version3-00.txt>
  The previous version of SSL, version 2.0 is documented at
      <http://home.netscape.com/newsref/std/SSL_old.html>

2.2) Where can I get a "management overview" of SSL and web security?

  There is a brief overview and FAQ on Netscape security called
  "On Internet Security", available at
      <http://home.netscape.com/info/security-doc.html>
  There is a brief introduction on how Netscape uses public key
  cryptography in the SSL protocol called "Using Public Key
  Cryptography" at
      <http://home.netscape.com/newsref/ref/rsa.html>
  An overview on certificates and VeriSign's Digital IDs is at
      <http://digitalid.verisign.com/crp_intr.htm>.

2.3) Where can I get a more in-depth look at SSL and web security?

  The online version of the technical specifications for the SSL 3.0
  protocol is at
      <http://home.netscape.com/eng/ssl3/ssl-toc.html>
  A PostScript version is also available at
      <http://home.netscape.com/eng/ssl3/index.html>
  A FAQ for SSLeay, a freeware implementation of the SSL 2.0 protocol
  is available at
      <http://www.psy.uq.oz.au/~ftp/Crypto/>
  A rather broad list of public key related documents, with a focus on
  certificates and standards can be found at
      <http://www.zoo.net/~marcnarc/PKI/References.htm>

2.4) What software supports SSL 2.0 and SSL 3.0?

  WebCompare offers a list of security features supported by over 100
  different servers and clients at
      <http://webcompare.iworld.com/compare/security.shtml>
  Currently it is not very accurate. If you know of changes please
  contact David Strom <david@strom.com>.

2.5) I'm confused by all the different laws that different countries

have on export and import of cryptographic applications. Is there

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
      <http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm>
  RSA Data Security, Inc. offers an Acrobat version of their
  "Frequently Asked Questions: Export" at
      <http://www.rsa.com/PUBS/exp_faq.pdf>
  Other information on US export issues can be found on
  the Electronic Frontier Foundation's web site at
      <http://www.eff.org/>
  Canadian export issues are converted at
      <http://insight.mcmaster.ca/org/efc/pages/doc/crypto-export.html>

3) USING PROXIES, GATEWAYS AND FIREWALLS WITH SSL

This section contains information on how the SSL protocol interacts

with proxy servers, security gateways, and firewalls.

3.1) What exactly is the meaning of "proxy" mentioned in the

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.

3.2) How does SSL work through (application level) firewalls,

gateways and proxy servers?

  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
  draft
      <http://www.netscape.com/newsref/std/tunneling_ssl.html>
  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,
        "Mozilla/3.0/Macintosh").
  • 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
      <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;
  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
      <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. 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
  connection.
  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.

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, 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
  1. —— ——- ———–
      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 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.

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 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
      <http://www.consensus.com/ietf-tls/>
  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
      <http://www.imc.org/ietf-tls/mail-archive/>
  The minutes for the last IETF-TLS Working Group meeting in
  San Jose in December of '96 are at
      <http://www.consensus.com/ietf-tls/minutes-9612.txt>
  The minutes for the IETF-TLS Working Group meeting in Montreal in
  June of '96 are in two messages at:
      <http://www.consensus.com/ietf-tls/minutes-9606-1.txt>
      <http://www.consensus.com/ietf-tls/minutes-9606-2.txt>
  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
      <http://www.consensus.com/ietf-tls/minutes-9605.txt>
  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):
      <draft-ietf-tls-protocol-01.txt>
          (157637 bytes, expires August '97)
  The TLS Protocol 1.0 (Old Version 00):
      <draft-ietf-tls-protocol-00.txt>
          (147284 bytes, expires May '97)
  Modifications to the SSL protocol for TLS:
      <draft-ietf-tls-ssl-mods-00.txt>
          (9271 bytes, expires May '97)
  Secure FTP over SSL:
      <draft-murray-auth-ftp-ssl-00.txt>
          (14238 bytes, expires June '97)
  Addition of Kerberos Cipher Suites to Transport Layer
  Security (TLS):
      <draft-ietf-tls-kerb-cipher-suites-00.txt>
          (9664 bytes, expires May '97)
  Addition of Shared Key Authentication to Transport Layer
  Security (TLS):
      <draft-ietf-tls-passauth-00.txt>
          (16885 bytes, expires May '97)
  The SSL Protocol Version 3.0:
      <draft-ietf-tls-ssl-version3-00.txt>
          (147476 bytes, expires May '97)
  The following internet drafts are expired, but are of historical
  interest:
  Tunneling SSL Through a WWW Proxy (originally
  <draft-luotonen-ssl-tunneling-02.txt>)
      <http://www.consensus.com/ietf-tls/ssl-tunneling-02.txt>
          (9242 bytes, expired December '95)
  SSH Transport Layer Protocol (originally
  <draft-ietf-tls-ssh-00.txt>)
      <http://www.consensus.com/ietf-tls/tls-ssh-00.txt>
          (44411 bytes, expired December '96)
  Another useful document is the "Request to the IANA to Regularize
  TLS/SSL Port Numbers"
      <http://www.consensus.com/ietf-tls/tls-ssl-port-requests.txt>
          (Thu, 13 Feb 1997 01:06:00 -0800):

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/>

4.10) What is the difference between SSL 2.0 and 3.0?

  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
  cipher.
  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.
  Other:
  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.

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
  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
      <http://home.netscape.com/newsref/std/ssl_2.0_certificate.html>
  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.

5.4) When comparing a URL against the common name of the certificate,

why don't you do a reverse-DNS lookup?

  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.

5.5) Does Netscape require hierarchical naming (that is, distinguished

names) for its certificates?

  Yes, Netscape requires distinguished names.

5.6) Where can I get more information on certificates?

  VeriSign, the default CA (Certificate Authority) used by Netscape
  and most other WWW browsers has a FAQ at
      <http://digitalid.verisign.com/id_faqs.htm>
  Entrust has a primer on Web Security with an emphasis on
  Certificate Authorities at
      <http://www.nortel.com/entrust/certificates/browcert.html>
  There is also a good resource of links to a variety of certificate
  technical and policy issue sites available at
      <http://www.zoo.net/~marcnarc/PKI/References.htm>.

5.7) What other CAs exist besides VeriSign?

  We know of these CAs:
      EuroSign - The European Certification Authority
          <http://eurosign.com/>
      COST Computer Security Technologies <http://www.cost.se/>
      Thawte Consulting <http://www.thawte.com/certs/>
      CompuSource <http://www.compusource.co.za/id/personal/
      Nortel Entrust,
          Browser Certs <http://www.nortel.com/entrust/certificates/
              browcert.html>
          Server Certs <http://www.nortel.com/entrust/certificates/
              servcert.html>
  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.

5.8) How do I set up my own Certificate Authority?

  There is some support for creating your own CA in SSLeay; there is
  information on how to integrate it with Netscape available at
      <http://www.webvision.com/developers/casetup.html>

5.9) What criteria should I use in deciding between one CA and another?

  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.

5.10) What are Attribute Certificates?

  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
      <http://lists.w3.org/Archives/Public/ietf-tls/msg00796.html>

6) SSL IMPLEMENTATION ISSUES

This section offers specific implementation details of different SSL

clients and servers that are not specific to the protocol.


6.1) NETSCAPE QUESTIONS

Sub-section 6.1 is maintained by Eric Greenberg ericg@netscape.com

any comments or questions should be sent to him.

6.1.1) Will SSL 3.0 functionality be available to Java applets via the

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

3.0?

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

6.1.2) Does the Netscape browser cache on disk data that has been sent

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.

6.1.3) Is the cached data encrypted using some key?

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

6.1.4) The Help Information for Netscape's Enterprise 2.0 server

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

6.1.5) What mechanisms will be available for "aging" passphrases used

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.

6.1.6) Is Netscape adopting any open standards for APIs in these

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

such APIs? Is there any word on the emerging security architectures,

such as Microsoft's Crypto-API, RSA's LOCT, or GSS-API?

  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.

6.1.7) Does Netscape use "regular" RSA libraries (such as BSAFE) or

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

6.1.8) Will Netscape client authentication be interoperable with

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

6.1.9) How might Netscape offer more "cryptographic flexibility,"

such as selection of algorithms and authentication without

encryption?

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

6.1.10) Isn't encrypt-only SSL open to "man-in-the-middle" attacks?

  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.

6.1.11) Are the 512-bit RSA keys used by exportable applications

generated on the fly by the server? How often are they changed? (The

spec recommends every 500 transactions.) Does the Netscape server

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.

6.1.12) What are the plans for mechanisms for adding root keys and

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

6.1.13) With regard to the certificate extensions documentation at

<http://home.netscape.com/eng/security/certs.html> what X.509v3

certificate extensions will the release 3.0 Navigator use?

  The following extensions are supported in some way by Navigator 3.0:
      netscape-revocation-url
      netscape-ca-revocation-url
  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.
      netscape-cert-renewal-url
  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.
      netscape-ca-policy-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.
      netscape-ssl-server-name
  This extension is used in place of the common name when it exists to
  verify the domain name of the site.
      netscape-comment
  A Netscape-specific place for comments.

6.1.14) Does the Navigator actually use the revocation URL

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.

6.2) MICROSOFT QUESTIONS

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

found at

      <http://www.microsoft.com/intdev/security/>

6.2.1) Which of Microsoft's products will support SSL?

  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.

6.2.2) Which Microsoft products support Client Authentication?

  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.

7) SSL TOOKIT QUESTIONS

This section offers specific details of different SSL development

toolkits that are not specific to the protocol.


7.1) SSLREF QUESTIONS

This subsection contains information on SSLRef 3.0 which was

codeveloped by Netscape Communications Corp. of Mountain View,

California <http://home.netscape.com/> and Consensus Development

Corporation of Berkeley, California <http://www.consensus.com/>.

7.1.1) What is SSLRef 3.0?

  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
      <http://home.netscape.com/newsref/std/sslref.html>
  If you are a US citizen you can download SSLRef 3.0 at
      <http://wwwus.netscape.com/eng/US-Current/>

7.1.2) How can I license SSLRef 3.0? What does it cost? With what

restrictions?

  The SSLRef 3.0 distribution includes a license for non-commercial
  use. For commercial licensing, send mail to <sslref@netscape.com>.
  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
          <http://www.rsa.com/>
      For RSAREF information contact Consensus Development at
          <http://www.consensus.com/rsaref/>

7.2) SSL PLUS QUESTIONS

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

3.0 Integration Suite™ software toolkit developed by Consensus

Development Corporation of Berkeley, California

<http://www.consensus.com/>.

7.2.1) What is the relationship between SSLRef and SSL Plus?

  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
  features.
  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
      (SSL_NULL_WITH_NULL_NULL)
  • RSA authenticated, unencrypted, with MD5
      (SSL_RSA_WITH_NULL_MD5)
  • RSA authenticated with exportable RC4 encryption, and MD5
      (SSL_RSA_EXPORT_WITH_RC4_40_MD5)
  • RSA authenticated with DES encryption, and SHA
      (SSL_RSA_WITH_DES_CBC_SHA)
  • Diffie-Hellman anonymous key exchange with DES encryption,
      and SHA
      (SSL_DH_anon_WITH_DES_CBC_SHA)
  SSL Plus 1.0 adds support for an additional 6 ciphersuites (with
  more planned for the future):
  • RSA authenticated, unencrypted, with SHA
      (SSL_RSA_WITH_NULL_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
      (SSL_RSA_WITH_3DES_EDE_CBC_SHA)
  • Diffie-Hellman anonymous key exchange with RC4 encryption,
      with MD5
      (SSL_DH_anon_WITH_RC4_128_MD5 &
       SSL_DH_anon_WITH_3DES_EDE_CBC_SHA)
  • Diffie-Hellman anonymous key exchange with Triple-DES
      encryption and SHA
      (SSL_DH_anon_WITH_RC4_128_MD5 &
       SSL_DH_anon_WITH_3DES_EDE_CBC_SHA)
  For more information on SSL Plus features see
      <http://www.consensus.com/SSLPlus/sslplus_stats.html>

7.2.2) What is the relationship with SSL Plus and SSLRef 2.0?

  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.

7.2.3) How can I license SSL Plus? What does it cost? With what

restrictions?

  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
  royalty.
  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
          <http://www.rsa.com/>
      For RSAREF information contact Consensus Development at
          <http://www.consensus.com/rsaref/>
  Copies of the evaluation NDA and beta agreement, the standard
  product license agreement, and standard support contract for
  SSL Plus are located at
      <http://www.consensus.com/sslplus/sslplus_contracts.html>

7.2.4) Is there any relationship between SSL Plus and Winsock 1.1 or

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

7.2.5) How does the data flow within the application, WinSock, SSL,

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).
  Normal:
  1. ————
      | Application |
  1. ————
           ^
           | I/O Calls
           v
  1. ————
      | WinSock     |
  1. ————
           ^
           | TCP Calls
           v
  1. ————
      | Internet    |
  1. ————
  SSL Plus:
  1. ————
      | Application |
  1. ————
           ^
           | SSL I/O Calls
           v
  1. ———— I/O Callbacks ——————–
      | SSL Plus    | <---------------->| Your Callback Code |
  1. ———— ——————–
                                                  ^
                                                  | I/O Calls
                                                  v
  1. ————
                                            | WinSock     |
  1. ————
                                                  ^
                                                  | TCP Calls
                                                  v
  1. ————
                                            | Internet    |
  1. ————

7.2.6) A part of my impression is that with the WinSock 2.0

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
      <http://www.microsoft.com/intdev/security/>
  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
      <http://home.netscape.com/newsref/std/ssl_integration.html>
  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.

7.2.7) Does SSL Plus support yielding?

  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.

7.2.8) I don't understand the nomenclatures of constants such as

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

7.2.9) Where are these cipher suites defined?

  In the file ciphers.c there is an array of values and implementation
  pointers for supported cipher suites.

7.2.10) Can I change the order of the values in ciphers.c?

  Yes. The order affects the preference; in general, the highest one
  on the client's list which the server supports will be selected.

7.2.11) Can this be done programmatically in the API?

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

7.2.12) Does SSL Plus support compression?

  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.

7.2.13) In sslrec.c function SSLWriteRecord(), the data buffer is

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.

7.2.14) When I call SSLRead(), according to the docs, on returning,

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
        arrives.
  • 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
  suggestions.

7.2.15) If session cache is stored in a database, can multiple Unix

processes share the same session data?

  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.

7.3) SSLEAY QUESTIONS

This sub-section contains information specific to the SSLeay

toolkit developed by Eric Young eay@mincom.com

7.3.1) Where is the SSLeay FAQ?

  There is a very complete SSLeay FAQ at:
      <http://www.psy.uq.oz.au/~ftp/Crypto/>

..Christopher Allen Consensus Development Corporation..

..ChristopherA@consensus.com 1563 Solano Avenue #355..

.. Berkeley, CA 94707-2116..

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

.. SSL 3.0 Integration Suite™" <http://www.consensus.com/SSLPlus/>..

/data/webs/external/dokuwiki/data/pages/archive/internet/sslfaq.103.txt · Last modified: 2002/07/11 02:53 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki