Peanuts NeXT Software Archives

home *** CD-ROM | disk | FTP | other *** search

/ Peanuts NeXT Software Archives / Peanuts-1.iso / CDROM / FAQs / Security / ssl-talk-faq < prev next >

Wrap

Internet Message Format | 1996-09-27 | 51.8 KB

Path: informatik.tu-muenchen.de!fu-berlin.de!nntp.zit.th-darmstadt.de!voskovec.radio.cz!news-feed.inet.tele.dk!news.inet.tele.dk!enews.sgi.com!news.mathworks.com!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv From: Christopher Allen <ChristopherA@consensus.com> Newsgroups: alt.security,comp.security.misc,comp.protocols,sci.crypt,comp.infosystems.www.misc,alt.answers,comp.answers,news.answers,sci.answers Subject: [SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.0.1 Followup-To: poster Date: 27 Sep 1996 09:24:24 GMT Organization: Consensus Development Corporation, Berkeley, CA, US <http://www.consensus.com/> Lines: 1291 Approved: news-answers-request@MIT.EDU Distribution: world Expires: 10 Nov 1996 09:21:53 GMT Message-ID: <computer-security/ssl-talk-faq_843816113@rtfm.mit.edu> NNTP-Posting-Host: bloom-picayune.mit.edu Summary: This document is a summary of FAQ (Frequently Asked Questions) found on the SSL-Talk discussion list regarding technical implemenation issues of the Secure Sockets Layer protocol, a transport level security protocol used for securing web servers and clients (such as Netscape Navigator) and other internet applications. X-Last-Updated: 1996/09/18 Originator: faqserv@bloom-picayune.MIT.EDU Xref: informatik.tu-muenchen.de alt.security:39707 comp.security.misc:33873 sci.crypt:54742 comp.infosystems.www.misc:54988 alt.answers:18881 comp.answers:21302 news.answers:82595 sci.answers:5130 Content-type: text/x-usenet-FAQ; version=1.0.1; title="[SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.0.1" Archive-name: computer-security/ssl-talk-faq Posting-Frequency: monthly Last-modified: Wed Sep 18 12:00:00 PDT 1996 Version: 1.0.1 (text) Wed Sep 18 12:00:00 PDT 1996 URL: http://www.consensus.com/security/ssl-talk-faq.html Copyright-Notice: (c) Copyright 1996 by Consensus Development Corporation -- All Rights Reserved SSL-Talk FAQ Secure Sockets Layer Discussion List FAQ v1.0.1 Wed Sep 18 12:00:00 PDT 1996 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 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 recieves 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> 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 points of the SSL protocol and its implementation. 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. ------------------------------ 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 previous version of SSL, version 2.0 is documented at <http://home.netscape.com/newsref/std/SSL_old.html> 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> 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 at the Electronic Frontier Foundation's web site at <http://www.eff.org/> ------------------------------ 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 Tunnneling protocol. 3.2) How does SSL work through (application level) firewalls, gateways and proxy servers? SSL was specifically designed for 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) as SSL considers these proxy servers as such a middle-man. The simplest solution to this is to use a packet filtering firewall. You set it up to open up 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 restricions based on client IP or server IP, SOCKS works fine. However, most non-SSL HTTP proxies work at the protocol level and have the ability to understand header information related to the protocol. This goes beyond SOCKS to allow the firewall administrator to use the header information for filtering and/or monitoring the traffic. Also SOCKS does not offer the firewall administrator sufficient information regarding the request such that it can fully log and/or evaluate the request in order to allow or deny it. A more secure approach is to use a firewall that supports the SSL Tunnelling CONNECT extension method as described in the Internet draft <ftp://ftp.internic.net/internet-drafts/draft-luotonen-ssl-tunneling-02.txt> In the case of SSL Tunneling, the client initiates an SSL connection via normal HTTP, then handshakes and creates a secure connection to the server via a byte-forwarding tunnel. The proxy has access to the client-proxy request headers, but the session is encrypted, and once the handshake occurs the proxy acts identically to a SOCKS gateway. This will allow the firewall to monitor the requests, but not the traffic itself. The biggest difference between the two methods is that when using SOCKS, DNS resolution is the responsibility of the client, whereas when requests are forwarded through a proxy, DNS resolution is the responsibility of the proxy. The are three additional things that the SSL Tunnelling mechanism does with the proxy server that do not happen when using SOCKS: * The user agent is sent (for example, "Mozilla/3.0/Macintosh"). * A proxy authorization is sent which allows you to use passwords to control external Internet access. * The standard is more easily extensible: for example, the client could in theory send the URL being requested to the firewall (or anything else). However, there is no standard to support this behavior and as far as we know there are no products which do it. The Netscape Proxy Server supports this SSL Tunnelling CONNECT extension methods for tunnelling SSL, and its use is described in <http://developer.netscape.com/library/one/sdk/proxy/unixguide/ssl-tunl.htm> Another solution, also available using the Netscape Proxy Server, is that the proxy server can spoof SSL on behalf of the internal client; the proxy will initiate SSL between itself and other servers on the Internet but be unsecure inside the firewall between the proxy server and the client. This compromise means that client authentication is not possible, as only server authentication is available of the remote sites, however you gain the ability for client authentication to the proxy. It's up to the administrator as to which is more important, until such time as a better solution arises. The description of this feature in the Netscape Proxy Server is at <http://developer.netscape.com/library/one/sdk/proxy/unixguide/ssl-tunl.htm#518342> Reverse proxies are a solution for serving secure content inside a firewall to outside clients. For the Netscape Proxy Server this is described at <http://developer.netscape.com/library/one/sdk/proxy/unixguide/revpxy.htm> It is possible for a proxy server to hold both client and server keys for its internal clients, allowing SSL sessions to be carried out twice (once between the client and proxy server, and again between the proxy server and the secure server) and thus allow the proxy server to listen-in on the conversation without having the private keys of external servers. Clearly this isn't reasonable for the general internet, but it is a viable solution for corporate requirements inside a firewall. The current 2.1 beta of the Netscape Proxy Server supports this feature. It can be used as above, or simply to create a secure tunnel between sites across an unsecure network. This is really multiple sessions of SSL, and not really an end-to-end secure connection. This means that 2.1 beta has full SSL support (as opposed to just SSL tunneling) and can therefore do client authentication and serve documents like a secure server, or request documents like an SSL enabled client. SSL doesn't allow recursive encryption, so when used in this fashion, you lose the transparency of the proxy and get multiple segments of secure connections, rather than a single end-to-end connection. 3.3) Since SSL is supposed to withstand replay attacks, does this preclude proxy servers from caching the data? A proxy server must just pass SSL directly through without caching. 3.4) What ports does SSL use? Theoretically SSL can transparently secure any TCP based protocol running on any port if both sides know the other side is using SSL. However, in practice, seperate port numbers have been reserved for each protocol commonly secured by SSL -- this allows packet filtering firewalls to allow such secure traffic through. As of September 1996, SSL has the following port numbers reserved with the Internet Assigned Numbers Authority (IANA), a part of the Internet Engineering Task Force (IETF): Keyword Decimal Description ------- ------- ----------- https 443/tcp https ssmtp 465/tcp ssmtp snews 563/tcp snews ssl-ldap 636/tcp ssl-ldap spop3 995/tcp SSL based POP3 3.5) Do you have any information on sftp? The name sftp conflicts with a prococol called simple file transfer protocol. As far as we can tell ftps has not been applied for, nor does it appear in the SSL 3.0 specification. ------------------------------ 4) SSL PROTOCOL QUESTIONS This section contains more detailed information on the SSL protocol. 4.1) Does SSL protect users from replay attack by eavesdroppers or message interceptors? Yes. Both the client and the server provide part of the random data used to generate the keys for each connection. (The client and server random portions from the connection that initiates a session are also used to generate the master secret associated with that session.) Additionally, each record is protected with a MAC that contains a sequence number for the message. 4.2) The record protocol sits underneath the other protocols, right? It appears that information can be sent only in blocks. Does there have to be a one-to-one mapping between write() calls on the client/server and SSL records? Is there some other blocking taking place when user data is being sent? The record layer takes a data stream from the higher layers and fragments it into records. If the write is longer than 2^14 bytes (with headers), the record layer will generate multiple records. Multiple writes can be condensed into a single record. 4.3) It appears that there is no way in the SSL protocol to resynchronize blocks if they get out of synch. Is that true? Yes, SSL relies on an underlying reliable protocol to assure that bytes are not lost or inserted. There was some discussion of reengineering the future TLS protocol to work over datagram protocols such as UDP, however, most people at a recent TLS meeting felt that this was inappropriate layering. 4.4) Why does SSL3 have Diffie-Hellman encryption at all? What good is it? Exchanging random numbers that are encrypted with the server's (or client's) public key would seem to be an adequate way of getting the secret bits across. Why have DH as well? Anonymous DH key exchange doesn't require the use of certificates. Ephemeral DH allows you to use signing-only certificates, and it protects the session from future compromise of the server's private key. Another advantage of DH is that the patent expires next year. 4.5) What is TLS? What happened at these meetings? Has anything come out of them yet? TLS is the Transport Layer Security working group of the IETF (Internet Engineering Task Force). It is the working group responsible for moving transport layer protocols such as SSL through the standards tracks. IETF working groups do most of their activities through mailing lists and thrice-annual IETF meetings. The first official TLS working group meeting was June 1996 in Montreal. (Before then it was an unofficial BOF "birds of a feather" group.) The discussion list for IETF-TLS is at IETF-TLS@W3.ORG. You subscribe and unsubscribe by sending to IETF-TLS-REQUEST@W3.ORG with subscribe or unsubscribe in the SUBJECT of the message. Archives of the list are at <http://lists.w3.org/Archives/Public/ietf-tls> There was a day-long pre-Montreal meeting last May in Palo Alto, the minutes of which are at <http://lists.w3.org/Archives/Public/ietf-tls/msg00185.html> These minutes give a fairly complete list of technical issues and possible solutions. The minutes for the official TLS working group meeting in Montreal are in two messages at <http://lists.w3.org/Archives/Public/ietf-tls/msg00217.html> <http://lists.w3.org/Archives/Public/ietf-tls/msg00212.html> 4.6) When did MD5 get "disavowed"? It hasn't been truly "disavowed", but weaknesses have been discovered such that some people believe that an alternative should be found. These weaknesses were found by Dr. Hans Dobbetin <dobbertin@skom.rhein.de> of the German Information Security Agency in a paper called "Cryptanalysis of MD5 Compress" dated May 2, 1996. A postscript version of the paper is at <http://www.cs.ucsd.edu/users/bsy/dobbertin.ps>. SSL uses MD5 in combination with SHA for all negotiation. It also uses MD5 alone in most negotiated cipher suites. However, in these cases it is used with the HMAC construction, which strengthens it such that there are no known problems with this construction. It has been proposed with TLS to start phasing out all use of MD5. 4.7) Can anyone explain to me the purpose of pad1 and pad2, and why the numbers 0x36 and 0x5c were chosen? The purpose of the construction of a "keyed-MAC" in the form of HASH(K,pad2,HASH(K,pad1,text)) was proposed by the cryptographer Hugo Krawczyk of IBM as much more secure alternative to traditional MACs. In a paper last year he demonstrated a proof that even if the hash function was relatively weak (as MD5 has since proven itself to be) the addition of the secret key in the function makes it significantly more secure. The particular method proposed by Krawczyk is now known as an HMAC. The particular construction that Netscape uses for SSL is based on the original internet-draft of last November, and since that time it has been revised such that it XOR the pads rather than appending them -- a nice consequence of which is that pads are of the same size whether you use MD5 or SHA and it also allows for long keys and has some security advantages. Our understanding is that this version of HMAC has now been approved and will soon be assigned an RFC. The current draft is at <ftp://ftp.internic.net/internet-drafts/draft-ietf-ipsec-hmac-md5-00.txt> In the proposals we've seen for the IETF-TLS working group the scheme SSL 3.0 uses will be replaced by the official RFC HMAC technique. The particular pad bytes used are the ones defined in Krawczyk's original HMAC paper. We believe that they are relatively arbitrary. The salient property is that half the bits differ: the hamming distance between 0x36 and 0x5c is 4 out of a possible 8. We don't know if the fact that each of the pads also has a hamming weight of 4 is significant or not. 4.8) Are you aware of any SSL toolkits supporting client authentication? SSLeay is able to do SSL 2.0 client authentication, however, we don't know of any browsers that support SSL 2.0 client authentication. SSLRef 3.0 and SSL Plus are two toolkits that now support SSL 3.0 client authentication. 4.9) What SSL implementations should I test against? There is no formal conformance testing, but Netscape does currently offer an interoperability test server that has been used to test conformance with many other implementations of SSL 3.0. This server is located at <https://www3.netscape.com/> VeriSign also has an "Authentic Site" program listing various sites that use SSL authentication. Also included is a test page that requires that you present a valid VeriSign client certificate. More information on the Authentic Site program is at <http://www.verisign.com/authentic/> Some other sites that client authentication can be tested against are <https://www.bassandco.com/secure/> <https://in-103.infospace.com/> ------------------------------ 5) CERTIFICATE RELATED QUESTIONS This section contains information on certificates used by the SSL protocol. 5.1) How does Netscape handle client certificates in Navigator 3.0? Netscape describes their framework for web-based key generation and certificate issuing on their web pages at <http://home.netscape.com/eng/security/certs.html> 5.2) What is the format of the SSL certificates used by Netscape Navigator? Netscape has documented their SSL 2.0 certificate format at <http://home.netscape.com/newsref/std/ssl_2.0_certificate.html>. 5.3) I am distributing load on several different web servers and I don't want to have to have a different certificate for each. How can I do this? When establishing a secure connection in SSL, many SSL clients applications, including Netscape's Navigator, check the common name of the certificate against the name of the site in the URL. If it doesn't match, the client application warns the user. Thus the preferred format of a common name of an SSL server is a simple DNS name like "www.consensus.com". To support multiple servers you can use a round-robin DNS to send 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 possiblities 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> 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 are there 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/> In addition, we have heard that Entrust (Northern Telecom/NorTel), 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://wheat.webvision.com/~dhm/wvca-howto.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. ------------------------------ 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 <erig@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 Netcape'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 subsction 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 also was 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 or Canadian 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 licencse 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(tm) 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_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: ------------- | Application | ------------- ^ | I/O Calls v ------------- | WinSock | ------------- ^ | TCP Calls v ------------- | Internet | ------------- SSL Plus: ------------- | Application | ------------- ^ | SSL I/O Calls v ------------- I/O Callbacks -------------------- | SSL Plus | <---------------->| Your Callback Code | ------------- -------------------- ^ | I/O Calls v ------------- | WinSock | ------------- ^ | TCP Calls v ------------- | Internet | ------------- 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 disussion 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.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.. ... Security Integration Suite(tm)" <http://www.consensus.com/SSLPlus/>..