--- libaws-2.5~124785.orig/res.ads +++ libaws-2.5~124785/res.ads @@ -0,0 +1,9 @@ + +-- AWSRes v1.2 - Genarated on June 01 2008 at 14:21:22 + +package res is + + procedure Init; + -- Register all resources files + +end res; --- libaws-2.5~124785.orig/res.adb +++ libaws-2.5~124785/res.adb @@ -0,0 +1,22 @@ + +-- AWSRes v1.2 - Genarated on June 01 2008 at 14:21:22 + + +with AWS.Resources.Embedded; +with GNAT.Calendar; + +package body res is + + Initialized : Boolean := False; + + procedure Init is + use AWS.Resources.Embedded; + begin + if not Initialized then + Initialized := True; + end if; + end Init; + +begin + Init; +end res; --- libaws-2.5~124785.orig/debian/README.Debian +++ libaws-2.5~124785/debian/README.Debian @@ -0,0 +1,35 @@ +Ada Web Server for Debian - maintainer's notes + +The Ada Web Server library can use either libopenssl or libgnutls for +strong cryptography. This enables support for the HTTPS and other +encrypted protocols. Unfortunately there are problems with both +libraries. + +libopenssl is licensed under terms incompatible with the General +Public License, while libaws is licensed under the GPL. Therefore, +Debian cannot ship binaries of libaws linked with libopenssl. + +Linking libaws with libgnutls has a technical problem which I haven't +been able to correct. The symptom is that both ada2wsdl and wsdl2aws +segfault during elaboration. The segmentation fault takes place in +the call to gcry_control which is at aws-net-ssl__gnutls.adb:1000. + +Ted Dennison writes: + +> Obviously there could be a million reasons for this. However, I know +> a common cause of this particular symptom in an Ada program is a +> task having too small of a stack for the amount of data being +> declared in it. There's usually a global default, which can be +> changed for a given task with pragma Storage_Size. + +> Most tasks are created and have their stack variables built during +> elaboration. The exception would be task objects (of a defined task +> type) that are dynamically allocated. Even those *could* be created +> during an elaboration, if the coder allocates them inside a +> package's "begin...end" block. + +If you would like to help solve this problem, please send email to +aws@lists.adacore.com (I'm on that list, so you don't need to CC me). + +-- +Ludovic Brenta, 2008-06-01 --- libaws-2.5~124785.orig/debian/copyright +++ libaws-2.5~124785/debian/copyright @@ -0,0 +1,60 @@ +This package was debianized by Ludovic Brenta on +Thu, 29 Jan 2004 14:57:34 +0100. + +It was downloaded from http://libre.act-europe.fr/aws + +Upstream Authors: Dmitriy Anisimkov and + Pascal Obry . + +Copyright: Copyright (c) 2000-2008 AdaCore + +This library is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or (at +your option) any later version. + +This library is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this library; if not, write to the Free Software Foundation, +Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + +The full text of the GNU Public License is available in +/usr/share/common-licenses/GPL. + +License change +-------------- + +AWS 2.2 has switched to the pure GNU GPL license. As a result, if +you use AWS 2.2 in your program, you have four options: + +- do not distribute your program at all (you can always use it for + yourself). + +- distribute your program under the terms of the GPL, i.e. with full + sources and the four freedoms: inspection, redistribution, + modification, and distribution of modified copies. + +- distribute your program in source form only, under licensing terms + of your choosing (perhaps under non-disclosure, non-redistribution + terms), and ask your licensees to recompile your program for + themselves. + +- contact AdaCore (sales@adacore.com) and purchase a GNAT-Modified + GPL which will allow you to distribute your program in binary-only + form without disclosing your sources. + +If you obtain AWS 2.2 or later from AdaCore's CVS or web server, you +may notice that the source files still contain the GNAT-Modified +license boilerplate. This boilerplate has no legal force; you must +ask AdaCore for clarification. The license is really the pure GPL. +In order to reduce the risk for confusion, I have removed this license +boilerplate from the sources in the Debian package. + +The GPL also applies to all documentation. + +-- +Ludovic Brenta, 2006-07-13 --- libaws-2.5~124785.orig/debian/compat +++ libaws-2.5~124785/debian/compat @@ -0,0 +1 @@ +5 --- libaws-2.5~124785.orig/debian/changelog +++ libaws-2.5~124785/debian/changelog @@ -0,0 +1,202 @@ +libaws (2.5~124785-1ubuntu1) karmic; urgency=low + + * debian/build_aws.gpr : replace dummy occurences with gnutls to reactivate + GNUTLS support in AWS + Close: Launchpad Bug #504974 + + -- David Sauvage Sat, 09 Jan 2010 14:04:05 +0100 + +libaws (2.5~124785-1) unstable; urgency=low + + * new upstream release (Subversion revision 124785). + Closes: #478728, #483555, #481829. + * debian/rules: do not export DH_COMPAT anymore; instead add debian/compat. + * debian/control: update standards-version to 3.7.3 with no changes required. + Migrate the documentation to texlive-generic-recommended, + texlive-fonts-recommended and texlive-latex-base. Migrate to gnat-4.3. + Add support for mips, mipsel and ppc64. + * debian/aws.gpr: turn into a library project file. + * debian/build_aws.gpr, debian/tools.gpr, debian/ada2wsdl.gpr: build + everything with debugging symbols. + * debian/control, debian/rules: introduce a new package, libaws-dbg, + containing debugging symbols for libaws. + * debian/control, debian/rules, debian/build_aws.gpr: do not build against + libgnutls because it causes a segfault during elaboration of wsdl2aws and + ada2wsdl. + * debian/docs.patch: work around a bug in pdfetex (see Debian bug #483966). + + -- Ludovic Brenta Sun, 1 Jun 2008 16:34:06 +0200 + +libaws (2.2dfsg-1) unstable; urgency=low + + * Fake a new upstream release; new source tarball in which I removed the + IETF's non-free Request For Comments. Closes: #387250. + * debian/rules: ugly hack to take the "dfsg" part of the version into + account, and leave it out of sonames etc. There is no soname change. + * (I talked to upstream; they're not planning a new release before the + Etch freeze). + + -- Ludovic Brenta Wed, 20 Sep 2006 18:53:21 +0200 + +libaws (2.2-3) unstable; urgency=low + + * debian/rules, debian/ada2wsdl.gpr, debian/tools.gpr: + do not link the libaws.so object files statically into the tools + (package libaws-bin); reduces their size significantly. + * debian/control (libaws-dev): depend on libtemplates-parser-dev. + Closes: #387896. (Olleg, thanks for your patience). + + -- Ludovic Brenta Sun, 17 Sep 2006 22:30:01 +0200 + +libaws (2.2-2) unstable; urgency=low + + * aws.gpr: add a package Naming to tell gnatmake which files to use for + strong crypto; we use GNU TLS. Closes: #387899. + + -- Ludovic Brenta Sun, 17 Sep 2006 21:09:41 +0200 + +libaws (2.2-1) unstable; urgency=low + + * New upstream version. Closes: #370560, #379921. + * debian/control: + (source) change maintainer's email address, I am now a full DD. + (build-depends): gnat (>= 3.15p) -> gnat (>= 4.1) + libasis-3.15p-1-dev -> libasis-dev (>= 2005) + libssl-dev -> libgnutls-dev + libxmlada1-dev -> libxmlada2-dev + - -> libtemplates_parser-dev + - -> quilt, texinfo, tetex-extra + (Standards-Version): update to 3.7.2 with no changes required. + (Architecture): add support for alpha, amd64, hppa, ia64 and s390. + (libaws2): rename to libaws2.2. + (libaws-dev): depend on libaws2.2 and gnat-4.1. + (libaws-bin): new package containing programs, will become mandatory for + multiarch. + (libaws-doc): provide the new web_elements (reusable pieces of web + applications) + * patches/series, + patches/demos.patch, + patches/docs.patch, + patches/ada2wsdl.patch: new; move from libaws_2.0p-11.diff.gz, and update. + * debian/rules: + - change the library's soname from libaws.so.2 to libaws.so.2.2 (new ABI) + - use quilt to apply and revert patches. + * debian/copyright: switch from GMGPL to pure GPL; explain. + + -- Ludovic Brenta Wed, 9 Aug 2006 21:08:18 +0200 + +libaws (2.0p-11) unstable; urgency=low + + * debian/rules (regexp): accept any character as part of the Debian + uplodad number. Closes: #359881. + + -- Ludovic Brenta Fri, 31 Mar 2006 08:14:06 +0200 + +libaws (2.0p-10) unstable; urgency=low + + * debian/control: enable support for GNU/kFreeBSD per request from + Aurélien Jarno. Build-depend on gnat (>= 3.15p-19), + libasis-3.15p-1-dev (>= 3.15p-10), and libxmlada-dev + (>= 1.0-3), which enable this support. Closes: #345060. + * debian/ada2wsdl.1: apply patch from Nicolas François that fixes a + typo. Thanks, Nicolas. Closes: #350486. + + -- Ludovic Brenta Wed, 8 Feb 2006 18:41:27 +0100 + +libaws (2.0p-9) unstable; urgency=low + + * debian/control: Add (>= 3.15p-9) to the existing Build-Depend on + libasis-3.15p-1-dev. Closes: #344699. + + -- Ludovic Brenta Mon, 26 Dec 2005 16:07:13 +0100 + +libaws (2.0p-8) unstable; urgency=low + + * debian/rules (ada2wsdl, awsres, wsdl2aws): pass -L. to the linker to + properly link against the just-built libaws.so. + + -- Ludovic Brenta Thu, 22 Dec 2005 12:54:13 +0100 + +libaws (2.0p-7) unstable; urgency=low + + * debian/rules: do not build the shared library twice, and do not put PIC + objects in the static library. Detect the number of CPUs available and + do a parallel build with that number instead of just 2. + * aws.gpr: remove the tools directory from the sources. + * tools.gpr: new. Use to build the tools. + + -- Ludovic Brenta Wed, 14 Dec 2005 09:45:17 +0100 + +libaws (2.0p-6) unstable; urgency=low + + * Bad, bad engineer! See what you've done! + * debian/control: build-depend on libasis-3.15p-dev on powerpc, too. Fixes + FTBFS on powerpc. + * debian/control: bump standards-version to 3.6.2. + + -- Ludovic Brenta Mon, 19 Sep 2005 20:34:12 +0200 + + +libaws (2.0p-5) unstable; urgency=low + + * Now that #177703 is resolved, build ada2wsdl on powerpc. + * Change maintainer's email address + + -- Ludovic Brenta Thu, 25 Aug 2005 23:13:23 +0200 + +libaws (2.0p-4) unstable; urgency=low + + * libaws-dev: Depend on zlib1g-dev. Closes: #268680. Also depend on + libldap2-dev, libssl-dev, and libxmlada1-dev for good measure. + * debian/rules: do not strip the static library. + + -- Ludovic Brenta Sat, 28 Aug 2004 17:56:19 +0200 + +libaws (2.0p-3) unstable; urgency=low + + * Do not use the same project file for ada2wsdl as for the other things; + ada2wsdl needs asis whereas the others don't. Fixes a FTBFS bug on + powerpc. + + -- Ludovic Brenta Tue, 13 Jul 2004 18:19:50 +0200 + +libaws (2.0p-2) unstable; urgency=low + + * Temporarily disable building ada2wsdl on powerpc. It requires asis, + and asis is not available on powerpc (see #177703). + * debian/rules (build): reorganised into several sub-targets. + * Update Standards-Version to 3.6.1.1. + + -- Ludovic Brenta Sat, 10 Jul 2004 17:31:30 +0200 + +libaws (2.0p-1) unstable; urgency=low + + * New upstream version. Change package name from libaws1 to libaws2. + * Build-Depend on libasis-3.15p-1-dev. + * libaws-doc: For the examples, replace the makefile with a simple one + and a GNAT project file. Both use the Debian paths to installed + libraries. Closes: #244815. + * debian/ada2wsdl.1: new man page. + * debian/wsdl2aws.1: updated man page. + + -- Ludovic Brenta Sat, 12 Jun 2004 20:15:35 +0200 + +libaws (1.4-2) unstable; urgency=low + + * Fix the maintainer's email address in control file. + * Force a recompile on powerpc. The buildd log reports a strange + (transient?) error. + * Build-Depend on gnat (>= 3.15p-7) to avoid problems with non-PIC code + in libgnat-3.15p-1 (= 3.15p-6). + + -- Ludovic Brenta Tue, 24 Feb 2004 16:21:51 +0100 + +libaws (1.4-1) unstable; urgency=low + + * Initial Release. Closes: #232471. + + -- Ludovic Brenta Fri, 13 Feb 2004 08:57:34 +0100 + +Local variables: +left-margin: 2 +End: --- libaws-2.5~124785.orig/debian/ada2wsdl.1 +++ libaws-2.5~124785/debian/ada2wsdl.1 @@ -0,0 +1,79 @@ +.TH ADA2WSDL 1 "11 JUN 2004" "GNU Ada Tools" "AWS User's Guide" +.SH NAME +ada2wsdl \- Generate a WDSL document from an Ada package specification +.SH SYNOPSIS +\fBada2wsdl\fR [options] \fIada_spec\fR +.SH DESCRIPTION +The Ada Web Server is a library that allows you to embed a web server +into your Ada application. It provides not only HTTP but also SOAP, +WSDL and several other facilities. Thus you can write full-fledged +web applications. + +WSDL (Web Service Definition Language) is a language based on XML. +WSDL documents describe, in a formal way, the interface to Web +Services. This description consists of the end-point (URL to the +server offering the service), the SOAPAction (needed to call the +remote procedure), the procedure names and a description of the input +and output parameters. + +Using \fBada2wsdl\fR, you can create a WSDL document that describes +Web Services provided by an Ada package. \fBada2wsdl\fR uses ASIS to +parse your Ada package specification, and generates a WSDL document by +mapping Ada types to Web Services types, and Ada subprograms to +operations. + +Please see the AWS User's guide for more details on how \fBada2wsdl\fR +works, and how you can use it to develop web services. + +.SH OPTIONS +.IP \fB-a\fR\ \fIurl\fR +Specify the URL for the Web Server address. Web Services will be +available at this address. A port can be specified on the URL, +\fBhttp://server[:port]\fR. The default value is \fBhttp://.../\fR. + +.IP \fB-f\fR +Force creation of the WSDL file. Overwrite exiting file with the +same name. + +.IP \fB-I\fR\ \fIpath\fR +Add path option for the ASIS compilation step. This option can appear +any number of time on the command line. + +.IP \fB-noenum\fR +Do not generate WSDL representation for Ada enumerations, map them to +standard string. + +.IP \fB-o\fR\ \fIfile\fR +Generate the WSDL document into \fIfile\fR. + +.IP \fB-q\fR +Quiet mode (no output). + +.IP \fB-s\fR\ \fIname\fR +Specify the Web Service name for the WSDL document, by default the +spec package's name is used. + +.IP \fB-v\fR +Verbose mode, display the parsed spec. + +.SH "BUGS" +\fBada2wsdl\fR does not handle constrained arrays in records. + +\fBUnbounded_String\fR are supported with full interoperability only +inside a record. + +Only unconstrained arrays are supported. + +Arrays with multiple dimensions are not supported. + +.SH "SEE ALSO" +.BR awsres (1), +.BR wsdl2aws (1) + +The Ada Web Server User's Guide in package libaws-doc. +.SH AUTHOR +\fBwsdl2aws\fR was written by Dmitriy Anisimkov +and Pascal Obry as part of the Ada Web Server. + +This manual page was written by Ludovic Brenta + for Debian GNU/Linux. --- libaws-2.5~124785.orig/debian/tools.gpr +++ libaws-2.5~124785/debian/tools.gpr @@ -0,0 +1,35 @@ +with "templates_parser"; +with "xmlada"; +project Tools is + for Source_Dirs use ("../debian/tmp", "../config", + "../include", "../soap", "../src", + "../ssl", "../tools", "../xsrc"); + for Object_Dir use "../obj-tools"; + for Exec_Dir use "tmp"; + for Main use ("awsres", "wsdl2aws"); + + package Compiler is + for Default_Switches ("Ada") + use ("-O2", "-g", "-gnatafno", "-gnatVa", "-gnatwa"); + end Compiler; + + package Naming is + -- Configuration for GNU/Linux using GNU TLS for strong crypto + for Body ("AWS.Net.SSL") use "aws-net-ssl__gnutls.adb"; + for Body ("AWS.Net.SSL.Certificate") + use "aws-net-ssl-certificate__gnutls.adb"; + for Body ("AWS.Net.Std") use "aws-net-std__gnat.adb"; + -- for Body ("AWS.OS_Lib") use "aws-os_lib__gnat.adb"; + for Spec ("AWS.OS_Lib") use "aws-os_lib-definitions.ads"; + for Body ("AWS.Translator.Conversion") + use "aws-translator-conversion__f.adb"; + for Spec ("SSL.Thin") use "ssl-thin__gnutls.ads"; + for Spec ("Templates_Parser.Configuration") + use "templates_parser-configuration__aws.ads"; + end Naming; + + package Linker is + for Default_Switches ("Ada") use ("-g", "-laws"); + end Linker; + +end Tools; --- libaws-2.5~124785.orig/debian/build_aws.gpr +++ libaws-2.5~124785/debian/build_aws.gpr @@ -0,0 +1,28 @@ +with "xmlada"; +with "templates_parser"; +project Build_AWS is + for Source_Dirs use ("../debian/tmp", "../config", + "../include", "../soap", "../src", + "../ssl", "../xsrc"); + for Object_Dir use "../" & External ("OBJ_DIR", "obj-shared"); + + package Naming is + -- Configuration for GNU/Linux using GNU TLS for strong crypto + for Body ("AWS.Net.SSL") use "aws-net-ssl__gnutls.adb"; + for Body ("AWS.Net.SSL.Certificate") + use "aws-net-ssl-certificate__gnutls.adb"; + for Body ("AWS.Net.Std") use "aws-net-std__gnat.adb"; + -- for Body ("AWS.OS_Lib") use "aws-os_lib__gnat.adb"; + for Spec ("AWS.OS_Lib") use "aws-os_lib-definitions.ads"; + for Body ("AWS.Translator.Conversion") + use "aws-translator-conversion__f.adb"; + for Spec ("SSL.Thin") use "ssl-thin__gnutls.ads"; + for Spec ("Templates_Parser.Configuration") + use "templates_parser-configuration__aws.ads"; + end Naming; + + package Compiler is + for Default_Switches ("Ada") + use ("-O2", "-g", "-gnatafno", "-gnatVa", "-gnatwa"); + end Compiler; +end Build_AWS; --- libaws-2.5~124785.orig/debian/awsres.1 +++ libaws-2.5~124785/debian/awsres.1 @@ -0,0 +1,63 @@ +.TH AWSRES 1 "29 JAN 2004" "GNU Ada Tools" "AWS User's Guide" +.SH NAME +awsres \- build resource files for Ada Web Server applications +.SH SYNOPSIS +\fBawsres\fR [\fB-h\fR] [\fB-r\fR \fIunit\fR] [\fB-q\fR] \fIfile\fR... +.SH DESCRIPTION +The Ada Web Server is a library that allows you to embed a web server +into your Ada application. It provides not only HTTP but also SOAP, +WSDL and several other facilities. Thus you can write full-fledged +web applications. \fBawsres\fR allows you to embed resources, such as +pictures, into your final executable, so that your executable is +completely self-contained and does not need to read other files at run +time. + +\fBawsres\fR works by creating Ada source files that contain the data +for your resources as arrays of bytes. You then compile these Ada +source files into your executable. At run time, the AWS library +automatically loads the resources from the executable whenever +available. + +\fBawsres\fR creates one parent Ada package named, by default, `res', +and one child package for each of the \fIfiles\fR given on the command +line. The package `res' registers each resource when your application +starts. To link `res' into your executable you simply add a `with +res;' statement in one of your source files. +.SH EXAMPLE +.de Vb \" Begin verbatim text +.ft CW +.nf +.. +.de Ve \" End verbatim text +.ft R +.fi +.. +.Vb +$ ls +image.png +$ awsres image.png +AWSRes - Resource Creator v1.0 + +creating image.png... + -> registered + +$ ls +res.adb res.ads res-image_png.ads image.png +.Ve +.SH OPTIONS +.IP \fB-h\fR +Display help message. +.IP \fB-r\fR\ \fIname\fR +Set the root unit name. Default is `res'. +.IP \fB-q\fR +Quiet mode. +.SH "SEE ALSO" +.BR wsdl2aws (1) + +The Ada Web Server User's Guide in package libaws1-doc. +.SH AUTHOR +\fBawsres\fR was written by Dmitriy Anisimkov +and Pascal Obry as part of the Ada Web Server. + +This manual page was written by Ludovic Brenta + for Debian GNU/Linux. --- libaws-2.5~124785.orig/debian/aws.gpr +++ libaws-2.5~124785/debian/aws.gpr @@ -0,0 +1,47 @@ +-- Ada Web Server project file for use with GNAT 3.15p +-- Copyright (c) 2004, 2006, 2008 Ludovic Brenta +-- +-- This program is free software; you can redistribute it and/or modify +-- it under the terms of the GNU General Public License as published by +-- the Free Software Foundation; either version 2 of the License, or +-- (at your option) any later version. +-- +-- This program is distributed in the hope that it will be useful, +-- but WITHOUT ANY WARRANTY; without even the implied warranty of +-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +-- GNU General Public License for more details. +-- +-- This project file is designed to help build applications that use +-- Ada Web Server. Here is an example of how to use this project file: +-- +-- with "aws.gpr"; +-- project Example is +-- for Object_Dir use "obj"; +-- for Exec_Dir use "."; +-- for Main use ("example"); +-- end Example; + +with "xmlada.gpr"; +with "templates_parser.gpr"; +project AWS is + for Source_Dirs use ("/usr/share/ada/adainclude/aws"); + for Library_Name use "aws"; + for Library_ALI_Dir use "/usr/lib/ada/adalib/aws"; + for Library_Dir use "/usr/lib"; + for Library_Kind use "dynamic"; + for Externally_Built use "true"; + + package Naming is + -- Configuration for GNU/Linux using GNU TLS for strong crypto + for Body ("AWS.Net.SSL") use "aws-net-ssl__gnutls.adb"; + for Body ("AWS.Net.SSL.Certificate") + use "aws-net-ssl-certificate__gnutls.adb"; + for Body ("AWS.Net.Std") use "aws-net-std__gnat.adb"; + for Body ("AWS.OS_Lib") use "aws-os_lib__gnat.adb"; + for Body ("AWS.Translator.Conversion") + use "aws-translator-conversion__f.adb"; + for Spec ("SSL.Thin") use "ssl-thin__gnutls.ads"; + for Spec ("Templates_Parser.Configuration") + use "templates_parser-configuration__aws.ads"; + end Naming; +end AWS; --- libaws-2.5~124785.orig/debian/control +++ libaws-2.5~124785/debian/control @@ -0,0 +1,119 @@ +Source: libaws +Priority: optional +Section: libs +Maintainer: Ludovic Brenta +Build-Depends: debhelper (>= 5), gnat, gnat-4.3, quilt, libldap2-dev, texinfo, + zlib1g-dev, libxmlada-dev (>= 3.0), libasis-dev (>= 2007), + libtemplates-parser-dev (>= 11.1), + texlive-generic-recommended, texlive-fonts-recommended, texlive-latex-base +Standards-Version: 3.7.3 + +Package: libaws-dev +Section: libdevel +Architecture: alpha amd64 hppa i386 ia64 kfreebsd-i386 mips mipsel powerpc ppc64 s390 sparc +Depends: libaws2.5 (= ${source:Version}), gnat-4.3, libldap2-dev, + libtemplates-parser-dev (>= 11.1), libxmlada-dev (>= 3.0), zlib1g-dev +Recommends: libaws-bin (= ${source:Version}), libaws-doc (= ${source:Version}) +Description: Ada Web Server development files + AWS is a complete framework to develop Web based applications. The + main part of the framework is the embedded Web server. This small yet + powerful Web server can be embedded into your application so your + application will be able to talk with a Web browser. Around this Web + server a lot of services have been developed. + . + - A Web parameters module. This module takes care of retrieving the + forms or URL parameters and to build an associative table for easy + access. + - A session server, this is a very important module to be able to + keep client's data from page to page. + - Support SOAP to develop Web Services. + - A tool to generate Web Services stubs/skeletons from a WSDL + document. + - A template parser, this module makes it possible to completely + separate the Web design from the code. No more scripting into your Web + page. + - Support for Secure Sockets (HTTPS/SSL), this is based on the GNU TLS + library. + - Support for large servers using dispatchers based on URI, request + methods. + - Support for virtual hosting (dispatchers based on the host name). + - Support for server push. + - A directory browser ready to be used in any application. + - A status page to get many information about the current AWS server. + - A log module. Log files keep information about all resources + requested to the server. + - Hotplug modules which can be loaded/unloaded dynamically to add + specific features to a server. + - A communication API to exchange data between applications using the + HTTP protocol. + - A configuration API to tune/change the server parameters without + recompilation. + - A client API to retrieve any Web page from a Web site. + - A Web Page service to build a simple static page server. + - Support for SMTP, LDAP and Jabber protocols. + +Package: libaws-bin +Section: devel +Architecture: alpha amd64 hppa i386 ia64 kfreebsd-i386 mips mipsel powerpc ppc64 s390 sparc +Depends: ${shlibs:Depends} +Description: Ada Web Server utilities + AWS is a complete framework to develop Web based applications. The + main part of the framework is the embedded Web server. This small yet + powerful Web server can be embedded into your application so your + application will be able to talk with a Web browser. Around this Web + server a lot of services have been developed. + . + This package contains utility programs to help develop web applications + with AWS: + . + awsres transforms any text or binary file into an Ada unit which you + can compile into your application, thereby making your application + completely independent of any external files (think: embedded) + . + ada2wsdl, an ASIS program, reads Ada unit specifications and creates + descriptions in the Web Service Description Language, so that you can + advertise your web service application to the world. + . + wsdl2aws does the opposite job: it creates an Ada unit (spec and + skeleton body) conforming to a specified description in WSDL. + +Package: libaws2.5 +Section: libs +Architecture: alpha amd64 hppa i386 ia64 kfreebsd-i386 mips mipsel powerpc ppc64 s390 sparc +Depends: ${shlibs:Depends} +Description: Ada Web Server shared library + AWS is a complete framework to develop Web based applications. The + main part of the framework is the embedded Web server. This small yet + powerful Web server can be embedded into your application so your + application will be able to talk with a Web browser. Around this Web + server a lot of services have been developed. + . + This is the runtime library for the Ada Web Server. + +Package: libaws-dbg +Section: libdevel +Priority: extra +Architecture: alpha amd64 hppa i386 ia64 kfreebsd-i386 mips mipsel powerpc ppc64 s390 sparc +Depends: libaws-dev (=${source:Version}), ${shlibs:Depends} +Description: Debugging symbols for the Ada Web Server shared library + AWS is a complete framework to develop Web based applications. The + main part of the framework is the embedded Web server. This small yet + powerful Web server can be embedded into your application so your + application will be able to talk with a Web browser. Around this Web + server a lot of services have been developed. + . + This is the library containing debugging symbols for the Ada Web Server. + +Package: libaws-doc +Section: doc +Architecture: all +Description: Ada Web Server documentation + AWS is a complete framework to develop Web based applications. The + main part of the framework is the embedded Web server. This small yet + powerful Web server can be embedded into your application so your + application will be able to talk with a Web browser. Around this Web + server a lot of services have been developed. + . + This package contains the documentation for the Ada Web Server in + info, ASCII and HTML formats, as well as demos and source code of + reusable web elements. --- libaws-2.5~124785.orig/debian/wsdl2aws.1 +++ libaws-2.5~124785/debian/wsdl2aws.1 @@ -0,0 +1,142 @@ +.TH WSDL2AWS 1 "11 JUN 2004" "GNU Ada Tools" "AWS User's Guide" +.SH NAME +wsdl2aws \- Generate stubs and skeletons for web services +.SH SYNOPSIS +\fBwsdl2aws\fR [options] \fIURL\fR +.SH DESCRIPTION +The Ada Web Server is a library that allows you to embed a web server +into your Ada application. It provides not only HTTP but also SOAP, +WSDL and several other facilities. Thus you can write full-fledged +web applications. + +WSDL (Web Service Definition Language) is a language based on XML. +WSDL documents describe, in a formal way, the interface to Web +Services. This description consists of the end-point (URL to the +server offering the service), the SOAPAction (needed to call the +remote procedure), the procedure names and a description of the input +and output parameters. + +Using \fBwsdl2aws\fR, you can create both the client and server sides +of a Web Service. On both sides, the generated code handles +marshalling and unmarshalling of parameters and return values, so you +do not have to deal with SOAP directly. + +The client side is an Ada package that contains stubs for the remote +subprograms declared by the WSDL document. These stubs call the +remote subprograms using SOAP. + +The server side is another package consisting of skeleton +implementations of these subprograms. + +The \fIURL\fR points to the WSDL document to be processed. +.SH OPTIONS +.IP \fB-a\fR +Generate using Ada style names. For example `getPrice' will be +converted to `Get_Price'. This formatting is done for packages, +routines and formal parameters. + +.IP \fB-cb\fR +Generate a SOAP dispatcher callback routine for the server. This +dispatcher routine contains the code to handle all the operations as +described in the WSDL document. You need also to specify the +\fB-types\fR option, see below. + +.IP \fB-cvs\fR +Add CVS id tag in every generated file. + +.IP \fB-doc\fR +Handle document style binding as RPC ones. This is sometimes needed +because some WSDL documents specify a document style binding even +though it is really an RPC one. + +.IP \fB-f\fR +Force creation of the file. Overwrite any exiting files with the same +name. + +.IP \fB-main\fR\ \fIfilename\fR +Specify the name of the server's procedure main to generate. If file +\fIfilename\fR.amt (Ada Main Template) is present, it uses this template +file to generate the main procedure. The template can reference the +following variable tags: + +.RS +.IP \fBSOAP_SERVICE\fR +The name of the service as described into the WSDL document. This tag +can be used to include the right units + + with @_SOAP_SERVICE_@.Client; + with @_SOAP_SERVICE_@.CB; + +.IP \fBSOAP_VERSION\fR +The AWS SOAP version. + +.IP \fBBAWS_VERSION\fR +The AWS version. + +.IP \fBUNIT_NAME\fR +The name of the generated unit. This is the name of the +procedure that will be created. + + procedure @_UNIT_NAME_@ is + begin + ... +.RE + +.IP \fB-noskel\fR +Do not generate skeletons, only stubs. + +.IP \fB-nostub\fR +Do not generate stubs, only skeletons. + +.IP \fB-o\fR\ \fIname\fR +Specify the name of the local WSDL document. This option can be used +only when using a Web WSDL document (i.e. passing an URL to +\fBwsdl2aws\fR). + +.IP \fB-pp\fR\ \fIpassword\fR +User password for the proxy if proxy authentication required. + +.IP \fB-proxy\fR\ \fIname\|IP\fR +Use this proxy to access the WSDL document and generate code to +access to these Web Services via this proxy. The proxy can be +specified by its DNS name or IP address. + +.IP \fB-pu\fR\ \fIname\fR +User name for the proxy if proxy authentication required. + +.IP \fB-q\fR +Quiet mode (no output). + +.IP \fB-s\fR +Skip non supported SOAP routines. By default, \fBwsdl2aws\fR exits +with an error when a problem is found while parsing the WSDL +document. This option is useful to skip routines using non supported +types and still be able to compile the generated files. + +.IP \fB-types\fR\ \fIspec\fR +Specify the name of the spec containing the Ada implementation of the +SOAP routines. This is used for example by the \fB-cb\fR option above +to instantiate all the server side SOAP callbacks used by the main +SOAP dispatcher routine. + +.IP \fB-v\fR +Verbose mode, display the parsed spec. + +.IP \fB-v\ -v\fR +Verbose mode, display the parsed spec and lots of information while +parsing the WSDL document. + +.IP \fB-wsdl\fR +Add WSDL document as comment into the generated root unit. + +.SH "SEE ALSO" +.BR ada2wsdl (1), +.BR awsres (1) + +The Ada Web Server User's Guide in package libaws-doc. +.SH AUTHOR +\fBwsdl2aws\fR was written by Dmitriy Anisimkov +and Pascal Obry as part of the Ada Web Server. + +This manual page was written by Ludovic Brenta + for Debian GNU/Linux. --- libaws-2.5~124785.orig/debian/rules +++ libaws-2.5~124785/debian/rules @@ -0,0 +1,173 @@ +#!/usr/bin/make -f +# Debian build script for AWS - Copyright (c) 2003, 2004, 2005, 2006, +# 2008 Ludovic Brenta + +# This build script is free software; you can redistribute it and/or +# modify it under terms of the GNU General Public License as published +# by the Free Software Foundation; either version 2, or (at your +# option) any later version. This build script is distributed in the +# hope that it will be useful, but WITHOUT ANY WARRANTY; without even +# the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR +# PURPOSE. See the GNU General Public License for more details. You +# should have received a copy of the GNU General Public License +# distributed with this build script; see file +# /usr/share/common-licenses/GPL. If not, write to the Free Software +# Foundation, 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + +CC=gnatgcc + +# Parse the version number from the change log: +# major.minor~subversion_revision-upload +regexp :=Version: ([0-9]+)\.([0-9]+)~([0-9]+)-(.+) +major :=$(shell dpkg-parsechangelog | grep ^Version: | sed -r 's/$(regexp)/\1/') +minor :=$(shell dpkg-parsechangelog | grep ^Version: | sed -r 's/$(regexp)/\2/') +svnrev :=$(shell dpkg-parsechangelog | grep ^Version: | sed -r 's/$(regexp)/\3/') +upload :=$(shell dpkg-parsechangelog | grep ^Version: | sed -r 's/$(regexp)/\4/') + +file_to_spec=sed -e "s/\.ads//" -e "s/-/./g" -e "s!.*/!!g" + +DEB_BUILD_ARCH=$(shell dpkg-architecture -qDEB_BUILD_ARCH) +CPUS := $(shell getconf _NPROCESSORS_ONLN) + +.SUFFIXES: + +build: patch build-stamp +build-stamp: static-lib shared-lib tools doc + touch $@ + +clean: + dh_testdir + dh_testroot +# to avoid conflict with libtemplateparser includes + rm -f build-stamp + rm -rf debian/tmp obj-static obj-shared obj-tools libaws.so + $(MAKE) -C docs $@ + -quilt pop -a + dh_clean -a -i + +pre-binary-checks: + dh_testdir + dh_testroot + +binary-indep: build-stamp pre-binary-checks libaws-doc + dh_fixperms -i + dh_installchangelogs -i + dh_compress -i -X.adb -X.ads -X.thtml -X.wsdl + dh_installdeb -i + dh_gencontrol -i + dh_md5sums -i + dh_builddeb -i + +libaws-doc: + : # The doc package + dh_installinfo -p$@ docs/aws.info docs/style-guide.info + dh_installdocs -p$@ docs/*.html docs/*.txt docs/features readme.txt + dh_installexamples -p$@ demos/* -Xmakefile + dh_installexamples -p$@ web_elements + +DIRS := config include soap src ssl xsrc +SOURCES := $(foreach d,$(DIRS),$(wildcard $(d)/*.ad[bs])) + +binary-arch: libaws-dev libaws-bin libaws$(major).$(minor) + : # Common to all architecture-dependent packages + dh_installchangelogs -a + dh_installdocs -a + dh_compress -a + dh_fixperms -a -X.ali + dh_makeshlibs -a + dh_installdeb -a + dh_shlibdeps -a -Llibaws$(major).$(minor) -ldebian/libaws$(major).$(minor)/usr/lib + dh_gencontrol -a + dh_md5sums -a + dh_builddeb -a + +libaws-dev: build-stamp pre-binary-checks + : # The development package + dh_installdirs -p$@ \ + /usr/lib \ + /usr/share/ada/adainclude/aws \ + /usr/lib/ada/adalib/aws + dh_install -p$@ debian/tmp/libaws.a /usr/lib + dh_install -p$@ obj-shared/*.ali /usr/lib/ada/adalib/aws + dh_install -p$@ debian/aws.gpr /usr/share/ada/adainclude + dh_install -p$@ $(SOURCES) /usr/share/ada/adainclude/aws + dh_install -p$@ debian/tmp/aws-os_lib-definitions.ads \ + /usr/share/ada/adainclude/aws + dh_link -p$@ \ + usr/lib/libaws.so.$(major).$(minor) usr/lib/libaws.so + dh_strip -p$@ -X.a + +libaws-bin: build-stamp pre-binary-checks + : # The -bin package + dh_installdirs -p$@ /usr/bin + for i in ada2wsdl awsres wsdl2aws; do \ + if [ -x debian/tmp/$$i ] ; then \ + dh_install -p$@ debian/tmp/$$i /usr/bin; \ + dh_installman -p$@ debian/$$i.1; \ + fi \ + done + dh_strip -p$@ + +libaws$(major).$(minor): build-stamp pre-binary-checks + : # The shared library package + dh_install -p$@ debian/tmp/libaws.so.$(major).$(minor) /usr/lib + : # The package containing debugging symbols + dh_strip -p$@ --dbg-package=libaws-dbg + +binary: binary-indep binary-arch +.PHONY: build clean binary-indep binary-arch binary pre-binary-checks +.PHONY: libaws-doc libaws-dev libaws-bin libaws$(major).$(minor) + +patch: + -quilt push -a + +static-lib: debian/tmp/libaws.a +debian/tmp/libaws.a: debian/tmp/aws-os_lib-definitions.ads +debian/tmp/libaws.a: | debian/tmp obj-static + : # Build the static library + gnatmake -c -j$(CPUS) -g -Pdebian/build_aws.gpr -XOBJ_DIR=obj-static + ar rc $@ obj-static/*.o + ranlib $@ + +shared-lib: debian/tmp/libaws.so.$(major).$(minor) +debian/tmp/libaws.so.$(major).$(minor): debian/tmp/aws-os_lib-definitions.ads +debian/tmp/libaws.so.$(major).$(minor): | debian/tmp obj-shared + : # Build the shared library + gnatmake -c -j$(CPUS) -g -fPIC -Pdebian/build_aws.gpr -XOBJ_DIR=obj-shared + gnatgcc -shared -o $@ obj-shared/*.o \ + -lgnat -lgnarl -lxmlada -ltemplates_parser -lldap -lz \ + -Wl,--soname,libaws.so.$(major).$(minor) -Wl,--export-dynamic + chmod a=r obj-shared/*.ali + : # A symlink for to build the tools + ln -sf debian/tmp/libaws.so.$(major).$(minor) libaws.so + +debian/tmp/aws-os_lib-definitions.ads: debian/tmp/check_config | debian/tmp + $< $@ + +debian/tmp/check_config: config/src/check_config.c | debian/tmp + $(CC) -o $@ $< + +tools: debian/tmp/ada2wsdl debian/tmp/awsres debian/tmp/wsdl2aws + +debian/tmp/ada2wsdl: debian/tmp/libaws.so.$(major).$(minor) | debian/tmp obj-tools + gnatmake -j$(CPUS) -Pdebian/ada2wsdl.gpr -largs -L. + +debian/tmp/awsres debian/tmp/wsdl2aws: debian/tmp/libaws.so.$(major).$(minor) +debian/tmp/awsres debian/tmp/wsdl2aws: | debian/tmp obj-tools + : # Build awsres and wsdl2aws + gnatmake -j$(CPUS) -Pdebian/tools.gpr -largs -L. + +debian/tmp obj-static obj-shared: + -mkdir $@ + +obj-tools: obj-shared debian/tmp/libaws.so.$(major).$(minor) + -mkdir $@ + cp -p obj-shared/*.ali $@ + chmod a=r $(patsubst obj-shared/%,obj-tools/%,$(wildcard obj-shared/*.ali)) + +doc: + chmod u+x docs/gentexifile + $(MAKE) -C docs + +.PHONY: patch static-lib shared-lib tools doc + --- libaws-2.5~124785.orig/debian/ada2wsdl.gpr +++ libaws-2.5~124785/debian/ada2wsdl.gpr @@ -0,0 +1,41 @@ +with "asis.gpr"; +with "templates_parser.gpr"; +with "xmlada.gpr"; +project Ada2WSDL is + for Source_Dirs use ("../debian/tmp", "../config", + "../include", "../soap", "../src", + "../ssl", "../tools", "../xsrc"); + for Object_Dir use "../obj-tools"; + for Main use ("ada2wsdl-main.adb"); + for Exec_Dir use "tmp"; + + package Builder is + for Executable ("ada2wsdl-main.adb") use "ada2wsdl"; + end Builder; + + package Compiler is + for Default_Switches ("Ada") + use ("-O2", "-g", "-gnatafno", "-gnatVa", "-gnatwa"); + end Compiler; + + package Naming is + -- Configuration for GNU/Linux using GNU TLS for strong crypto + for Body ("AWS.Net.SSL") use "aws-net-ssl__gnutls.adb"; + for Body ("AWS.Net.SSL.Certificate") + use "aws-net-ssl-certificate__gnutls.adb"; + for Body ("AWS.Net.Std") use "aws-net-std__gnat.adb"; + -- for Body ("AWS.OS_Lib") use "aws-os_lib__gnat.adb"; + for Spec ("AWS.OS_Lib") use "aws-os_lib-definitions.ads"; + for Body ("AWS.Translator.Conversion") + use "aws-translator-conversion__f.adb"; + for Spec ("SSL.Thin") use "ssl-thin__gnutls.ads"; + for Spec ("Templates_Parser.Configuration") + use "templates_parser-configuration__aws.ads"; + end Naming; + + package Linker is + for Default_Switches ("Ada") use + ("-laws"); + end Linker; + +end Ada2WSDL; --- libaws-2.5~124785.orig/.pc/.version +++ libaws-2.5~124785/.pc/.version @@ -0,0 +1 @@ +2 --- libaws-2.5~124785.orig/lib/makefile +++ libaws-2.5~124785/lib/makefile @@ -18,12 +18,6 @@ # along with this library; if not, write to the Free Software Foundation, # # Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # # # -# As a special exception, if other files instantiate generics from this # -# unit, or you link this unit with other files to produce an executable, # -# this unit does not by itself cause the resulting executable to be # -# covered by the GNU General Public License. This exception does not # -# however invalidate any other reasons why the executable file might be # -# covered by the GNU Public License. # ############################################################################ .SILENT: --- libaws-2.5~124785.orig/config/aws-net-std__adasockets.adb +++ libaws-2.5~124785/config/aws-net-std__adasockets.adb @@ -18,12 +18,6 @@ -- along with this library; if not, write to the Free Software Foundation, -- -- Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. -- -- -- --- As a special exception, if other files instantiate generics from this -- --- unit, or you link this unit with other files to produce an executable, -- --- this unit does not by itself cause the resulting executable to be -- --- covered by the GNU General Public License. This exception does not -- --- however invalidate any other reasons why the executable file might be -- --- covered by the GNU Public License. -- ------------------------------------------------------------------------------ with Ada.Unchecked_Deallocation; --- libaws-2.5~124785.orig/docs/RFC.INDEX +++ libaws-2.5~124785/docs/RFC.INDEX @@ -0,0 +1,54 @@ + +List of RFC documents found in this repository +---------------------------------------------- + +RFC-821 SIMPLE MAIL TRANSFER PROTOCOL + +RFC-822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES + +RFC-1521 MIME (Multipurpose Internet Mail Extensions) Part One: + Mechanisms for Specifying and Describing + the Format of Internet Message Bodies + +RFC-1738 Uniform Resource Locators (URL) + +RFC-1867 Form-based File Upload in HTML + +RFC-1939 Post Office Protocol - Version 3 + +RFC-1945 Hypertext Transfer Protocol -- HTTP/1.0 + +RFC-2045 Multipurpose Internet Mail Extensions + (MIME) Part One: + Format of Internet Message Bodies + +RFC-2046 Multipurpose Internet Mail Extensions + (MIME) Part Two: + Media Types + +RFC-2049 Multipurpose Internet Mail Extensions + (MIME) Part Five: + Conformance Criteria and Examples + +RFC-2109 HTTP State Management Mechanism + +RFC-2183 Communicating Presentation Information in + Internet Messages: + The Content-Disposition Header Field + +RFC-2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response + +RFC-2387 The MIME Multipart/Related Content-type + +RFC-2554 SMTP Service Extension + for Authentication + +RFC-2595 Using TLS with IMAP, POP3 and ACAP + +RFC-2616 Hypertext Transfer Protocol -- HTTP/1.1 + +RFC-2617 HTTP Authentication: Basic and Digest Access Authentication + +RFC-2817 Upgrading to TLS Within HTTP/1.1 + +RFC-2818 HTTP Over TLS --- libaws-2.5~124785.orig/docs/draft302.txt +++ libaws-2.5~124785/docs/draft302.txt @@ -0,0 +1,3715 @@ +Transport Layer Security Working Group Alan O. Freier +INTERNET-DRAFT Netscape Communications +Expire in six months Philip Karlton + Netscape Communications + Paul C. Kocher + Independent Consultant + November 18, 1996 + + + + + + + + + + + The SSL Protocol + Version 3.0 + + + + + + + + + + +Status of this memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet- Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or made obsolete by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as work in + progress. + + To learn the current status of any Internet-Draft, please check the + 1id-abstracts.txt listing contained in the Internet Drafts Shadow + Directories on ds.internic.net (US East Coast), nic.nordu.net + (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific + Rim). + +Abstract + + This document specifies Version 3.0 of the Secure Sockets Layer + (SSL V3.0) protocol, a security protocol that provides + communications privacy over the Internet. The protocol allows + client/server applications to communicate in a way that is designed + to prevent eavesdropping, tampering, or message forgery. + + +Freier, Karlton, Kocher [Page 1] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + +Table of Contents + Status of this memo 1 + Abstract 1 + Table of Contents 2 + 1. Introduction 4 + 2. Goals 4 + 3. Goals of this document 5 + 4. Presentation language 5 + 4.1 Basic block size 5 + 4.2 Miscellaneous 6 + 4.3 Vectors 6 + 4.4 Numbers 7 + 4.5 Enumerateds 7 + 4.6 Constructed types 8 + 4.6.1 Variants 8 + 4.7 Cryptographic attributes 9 + 4.8 Constants 10 + 5. SSL protocol 10 + 5.1 Session and connection states 10 + 5.2 Record layer 12 + 5.2.1 Fragmentation 12 + 5.2.2 Record compression and decompression 13 + 5.2.3 Record payload protection and the CipherSpec 13 + 5.2.3.1 Null or standard stream cipher 14 + 5.2.3.2 CBC block cipher 15 + 5.3 Change cipher spec protocol 16 + 5.4 Alert protocol 16 + 5.4.1 Closure alerts 17 + 5.4.2 Error alerts 17 + 5.5 Handshake protocol overview 18 + 5.6 Handshake protocol 20 + 5.6.1 Hello messages 21 + 5.6.1.1 Hello request 21 + 5.6.1.2 Client hello 21 + 5.6.1.3 Server hello 24 + 5.6.2 Server certificate 25 + 5.6.3 Server key exchange message 25 + 5.6.4 Certificate request 27 + 5.6.5 Server hello done 27 + 5.6.6 Client certificate 28 + 5.6.7 Client key exchange message 28 + 5.6.7.1 RSA encrypted premaster secret message 28 + 5.6.7.2 FORTEZZA key exchange message 29 + 5.6.7.3 Client Diffie-Hellman public value 30 + 5.6.8 Certificate verify 30 + 5.6.9 Finished 31 + 5.7 Application data protocol 32 + 6. Cryptographic computations 32 + 6.1 Asymmetric cryptographic computations 32 + 6.1.1 RSA 32 + 6.1.2 Diffie-Hellman 33 + 6.1.3 FORTEZZA 33 + +Freier, Karlton, Kocher [Page 2] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + 6.2 Symmetric cryptographic calculations and the CipherSpec 33 + 6.2.1 The master secret 33 + 6.2.2 Converting the master secret into keys and MAC 33 + 6.2.2.1 Export key generation example 35 + A. Protocol constant values 36 + A.1 Reserved port assignments 36 + A.1.1 Record layer 36 + A.2 Change cipher specs message 37 + A.3 Alert messages 37 + A.4 Handshake protocol 37 + A.4.1 Hello messages 38 + A.4.2 Server authentication and key exchange messages 39 + A.5 Client authentication and key exchange messages 40 + A.5.1 Handshake finalization message 41 + A.6 The CipherSuite 41 + A.7 The CipherSpec 42 + B. Glossary 44 + C. CipherSuite definitions 47 + D. Implementation Notes 49 + D.1 Temporary RSA keys 49 + D.2 Random Number Generation and Seeding 49 + D.3 Certificates and authentication 50 + D.4 CipherSuites 50 + D.5 FORTEZZA 50 + D.5.1 Notes on use of FORTEZZA hardware 50 + D.5.2 FORTEZZA Ciphersuites 51 + D.5.3 FORTEZZA Session resumption 51 + E. Version 2.0 Backward Compatibility 52 + E.1 Version 2 client hello 52 + E.2 Avoiding man-in-the-middle version rollback 53 + F. Security analysis 55 + F.1 Handshake protocol 55 + F.1.1 Authentication and key exchange 55 + F.1.1.1 Anonymous key exchange 55 + F.1.1.2 RSA key exchange and authentication 56 + F.1.1.3 Diffie-Hellman key exchange with authentication 57 + F.1.1.4 FORTEZZA 57 + F.1.2 Version rollback attacks 57 + F.1.3 Detecting attacks against the handshake protocol 58 + F.1.4 Resuming sessions 58 + F.1.5 MD5 and SHA 58 + F.2 Protecting application data 59 + F.3 Final notes 59 + G. Patent Statement 60 + References 61 + Authors 62 + + + + + + + +Freier, Karlton, Kocher [Page 3] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + +1. Introduction + + The primary goal of the SSL Protocol is to provide privacy and + reliability between two communicating applications. The protocol + is composed of two layers. At the lowest level, layered on top of + some reliable transport protocol (e.g., TCP[TCP]), is the SSL + Record Protocol. The SSL Record Protocol is used for encapsulation + of various higher level protocols. One such encapsulated protocol, + the SSL Handshake Protocol, allows the server and client to + authenticate each other and to negotiate an encryption algorithm + and cryptographic keys before the application protocol transmits or + receives its first byte of data. One advantage of SSL is that it + is application protocol independent. A higher level protocol can + layer on top of the SSL Protocol transparently. The SSL protocol + provides connection security that has three basic properties: + + - The connection is private. Encryption is used after an + initial handshake to define a secret key. Symmetric + cryptography is used for data encryption (e.g., DES[DES], + RC4[RC4], etc.) + - The peer's identity can be authenticated using asymmetric, or + public key, cryptography (e.g., RSA[RSA], DSS[DSS], etc.). + - The connection is reliable. Message transport includes a + message integrity check using a keyed MAC. Secure hash + functions (e.g., SHA, MD5, etc.) are used for MAC + computations. + +2. Goals + + The goals of SSL Protocol v3.0, in order of their priority, + are: + 1. Cryptographic security + SSL should be used to establish a secure + connection between two parties. + 2. Interoperability + Independent programmers should be able to + develop applications utilizing SSL 3.0 that + will then be able to successfully exchange + cryptographic parameters without knowledge of + one another's code. + + Note: It is not the case that all instances of SSL (even + in the same application domain) will be able to + successfully connect. For instance, if the server + supports a particular hardware token, and the client + does not have access to such a token, then the + connection will not succeed. + + 3. Extensibility SSL seeks to provide a framework into which new + public key and bulk encryption methods can be + incorporated as necessary. This will also + accomplish two sub-goals: to prevent the need + +Freier, Karlton, Kocher [Page 4] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + to create a new protocol (and risking the + introduction of possible new weaknesses) and to + avoid the need to implement an entire new + security library. + 4. Relative efficiency + Cryptographic operations tend to be highly CPU + intensive, particularly public key operations. + For this reason, the SSL protocol has + incorporated an optional session caching scheme + to reduce the number of connections that need + to be established from scratch. Additionally, + care has been taken to reduce network activity. + +3. Goals of this document + + The SSL Protocol Version 3.0 Specification is intended primarily + for readers who will be implementing the protocol and those doing + cryptographic analysis of it. The spec has been written with this + in mind, and it is intended to reflect the needs of those two + groups. For that reason, many of the algorithm-dependent data + structures and rules are included in the body of the text (as + opposed to in an Appendix), providing easier access to them. + + This document is not intended to supply any details of service + definition nor interface definition, although it does cover select + areas of policy as they are required for the maintenance of solid + security. + +4. Presentation language + + This document deals with the formatting of data in an external + representation. The following very basic and somewhat casually + defined presentation syntax will be used. The syntax draws from + several sources in its structure. Although it resembles the + programming language "C" in its syntax and XDR [XDR] in both its + syntax and intent, it would be risky to draw too many parallels. + The purpose of this presentation language is to document SSL only, + not to have general application beyond that particular goal. + +4.1 Basic block size + + The representation of all data items is explicitly specified. The + basic data block size is one byte (i.e. 8 bits). Multiple byte + data items are concatenations of bytes, from left to right, from + top to bottom. From the bytestream a multi-byte item (a numeric in + the example) is formed (using C notation) by: + + value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ... + | byte[n-1]; + + This byte ordering for multi-byte values is the commonplace network + byte order or big endian format. + +Freier, Karlton, Kocher [Page 5] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + +4.2 Miscellaneous + + Comments begin with "/*" and end with "*/". + Optional components are denoted by enclosing them in "[[ ]]" double + brackets. + Single byte entities containing uninterpreted data are of type + opaque. + +4.3 Vectors + + A vector (single dimensioned array) is a stream of homogeneous data + elements. The size of the vector may be specified at documentation + time or left unspecified until runtime. In either case the length + declares the number of bytes, not the number of elements, in the + vector. The syntax for specifying a new type T' that is a fixed + length vector of type T is + + T T'[n]; + + Here T' occupies n bytes in the data stream, where n is a multiple + of the size of T. The length of the vector is not included in the + encoded stream. + + In the following example, Datum is defined to be three consecutive + bytes that the protocol does not interpret, while Data is three + consecutive Datum, consuming a total of nine bytes. + + opaque Datum[3]; /* three uninterpreted bytes */ + Datum Data[9]; /* 3 consecutive 3 byte vectors */ + + Variable length vectors are defined by specifying a subrange of + legal lengths, inclusively, using the notation . + When encoded, the actual length precedes the vector's contents in + the byte stream. The length will be in the form of a number + consuming as many bytes as required to hold the vector's specified + maximum (ceiling) length. A variable length vector with an actual + length field of zero is referred to as an empty vector. + + T T'; + + In the following example, mandatory is a vector that must contain + between 300 and 400 bytes of type opaque. It can never be empty. + The actual length field consumes two bytes, a uint16, sufficient to + represent the value 400 (see Section 4.4). On the other hand, + longer can represent up to 800 bytes of data, or 400 uint16 + elements, and it may be empty. Its encoding will include a two + byte actual length field prepended to the vector. + + opaque mandatory<300..400>; + /* length field is 2 bytes, cannot be empty */ + uint16 longer<0..800>; + /* zero to 400 16-bit unsigned integers */ + +Freier, Karlton, Kocher [Page 6] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + +4.4 Numbers + + The basic numeric data type is an unsigned byte (uint8). All + larger numeric data types are formed from fixed length series of + bytes concatenated as described in Section 4.1 and are also + unsigned. The following numeric types are predefined. + + uint8 uint16[2]; + uint8 uint24[3]; + uint8 uint32[4]; + uint8 uint64[8]; + +4.5 Enumerateds + + An additional sparse data type is available called enum. A field + of type enum can only assume the values declared in the definition. + Each definition is a different type. Only enumerateds of the same + type may be assigned or compared. Every element of an enumerated + must be assigned a value, as demonstrated in the following example. + Since the elements of the enumerated are not ordered, they can be + assigned any unique value, in any order. + + enum { e1(v1), e2(v2), ... , en(vn), [[(n)]] } Te; + + Enumerateds occupy as much space in the byte stream as would its + maximal defined ordinal value. The following definition would + cause one byte to be used to carry fields of type Color. + + enum { red(3), blue(5), white(7) } Color; + + One may optionally specify a value without its associated tag to + force the width definition without defining a superfluous element. + In the following example, Taste will consume two bytes in the data + stream but can only assume the values 1, 2 or 4. + + enum { sweet(1), sour(2), bitter(4), (32000) } Taste; + + The names of the elements of an enumeration are scoped within the + defined type. In the first example, a fully qualified reference to + the second element of the enumeration would be Color.blue. Such + qualification is not required if the target of the assignment is + well specified. + + Color color = Color.blue; /* overspecified, legal */ + Color color = blue; /* correct, type implicit */ + + For enumerateds that are never converted to external + representation, the numerical information may be omitted. + + enum { low, medium, high } Amount; + + + +Freier, Karlton, Kocher [Page 7] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + +4.6 Constructed types + + Structure types may be constructed from primitive types for + convenience. Each specification declares a new, unique type. The + syntax for definition is much like that of C. + + struct { + T1 f1; + T2 f2; + ... + Tn fn; + } [[T]]; + + The fields within a structure may be qualified using the type's + name using a syntax much like that available for enumerateds. For + example, T.f2 refers to the second field of the previous + declaration. Structure definitions may be embedded. + +4.6.1 Variants + + Defined structures may have variants based on some knowledge that + is available within the environment. The selector must be an + enumerated type that defines the possible variants the structure + defines. There must be a case arm for every element of the + enumeration declared in the select. The body of the variant + structure may be given a label for reference. The mechanism by + which the variant is selected at runtime is not prescribed by the + presentation language. + + struct { + T1 f1; + T2 f2; + .... + Tn fn; + select (E) { + case e1: Te1; + case e2: Te2; + .... + case en: Ten; + } [[fv]]; + } [[Tv]]; + + For example + + enum { apple, orange } VariantTag; + struct { + uint16 number; + opaque string<0..10>; /* variable length */ + } V1; + + + + +Freier, Karlton, Kocher [Page 8] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + struct { + uint32 number; + opaque string[10]; /* fixed length */ + } V2; + struct { + select (VariantTag) { /* value of selector is implicit */ + case apple: V1; /* VariantBody, tag = apple */ + case orange: V2; /* VariantBody, tag = orange */ + } variant_body; /* optional label on variant */ + } VariantRecord; + + Variant structures may be qualified (narrowed) by specifying a + value for the selector prior to the type. For example, a + + orange VariantRecord + + is a narrowed type of a VariantRecord containing a variant_body of + type V2. + +4.7 Cryptographic attributes + + The four cryptographic operations digital signing, stream cipher + encryption, block cipher encryption, and public key encryption are + designated digitally-signed, stream-ciphered, block-ciphered, and + public-key-encrypted, respectively. A field's cryptographic + processing is specified by prepending an appropriate key word + designation before the field's type specification. Cryptographic + keys are implied by the current session state (see Section 5.1). + + In digital signing, one-way hash functions are used as input for a + signing algorithm. In RSA signing, a 36-byte structure of two + hashes (one SHA and one MD5) is signed (encrypted with the private + key). In DSS, the 20 bytes of the SHA hash are run directly + through the Digital Signing Algorithm with no additional hashing. + + In stream cipher encryption, the plaintext is exclusive-ORed with + an identical amount of output generated from a + cryptographically-secure keyed pseudorandom number generator. + + In block cipher encryption, every block of plaintext encrypts to a + block of ciphertext. Because it is unlikely that the plaintext + (whatever data is to be sent) will break neatly into the necessary + block size (usually 64 bits), it is necessary to pad out the end of + short blocks with some regular pattern, usually all zeroes. + + In public key encryption, one-way functions with secret "trapdoors" + are used to encrypt the outgoing data. Data encrypted with the + public key of a given key pair can only be decrypted with the + private key, and vice-versa. In the following example: + + + + +Freier, Karlton, Kocher [Page 9] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + stream-ciphered struct { + uint8 field1; + uint8 field2; + digitally-signed opaque hash[20]; + } UserType; + + The contents of hash are used as input for the signing algorithm, + then the entire structure is encrypted with a stream cipher. + +4.8 Constants + + Typed constants can be defined for purposes of specification by + declaring a symbol of the desired type and assigning values to it. + Under-specified types (opaque, variable length vectors, and + structures that contain opaque) cannot be assigned values. No + fields of a multi-element structure or vector may be elided. + + For example, + struct { + uint8 f1; + uint8 f2; + } Example1; + + Example1 ex1 = {1, 4};/* assigns f1 = 1, f2 = 4 */ + +5. SSL protocol + + SSL is a layered protocol. At each layer, messages may include + fields for length, description, and content. SSL takes messages to + be transmitted, fragments the data into manageable blocks, + optionally compresses the data, applies a MAC, encrypts, and + transmits the result. Received data is decrypted, verified, + decompressed, and reassembled, then delivered to higher level + clients. + +5.1 Session and connection states + + An SSL session is stateful. It is the responsibility of the SSL + Handshake protocol to coordinate the states of the client and + server, thereby allowing the protocol state machines of each to + operate consistently, despite the fact that the state is not + exactly parallel. Logically the state is represented twice, once + as the current operating state, and (during the handshake protocol) + again as the pending state. Additionally, separate read and write + states are maintained. When the client or server receives a change + cipher spec message, it copies the pending read state into the + current read state. When the client or server sends a change + cipher spec message, it copies the pending write state into the + current write state. When the handshake negotiation is complete, + the client and server exchange change cipher spec messages (see + Section 5.3), and they then communicate using the newly agreed-upon + cipher spec. + +Freier, Karlton, Kocher [Page 10] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + An SSL session may include multiple secure connections; in + addition, parties may have multiple simultaneous sessions. + + The session state includes the following elements: + + session identifier + An arbitrary byte sequence chosen by the server + to identify an active or resumable session + state. + peer certificate X509.v3[X509] certificate of the peer. This + element of the state may be null. + compression method + The algorithm used to compress data prior to + encryption. + cipher spec Specifies the bulk data encryption algorithm + (such as null, DES, etc.) and a MAC algorithm + (such as MD5 or SHA). It also defines + cryptographic attributes such as the hash_size. + (See Appendix A.7 for formal definition) + master secret 48-byte secret shared between the client and + server. + is resumable A flag indicating whether the session can be + used to initiate new connections. + + The connection state includes the following elements: + + server and client random + Byte sequences that are chosen by the server + and client for each connection. + server write MAC secret + The secret used in MAC operations on data + written by the server + client write MAC secret + The secret used in MAC operations on data + written by the client. + server write key The bulk cipher key for data encrypted by the + server and decrypted by the client. + client write key The bulk cipher key for data encrypted by the + client and decrypted by the server. + initialization vectors + When a block cipher in CBC mode is used, an + initialization vector (IV) is maintained for + each key. This field is first initialized by + the SSL handshake protocol. Thereafter the + final ciphertext block from each record is + preserved for use with the following record. + sequence numbers Each party maintains separate sequence numbers + for transmitted and received messages for each + connection. When a party sends or receives a + change cipher spec message, the appropriate + sequence number is set to zero. Sequence + + +Freier, Karlton, Kocher [Page 11] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + numbers are of type uint64 and may not exceed + 2^64-1. + +5.2 Record layer + + The SSL Record Layer receives uninterpreted data from higher layers + in non-empty blocks of arbitrary size. + +5.2.1 Fragmentation + + The record layer fragments information blocks into SSLPlaintext + records of 2^14 bytes or less. Client message boundaries are not + preserved in the record layer (i.e., multiple client messages of + the same ContentType may be coalesced into a single SSLPlaintext + record). + + struct { + uint8 major, minor; + } ProtocolVersion; + + enum { + change_cipher_spec(20), alert(21), handshake(22), + application_data(23), (255) + } ContentType; + + struct { + ContentType type; + ProtocolVersion version; + uint16 length; + opaque fragment[SSLPlaintext.length]; + } SSLPlaintext; + + type The higher level protocol used to process the + enclosed fragment. + version The version of protocol being employed. This + document describes SSL Version 3.0 (See + Appendix A.1.1). + length The length (in bytes) of the following + SSLPlaintext.fragment. The length should not + exceed 2^14. + fragment The application data. This data is transparent + and treated as an independent block to be dealt + with by the higher level protocol specified by + the type field. + + Note: Data of different SSL Record layer content types may + be interleaved. Application data is generally of + lower precedence for transmission than other content + types. + + + + +Freier, Karlton, Kocher [Page 12] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + +5.2.2 Record compression and decompression + + All records are compressed using the compression algorithm defined + in the current session state. There is always an active + compression algorithm, however initially it is defined as + CompressionMethod.null. The compression algorithm translates an + SSLPlaintext structure into an SSLCompressed structure. + Compression functions erase their state information whenever the + CipherSpec is replaced. + + Note: The CipherSpec is part of the session state + described in Section 5.1. References to fields of + the CipherSpec are made throughout this document + using presentation syntax. A more complete + description of the CipherSpec is shown in Appendix + A.7. + + Compression must be lossless and may not increase the content + length by more than 1024 bytes. If the decompression function + encounters an SSLCompressed.fragment that would decompress to a + length in excess of 2^14 bytes, it should issue a fatal + decompression_failure alert (Section 5.4.2). + + struct { + ContentType type; /* same as SSLPlaintext.type */ + ProtocolVersion version;/* same as SSLPlaintext.version */ + uint16 length; + opaque fragment[SSLCompressed.length]; + } SSLCompressed; + + length The length (in bytes) of the following + SSLCompressed.fragment. The length + should not exceed 2^14 + 1024. + fragment The compressed form of + SSLPlaintext.fragment. + + Note: A CompressionMethod.null operation is an identity + operation; no fields are altered. + (See Appendix A.4.1) + + Implementation note: + Decompression functions are responsible for + ensuring that messages cannot cause internal buffer + overflows. + +5.2.3 Record payload protection and the CipherSpec + + All records are protected using the encryption and MAC algorithms + defined in the current CipherSpec. There is always an active + CipherSpec, however initially it is SSL_NULL_WITH_NULL_NULL, which + does not provide any security. + + +Freier, Karlton, Kocher [Page 13] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Once the handshake is complete, the two parties have shared secrets + which are used to encrypt records and compute keyed message + authentication codes (MACs) on their contents. The techniques used + to perform the encryption and MAC operations are defined by the + CipherSpec and constrained by CipherSpec.cipher_type. The + encryption and MAC functions translate an SSLCompressed structure + into an SSLCiphertext. The decryption functions reverse the + process. Transmissions also include a sequence number so that + missing, altered, or extra messages are detectable. + + struct { + ContentType type; + ProtocolVersion version; + uint16 length; + select (CipherSpec.cipher_type) { + case stream: GenericStreamCipher; + case block: GenericBlockCipher; + } fragment; + } SSLCiphertext; + + type The type field is identical to + SSLCompressed.type. + version The version field is identical to + SSLCompressed.version. + length The length (in bytes) of the following + SSLCiphertext.fragment. The length may + not exceed 2^14 + 2048. + fragment The encrypted form of + SSLCompressed.fragment, including the + MAC. + +5.2.3.1 Null or standard stream cipher + + Stream ciphers (including BulkCipherAlgorithm.null - see Appendix + A.7) convert SSLCompressed.fragment structures to and from stream + SSLCiphertext.fragment structures. + + stream-ciphered struct { + opaque content[SSLCompressed.length]; + opaque MAC[CipherSpec.hash_size]; + } GenericStreamCipher; + + The MAC is generated as: + + hash(MAC_write_secret + pad_2 + + hash(MAC_write_secret + pad_1 + seq_num + + SSLCompressed.type + SSLCompressed.length + + SSLCompressed.fragment)); + + where "+" denotes concatenation. + + + +Freier, Karlton, Kocher [Page 14] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + pad_1 The character 0x36 repeated 48 times for MD5 + or 40 times for SHA. + pad_2 The character 0x5c repeated 48 times for MD5 + or 40 times for SHA. + seq_num The sequence number for this message. + hash Hashing algorithm derived from the cipher + suite. + + Note that the MAC is computed before encryption. The stream cipher + encrypts the entire block, including the MAC. For stream ciphers + that do not use a synchronization vector (such as RC4), the stream + cipher state from the end of one record is simply used on the + subsequent packet. If the CipherSuite is SSL_NULL_WITH_NULL_NULL, + encryption consists of the identity operation (i.e., the data is + not encrypted and the MAC size is zero implying that no MAC is + used). SSLCiphertext.length is SSLCompressed.length plus + CipherSpec.hash_size. + +5.2.3.2 CBC block cipher + + For block ciphers (such as RC2 or DES), the encryption and MAC + functions convert SSLCompressed.fragment structures to and from + block SSLCiphertext.fragment structures. + + block-ciphered struct { + opaque content[SSLCompressed.length]; + opaque MAC[CipherSpec.hash_size]; + uint8 padding[GenericBlockCipher.padding_length]; + uint8 padding_length; + } GenericBlockCipher; + + The MAC is generated as described in Section 5.2.3.1. + + padding Padding that is added to force the length of + the plaintext to be a multiple of the block + cipher's block length. + padding_length The length of the padding must be less than the + cipher's block length and may be zero. The + padding length should be such that the total + size of the GenericBlockCipher structure is a + multiple of the cipher's block length. + + The encrypted data length (SSLCiphertext.length) is one more than + the sum of SSLCompressed.length, CipherSpec.hash_size, and + padding_length. + + Note: With CBC block chaining the initialization vector + (IV) for the first record is provided by the + handshake protocol. The IV for subsequent records + is the last ciphertext block from the previous + record. + + +Freier, Karlton, Kocher [Page 15] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + +5.3 Change cipher spec protocol + + The change cipher spec protocol exists to signal transitions in + ciphering strategies. The protocol consists of a single message, + which is encrypted and compressed under the current (not the + pending) CipherSpec. The message consists of a single byte of + value 1. + + struct { + enum { change_cipher_spec(1), (255) } type; + } ChangeCipherSpec; + + The change cipher spec message is sent by both the client and + server to notify the receiving party that subsequent records will + be protected under the just-negotiated CipherSpec and keys. + Reception of this message causes the receiver to copy the read + pending state into the read current state. The client sends a + change cipher spec message following handshake key exchange and + certificate verify messages (if any), and the server sends one + after successfully processing the key exchange message it received + from the client. An unexpected change cipher spec message should + generate an unexpected_message alert (Section 5.4.2). When + resuming a previous session, the change cipher spec message is sent + after the hello messages. + +5.4 Alert protocol + + One of the content types supported by the SSL Record layer is the + alert type. Alert messages convey the severity of the message and + a description of the alert. Alert messages with a level of fatal + result in the immediate termination of the connection. In this + case, other connections corresponding to the session may continue, + but the session identifier must be invalidated, preventing the + failed session from being used to establish new connections. Like + other messages, alert messages are encrypted and compressed, as + specified by the current connection state. + + enum { warning(1), fatal(2), (255) } AlertLevel; + + enum { + close_notify(0), + unexpected_message(10), + bad_record_mac(20), + decompression_failure(30), + handshake_failure(40), + no_certificate(41), + bad_certificate(42), + unsupported_certificate(43), + certificate_revoked(44), + certificate_expired(45), + certificate_unknown(46), + + +Freier, Karlton, Kocher [Page 16] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + illegal_parameter (47) + (255) + } AlertDescription; + + struct { + AlertLevel level; + AlertDescription description; + } Alert; + +5.4.1 Closure alerts + + The client and the server must share knowledge that the connection + is ending in order to avoid a truncation attack. Either party may + initiate the exchange of closing messages. + + close_notify This message notifies the recipient that the + sender will not send any more messages on this + connection. The session becomes unresumable if + any connection is terminated without proper + close_notify messages with level equal to + warning. + + Either party may initiate a close by sending a close_notify alert. + Any data received after a closure alert is ignored. + + Each party is required to send a close_notify alert before closing + the write side of the connection. It is required that the other + party respond with a close_notify alert of its own and close down + the connection immediately, discarding any pending writes. It is + not required for the initiator of the close to wait for the + responding close_notify alert before closing the read side of the + connection. + + NB: It is assumed that closing a connection reliably delivers + pending data before destroying the transport. + + +5.4.2 Error alerts + + Error handling in the SSL Handshake protocol is very simple. When + an error is detected, the detecting party sends a message to the + other party. Upon transmission or receipt of an fatal alert + message, both parties immediately close the connection. Servers + and clients are required to forget any session-identifiers, keys, + and secrets associated with a failed connection. The following + error alerts are defined: + + unexpected_message + An inappropriate message was received. This + alert is always fatal and should never be + observed in communication between proper + implementations. + +Freier, Karlton, Kocher [Page 17] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + bad_record_mac This alert is returned if a record is received + with an incorrect MAC. This message is always + fatal. + decompression_failure + The decompression function received improper + input (e.g. data that would expand to excessive + length). This message is always fatal. + handshake_failure Reception of a handshake_failure alert message + indicates that the sender was unable to + negotiate an acceptable set of security + parameters given the options available. This + is a fatal error. + no_certificate A no_certificate alert message may be sent in + response to a certification request if no + appropriate certificate is available. + bad_certificate A certificate was corrupt, contained signatures + that did not verify correctly, etc. + unsupported_certificate + A certificate was of an unsupported type. + certificate_revoked + A certificate was revoked by its signer. + certificate_expired + A certificate has expired or is not currently + valid. + certificate_unknown + Some other (unspecified) issue arose in + processing the certificate, rendering it + unacceptable. + illegal_parameter A field in the handshake was out of range or + inconsistent with other fields. This is always + fatal. + +5.5 Handshake protocol overview + + The cryptographic parameters of the session state are produced by + the SSL Handshake Protocol, which operates on top of the SSL Record + Layer. When a SSL client and server first start communicating, + they agree on a protocol version, select cryptographic algorithms, + optionally authenticate each other, and use public-key encryption + techniques to generate shared secrets. These processes are + performed in the handshake protocol, which can be summarized as + follows: The client sends a client hello message to which the + server must respond with a server hello message, or else a fatal + error will occur and the connection will fail. The client hello + and server hello are used to establish security enhancement + capabilities between client and server. The client hello and + server hello establish the following attributes: Protocol Version, + Session ID, Cipher Suite, and Compression Method. Additionally, + two random values are generated and exchanged: ClientHello.random + and ServerHello.random. + + + +Freier, Karlton, Kocher [Page 18] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Following the hello messages, the server will send its certificate, + if it is to be authenticated. Additionally, a server key exchange + message may be sent, if it is required (e.g. if their server has no + certificate, or if its certificate is for signing only). If the + server is authenticated, it may request a certificate from the + client, if that is appropriate to the cipher suite selected. Now + the server will send the server hello done message, indicating that + the hello-message phase of the handshake is complete. The server + will then wait for a client response. If the server has sent a + certificate request Message, the client must send either the + certificate message or a no_certificate alert. The client key + exchange message is now sent, and the content of that message will + depend on the public key algorithm selected between the client + hello and the server hello. If the client has sent a certificate + with signing ability, a digitally-signed certificate verify message + is sent to explicitly verify the certificate. + + At this point, a change cipher spec message is sent by the client, + and the client copies the pending Cipher Spec into the current + Cipher Spec. The client then immediately sends the finished + message under the new algorithms, keys, and secrets. In response, + the server will send its own change cipher spec message, transfer + the pending to the current Cipher Spec, and send its finished + message under the new Cipher Spec. At this point, the handshake is + complete and the client and server may begin to exchange + application layer data. (See flow chart below.) + + Client Server + + ClientHello --------> + ServerHello + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + * Indicates optional or situation-dependent messages that are not + always sent. + + Note: To help avoid pipeline stalls, ChangeCipherSpec is + an independent SSL Protocol content type, and is not + actually an SSL handshake message. + + + +Freier, Karlton, Kocher [Page 19] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + When the client and server decide to resume a previous session or + duplicate an existing session (instead of negotiating new security + parameters) the message flow is as follows: + + The client sends a ClientHello using the Session ID of the session + to be resumed. The server then checks its session cache for a + match. If a match is found, and the server is willing to + re-establish the connection under the specified session state, it + will send a ServerHello with the same Session ID value. At this + point, both client and server must send change cipher spec messages + and proceed directly to finished messages. Once the + re-establishment is complete, the client and server may begin to + exchange application layer data. (See flow chart below.) If a + Session ID match is not found, the server generates a new session + ID and the SSL client and server perform a full handshake. + + Client Server + + ClientHello --------> + ServerHello + [change cipher spec] + <-------- Finished + change cipher spec + Finished --------> + Application Data <-------> Application Data + + The contents and significance of each message will be presented in + detail in the following sections. + +5.6 Handshake protocol + + The SSL Handshake Protocol is one of the defined higher level + clients of the SSL Record Protocol. This protocol is used to + negotiate the secure attributes of a session. Handshake messages + are supplied to the SSL Record Layer, where they are encapsulated + within one or more SSLPlaintext structures, which are processed and + transmitted as specified by the current active session state. + + enum { + hello_request(0), client_hello(1), server_hello(2), + certificate(11), server_key_exchange (12), + certificate_request(13), server_hello_done(14), + certificate_verify(15), client_key_exchange(16), + finished(20), (255) + } HandshakeType; + + struct { + HandshakeType msg_type; /* handshake type */ + uint24 length; /* bytes in message */ + select (HandshakeType) { + case hello_request: HelloRequest; + case client_hello: ClientHello; + +Freier, Karlton, Kocher [Page 20] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + case server_hello: ServerHello; + case certificate: Certificate; + case server_key_exchange: ServerKeyExchange; + case certificate_request: CertificateRequest; + case server_hello_done: ServerHelloDone; + case certificate_verify: CertificateVerify; + case client_key_exchange: ClientKeyExchange; + case finished: Finished; + } body; + } Handshake; + + The handshake protocol messages are presented in the order they + must be sent; sending handshake messages in an unexpected order + results in a fatal error. + +5.6.1 Hello messages + + The hello phase messages are used to exchange security enhancement + capabilities between the client and server. When a new session + begins, the CipherSpec encryption, hash, and compression algorithms + are initialized to null. The current CipherSpec is used for + renegotiation messages. + +5.6.1.1 Hello request + + The hello request message may be sent by the server at any time, + but will be ignored by the client if the handshake protocol is + already underway. It is a simple notification that the client + should begin the negotiation process anew by sending a client hello + message when convenient. + + Note: Since handshake messages are intended to have + transmission precedence over application data, it is + expected that the negotiation begin in no more than + one or two times the transmission time of a maximum + length application data message. + + After sending a hello request, servers should not repeat the + request until the subsequent handshake negotiation is complete. A + client that receives a hello request while in a handshake + negotiation state should simply ignore the message. + + The structure of a hello request message is as follows: + + struct { } HelloRequest; + +5.6.1.2 Client hello + + When a client first connects to a server it is required to send the + client hello as its first message. The client can also send a + client hello in response to a hello request or on its own + initiative in order to renegotiate the security parameters in an + +Freier, Karlton, Kocher [Page 21] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + existing connection. The client hello message includes a random + structure, which is used later in the protocol. + + struct { + uint32 gmt_unix_time; + opaque random_bytes[28]; + } Random; + + gmt_unix_time The current time and date in standard UNIX + 32-bit format according to the sender's + internal clock. Clocks are not required to be + set correctly by the basic SSL Protocol; higher + level or application protocols may define + additional requirements. + random_bytes 28 bytes generated by a secure random number + generator. + + The client hello message includes a variable length session + identifier. If not empty, the value identifies a session between + the same client and server whose security parameters the client + wishes to reuse. The session identifier may be from an earlier + connection, this connection, or another currently active + connection. The second option is useful if the client only wishes + to update the random structures and derived values of a connection, + while the third option makes it possible to establish several + simultaneous independent secure connections without repeating the + full handshake protocol. The actual contents of the SessionID are + defined by the server. + + opaque SessionID<0..32>; + + Warning: Servers must not place confidential information in + session identifiers or let the contents of fake + session identifiers cause any breach of security. + + The CipherSuite list, passed from the client to the server in the + client hello message, contains the combinations of cryptographic + algorithms supported by the client in order of the client's + preference (first choice first). Each CipherSuite defines both a + key exchange algorithm and a CipherSpec. The server will select a + cipher suite or, if no acceptable choices are presented, return a + handshake failure alert and close the connection. + + uint8 CipherSuite[2]; /* Cryptographic suite selector */ + + The client hello includes a list of compression algorithms + supported by the client, ordered according to the client's + preference. If the server supports none of those specified by the + client, the session must fail. + + enum { null(0), (255) } CompressionMethod; + + +Freier, Karlton, Kocher [Page 22] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Issue: Which compression methods to support is under + investigation. + + The structure of the client hello is as follows. + struct { + ProtocolVersion client_version; + Random random; + SessionID session_id; + CipherSuite cipher_suites<2..2^16-1>; + CompressionMethod compression_methods<1..2^8-1>; + } ClientHello; + + client_version The version of the SSL protocol by which the + client wishes to communicate during this + session. This should be the most recent + (highest valued) version supported by the + client. For this version of the specification, + the version will be 3.0 (See Appendix E for + details about backward compatibility). + random A client-generated random structure. + session_id The ID of a session the client wishes to use + for this connection. This field should be + empty if no session_id is available or the + client wishes to generate new security + parameters. + cipher_suites This is a list of the cryptographic options + supported by the client, sorted with the + client's first preference first. If the + session_id field is not empty (implying a + session resumption request) this vector must + include at least the cipher_suite from that + session. Values are defined in Appendix A.6. + compression_methods + This is a list of the compression methods + supported by the client, sorted by client + preference. If the session_id field is not + empty (implying a session resumption request) + this vector must include at least the + compression_method from that session. All + implementations must support + CompressionMethod.null. + + After sending the client hello message, the client waits for a + server hello message. Any other handshake message returned by the + server except for a hello request is treated as a fatal error. + + Implementation note: + Application data may not be sent before a finished + message has been sent. Transmitted application data + is known to be insecure until a valid finished + message has been received. This absolute + + +Freier, Karlton, Kocher [Page 23] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + restriction is relaxed if there is a current, + non-null encryption on this connection. + + Forward compatibility note: + In the interests of forward compatibility, it is + permitted for a client hello message to include + extra data after the compression methods. This data + must be included in the handshake hashes, but must + otherwise be ignored. + +5.6.1.3 Server hello + + The server processes the client hello message and responds with + either a handshake_failure alert or server hello message. + + struct { + ProtocolVersion server_version; + Random random; + SessionID session_id; + CipherSuite cipher_suite; + CompressionMethod compression_method; + } ServerHello; + + server_version This field will contain the lower of that + suggested by the client in the client hello and + the highest supported by the server. For this + version of the specification, the version will + be 3.0 (See Appendix E for details about + backward compatibility). + random This structure is generated by the server and + must be different from (and independent of) + ClientHello.random. + session_id This is the identity of the session + corresponding to this connection. If the + ClientHello.session_id was non-empty, the + server will look in its session cache for a + match. If a match is found and the server is + willing to establish the new connection using + the specified session state, the server will + respond with the same value as was supplied by + the client. This indicates a resumed session + and dictates that the parties must proceed + directly to the finished messages. Otherwise + this field will contain a different value + identifying the new session. The server may + return an empty session_id to indicate that the + session will not be cached and therefore cannot + be resumed. + cipher_suite The single cipher suite selected by the server + from the list in ClientHello.cipher_suites. + For resumed sessions this field is the value + from the state of the session being resumed. + +Freier, Karlton, Kocher [Page 24] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + compression_method + The single compression algorithm selected by + the server from the list in + ClientHello.compression_methods. For resumed + sessions this field is the value from the + resumed session state. + +5.6.2 Server certificate + + If the server is to be authenticated (which is generally the case), + the server sends its certificate immediately following the server + hello message. The certificate type must be appropriate for the + selected cipher suite's key exchange algorithm, and is generally an + X.509.v3 certificate (or a modified X.509 certificate in the case + of FORTEZZA(tm) [FOR]). The same message type will be used for the + client's response to a certificate request message. + + opaque ASN.1Cert<1..2^24-1>; + struct { + ASN.1Cert certificate_list<1..2^24-1>; + } Certificate; + + certificate_list This is a sequence (chain) of X.509.v3 + certificates, ordered with the sender's + certificate first followed by any certificate + authority certificates proceeding sequentially + upward. + + Note: PKCS #7 [PKCS7] is not used as the format for the + certificate vector because PKCS #6 [PKCS6] extended + certificates are not used. Also PKCS #7 defines a + SET rather than a SEQUENCE, making the task of + parsing the list more difficult. + +5.6.3 Server key exchange message + + The server key exchange message is sent by the server if it has no + certificate, has a certificate only used for signing (e.g., DSS + [DSS] certificates, signing-only RSA [RSA] certificates), or + FORTEZZA KEA key exchange is used. This message is not used if the + server certificate contains Diffie-Hellman [DH1] parameters. + + Note: According to current US export law, RSA moduli + larger than 512 bits may not be used for key + exchange in software exported from the US. With + this message, larger RSA keys may be used as + signature-only certificates to sign temporary + shorter RSA keys for key exchange. + + enum { rsa, diffie_hellman, fortezza_kea } + KeyExchangeAlgorithm; + + +Freier, Karlton, Kocher [Page 25] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + struct { + opaque rsa_modulus<1..2^16-1>; + opaque rsa_exponent<1..2^16-1>; + } ServerRSAParams; + + rsa_modulus The modulus of the server's temporary RSA key. + rsa_exponent The public exponent of the server's temporary + RSA key. + + struct { + opaque dh_p<1..2^16-1>; + opaque dh_g<1..2^16-1>; + opaque dh_Ys<1..2^16-1>; + } ServerDHParams; /* Ephemeral DH parameters */ + + dh_p The prime modulus used for the Diffie-Hellman + operation. + dh_g The generator used for the Diffie-Hellman + operation. + dh_Ys The server's Diffie-Hellman public value + (gX mod p). + + struct { + opaque r_s [128]; + } ServerFortezzaParams; + + r_s Server random number for FORTEZZA KEA (Key + Exchange Algorithm). + + struct { + select (KeyExchangeAlgorithm) { + case diffie_hellman: + ServerDHParams params; + Signature signed_params; + case rsa: + ServerRSAParams params; + Signature signed_params; + case fortezza_kea: + ServerFortezzaParams params; + }; + } ServerKeyExchange; + + params The server's key exchange parameters. + signed_params A hash of the corresponding params value, with + the signature appropriate to that hash applied. + md5_hash MD5(ClientHello.random + ServerHello.random + + ServerParams); + sha_hash SHA(ClientHello.random + ServerHello.random + + ServerParams); + + enum { anonymous, rsa, dsa } SignatureAlgorithm; + + +Freier, Karlton, Kocher [Page 26] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + digitally-signed struct { + select(SignatureAlgorithm) { + case anonymous: struct { }; + case rsa: + opaque md5_hash[16]; + opaque sha_hash[20]; + case dsa: + opaque sha_hash[20]; + }; + } Signature; + + +5.6.4 Certificate request + + A non-anonymous server can optionally request a certificate from + the client, if appropriate for the selected cipher suite. + + enum { + rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), + rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_kea(20), + (255) + } ClientCertificateType; + + opaque DistinguishedName<1..2^16-1>; + + struct { + ClientCertificateType certificate_types<1..2^8-1>; + DistinguishedName certificate_authorities<3..2^16-1>; + } CertificateRequest; + + certificate_types This field is a list of the types of + certificates requested, sorted in order of the + server's preference. + certificate_authorities + A list of the distinguished names of acceptable + certificate authorities. + + Note: DistinguishedName is derived from [X509]. + + Note: It is a fatal handshake_failure alert for an + anonymous server to request client identification. + +5.6.5 Server hello done + + The server hello done message is sent by the server to indicate the + end of the server hello and associated messages. After sending + this message the server will wait for a client response. + + struct { } ServerHelloDone; + + + + +Freier, Karlton, Kocher [Page 27] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Upon receipt of the server hello done message the client should + verify that the server provided a valid certificate if required and + check that the server hello parameters are acceptable. + +5.6.6 Client certificate + + This is the first message the client can send after receiving a + server hello done message. This message is only sent if the server + requests a certificate. If no suitable certificate is available, + the client should send a no_certificate alert instead. This alert + is only a warning, however the server may respond with a fatal + handshake failure alert if client authentication is required. + Client certificates are sent using the Certificate defined in + Section 5.6.2. + + Note: Client Diffie-Hellman certificates must match the + server specified Diffie-Hellman parameters. + +5.6.7 Client key exchange message + + The choice of messages depends on which public key algorithm(s) has + (have) been selected. See Section 5.6.3 for the + KeyExchangeAlgorithm definition. + + struct { + select (KeyExchangeAlgorithm) { + case rsa: EncryptedPreMasterSecret; + case diffie_hellman: ClientDiffieHellmanPublic; + case fortezza_kea: FortezzaKeys; + } exchange_keys; + } ClientKeyExchange; + + The information to select the appropriate record structure is in + the pending session state (see Section 5.1). + +5.6.7.1 RSA encrypted premaster secret message + + If RSA is being used for key agreement and authentication, the + client generates a 48-byte pre-master secret, encrypts it under the + public key from the server's certificate or temporary RSA key from + a server key exchange message, and sends the result in an encrypted + premaster secret message. + + struct { + ProtocolVersion client_version; + opaque random[46]; + } PreMasterSecret; + + client_version The latest (newest) version supported by the + client. This is used to detect version + roll-back attacks. + random 46 securely-generated random bytes. + +Freier, Karlton, Kocher [Page 28] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + struct { + public-key-encrypted PreMasterSecret pre_master_secret; + } EncryptedPreMasterSecret; + + pre_master_secret This random value is generated by the client + and is used to generate the master secret, as + specified in Section 6.1. + +5.6.7.2 FORTEZZA key exchange message + + Under FORTEZZA, the client derives a Token Encryption Key (TEK) + using the FORTEZZA Key Exchange Algorithm (KEA). The client's KEA + calculation uses the public key in the server's certificate along + with private parameters in the client's token. The client sends + public parameters needed for the server to generate the TEK, using + its own private parameters. The client generates session keys, + wraps them using the TEK, and sends the results to the server. The + client generates IV's for the session keys and TEK and sends them + also. The client generates a random 48-byte premaster secret, + encrypts it using the TEK, and sends the result: + + struct { + opaque y_c<0..128>; + opaque r_c[128]; + opaque y_signature[40]; + opaque wrapped_client_write_key[12]; + opaque wrapped_server_write_key[12]; + opaque client_write_iv[24]; + opaque server_write_iv[24]; + opaque master_secret_iv[24]; + block-ciphered opaque encrypted_pre_master_secret[48]; + } FortezzaKeys; + + y_signature y_signature is the signature of the KEA public + key, signed with the client's DSS private key. + y_c The client's Yc value (public key) for the KEA + calculation. If the client has sent a + certificate, and its KEA public key is + suitable, this value must be empty since the + certificate already contains this value. If + the client sent a certificate without a + suitable public key, y_c is used and + y_signature is the KEA public key signed with + the client's DSS private key. For this value + to be used, it must be between 64 and 128 + bytes. + r_c The client's Rc value for the KEA calculation. + wrapped_client_write_key + This is the client's write key, wrapped by the + TEK. + + + +Freier, Karlton, Kocher [Page 29] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + wrapped_server_write_key + This is the server's write key, wrapped by the + TEK. + client_write_iv The IV for the client write key. + server_write_iv The IV for the server write key. + master_secret_iv This is the IV for the TEK used to encrypt the + pre-master secret. + pre_master_secret A random value, generated by the client and + used to generate the master secret, as + specified in Section 6.1. In the the above + structure, it is encrypted using the TEK. + +5.6.7.3 Client Diffie-Hellman public value + + This structure conveys the client's Diffie-Hellman public value + (Yc) if it was not already included in the client's certificate. + The encoding used for Yc is determined by the enumerated + PublicValueEncoding. + + enum { implicit, explicit } PublicValueEncoding; + + implicit If the client certificate already contains the + public value, then it is implicit and Yc does + not need to be sent again. + explicit Yc needs to be sent. + + struct { + select (PublicValueEncoding) { + case implicit: struct { }; + case explicit: opaque dh_Yc<1..2^16-1>; + } dh_public; + } ClientDiffieHellmanPublic; + + dh_Yc The client's Diffie-Hellman public value (Yc). + +5.6.8 Certificate verify + + This message is used to provide explicit verification of a client + certificate. This message is only sent following any client + certificate that has signing capability (i.e. all certificates + except those containing fixed Diffie-Hellman parameters). + + struct { + Signature signature; + } CertificateVerify; + + CertificateVerify.signature.md5_hash + MD5(master_secret + pad_2 + + MD5(handshake_messages + master_secret + pad_1)); + Certificate.signature.sha_hash + SHA(master_secret + pad_2 + + SHA(handshake_messages + master_secret + pad_1)); + +Freier, Karlton, Kocher [Page 30] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + pad_1 This is identical to the pad_1 defined in + section 5.2.3.1. + pad_2 This is identical to the pad_2 defined in + section 5.2.3.1. + + Here handshake_messages refers to all handshake messages starting + at client hello up to but not including this message. + +5.6.9 Finished + + A finished message is always sent immediately after a change cipher + specs message to verify that the key exchange and authentication + processes were successful. The finished message is the first + protected with the just-negotiated algorithms, keys, and secrets. + No acknowledgment of the finished message is required; parties may + begin sending encrypted data immediately after sending the finished + message. Recipients of finished messages must verify that the + contents are correct. + + enum { client(0x434C4E54), server(0x53525652) } Sender; + + struct { + opaque md5_hash[16]; + opaque sha_hash[20]; + } Finished; + + md5_hash MD5(master_secret + pad2 + + MD5(handshake_messages + Sender + + master_secret + pad1)); + sha_hash SHA(master_secret + pad2 + + SHA(handshake_messages + Sender + + master_secret + pad1)); + + handshake_messages All of the data from all handshake messages + up to but not including this message. This + is only data visible at the handshake layer + and does not include record layer headers. + + It is a fatal error if a finished message is not preceeded by a + change cipher spec message at the appropriate point in the + handshake. + + The hash contained in finished messages sent by the server + incorporate Sender.server; those sent by the client incorporate + Sender.client. The value handshake_messages includes all handshake + messages starting at client hello up to, but not including, this + finished message. This may be different from handshake_messages in + Section 5.6.8 because it would include the certificate verify + message (if sent). + + + + +Freier, Karlton, Kocher [Page 31] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Note: Change cipher spec messages are not handshake + messages and are not included in the hash + computations. + +5.7 Application data protocol + + Application data messages are carried by the Record Layer and are + fragmented, compressed and encrypted based on the current + connection state. The messages are treated as transparent data to + the record layer. + +6. Cryptographic computations + + The key exchange, authentication, encryption, and MAC algorithms + are determined by the cipher_suite selected by the server and + revealed in the server hello message. + +6.1 Asymmetric cryptographic computations + + The asymmetric algorithms are used in the handshake protocol to + authenticate parties and to generate shared keys and secrets. + + For Diffie-Hellman, RSA, and FORTEZZA, the same algorithm is used + to convert the pre_master_secret into the master_secret. The + pre_master_secret should be deleted from memory once the + master_secret has been computed. + + master_secret = + MD5(pre_master_secret + SHA('A' + pre_master_secret + + ClientHello.random + ServerHello.random)) + + MD5(pre_master_secret + SHA('BB' + pre_master_secret + + ClientHello.random + ServerHello.random)) + + MD5(pre_master_secret + SHA('CCC' + pre_master_secret + + ClientHello.random + ServerHello.random)); + +6.1.1 RSA + + When RSA is used for server authentication and key exchange, a + 48-byte pre_master_secret is generated by the client, encrypted + under the server's public key, and sent to the server. The server + uses its private key to decrypt the pre_master_secret. Both + parties then convert the pre_master_secret into the master_secret, + as specified above. + + RSA digital signatures are performed using PKCS #1 [PKCS1] block + type 1. RSA public key encryption is performed using PKCS #1 block + type 2. + + + + + + +Freier, Karlton, Kocher [Page 32] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + +6.1.2 Diffie-Hellman + + A conventional Diffie-Hellman computation is performed. The + negotiated key (Z) is used as the pre_master_secret, and is + converted into the master_secret, as specified above. + + Note: Diffie-Hellman parameters are specified by the + server, and may be either ephemeral or contained + within the server's certificate. + +6.1.3 FORTEZZA + + A random 48-byte pre_master_secret is sent encrypted under the TEK + and its IV. The server decrypts the pre_master_secret and converts + it into a master_secret, as specified above. Bulk cipher keys and + IVs for encryption are generated by the client's token and + exchanged in the key exchange message; the master_secret is only + used for MAC computations. + +6.2 Symmetric cryptographic calculations and the CipherSpec + + The technique used to encrypt and verify the integrity of SSL + records is specified by the currently active CipherSpec. A typical + example would be to encrypt data using DES and generate + authentication codes using MD5. The encryption and MAC algorithms + are set to SSL_NULL_WITH_NULL_NULL at the beginning of the SSL + Handshake Protocol, indicating that no message authentication or + encryption is performed. The handshake protocol is used to + negotiate a more secure CipherSpec and to generate cryptographic + keys. + +6.2.1 The master secret + + Before secure encryption or integrity verification can be performed + on records, the client and server need to generate shared secret + information known only to themselves. This value is a 48-byte + quantity called the master secret. The master secret is used to + generate keys and secrets for encryption and MAC computations. + Some algorithms, such as FORTEZZA, may have their own procedure for + generating encryption keys (the master secret is used only for MAC + computations in FORTEZZA). + +6.2.2 Converting the master secret into keys and MAC secrets + + The master secret is hashed into a sequence of secure bytes, which + are assigned to the MAC secrets, keys, and non-export IVs required + by the current CipherSpec (see Appendix A.7). CipherSpecs require + a client write MAC secret, a server write MAC secret, a client + write key, a server write key, a client write IV, and a server + write IV, which are generated from the master secret in that order. + Unused values, such as FORTEZZA keys communicated in the + + +Freier, Karlton, Kocher [Page 33] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + KeyExchange message, are empty. The following inputs are available + to the key definition process: + + opaque MasterSecret[48] + ClientHello.random + ServerHello.random + + When generating keys and MAC secrets, the master secret is used as + an entropy source, and the random values provide unencrypted salt + material and IVs for exportable ciphers. + + To generate the key material, compute + + key_block = + MD5(master_secret + SHA(`A' + master_secret + + ServerHello.random + + ClientHello.random)) + + MD5(master_secret + SHA(`BB' + master_secret + + ServerHello.random + + ClientHello.random)) + + MD5(master_secret + SHA(`CCC' + master_secret + + ServerHello.random + + ClientHello.random)) + [...]; + + until enough output has been generated. Then the key_block is + partitioned as follows. + + client_write_MAC_secret[CipherSpec.hash_size] + server_write_MAC_secret[CipherSpec.hash_size] + client_write_key[CipherSpec.key_material] + server_write_key[CipherSpec.key_material] + client_write_IV[CipherSpec.IV_size] /* non-export ciphers */ + server_write_IV[CipherSpec.IV_size] /* non-export ciphers */ + + Any extra key_block material is discarded. + + Exportable encryption algorithms (for which + CipherSpec.is_exportable is true) require additional processing as + follows to derive their final write keys: + + final_client_write_key = MD5(client_write_key + + ClientHello.random + + ServerHello.random); + final_server_write_key = MD5(server_write_key + + ServerHello.random + + ClientHello.random); + + Exportable encryption algorithms derive their IVs from the random + messages: + + client_write_IV = MD5(ClientHello.random + ServerHello.random); + server_write_IV = MD5(ServerHello.random + ClientHello.random); + +Freier, Karlton, Kocher [Page 34] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + MD5 outputs are trimmed to the appropriate size by discarding the + least-significant bytes. + +6.2.2.1 Export key generation example + + SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for + each of the two encryption keys and 16 bytes for each of the MAC + keys, for a total of 42 bytes of key material. MD5 produces 16 + bytes of output per call, so three calls to MD5 are required. The + MD5 outputs are concatenated into a 48-byte key_block with the + first MD5 call providing bytes zero through 15, the second + providing bytes 16 through 31, etc. The key_block is partitioned, + and the write keys are salted because this is an exportable + encryption algorithm. + + client_write_MAC_secret = key_block[0..15] + server_write_MAC_secret = key_block[16..31] + client_write_key = key_block[32..36] + server_write_key = key_block[37..41] + final_client_write_key = MD5(client_write_key + + ClientHello.random + + ServerHello.random)[0..15]; + final_server_write_key = MD5(server_write_key + + ServerHello.random + + ClientHello.random)[0..15]; + client_write_IV = MD5(ClientHello.random + + ServerHello.random)[0..7]; + server_write_IV = MD5(ServerHello.random + + ClientHello.random)[0..7]; + + + + + + + + + + + + + + + + + + + + + + + + +Freier, Karlton, Kocher [Page 35] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Appendix A + +A. Protocol constant values + + This section describes protocol types and constants. + +A.1 Reserved port assignments + + At the present time SSL is implemented using TCP/IP as the base + networking technology. The IANA reserved the following Internet + Protocol [IP] port numbers for use in conjunction with SSL. + + 443 Reserved for use by Hypertext Transfer Protocol with + SSL (https). + 465 Reserved (pending) for use by Simple Mail Transfer Protocol + with SSL (ssmtp). + 563 Reserved (pending) for use by Network News Transfer + Protocol (snntp). + +A.1.1 Record layer + + struct { + uint8 major, minor; + } ProtocolVersion; + + ProtocolVersion version = { 3,0 }; + + enum { + change_cipher_spec(20), alert(21), handshake(22), + application_data(23), (255) + } ContentType; + + struct { + ContentType type; + ProtocolVersion version; + uint16 length; + opaque fragment[SSLPlaintext.length]; + } SSLPlaintext; + + struct { + ContentType type; + ProtocolVersion version; + uint16 length; + opaque fragment[SSLCompressed.length]; + } SSLCompressed; + + struct { + ContentType type; + ProtocolVersion version; + uint16 length; + select (CipherSpec.cipher_type) { + case stream: GenericStreamCipher; + +Freier, Karlton, Kocher [Page 36] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + case block: GenericBlockCipher; + } fragment; + } SSLCiphertext; + + stream-ciphered struct { + opaque content[SSLCompressed.length]; + opaque MAC[CipherSpec.hash_size]; + } GenericStreamCipher; + + block-ciphered struct { + opaque content[SSLCompressed.length]; + opaque MAC[CipherSpec.hash_size]; + uint8 padding[GenericBlockCipher.padding_length]; + uint8 padding_length; + } GenericBlockCipher; + +A.2 Change cipher specs message + + struct { + enum { change_cipher_spec(1), (255) } type; + } ChangeCipherSpec; + +A.3 Alert messages + + enum { warning(1), fatal(2), (255) } AlertLevel; + + enum { + close_notify(0), + unexpected_message(10), + bad_record_mac(20), + decompression_failure(30), + handshake_failure(40), + no_certificate(41), + bad_certificate(42), + unsupported_certificate(43), + certificate_revoked(44), + certificate_expired(45), + certificate_unknown(46), + illegal_parameter (47), + (255) + } AlertDescription; + + struct { + AlertLevel level; + AlertDescription description; + } Alert; + +A.4 Handshake protocol + + enum { + hello_request(0), client_hello(1), server_hello(2), + certificate(11), server_key_exchange (12), + +Freier, Karlton, Kocher [Page 37] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + certificate_request(13), server_done(14), + certificate_verify(15), client_key_exchange(16), + finished(20), (255) + } HandshakeType; + + struct { + HandshakeType msg_type; + uint24 length; + select (HandshakeType) { + case hello_request: HelloRequest; + case client_hello: ClientHello; + case server_hello: ServerHello; + case certificate: Certificate; + case server_key_exchange: ServerKeyExchange; + case certificate_request: CertificateRequest; + case server_done: ServerHelloDone; + case certificate_verify: CertificateVerify; + case client_key_exchange: ClientKeyExchange; + case finished: Finished; + } body; + } Handshake; + +A.4.1 Hello messages + + struct { } HelloRequest; + + struct { + uint32 gmt_unix_time; + opaque random_bytes[28]; + } Random; + + opaque SessionID<0..32>; + + uint8 CipherSuite[2]; + + enum { null(0), (255) } CompressionMethod; + + struct { + ProtocolVersion client_version; + Random random; + SessionID session_id; + CipherSuite cipher_suites<0..2^16-1>; + CompressionMethod compression_methods<0..2^8-1>; + } ClientHello; + + struct { + ProtocolVersion server_version; + Random random; + SessionID session_id; + CipherSuite cipher_suite; + CompressionMethod compression_method; + } ServerHello; + +Freier, Karlton, Kocher [Page 38] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + +A.4.2 Server authentication and key exchange messages + + opaque ASN.1Cert<2^24-1>; + + struct { + ASN.1Cert certificate_list<1..2^24-1>; + } Certificate; + + enum { rsa, diffie_hellman, fortezza_kea } KeyExchangeAlgorithm; + + struct { + opaque RSA_modulus<1..2^16-1>; + opaque RSA_exponent<1..2^16-1>; + } ServerRSAParams; + + struct { + opaque DH_p<1..2^16-1>; + opaque DH_g<1..2^16-1>; + opaque DH_Ys<1..2^16-1>; + } ServerDHParams; + + struct { + opaque r_s [128] + } ServerFortezzaParams + + struct { + select (KeyExchangeAlgorithm) { + case diffie_hellman: + ServerDHParams params; + Signature signed_params; + case rsa: + ServerRSAParams params; + Signature signed_params; + case fortezza_kea: + ServerFortezzaParams params; + }; + } ServerKeyExchange; + + enum { anonymous, rsa, dsa } SignatureAlgorithm; + + digitally-signed struct { + select(SignatureAlgorithm) { + case anonymous: struct { }; + case rsa: + opaque md5_hash[16]; + opaque sha_hash[20]; + case dsa: + opaque sha_hash[20]; + }; + } Signature; + + + +Freier, Karlton, Kocher [Page 39] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + enum { + RSA_sign(1), DSS_sign(2), RSA_fixed_DH(3), + DSS_fixed_DH(4), RSA_ephemeral_DH(5), DSS_ephemeral_DH(6), + FORTEZZA_MISSI(20), (255) + } CertificateType; + + opaque DistinguishedName<1..2^16-1>; + + struct { + CertificateType certificate_types<1..2^8-1>; + DistinguishedName certificate_authorities<3..2^16-1>; + } CertificateRequest; + + struct { } ServerHelloDone; + +A.5 Client authentication and key exchange messages + + struct { + select (KeyExchangeAlgorithm) { + case rsa: EncryptedPreMasterSecret; + case diffie_hellman: DiffieHellmanClientPublicValue; + case fortezza_kea: FortezzaKeys; + } exchange_keys; + } ClientKeyExchange; + + struct { + ProtocolVersion client_version; + opaque random[46]; + } PreMasterSecret; + + struct { + public-key-encrypted PreMasterSecret pre_master_secret; + } EncryptedPreMasterSecret; + + struct { + opaque y_c<0..128>; + opaque r_c[128]; + opaque y_signature[40]; + opaque wrapped_client_write_key[12]; + opaque wrapped_server_write_key[12]; + opaque client_write_iv[24]; + opaque server_write_iv[24]; + opaque master_secret_iv[24]; + opaque encrypted_preMasterSecret[48]; + } FortezzaKeys; + + enum { implicit, explicit } PublicValueEncoding; + + struct { + select (PublicValueEncoding) { + case implicit: struct {}; + case explicit: opaque DH_Yc<1..2^16-1>; + +Freier, Karlton, Kocher [Page 40] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + } dh_public; + } ClientDiffieHellmanPublic; + + struct { + Signature signature; + } CertificateVerify; + +A.5.1 Handshake finalization message + + struct { + opaque md5_hash[16]; + opaque sha_hash[20]; + } Finished; + +A.6 The CipherSuite + + The following values define the CipherSuite codes used in the + client hello and server hello messages. + + A CipherSuite defines a cipher specifications supported in SSL + Version 3.0. + + CipherSuite SSL_NULL_WITH_NULL_NULL = { 0x00,0x00 }; + + The following CipherSuite definitions require that the server + provide an RSA certificate that can be used for key exchange. The + server may request either an RSA or a DSS signature-capable + certificate in the certificate request message. + + CipherSuite SSL_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; + CipherSuite SSL_RSA_WITH_NULL_SHA = { 0x00,0x02 }; + CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; + CipherSuite SSL_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; + CipherSuite SSL_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; + CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; + CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; + CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; + CipherSuite SSL_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; + CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; + + The following CipherSuite definitions are used for + server-authenticated (and optionally client-authenticated) + Diffie-Hellman. DH denotes cipher suites in which the server's + certificate contains the Diffie-Hellman parameters signed by the + certificate authority (CA). DHE denotes ephemeral Diffie-Hellman, + where the Diffie-Hellman parameters are signed by a DSS or RSA + certificate, which has been signed by the CA. The signing + algorithm used is specified after the DH or DHE parameter. In all + cases, the client must have the same type of certificate, and must + use the Diffie-Hellman parameters chosen by the server. + + + +Freier, Karlton, Kocher [Page 41] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; + CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; + CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; + CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; + CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; + CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; + CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; + CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; + CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; + CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; + CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; + CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; + + The following cipher suites are used for completely anonymous + Diffie-Hellman communications in which neither party is + authenticated. Note that this mode is vulnerable to + man-in-the-middle attacks and is therefore strongly discouraged. + + CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; + CipherSuite SSL_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; + CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; + CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; + CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; + + The final cipher suites are for the FORTEZZA token. + + CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA = { 0X00,0X1C }; + CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = { 0x00,0x1D }; + CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA = { 0x00,0x1E }; + + Note: All cipher suites whose first byte is 0xFF are + considered private and can be used for defining + local/experimental algorithms. Interoperability of + such types is a local matter. + + Note: Additional cipher suites will be considered for + implementation only with submission of notarized + letters from two independent entities. Netscape + Communications Corp. will act as an interim + registration office, until a public standards body + assumes control of SSL. + +A.7 The CipherSpec + + A cipher suite identifies a CipherSpec. These structures are part + of the SSL session state. The CipherSpec includes: + + enum { stream, block } CipherType; + + enum { true, false } IsExportable; + + + +Freier, Karlton, Kocher [Page 42] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + enum { null, rc4, rc2, des, 3des, des40, fortezza } + BulkCipherAlgorithm; + + enum { null, md5, sha } MACAlgorithm; + + struct { + BulkCipherAlgorithm bulk_cipher_algorithm; + MACAlgorithm mac_algorithm; + CipherType cipher_type; + IsExportable is_exportable + uint8 hash_size; + uint8 key_material; + uint8 IV_size; + } CipherSpec; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Freier, Karlton, Kocher [Page 43] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Appendix B + +B. Glossary + application protocol An application protocol is a protocol that + normally layers directly on top of the + transport layer (e.g., TCP/IP). Examples + include HTTP, TELNET, FTP, and SMTP. + asymmetric cipher See public key cryptography. + authentication Authentication is the ability of one entity + to determine the identity of another entity. + block cipher A block cipher is an algorithm that operates + on plaintext in groups of bits, called + blocks. 64 bits is a typical block size. + bulk cipher A symmetric encryption algorithm used to + encrypt large quantities of data. + cipher block chaining + Mode (CBC) CBC is a mode in which every + plaintext block encrypted with the block + cipher is first exclusive-ORed with the + previous ciphertext block (or, in the case + of the first block, with the initialization + vector). + certificate As part of the X.509 protocol (a.k.a. ISO + Authentication framework), certificates are + assigned by a trusted Certificate Authority + and provide verification of a party's + identity and may also supply its public key. + client The application entity that initiates a + connection to a server. + client write key The key used to encrypt data written by the + client. + client write MAC secret + The secret data used to authenticate data + written by the client. + connection A connection is a transport (in the OSI + layering model definition) that provides a + suitable type of service. For SSL, such + connections are peer to peer relationships. + The connections are transient. Every + connection is associated with one session. + Data Encryption Standard + (DES) DES is a very widely used symmetric + encryption algorithm. DES is a block + cipher. + Digital Signature Standard + (DSS) A standard for digital signing, + including the Digital Signing Algorithm, + approved by the National Institute of + Standards and Technology, defined in NIST + FIPS PUB 186, "Digital Signature Standard," + published May, 1994 by the U.S. Dept. of + Commerce. + +Freier, Karlton, Kocher [Page 44] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + digital signatures Digital signatures utilize public key + cryptography and one-way hash functions to + produce a signature of the data that can be + authenticated, and is difficult to forge or + repudiate. + FORTEZZA A PCMCIA card that provides both encryption + and digital signing. + handshake An initial negotiation between client and + server that establishes the parameters of + their transactions. + Initialization Vector + (IV) When a block cipher is used in CBC + mode, the initialization vector is + exclusive-ORed with the first plaintext + block prior to encryption. + IDEA A 64-bit block cipher designed by Xuejia Lai + and James Massey. + Message Authentication Code + (MAC) A Message Authentication Code is a + one-way hash computed from a message and + some secret data. Its purpose is to detect + if the message has been altered. + master secret Secure secret data used for generating + encryption keys, MAC secrets, and IVs. + MD5 MD5 [7] is a secure hashing function that + converts an arbitrarily long data stream + into a digest of fixed size. + public key cryptography + A class of cryptographic techniques + employing two-key ciphers. Messages + encrypted with the public key can only be + decrypted with the associated private key. + Conversely, messages signed with the private + key can be verified with the public key. + one-way hash function + A one-way transformation that converts an + arbitrary amount of data into a fixed-length + hash. It is computation- ally hard to + reverse the transformation or to find + collisions. MD5 and SHA are examples of + one-way hash functions. + RC2, RC4 Proprietary bulk ciphers from RSA Data + Security, Inc. (There is no good reference + to these as they are unpublished works; + however, see [RSADSI]). RC2 is block cipher + and RC4 is a stream cipher. + RSA A very widely used public-key algorithm that + can be used for either encryption or digital + signing. + salt Non-secret random data used to make export + encryption keys resist precomputation + attacks. + +Freier, Karlton, Kocher [Page 45] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + server The server is the application entity that + responds to requests for connections from + clients. The server is passive, waiting for + requests from clients. + session A SSL session is an association between a + client and a server. Sessions are created + by the handshake protocol. Sessions define + a set of cryptographic security parameters, + which can be shared among multiple + connections. Sessions are used to avoid the + expensive negotiation of new security + parameters for each connection. + session identifier A session identifier is a value generated by + a server that identifies a particular + session. + server write key The key used to encrypt data written by the + server. + server write MAC secret + The secret data used to authenticate data + written by the server. + SHA The Secure Hash Algorithm is defined in FIPS + PUB 180-1. It produces a 20-byte output + [SHA]. + stream cipher An encryption algorithm that converts a key + into a cryptographically-strong keystream, + which is then exclusive-ORed with the + plaintext. + symmetric cipher See bulk cipher. + + + + + + + + + + + + + + + + + + + + + + + + + +Freier, Karlton, Kocher [Page 46] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Appendix C + +C. CipherSuite definitions + +CipherSuite Is Key Cipher Hash + Exportable Exchange + +SSL_NULL_WITH_NULL_NULL * NULL NULL NULL +SSL_RSA_WITH_NULL_MD5 * RSA NULL MD5 +SSL_RSA_WITH_NULL_SHA * RSA NULL SHA +SSL_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5 +SSL_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 +SSL_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA +SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5 +SSL_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA +SSL_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA +SSL_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA +SSL_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA +SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA +SSL_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA +SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA +SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA +SSL_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA +SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA +SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA +SSL_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA +SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA +SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA +SSL_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA +SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA +SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5 +SSL_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 +SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA +SSL_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA +SSL_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA +SSL_FORTEZZA_KEA_WITH_NULL_SHA FORTEZZA_KEA NULL SHA +SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA FORTEZZA_KEA FORTEZZA_CBC SHA +SSL_FORTEZZA_KEA_WITH_RC4_128_SHA FORTEZZA_KEA RC4_128 SHA + + * Indicates IsExportable is True + + Key Description Key size limit + Exchange + Algorithm + DHE_DSS Ephemeral DH with DSS signatures None + DHE_DSS_EXPORT Ephemeral DH with DSS signatures DH = 512 bits + DHE_RSA Ephemeral DH with RSA signatures None + DHE_RSA_EXPORT Ephemeral DH with RSA signatures DH = 512 bits, + RSA = none + DH_anon Anonymous DH, no signatures None + DH_anon_EXPORT Anonymous DH, no signatures DH = 512 bits + DH_DSS DH with DSS-based certificates None + +Freier, Karlton, Kocher [Page 47] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + DH_DSS_EXPORT DH with DSS-based certificates DH = 512 bits + DH_RSA DH with RSA-based certificates None + DH_RSA_EXPORT DH with RSA-based certificates DH = 512 bits, + RSA = none + FORTEZZA_KEA FORTEZZA KEA. Details unpublished N/A + NULL No key exchange N/A + RSA RSA key exchange None + RSA_EXPORT RSA key exchange RSA = 512 bits + + Key size limit The key size limit gives the size of the + largest public key that can be legally + used for encryption in cipher suites that + are exportable. + + Cipher Cipher IsExpo Key Exp. Effect IV Block + Type rtable Material Key Mat ive Key Size Size + erial Bits + + NULL Stream * 0 0 0 0 N/A + FORTEZZA_CBC Block NA(**) 12(**) 96(**) 20(**) 8 + IDEA_CBC Block 16 16 128 8 8 + RC2_CBC_40 Block * 5 16 40 8 8 + RC4_40 Stream * 5 16 40 0 N/A + RC4_128 Stream 16 16 128 0 N/A + DES40_CBC Block * 5 8 40 8 8 + DES_CBC Block 8 8 56 8 8 + 3DES_EDE_CBC Block 24 24 168 8 8 + + * Indicates IsExportable is true. + ** FORTEZZA uses its own key and IV generation algorithms. + + Key Material The number of bytes from the key_block that are + used for generating the write keys. + Expanded Key Material + The number of bytes actually fed into the + encryption algorithm. + Effective Key Bits + How much entropy material is in the key + material being fed into the encryption + routines. + + Hash Hash Size Padding + function Size + NULL 0 0 + MD5 16 48 + SHA 20 40 + + + + + + + +Freier, Karlton, Kocher [Page 48] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Appendix D + +D. Implementation Notes + + The SSL protocol cannot prevent many common security mistakes. + This section provides several recommendations to assist + implementers. + + +D.1 Temporary RSA keys + + US Export restrictions limit RSA keys used for encryption to 512 + bits, but do not place any limit on lengths of RSA keys used for + signing operations. Certificates often need to be larger than 512 + bits, since 512-bit RSA keys are not secure enough for high-value + transactions or for applications requiring long-term security. + Some certificates are also designated signing-only, in which case + they cannot be used for key exchange. + + When the public key in the certificate cannot be used for + encryption, the server signs a temporary RSA key, which is then + exchanged. In exportable applications, the temporary RSA key + should be the maximum allowable length (i.e., 512 bits). Because + 512-bit RSA keys are relatively insecure, they should be changed + often. For typical electronic commerce applications, it is + suggested that keys be changed daily or every 500 transactions, and + more often if possible. Note that while it is acceptable to use + the same temporary key for multiple transactions, it must be signed + each time it is used. + + RSA key generation is a time-consuming process. In many cases, a + low-priority process can be assigned the task of key generation. + Whenever a new key is completed, the existing temporary key can be + replaced with the new one. + +D.2 Random Number Generation and Seeding + + SSL requires a cryptographically-secure pseudorandom number + generator (PRNG). Care must be taken in designing and seeding + PRNGs. PRNGs based on secure hash operations, most notably MD5 + and/or SHA, are acceptable, but cannot provide more security than + the size of the random number generator state. (For example, + MD5-based PRNGs usually provide 128 bits of state.) + + To estimate the amount of seed material being produced, add the + number of bits of unpredictable information in each seed byte. For + example, keystroke timing values taken from a PC- compatible's 18.2 + Hz timer provide 1 or 2 secure bits each, even though the total + size of the counter value is 16 bits or more. To seed a 128-bit + PRNG, one would thus require approximately 100 such timer values. + + + +Freier, Karlton, Kocher [Page 49] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Note: The seeding functions in RSAREF and versions of + BSAFE prior to 3.0 are order-independent. For + example, if 1000 seed bits are supplied, one at a + time, in 1000 separate calls to the seed function, + the PRNG will end up in a state which depends only + on the number of 0 or 1 seed bits in the seed data + (i.e., there are 1001 possible final states). + Applications using BSAFE or RSAREF must take extra + care to ensure proper seeding. + +D.3 Certificates and authentication + + Implementations are responsible for verifying the integrity of + certificates and should generally support certificate revocation + messages. Certificates should always be verified to ensure proper + signing by a trusted Certificate Authority (CA). The selection and + addition of trusted CAs should be done very carefully. Users + should be able to view information about the certificate and root + CA. + +D.4 CipherSuites + + SSL supports a range of key sizes and security levels, including + some which provide no or minimal security. A proper implementation + will probably not support many cipher suites. For example, 40-bit + encryption is easily broken, so implementations requiring strong + security should not allow 40-bit keys. Similarly, anonymous + Diffie-Hellman is strongly discouraged because it cannot prevent + man-in-the- middle attacks. Applications should also enforce + minimum and maximum key sizes. For example, certificate chains + containing 512-bit RSA keys or signatures are not appropriate for + high-security applications. + +D.5 FORTEZZA + + This section describes implementation details for ciphersuites that + make use of the FORTEZZA hardware encryption system. + +D.5.1 Notes on use of FORTEZZA hardware + + A complete explanation of all issues regarding the use of FORTEZZA + hardware is outside the scope of this document. However, there are + a few special requirements of SSL that deserve mention. + + Because SSL is a full duplex protocol, two crypto states must be + maintained, one for reading and one for writing. There are also a + number of circumstances which can result in the crypto state in the + FORTEZZA card being lost. For these reasons, it's recommended that + the current crypto state be saved after processing a record, and + loaded before processing the next. + + + +Freier, Karlton, Kocher [Page 50] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + After the client generates the TEK, it also generates two MEKs, + for one for reading and one for writing. After generating each of + these keys, the client must generate a corresponding IV and then + save the crypto state. The client also uses the TEK to generate an + IV and encrypt the premaster secret. All three IVs are sent to the + server, along with the wrapped keys and the encrypted premaster + secret in the client key exchange message. At this point, the TEK + is no longer needed, and may be discarded. + + On the server side, the server uses the master IV and the TEK to + decrypt the premaster secret. It also loads the wrapped MEKs into + the card. The server loads both IVs to verify that the IVs match + the keys. However, since the card is unable to encrypt after + loading an IV, the server must generate a new IV for the server + write key. This IV is discarded. + + When encrypting the first encrypted record (and only that record), + the server adds 8 bytes of random data to the beginning of the + fragment. These 8 bytes are discarded by the client after + decryption. The purpose of this is to synchronize the state on the + client and server resulting from the different IVs. + +D.5.2 FORTEZZA Ciphersuites + + 5) FORTEZZA_NULL_WITH_NULL_SHA: + Uses the full FORTEZZA key exchange, including sending server and + client write keys and iv's. + +D.5.3 FORTEZZA Session resumption + + There are two possibilities for FORTEZZA session restart: + 1) Never restart a FORTEZZA session. + 2) Restart a session with the previously negotiated keys and iv's. + + Never restarting a FORTEZZA session: + + Clients who never restart FORTEZZA sessions should never send + Session ID's which were previously used in a FORTEZZA session as + part of the ClientHello. Servers who never restart FORTEZZA + sessions should never send a previous session id on the + ServerHello if the negotiated session is FORTEZZA. + + Restart a session: + + You cannot restart FORTEZZA on a session which has never done a + complete FORTEZZA key exchange (That is you cannot restart FORTEZZA + if the session was an RSA/RC4 session renegotiated for FORTEZZA). + If you wish to restart a FORTEZZA session, you must save the MEKs + and IVs from the initial key exchange for this session and reuse + them for any new connections on that session. This is not + recommended, but it is possible. + + +Freier, Karlton, Kocher [Page 51] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Appendix E + +E. Version 2.0 Backward Compatibility + + Version 3.0 clients that support Version 2.0 servers must send + Version 2.0 client hello messages [SSL-2]. Version 3.0 servers + should accept either client hello format. The only deviations from + the Version 2.0 specification are the ability to specify a version + with a value of three and the support for more ciphering types in + the CipherSpec. + + Warning: The ability to send Version 2.0 client hello + messages will be phased out with all due haste. + Implementers should make every effort to move + forward as quickly as possible. Version 3.0 + provides better mechanisms for transitioning to + newer versions. + + The following cipher specifications are carryovers from SSL Version + 2.0. These are assumed to use RSA for key exchange and + authentication. + + V2CipherSpec SSL_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; + V2CipherSpec SSL_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; + V2CipherSpec SSL_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; + V2CipherSpec SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 + = { 0x04,0x00,0x80 }; + V2CipherSpec SSL_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 }; + V2CipherSpec SSL_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 }; + V2CipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; + + Cipher specifications introduced in Version 3.0 can be included in + Version 2.0 client hello messages using the syntax below. Any + V2CipherSpec element with its first byte equal to zero will be + ignored by Version 2.0 servers. Clients sending any of the above + V2CipherSpecs should also include the Version 3.0 equivalent (see + Appendix A.6): + + V2CipherSpec (see Version 3.0 name) = { 0x00, CipherSuite }; + +E.1 Version 2 client hello + + The Version 2.0 client hello message is presented below using this + document's presentation model. The true definition is still + assumed to be the SSL Version 2.0 specification. + + uint8 V2CipherSpec[3]; + + struct { + unit8 msg_type; + Version version; + uint16 cipher_spec_length; + +Freier, Karlton, Kocher [Page 52] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + uint16 session_id_length; + uint16 challenge_length; + V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; + opaque session_id[V2ClientHello.session_id_length]; + Random challenge; + } V2ClientHello; + + msg_type This field, in conjunction with the version + field, identifies a version 2 client hello + message. The value should equal one (1). + version The highest version of the protocol supported + by the client (equals ProtocolVersion.version, + see Appendix A.1.1). + cipher_spec_length + This field is the total length of the field + cipher_specs. It cannot be zero and must be a + multiple of the V2CipherSpec length (3). + session_id_length This field must have a value of either zero or + 16. If zero, the client is creating a new + session. If 16, the session_id field will + contain the 16 bytes of session identification. + challenge_length The length in bytes of the client's challenge + to the server to authenticate itself. This + value must be 32. + cipher_specs This is a list of all CipherSpecs the client is + willing and able to use. There must be at + least one CipherSpec acceptable to the server. + session_id If this field's length is not zero, it will + contain the identification for a session that + the client wishes to resume. + challenge The client's challenge to the server for the + server to identify itself is a (nearly) + arbitrary length random. The Version 3.0 + server will right justify the challenge data to + become the ClientHello.random data (padded with + leading zeroes, if necessary), as specified in + this Version 3.0 protocol. If the length of + the challenge is greater than 32 bytes, then + only the last 32 bytes are used. It is + legitimate (but not necessary) for a V3 server + to reject a V2 ClientHello that has fewer than + 16 bytes of challenge data. + + Note: Requests to resume an SSL 3.0 session should use an + SSL 3.0 client hello. + +E.2 Avoiding man-in-the-middle version rollback + + When SSL Version 3.0 clients fall back to Version 2.0 compatibility + mode, they use special PKCS #1 block formatting. This is done so + that Version 3.0 servers will reject Version 2.0 sessions with + Version 3.0-capable clients. + +Freier, Karlton, Kocher [Page 53] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + + When Version 3.0 clients are in Version 2.0 compatibility mode, + they set the right-hand (least-significant) 8 random bytes of the + PKCS padding (not including the terminal null of the padding) for + the RSA encryption of the ENCRYPTED-KEY- DATA field of the + CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random). + After decrypting the ENCRYPTED- KEY-DATA field, servers that + support SSL 3.0 should issue an error if these eight padding bytes + are 0x03. Version 2.0 servers receiving blocks padded in this + manner will proceed normally. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Freier, Karlton, Kocher [Page 54] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Appendix F + +F. Security analysis + + The SSL protocol is designed to establish a secure connection + between a client and a server communicating over an insecure + channel. This document makes several traditional assumptions, + including that attackers have substantial computational resources + and cannot obtain secret information from sources outside the + protocol. Attackers are assumed to have the ability to capture, + modify, delete, replay, and otherwise tamper with messages sent + over the communication channel. This appendix outlines how SSL has + been designed to resist a variety of attacks. + +F.1 Handshake protocol + + The handshake protocol is responsible for selecting a CipherSpec + and generating a MasterSecret, which together comprise the primary + cryptographic parameters associated with a secure session. The + handshake protocol can also optionally authenticate parties who + have certificates signed by a trusted certificate authority. + +F.1.1 Authentication and key exchange + + SSL supports three authentication modes: authentication of both + parties, server authentication with an unauthenticated client, and + total anonymity. Whenever the server is authenticated, the channel + should be secure against man-in- the-middle attacks, but completely + anonymous sessions are inherently vulnerable to such attacks. + Anonymous servers cannot authenticate clients, since the client + signature in the certificate verify message may require a server + certificate to bind the signature to a particular server. If the + server is authenticated, its certificate message must provide a + valid certificate chain leading to an acceptable certificate + authority. Similarly, authenticated clients must supply an + acceptable certificate to the server. Each party is responsible + for verifying that the other's certificate is valid and has not + expired or been revoked. + + The general goal of the key exchange process is to create a + pre_master_secret known to the communicating parties and not to + attackers. The pre_master_secret will be used to generate the + master_secret (see Section 6.1). The master_secret is required to + generate the finished messages, encryption keys, and MAC secrets + (see Sections 5.6.9 and 6.2.2). By sending a correct finished + message, parties thus prove that they know the correct + pre_master_secret. + +F.1.1.1 Anonymous key exchange + + Completely anonymous sessions can be established using RSA, + Diffie-Hellman, or FORTEZZA for key exchange. With anonymous RSA, + +Freier, Karlton, Kocher [Page 55] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + the client encrypts a pre_master_secret with the server's + uncertified public key extracted from the server key exchange + message. The result is sent in a client key exchange message. + Since eavesdroppers do not know the server's private key, it will + be infeasible for them to decode the pre_master_secret. + + With Diffie-Hellman or FORTEZZA, the server's public parameters are + contained in the server key exchange message and the client's are + sent in the client key exchange message. Eavesdroppers who do not + know the private values should not be able to find the + Diffie-Hellman result (i.e. the pre_master_secret) or the FORTEZZA + token encryption key (TEK). + + Warning: Completely anonymous connections only provide + protection against passive eavesdropping. Unless an + independent tamper-proof channel is used to verify + that the finished messages were not replaced by an + attacker, server authentication is required in + environments where active man-in-the-middle attacks + are a concern. + +F.1.1.2 RSA key exchange and authentication + + With RSA, key exchange and server authentication are combined. The + public key may be either contained in the server's certificate or + may be a temporary RSA key sent in a server key exchange message. + When temporary RSA keys are used, they are signed by the server's + RSA or DSS certificate. The signature includes the current + ClientHello.random, so old signatures and temporary keys cannot be + replayed. Servers may use a single temporary RSA key for multiple + negotiation sessions. + + Note: The temporary RSA key option is useful if servers + need large certificates but must comply with + government-imposed size limits on keys used for key + exchange. + + After verifying the server's certificate, the client encrypts a + pre_master_secret with the server's public key. By successfully + decoding the pre_master_secret and producing a correct finished + message, the server demonstrates that it knows the private key + corresponding to the server certificate. + + When RSA is used for key exchange, clients are authenticated using + the certificate verify message (see Section 5.6.8). The client + signs a value derived from the master_secret and all preceding + handshake messages. These handshake messages include the server + certificate, which binds the signature to the server, and + ServerHello.random, which binds the signature to the current + handshake process. + + + +Freier, Karlton, Kocher [Page 56] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + +F.1.1.3 Diffie-Hellman key exchange with authentication + + When Diffie-Hellman key exchange is used, the server can either + supply a certificate containing fixed Diffie-Hellman parameters or + can use the server key exchange message to send a set of temporary + Diffie-Hellman parameters signed with a DSS or RSA certificate. + Temporary parameters are hashed with the hello.random values before + signing to ensure that attackers do not replay old parameters. In + either case, the client can verify the certificate or signature to + ensure that the parameters belong to the server. + + If the client has a certificate containing fixed Diffie- Hellman + parameters, its certificate contains the information required to + complete the key exchange. Note that in this case the client and + server will generate the same Diffie- Hellman result (i.e., + pre_master_secret) every time they communicate. To prevent the + pre_master_secret from staying in memory any longer than necessary, + it should be converted into the master_secret as soon as possible. + Client Diffie- Hellman parameters must be compatible with those + supplied by the server for the key exchange to work. + + If the client has a standard DSS or RSA certificate or is + unauthenticated, it sends a set of temporary parameters to the + server in the client key exchange message, then optionally uses a + certificate verify message to authenticate itself. + +F.1.1.4 FORTEZZA + + FORTEZZA's design is classified, but at the protocol level it is + similar to Diffie-Hellman with fixed public values contained in + certificates. The result of the key exchange process is the token + encryption key (TEK), which is used to wrap data encryption keys, + client write key, server write key, and master secret encryption + key. The data encryption keys are not derived from the + pre_master_secret because unwrapped keys are not accessible outside + the token. The encrypted pre_master_secret is sent to the server + in a client key exchange message. + +F.1.2 Version rollback attacks + + Because SSL Version 3.0 includes substantial improvements over SSL + Version 2.0, attackers may try to make Version 3.0- capable clients + and servers fall back to Version 2.0. This attack is occurring if + (and only if) two Version 3.0-capable parties use an SSL 2.0 + handshake. + + Although the solution using non-random PKCS #1 block type 2 message + padding is inelegant, it provides a reasonably secure way for + Version 3.0 servers to detect the attack. This solution is not + secure against attackers who can brute force the key and substitute + a new ENCRYPTED-KEY-DATA message containing the same key (but with + normal padding) before the application specified wait threshold has + +Freier, Karlton, Kocher [Page 57] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + expired. Parties concerned about attacks of this scale should not + be using 40-bit encryption keys anyway. Altering the padding of + the least-significant 8 bytes of the PKCS padding does not impact + security, since this is essentially equivalent to increasing the + input block size by 8 bytes. + +F.1.3 Detecting attacks against the handshake protocol + + An attacker might try to influence the handshake exchange to make + the parties select different encryption algorithms than they would + normally choose. Because many implementations will support 40-bit + exportable encryption and some may even support null encryption or + MAC algorithms, this attack is of particular concern. + + For this attack, an attacker must actively change one or more + handshake messages. If this occurs, the client and server will + compute different values for the handshake message hashes. As a + result, the parties will not accept each others' finished messages. + Without the master_secret, the attacker cannot repair the finished + messages, so the attack will be discovered. + +F.1.4 Resuming sessions + + When a connection is established by resuming a session, new + ClientHello.random and ServerHello.random values are hashed with + the session's master_secret. Provided that the master_secret has + not been compromised and that the secure hash operations used to + produce the encryption keys and MAC secrets are secure, the + connection should be secure and effectively independent from + previous connections. Attackers cannot use known encryption keys + or MAC secrets to compromise the master_secret without breaking the + secure hash operations (which use both SHA and MD5). + + Sessions cannot be resumed unless both the client and server agree. + If either party suspects that the session may have been + compromised, or that certificates may have expired or been revoked, + it should force a full handshake. An upper limit of 24 hours is + suggested for session ID lifetimes, since an attacker who obtains a + master_secret may be able to impersonate the compromised party + until the corresponding session ID is retired. Applications that + may be run in relatively insecure environments should not write + session IDs to stable storage. + +F.1.5 MD5 and SHA + + SSL uses hash functions very conservatively. Where possible, both + MD5 and SHA are used in tandem to ensure that non- catastrophic + flaws in one algorithm will not break the overall protocol. + + + + + +Freier, Karlton, Kocher [Page 58] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + +F.2 Protecting application data + + The master_secret is hashed with the ClientHello.random and + ServerHello.random to produce unique data encryption keys and MAC + secrets for each connection. FORTEZZA encryption keys are + generated by the token, and are not derived from the master_secret. + + Outgoing data is protected with a MAC before transmission. To + prevent message replay or modification attacks, the MAC is computed + from the MAC secret, the sequence number, the message length, the + message contents, and two fixed character strings. The message + type field is necessary to ensure that messages intended for one + SSL Record Layer client are not redirected to another. The + sequence number ensures that attempts to delete or reorder messages + will be detected. Since sequence numbers are 64-bits long, they + should never overflow. Messages from one party cannot be inserted + into the other's output, since they use independent MAC secrets. + Similarly, the server-write and client-write keys are independent + so stream cipher keys are used only once. + + If an attacker does break an encryption key, all messages encrypted + with it can be read. Similarly, compromise of a MAC key can make + message modification attacks possible. Because MACs are also + encrypted, message-alteration attacks generally require breaking + the encryption algorithm as well as the MAC. + + Note: MAC secrets may be larger than encryption keys, so + messages can remain tamper resistant even if + encryption keys are broken. + +F.3 Final notes + + For SSL to be able to provide a secure connection, both the client + and server systems, keys, and applications must be secure. In + addition, the implementation must be free of security errors. + + The system is only as strong as the weakest key exchange and + authentication algorithm supported, and only trustworthy + cryptographic functions should be used. Short public keys, 40-bit + bulk encryption keys, and anonymous servers should be used with + great caution. Implementations and users must be careful when + deciding which certificates and certificate authorities are + acceptable; a dishonest certificate authority can do tremendous + damage. + + + + + + + + + +Freier, Karlton, Kocher [Page 59] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Appendix G + +G. Patent Statement + + This version of the SSL protocol relies on the use of patented + public key encryption technology for authentication and encryption. + The Internet Standards Process as defined in RFC 1310 requires a + written statement from the Patent holder that a license will be + made available to applicants under reasonable terms and conditions + prior to approving a specification as a Proposed, Draft or Internet + Standard. The Massachusetts Institute of Technology has granted + RSA Data Security, Inc., exclusive sub-licensing rights to the + following patent issued in the United States: + + Cryptographic Communications System and Method ("RSA"), + No. 4,405,829 + + The Board of Trustees of the Leland Stanford Junior University have + granted Caro-Kann Corporation, a wholly owned subsidiary + corporation, exclusive sub-licensing rights to the following + patents issued in the United States, and all of their corresponding + foreign patents: + + Cryptographic Apparatus and Method ("Diffie-Hellman"), + No. 4,200,770 + + Public Key Cryptographic Apparatus and Method ("Hellman- + Merkle"), No. 4,218,582 + + The Internet Society, Internet Architecture Board, Internet + Engineering Steering Group and the Corporation for National + Research Initiatives take no position on the validity or scope of + the patents and patent applications, nor on the appropriateness of + the terms of the assurance. The Internet Society and other groups + mentioned above have not made any determination as to any other + intellectual property rights which may apply to the practice of + this standard. Any further consideration of these matters is the + user's own responsibility. + + + + + + + + + + + + + + + +Freier, Karlton, Kocher [Page 60] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + +References + + [DH1] W. Diffie and M. E. Hellman, "New Directions in + Cryptography," IEEE Transactions on Information Theory, V. + IT-22, n. 6, Jun 1977, pp. 74-84. + + [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions + To DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41. + + [DES] ANSI X3.106, "American National Standard for + Information Systems-Data Link Encryption," American National + Standards Institute, 1983. + + [DSS] NIST FIPS PUB 186, "Digital Signature Standard," + National Institute of Standards and Technology, U.S. + Department of Commerce, 18 May 1994. + + [FOR] NSA X22, Document # PD4002103-1.01, "FORTEZZA: + Application Implementers Guide," April 6, 1995. + + [FTP] J. Postel and J. Reynolds, RFC 959: File Transfer + Protocol, October 1985. + + [HTTP] T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext + Transfer Protocol -- HTTP/1.0, October, 1995. + + [IDEA] X. Lai, "On the Design and Security of Block + Ciphers," ETH Series in Information Processing, v. 1, + Konstanz: Hartung-Gorre Verlag, 1992. + + [KRAW] H. Krawczyk, IETF Draft: Keyed-MD5 for Message + Authentication, November 1995. + + [MD2] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. + April 1992. + + [MD5] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. + April 1992. + + [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption + Standard," version 1.5, November 1993. + + [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate + Syntax Standard," version 1.5, November 1993. + + [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic + Message Syntax Standard," version 1.5, November 1993. + + [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for + Obtaining Digital Signatures and Public-Key Cryptosystems," + Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120- + 126. + +Freier, Karlton, Kocher [Page 61] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782 + [SCH] B. Schneier. Applied Cryptography: Protocols, + Algorithms, and Source Code in C, Published by John Wiley & + Sons, Inc. 1994. + + [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National + Institute of Standards and Technology, U.S. Department of + Commerce, DRAFT, 31 May 1994. + [TCP] ISI for DARPA, RFC 793: Transport Control Protocol, + September 1981. + + [TEL] J. Postel and J. Reynolds, RFC 854/5, May, 1993. + [X509] CCITT. Recommendation X.509: "The Directory - + Authentication Framework". 1988. + + [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: + External Data Representation Standard, August 1995. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Freier, Karlton, Kocher [Page 62] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Authors + + Alan O. Freier Paul C. Kocher + Netscape Communications Independent Consultant + freier@netscape.com pck@netcom.com + + Philip L. Karlton + Netscape Communications + karlton@netscape.com + + Other contributors + + Martin Abadi Robert Relyea + Digital Equipment Corporation Netscape Communications + ma@pa.dec.com relyea@netscape.com + + Taher Elgamal Jim Roskind + Netscape Communications Netscape Communications + elgamal@netscape.com jar@netscape.com + + Anil Gangolli Micheal J. Sabin, Ph. D. + Netscape Communications Consulting Engineer + gangolli@netscape.com msabin@netcom.com + + Kipp E.B. Hickman Tom Weinstein + Netscape Communications Netscape Communications + kipp@netscape.com tomw@netscape.com + + Early reviewers + + Robert Baldwin Clyde Monma + RSA Data Security, Inc. Bellcore + baldwin@rsa.com clyde@bellcore.com + + George Cox Eric Murray + Intel Corporation ericm@lne.com + cox@ibeam.jf.intel.com + + Cheri Dowell Avi Rubin + Sun Microsystems Bellcore + cheri@eng.sun.com rubin@bellcore.com + + Stuart Haber Don Stephenson + Bellcore Sun Microsystems + stuart@bellcore.com don.stephenson@eng.sun.com + + Burt Kaliski Joe Tardo + RSA Data Security, Inc. General Magic + burt@rsa.com tardo@genmagic.com + + + + +Freier, Karlton, Kocher [Page 63] + + +INTERNET-DRAFT SSL 3.0 November 18, 1996 + + Send all written communication about this document to: + Netscape Communications + 501 East Middlefield Rd. + Mountain View, CA 94043 + Attn: Alan Freier + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Freier, Karlton, Kocher [Page 63] + + + --- libaws-2.5~124785.orig/docs/openssl.license +++ libaws-2.5~124785/docs/openssl.license @@ -0,0 +1,126 @@ + LICENSE ISSUES + ============== + + The OpenSSL toolkit stays under a dual license, i.e. both the conditions of + the OpenSSL License and the original SSLeay license apply to the toolkit. + See below for the actual license texts. Actually both licenses are BSD-style + Open Source licenses. In case of any license issues related to OpenSSL + please contact openssl-core@openssl.org. + + OpenSSL License + --------------- + +/* ==================================================================== + * Copyright (c) 1998-2001 The OpenSSL Project. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * + * 3. All advertising materials mentioning features or use of this + * software must display the following acknowledgment: + * "This product includes software developed by the OpenSSL Project + * for use in the OpenSSL Toolkit. (http://www.openssl.org/)" + * + * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to + * endorse or promote products derived from this software without + * prior written permission. For written permission, please contact + * openssl-core@openssl.org. + * + * 5. Products derived from this software may not be called "OpenSSL" + * nor may "OpenSSL" appear in their names without prior written + * permission of the OpenSSL Project. + * + * 6. Redistributions of any form whatsoever must retain the following + * acknowledgment: + * "This product includes software developed by the OpenSSL Project + * for use in the OpenSSL Toolkit (http://www.openssl.org/)" + * + * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY + * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR + * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED + * OF THE POSSIBILITY OF SUCH DAMAGE. + * ==================================================================== + * + * This product includes cryptographic software written by Eric Young + * (eay@cryptsoft.com). This product includes software written by Tim + * Hudson (tjh@cryptsoft.com). + * + */ + + Original SSLeay License + ----------------------- + +/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com) + * All rights reserved. + * + * This package is an SSL implementation written + * by Eric Young (eay@cryptsoft.com). + * The implementation was written so as to conform with Netscapes SSL. + * + * This library is free for commercial and non-commercial use as long as + * the following conditions are aheared to. The following conditions + * apply to all code found in this distribution, be it the RC4, RSA, + * lhash, DES, etc., code; not just the SSL code. The SSL documentation + * included with this distribution is covered by the same copyright terms + * except that the holder is Tim Hudson (tjh@cryptsoft.com). + * + * Copyright remains Eric Young's, and as such any Copyright notices in + * the code are not to be removed. + * If this package is used in a product, Eric Young should be given attribution + * as the author of the parts of the library used. + * This can be in the form of a textual message at program startup or + * in documentation (online or textual) provided with the package. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * "This product includes cryptographic software written by + * Eric Young (eay@cryptsoft.com)" + * The word 'cryptographic' can be left out if the rouines from the library + * being used are not cryptographic related :-). + * 4. If you include any Windows specific code (or a derivative thereof) from + * the apps directory (application code) you must include an acknowledgement: + * "This product includes software written by Tim Hudson (tjh@cryptsoft.com)" + * + * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * The licence and distribution terms for any publically available version or + * derivative of this code cannot be changed. i.e. this code cannot simply be + * copied and put under another distribution licence + * [including the GNU Public Licence.] + */ + --- libaws-2.5~124785.orig/patches/aws_os_lib.patch +++ libaws-2.5~124785/patches/aws_os_lib.patch @@ -0,0 +1,13 @@ +Index: org.debian.libaws/config/aws-net-ssl__gnutls.adb +=================================================================== +--- org.debian.libaws.orig/config/aws-net-ssl__gnutls.adb 2008-04-22 10:38:49.189880424 +0200 ++++ org.debian.libaws/config/aws-net-ssl__gnutls.adb 2008-04-22 10:39:07.769961872 +0200 +@@ -386,7 +386,7 @@ + + procedure Check_File (Prefix, Filename : in String) is + begin +- if not OS_Lib.Is_Regular_File (Filename) then ++ if not Utils.Is_Regular_File (Filename) then + Raise_Exception + (Socket_Error'Identity, + Prefix & " file """ & Filename & """ error."); --- libaws-2.5~124785.orig/patches/demos.patch +++ libaws-2.5~124785/patches/demos.patch @@ -0,0 +1,197 @@ +Index: demos/demos.gpr +=================================================================== +--- demos/demos.gpr.orig ++++ demos/demos.gpr +@@ -1,34 +1,25 @@ +------------------------------------------------------------------------------- +--- Ada Web Server -- +--- -- +--- Copyright (C) 2003-2007 -- +--- AdaCore -- +--- -- +--- This library is free software; you can redistribute it and/or modify -- +--- it under the terms of the GNU General Public License as published by -- +--- the Free Software Foundation; either version 2 of the License, or (at -- +--- your option) any later version. -- +--- -- +--- This library is distributed in the hope that it will be useful, but -- +--- WITHOUT ANY WARRANTY; without even the implied warranty of -- +--- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -- +--- General Public License for more details. -- +--- -- +--- You should have received a copy of the GNU General Public License -- +--- along with this library; if not, write to the Free Software Foundation, -- +--- Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. -- +--- -- +------------------------------------------------------------------------------- +- +-with "../shared"; +-with "../include/include"; +-with "../src/src"; +-with "../win32/win32"; +-with "demos_shared"; +- ++-- Ada Web server - project file to build the examples ++-- Copyright (c) 2004, 2008 Ludovic Brenta ++-- ++-- This program is free software; you can redistribute it and/or modify ++-- it under the terms of the GNU General Public License as published by ++-- the Free Software Foundation; either version 2 of the License, or ++-- (at your option) any later version. ++-- ++-- This program is distributed in the hope that it will be useful, ++-- but WITHOUT ANY WARRANTY; without even the implied warranty of ++-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ++-- GNU General Public License in file /usr/share/common-licenses/GPL for ++-- more details. ++-- ++-- You should normally copy the examples directory to a user-writable ++-- directory before trying to compile. ++with "aws.gpr"; ++with "xmlada.gpr"; + project Demos is +- +- for Languages use ("Ada", "Project file"); ++ for Source_Dirs use ("."); ++ for Object_Dir use "obj"; ++ for Exec_Dir use "."; + + Mains := ("hello_world.adb", "com_1.adb", "com_2.adb", "main.adb", + "hotplug.adb", "dispatch.adb", "wps.adb", "ws.adb", +@@ -48,72 +39,11 @@ + "rdemo-adains_png.ads", "rdemo-page3_html.ads", "demos.gpr", + "web_elements_containers.ads", "web_elements_containers.adb"); + +- for Main use Mains; +- +- case Shared.XMLAda is +- when "Installed" => +- for Main use project'Main & Mains_XMLAda; +- for Source_Files use +- project'Source_Files +- & Mains_XMLADA +- & ("hello_demo.ads", "hello_demo-client.adb", +- "hello_demo-server.adb", "hello_demo-types.ads", +- "wsdl_demo_server_cb.adb", "interoplab.ads", +- "interoplab-client.adb", "interoplab-types.ads", +- "soap_server_cb.adb", "soap_server_disp_cb.adb", +- "soap_svs_cb.ads", "soap_svs_cb.adb", +- "soapinterop-org-xsd-arrayoffloat_type_pkg.ads", +- "soapinterop-org-xsd-arrayofint_type_pkg.ads", +- "soapinterop-org-xsd-arrayofsoapstruct_type_pkg.ads", +- "soapinterop-org-xsd-arrayofstring_type_pkg.ads", +- "soapinterop-org-xsd-soapstruct_type_pkg.adb", +- "soapinterop-org-xsd-soapstruct_type_pkg.ads", +- "soapinterop-org-xsd.ads", +- "soapinterop-org.ads", "soapinterop.ads"); +- when "Disabled" => +- null; +- end case; +- +- case Shared.LDAP is +- when "Installed" => +- for Main use project'Main & ("test_ldap.adb"); +- for Source_Files use +- project'Source_Files & ("test_ldap.adb"); +- when others => +- null; +- end case; +- +- for Object_Dir use "../" & Shared'Object_Dir & "/demos"; +- for Exec_Dir use "../" & Shared'Exec_Dir & "/demos"; +- +- --------- +- -- Ide -- +- --------- +- +- package Ide renames Shared.Ide; +- +- ------------ +- -- Binder -- +- ------------ +- +- package Binder renames Shared.Binder; +- +- ------------- +- -- Builder -- +- ------------- +- +- package Builder renames Shared.Builder; +- +- -------------- +- -- Compiler -- +- -------------- +- +- package Compiler renames Demos_Shared.Compiler; +- +- ------------ +- -- Linker -- +- ------------ ++ for Main use Mains & Mains_XMLAda & ("test_ldap.adb"); + +- package Linker renames Demos_Shared.Linker; ++ package Compiler is ++ for Default_Switches ("Ada") ++ use ("-g", "-gnatafnoy", "-gnatVa", "-gnatwa"); ++ end Compiler; + + end Demos; +Index: demos/makefile +=================================================================== +--- demos/makefile.orig ++++ demos/makefile +@@ -20,31 +20,27 @@ + # # + ############################################################################ + +-build_res: +- echo Generate resources for res_demo +- $(AWSRES) -q -r rdemo adains.png page3.html +- +-build_wsdl: +- echo Generate stub/skel from WSDL documents +- $(WSDL2AWS) -q -f -doc -timeouts 1,2,2 hello.wsdl +- $(WSDL2AWS) -q -f -doc -noskel interoplab_main.wsdl ++# This Makefile builds all the Ada Web Server examples, using the ++# Debian way of organising files. In particular, it uses project ++# files to do most of the work, instead of specifying dependencies ++# explicitly. + +-force: ++.SUFFIXES= + +-AWSRES = ../$(BDIR)/tools/awsres +-WSDL2AWS = ../$(BDIR)/tools/wsdl2aws ++all: obj rdemo.ads hello_demo.ads interoplab.ads ++ gnatmake -Pdemos + +-ifeq (${PRJ_XMLADA}, Installed) +-BUILD_EXT = build_wsdl +-endif ++rdemo.ads: adains.png page3.html ++ awsres -q -r rdemo $< ++ ++hello_demo.ads: hello.wsdl ++ wsdl2aws -q -f -doc $< ++ ++interoplab.ads: interoplab_main.wsdl ++ wsdl2aws -q -f -doc -noskel $< + +-setup: +- -$(MKDIR) -p ../$(BDIR)/obj/demos +- -$(MKDIR) -p ../$(BDIR)/demos +- +-build: build_res $(BUILD_EXT) +- $(GNAT) make -Pdemos +- $(GNAT) make -Pdemos_ssl ++obj: ++ mkdir -p obj + + install: + $(CP) *.thtml $(I_TPL) +@@ -57,4 +53,4 @@ + check: + + clean: +- $(RM) -fr ../$(BDIR)/demos ++ rm -rf obj rdemo.ads hello_demo* interoplab-* interoplab.ads --- libaws-2.5~124785.orig/patches/series +++ libaws-2.5~124785/patches/series @@ -0,0 +1,6 @@ +GPL.patch -p0 +docs.patch -p0 +demos.patch -p0 +ada2wsdl.patch +aws_os_lib.patch +aws_net_ssl_ads.patch --- libaws-2.5~124785.orig/patches/aws_net_ssl_ads.patch +++ libaws-2.5~124785/patches/aws_net_ssl_ads.patch @@ -0,0 +1,13 @@ +Index: org.debian.libaws/src/aws-net-ssl.ads +=================================================================== +--- org.debian.libaws.orig/src/aws-net-ssl.ads 2008-04-22 10:49:26.372675585 +0200 ++++ org.debian.libaws/src/aws-net-ssl.ads 2008-04-22 10:49:35.704716553 +0200 +@@ -166,7 +166,7 @@ + type Socket_Type is new Net.Std.Socket_Type with record + Config : SSL.Config := Null_Config; + SSL : SSL_Handle := TSSL.Null_Handle; +- IO : TSSL.BIO_Access; ++ -- IO : TSSL.BIO_Access; + end record; + + overriding procedure Set_Timeout --- libaws-2.5~124785.orig/patches/GPL.patch +++ libaws-2.5~124785/patches/GPL.patch @@ -0,0 +1,16 @@ +Index: docs/aws.texi.tmplt +=================================================================== +--- docs/aws.texi.tmplt.orig ++++ docs/aws.texi.tmplt +@@ -57,11 +57,6 @@ + + @* + +-This document may be copied, in whole or in part, in any form or by any +-means, as is or with alterations, provided that (1) alterations are clearly +-marked as alterations and (2) this copyright notice is included +-unmodified in any copy. +- + @end titlepage + + @ifhtml --- libaws-2.5~124785.orig/patches/ada2wsdl.patch +++ libaws-2.5~124785/patches/ada2wsdl.patch @@ -0,0 +1,33 @@ +Index: libaws-2.2/tools/ada2wsdl-options.adb +=================================================================== +--- /dev/null 1970-01-01 00:00:00.000000000 +0000 ++++ libaws-2.2/tools/ada2wsdl-options.adb 2006-07-30 12:57:08.000000000 +0200 +@@ -0,0 +1,28 @@ ++-- Ada2WSDL.Options - Debian-specific file ++-- Copyright (c) 2004, 2006 Ludovic Brenta ++-- ++-- This program is free software; you can redistribute it and/or modify ++-- it under the terms of the GNU General Public License as published by ++-- the Free Software Foundation; either version 2 of the License, or ++-- (at your option) any later version. ++-- ++-- This program is distributed in the hope that it will be useful, ++-- but WITHOUT ANY WARRANTY; without even the implied warranty of ++-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ++-- GNU General Public License for more details. ++-- ++-- The upstream makefile normally generates this file before ++-- compiling the AWS tools. The generated file does however not ++-- contain the options appropriate for Debian. This file contains ++-- Debian-specific options. ++ ++with Ada2WSDL.Parser; ++package body Ada2WSDL.Options is ++ procedure Set_Default is ++ begin ++ Parser.Add_Option ("-aI/usr/share/ada/adainclude/xmlada"); ++ Parser.Add_Option ("-aO/usr/lib/ada/adalib/xmlada"); ++ Parser.Add_Option ("-aI/usr/share/ada/adainclude/aws"); ++ Parser.Add_Option ("-aO/usr/lib/ada/adalib/aws"); ++ end Set_Default; ++end Ada2WSDL.Options; --- libaws-2.5~124785.orig/patches/docs.patch +++ libaws-2.5~124785/patches/docs.patch @@ -0,0 +1,250 @@ +Index: docs/makefile +=================================================================== +--- docs/makefile.orig ++++ docs/makefile +@@ -20,7 +20,7 @@ + # # + ############################################################################ + +-.SILENT: ++.SUFFIXES= + + BUILD_DOC_SCRIPT = true + # When true the main documentation texinfo file will be generated from the +@@ -37,92 +37,21 @@ + subtype generic limited access all tagged abstract renames \ + pragma new case when null + +-APIFILES = ../src/aws.ads.texi \ +- ../src/aws-attachments.ads.texi \ +- ../src/aws-client.ads.texi \ +- ../src/aws-client-hotplug.ads.texi \ +- ../src/aws-communication-client.ads.texi \ +- ../src/aws-communication-server.ads.texi \ +- ../src/aws-communication.ads.texi \ +- ../src/aws-config-ini.ads.texi \ +- ../src/aws-config-set.ads.texi \ +- ../src/aws-config.ads.texi \ +- ../src/aws-containers-tables.ads.texi \ +- ../src/aws-default.ads.texi \ +- ../src/aws-dispatchers-callback.ads.texi \ +- ../src/aws-dispatchers.ads.texi \ +- ../src/aws-exceptions.ads.texi \ +- ../src/aws-headers.ads.texi \ +- ../src/aws-headers-values.ads.texi \ +- ../src/aws-ldap-client.ads.texi \ +- ../src/aws-log.ads.texi \ +- ../src/aws-messages.ads.texi \ +- ../src/aws-mime.ads.texi \ +- ../src/aws-net.ads.texi \ +- ../src/aws-net-buffered.ads.texi \ +- ../src/aws-net-log.ads.texi \ +- ../src/aws-net-log-callbacks.ads.texi \ +- ../src/aws-net-ssl.ads.texi \ +- ../src/aws-net-ssl-certificate.ads.texi \ +- ../src/aws-parameters.ads.texi \ +- ../src/aws-pop.ads.texi \ +- ../src/aws-resources-files.ads.texi \ +- ../src/aws-resources-embedded.ads.texi \ +- ../src/aws-resources-streams.ads.texi \ +- ../src/aws-resources-streams-disk.ads.texi \ +- ../src/aws-resources-streams-disk-once.ads.texi \ +- ../src/aws-resources-streams-memory.ads.texi \ +- ../src/aws-resources-streams-memory-zlib.ads.texi \ +- ../src/aws-resources-streams-pipe.ads.texi \ +- ../src/aws-resources.ads.texi \ +- ../src/aws-response.ads.texi \ +- ../src/aws-server-hotplug.ads.texi \ +- ../src/aws-server-push.ads.texi \ +- ../src/aws-server-status.ads.texi \ +- ../src/aws-server-log.ads.texi \ +- ../src/aws-server.ads.texi \ +- ../src/aws-services-callbacks.ads.texi \ +- ../src/aws-services-directory.ads.texi \ +- ../src/aws-services-dispatchers-linker.ads.texi \ +- ../src/aws-services-dispatchers-method.ads.texi \ +- ../src/aws-services-dispatchers-uri.ads.texi \ +- ../src/aws-services-dispatchers-virtual_host.ads.texi \ +- ../src/aws-services-dispatchers.ads.texi \ +- ../src/aws-services-download.ads.texi \ +- ../src/aws-services-page_server.ads.texi \ +- ../src/aws-services-split_pages.ads.texi \ +- ../src/aws-services-split_pages-uniform.ads.texi \ +- ../src/aws-services-split_pages-uniform-alpha.ads.texi \ +- ../src/aws-services-split_pages-uniform-overlapping.ads.texi \ +- ../src/aws-services-split_pages-alpha.ads.texi \ +- ../src/aws-services-split_pages-alpha-bounded.ads.texi \ +- ../src/aws-services-transient_pages.ads.texi \ +- ../src/aws-services-web_block.ads.texi \ +- ../src/aws-services-web_block-context.ads.texi \ +- ../src/aws-services-web_block-registry.ads.texi \ +- ../src/aws-session.ads.texi \ +- ../src/aws-smtp-client.ads.texi \ +- ../src/aws-smtp.ads.texi \ +- ../src/aws-status.ads.texi \ +- ../src/aws-templates.ads.texi \ +- ../src/aws-translator.ads.texi \ +- ../src/aws-url.ads.texi \ +- ../xsrc/aws-jabber.ads.texi \ +- ../soap/soap.ads.texi \ +- ../soap/soap-client.ads.texi \ +- ../soap/soap-dispatchers.ads.texi \ +- ../soap/soap-dispatchers-callback.ads.texi \ +- ../soap/soap-message-xml.ads.texi \ +- ../soap/soap-message.ads.texi \ +- ../soap/soap-parameters.ads.texi \ +- ../soap/soap-types.ads.texi +- +-build_doc: $(APIFILES) aws_docs sg_docs +- echo "" +- echo AWS Documentation built with success. +- ${MAKE} -C ../templates_parser doc LIBRARY_TYPE="$(LIBRARY_TYPE)" ++DIRS := ../src ../wsrc ../soap ../ssl ../xsrc ++vpath %.ads $(DIRS) ../include + +-aws_docs: aws.texi aws.pdf aws.ps aws.html aws.txt aws.info ++APIREFS := $(foreach dir,$(DIRS),$(wildcard $(dir)/*.ads)) \ ++ $(wildcard ../include/strings_cutter.ads) \ ++ $(wildcard ../include/zlib*.ads) \ ++ $(wildcard ../include/memory_streams.ads) ++ ++APIFILES := $(foreach f,$(APIREFS),$(notdir $(f)).texi) ++ ++build_doc: aws_docs sg_docs ++ @echo "" ++ @echo AWS Documentation built with success. ++ ++aws_docs: aws.pdf aws.ps aws.html aws.txt aws.info + + sg_docs: style-guide.pdf style-guide.ps style-guide.html style-guide.txt \ + style-guide.info +@@ -149,13 +78,12 @@ + %.ads.texi: %.ads ada.sed gentexifile + ./gentexifile $< NOGROUP + +-%.adb.texi: %.adb ada.sed gentexifile +- ./gentexifile $< NOGROUP +- + %.dvi: %.texi + ifneq (${TEXI2DVI},) +- echo Building $@ +- -${TEXI2DVI} --expand --clean --quiet $< ++ @echo Building $@ ++ -tmpdir=$$(mktemp -d); \ ++ ${TEXI2DVI} --expand --build-dir=$$tmpdir --quiet $< ; \ ++ rm -r $$tmpdir + else + @echo "--------------------------------------------------------" + @echo "texi2dvi not found, cannot build DVI or PS documentation" +@@ -164,7 +92,7 @@ + + %.ps: %.dvi + ifneq (${DVIPS},) +- echo Building $@ ++ @echo Building $@ + -${DVIPS} -q $< -o $@ + else + @echo "------------------------------------------------------" +@@ -175,8 +103,10 @@ + %.pdf: %.texi + ifneq (${TEXI2DVI},) + ifneq (${PDFTEX},) +- echo Building $@ +- ${TEXI2DVI} -p --expand --clean --quiet $< ++ @echo Building $@ ++ -tmpdir=$$(mktemp -d); \ ++ ${TEXI2DVI} -p --expand --build-dir=$$tmpdir --quiet $< ; \ ++ rm -r $$tmpdir + else + @echo "------------------------------------------------" + @echo "pdftex not found, cannot build PDF documentation" +@@ -190,8 +120,8 @@ + + %.info: %.texi + ifneq (${MAKEINFO},) +- echo Building $@ +- -${MAKEINFO} $< ++ @echo Building $@ ++ -${MAKEINFO} --no-split $< + else + @echo "---------------------------------------------------" + @echo "makeinfo not found, cannot build INFO documentation" +@@ -200,7 +130,7 @@ + + %.html: %.texi + ifneq (${MAKEINFO},) +- echo Building $@ ++ @echo Building $@ + -${MAKEINFO} --html --no-split --css-include=aws.css --ifinfo $< + else + @echo "---------------------------------------------------" +@@ -210,7 +140,7 @@ + + %.txt: %.texi + ifneq (${MAKEINFO},) +- echo Building $@ ++ @echo Building $@ + -${MAKEINFO} --plaintext --no-headers $< --output $@ + else + @echo "---------------------------------------------------" +@@ -225,11 +155,11 @@ + + ifeq (${BUILD_DOC_SCRIPT},false) + gen_texi: prog aws.texi.tmplt +- echo build from ada ++ @echo build from ada + ./build | tr -d '\r' > aws.texi + else + gen_texi: aws.texi.tmplt +- echo build from script ++ @echo build from script + sed -f ./gen_doc.sed < aws.texi.tmplt > aws.texi + endif + +@@ -247,9 +177,11 @@ + -$(CP) aws.txt $(I_DOC) + -$(CP) *.info* $(I_DOC) + ++aws.info aws.pdf aws.dvi aws.txt aws.html: $(APIFILES) ++ + clean: + -$(GNAT) clean -Pdocs -XPRJ_Build=${PRJ_BUILD} -XPRJ_XMLADA=Installed +- -$(RM) -f aws.texi aws.dvi aws.html aws.info* aws.log aws.ps aws.txt +- -$(RM) -f $(APIFILES) *~ genout ++ -$(RM) -f aws.texi aws.dvi aws.html aws.info* aws.log aws.ps aws.txt aws.pdf ++ -$(RM) -f *.ads.texi *~ *.o *.ali genout .ads.texi ada.sed + -$(RM) -f style-guide.dvi style-guide.html style-guide.info* \ +- style-guide.log style-guide.ps style-guide.txt ++ style-guide.log style-guide.ps style-guide.pdf style-guide.txt +Index: docs/aws.texi.tmplt +=================================================================== +--- docs/aws.texi.tmplt.orig ++++ docs/aws.texi.tmplt +@@ -10,6 +10,11 @@ + @afourpaper + @end iftex + ++@dircategory GNU Ada tools ++@direntry ++* AWS: (aws). The Ada Web Server. ++@end direntry ++ + @c ----------------------------------------- MACRO + + @c Macro used for all AWS examples +Index: docs/style-guide.texi +=================================================================== +--- docs/style-guide.texi.orig ++++ docs/style-guide.texi +@@ -18,6 +18,11 @@ + @setchapternewpage off + @c %**end of header + ++@dircategory GNU Ada tools ++@direntry ++* AWS Style Guide: (style-guide). AWS Coding Style. ++@end direntry ++ + @ifinfo + @center AWS Coding Style +