diff options
| author | Nikos Mavrogiannopoulos <nmav@gnutls.org> | 2003-08-09 17:30:37 +0000 |
|---|---|---|
| committer | Nikos Mavrogiannopoulos <nmav@gnutls.org> | 2003-08-09 17:30:37 +0000 |
| commit | fc3862bdc14cbb39200ab622cef44e90e49616d3 (patch) | |
| tree | 1ae2a3ccdd19ba8c79128bb2f9d35069fa9d62b9 | |
| parent | 04a2b6cdd6a3e4f1d51720e5bb1ea40728ba6ed2 (diff) | |
| download | gnutls-fc3862bdc14cbb39200ab622cef44e90e49616d3.tar.gz | |
Applied patch from Arne Thomassen <arne@arne-thomassen.de>, which
corrects several things in the library.
40 files changed, 481 insertions, 450 deletions
@@ -1,5 +1,7 @@ Version 0.9.7 - The tex files are now included in the distribution. +- The library can now decrypt PKCS #12 files encrypted with + the RC2-40 cipher. Version 0.9.6 (28/06/2003) - Added gnutls_x509_privkey_get_key_id() and gnutls_x509_crt_get_key_id() diff --git a/configure.in b/configure.in index a907925a60..d68318ea5e 100644 --- a/configure.in +++ b/configure.in @@ -222,7 +222,7 @@ AC_MSG_RESULT([*** *** Checking for external libraries... ]) -AM_PATH_LIBGCRYPT(1.1.12,, +AM_PATH_LIBGCRYPT(1.1.42,, AC_MSG_ERROR([[ *** *** libgcrypt was not found. You may want to get it from diff --git a/doc/README.CODING_STYLE b/doc/README.CODING_STYLE index 96506a268f..76b2c0ceaa 100644 --- a/doc/README.CODING_STYLE +++ b/doc/README.CODING_STYLE @@ -6,48 +6,48 @@ The rules here are not always used, although we try to stick to them. All file names are usually prefixed with "gnutls_", "auth_", or "x509_", or something else that indicates the part of gnutls where this file refers to. The suffix should be more - specific. Ie. "gnutls_record.c" refers to the TLS library - and more specific, to the TLS record protocol. "auth_rsa", + specific. I.e., "gnutls_record.c" refers to the TLS library + and, more specifically, to the TLS record protocol. "auth_rsa.c" is the implementation of the RSA certificate authentication method. - An other way to distinguish files, might be using different + Another way to distinguish files might be using different subdirectories. Use the lib/x509/ directory, which contains all the X.509 certificate and crl stuff. *** Function names: All the function names use underscore "_", to separate words, - functions like gnutlsDoThat, are not used. The function names + functions like gnutlsDoThat are not used. The function names usually start with "gnutls_" prefix, and the words that follow specify the exact part of gnutls that this function refers to. - Ie "gnutls_x509_crt_get_dn", refers to the X.509 + E.g. "gnutls_x509_crt_get_dn", refers to the X.509 certificate parsing part of gnutls. Currently used prefixes are: "gnutls_x509_crt_" for the X.509 certificate part "gnutls_openpgp_key_" for the openpgp key part "gnutls_session_" for the TLS session part (but this may be omited) "gnutls_handshake_" for the TLS handshake part - "gnutls_record_" for the TLS record part + "gnutls_record_" for the TLS record protocol part "gnutls_alert_" for the TLS alert protocol part "gnutls_credentials_" for the credentials structures "gnutls_global_" for the global structures handling and probably more. Internal functions -- that are not exported in the API -- should - be prefixed with an underscore. Ie. _gnutls_handshake_begin() + be prefixed with an underscore. E.g. _gnutls_handshake_begin() - All exported functions must be listed in gnutls.sym and gnutls-extra.sym, + All exported functions must be listed in gnutls.sym and gnutls-extra.sym in order to be exported. *** Constructed types: The constructed types in gnutls always have the "gnutls_" prefix. Definitions, value defaults and enumerated values should be in - capitals. Ie GNUTLS_CIPHER_3DES_CBC + capitals. E.g. GNUTLS_CIPHER_3DES_CBC *** Function parameters: The gnutls functions accept parameters in the order: - 1. Input parameters. + 1. Input parameters 2. Output parameters When data and size is expected, a gnutls_datum structure should be @@ -56,7 +56,7 @@ The rules here are not always used, although we try to stick to them. *** Callback function parameters: Callback functions should be avoided, if this is possible. Callbacks that refer to a TLS session should include the - current session as a parameter, in order for the called, to + current session as a parameter, in order for the called function to be able to retrieve the data associated with the session. This is not always done though -- see the push/pull callbacks. @@ -65,6 +65,6 @@ The rules here are not always used, although we try to stick to them. case 0 should be returned in case of success, or maybe a positive value, if some other indication is needed. - A negative value, always indicates failure. All the available + A negative value always indicates failure. All the available error codes are defined in gnutls_errors_int.h and a description is available in gnutls_errors.c diff --git a/doc/README.CVS b/doc/README.CVS index d48ec9d131..cac8b2096f 100644 --- a/doc/README.CVS +++ b/doc/README.CVS @@ -1,7 +1,7 @@ If you just want to browse the cvs tree, you may visit http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/gnutls/?cvsroot=GNU+TLS+Library -Otherwise, if you want to get and built the tree, you should have the +Otherwise, if you want to get and build the tree, you should have the following software: * cvs (http://www.gnu.org/software/cvs/) @@ -35,6 +35,5 @@ $ cd doc/tex $ make gnutls.ps $ make gnutls.html -4. If you intend to change any code in gnutls, check the +4. If you intend to change any code in gnutls, check the file doc/README.CODING_STYLE. - diff --git a/doc/protocol/draft-ietf-tls-rfc2246-bis-04.txt b/doc/protocol/draft-ietf-tls-rfc2246-bis-05.txt index 401621a5c0..924d19fb1e 100644 --- a/doc/protocol/draft-ietf-tls-rfc2246-bis-04.txt +++ b/doc/protocol/draft-ietf-tls-rfc2246-bis-05.txt @@ -8,7 +8,7 @@ Independent | Eric Rescorla | INTERNET-DRAFT RTFM, Inc. | -<draft-ietf-tls-rfc2246-bis-04.txt> April 2003 (Expires October 2003) | +<draft-ietf-tls-rfc2246-bis-05.txt> June 2003 (Expires December 2003) | The TLS Protocol Version 1.1 | @@ -55,7 +55,7 @@ Table of Contents -Dierks & Rescorla Standards Track [Page 1] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 1] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 4.4. Numbers 7 @@ -109,7 +109,7 @@ Dierks & Rescorla Standards Track [Page 1] draft- -Dierks & Rescorla Standards Track [Page 2] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 2] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 A.4. Handshake protocol 51 @@ -152,20 +152,24 @@ Change history | Note: Change bars in this draft are from RFC 2246, not draft-00 | + 26-Jun-03 ekr@rtfm.com | + * Incorporated Last Call comments from Franke Marcus, Jack Lloyd, | + Brad Wetmore, and others. | + 22-Apr-03 ekr@rtfm.com | * coverage of the Vaudenay, Boneh-Brumley, and KPR attacks | * cleaned up IV text a bit. | * Added discussion of Denial of Service attacks. | - | - 11-Feb-02 ekr@rtfm.com | - * Clarified the behavior of empty certificate lists [Nelson Bolyard] | - * Added text explaining the security implications of authenticate | -Dierks & Rescorla Standards Track [Page 3] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 3] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + | + 11-Feb-02 ekr@rtfm.com | + * Clarified the behavior of empty certificate lists [Nelson Bolyard] | + * Added text explaining the security implications of authenticate | then encrypt. | * Cleaned up the explicit IV text. | * Added some more acknowledgement names | @@ -210,15 +214,15 @@ Dierks & Rescorla Standards Track [Page 3] draft- * Removed the reference to requiring the master secret to generate | the CertificateVerify in F.1.1 [Bodo Moeller] | * Deprecated EXPORT40. | - * Fixed a bunch of errors in the SSLv2 backward compatible client hello.| -1. Introduction +Dierks & Rescorla Standards Track [Page 4] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 -Dierks & Rescorla Standards Track [Page 4] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 + * Fixed a bunch of errors in the SSLv2 backward compatible client hello.| +1. Introduction The primary goal of the TLS Protocol is to provide privacy and data integrity between two communicating applications. The protocol is @@ -264,16 +268,16 @@ Dierks & Rescorla Standards Track [Page 4] draft- negotiation communication without being detected by the parties to the communication. - One advantage of TLS is that it is application protocol independent. - Higher level protocols can layer on top of the TLS Protocol - transparently. The TLS standard, however, does not specify how - protocols add security with TLS; the decisions on how to initiate TLS -Dierks & Rescorla Standards Track [Page 5] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 5] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + One advantage of TLS is that it is application protocol independent. + Higher level protocols can layer on top of the TLS Protocol + transparently. The TLS standard, however, does not specify how + protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of TLS. @@ -318,16 +322,16 @@ Dierks & Rescorla Standards Track [Page 5] draft- significant enough that TLS 1.0 and SSL 3.0 do not interoperate (although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0). This document is intended - primarily for readers who will be implementing the protocol and those - doing cryptographic analysis of it. The specification 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 -Dierks & Rescorla Standards Track [Page 6] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 6] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + primarily for readers who will be implementing the protocol and those + doing cryptographic analysis of it. The specification 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. @@ -375,11 +379,7 @@ Dierks & Rescorla Standards Track [Page 6] draft- - - - - -Dierks & Rescorla Standards Track [Page 7] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 7] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 4.1. Basic block size @@ -433,7 +433,7 @@ Dierks & Rescorla Standards Track [Page 7] draft- -Dierks & Rescorla Standards Track [Page 8] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 8] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 Variable length vectors are defined by specifying a subrange of legal @@ -487,7 +487,7 @@ Dierks & Rescorla Standards Track [Page 8] draft- -Dierks & Rescorla Standards Track [Page 9] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 9] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 be assigned a value, as demonstrated in the following example. Since @@ -541,7 +541,7 @@ Dierks & Rescorla Standards Track [Page 9] draft- -Dierks & Rescorla Standards Track [Page 10] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 10] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 The fields within a structure may be qualified using the type's name @@ -595,7 +595,7 @@ Dierks & Rescorla Standards Track [Page 10] draft- -Dierks & Rescorla Standards Track [Page 11] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 11] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 orange VariantRecord @@ -649,7 +649,7 @@ Dierks & Rescorla Standards Track [Page 11] draft- -Dierks & Rescorla Standards Track [Page 12] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 12] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 An RSA encrypted value is encoded with PKCS #1 block type 2 as @@ -703,7 +703,7 @@ Dierks & Rescorla Standards Track [Page 12] draft- -Dierks & Rescorla Standards Track [Page 13] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 13] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 data). Additional hash algorithms can be defined by cipher suites and @@ -757,7 +757,7 @@ Dierks & Rescorla Standards Track [Page 13] draft- -Dierks & Rescorla Standards Track [Page 14] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 14] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 The secret is partitioned into two halves (with the possibility of @@ -811,7 +811,7 @@ Dierks & Rescorla Standards Track [Page 14] draft- -Dierks & Rescorla Standards Track [Page 15] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 15] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 6.1. Connection states @@ -865,7 +865,7 @@ Dierks & Rescorla Standards Track [Page 15] draft- -Dierks & Rescorla Standards Track [Page 16] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 16] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 server random @@ -903,8 +903,8 @@ Dierks & Rescorla Standards Track [Page 16] draft- opaque server_random[32]; } SecurityParameters; - The record layer will use the security parameters to generate the - following six items: + The record layer will use the security parameters to generate the | + following four items: client write MAC secret server write MAC secret @@ -919,7 +919,7 @@ Dierks & Rescorla Standards Track [Page 16] draft- -Dierks & Rescorla Standards Track [Page 17] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 17] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 generated, the connection states can be instantiated by making them | @@ -943,8 +943,10 @@ Dierks & Rescorla Standards Track [Page 17] draft- Each connection state contains a sequence number, which is maintained separately for read and write states. The sequence | number MUST be set to zero whenever a connection state is made - the active state. Sequence numbers are of type uint64 and may not - exceed 2^64-1. A sequence number is incremented after each + the active state. Sequence numbers are of type uint64 and may not | + exceed 2^64-1. Sequence numbers do not wrap. If a TLS | + implementation would need to wrap a sequence number it must | + renegotiate instead. A sequence number is incremented after each record: specifically, the first record which is transmitted under | a particular connection state MUST use sequence number 0. @@ -968,14 +970,14 @@ Dierks & Rescorla Standards Track [Page 17] draft- } ProtocolVersion; enum { - change_cipher_spec(20), alert(21), handshake(22), - application_data(23), (255) -Dierks & Rescorla Standards Track [Page 18] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 18] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + change_cipher_spec(20), alert(21), handshake(22), + application_data(23), (255) } ContentType; struct { @@ -1006,8 +1008,11 @@ Dierks & Rescorla Standards Track [Page 18] draft- specified by the type field. Note: Data of different TLS Record layer content types MAY be | - interleaved. Application data is generally of lower precedence - for transmission than other content types. + interleaved. Application data is generally of lower precedence | + for transmission than other content types and therefore handshake | + records may be held if application data is pending. However, | + records MUST be delivered to the network in the same order as | + they are protected by the record layer. | 6.2.2. Record compression and decompression @@ -1019,16 +1024,16 @@ Dierks & Rescorla Standards Track [Page 18] draft- functions are initialized with default state information whenever a connection state is made active. - Compression must be lossless and may not increase the content length - by more than 1024 bytes. If the decompression function encounters a - TLSCompressed.fragment that would decompress to a length in excess of - 2^14 bytes, it should report a fatal decompression failure error. +Dierks & Rescorla Standards Track [Page 19] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 -Dierks & Rescorla Standards Track [Page 19] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 + Compression must be lossless and may not increase the content length + by more than 1024 bytes. If the decompression function encounters a + TLSCompressed.fragment that would decompress to a length in excess of + 2^14 bytes, it should report a fatal decompression failure error. struct { ContentType type; /* same as TLSPlaintext.type */ @@ -1074,15 +1079,14 @@ Dierks & Rescorla Standards Track [Page 19] draft- version The version field is identical to TLSCompressed.version. - length - The length (in bytes) of the following TLSCiphertext.fragment. - The length may not exceed 2^14 + 2048. +Dierks & Rescorla Standards Track [Page 20] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 -Dierks & Rescorla Standards Track [Page 20] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 - + length + The length (in bytes) of the following TLSCiphertext.fragment. + The length may not exceed 2^14 + 2048. fragment | The encrypted form of TLSCompressed.fragment, with the MAC. @@ -1129,15 +1133,14 @@ Dierks & Rescorla Standards Track [Page 20] draft- functions convert TLSCompressed.fragment structures to and from block TLSCiphertext.fragment structures. - block-ciphered struct { - opaque IV[CipherSpec.block_length]; | - opaque content[TLSCompressed.length]; - -Dierks & Rescorla Standards Track [Page 21] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 21] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + block-ciphered struct { + opaque IV[CipherSpec.block_length]; | + opaque content[TLSCompressed.length]; opaque MAC[CipherSpec.hash_size]; uint8 padding[GenericBlockCipher.padding_length]; uint8 padding_length; @@ -1145,7 +1148,7 @@ Dierks & Rescorla Standards Track [Page 21] draft- The MAC is generated as described in Section 6.2.3.1. - encryptedIV | + IV | Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit | IV in order to prevent the attacks described by [CBCATT]. | We recommend the following equivalently strong procedures. | @@ -1184,14 +1187,13 @@ Dierks & Rescorla Standards Track [Page 21] draft- E(mask XOR R) is placed in the IV field. The first | block of content contains E(IV XOR data) | - The following alternative procedure MAY be used: However, it has | - not been demonstrated to be equivalently cryptographically strong | - -Dierks & Rescorla Standards Track [Page 22] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 22] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + The following alternative procedure MAY be used: However, it has | + not been demonstrated to be equivalently cryptographically strong | to the above procedures. The sender prepends a fixed block F to | the plaintext (or alternatively a block generated with a weak | PRNG). He then encrypts as in (2) above, using the CBC residue | @@ -1215,7 +1217,7 @@ Dierks & Rescorla Standards Track [Page 22] draft- the lengths of exchanged messages. Each uint8 in the padding data | vector MUST be filled with the padding length value. The receiver | MUST check this padding and SHOULD use the bad_record_mac alert | - to indivate padding errors. + to indicate padding errors. padding_length The padding length MUST be such that the total size of the | @@ -1229,22 +1231,23 @@ Dierks & Rescorla Standards Track [Page 22] draft- padding_length. Example: If the block length is 8 bytes, the content length - (TLSCompressed.length) is 61 bytes, and the MAC length is 20 - bytes, the length before padding is 82 bytes. Thus, the - padding length modulo 8 must be equal to 6 in order to make - the total length an even multiple of 8 bytes (the block - length). The padding length can be 6, 14, 22, and so on, - through 254. If the padding length were the minimum necessary, - 6, the padding would be 6 bytes, each containing the value 6. - Thus, the last 8 octets of the GenericBlockCipher before block - encryption would be xx 06 06 06 06 06 06 06, where xx is the - last octet of the MAC. + (TLSCompressed.length) is 61 bytes, and the MAC length is 20 | + bytes, the length before padding is 82 bytes (this does not | + include the IV, which may or may not be encrypted, as | + discussed above). Thus, the padding length modulo 8 must be + equal to 6 in order to make the total length an even multiple + of 8 bytes (the block length). The padding length can be 6, + 14, 22, and so on, through 254. If the padding length were the + minimum necessary, 6, the padding would be 6 bytes, each + containing the value 6. Thus, the last 8 octets of the +Dierks & Rescorla Standards Track [Page 23] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 -Dierks & Rescorla Standards Track [Page 23] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 + GenericBlockCipher before block encryption would be xx 06 06 + 06 06 06 06 06, where xx is the last octet of the MAC. Note: With block ciphers in CBC mode (Cipher Block Chaining), | it is critical that the entire plaintext of the record be known | @@ -1272,12 +1275,12 @@ Dierks & Rescorla Standards Track [Page 23] draft- secrets from the security parameters provided by the handshake protocol. - 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 connection state (see Appendix A.6). CipherSpecs require - a client write MAC secret, a server write MAC secret, a client write | - key, and a server write key, which are generated from the master | - secret in that order. Unused values are empty. + The master secret is hashed into a sequence of secure bytes, which | + are assigned to the MAC secrets and keys required by the current + connection state (see Appendix A.6). CipherSpecs require a client + write MAC secret, a server write MAC secret, a client write key, and | + a server write key, which are generated from the master secret in | + that order. Unused values are empty. When generating keys and MAC secrets, the master secret is used as an entropy source, and the random values provide unencrypted salt | @@ -1291,15 +1294,15 @@ Dierks & Rescorla Standards Track [Page 23] draft- SecurityParameters.client_random); until enough output has been generated. Then the key_block is - partitioned as follows: - client_write_MAC_secret[SecurityParameters.hash_size] +Dierks & Rescorla Standards Track [Page 24] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 -Dierks & Rescorla Standards Track [Page 24] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 + partitioned as follows: + client_write_MAC_secret[SecurityParameters.hash_size] server_write_MAC_secret[SecurityParameters.hash_size] client_write_key[SecurityParameters.key_material_length] server_write_key[SecurityParameters.key_material_length] @@ -1345,15 +1348,15 @@ Dierks & Rescorla Standards Track [Page 24] draft- final_client_write_key = PRF(client_write_key, "client write key", client_random + - server_random)[0..15] - final_server_write_key = PRF(server_write_key, - "server write key", -Dierks & Rescorla Standards Track [Page 25] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 25] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + server_random)[0..15] + final_server_write_key = PRF(server_write_key, + "server write key", client_random + server_random)[0..15] @@ -1399,15 +1402,15 @@ Dierks & Rescorla Standards Track [Page 25] draft- 7.1. 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) -Dierks & Rescorla Standards Track [Page 26] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 26] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + 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) connection state. The message consists of a single byte of value 1. struct { @@ -1453,15 +1456,15 @@ Dierks & Rescorla Standards Track [Page 26] draft- certificate_revoked(44), certificate_expired(45), certificate_unknown(46), - illegal_parameter(47), - unknown_ca(48), - access_denied(49), -Dierks & Rescorla Standards Track [Page 27] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 27] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + illegal_parameter(47), + unknown_ca(48), + access_denied(49), decode_error(50), decrypt_error(51), export_restriction(60), @@ -1507,15 +1510,15 @@ Dierks & Rescorla Standards Track [Page 27] draft- close_notify alert before indicating to the application layer that the TLS connection has ended. If the application protocol will not transfer any additional data, but will only close the underlying | - transport connection, then the implementation MAY choose to close the - transport without waiting for the responding close_notify. No part of - this standard should be taken to dictate the manner in which a usage -Dierks & Rescorla Standards Track [Page 28] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 28] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + transport connection, then the implementation MAY choose to close the + transport without waiting for the responding close_notify. No part of + this standard should be taken to dictate the manner in which a usage profile for TLS manages its data transport, including when connections are opened or closed. @@ -1551,7 +1554,7 @@ Dierks & Rescorla Standards Track [Page 28] draft- NB: Differentiating between bad_record_mac and decryption_failed | alerts may permit certain attacks against CBC mode as used in TLS | - [CBCATTACK]. It is preferable to uniformly use the bad_record_mac | + [CBCATT]. It is preferable to uniformly use the bad_record_mac | alert to hide the specific type of the error. | @@ -1561,14 +1564,15 @@ Dierks & Rescorla Standards Track [Page 28] draft- with more than 2^14+1024 bytes. 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. -Dierks & Rescorla Standards Track [Page 29] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 29] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + + 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 @@ -1614,16 +1618,16 @@ Dierks & Rescorla Standards Track [Page 29] draft- decode_error A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This - message is always fatal. - decrypt_error - A handshake cryptographic operation failed, including being +Dierks & Rescorla Standards Track [Page 30] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 -Dierks & Rescorla Standards Track [Page 30] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 + message is always fatal. + decrypt_error + A handshake cryptographic operation failed, including being unable to correctly verify a signature, decrypt a key exchange, or validate a finished message. @@ -1668,16 +1672,16 @@ Dierks & Rescorla Standards Track [Page 30] draft- satisfy a request; the process might receive security parameters (key length, authentication, etc.) at startup and it might be difficult to communicate changes to these parameters after that - point. This message is always a warning. - For all errors where an alert level is not explicitly specified, the | - sending party MAY determine at its discretion whether this is a fatal +Dierks & Rescorla Standards Track [Page 31] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 -Dierks & Rescorla Standards Track [Page 31] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 + point. This message is always a warning. + For all errors where an alert level is not explicitly specified, the | + sending party MAY determine at its discretion whether this is a fatal error or not; if an alert with a level of warning is received, the @@ -1725,11 +1729,7 @@ Dierks & Rescorla Standards Track [Page 31] draft- - - - - -Dierks & Rescorla Standards Track [Page 32] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 32] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 receiving party MAY decide at its discretion whether to treat this as | @@ -1783,7 +1783,7 @@ Dierks & Rescorla Standards Track [Page 32] draft- -Dierks & Rescorla Standards Track [Page 33] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 33] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 However, you SHOULD never send data over a link encrypted with 40 bit | @@ -1837,7 +1837,7 @@ Dierks & Rescorla Standards Track [Page 33] draft- -Dierks & Rescorla Standards Track [Page 34] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 34] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 Cipher Spec. At this point, the handshake is complete and the client @@ -1891,7 +1891,7 @@ Dierks & Rescorla Standards Track [Page 34] draft- -Dierks & Rescorla Standards Track [Page 35] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 35] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 Client Server @@ -1945,7 +1945,7 @@ Dierks & Rescorla Standards Track [Page 35] draft- -Dierks & Rescorla Standards Track [Page 36] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 36] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 The handshake protocol messages are presented below in the order they | @@ -1954,7 +1954,7 @@ Dierks & Rescorla Standards Track [Page 36] draft- however. Note one exception to the ordering: the Certificate message is used twice in the handshake (from server to client, then from client to server), but described only in its first position. The one - message which is not bound by these ordering rules in the Hello + message which is not bound by these ordering rules is the Hello | Request message, which can be sent at any time, but which should be ignored by the client if it arrives in the middle of a handshake. @@ -1999,7 +1999,7 @@ Dierks & Rescorla Standards Track [Page 36] draft- -Dierks & Rescorla Standards Track [Page 37] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 37] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 7.4.1.2. Client hello @@ -2053,7 +2053,7 @@ Dierks & Rescorla Standards Track [Page 37] draft- -Dierks & Rescorla Standards Track [Page 38] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 38] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 Warning: @@ -2107,7 +2107,7 @@ Dierks & Rescorla Standards Track [Page 38] draft- -Dierks & Rescorla Standards Track [Page 39] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 39] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 cipher_suites @@ -2140,7 +2140,7 @@ Dierks & Rescorla Standards Track [Page 39] draft- precisely. Note: For the intended use of trailing data in the ClientHello, see RFC | - XXXX [Extensions]. | + 3546 [TLSEXT]. | 7.4.1.3. Server hello @@ -2161,7 +2161,7 @@ Note: For the intended use of trailing data in the ClientHello, see RFC | -Dierks & Rescorla Standards Track [Page 40] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 40] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 server_version @@ -2215,7 +2215,7 @@ Dierks & Rescorla Standards Track [Page 40] draft- -Dierks & Rescorla Standards Track [Page 41] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 41] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 algorithm for the certificate MUST be the same as the algorithm | @@ -2269,7 +2269,7 @@ Dierks & Rescorla Standards Track [Page 41] draft- -Dierks & Rescorla Standards Track [Page 42] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 42] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 certificate_list @@ -2323,7 +2323,7 @@ Dierks & Rescorla Standards Track [Page 42] draft- -Dierks & Rescorla Standards Track [Page 43] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 43] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 Meaning of this message: @@ -2377,7 +2377,7 @@ Dierks & Rescorla Standards Track [Page 43] draft- -Dierks & Rescorla Standards Track [Page 44] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 44] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 struct { @@ -2391,6 +2391,15 @@ Dierks & Rescorla Standards Track [Page 44] draft- }; } ServerKeyExchange; + struct { | + select (KeyExchangeAlgorithm) { | + case diffie_hellman: | + ServerDHParams params; | + case rsa: | + ServerRSAParams params; | + }; | + } ServerParams; | + params The server's key exchange parameters. @@ -2407,8 +2416,10 @@ Dierks & Rescorla Standards Track [Page 44] draft- enum { anonymous, rsa, dsa } SignatureAlgorithm; - select (SignatureAlgorithm) - { case anonymous: struct { }; + + select (SignatureAlgorithm) | + { | + case anonymous: struct { }; | case rsa: digitally-signed struct { opaque md5_hash[16]; @@ -2417,6 +2428,12 @@ Dierks & Rescorla Standards Track [Page 44] draft- case dsa: digitally-signed struct { opaque sha_hash[20]; + + + +Dierks & Rescorla Standards Track [Page 45] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + + }; } Signature; @@ -2429,11 +2446,6 @@ Dierks & Rescorla Standards Track [Page 44] draft- message (if it is sent; otherwise, the Server Certificate message). - - -Dierks & Rescorla Standards Track [Page 45] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 - - Structure of this message: enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), @@ -2450,8 +2462,8 @@ Dierks & Rescorla Standards Track [Page 45] draft- } CertificateRequest; certificate_types - This field is a list of the types of certificates requested, - sorted in order of the server's preference. + 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 @@ -2465,13 +2477,19 @@ Dierks & Rescorla Standards Track [Page 45] draft- arrangement to the contrary. | - Note: values listed as RESERVED may not be used. They were used in | + Note: Values listed as RESERVED may not be used. They were used in | SSLv3. Note: DistinguishedName is derived from [X509]. + + + +Dierks & Rescorla Standards Track [Page 46] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + + Note: It is a fatal handshake_failure alert for an anonymous server to - request client identification. + request client authentication. | 7.4.5. Server hello done @@ -2482,12 +2500,6 @@ Dierks & Rescorla Standards Track [Page 45] draft- Meaning of this message: This message means that the server is done sending messages to - - - -Dierks & Rescorla Standards Track [Page 46] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 - - support the key exchange, and the client can proceed with its phase of the key exchange. @@ -2524,6 +2536,12 @@ Dierks & Rescorla Standards Track [Page 46] draft- When this message will be sent: This message is always sent by the client. It will immediately + + + +Dierks & Rescorla Standards Track [Page 47] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + + follow the client certificate message, if it is sent. Otherwise it will be the first message sent by the client after it receives the server hello done message. @@ -2536,12 +2554,6 @@ Dierks & Rescorla Standards Track [Page 46] draft- exchange method is DH_RSA or DH_DSS, client certification has been requested, and the client was able to respond with a certificate which contained a Diffie-Hellman public key whose - - - -Dierks & Rescorla Standards Track [Page 47] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 - - parameters (group and generator) matched those specified by the | server in its certificate, this message MUST not contain any data. @@ -2578,6 +2590,12 @@ Dierks & Rescorla Standards Track [Page 47] draft- client_version The latest (newest) version supported by the client. This is used to detect version roll-back attacks. Upon receiving the | + + + +Dierks & Rescorla Standards Track [Page 48] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + + premaster secret, the server SHOULD check that this value matches the value transmitted by the client in the client hello message. @@ -2590,12 +2608,6 @@ Dierks & Rescorla Standards Track [Page 47] draft- } EncryptedPreMasterSecret; pre_master_secret | - - - -Dierks & Rescorla Standards Track [Page 48] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 - - This random value is generated by the client and is used to | generate the master secret, as specified in Section 8.1. | @@ -2632,28 +2644,28 @@ Dierks & Rescorla Standards Track [Page 48] draft- implementations to generate and accept the correct encoding. | Implementors who wish to be compatible with both SSLv3 and TLS | should make their implementation's behavior dependent on the | - protocol version. + + + +Dierks & Rescorla Standards Track [Page 49] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + + + protocol version. | Implementation Note: It is now known that remote timing-based attacks | on SSL are possible, at least when the client and server are on | the same LAN. Accordingly, implementations which use static RSA | keys SHOULD use RSA blinding or some other anti-timing technique, | - as described in [TIMING]. | + as described in [TIMING]. Note: The version number in the PreMasterSecret is that offered by the | client, NOT the version negotiated for the connection. This | feature is designed to prevent rollback attacks. Unfortunately, | many implementations use the negotiated version instead and | - - - -Dierks & Rescorla Standards Track [Page 49] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 - - therefore checking the version number may lead to failure to | interoperate with such incorrect client implementations. Client | - implementations MUST Server implementations MAY check the version | - number. In practice, since there are no significant known | + implementations MUST and Server implementations MAY check the | + version number. In practice, since there are no significant known | security differences between TLS and SSLv3, rollback to SSLv3 is | not believed to be a serious security risk. Note that if servers | choose to to check the version number, they should randomize the | @@ -2686,6 +2698,12 @@ Dierks & Rescorla Standards Track [Page 49] draft- case implicit: struct { }; case explicit: opaque dh_Yc<1..2^16-1>; } dh_public; + + + +Dierks & Rescorla Standards Track [Page 50] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + + } ClientDiffieHellmanPublic; dh_Yc @@ -2698,12 +2716,6 @@ Dierks & Rescorla Standards Track [Page 49] draft- certificate. This message is only sent following a client certificate that has signing capability (i.e. all certificates except those containing fixed Diffie-Hellman parameters). When - - - -Dierks & Rescorla Standards Track [Page 50] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 - - sent, it will immediately follow the client key exchange message. Structure of this message: @@ -2716,7 +2728,7 @@ Dierks & Rescorla Standards Track [Page 50] draft- CertificateVerify.signature.md5_hash MD5(handshake_messages); - Certificate.signature.sha_hash + CertificateVerify.signature.sha_hash | SHA(handshake_messages); Here handshake_messages refers to all handshake messages sent or @@ -2740,6 +2752,12 @@ Dierks & Rescorla Standards Track [Page 50] draft- messages MUST verify that the contents are correct. Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive + + + +Dierks & Rescorla Standards Track [Page 51] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + + application data over the connection. struct { @@ -2752,12 +2770,6 @@ Dierks & Rescorla Standards Track [Page 50] draft- finished_label For Finished messages sent by the client, the string "client - - - -Dierks & Rescorla Standards Track [Page 51] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 - - finished". For Finished messages sent by the server, the string "server finished". @@ -2795,6 +2807,11 @@ Dierks & Rescorla Standards Track [Page 51] draft- are exchanged in the hello messages. All that remains is to calculate the master secret. + + +Dierks & Rescorla Standards Track [Page 52] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + + 8.1. Computing the master secret For all key exchange methods, the same algorithm is used to convert @@ -2806,12 +2823,6 @@ Dierks & Rescorla Standards Track [Page 51] draft- ClientHello.random + ServerHello.random) [0..47]; - - - -Dierks & Rescorla Standards Track [Page 52] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 - - The master secret is always exactly 48 bytes in length. The length of the premaster secret will vary depending on key exchange method. @@ -2852,18 +2863,7 @@ Dierks & Rescorla Standards Track [Page 52] draft- - - - - - - - - - - - -Dierks & Rescorla Standards Track [Page 53] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 53] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 8.1.1. RSA @@ -2882,7 +2882,8 @@ Dierks & Rescorla Standards Track [Page 53] draft- 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. + into the master_secret, as specified above. Leading 0 bytes of Z are | + stripped before it is used as the pre_master_secret. Note: Diffie-Hellman parameters are specified by the server, and may be either ephemeral or contained within the server's certificate. @@ -2916,8 +2917,7 @@ Dierks & Rescorla Standards Track [Page 53] draft- - -Dierks & Rescorla Standards Track [Page 54] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 54] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 A. Protocol constant values @@ -2971,7 +2971,7 @@ A.1. Record layer -Dierks & Rescorla Standards Track [Page 55] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 55] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 opaque content[TLSCompressed.length]; @@ -3025,7 +3025,7 @@ A.3. Alert messages -Dierks & Rescorla Standards Track [Page 56] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 56] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 A.4. Handshake protocol @@ -3079,7 +3079,7 @@ A.4.1. Hello messages -Dierks & Rescorla Standards Track [Page 57] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 57] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 } ClientHello; @@ -3124,18 +3124,27 @@ A.4.2. Server authentication and key exchange messages }; } ServerKeyExchange; - enum { anonymous, rsa, dsa } SignatureAlgorithm; + enum { anonymous, rsa, dsa } SignatureAlgorithm; | - select (SignatureAlgorithm) - { case anonymous: struct { }; - case rsa: - digitally-signed struct { + struct { | + select (KeyExchangeAlgorithm) { | + case diffie_hellman: | + ServerDHParams params; | -Dierks & Rescorla Standards Track [Page 58] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 58] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + case rsa: | + ServerRSAParams params; | + }; | + } ServerParams; | + + select (SignatureAlgorithm) + { case anonymous: struct { }; + case rsa: + digitally-signed struct { opaque md5_hash[16]; opaque sha_hash[20]; }; @@ -3173,9 +3182,14 @@ A.4.3. Client authentication and key exchange messages struct { ProtocolVersion client_version; opaque random[46]; - } PreMasterSecret; + + + +Dierks & Rescorla Standards Track [Page 59] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + + struct { public-key-encrypted PreMasterSecret pre_master_secret; } EncryptedPreMasterSecret; @@ -3184,12 +3198,6 @@ A.4.3. Client authentication and key exchange messages struct { select (PublicValueEncoding) { - - - -Dierks & Rescorla Standards Track [Page 59] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 - - case implicit: struct {}; case explicit: opaque DH_Yc<1..2^16-1>; } dh_public; @@ -3230,6 +3238,12 @@ A.5. The CipherSuite CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; + + + +Dierks & Rescorla Standards Track [Page 60] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + + CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; @@ -3238,12 +3252,6 @@ A.5. The CipherSuite The following CipherSuite definitions are used for server- authenticated (and optionally client-authenticated) Diffie-Hellman. - - - -Dierks & Rescorla Standards Track [Page 60] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 - - 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 @@ -3284,6 +3292,12 @@ Dierks & Rescorla Standards Track [Page 60] draft- algorithms. Interoperability of such types is a local matter. Note: Additional cipher suites can be registered by publishing an RFC + + + +Dierks & Rescorla Standards Track [Page 61] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + + which specifies the cipher suites, including the necessary TLS protocol information, including message encoding, premaster secret derivation, symmetric encryption and MAC calculation and @@ -3292,12 +3306,6 @@ Dierks & Rescorla Standards Track [Page 60] draft- specifications for cipher suites which are not completely described (e.g., for classified algorithms) if it finds the specification to be of technical interest and completely - - - -Dierks & Rescorla Standards Track [Page 61] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 - - specified. Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are @@ -3338,6 +3346,12 @@ A.6. The Security Parameters CompressionMethod compression_algorithm; opaque master_secret[48]; opaque client_random[32]; + + + +Dierks & Rescorla Standards Track [Page 62] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 + + opaque server_random[32]; } SecurityParameters; @@ -3349,7 +3363,47 @@ A.6. The Security Parameters -Dierks & Rescorla Standards Track [Page 62] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 63] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 B. Glossary @@ -3403,7 +3457,7 @@ B. Glossary -Dierks & Rescorla Standards Track [Page 63] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 64] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 client write MAC secret @@ -3457,7 +3511,7 @@ Dierks & Rescorla Standards Track [Page 63] draft- -Dierks & Rescorla Standards Track [Page 64] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 65] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 Message Authentication Code (MAC) @@ -3511,7 +3565,7 @@ Dierks & Rescorla Standards Track [Page 64] draft- -Dierks & Rescorla Standards Track [Page 65] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 66] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 session @@ -3565,7 +3619,7 @@ Dierks & Rescorla Standards Track [Page 65] draft- -Dierks & Rescorla Standards Track [Page 66] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 67] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 C. CipherSuite definitions @@ -3619,7 +3673,7 @@ TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA -Dierks & Rescorla Standards Track [Page 67] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 68] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 DH_DSS DH with DSS-based certificates None @@ -3633,8 +3687,8 @@ Dierks & Rescorla Standards Track [Page 67] draft- 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. + can be legally used for encryption or key agreement in | + cipher suites that are exportable. | Key Expanded Effective IV Block Cipher Type Material Key Material Key Bits Size Size @@ -3673,7 +3727,7 @@ Dierks & Rescorla Standards Track [Page 67] draft- -Dierks & Rescorla Standards Track [Page 68] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 69] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 Block Size @@ -3727,7 +3781,7 @@ Dierks & Rescorla Standards Track [Page 68] draft- -Dierks & Rescorla Standards Track [Page 69] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 70] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 D. Implementation Notes @@ -3781,7 +3835,7 @@ D.3. Certificates and authentication -Dierks & Rescorla Standards Track [Page 70] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 71] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 Implementations are responsible for verifying the integrity of @@ -3835,7 +3889,7 @@ D.4. CipherSuites -Dierks & Rescorla Standards Track [Page 71] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 72] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 E. Backward Compatibility With SSL @@ -3850,7 +3904,7 @@ E. Backward Compatibility With SSL TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting | both is easy. TLS clients who wish to negotiate with such older | - servers should send client hello messages using the SSL 3.0 record + servers SHOULD send client hello messages using the SSL 3.0 record | format and client hello structure, sending {3, 2} for the version | field to note that they support TLS 1.1. If the server supports only | TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello; | @@ -3866,19 +3920,19 @@ E. Backward Compatibility With SSL version field of {3, 1} is received, the server SHOULD respond with a | TLS 1.0 hello with a version field of {3, 1}. - Whenever a client already knows the highest protocol known to a - server (for example, when resuming a session), it should initiate the + Whenever a client already knows the highest protocol known to a | + server (for example, when resuming a session), it SHOULD initiate the connection in that native protocol. - TLS 1.1 clients that support SSL Version 2.0 servers must send SSL | - Version 2.0 client hello messages [SSL2]. TLS servers should accept + TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL | + Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept either client hello format if they wish to support SSL 2.0 clients on the same connection port. 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. Implementors should make every + phased out with all due haste. Implementors SHOULD make every | effort to move forward as quickly as possible. Version 3.0 provides better mechanisms for moving to newer versions. @@ -3889,7 +3943,7 @@ E. Backward Compatibility With SSL -Dierks & Rescorla Standards Track [Page 72] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 73] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; @@ -3903,8 +3957,8 @@ Dierks & Rescorla Standards Track [Page 72] draft- Cipher specifications native to TLS 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 + 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 TLS equivalent (see Appendix A.5): V2CipherSpec (see TLS name) = { 0x00, CipherSuite }; @@ -3913,7 +3967,7 @@ 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. Note that this message must | + to be the SSL Version 2.0 specification. Note that this message MUST | be sent directly on the wire, not wrapped as an SSLv3 record uint8 V2CipherSpec[3]; @@ -3932,29 +3986,29 @@ E.1. Version 2 client hello msg_length | This field is the length of the following data in bytes. The high | - bit must be 1 and is not part of the length. | + bit MUST be 1 and is not part of the length. | msg_type - This field, in conjunction with the version field, identifies a - version 2 client hello message. The value should be one (1). + This field, in conjunction with the version field, identifies a | + version 2 client hello message. The value SHOULD be one (1). version The highest version of the protocol supported by the client -Dierks & Rescorla Standards Track [Page 73] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 74] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 (equals ProtocolVersion.version, see Appendix A.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 + 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 zero. | + This field MUST have a value of zero. | challenge_length The length in bytes of the client's challenge to the server to | @@ -3962,12 +4016,12 @@ Dierks & Rescorla Standards Track [Page 73] draft- handshake the client MUST use a 32-byte challenge. 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 + 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 - This field must be empty. | + This field MUST be empty. | challenge The client challenge to the server for the server to identify @@ -3983,21 +4037,21 @@ Dierks & Rescorla Standards Track [Page 73] draft- E.2. Avoiding man-in-the-middle version rollback - When TLS clients fall back to Version 2.0 compatibility mode, they - should use special PKCS #1 block formatting. This is done so that TLS + When TLS clients fall back to Version 2.0 compatibility mode, they | + SHOULD use special PKCS #1 block formatting. This is done so that TLS servers will reject Version 2.0 sessions with TLS-capable clients. When TLS 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 TLS should issue an + to 0x03 (the other padding bytes are random). After decrypting the | + ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an error if these eight padding bytes are 0x03. Version 2.0 servers -Dierks & Rescorla Standards Track [Page 74] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 75] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 receiving blocks padded in this manner will proceed normally. @@ -4051,7 +4105,7 @@ Dierks & Rescorla Standards Track [Page 74] draft- -Dierks & Rescorla Standards Track [Page 75] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 76] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 F. Security analysis @@ -4105,14 +4159,15 @@ F.1.1.1. Anonymous key exchange -Dierks & Rescorla Standards Track [Page 76] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 77] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 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. (Note that no anonymous RSA Cipher Suites are - defined in this document). + private key, it will be infeasible for them to decode the | + pre_master_secret. | + + Note: No anonymous RSA Cipher Suites are defined in this document. With Diffie-Hellman, the server's public parameters are contained in the server key exchange message and the client's are sent in the @@ -4132,11 +4187,10 @@ 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. + temporary RSA keys are used, they are signed by the server's RSA | + 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 @@ -4159,7 +4213,7 @@ F.1.1.2. RSA key exchange and authentication -Dierks & Rescorla Standards Track [Page 77] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 78] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 the certificate verify message (see Section 7.4.8). The client signs @@ -4213,7 +4267,7 @@ F.1.2. Version rollback attacks -Dierks & Rescorla Standards Track [Page 78] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 79] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 Because TLS includes substantial improvements over SSL Version 2.0, @@ -4267,7 +4321,7 @@ F.1.4. Resuming sessions -Dierks & Rescorla Standards Track [Page 79] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 80] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 force a full handshake. An upper limit of 24 hours is suggested for @@ -4321,7 +4375,7 @@ F.3. Explicit IVs | -Dierks & Rescorla Standards Track [Page 80] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 81] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 F.4 Security of Composite Cipher Modes | @@ -4375,7 +4429,7 @@ F.4 Security of Composite Cipher Modes | -Dierks & Rescorla Standards Track [Page 81] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 82] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 F.5 Denial of Service | @@ -4429,7 +4483,7 @@ F.6. Final notes -Dierks & Rescorla Standards Track [Page 82] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 83] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 G. Patent Statement @@ -4483,7 +4537,7 @@ G. Patent Statement -Dierks & Rescorla Standards Track [Page 83] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 84] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 The Internet Society, Internet Architecture Board, Internet @@ -4537,7 +4591,7 @@ Normative References | -Dierks & Rescorla Standards Track [Page 84] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 85] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax @@ -4572,28 +4626,33 @@ Dierks & Rescorla Standards Track [Page 84] draft- Netscape Communications Corp., Nov 18, 1996. [REQ] Bradner, S., "Key words for use in RFCs to Indicate | - Requirement Levels", BCP 14, RFC 2119, March 1997. | + Requirement Levels", BCP 14, RFC 2119, March 1997. [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0", | - RFC 2246, January 1999. | - [X509] CCITT. Recommendation X.509: "The Directory - Authentication | - Framework". 1988. | + RFC 2246, January 1999. + [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J., | + Wright, T., "Transport Layer Security (TLS) Extensions", RFC | + 3546, June 2003. + [X509] CCITT. Recommendation X.509: "The Directory - Authentication + Framework". 1988. -Informative References | - [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC | - 2402, November 1998. | -Dierks & Rescorla Standards Track [Page 85] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 86] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 +Informative References | + + [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC | + 2402, November 1998. | + [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against | Protocols Based on RSA Encryption Standard PKCS #1" in | Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: | @@ -4629,25 +4688,24 @@ Dierks & Rescorla Standards Track [Page 85] draft- 1994. | [SEQNUM] Bellovim. S., "Defending Against Sequence Number Attacks", | - RFC 1948, May 1996. + RFC 1948, May 1996. | [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup | Attacks on the Diffie-Hellman Key Agreement Method for | - S/MIME", RFC 2785, March 2000. + S/MIME", RFC 2785, March 2000. | [TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, | - September 1981. - - [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are | - practical", USENIX Security Symposium 2003. + September 1981. | - [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External +Dierks & Rescorla Standards Track [Page 87] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 -Dierks & Rescorla Standards Track [Page 86] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 + [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are | + practical", USENIX Security Symposium 2003. | + [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External Data Representation Standard, August 1995. @@ -4693,14 +4751,14 @@ Credits | Phil Karlton (co-author of SSLv3) | - Paul Kocher (co-author of SSLv3) | - Cryptography Research | - paul@cryptography.com | +Dierks & Rescorla Standards Track [Page 88] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 -Dierks & Rescorla Standards Track [Page 87] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 + Paul Kocher (co-author of SSLv3) | + Cryptography Research | + paul@cryptography.com | Hugo Krawczyk | Technion Israel Institute of Technology | @@ -4749,11 +4807,7 @@ Comments - - - - -Dierks & Rescorla Standards Track [Page 88] draft-ietlf-tls-rfc2246-bis-04.txt TLS April 2003 +Dierks & Rescorla Standards Track [Page 89] draft-ietlf-tls-rfc2246-bis-05.txt TLS June 2003 Full Copyright Statement @@ -4807,4 +4861,4 @@ Full Copyright Statement -Dierks & Rescorla Standards Track [Page 89] +Dierks & Rescorla Standards Track [Page 90] diff --git a/includes/gnutls/x509.h b/includes/gnutls/x509.h index ce87e4750e..6e3e06f7dd 100644 --- a/includes/gnutls/x509.h +++ b/includes/gnutls/x509.h @@ -212,7 +212,8 @@ typedef enum gnutls_privkey_pkcs8_flags { * be encrypted. */ GNUTLS_PKCS8_USE_PKCS12_3DES, - GNUTLS_PKCS8_USE_PKCS12_ARCFOUR + GNUTLS_PKCS8_USE_PKCS12_ARCFOUR, + GNUTLS_PKCS8_USE_PKCS12_RC2_40 } gnutls_privkey_pkcs8_flags; int gnutls_x509_privkey_init(gnutls_x509_privkey * key); diff --git a/lib/auth_anon.c b/lib/auth_anon.c index 15a26cab14..1f12226309 100644 --- a/lib/auth_anon.c +++ b/lib/auth_anon.c @@ -67,7 +67,7 @@ static int gen_anon_server_kx( gnutls_session session, opaque** data) { cred = _gnutls_get_cred(session->key, GNUTLS_CRD_ANON, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } bits = _gnutls_dh_get_prime_bits( session); @@ -113,7 +113,7 @@ GNUTLS_MPI p, g; cred = _gnutls_get_cred(session->key, GNUTLS_CRD_ANON, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } if ( (ret=_gnutls_get_dh_params( cred->dh_params, &p, &g)) < 0) { diff --git a/lib/auth_cert.c b/lib/auth_cert.c index 45b6a977fd..1163c0c326 100644 --- a/lib/auth_cert.c +++ b/lib/auth_cert.c @@ -247,7 +247,7 @@ static int _gnutls_find_acceptable_client_cert(gnutls_session session, _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } /* If we have no callback. @@ -646,7 +646,7 @@ int _gnutls_proc_x509_server_certificate(gnutls_session session, _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } @@ -782,7 +782,7 @@ int _gnutls_proc_openpgp_server_certificate(gnutls_session session, _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } if ((ret = @@ -988,7 +988,7 @@ int _gnutls_proc_cert_cert_req(gnutls_session session, opaque * data, _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } if ((ret = @@ -1186,7 +1186,7 @@ int _gnutls_gen_cert_server_cert_req(gnutls_session session, _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } size = CERTTYPE_SIZE + 2; /* 2 for gnutls_certificate_type + 2 for size of rdn_seq @@ -1238,7 +1238,7 @@ int _gnutls_find_apr_cert(gnutls_session session, *apr_cert_list = NULL; *apr_pkey = NULL; *apr_cert_list_length = 0; - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } if (session->security_parameters.entity == GNUTLS_SERVER) { @@ -1248,7 +1248,7 @@ int _gnutls_find_apr_cert(gnutls_session session, *apr_cert_list_length = 0; *apr_pkey = NULL; gnutls_assert(); /* this is not allowed */ - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } else { /* find_cert_list_index() has been called before. */ @@ -1259,7 +1259,7 @@ int _gnutls_find_apr_cert(gnutls_session session, *apr_cert_list_length = 0; *apr_pkey = NULL; gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } else { *apr_cert_list = cred->cert_list[ind]; *apr_cert_list_length = @@ -1342,7 +1342,7 @@ static int _gnutls_server_find_cert_list_index(gnutls_session session, _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } index = -1; /* default is use no certificate */ diff --git a/lib/auth_dhe.c b/lib/auth_dhe.c index d495311c53..8e255da02d 100644 --- a/lib/auth_dhe.c +++ b/lib/auth_dhe.c @@ -91,7 +91,7 @@ static int gen_dhe_server_kx(gnutls_session session, opaque ** data) cred = _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } bits = _gnutls_dh_get_prime_bits( session); @@ -262,7 +262,7 @@ GNUTLS_MPI p, g; cred = _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } if ( (ret=_gnutls_get_dh_params( cred->dh_params, &p, &g)) < 0) { diff --git a/lib/auth_rsa.c b/lib/auth_rsa.c index 5735dc5c29..ef8d0d6d5e 100644 --- a/lib/auth_rsa.c +++ b/lib/auth_rsa.c @@ -162,7 +162,7 @@ const gnutls_certificate_credentials cred; cred = _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } if ( (index=session->internals.selected_cert_index) < 0) { @@ -307,7 +307,7 @@ int _gnutls_gen_rsa_client_kx(gnutls_session session, opaque ** data) * function should have detected that. */ gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } RANDOMIZE_KEY(session->key->key, gnutls_secure_malloc, GNUTLS_STRONG_RANDOM); diff --git a/lib/auth_rsa_export.c b/lib/auth_rsa_export.c index b57def2cff..8c4e4ca8a1 100644 --- a/lib/auth_rsa_export.c +++ b/lib/auth_rsa_export.c @@ -83,7 +83,7 @@ static int gen_rsa_export_server_kx(gnutls_session session, opaque ** data) cred = _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } /* find the appropriate certificate */ diff --git a/lib/gnutls_alert.c b/lib/gnutls_alert.c index 2c118d41f8..be5d44291d 100644 --- a/lib/gnutls_alert.c +++ b/lib/gnutls_alert.c @@ -181,7 +181,7 @@ int _level = -1; break; case GNUTLS_E_UNKNOWN_CIPHER_SUITE: case GNUTLS_E_UNKNOWN_COMPRESSION_ALGORITHM: - case GNUTLS_E_INSUFICIENT_CREDENTIALS: + case GNUTLS_E_INSUFFICIENT_CREDENTIALS: case GNUTLS_E_NO_CIPHER_SUITES: case GNUTLS_E_NO_COMPRESSION_ALGORITHMS: ret = GNUTLS_A_HANDSHAKE_FAILURE; @@ -276,4 +276,3 @@ int level; gnutls_alert_description gnutls_alert_get( gnutls_session session) { return session->internals.last_alert; } - diff --git a/lib/gnutls_anon_cred.c b/lib/gnutls_anon_cred.c index f1a1182533..98a3f56c38 100644 --- a/lib/gnutls_anon_cred.c +++ b/lib/gnutls_anon_cred.c @@ -19,12 +19,12 @@ * */ +#ifdef ENABLE_ANON + #include "gnutls_int.h" #include "gnutls_errors.h" #include "auth_anon.h" -#ifdef ENABLE_ANON - #include "gnutls_auth_int.h" #include "gnutls_dh.h" #include "gnutls_num.h" @@ -70,7 +70,6 @@ int gnutls_anon_allocate_server_credentials( gnutls_anon_server_credentials *sc) * the structure. **/ void gnutls_anon_free_client_credentials( gnutls_anon_client_credentials sc) { - return; } /** diff --git a/lib/gnutls_auth.c b/lib/gnutls_auth.c index 5efe9fa402..8454984469 100644 --- a/lib/gnutls_auth.c +++ b/lib/gnutls_auth.c @@ -52,8 +52,6 @@ void gnutls_credentials_clear( gnutls_session session) { } session->key->cred = NULL; } - - return; } /* @@ -167,10 +165,12 @@ int server = session->security_parameters.entity==GNUTLS_SERVER?1:0; } const void *_gnutls_get_cred( GNUTLS_KEY key, gnutls_credentials_type type, int *err) { + const void *retval = NULL; + int _err = -1; AUTH_CRED * ccred; - if (key == NULL) return NULL; - + if (key == NULL) goto out; + ccred = key->cred; while(ccred!=NULL) { if (ccred->algorithm==type) { @@ -178,13 +178,14 @@ const void *_gnutls_get_cred( GNUTLS_KEY key, gnutls_credentials_type type, int } ccred = ccred->next; } - if (ccred==NULL) { - if (err!=NULL) *err=-1; - return NULL; - } - - if (err!=NULL) *err=0; - return ccred->credentials; + if (ccred==NULL) goto out; + + _err = 0; + retval = ccred->credentials; + + out: + if (err!=NULL) *err=_err; + return retval; } /*- diff --git a/lib/gnutls_cert.c b/lib/gnutls_cert.c index 3b8159452c..354c5732f6 100644 --- a/lib/gnutls_cert.c +++ b/lib/gnutls_cert.c @@ -317,7 +317,7 @@ int _gnutls_openpgp_cert_verify_peers(gnutls_session session) cred = _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } if (info->raw_certificate_list == NULL || info->ncerts == 0) { @@ -571,8 +571,6 @@ void _gnutls_free_cert(gnutls_cert *cert) } _gnutls_free_datum(&cert->raw); - - return; } /* Returns the issuer's Distinguished name in odn, of the certificate diff --git a/lib/gnutls_compress_int.c b/lib/gnutls_compress_int.c index c268da9670..d43f2c5522 100644 --- a/lib/gnutls_compress_int.c +++ b/lib/gnutls_compress_int.c @@ -135,8 +135,6 @@ int err; gnutls_free( handle); } - - return; } /* These functions are memory consuming diff --git a/lib/gnutls_errors.c b/lib/gnutls_errors.c index 4fd0d5989d..d570bea753 100644 --- a/lib/gnutls_errors.c +++ b/lib/gnutls_errors.c @@ -79,7 +79,7 @@ static gnutls_error_entry error_algorithms[] = { ERROR_ENTRY("Internal error in memory allocation.", GNUTLS_E_MEMORY_ERROR, 1 ), ERROR_ENTRY("An unimplemented feature has been requested.", GNUTLS_E_UNIMPLEMENTED_FEATURE, 1 ), - ERROR_ENTRY("Insuficient credentials for that request.", GNUTLS_E_INSUFICIENT_CREDENTIALS, 1 ), + ERROR_ENTRY("Insufficient credentials for that request.", GNUTLS_E_INSUFFICIENT_CREDENTIALS, 1 ), ERROR_ENTRY("Error in SRP password file.", GNUTLS_E_SRP_PWD_ERROR, 1 ), ERROR_ENTRY("Wrong padding in PKCS1 packet.", GNUTLS_E_PKCS1_WRONG_PAD, 1 ), ERROR_ENTRY("The requested session has expired.", GNUTLS_E_EXPIRED, 1 ), @@ -274,8 +274,6 @@ void _gnutls_log( int level, const char *fmt, ...) { va_end(args); log_func( level, str); - - return; } #ifndef DEBUG # ifndef C99_MACROS diff --git a/lib/gnutls_errors_int.h b/lib/gnutls_errors_int.h index dadaf59ab2..6e153abcb2 100644 --- a/lib/gnutls_errors_int.h +++ b/lib/gnutls_errors_int.h @@ -29,8 +29,10 @@ #define GNUTLS_E_EXPIRED -29 #define GNUTLS_E_DB_ERROR -30 #define GNUTLS_E_SRP_PWD_ERROR -31 -#define GNUTLS_E_INSUFICIENT_CREDENTIALS -32 -#define GNUTLS_E_INSUFICIENT_CRED GNUTLS_E_INSUFICIENT_CREDENTIALS +#define GNUTLS_E_INSUFFICIENT_CREDENTIALS -32 +#define GNUTLS_E_INSUFICIENT_CREDENTIALS GNUTLS_E_INSUFFICIENT_CREDENTIALS /* for backwards compatibility only */ +#define GNUTLS_E_INSUFFICIENT_CRED GNUTLS_E_INSUFFICIENT_CREDENTIALS +#define GNUTLS_E_INSUFICIENT_CRED GNUTLS_E_INSUFFICIENT_CREDENTIALS /* for backwards compatibility only */ #define GNUTLS_E_HASH_FAILED -33 #define GNUTLS_E_BASE64_DECODING_ERROR -34 diff --git a/lib/gnutls_extensions.c b/lib/gnutls_extensions.c index d0177f5709..3525addf68 100644 --- a/lib/gnutls_extensions.c +++ b/lib/gnutls_extensions.c @@ -166,8 +166,6 @@ static void _gnutls_extension_list_add( gnutls_session session, uint16 type) { _gnutls_debug_log("extensions: Increase MAX_EXT_TYPES\n"); } } - - return; } int _gnutls_gen_extensions( gnutls_session session, opaque** data) { diff --git a/lib/gnutls_global.c b/lib/gnutls_global.c index 0c6319e812..d45071ff17 100644 --- a/lib/gnutls_global.c +++ b/lib/gnutls_global.c @@ -96,7 +96,7 @@ int _gnutls_is_secure_mem_null( const void*); * @secure_alloc_func: This is the memory allocation function that will be used for sensitive data. * @is_secure_func: a function that returns 0 if the memory given is not secure. May be NULL. * @realloc_func: A realloc function - * @free_func: The function that frees allocated data. + * @free_func: The function that frees allocated data. Must accept a NULL pointer. * * This is the function were you set the memory allocation functions gnutls * is going to use. By default the libc's allocation functions (malloc(), free()), @@ -117,7 +117,7 @@ void gnutls_global_set_mem_functions( gnutls_realloc = gnutls_realloc_func; gnutls_free = gnutls_free_func; - if (gnutls_is_secure_func==NULL) + if (gnutls_is_secure_func!=NULL) _gnutls_is_secure_memory = gnutls_is_secure_func; else _gnutls_is_secure_memory = _gnutls_is_secure_mem_null; @@ -132,7 +132,6 @@ void gnutls_global_set_mem_functions( gnutls_strdup = _gnutls_strdup; gnutls_calloc = _gnutls_calloc; } - return; } #ifdef DEBUG diff --git a/lib/gnutls_handshake.c b/lib/gnutls_handshake.c index 12cdf8648b..6469ff9460 100644 --- a/lib/gnutls_handshake.c +++ b/lib/gnutls_handshake.c @@ -112,8 +112,6 @@ static void resume_copy_required_values(gnutls_session session) session->security_parameters.session_id_size = session->internals.resumed_security_parameters. session_id_size; - - return; } void _gnutls_set_server_random(gnutls_session session, uint8 * random) @@ -227,7 +225,7 @@ int _gnutls_create_random(opaque * dst) gnutls_assert(); return GNUTLS_E_MEMORY_ERROR; } - memcpy(&dst[4], rand, 28); + memcpy(&dst[4], rand, TLS_RANDOM_SIZE - 4); return 0; } @@ -586,14 +584,14 @@ int _gnutls_server_select_suite(gnutls_session session, opaque *data, int datale return retval; } - /* check if the credentials (username, public key etc. are ok) + /* check if the credentials (username, public key etc.) are ok */ if (_gnutls_get_kx_cred (session, _gnutls_cipher_suite_get_kx_algo(session->security_parameters. current_cipher_suite), &err) == NULL && err != 0) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } @@ -818,11 +816,11 @@ static int _gnutls_recv_handshake_header(gnutls_session session, SSL2_HEADERS); if (ret < 0) { - return (ret < - 0) ? ret : - GNUTLS_E_UNEXPECTED_PACKET_LENGTH; + return GNUTLS_E_UNEXPECTED_PACKET_LENGTH; } + /* The case ret==0 is catched here. + */ if (ret != SSL2_HEADERS) { gnutls_assert(); return GNUTLS_E_UNEXPECTED_PACKET_LENGTH; @@ -965,8 +963,10 @@ int _gnutls_recv_handshake(gnutls_session session, uint8 ** data, if (ret < 0) { if (ret == GNUTLS_E_UNEXPECTED_HANDSHAKE_PACKET && optional == OPTIONAL_PACKET) { - *datalen = 0; - *data = NULL; + if (datalen != NULL) + *datalen = 0; + if (data != NULL) + *data = NULL; return 0; /* ok just ignore the packet */ } /* gnutls_assert(); */ @@ -1077,7 +1077,7 @@ static int _gnutls_client_set_ciphersuite(gnutls_session session, for (i = 0; i < cipher_suite_num; i++) { if (memcmp(&cipher_suites[i], suite, 2) == 0) { - z = 0; + z = 0; break; } } @@ -1107,7 +1107,7 @@ static int _gnutls_client_set_ciphersuite(gnutls_session session, current_cipher_suite), &err) == NULL && err != 0) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } @@ -1150,7 +1150,7 @@ static int _gnutls_client_set_comp_method(gnutls_session session, for (i = 0; i < comp_methods_num; i++) { if (compression_methods[i] == comp_method) { - comp_methods_num = 0; + comp_methods_num = 0; break; } } @@ -1340,7 +1340,7 @@ static int _gnutls_copy_ciphersuites(gnutls_session session, */ if (ret == 0) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } cipher_num = ret; @@ -1397,6 +1397,7 @@ static int _gnutls_copy_comp_methods(gnutls_session session, *ret_data = gnutls_malloc(datalen); if (*ret_data == NULL) { gnutls_assert(); + gnutls_free(compression_methods); return GNUTLS_E_MEMORY_ERROR; } @@ -1415,7 +1416,7 @@ static int _gnutls_copy_comp_methods(gnutls_session session, */ static int _gnutls_send_client_hello(gnutls_session session, int again) { - opaque *data = NULL; + opaque *data; opaque *extdata = NULL; int extdatalen; int pos = 0; @@ -1463,6 +1464,7 @@ static int _gnutls_send_client_hello(gnutls_session session, int again) if (hver == 0) hver = GNUTLS_E_INTERNAL_ERROR; gnutls_assert(); + gnutls_free(data); return hver; } @@ -1876,14 +1878,14 @@ int gnutls_handshake(gnutls_session session) return 0; } -#define IMED_RET( str, ret) \ +#define IMED_RET( str, ret) do { \ if (ret < 0) { \ if (gnutls_error_is_fatal(ret)==0) return ret; \ gnutls_assert(); \ ERR( str, ret); \ _gnutls_handshake_hash_buffers_clear(session); \ return ret; \ - } + } } while (0) diff --git a/lib/gnutls_hash_int.c b/lib/gnutls_hash_int.c index c5b17a4554..ebfb683b04 100644 --- a/lib/gnutls_hash_int.c +++ b/lib/gnutls_hash_int.c @@ -131,7 +131,6 @@ void _gnutls_hash_deinit(GNUTLS_HASH_HANDLE handle, void *digest) gcry_md_close(handle->handle); gnutls_free(handle); - return; } @@ -209,7 +208,6 @@ void _gnutls_hmac_deinit(GNUTLS_MAC_HANDLE handle, void *digest) gcry_md_close(handle->handle); gnutls_free(handle); - return; } GNUTLS_MAC_HANDLE _gnutls_mac_init_ssl3(gnutls_mac_algorithm algorithm, void *key, @@ -279,7 +277,6 @@ void _gnutls_mac_deinit_ssl3(GNUTLS_MAC_HANDLE handle, void *digest) _gnutls_hash_deinit(td, digest); } - return; } void _gnutls_mac_deinit_ssl3_handshake(GNUTLS_MAC_HANDLE handle, @@ -325,7 +322,6 @@ void _gnutls_mac_deinit_ssl3_handshake(GNUTLS_MAC_HANDLE handle, _gnutls_hash_deinit(td, digest); } - return; } static int ssl3_sha(int i, char *secret, int secret_len, char *random, diff --git a/lib/gnutls_int.h b/lib/gnutls_int.h index 4c4d99d0b9..10f2a034df 100644 --- a/lib/gnutls_int.h +++ b/lib/gnutls_int.h @@ -95,9 +95,9 @@ typedef void * gnutls_transport_ptr; #include <gnutls_mem.h> #include <gnutls_ui.h> -#define DECR_LEN(len, x) len-=x; if (len<0) {gnutls_assert(); return GNUTLS_E_UNEXPECTED_PACKET_LENGTH;} -#define DECR_LENGTH_RET(len, x, RET) len-=x; if (len<0) {gnutls_assert(); return RET;} -#define DECR_LENGTH_COM(len, x, COM) len-=x; if (len<0) {gnutls_assert(); COM;} +#define DECR_LEN(len, x) do { len-=x; if (len<0) {gnutls_assert(); return GNUTLS_E_UNEXPECTED_PACKET_LENGTH;} } while (0) +#define DECR_LENGTH_RET(len, x, RET) do { len-=x; if (len<0) {gnutls_assert(); return RET;} } while (0) +#define DECR_LENGTH_COM(len, x, COM) do { len-=x; if (len<0) {gnutls_assert(); COM;} } while (0) typedef unsigned char opaque; typedef struct { opaque pint[3]; } uint24; diff --git a/lib/gnutls_num.c b/lib/gnutls_num.c index 8e078bb098..7729722c00 100644 --- a/lib/gnutls_num.c +++ b/lib/gnutls_num.c @@ -97,7 +97,6 @@ uint24 tmp; data[0] = tmp.pint[0]; data[1] = tmp.pint[1]; data[2] = tmp.pint[2]; - return; } uint32 _gnutls_read_uint32( const opaque* data) { @@ -116,7 +115,6 @@ void _gnutls_write_uint32( uint32 num, opaque* data) { num = byteswap32( num); #endif memcpy( data, &num, sizeof(uint32)); - return; } uint16 _gnutls_read_uint16( const opaque* data) { @@ -134,7 +132,6 @@ void _gnutls_write_uint16( uint16 num, opaque* data) { num = byteswap16( num); #endif memcpy( data, &num, sizeof(uint16)); - return; } uint32 _gnutls_conv_uint32( uint32 data) { diff --git a/lib/gnutls_pk.c b/lib/gnutls_pk.c index 7f4fe1b652..5b523fb06e 100644 --- a/lib/gnutls_pk.c +++ b/lib/gnutls_pk.c @@ -619,7 +619,7 @@ int _gnutls_pk_decrypt(int algo, GNUTLS_MPI * resarr, GNUTLS_MPI data, GNUTLS_MP if (rc != 0) { gnutls_assert(); - return GNUTLS_E_PK_ENCRYPTION_FAILED; + return GNUTLS_E_PK_DECRYPTION_FAILED; } else { /* add better error handling or make gnupg use S-Exp directly */ resarr[0] = gcry_sexp_nth_mpi(s_plain, 0, 0); diff --git a/lib/gnutls_random.c b/lib/gnutls_random.c index ffabbe7120..b80639ca1e 100644 --- a/lib/gnutls_random.c +++ b/lib/gnutls_random.c @@ -43,15 +43,17 @@ int _gnutls_get_random(opaque * res, int bytes, int level) int fd; char *device; - device = "dev/urandom"; + device = "/dev/urandom"; fd = open(device, O_RDONLY); - if (device == NULL || fd < 0) { + if (fd < 0) { _gnutls_log( "Could not open random device\n"); return GNUTLS_E_FILE_ERROR; } else { - read(fd, res, bytes); + ssize_t err = read(fd, res, bytes); + /* IMPLEMENTME: handle EINTR etc. nicely! */ close(fd); + if ( (err < 0) || (err < bytes) ) return GNUTLS_E_FILE_ERROR; } return 0; #else /* using gcrypt */ @@ -61,4 +63,3 @@ int _gnutls_get_random(opaque * res, int bytes, int level) #endif } - diff --git a/lib/gnutls_state.c b/lib/gnutls_state.c index e58ac27f0c..0bbb497519 100644 --- a/lib/gnutls_state.c +++ b/lib/gnutls_state.c @@ -310,8 +310,6 @@ void _gnutls_deinit(gnutls_session session) memset( session, 0, sizeof(struct gnutls_session_int)); gnutls_free(session); - - return; } /** @@ -635,7 +633,6 @@ int i; for (i = 0; i < length; i++) { o1[i] ^= o2[i]; } - return ; } diff --git a/lib/gnutls_v2_compat.c b/lib/gnutls_v2_compat.c index 48ec1ae9e1..ac84f89549 100644 --- a/lib/gnutls_v2_compat.c +++ b/lib/gnutls_v2_compat.c @@ -154,7 +154,7 @@ int _gnutls_read_client_hello_v2(gnutls_session session, opaque * data, */ if (_gnutls_get_kx_cred( session, _gnutls_cipher_suite_get_kx_algo(session->security_parameters.current_cipher_suite), &err) == NULL && err != 0) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } /* set the MOD_AUTH_STRUCT to the appropriate struct diff --git a/lib/gnutls_x509.c b/lib/gnutls_x509.c index a765b12217..50b00a7c92 100644 --- a/lib/gnutls_x509.c +++ b/lib/gnutls_x509.c @@ -87,7 +87,7 @@ int _gnutls_x509_cert_verify_peers(gnutls_session session) cred = _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } if (info->raw_certificate_list == NULL || info->ncerts == 0) diff --git a/lib/minitasn1/errors.c b/lib/minitasn1/errors.c index 70f38cb3a8..56f43d5568 100644 --- a/lib/minitasn1/errors.c +++ b/lib/minitasn1/errors.c @@ -114,8 +114,6 @@ void _libtasn1_log( const char *fmt, ...) { va_end(args); fprintf(stderr, str); - - return; } #else /* not DEBUG */ # ifndef C99_MACROS @@ -19,6 +19,10 @@ * */ +/* This file contains the RC2 cipher algorithm. This is the RC2 + * used in PKCS #12. RC2 with 40 bit key reduced to 40 bits (!!!). + */ + #include <gnutls_int.h> #include <gnutls_errors.h> #include <gcrypt.h> @@ -193,6 +197,9 @@ do_rc2_setkey (void *context, const uint8 *key, unsigned int keylen) int bits = keylen * 8, len; #if 0 + /* Self test is for the plain cipher (with phase 2 stripped) + */ + if( !initialized ) { initialized = 1; selftest_failed = selftest(); diff --git a/libextra/auth_srp.c b/libextra/auth_srp.c index 6e32edc14e..4c62e5963e 100644 --- a/libextra/auth_srp.c +++ b/libextra/auth_srp.c @@ -197,7 +197,7 @@ int _gnutls_gen_srp_client_kx(gnutls_session state, opaque ** data) if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CRED; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } username = cred->username; @@ -205,14 +205,14 @@ int _gnutls_gen_srp_client_kx(gnutls_session state, opaque ** data) if (username == NULL || password == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CRED; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } /* calc A = g^a % N */ if (G == NULL || N == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CRED; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } A = _gnutls_calc_srp_A( &_a, G, N); @@ -380,7 +380,7 @@ int _gnutls_proc_srp_server_kx(gnutls_session state, opaque * data, size_t _data if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CRED; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } username = cred->username; @@ -388,7 +388,7 @@ int _gnutls_proc_srp_server_kx(gnutls_session state, opaque * data, size_t _data if (username == NULL || password == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CRED; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } i = 0; diff --git a/libextra/auth_srp_passwd.c b/libextra/auth_srp_passwd.c index 66a3ac79ce..77a31aeed4 100644 --- a/libextra/auth_srp_passwd.c +++ b/libextra/auth_srp_passwd.c @@ -238,7 +238,7 @@ int _gnutls_srp_pwd_read_entry( gnutls_session state, char* username, if (cred==NULL) { gnutls_assert(); _gnutls_srp_entry_free(entry); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } /* if the callback which sends the parameters is @@ -399,8 +399,6 @@ void _gnutls_srp_entry_free( SRP_PWD_ENTRY * entry) { gnutls_free(entry->username); gnutls_free(entry); - - return; } diff --git a/libextra/auth_srp_rsa.c b/libextra/auth_srp_rsa.c index a395a3548c..4d05a06525 100644 --- a/libextra/auth_srp_rsa.c +++ b/libextra/auth_srp_rsa.c @@ -95,7 +95,7 @@ int apr_cert_list_length; cred = _gnutls_get_cred(session->key, GNUTLS_CRD_CERTIFICATE, NULL); if (cred == NULL) { gnutls_assert(); - return GNUTLS_E_INSUFICIENT_CREDENTIALS; + return GNUTLS_E_INSUFFICIENT_CREDENTIALS; } /* find the appropriate certificate */ diff --git a/libextra/gnutls_extra.c b/libextra/gnutls_extra.c index 53c042bd95..5938e9ff92 100644 --- a/libextra/gnutls_extra.c +++ b/libextra/gnutls_extra.c @@ -157,8 +157,6 @@ static void _gnutls_add_openpgp_functions(void) { _E_gnutls_openpgp_fingerprint = gnutls_openpgp_fingerprint; _E_gnutls_openpgp_request_key = _gnutls_openpgp_request_key; _E_gnutls_openpgp_cert2gnutls_cert = _gnutls_openpgp_cert2gnutls_cert; - - return; } extern const char* gnutls_check_version( const char*); diff --git a/libextra/gnutls_openssl.c b/libextra/gnutls_openssl.c index 10c7d79826..23f20e62a9 100644 --- a/libextra/gnutls_openssl.c +++ b/libextra/gnutls_openssl.c @@ -39,7 +39,6 @@ int SSL_library_init(void) void OpenSSL_add_all_algorithms(void) { - return; } @@ -111,7 +110,7 @@ long SSL_CTX_set_mode(SSL_CTX *ctx, long mode) int SSL_CTX_set_cipher_list(SSL_CTX *ctx, const char *list) { /* FIXME: ignore this for the moment */ - /* We've going to have to parse the "list" string to do this */ + /* We're going to have to parse the "list" string to do this */ /* It is a string, which in its simplest form is something like "DES-CBC3-SHA:IDEA-CBC-MD5", but can be rather more complicated (see OpenSSL's ciphers(1) manpage for details) */ @@ -225,12 +224,10 @@ void SSL_free(SSL *ssl) gnutls_certificate_free_cred(ssl->gnutls_cred); gnutls_deinit(ssl->gnutls_state); free(ssl); - return; } void SSL_load_error_strings(void) { - return; } int SSL_get_error(SSL *ssl, int ret) @@ -275,7 +272,6 @@ void SSL_set_bio(SSL *ssl, BIO *rbio, BIO *wbio) void SSL_set_connect_state(SSL *ssl) { - return; } int SSL_pending(SSL *ssl) @@ -806,7 +802,6 @@ char *X509_NAME_oneline(gnutls_x509_dn *name, char *buf, int len) void X509_free(const X509 *cert) { /* only get certificates as const items */ - return; } @@ -858,7 +853,6 @@ int RAND_status(void) void RAND_seed(const void *buf, int num) { - return; } int RAND_bytes(unsigned char *buf, int num) @@ -893,7 +887,7 @@ int RAND_egd_bytes(const char *path, int bytes) void MD5_Init(MD5_CTX *ctx) { - ctx->handle = gcry_md_open(GCRY_MD_MD5, 0); + gcry_md_open(&ctx->handle, GCRY_MD_MD5, 0); } void MD5_Update(MD5_CTX *ctx, const void *buf, int len) @@ -934,7 +928,7 @@ unsigned char *MD5(const unsigned char *buf, unsigned long len, void RIPEMD160_Init(RIPEMD160_CTX *ctx) { - ctx->handle = gcry_md_open(GCRY_MD_RMD160, 0); + gcry_md_open(&ctx->handle, GCRY_MD_RMD160, 0); } void RIPEMD160_Update(RIPEMD160_CTX *ctx, const void *buf, int len) diff --git a/libextra/gnutls_srp.h b/libextra/gnutls_srp.h index fa3883606b..4990ec09ef 100644 --- a/libextra/gnutls_srp.h +++ b/libextra/gnutls_srp.h @@ -1,11 +1,11 @@ #ifdef ENABLE_SRP -int _gnutls_srp_gx(opaque *text, size_t textsize, opaque** result, MPI g, MPI prime, gnutls_alloc_function); -MPI _gnutls_calc_srp_B(MPI * ret_b, MPI g, MPI n, MPI v); -MPI _gnutls_calc_srp_u( MPI A, MPI B); -MPI _gnutls_calc_srp_S1(MPI A, MPI b, MPI u, MPI v, MPI n); -MPI _gnutls_calc_srp_A(MPI *a, MPI g, MPI n); -MPI _gnutls_calc_srp_S2(MPI B, MPI g, MPI x, MPI a, MPI u, MPI n); +int _gnutls_srp_gx(opaque *text, size_t textsize, opaque** result, GNUTLS_MPI g, GNUTLS_MPI prime, gnutls_alloc_function); +GNUTLS_MPI _gnutls_calc_srp_B(GNUTLS_MPI * ret_b, GNUTLS_MPI g, GNUTLS_MPI n, GNUTLS_MPI v); +GNUTLS_MPI _gnutls_calc_srp_u( GNUTLS_MPI A, GNUTLS_MPI B); +GNUTLS_MPI _gnutls_calc_srp_S1(GNUTLS_MPI A, GNUTLS_MPI b, GNUTLS_MPI u, GNUTLS_MPI v, GNUTLS_MPI n); +GNUTLS_MPI _gnutls_calc_srp_A(GNUTLS_MPI *a, GNUTLS_MPI g, GNUTLS_MPI n); +GNUTLS_MPI _gnutls_calc_srp_S2(GNUTLS_MPI B, GNUTLS_MPI g, GNUTLS_MPI x, GNUTLS_MPI a, GNUTLS_MPI u, GNUTLS_MPI n); int _gnutls_calc_srp_x( char* username, char* password, opaque* salt, size_t salt_size, size_t* size, void* digest); int _gnutls_srp_gn( opaque** ret_g, opaque** ret_n, int bits); diff --git a/src/common.c b/src/common.c index b53998e7d8..0df166de94 100644 --- a/src/common.c +++ b/src/common.c @@ -407,8 +407,6 @@ void print_list(void) printf("Compression methods:"); printf(" ZLIB"); printf(", NULL\n"); - - return; } void print_license(void) diff --git a/src/serv.c b/src/serv.c index 852d329b12..840f568bb1 100644 --- a/src/serv.c +++ b/src/serv.c @@ -1021,7 +1021,6 @@ static void wrap_db_init(void) static void wrap_db_deinit(void) { - return; } static int wrap_db_store(void *dbf, gnutls_datum key, gnutls_datum data) diff --git a/tests/x509_test.c b/tests/x509_test.c index d458a23294..f1390921fd 100644 --- a/tests/x509_test.c +++ b/tests/x509_test.c @@ -47,8 +47,6 @@ static void print_res( int x) if (x&GNUTLS_CERT_REVOKED) printf("- certificate is revoked.\n"); - - return; } int main() |