home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / computer-security / ssl-talk-faq < prev    next >
Encoding:
Internet Message Format  |  2004-04-18  |  61.2 KB

  1. Path: senator-bedfellow.mit.edu!dreaderd!not-for-mail
  2. Message-ID: <computer-security/ssl-talk-faq_1082200966@rtfm.mit.edu>
  3. Supersedes: <computer-security/ssl-talk-faq_1079601013@rtfm.mit.edu>
  4. Expires: 31 May 2004 11:22:46 GMT
  5. From: Shannon Appel <SAppel@consensus.com>
  6. Subject: [SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.1.1
  7. Followup-To: poster
  8. Approved: news-answers-request@MIT.EDU
  9. Organization: Consensus Development Corporation, Berkeley, CA, US; http://www.consensus.com/
  10. Newsgroups: alt.security,comp.security.misc,comp.protocols,sci.crypt,comp.infosystems.www.misc,alt.answers,comp.answers,news.answers,sci.answers
  11. Distribution: world
  12. X-Last-Updated: 1998/11/16
  13. Summary: This document is a summary of FAQ (Frequently Asked
  14.     Questions) found on the SSL-Talk discussion list regarding technical
  15.     implementation issues of the Secure Sockets Layer protocol, a
  16.     transport level security protocol used for securing web servers and
  17.     clients (such as Netscape Navigator) and other internet
  18.     applications.
  19. Originator: faqserv@penguin-lust.MIT.EDU
  20. Date: 17 Apr 2004 11:27:27 GMT
  21. Lines: 1533
  22. NNTP-Posting-Host: penguin-lust.mit.edu
  23. X-Trace: 1082201247 senator-bedfellow.mit.edu 576 18.181.0.29
  24. Xref: senator-bedfellow.mit.edu alt.security:65345 comp.security.misc:93816 sci.crypt:263188 comp.infosystems.www.misc:69329 alt.answers:72479 comp.answers:56868 news.answers:269860 sci.answers:15944
  25.  
  26. Content-type: text/x-usenet-FAQ;
  27.     version=1.1;
  28.     title="[SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.1.1"
  29. Archive-name: computer-security/ssl-talk-faq
  30. Posting-Frequency: monthly
  31. Last-modified: Nov 16 12:00:00 PST 1998
  32. Version: 1.1.1 (text) Mon Nov 16 12:00:00 PST 1998
  33. URL: http://www.consensus.com/security/ssl-talk-faq.html
  34. Copyright-Notice: (c) Copyright 1996-1998 by Consensus Development Corporation -- All Rights Reserved
  35.  
  36.                               SSL-Talk FAQ
  37.             Secure Sockets Layer Discussion List FAQ v1.1.1
  38.  
  39.                       Mon Nov 16 12:00:00 PST 1998
  40.  
  41.                            FAQ Maintained by:
  42.                   Shannon Appel <SAppel@consensus.com>
  43.                     Consensus Development Corporation
  44.                         <http://www.consensus.com/>
  45.  
  46.          The latest edition of this FAQ can always be found at:
  47.           <http://www.consensus.com/security/ssl-talk-faq.html>
  48.            <http://www.consensus.com/security/ssl-talk-faq.txt>
  49.  
  50.   Copyright (c) 1996-1998 Consensus Development Corporation - All Rights 
  51.   Reserved
  52.  
  53.     ********************************************************************* 
  54.     Due to the November 15, 1998 dissolution of the SSL-Talk mailing 
  55.     list, this will be the last version of this FAQ in its current form. 
  56.     It will be replaced by a more general TLS & SSL FAQ in the near 
  57.     future that is not tied to any mailing list or newsgroup. 
  58.     *********************************************************************
  59.  
  60.     All information contained in this work is provided "as is." All
  61.     warranties, expressed, implied or statutory, concerning the accuracy
  62.     of the information of the suitability for any particular use are
  63.     hereby specifically disclaimed. While every effort has been taken to
  64.     ensure the accuracy of the information contained in this work,
  65.     the authors assume(s) no responsibility for errors or omissions or
  66.     for damages resulting from the use of the information contained
  67.     herein.
  68.  
  69.     This work may be copied in any printed or electronic form for
  70.     non-commercial, personal, or educational purposes if the work is not
  71.     modified in any way, provided that the copyright notice, the notices 
  72.     of any other author included in this work, and this copyright 
  73.     agreement appear on all copies.
  74.  
  75.     Consensus Development Corporation also grants permission to
  76.     distribute this work in electronic form over computer networks for
  77.     other purposes, provided that, in addition to the terms and
  78.     restrictions set forth above, Consensus Development Corporation
  79.     and/or other cited authors are notified and that no fees are charged
  80.     for access to the information in excess of normal online charges
  81.     that are required for such distribution.
  82.  
  83.     This work may also be mentioned, cited, referred to or described
  84.     (but not copied or distributed, except as authorized above) in
  85.     printed publications, on-line services, other electronic
  86.     communications media, and otherwise, provided that Consensus
  87.     Development Corporation and any other cited author receives
  88.     appropriate attribution.
  89.  
  90.     Comments about, suggestions about, or corrections to this document
  91.     are welcomed. If you would like to ask us to change this document
  92.     in some way, the method we appreciate most is for you to actually
  93.     make the desired modifications to a copy of the posting, and then to
  94.     send us the modified document, or a context diff between the posted
  95.     version and your modified version (if you do the latter, make sure
  96.     to include in your mail the "Version:" line from the posted
  97.     version). Submitting changes in this way makes dealing with them
  98.     easier for us and helps to avoid misunderstandings about what you
  99.     are suggesting.
  100.  
  101.     Many people have in the past provided feedback and corrections; we
  102.     thank them for their input.
  103.  
  104.     In particular, many thanks to:
  105.  
  106.         Christopher Allen <ChristopherA@consensus.com>
  107.         Shannon Appel <SAppel@consensus.com>
  108.         Nelson Bolyard <NelsonB@netscape.com>
  109.         Tim Dierks <TimD@consensus.com>
  110.         Eric Greenberg <ericg@netscape.com>
  111.         Charles Neerdaels <chuckn@netscape.com>
  112.         Bruce Schneier <schneier@counterpane.com>
  113.         Tom Weinstein <tomw@netscape.com>
  114.         Jonathan Zamick <JonathanZ@consensus.com>
  115.  
  116.     Remaining ambiguities, errors, and difficult-to-read passages are
  117.     not their fault. :)
  118.     
  119. ------------------------------
  120.  
  121. CONTENTS
  122.  
  123.     1) THE SSL-TALK LIST
  124.     2) GENERAL SSL QUESTIONS
  125.     3) USING PROXIES, GATEWAYS AND FIREWALLS WITH SSL
  126.     4) SSL PROTOCOL QUESTIONS
  127.     5) CERTIFICATE RELATED QUESTIONS
  128.     6) SSL IMPLEMENTATION QUESTIONS
  129.         6.1) NETSCAPE QUESTIONS
  130.         6.2) MICROSOFT QUESTIONS
  131.     7) SSL TOOLKIT QUESTIONS
  132.         7.1) SSLREF QUESTIONS
  133.         7.2) SSL PLUS QUESTIONS
  134.         7.3) SSLEAY QUESTIONS
  135.  
  136.  
  137. ------------------------------
  138.  
  139. 1) THE SSL-TALK LIST
  140.  
  141. This section contains information about the SSL-Talk list.
  142.  
  143.  
  144. 1.1) What is the SSL-Talk List?
  145.  
  146.     The SSL-Talk List was an email list intended for discussion of the
  147.     technical issues of implementing the SSL protocol. It ceased to exist 
  148.     on November 15, 1998.
  149.  
  150.     Past discussions included issues of software development,
  151.     cryptanalysis of the protocol and of its various implementations,
  152.     testing, interoperability, the applicability of SSL to additional
  153.     TCP-based applications, infrastructure growth questions, etc.
  154.  
  155. 1.1.1) Do archives of the SSL-Talk List exist?
  156.  
  157.     Yes. An archive is maintained at: 
  158.     
  159.        <http://www.egroups.com/list/ssl-talk/>
  160.  
  161.     It covers the list from 1995-1998 and is filled with useful 
  162.     information.
  163.     
  164.     We are not aware of any plain text archives of the list.
  165.  
  166.  
  167. 1.2) What is SSL?
  168.  
  169.     SSL is the Secure Sockets Layer protocol. Version 2.0 originated by
  170.     Netscape Development Corporation, and version 3.0 was designed with
  171.     public review and input from industry, and is defined at
  172.         <http://home.netscape.com/eng/ssl3/index.html>
  173.  
  174.  
  175. 1.2.1) What is TLS?
  176.  
  177.     TLS is the Transport Layer Security protocol. It is effectively SSL 
  178.     3.1 and was submitted to the IETF standards committee for change 
  179.     control in 1996. It should be close to release.
  180.  
  181.  
  182. 1.3) Has netscape replaced the SSL-Talk mailing list?
  183.  
  184.     Yes. Netscape, the host of the old ssl-talk mailing list, has 
  185.     replaced it with a newsgroup.
  186.     
  187.     The newsgroup netscape.dev.ssl is now available via two means:
  188.  
  189.     a) from <snews://secnews.netscape.com/>
  190.     
  191.     Note: snews is nntp over SSL. Supported in Communicator 4.x. 
  192.  
  193.     b) from 
  194.     
  195.     <http://www.dejanews.com/
  196.         dnquery.xp?QRY=netscape.dev.ssl&DBS=2&maxhits=25&format=terse> 
  197.  
  198.  
  199. 1.4) Are there any other SSL mailing lists?
  200.  
  201.     Some people prefer mailing lists to newsgroups. Fortunately, several 
  202.     other mailing lists exist to discuss SSL.
  203.  
  204.     THE SSL DEVELOPER LIST
  205.  
  206.     This is a mailing list specifically geared toward application     
  207.     developers who are incorporating SSL or TLS into their products. It 
  208.     is hosted by Consensus Development, a division of Certicom, who has 
  209.     helped to develop the TLS specifications. To join, send a message to:
  210.  
  211.       join-ssl-dev@lists.consensus.com
  212.  
  213.     THE SSL LIST
  214.  
  215.     As with the older SSL-Talk mailing list, the purpose of this 
  216.     mailing list is to discuss any SSL & TLS related issues. It covers 
  217.     the whole spectrum of issues, from beginners on up and is more 
  218.     oriented toward users of SSL-enabled applications. To subscribe 
  219.     simply send e-mail to:
  220.  
  221.     ssl-subscribe@engine.ca
  222.  
  223.     THE SSL-USERS LIST
  224.  
  225.     This is a list concerning SSLeay, a public implementation of SSL. To 
  226.     subscribe send mail to: 
  227.  
  228.         factotum@lists.cryptsoft.com 
  229.  
  230.     The command "subscribe ssl-users" must appear in the body of the 
  231.     message.
  232.     
  233.     THE IETF-TLS LIST
  234.  
  235.     This is a mailing list dedicated to the writing of the TLS     
  236.     specification for the IETF. To subscribe, send a message to:
  237.     
  238.         join-ietf-tls@lists.consensus.com
  239.  
  240. ------------------------------
  241.  
  242. 2) GENERAL SSL QUESTIONS
  243.  
  244. This section contains general information on SSL and the SSL
  245. protocol.
  246.  
  247.  
  248. 2.1) What is the current version of the SSL protocol?
  249.  
  250.     The current version is SSL 3.0, as documented at
  251.         <http://home.netscape.com/eng/ssl3/index.html>
  252.  
  253.     Errata to the SSL 3.0 Specification is periodically posted on
  254.     the SSL discussion list, and is available at
  255.         <http://home.netscape.com/eng/ssl3/ssl-errata.html>
  256.  
  257.     Netscape has submitted SSL 3.0 to the IETF-TLS Working Group
  258.     as an Internet Draft (see the section 4.5 of this FAQ for more
  259.     info on TLS). This will be TLS 1.0:
  260.     <http://www.ietf.org/internet-drafts/
  261.         draft-ietf-tls-protocol-05.txt>    
  262.  
  263.     The previous version of SSL, version 2.0 is documented at
  264.         <http://home.netscape.com/newsref/std/SSL_old.html>
  265.  
  266.  
  267. 2.2) Where can I get a "management overview" of SSL and web security?
  268.  
  269.     There is a brief introduction on how Netscape uses public key
  270.     cryptography in the SSL protocol called "Using Public Key
  271.     Cryptography" at
  272.         <http://home.netscape.com/newsref/ref/rsa.html>
  273.  
  274.     An overview on certificates and VeriSign's Digital IDs is at
  275.         <http://digitalid.verisign.com/crp_intr.htm>.
  276.  
  277.     General information on Netscape security can be found in a
  278.     set of web pages called "Network Security Solutions", at:
  279.         <http://home.netscape.com/products/security/index.html>
  280.  
  281.  
  282. 2.3) Where can I get a more in-depth look at SSL and web security?
  283.  
  284.     The online version of the technical specifications for the SSL 3.0
  285.     protocol is at
  286.         <http://home.netscape.com/eng/ssl3/ssl-toc.html>
  287.  
  288.     A PostScript version is also available at
  289.         <http://home.netscape.com/eng/ssl3/index.html>
  290.  
  291.     A FAQ for SSLeay, a freeware implementation which support SSL 2.0, 
  292.     SSL 3.0, and TLS 1.0, is available at
  293.         <http://www.psy.uq.oz.au/~ftp/Crypto/>
  294.  
  295.     A rather broad list of public key related documents, with a focus on
  296.     certificates and standards can be found at
  297.     <http://www.xcert.com/~marcnarc/PKI/>
  298.  
  299.  
  300. 2.4) What software supports SSL 2.0 and SSL 3.0?
  301.  
  302.     A list of web servers that support SSL 3.0 can be found using the 
  303.     powersearch at:
  304.         <http://webcompare.internet.com>
  305.  
  306.     SSL is not just for web servers and is supported by numerous other 
  307.     internet clients and servers.
  308.  
  309.     
  310. 2.5) What are the laws regarding the import and export of cryptography in 
  311. various countries?
  312.  
  313.     There is an impressive "International Law Crypto Survey" of
  314.     cryptographic laws and regulations throughout the world at
  315.         <http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm>
  316.  
  317.     RSA Data Security, Inc. offers an Acrobat version of their
  318.     "Frequently Asked Questions: Export" at
  319.         <http://www.rsa.com/PUBS/exp_faq.pdf>
  320.  
  321.     Other information on US export issues can be found on
  322.     the Electronic Frontier Foundation's web site at
  323.         <http://www.eff.org/>
  324.  
  325.     Canadian export issues are covered at
  326.         <http://insight.mcmaster.ca/org/efc/pages/doc/crypto-export.html>
  327.  
  328.  
  329. ------------------------------
  330.  
  331. 3) USING PROXIES, GATEWAYS, AND FIREWALLS WITH SSL
  332.  
  333. This section contains information on how the SSL protocol interacts
  334. with proxy servers, security gateways, and firewalls.
  335.  
  336.  
  337. 3.1) What is a proxy server?
  338.  
  339.     A proxy server is a computer program that resides on your firewall
  340.     and acts as a conduit between your computer and the broader
  341.     Internet. In addition to acting as network guardian and logging
  342.     traffic, a proxy server can also provide an enterprise cache for
  343.     files as well as replication and site-filtering services.
  344.  
  345.     Any application which needs to communicate through a proxy has to
  346.     negotiate with the proxy first before continuing through the
  347.     firewall. Netscape Navigator works with many different types of
  348.     proxies (such as the CERN proxy server and their own Netscape Proxy
  349.     Server) and gateways that use the SOCKS protocol.
  350.  
  351.     One problem with SSL-based traffic is that it does not allow
  352.     caching and replication with proxy servers. For a proxy server to
  353.     support SSL it must either support SOCKS (a protocol independent 
  354.     proxy mechanism), or use a special SSL Tunneling protocol. The 
  355.     Netscape Proxy Server supports both SOCKS and the SSL Tunneling 
  356.     protocol.
  357.  
  358.  
  359. 3.2) How does SSL work through (application level) firewalls,
  360. gateways and proxy servers?
  361.  
  362.     SSL was designed to provide security between client and server and
  363.     to avoid any kind of 3-way man-in-the-middle attack. Thus SSL cannot
  364.     be proxied through traditional application level firewalls (such as
  365.     the CERN proxy server) because SSL considers a proxy server to be a 
  366.     middleman.
  367.  
  368.     The simplest alternative to this problem is to use a packet
  369.     filtering firewall. You set it up to open a reserved and trusted
  370.     port for the SSL+HTTP or SSL+NNTP services (443 or 563 respectively)
  371.     allowing all traffic on those ports to be passed through
  372.     unrestricted. The risk with this solution is that an internal
  373.     attacker could attempt to use these trusted ports without using SSL
  374.     and there is no way for the firewall to know.
  375.  
  376.     SSL also can work with gateways that support the SOCKS protocol, a
  377.     protocol independent proxy mechanism. SOCKS is a generic byte
  378.     forwarding gateway between client and server and generally works
  379.     at the socket level. If all you want is TCP/UDP restrictions based on
  380.     client IP or server IP, SOCKS works fine.
  381.  
  382.     However, most non-SSL HTTP proxies work at the protocol level and
  383.     have the ability to understand header information related to the
  384.     protocol. This goes beyond SOCKS to allow the firewall administrator
  385.     to use the header information for filtering and/or monitoring the
  386.     traffic. Also, SOCKS does not offer the firewall administrator
  387.     enough information about the request to let it decide whether to
  388.     allow it and whether to log the request.
  389.  
  390.     A more secure approach is to use a firewall that supports the SSL
  391.     Tunneling CONNECT extension method as described in the Internet
  392.     draft
  393.  
  394.         <http://search.ietf.org/internet-drafts/
  395.             draft-luotonen-web-proxy-tunneling-01.txt>
  396.  
  397.     In SSL Tunneling, the client initiates an SSL connection via normal
  398.     HTTP then handshakes and creates a secure connection to the server
  399.     via a byte-forwarding tunnel. The proxy has access to the
  400.     client-proxy request headers, but the session is encrypted. Once
  401.     the handshake occurs, the proxy acts just like a SOCKS gateway. This
  402.     allows the firewall to monitor the requests, but not the traffic.
  403.  
  404.     The biggest difference between the two methods is that when using
  405.     SOCKS, DNS resolution is the responsibility of the client, whereas
  406.     when requests are forwarded through a proxy, DNS resolution is the
  407.     responsibility of the proxy.
  408.  
  409.     The are three additional things that the SSL Tunneling mechanism
  410.     does with the proxy server that do not happen when using SOCKS:
  411.  
  412.         * The client sends a "user agent" message (for example,
  413.           "Mozilla/3.0/Macintosh").
  414.  
  415.         * The proxy can send to the client an authorization request
  416.           allowing the administrator to use passwords to control external
  417.           Internet access.
  418.  
  419.         * The standard is more easily extensible. For example, the client
  420.           could, in theory, send the URL being requested (or anything
  421.           else) to the firewall. However, there is no standard to support
  422.           this behavior and as far as we know there are no products which
  423.           do it.
  424.  
  425.     The Netscape Proxy Server supports the SSL Tunneling CONNECT 
  426.     extension method for tunneling SSL, and the use of the proxy is 
  427.     described in 
  428.         
  429.     <http://developer.netscape.com/docs/manuals/proxy/adminux/    
  430.      encrypt.htm>
  431.  
  432.     Another solution, also available using the Netscape Proxy Server, is 
  433.     that the proxy server can spoof SSL on behalf of the internal client. 
  434.     The proxy will initiate SSL between itself and other servers on the 
  435.     Internet, but be unsecure inside the firewall between the proxy 
  436.     server and the client.
  437.  
  438.     This compromise means that client authentication is not possible;
  439.     only server authentication of the remote sites is available.
  440.     However, you gain the ability for client authentication between the
  441.     client and the proxy. The administrator must decide which is more
  442.     important, until such time as a better solution arises. The
  443.     description of this feature of the Netscape Proxy Server is at
  444.  
  445.     <http://developer.netscape.com/docs/manuals/proxy/adminux/    
  446.     encrypt.htm>
  447.  
  448.     Reverse proxies are a solution for serving secure content inside
  449.     a firewall to outside clients. For the Netscape Proxy Server
  450.     this is described at
  451.  
  452.     <http://developer.netscape.com/docs/manuals/proxy/adminux/    
  453.      revpxy.htm>
  454.  
  455.     It is possible for a proxy server to hold both client and server
  456.     keys for its internal clients. This allows SSL sessions to be
  457.     carried out twice: once between the client and proxy server, and
  458.     again between the proxy server and the secure server. Thus, the
  459.     proxy server can to listen in on the conversation without having the
  460.     private keys of external servers. Clearly this isn't reasonable for
  461.     the general internet, but it is a viable solution for corporate
  462.     requirements inside a firewall.
  463.  
  464.     Netscape Proxy Server 3.5 supports this feature. It can be used as 
  465.     described above, or simply to create a secure tunnel between sites 
  466.     across an insecure network. This is really multiple sessions of SSL, 
  467.     not an end-to-end secure connection.
  468.  
  469.     This means that 3.5 has full SSL support as opposed to just SSL
  470.     tunneling. It can therefore do client authentication and serve
  471.     documents like a secure server, or request documents like an
  472.     SSL-enabled client. SSL doesn't allow recursive encryption, so by
  473.     using it this way you lose the transparency of the proxy and get
  474.     multiple segments of secure connections, rather than a single
  475.     end-to-end connection.
  476.  
  477.  
  478. 3.3) Since SSL is supposed to withstand replay attacks, does this
  479. preclude proxy servers from caching the data?
  480.  
  481.     A proxy server must pass SSL directly through without caching.
  482.  
  483.  
  484. 3.4) What ports does SSL use?
  485.  
  486.     Theoretically SSL can transparently secure any TCP-based protocol
  487.     running on any port if both sides know the other side is using SSL.
  488.     However, in practice, separate port numbers have been reserved for
  489.     each protocol commonly secured by SSL -- this allows packet
  490.     filtering firewalls to allow such secure traffic through.
  491.  
  492.     As of October 1998, SSL has the following port numbers reserved
  493.     with the Internet Assigned Numbers Authority (IANA), a part of the
  494.     Internet Engineering Task Force (IETF):
  495.  
  496.         Keyword         Decimal         Description
  497.         -------         -------         -----------
  498.         nsiiops         261/tcp         IIOP Name Service over TLS/SSL
  499.         https           443/tcp         http protocol over TLS/SSL
  500.         ddm-ssl         448/tcp         DDM-SSL
  501.         smtps           465/tcp         smtp protocol over TLS/SSL 
  502.         nntps           563/tcp         nntp protocol over TLS/SSL
  503.         sshell          614/tcp         SSLshell
  504.         ldaps           636/tcp         ldap protocol over TLS/SSL 
  505.         ftps-data       989/tcp         ftp protocol, data, over TLS/SSL
  506.         ftps            990/tcp         ftp, control, over TLS/SSL
  507.         telnets         992/tcp         telnet protocol over TLS/SSL
  508.         imaps           993/tcp         imap4 protocol over TLS/SSL
  509.         ircs            994/tcp         irc protocol over TLS/SSL
  510.         pop3s           995/tcp         pop3 protocol over TLS/SSL
  511.  
  512.     A listing of all IANA port assignments can currently be found at 
  513.     <http://www.isi.edu/in-notes/iana/assignments/port-numbers>.
  514.    
  515.  
  516. 3.5) Do you have any information on sftp?
  517.  
  518.     SSL FTP has been assigned port 990 under the name ftps.
  519.  
  520.  
  521. ------------------------------
  522.  
  523. 4) SSL PROTOCOL QUESTIONS
  524.  
  525. This section contains more detailed information on the SSL protocol.
  526.  
  527.  
  528. 4.1) Does SSL protect users from replay attack by eavesdroppers or
  529. message interceptors?
  530.  
  531.     Yes. The client and the server each provide part of the random data
  532.     used to generate the keys for a connection. (The random portions of 
  533.     the connection that initiate a session, drawn from both the client 
  534.     and the server, are used to generate the master secret associated 
  535.     with that session.) Additionally, each record is protected with a 
  536.     MAC (Message Authentication Code) that contains a sequence number for 
  537.     the message.
  538.  
  539.  
  540. 4.2) Isn't encrypt-only SSL open to "man-in-the-middle" attacks?
  541.  
  542.     Yes, even though SSL 3.0 defines an encrypt-only cipher suite (the
  543.     SSL_DH_anon_WITH_DES_CBC_SHA cipher suite), there are many possible
  544.     attacks against it, and some recommend against using it. SSL *MUST* 
  545.     have strong server authentication or it becomes open to some attacks.
  546.     Netscape's browser and server products do not presently support 
  547.     encrypt-only cipher suites for this reason. 
  548.  
  549.  
  550. 4.3) When did MD5 get "disavowed"?
  551.  
  552.     It hasn't been truly "disavowed", but weaknesses have been
  553.     discovered such that some people believe that an alternative should
  554.     be found. These weaknesses were found by Dr. Hans Dobbertin
  555.     <dobbertin@skom.rhein.de> of the German Information Security Agency
  556.     in a paper called "Cryptanalysis of MD5 Compress" dated May 2, 1996.
  557.     A postscript version of the paper is at
  558.         <http://www.cs.ucsd.edu/users/bsy/dobbertin.ps>.
  559.  
  560.     SSL uses MD5 in combination with SHA for all negotiation. It also
  561.     uses MD5 alone in most negotiated cipher suites. However, in these
  562.     cases it is used with the HMAC construction, which strengthens it
  563.     such that there are no known problems with this construction.
  564.  
  565.     It has been proposed with TLS to start phasing out all use of MD5.
  566.  
  567.  
  568. 4.4) The record protocol sits underneath the other protocols, right?
  569. It appears that information can be sent only in blocks. Does
  570. there have to be a one-to-one mapping between write() calls on the
  571. client/server and SSL records? Is there some other blocking
  572. taking place when user data is being sent?
  573.  
  574.     The record layer takes a data stream from the higher layers and
  575.     fragments it into records. If the write is longer than 2^14 bytes
  576.     (with headers), the record layer will generate multiple records.
  577.     Multiple writes can be condensed into a single record.
  578.  
  579.  
  580. 4.5) It appears that there is no way in the SSL protocol to
  581. resynchronize blocks if they get out of synch. Is that true?
  582.  
  583.     Yes. SSL relies on an underlying reliable protocol to assure that
  584.     bytes are not lost or inserted. There was some discussion of
  585.     reengineering the future TLS protocol to work over datagram
  586.     protocols such as UDP, however TLS 1.0 does not support this.
  587.  
  588.  
  589. 4.6) Why does SSL3 have Diffie-Hellman encryption at all? What good is
  590. it? Exchanging random numbers that are encrypted with the server's (or
  591. client's) public key would seem to be an adequate way of getting the
  592. secret bits across. Why have DH as well?
  593.  
  594.     Anonymous DH key exchange doesn't require the use of certificates.
  595.     Ephemeral DH allows you to use signing-only certificates, and it
  596.     protects the session from future compromise of the server's private
  597.     key. Another advantage of DH is that the patent expired in 1997.
  598.  
  599.  
  600. 4.7) What is TLS? What happened at these meetings? Has anything come
  601. out of them yet?
  602.  
  603.     TLS is the Transport Layer Security Working Group of the IETF
  604.     (Internet Engineering Task Force). It is the working group
  605.     responsible for moving transport layer protocols such as SSL
  606.     through the standards tracks.
  607.  
  608.     IETF working groups do most of their activities through mailing
  609.     lists and thrice-annual IETF meetings. The first official IETF-TLS
  610.     Working Group meeting was June 1996 in Montreal. (Before then it was
  611.     an unofficial BOF "birds of a feather" group.)
  612.  
  613.     The home page for the IETF-TLS Working Group is at 
  614.         <http://www.ietf.org/html.charters/tls-charter.html>
  615.  
  616.     The discussion list for IETF-TLS is at IETF-TLS@CONSENSUS.COM. You
  617.     subscribe and unsubscribe by sending to IETF-TLS@CONSENSUS.COM with
  618.     subscribe or unsubscribe in the SUBJECT of the message. Archives of
  619.     the list are at
  620.         <http://www.imc.org/ietf-tls/mail-archive/>
  621.  
  622.     Minutes are available for a number of past IETF-TLS meetings.
  623.  
  624.     August 1998:
  625.     Not currently available
  626.                 
  627.     March 1998:
  628.     <http://www.ietf.org/proceedings/98mar/98mar-edited-114.htm>
  629.  
  630.     December 1997:
  631.     <http://www.ietf.org/proceedings/97dec/97dec-final-116.htm>
  632.  
  633.     April 1997:
  634.     <http://www.consensus.com/ietf-tls/minutes-9704.txt> 
  635.  
  636.     December 1996:
  637.         <http://www.consensus.com/ietf-tls/minutes-9612.txt>
  638.  
  639.     June 1996:
  640.         <http://www.consensus.com/ietf-tls/minutes-9606-1.txt>
  641.         <http://www.consensus.com/ietf-tls/minutes-9606-2.txt>
  642.  
  643.     May 1996:
  644.         <http://www.consensus.com/ietf-tls/minutes-9605.txt>
  645.  
  646.     A number of internet-draft documents have been submitted to the
  647.     IETF-TLS Working Group.
  648.  
  649.     The TLS Protocol 1.0 (Current Version 06):
  650.     <ftp://ftp.ietf.org/internet-drafts/
  651.         draft-ietf-tls-protocol-06.txt>
  652.  
  653.     Addition of Kerberos Cipher Suites to Transport Layer
  654.     Security (TLS):
  655.     <http://www.ietf.org/internet-drafts/
  656.         draft-ietf-tls-kerb-cipher-suites-03.txt>
  657.  
  658.     ECC Cipher Suites for TLS
  659.     <http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-00.txt>
  660.  
  661.     HTTP over SSL:
  662.     <http://www.ietf.org/internet-drafts/draft-ietf-tls-https-01.txt>
  663.  
  664.     An Internet AttributeCertificate Profile for Authorization 
  665.     <http://www.ietf.org/internet-drafts/
  666.         draft-ietf-tls-ac509prof-00.txt>
  667.  
  668.     TLS extensions for AttributeCertificate based authorization
  669.     <http://www.ietf.org/internet-drafts/
  670.         draft-ietf-tls-attr-cert-01.txt>
  671.  
  672.     The following internet drafts are expired, but are of historical
  673.     interest:
  674.  
  675.     Addition of Shared Key Authentication to Transport Layer
  676.     Security (TLS):
  677.         <draft-ietf-tls-passauth-00.txt>
  678.             (16885 bytes, expires May '97)
  679.  
  680.     Modifications to the SSL protocol for TLS: 
  681.         <draft-ietf-tls-ssl-mods-00.txt> (9271 bytes, expires May '97)
  682.  
  683.     Secure FTP over SSL:
  684.         <draft-murray-auth-ftp-ssl-00.txt>
  685.             (14238 bytes, expires June '97)
  686.  
  687.     SSH Transport Layer Protocol (originally
  688.     <draft-ietf-tls-ssh-00.txt>)
  689.         <http://www.consensus.com/ietf-tls/tls-ssh-00.txt>
  690.             (44411 bytes, expired December '96)
  691.  
  692.  
  693. 4.8) What is the purpose of pad1 and pad2, and why were the numbers 0x36 
  694. and 0x5c chosen?
  695.  
  696.     The purpose of the construction of a "keyed-MAC" in the form of
  697.     HASH(K,pad2,HASH(K,pad1,text)). It was proposed by the cryptographer
  698.     Hugo Krawczyk of IBM as a much more secure alternative to traditional
  699.     MACs. In a paper last year he demonstrated a proof that even if the
  700.     hash function was relatively weak (as MD5 has since proven itself to
  701.     be) the addition of the secret key in the function makes it
  702.     significantly more secure. The particular method proposed by
  703.     Krawczyk is now known as an HMAC.
  704.  
  705.     The particular construction that Netscape uses for SSL is based on 
  706.     the original internet-draft, and since that time it has been revised 
  707.     such that it XORs the pads rather than appending them -- a nice 
  708.     consequence of which is that pads are of the same size whether you 
  709.     use  MD5 or SHA; it also allows for long keys and has some 
  710.     security advantages. This version may now be found as RFC 2104:
  711.  
  712.         <http://andrew2.andrew.cmu.edu/rfc/rfc2104.html>
  713.  
  714.     In the proposals we've seen for the IETF-TLS Working Group the
  715.     scheme SSL 3.0 uses will be replaced by the official RFC HMAC
  716.     technique.
  717.  
  718.     The particular pad bytes used are the ones defined in Krawczyk's
  719.     original HMAC paper.  We believe that they are relatively arbitrary.
  720.     The salient property is that half the bits differ: the hamming
  721.     distance between 0x36 and 0x5c is 4 out of a possible 8. We don't
  722.     know if the fact that each of the pads also has a hamming weight of
  723.     4 is significant or not.
  724.  
  725.  
  726. 4.9) Are you aware of any SSL toolkits supporting client authentication?
  727.  
  728.     SSLRef 3.0 and SSL Plus both support SSL 3.0 client authentication. 
  729.     SSLeay supports SSL 2.0 and 3.0 client authentication as well as the 
  730.     proposed TLS standard for client authentication.
  731.  
  732.  
  733. 4.10) What SSL implementations should I test against?
  734.  
  735.     There is no formal conformance testing, but Netscape does currently
  736.     offer an interoperability test server that has been used to test
  737.     conformance with many other implementations of SSL 3.0. This server
  738.     is located at
  739.         <https://ssl3.netscape.com/>
  740.  
  741.     Another interoperability test server can be found at:
  742.         <https://ssl3.c2.org>
  743.     
  744.     VeriSign also has an "Authentic Site" program listing various sites
  745.     that use SSL authentication. Also included is a test page that
  746.     requires that you present a valid VeriSign client certificate.
  747.     More information on the Authentic Site program is at
  748.         <http://www.verisign.com/authentic/>
  749.  
  750.     Client authentication can be tested at:
  751.         <https://in-103.infospace.com/>
  752.  
  753.  
  754. 4.11) What is the difference between SSL 2.0 and 3.0?
  755.  
  756.     Security improvements:
  757.  
  758.     1.  SSL 2.0 is vulnerable to a "man-in-the-middle" attack. An
  759.     active attacker can invisibly edit the list of ciphersuite
  760.     preferences in the hello messages to invisibly force both client and
  761.     server to use 40-bit encryption. SSL 3.0 defends against this
  762.     attack by having the last handshake message include a hash of all
  763.     the previous handshake messages.
  764.  
  765.     2.  SSL 2.0 uses a weak MAC construction, although post-encryption
  766.     seems to stop attacks. This is fixed in 3.0.
  767.  
  768.     3.  SSL 2.0 feeds padding bytes into the MAC in block cipher modes,
  769.     but leaves the padding-length field unauthenticated, which could
  770.     allow active attackers to delete bytes from the end of messages.
  771.     This, too, is fixed in 3.0.
  772.  
  773.     4.  In SSL 3.0, the Message Authentication Hash uses a full 128 bits
  774.     of keying material, even when using an Export cipher. In SSL 2.0,
  775.     Message Authentication used only 40 bits when using an Export
  776.     cipher.
  777.  
  778.     Functionality improvements:
  779.  
  780.     1.  In SSL 2.0, the client can only initiate a handshake at the
  781.     beginning of the connection. In 3.0, the client can initiate a
  782.     handshake routine, even in the middle of an open session. A server
  783.     can request that the client start a new handshake. Thus, the
  784.     parties can change the algorithms and keys used whenever they want.
  785.  
  786.     2.  SSL 3.0 allows the server and client to send chains of
  787.     certificates. This allows organizations to use a certificate
  788.     hierarchy that is more than two certifications deep.
  789.  
  790.     3.  SSL 3.0 has a generalized key exchange protocol.  It allows
  791.     Diffie-Hellman and Fortezza key exchanges and non-RSA certificates.
  792.  
  793.     4.  SSL 3.0 allows for record compression and decompression.
  794.  
  795.     Backward compatibility:
  796.  
  797.     1. SSL 3.0 can recognize an SSL 2.0 client hello and fall back to
  798.     SSL 2.0. An SSL 3.0 client can also generate an SSL 2.0 client
  799.     hello with the version set to SSL 3.0, so SSL 3.0 servers will
  800.     continue the handshake in SSL 3.0, and SSL 2.0 server will cause the
  801.     client to fall back to SSL 2.0.
  802.  
  803.     Other:
  804.  
  805.     1.  SSL 3.0 separates the transport of data from the message layer.
  806.     In 2.0, each packet contained only one handshake message. In 3.0, a
  807.     record may contain part of a message, a whole message, or several
  808.     messages. This requires different logic to process packets into
  809.     handshake messages.  Therefore, the formatting of the packets had to
  810.     be completely changed.
  811.  
  812.     2.  Cipher specifications, handshake messages, and other constants
  813.     are different.
  814.  
  815.  
  816. ------------------------------
  817.  
  818. 5) CERTIFICATE RELATED QUESTIONS
  819.  
  820. This section contains information on certificates used by the SSL
  821. protocol.
  822.  
  823.  
  824. 5.1) How does Netscape handle client certificates in Communicator 4.X? 
  825. Navigator 3.X?
  826.  
  827.     Netscape describes their framework for web-based key generation and
  828.     certificate issuing on their web pages at
  829.         <http://home.netscape.com/eng/security/certs.html>
  830.  
  831.  
  832. 5.2) What is the format of the SSL certificates used by Netscape
  833. Navigator?
  834.  
  835.     Netscape has documented their SSL 2.0 certificate format at
  836.         <http://home.netscape.com/newsref/std/ssl_2.0_certificate.html>.
  837.  
  838.  
  839. 5.3) I am distributing load on several different web servers and I
  840. don't want to have to have a different certificate for each. How can
  841. I do this?
  842.  
  843.     When establishing a secure connection in SSL, many SSL clients
  844.     applications, including Netscape's Navigator, check the common name
  845.     of the certificate against the name of the site in the URL. If it
  846.     doesn't match, the client application warns the user. Thus the
  847.     preferred format of a common name of an SSL server is a simple DNS 
  848.     name like "www.consensus.com".
  849.  
  850.     To support multiple servers you can use a round-robin DNS to send
  851.     each request for "www.consensus.com" to different IP addresses. As
  852.     Netscape Navigator does not check to see that the IP address matches
  853.     the original domain name (reverse-IP), this will work for each
  854.     round-robin server.
  855.  
  856.     Netscape's Navigator will also allow for some simple pattern
  857.     matching. Netscape has documented a number of different possibilities
  858.     in their SSL 2.0 Certificate Format web pages at:
  859.         <http://home.netscape.com/newsref/std/ssl_2.0_certificate.html>
  860.  
  861.     Note, however, none of these regular expression/pattern matching
  862.     choices are accepted by VeriSign. In the past they have accepted
  863.     server certificate common names with regular expressions, but these
  864.     are no longer allowed.
  865.  
  866.     Other CAs may have different policies regarding use of regular
  867.     expressions in common names.
  868.  
  869.  
  870. 5.4) When comparing a URL against the common name of the certificate,
  871. why don't you do a reverse-DNS lookup?
  872.  
  873.     DNS is not a secure name service, and trying to treat it like one
  874.     could be a security hole. The purpose of checking the common name
  875.     against the URL is to make sure that at least the user's expectation
  876.     of what site the user is visiting is not compromised.
  877.  
  878.  
  879. 5.5) Does Netscape require hierarchical naming (that is, distinguished
  880. names) for its certificates?
  881.  
  882.     Yes, Netscape requires distinguished names.
  883.  
  884.  
  885. 5.6) Where can I get more information on certificates?
  886.  
  887.     PKIX is an IETF working group dedicated to providing standards 
  888.     for an X509-based PKI. You can find their charter at:
  889.     <http://www.ietf.org/html.charters/pkix-charter.html>   
  890.     
  891.     VeriSign, the default CA (Certificate Authority) used by Netscape
  892.     and most other WWW browsers has a FAQ at:
  893.         <http://digitalid.verisign.com/id_faqs.htm>
  894.  
  895.     Entrust has a primer on Web Security with an emphasis on
  896.     Certificate Authorities at:
  897.     <http://www.entrust.com/products/library/primer.htm>
  898.  
  899.     There is also a good resource of links to a variety of certificate 
  900.     technical and policy issue sites available at:
  901.         <http://www.xcert.com/~marcnarc/PKI/>
  902.  
  903.  
  904. 5.7) What other CAs exist besides VeriSign?
  905.  
  906.     We know of these CAs:
  907.  
  908.         Thawte Consulting <http://www.thawte.com/certs/>
  909.         COST Computer Security Technologies <http://www.cost.se/>
  910.         CompuSource <http://www.compusource.co.za/id/personal/>
  911.         XCert <http://www.xcert.com>
  912.  
  913.     Numerous other CAs now exist; additional links will be included in 
  914.     the replacement TLS/SSL FAQ intended for the future.
  915.     
  916.     
  917. 5.8) How do I set up my own Certificate Authority?
  918.  
  919.     There is some support for creating your own CA in SSLeay; there is
  920.     information on how to integrate it with Netscape available at:
  921.         <http://www.webvision.com/developers_new/casetup.html>
  922.  
  923.     Several specific products also exist; additional links will be 
  924.     included in the replacement TLS/SSL FAQ intended for the future.
  925.  
  926.  
  927. 5.9) What criteria should I use in deciding between one CA and another?
  928.  
  929.     The purpose of a Certificate Authority is to bind a public key to
  930.     the common name of the certificate, and thus assure third parties
  931.     that some measure of care was taken to ensure that this binding
  932.     is valid. A measure of a Certificate Authority is their "Policy
  933.     Statement" which states what measures they take for each class of
  934.     certificate they offer to ensure that this binding of identity
  935.     with public key is valid.
  936.  
  937.  
  938. 5.10) What are Attribute Certificates?
  939.  
  940.     Attribute Certificates are a new type of certificate proposed by
  941.     Netscape. These are signed objects that assert additional properties
  942.     about a particular identity certificate.
  943.  
  944.     An attribute cert has no associated key pair and consequently cannot
  945.     be used to establish identity. Informally, one can think of them as
  946.     a mechanism for extending the attributes of an identity certificate
  947.     without requiring that the identity certificate be reissued.
  948.  
  949.     More details of the proposal are at
  950.         <http://lists.w3.org/Archives/Public/ietf-tls/msg00796.html>
  951.  
  952.  
  953. ------------------------------
  954.  
  955. 6) SSL IMPLEMENTATION ISSUES
  956.  
  957. This section offers specific implementation details of different SSL
  958. clients and servers that are not specific to the protocol.
  959.  
  960.  
  961. ------------------------------
  962.  
  963. 6.1) NETSCAPE QUESTIONS
  964.  
  965. This is not an official statement by Netscape, and Netscape has not 
  966. reviewed this for accuracy. For additional information, please see:
  967.  
  968.     <http://home.netscape.com/info/security-doc.html> 
  969.     <http://home.netscape.com/eng/security/>
  970.  
  971.  
  972. 6.1.1) I just downloaded a new version of Netscape's browser, and it
  973. doesn't have 128-bit encryption. What version(s) of the browser have
  974. 128-bit encryption?
  975.  
  976.     All versions of Netscape Navigator and Communicator, except "Preview
  977.     Release" versions, are available in two flavors: a "domestic" flavor
  978.     with 128-bit encryption for use in the USA and Canada, and an 
  979.     "export" or "international" flavor with only 40-bit encryption. 
  980.     (There is also a third flavor of Communicator 4.x available for use 
  981.     in France.) Preview releases are only available in the export flavor. 
  982.     To get 128-bit encryption, you must download the U.S. flavor.
  983.  
  984.  
  985. 6.1.2) I just downloaded a newly released version of Netscape's browser
  986. and my bank's server tells me my browser does not have adequate
  987. security. What's wrong?
  988.  
  989.     Here are the likely explanations for this:
  990.  
  991.     a) You have downloaded an "export" flavor of the browser with only
  992.     40-bit encryption, but your bank requires that you use the "domestic"
  993.     flavor of the browser with 128-bit encryption. In this case, you must
  994.     download the domestic 128-bit version.
  995.  
  996.     b) Your bank's server keeps a list of the browser versions with which 
  997.     it will work, and that list has not yet been updated to include the 
  998.     very latest version(s) of Netscape's browser. In this case, please 
  999.     ask your bank to add the newest version of Netscape's browser to 
  1000.     their server's list of acceptable versions. Note that many banks will 
  1001.     not accept "Preview Release" versions because they do not contain 
  1002.     domestic (128-bit) encryption.
  1003.  
  1004.  
  1005. 6.1.3) I downloaded a version of Netscape's browser that is newer than
  1006. version 4.05. Now, when I go to certain https web sites that used to
  1007. work for me (like my bank) I get an error message telling me that
  1008. "Netscape has received bad data from the server." I've been told the 
  1009. problem is with SSL v3 in my new browser, and that I should disable 
  1010. SSL v3 in my browser. What's wrong with SSL v3 in these new browsers?
  1011. Should I disable it?
  1012.  
  1013.     Newer versions of Netscape's browsers enforce the legal export 
  1014.     control requirements of the SSL v3 specification and will not work 
  1015.     with servers that violate the export control provisions of the SSL v3 
  1016.     specification.
  1017.  
  1018.     Some SSL servers do not properly follow the SSL v3 specification's
  1019.     requirements for the U.S. Government's export control regulations.
  1020.     Netscape's server products, and most other brands of server products,
  1021.     conform to the specification, but a few others do not.
  1022.  
  1023.     We strongly advise you to NOT disable SSL v3 in your browser. If you 
  1024.     do disable SSL v3, you lose the extra security protections of SSL v3
  1025.     with ALL the https web sites you visit. By keeping SSL v2 and v3
  1026.     enabled in your browser, you get the best protection each site can
  1027.     provide.
  1028.  
  1029.     Please ask the failing web site to upgrade to conforming servers.
  1030.  
  1031.     Web sites whose servers violate the specification have several 
  1032.     options at their disposal, including falling back on the less secure 
  1033.     SSL v2, by disabling the non-conformant SSL v3 in their servers, or 
  1034.     replacing their servers with servers that conform to the SSL v3 spec.
  1035.  
  1036.  
  1037. 6.1.4) Do Netscape's browsers cache data on disk that has been received
  1038. via https?
  1039.  
  1040.     Navigator 3.0 and Communicator 4.x have an option to allow on-disk
  1041.     caching of data fetched over SSL connections. The default setting is 
  1042.     to not cache https data on disk.
  1043.  
  1044.     In Navigator 2.0, documents fetched using SSL were cached in the same
  1045.     way as non-SSL documents. You could use the "Pragma: no-cache" HTTP
  1046.     header to disable caching for a particular page.
  1047.  
  1048.     In Navigator 1.0, documents fetched with SSL were not cached on disk.
  1049.  
  1050.  
  1051. 6.1.5) Is the cached data encrypted using some key?
  1052.  
  1053.     No, Navigator and Communicator do not encrypt documents that are 
  1054.     stored in the cache.
  1055.  
  1056.  
  1057. 6.1.6) Does Netscape use "regular" RSA libraries (such as BSAFE) or
  1058. "custom" RSA code? More specifically, is Netscape using BSAFE 3.0?
  1059.  
  1060.     Netscape is a BSAFE source licensee. Much of the code in BSAFE 3.0 
  1061.     has been integrated into Netscape's products. However, the BSAFE API 
  1062.     is not available to plugins.
  1063.  
  1064.  
  1065. 6.1.7) Are the 512-bit RSA keys used by exportable servers generated on 
  1066. the fly by Netscape's servers? How often are they changed?
  1067. Does the Netscape server take care of changing them automatically?
  1068.  
  1069.     In Netscape's server products, if the server's public key is longer 
  1070.     than 512 bits, the server generates a temporary 512-bit export key at 
  1071.     start-up time. This key is regenerated only when the server is 
  1072.     restarted.  
  1073.  
  1074.  
  1075. 6.1.8) How can additional root CA certificates be added to the
  1076. browser's certificate database?
  1077.  
  1078.     Root keys for CA (Certificate Authority) certificates may be loaded
  1079.     using an SSL connection to a previously unknown CA. Please see:
  1080.  
  1081.     <http://home.netscape.com/eng/security/comm4-cert-download.html>
  1082.  
  1083.     for more information. Also, new releases of the Navigator have added 
  1084.     additional CA root keys.
  1085.  
  1086.  
  1087. 6.1.9) What X.509v3 certificate extensions are supported by the various
  1088. versions of Netscape browsers?
  1089.  
  1090.     Please see <http://home.netscape.com/eng/security/certs.html>.
  1091.  
  1092.  
  1093. 6.1.10) The Help Information for Netscape's Enterprise server indicates
  1094. that the server supports 6 ciphers for SSL 2.0 and 6 ciphers for SSL
  1095. 3.0. However, the Encryption|Security Preferences menu in the server
  1096. Manager displays only 2 choices for SSL 2.0 and 3 choices for SSL 3.0.
  1097. How can I select the other choices?
  1098.  
  1099.     The Enterprise server is available in two flavors, the "domestic" 
  1100.     flavor with 128-bit encryption for use in the USA and Canada, and the 
  1101.     "export" or "international" flavor with only 40-bit encryption. If 
  1102.     you do not have all the ciphers, then you have the export flavor of 
  1103.     the server. If you want to use the others, you must use the domestic 
  1104.     (non-export) flavor.
  1105.  
  1106.  
  1107. 6.1.11) When will Netscape support SSL sockets for Java browser applets? 
  1108.  
  1109.     There are presently no announced plans to do so.
  1110.  
  1111.  
  1112. ------------------------------
  1113.  
  1114. 6.2) MICROSOFT QUESTIONS
  1115.  
  1116. The text for sub-section 6.2 was grabbed from various documents
  1117. found at
  1118.  
  1119.     <http://www.microsoft.com/workshop/security/default.asp>
  1120.  
  1121.  
  1122. 6.2.1) Which of Microsoft's products will support SSL?
  1123.  
  1124.     Internet Explorer 3.0 provides support for SSL versions 2.0 and 3.0
  1125.     and for Private Communication Technology (PCT) version 1.0. It will
  1126.     include support for the Transport Layer Security Protocol (TLS),
  1127.     which is being considered by IETF.
  1128.  
  1129.  
  1130. 6.2.2) Which Microsoft products support Client Authentication?
  1131.  
  1132.     Client authentication as implemented by Microsoft Internet Explorer
  1133.     3.0 is interoperable with popular Web servers that support secure
  1134.     sockets layer (SSL) 3.0 client authentication.
  1135.  
  1136.     Internet Information Server 3.0 supports client authentication using 
  1137.     standards-based X.509 version 3 certificates. Webmasters can easily 
  1138.     add client authentication to their Web sites by creating an Active 
  1139.     Server Pages (ASP) application.
  1140.  
  1141. ------------------------------
  1142.  
  1143. 7) SSL TOOKIT QUESTIONS
  1144.  
  1145. This section offers specific details of different SSL development
  1146. toolkits that are not specific to the protocol.
  1147.  
  1148.  
  1149. ------------------------------
  1150.  
  1151. 7.1) SSLREF QUESTIONS
  1152.  
  1153. This subsection contains information on SSLRef 3.0 which was
  1154. codeveloped by Netscape Communications Corp. of Mountain View,
  1155. California <http://home.netscape.com/> and Consensus Development
  1156. Corporation of Berkeley, California <http://www.consensus.com/>.
  1157.  
  1158.  
  1159. 7.1.1) What is SSLRef 3.0?
  1160.  
  1161.     SSLRef 3.0 is a reference implementation of the SSL (Secure Sockets
  1162.     Layer) protocol. SSLRef 3.0 is intended to aid and accelerate
  1163.     developers' efforts to provide security within TCP/IP applications.
  1164.     It can also be used to qualify other implementations of version 3.0
  1165.     of the SSL protocol.
  1166.  
  1167.     SSLRef 3.0 consists of a software library, distributed as ANSI C
  1168.     source-code, that can be compiled on Windows 95/NT and Solaris
  1169.     platforms and then linked into TCP/IP application programs. SSLRef
  1170.     3.0 was also designed to be easily ported to a wide variety of
  1171.     other platforms and operating systems.
  1172.  
  1173.     More information on SSLRef can be found at
  1174.         <http://home.netscape.com/newsref/std/sslref.html>
  1175.  
  1176.     If you are a US citizen you can download SSLRef 3.0 at
  1177.     <http://test-drive.netscape.com/tdrive-new/sslref.html>
  1178.  
  1179.  
  1180. 7.1.2) How can I license SSLRef 3.0? What does it cost? With what
  1181. restrictions?
  1182.  
  1183.     The SSLRef 3.0 distribution includes a license for non-commercial
  1184.     use. For commercial licensing, send mail to <sslref@netscape.com>.
  1185.  
  1186.     The SSLRef 3.0 commercial license is Part Number 70-01128-00 and the
  1187.     price is $30,000. The license agreement is a flat one-time fee, not
  1188.     a recurring royalty.
  1189.  
  1190.     SSLRef 3.0 may not be exported. However, the encryption options in
  1191.     SSLRef 3.0 can be limited to make exportable products.
  1192.  
  1193.     SSLRef 3.0 does not include an RSA/BSAFE license for required
  1194.     cryptographic functions. Most users would use BSAFE.
  1195.  
  1196.         For BSAFE information contact RSA at
  1197.             <http://www.rsa.com/>
  1198.  
  1199.  
  1200. ------------------------------
  1201.  
  1202. 7.2) SSL PLUS QUESTIONS
  1203.  
  1204. This sub-section contains information specific to the SSL Plus: SSL
  1205. 3.0 Integration Suite(tm) software toolkit developed by Consensus
  1206. Development Corporation of Berkeley, California
  1207. <http://www.consensus.com/>.
  1208.  
  1209.  
  1210. 7.2.1) What is the relationship between SSLRef and SSL Plus?
  1211.  
  1212.     SSLRef 3.0 was written by Netscape Development Corporation and
  1213.     Consensus Development Corporation. SSL Plus, a derivative of
  1214.     SSLRef 3.0, is fully supported and offers unique value-added
  1215.     features.
  1216.  
  1217.     SSL Plus 2.0 includes numerous updates to SSLRef 3.0, support, a 
  1218.     VeriSign certificate request tool, and a "signer" file format for 
  1219.     storing keys and certificates. It is qualified for additional 
  1220.     platforms, and system integration services are available. When the 
  1221.     TLS spec becomes official, SSL Plus will be upgraded to that new 
  1222.     protocol.  
  1223.  
  1224.     SSLRef 3.0 offers 4 ciphersuites:
  1225.  
  1226.       * RSA authenticated, unencrypted, with MD5
  1227.         (SSL_RSA_WITH_NULL_MD5)
  1228.  
  1229.       * RSA authenticated with exportable RC4 encryption, and MD5
  1230.         (SSL_RSA_EXPORT_WITH_RC4_40_MD5)
  1231.  
  1232.       * RSA authenticated with DES encryption, and SHA
  1233.         (SSL_RSA_WITH_DES_CBC_SHA)
  1234.  
  1235.       * Diffie-Hellman anonymous key exchange with DES encryption,
  1236.         and SHA
  1237.         (SSL_DH_anon_WITH_DES_CBC_SHA)
  1238.  
  1239.     SSL Plus 2.0 adds support for an additional 6 ciphersuites:
  1240.  
  1241.       * RSA authenticated, unencrypted, with SHA
  1242.         (SSL_RSA_WITH_NULL_SHA)
  1243.  
  1244.       * RSA authenticated with non-exportable RC4 encryption, with
  1245.         MD5 or SHA
  1246.         (SSL_RSA_WITH_RC4_128_MD5 & SSL_RSA_WITH_RC4_128_SHA)
  1247.  
  1248.       * RSA authenticated with Triple-DES encryption, with SHA
  1249.         (SSL_RSA_WITH_3DES_EDE_CBC_SHA)
  1250.  
  1251.       * Diffie-Hellman anonymous key exchange with RC4 encryption,
  1252.         with MD5
  1253.         (SSL_DH_anon_WITH_RC4_128_MD5 &
  1254.          SSL_DH_anon_WITH_3DES_EDE_CBC_SHA)
  1255.  
  1256.       * Diffie-Hellman anonymous key exchange with Triple-DES
  1257.         encryption and SHA
  1258.         (SSL_DH_anon_WITH_RC4_128_MD5 &
  1259.          SSL_DH_anon_WITH_3DES_EDE_CBC_SHA)
  1260.  
  1261.     For more information on SSL Plus features see
  1262.         <http://www.consensus.com/SSLPlus/sslplus_stats.html>
  1263.  
  1264.  
  1265. 7.2.2) What is the relationship between SSL Plus and SSLRef 2.0?
  1266.  
  1267.     There is no relationship between SSLRef 2.0 and SSL Plus -- SSL Plus
  1268.     was originally based on SSLRef 3.0 which was not based on SSLRef 2.0.
  1269.  
  1270.  
  1271. 7.2.3) How can I license SSL Plus?
  1272.  
  1273.     SSL Plus is available for commercial use only. Certicom will work 
  1274.     with you to provide a license tailored to fit your company's business 
  1275.     model, whether you prefer flat yearly licenses, royalty based payment 
  1276.     or even one time buyouts. 
  1277.  
  1278.     Since SSL Plus is a protocol toolkit, SSL Plus customers will also 
  1279.     require a license for one of the standard crytographic libraries such 
  1280.     as Certicom's Security Builder, or RSA's BSAFE. 
  1281.  
  1282.     You can get more information about SSL Plus at 
  1283.     <http://www.consensus.com/SSLPlus>, and about Certicom's Security 
  1284.     Builder toolkit at <http://www.certicom.com/cSecure/sdk.htm>
  1285.  
  1286.     In addition, you can contact Consensus directly for more information 
  1287.     on SSL Plus, including pricing, technical information, or more 
  1288.     information about cryptographic library tools, at 
  1289.     <mailto:sales@consensus.com> or at 510/649-3300.
  1290.  
  1291.  
  1292. 7.2.4) Is there any relationship between SSL Plus and Winsock 1.1 or
  1293. Winsock 2.0? Which Winsock would you recommend using to test our
  1294. SSL? Does it matter if Winsock 1.1 or 2.0 architecture is used?
  1295.  
  1296.     No -- SSL Plus is designed to be transport independent and work with
  1297.     both socket and stream styles of I/O. SSL Plus includes some
  1298.     examples of using WinSock 1.1 in the Win32 builds of our sample
  1299.     code. However, we recommend that you write your own callback code if
  1300.     you want better handling of your I/O than what our sample routines
  1301.     provide.
  1302.  
  1303.  
  1304. 7.2.5) How does the data flow within the application, WinSock, SSL,
  1305. TCP/IP stack layers?
  1306.  
  1307.     The short answer is that you insert SSL Plus between your I/O and
  1308.     your application code.
  1309.  
  1310.     Basically, you call SSL Plus instead of your read and write. SSL
  1311.     Plus does its stuff and calls your callback code to do the I/O. Data
  1312.     comes through your I/O routines, through SSL Plus, and then finally
  1313.     to your application.  SSL Plus only manages the data flowing through
  1314.     the connection; it does not handle setting up and tearing down the
  1315.     underlying network connection; your application should open the
  1316.     network connection, then hand it off to SSL Plus for SSL handshaking
  1317.     and data transfer. (This step is not shown in the diagram).
  1318.  
  1319.     Normal:
  1320.  
  1321.          -------------
  1322.         | Application |
  1323.          -------------
  1324.              ^
  1325.              | I/O Calls
  1326.              v
  1327.          -------------
  1328.         | WinSock     |
  1329.          -------------
  1330.              ^
  1331.              | TCP Calls
  1332.              v
  1333.          -------------
  1334.         | Internet    |
  1335.          -------------
  1336.  
  1337.  
  1338.     SSL Plus:
  1339.  
  1340.          -------------
  1341.         | Application |
  1342.          -------------
  1343.              ^
  1344.              | SSL I/O Calls
  1345.              v
  1346.          -------------     I/O Callbacks   --------------------
  1347.         | SSL Plus    | <---------------->| Your Callback Code |
  1348.          -------------                     --------------------
  1349.                                                     ^
  1350.                                                     | I/O Calls
  1351.                                                     v
  1352.                                                -------------
  1353.                                               | WinSock     |
  1354.                                                -------------
  1355.                                                     ^
  1356.                                                     | TCP Calls
  1357.                                                     v
  1358.                                                -------------
  1359.                                               | Internet    |
  1360.                                                -------------
  1361.  
  1362.  
  1363. 7.2.6) With the WinSock 2.0 architecture, the application need only chose 
  1364. an appropriate SSL-enabled service provider. Does SSL Plus support this?
  1365.  
  1366.     With WinSock 2.0 there is some discussion of functionality that 
  1367.     allows you to create a module that you could add to WinSock 2.0.
  1368.  
  1369.     At this time we do not believe that this functionality is actually
  1370.     shipping (as Microsoft was supporting PCT but is now supporting
  1371.     SSL 3), but we do know that it is part of their plans. See the
  1372.     MS-ISF (Microsoft Internet Security Framework) description at
  1373.      <http://premium.microsoft.com/msdn/library/backgrnd/html/
  1374.         msdn_misf.htm>
  1375.  
  1376.     We can't speak to when or if Microsoft will add it to their system
  1377.     software, or if another third-party offers such a module.
  1378.  
  1379.     Meanwhile, there has been some discussion on what changes might be
  1380.     required under WinSock 2.0 to do SSL. See:
  1381.         <http://home.netscape.com/newsref/std/ssl_integration.html>
  1382.  
  1383.  
  1384. 7.2.7) Does SSL Plus support yielding?
  1385.  
  1386.     SSL Plus includes support for processor yielding during
  1387.     cryptographic operations. Because developers provide their own I/O
  1388.     routines, they can do yielding during I/O. Our sample code include 
  1389.     examples of I/O yielding.
  1390.  
  1391.  
  1392. 7.2.8) I don't understand the nomenclatures of constants such as
  1393. "SSL_RSA_EXPORT_WITH_RC4_40_MD5" -- where are they defined?
  1394.  
  1395.     They are actually defined by the SSL 3.0 specification, but also see 
  1396.     section 7.2.1 for an overview.
  1397.  
  1398.  
  1399. 7.2.9) In what order are the cipher suites called? 
  1400.  
  1401.     The default order of the cipher suites is:
  1402.     
  1403.         SSL_RSA_WITH_3DES_EDE_CBC_SHA
  1404.         SSL_RSA_WITH_RC4_128_SHA
  1405.         SSL_RSA_WITH_RC4_128_MD5
  1406.         SSL_RSA_WITH_DES_CBC_SHA
  1407.         SSL_RSA_EXPORT_WITH_RC4_40_MD5
  1408.         SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
  1409.         SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
  1410.         SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
  1411.         SSL_DH_anon_WITH_RC4_128_MD5
  1412.         SSL_DH_anon_WITH_DES_CBC_SHA
  1413.         SSL_RSA_WITH_NULL_SHA
  1414.         SSL_RSA_WITH_NULL_MD5
  1415.  
  1416.  
  1417. 7.2.10) Can I change the order of the cipher suites?
  1418.  
  1419.     Yes. This is easily done with the SSLSetCipherSuites function.
  1420.  
  1421.  
  1422. 7.2.11) Does SSL Plus support compression?
  1423.  
  1424.     Not as of 2.0. If there is a specific customer requirement, or if a 
  1425.     compression cipher suite is defined we expect to support it in the
  1426.     future, but otherwise we have no plans here.
  1427.  
  1428.  
  1429. 7.2.12) In the function SSLWriteRecord(), the data buffer is
  1430. copied, encrypted, then enqueued on the SSL write queue. The function
  1431. then returns. What thread services the write queue? How is the
  1432. thread created?
  1433.  
  1434.     The write queue is serviced by the public function called
  1435.     SSLServiceWriteQueue(). It is called in a number of places in
  1436.     ssltrspt.c, including with every call to SSLWrite(). Data to be
  1437.     written is sent to the I/O layer as you exit out of the write
  1438.     function (for example, right near the bottom of SSLWrite).
  1439.  
  1440.     If SSLWrite() returns SSLWouldBlockError, then make a call to
  1441.     SSLServiceWriteQueue() to service the write queue. (You could
  1442.     instead make a call to SSLWrite() with more data to be written, but
  1443.     this is unlikely.)
  1444.  
  1445.     The write queue is not serviced by a separate execution thread. The
  1446.     write queue mechanism was designed to support non-blocking I/O
  1447.     without undue overhead.
  1448.  
  1449.  
  1450. 7.2.13) When I call SSLRead(), on returning, the length argument should 
  1451. be replaced with the number of bytes actually read. In practice, this 
  1452. doesn't seem to be happening. What am I doing wrong?
  1453.  
  1454.     The difficulty is that it's hard for SSL to precisely emulate the
  1455.     behavior of Unix-style socket calls.
  1456.  
  1457.     The problem is that you are using SSL Plus in its blocking mode; if
  1458.     you return SSLWouldBlock from your I/O Read callback, the library
  1459.     will return the data it has along with the SSLWouldBlock error.
  1460.  
  1461.     The best way to solve this is always to know how much data you're
  1462.     waiting for and to request exactly that much. I know this doesn't 
  1463.     work with a lot of free-form Internet protocols.
  1464.  
  1465.     Alternatively, you would like the call to block until it gets some
  1466.     data, then return it to you, even if it's less than 512 bytes.
  1467.     Ideally, you'd like to do this without busy-looping the CPU waiting
  1468.     for data. The best way to do this using SSL Plus is to write a
  1469.     wrapper for SSLRead() which does the following:
  1470.  
  1471.         * Make a blocking select() call until there is some data
  1472.           available on the TCP/IP connection over which you're speaking
  1473.           SSL. This will cause you to block in a friendly way until data
  1474.           arrives.
  1475.  
  1476.         * Call SSLRead(). If zero bytes are returned from the read,
  1477.           loop and do the select() again. Otherwise, return whatever
  1478.           came back.
  1479.  
  1480.         * Make your Read() callback non-blocking. The easiest thing to
  1481.           do is to check how much data is available on the incoming
  1482.           connection and return SSLWouldBlockErr if you can't completely
  1483.           fulfill the request. (You can optionally read what data there
  1484.           is and return it first; this won't affect functionality).
  1485.  
  1486.     This will result in the following behavior:
  1487.  
  1488.     1. Your program will block gracefully in the select() call until
  1489.        something arrives on the connection.
  1490.  
  1491.     2. You will then ask SSL Plus to read some data.
  1492.  
  1493.     3. SSL Plus will ask the Read() callback to read the header of the
  1494.        next record (3 or 5 bytes).
  1495.  
  1496.     4. The Read() callback will fulfill that, if possible
  1497.  
  1498.     5. SSL Plus will ask to read the body of the record (whose length
  1499.        will be equal to how much data was sent by the other side, plus
  1500.        MAC and encryption padding).
  1501.  
  1502.     6. The Read() callback will fulfill that, if possible.
  1503.  
  1504.     7. If the amount of data received is greater than or equal to how
  1505.        much was requested in 2., the data will be returned
  1506.  
  1507.     8. Otherwise, go back to 3.
  1508.  
  1509.     What will happen in practice looks something like this: because the
  1510.     SSL peer on the other end of the connection generates record layer
  1511.     records monolithically, and they're relatively small, the header and
  1512.     content of a record will arrive at your machine all together. Thus,
  1513.     when your select() call returns, you will be able to successfully
  1514.     read a header and body without blocking. When SSL Plus goes to read
  1515.     another one, your Read() callback will see that there's no data
  1516.     available on the connection (assuming another record hasn't arrived)
  1517.     and return SSLWouldBlockErr. SSL Plus will then return the data it
  1518.     has received and the error SSLWouldBlockErr; you can return that
  1519.     data as a partial completion of the desired read.
  1520.  
  1521.     If a partial record arrives, your select() will wake up, but SSL
  1522.     Plus won't be able to decrypt and check a complete record before the
  1523.     Read() callback returns SSLWouldBlockErr; thus, your read will
  1524.     return with zero bytes returned. Since this isn't the behavior your
  1525.     client expects, you should select() again until more data arrives,
  1526.     hopefully completing the record.
  1527.  
  1528.  
  1529. 7.2.14) If session cache is stored in a database, can multiple Unix
  1530. processes share the same session data?
  1531.  
  1532.     There is no information stored in the session database which can't
  1533.     be passed between processes. Specifically, there is no pointer
  1534.     indirection. Of course, you'll have to figure out how to pass
  1535.     session database records (and their changes or deletions) between
  1536.     processes; that is not part of SSL Plus.
  1537.  
  1538.  
  1539. ------------------------------
  1540.  
  1541. 7.3) SSLEAY QUESTIONS
  1542.  
  1543. This sub-section contains information specific to the SSLeay
  1544. toolkit developed by Eric Young <eay@mincom.com>
  1545.  
  1546.  
  1547. 7.3.1) Where is the SSLeay FAQ?
  1548.  
  1549.     There is a very complete SSLeay FAQ at:
  1550.         <http://www.psy.uq.oz.au/~ftp/Crypto/>
  1551. ------------------------------------------------------------------------
  1552. .. Shannon Appel                    Consensus Development Corporation ..
  1553. .. Research Assistant            a subsidiary of Certicom Corporation ..
  1554. .. <SAppel@consensus.com>                     2930 Shattuck Ave. #206 ..
  1555. .. <http://www.consensus.com>                 Berkeley, CA 94705-1883 ..
  1556. .. <http://www.certicom.com>             o510/649-3300  f510/649-3301 ..
  1557.  
  1558.