5357N/A * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights reserved. 0N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A * This code is free software; you can redistribute it and/or modify it 0N/A * under the terms of the GNU General Public License version 2 only, as 2362N/A * published by the Free Software Foundation. Oracle designates this 0N/A * particular file as subject to the "Classpath" exception as provided 2362N/A * by Oracle in the LICENSE file that accompanied this code. 0N/A * This code is distributed in the hope that it will be useful, but WITHOUT 0N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A * version 2 for more details (a copy is included in the LICENSE file that 0N/A * accompanied this code). 0N/A * You should have received a copy of the GNU General Public License version 0N/A * 2 along with this work; if not, write to the Free Software Foundation, 0N/A * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 2362N/A * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 2362N/A * or visit www.oracle.com if you need additional information or have any 0N/A * Many data structures are involved in the handshake messages. These 0N/A * classes are used as structures, with public data members. They are 0N/A * not visible outside the SSL package. 0N/A * Handshake messages all have a common header format, and they are all 0N/A * encoded in a "handshake data" SSL record substream. The base class 0N/A * here (HandshakeMessage) provides a common framework and records the 0N/A * SSL record type of the particular handshake message. 0N/A * This file contains subclasses for all the basic handshake messages. 0N/A * All handshake messages know how to encode and decode themselves on 0N/A * SSL streams; this facilitates using the same code on SSL client and 0N/A * server sides, although they don't send and receive the same messages. 0N/A * Messages also know how to print themselves, which is quite handy 0N/A * for debugging. They always identify their type, and can optionally 0N/A * dump all of their content. 0N/A * @author David Brownell 0N/A // enum HandshakeType: 0N/A /* Class and subclass dynamic debugging support */ 0N/A * Utility method to convert a BigInteger to a byte array in unsigned 0N/A * format as needed in the handshake messages. BigInteger uses 0N/A * 2's complement format, i.e. it prepends an extra zero if the MSB 0N/A * is set. We remove that. 0N/A * SSL 3.0 MAC padding constants. 0N/A * Also used by CertificateVerify and Finished during the handshake. 0N/A * Write a handshake message on the (handshake) output stream. 0N/A * This is just a four byte header followed by the data. 0N/A * NOTE that huge messages -- notably, ones with huge cert 0N/A * chains -- are handled correctly. 0N/A * Subclasses implement these methods so those kinds of 0N/A * messages can be emitted. Base class delegates to subclass. 0N/A * Write a descriptive message on the output stream; for debugging. 0N/A// NOTE: the rest of these classes are nested within this one, and are 0N/A// imported by other classes in this package. There are a few other 0N/A// handshake message classes, not neatly nested here because of current 0N/A// licensing requirement for native (RSA) methods. They belong here, 0N/A// but those native methods complicate things a lot! 0N/A * HelloRequest ... SERVER --> CLIENT 0N/A * Server can ask the client to initiate a new handshake, e.g. to change 0N/A * session parameters after a connection has been (re)established. 0N/A // nothing in this message 0N/A // nothing in this messaage 0N/A * ClientHello ... CLIENT --> SERVER 0N/A * Client initiates handshake by telling server what it wants, and what it 0N/A * can support (prioritized by what's first in the ciphe suite list). 0N/A * By RFC2246:7.4.1.2 it's explicitly anticipated that this message 0N/A * will have more data added at the end ... e.g. what CAs the client trusts. 0N/A * Until we know how to parse it, we will just read what we know 0N/A * about, and let our caller handle the jumps over unknown data. 2890N/A // add renegotiation_info extension 3002N/A // add server_name extension 3002N/A // We would have checked that the hostname ia a FQDN. 3002N/A // ignore the exception and return 3002N/A // add signature_algorithm extension 2890N/A * Add fixed size parts of each field... 2890N/A * version + random + session + cipher + compress 0N/A * ServerHello ... SERVER --> CLIENT 0N/A * Server chooses protocol options from among those it supports and the 0N/A * client supports. Then it sends the basic session descriptive parameters 0N/A * back to the client. 0N/A // almost fixed size, except session ID and extensions: 0N/A // major + minor = 2 0N/A // session ID len field = 1 0N/A // cipher suite + compression = 3 0N/A // extensions: if present, 2 + length of extensions 0N/A * CertificateMsg ... send by both CLIENT and SERVER 0N/A * Each end of a connection may need to pass its certificate chain to 0N/A * the other end. Such chains are intended to validate an identity with 0N/A * reference to some certifying authority. Examples include companies 0N/A * like Verisign, or financial institutions. There's some control over 0N/A * the certifying authorities which are sent. 0N/A * NOTE: that these messages might be huge, taking many handshake records. 0N/A * Up to 2^48 bytes of certificate may be sent, in records of at most 2^14 0N/A * bytes each ... up to 2^32 records sent on the output stream. 0N/A * ServerKeyExchange ... SERVER --> CLIENT 0N/A * The cipher suite selected, when combined with the certificate exchanged, 0N/A * implies one of several different kinds of key exchange. Most current 0N/A * cipher suites require the server to send more than its certificate. 0N/A * The primary exceptions are when a server sends an encryption-capable 0N/A * RSA public key in its cert, to be used with RSA (or RSA_export) key 0N/A * exchange; and when a server sends its Diffie-Hellman cert. Those kinds 0N/A * of key exchange do not require a ServerKeyExchange message. 0N/A * Key exchange can be viewed as having three modes, which are explicit 0N/A * for the Diffie-Hellman flavors and poorly specified for RSA ones: 0N/A * - "Ephemeral" keys. Here, a "temporary" key is allocated by the 0N/A * server, and signed. Diffie-Hellman keys signed using RSA or 0N/A * DSS are ephemeral (DHE flavor). RSA keys get used to do the same 0N/A * thing, to cut the key size down to 512 bits (export restrictions) 0N/A * or for signing-only RSA certificates. 0N/A * - Anonymity. Here no server certificate is sent, only the public 0N/A * key of the server. This case is subject to man-in-the-middle 0N/A * attacks. This can be done with Diffie-Hellman keys (DH_anon) or 0N/A * with RSA keys, but is only used in SSLv3 for DH_anon. 0N/A * - "Normal" case. Here a server certificate is sent, and the public 0N/A * key there is used directly in exchanging the premaster secret. 0N/A * For example, Diffie-Hellman "DH" flavor, and any RSA flavor with 0N/A * only 512 bit keys. 0N/A * If a server certificate is sent, there is no anonymity. However, 0N/A * when a certificate is sent, ephemeral keys may still be used to 0N/A * exchange the premaster secret. That's how RSA_EXPORT often works, 0N/A * as well as how the DHE_* flavors work. 0N/A * Using RSA for Key Exchange: exchange a session key that's not as big 0N/A * as the signing-only key. Used for export applications, since exported 0N/A * RSA encryption keys can't be bigger than 512 bytes. 0N/A * This is never used when keys are 512 bits or smaller, and isn't used 0N/A * on "US Domestic" ciphers in any case. 0N/A * Hash the nonces and the ephemeral RSA public key. 0N/A * Construct an RSA server key exchange message, using data 0N/A * known _only_ to the server. 0N/A * The client knows the public key corresponding to this private 0N/A * key, from the Certificate message sent previously. To comply 0N/A * with US export regulations we use short RSA keys ... either 0N/A * long term ones in the server's X509 cert, or else ephemeral 0N/A * ones sent using this message. 0N/A * Parse an RSA server key exchange message, using data known 0N/A * to the client (and, in some situations, eavesdroppers). 0N/A * Get the ephemeral RSA public key that will be used in this 0N/A // modulus and exponent are always positive 0N/A * Verify the signed temporary key using the hashes computed 0N/A * from it and the two nonces. This is called by clients 0N/A * with "exportable" RSA flavors. 0N/A * Using Diffie-Hellman algorithm for key exchange. All we really need to 0N/A * do is securely get Diffie-Hellman keys (using the same P, G parameters) 0N/A * to our peer, then we automatically have a shared secret without need 0N/A * to exchange any more data. (D-H only solutions, such as SKIP, could 0N/A * eliminate key exchange negotiations and get faster connection setup. 0N/A * But they still need a signature algorithm like DSS/DSA to support the 0N/A * trusted distribution of keys without relying on unscalable physical 0N/A * key distribution systems.) 0N/A * This class supports several DH-based key exchange algorithms, though 0N/A * perhaps eventually each deserves its own class. Notably, this has 0N/A * basic support for DH_anon and its DHE_DSS and DHE_RSA signed variants. 0N/A // Fix message encoding, see 4348279 0N/A private byte dh_p [];
// 1 to 2^16 - 1 bytes 0N/A private byte dh_g [];
// 1 to 2^16 - 1 bytes 0N/A private byte dh_Ys [];
// 1 to 2^16 - 1 bytes 3002N/A // protocol version being established using this ServerKeyExchange message 3002N/A // the preferable signature algorithm used by this ServerKeyExchange message 0N/A * Construct from initialized DH key object, for DH_anon 5690N/A // The DH key has been validated in the constructor of DHCrypt. 0N/A * Construct from initialized DH key object and the key associated 0N/A * with the cert chain which was sent ... for DHE_DSS and DHE_RSA 0N/A * key exchange. (Constructor called by server.) 5690N/A // The DH key has been validated in the constructor of DHCrypt. 0N/A * Construct a DH_ServerKeyExchange message from an input 0N/A * stream, as if sent from server to client for use with 0N/A * DH_anon key exchange 0N/A * Construct a DH_ServerKeyExchange message from an input stream 0N/A * and a certificate, as if sent from server to client for use with 0N/A * DHE_DSS or DHE_RSA key exchange. (Called by client.) 3002N/A // read params: ServerDHParams 3002N/A // read the signature and hash algorithm 3002N/A // Is it a local supported signature algorithm? 3002N/A "Unsupported SignatureAndHashAlgorithm in " +
3002N/A "ServerKeyExchange message");
3865N/A /* Return the Diffie-Hellman modulus */ 3865N/A /* Return the server's Diffie-Hellman public key */ 3865N/A * Update sig with nonces and Diffie-Hellman public key. 0N/A int temp =
6;
// overhead for p, g, y(s) values. 0N/A s.
println(
"*** Diffie-Hellman ServerKeyExchange");
0N/A * ECDH server key exchange message. Sent by the server for ECDHE and ECDH_anon 0N/A * ciphersuites to communicate its ephemeral public key (including the 0N/A * EC domain parameters). 0N/A * We support named curves only, no explicitly encoded curves. 0N/A // constants for ECCurveType 0N/A // id of the curve we are using 0N/A // encoded public point 0N/A // signature bytes (or null if anonymous) 0N/A // public key object encapsulated in this message 3002N/A // protocol version being established using this ServerKeyExchange message 3002N/A // the preferable signature algorithm used by this ServerKeyExchange message 0N/A * Parse an ECDH server key exchange message. 3002N/A // read params: ServerECDHParams 0N/A // These parsing errors should never occur as we negotiated 0N/A // the supported curves during the exchange of the Hello messages. 3002N/A // read the signature and hash algorithm 3002N/A // Is it a local supported signature algorithm? 3002N/A "Unsupported SignatureAndHashAlgorithm in " +
3002N/A "ServerKeyExchange message");
3002N/A "Invalid signature on ECDH server key exchange message");
0N/A * Get the ephemeral EC public key encapsulated in this message. 0N/A * DER encoded distinguished name. 0N/A * TLS requires that its not longer than 65535 bytes. 0N/A * CertificateRequest ... SERVER --> CLIENT 0N/A * Authenticated servers may ask clients to authenticate themselves 0N/A * in turn, using this message. 3002N/A * Prior to TLS 1.2, the structure of the message is defined as: 3002N/A * ClientCertificateType certificate_types<1..2^8-1>; 3002N/A * DistinguishedName certificate_authorities<0..2^16-1>; 3002N/A * In TLS 1.2, the structure is changed to: 3002N/A * ClientCertificateType certificate_types<1..2^8-1>; 3002N/A * SignatureAndHashAlgorithm 3002N/A * supported_signature_algorithms<2^16-1>; 3002N/A * DistinguishedName certificate_authorities<0..2^16-1>; 0N/A // enum ClientCertificateType 0N/A // The existance of these two values is a bug in the SSL specification. 0N/A // They are never used in the protocol. 0N/A // From RFC 4492 (ECC) 0N/A // ... "3" because that's the smallest DER-encoded X500 DN 3002N/A // protocol version being established using this CertificateRequest message 3002N/A // supported_signature_algorithms for TLS 1.2 or later 3002N/A // length of supported_signature_algorithms 0N/A // always use X500Principal 0N/A // we support RSA, DSS, and ECDSA client authentication and they 0N/A // can be used with all ciphersuites. If this changes, the code 0N/A // needs to be adapted to take keyExchange into account. 0N/A // We only request ECDSA client auth if we have ECC crypto available. 3002N/A // Use supported_signature_algorithms for TLS 1.2 or later. 3002N/A "No supported signature algorithms");
3002N/A // Read the certificate_types. 3002N/A // Read the supported_signature_algorithms for TLS 1.2 or later. 3002N/A "Invalid supported_signature_algorithms field");
3002N/A "Invalid supported_signature_algorithms field");
3002N/A // read the certificate_authorities 3002N/A // put supported_signature_algorithms 3002N/A // put certificate_authorities 0N/A s.
print(
"Ephemeral DH (RSA sig)");
break;
0N/A s.
print(
"Ephemeral DH (DSS sig)");
break;
0N/A s.
print(
"Fixed ECDH (ECDSA sig)");
break;
0N/A * ServerHelloDone ... SERVER --> CLIENT 0N/A * When server's done sending its messages in response to the client's 0N/A * "hello" (e.g. its own hello, certificate, key exchange message, perhaps 0N/A * client certificate request) it sends this message to flag that it's 0N/A * done that part of the handshake. 0N/A * CertificateVerify ... CLIENT --> SERVER 0N/A * Sent after client sends signature-capable certificates (e.g. not 0N/A * Diffie-Hellman) to verify. 3002N/A // protocol version being established using this ServerKeyExchange message 3002N/A // the preferable signature algorithm used by this CertificateVerify message 0N/A * Create an RSA or DSA signed certificate verify message. 0N/A // Unmarshal the signed data from the input stream. 3002N/A // read the signature and hash algorithm 3002N/A // Is it a local supported signature algorithm? 3002N/A "Unsupported SignatureAndHashAlgorithm in " +
3002N/A "ServerKeyExchange message");
3002N/A * Get the preferable signature algorithm used by this message 0N/A * Verify a certificate verify message. Return the result of verification, 0N/A * if there is a problem throw a GeneralSecurityException. 0N/A * Get the Signature object appropriate for verification using the 0N/A * given signature algorithm and protocol version. 0N/A * Update the Signature with the data appropriate for the given 0N/A * signature algorithm and protocol version so that the object is 0N/A * ready for signing or verifying. 3002N/A // The signature must be an instance of RSASignature, need 3002N/A // to use these hashes directly. 0N/A }
else {
// DSA, ECDSA 0N/A * Update the MessageDigest for SSLv3 certificate verify or finished 0N/A * message calculation. The digest must already have been updated with 0N/A * all preceding handshake messages. 0N/A * Used by the Finished class as well. 0N/A // Digest the key bytes if available. 0N/A // Otherwise (sensitive key), try digesting the key directly. 0N/A // That is currently only implemented in SunPKCS11 using a private 0N/A // reflection API, so we avoid that if possible. 0N/A // ConcurrentHashMap does not allow null values, use this marker object 0N/A // cache Method objects per Spi class 0N/A // Note that this will prevent the Spi classes from being GC'd. We assume 0N/A // that is not a problem. 0N/A // Verify that md is implemented via MessageDigestSpi, not 0N/A // via JDK 1.1 style MessageDigest subclassing. 3002N/A "Digest does not support implUpdate(SecretKey)");
3002N/A "Could not obtain encoded key and " 3002N/A +
"MessageDigest cannot digest key", e);
0N/A * FINISHED ... sent by both CLIENT and SERVER 0N/A * This is the FINISHED message as defined in the SSL and TLS protocols. 0N/A * Both protocols define this handshake message slightly differently. 0N/A * This class supports both formats. 0N/A * When handshaking is finished, each side sends a "change_cipher_spec" 0N/A * record, then immediately sends a "finished" handshake message prepared 0N/A * according to the newly adopted cipher spec. 0N/A * NOTE that until this is sent, no application data may be passed, unless 0N/A * some non-default cipher suite has already been set up on this connection 0N/A * connection (e.g. a previous handshake arranged one). 0N/A // constant for a Finished message sent by the client 0N/A // constant for a Finished message sent by the server 0N/A // enum Sender: "CLNT" and "SRVR" 0N/A private static final byte[]
SSL_CLIENT = {
0x43,
0x4C,
0x4E,
0x54 };
0N/A private static final byte[]
SSL_SERVER = {
0x53,
0x52,
0x56,
0x52 };
0N/A * Contents of the finished message ("checksum"). For TLS, it 0N/A * is 12 bytes long, for SSLv3 36 bytes. 3002N/A * Current cipher suite we are negotiating. TLS 1.2 has 3002N/A * ciphersuite-defined PRF algorithms. 0N/A * Create a finished message to send to the remote peer. 0N/A * Constructor that reads FINISHED message from stream. 0N/A * Verify that the hashes here are what would have been produced 0N/A * according to a given set of inputs. This is used to ensure that 0N/A * both client and server are fully in sync, and that the handshake 0N/A * computations have been successful. 0N/A * Perform the actual finished message calculation. 3002N/A // Get the KeyGenerator alg and calculate the seed. 3002N/A * RFC 5246/7.4.9 says that finished messages can 3002N/A * algorithm. If we ever run across a different 3002N/A * length, this call will need to be updated. 3002N/A "Invalid PRF output, format must be RAW");
0N/A * Update the MessageDigest for SSLv3 finished message calculation. 0N/A * The digest must already have been updated with all preceding handshake 0N/A * messages. This operation is almost identical to the certificate verify 0N/A * hash, reuse that code. 2890N/A // get the verify_data of the finished message 0N/A// END of nested classes